This lesson's interactive features are locked, please to keep using them
Prompt Examples
Prompting isn't a dark art. I'd take a technical domain expert who understands their customer over someone with a "Prompting for Dummies" cheatsheet any day.
It's easy to learn to write better prompts. It's hard to learn to code and understand your customers' needs. That said, there are some basic rules to be aware of. Some providers even have guides on writing better prompts:
But you're here for our opinions, so here are a few more examples of good and bad prompts.
The following examples are of a software developer using AI to write code for a hypothetical online shopping site, like Amazon.com.
Clarify Scope
Worse:
Customer reviews aren't displaying large enough to be easily read; increase the font size.
Better:
Customer reviews on the product checkout page are hard to read; increase the font size of those reviews only.
Without a clear understanding of where and how much to update, the agent may choose to update a single file, or every related function across the codebase.
Provide Implementation Constraints
Worse:
Customer reviews on the product checkout page are hard to read; increase the font size of those reviews only.
Better:
Customer reviews on the product checkout page are hard to read; increase the font size of those reviews only. If the function is shared, allow configurable font size via parameters.
AI agents will often over-abstract or under-abstract aggressively, either by creating parameters that are never actually used, or on the contrary, reconstructing entirely new implementations that could have just been a new parameter.
AI can't produce good code without you.
Point the AI to Existing Patterns
Worse:
The checkout page currently always shows the price in US dollars. It should localize the price to the user's currency.
Better:
The checkout page currently always shows the price in US dollars. It should localize the price to the user's currency. Take a look at the gift-code page, which already implements this pattern.
The model REALLY wants to solve the problem, and it won't always scan your entire codebase perfectly to find existing patterns, especially if they're not easily found via a keyword-based regex. Tell it where to look if you already know the place.
Break Massive Tasks Into Smaller Steps
Worse:
Build me a new checkout experience from scratch using Stripe.
Better:
Build a new checkout page component on the frontend, using mock data for now.
Then work with the agent to get the UI the way you want it...
Add the backend endpoints necessary for the checkout page to function, and update the frontend accordingly to use them.
Then work with the agent to hook up the backend logic...
This one depends on how much planning you've done. If you wrote a detailed architecture prompt or had a long Plan session already, you can try to one-shot bigger tasks. It's higher-risk, higher-reward. If you step away and let the model cook, there's a good chance it goes off the rails early in a way that was entirely preventable.