You know what you want to build. Now it’s about saying it so 3B builds the right thing.
A good prompt isn’t longer or cleverer than a bad one. It’s just more complete. When a build comes back wrong, it’s rarely because you said something wrong, it’s because something went unsaid and 3B filled the gap for you. So the skill worth having isn’t fancy wording, it’s knowing what a prompt needs to contain and giving yours a quick once-over before you send it.
Four things tend to separate prompts that work from the ones that don’t: structure, specificity, constraints, and context.
Structure: say what happens in order
3B follows the shape of your request, so if you lay things out in the order they should happen, you usually get a build that flows that way too. Describe them in whatever order they pop into your head and 3B has to guess the sequence. For an app, the easiest approach is to walk through it the way someone would actually use it: what they see first, what they do, what happens next.
- Unstructured: “I want a Slack message and also a list of requests, oh and people should be able to filter it by status.”
- Structured: “Show submitted requests in a list that can be filtered by status. When a new one comes in, post a note to Slack.”
Same ingredients, but the second one gives 3B a clear order to build against instead of a pile of parts.
Specificity: name the thing
Vague nouns leave the details up to 3B. “Send a notification” says nothing about where, to whom, or what it should say. “Post a message to the #it-requests Slack channel with the requester and the item they asked for” leaves nothing to chance. Name the fields, the channel, the format. Every detail you pin down is one that doesn’t get decided for you.
Constraints: say what not to do
Constraints are the boundaries you’d otherwise end up enforcing later, by hand, after the build did the too-broad version. “Only show requests from the last 30 days.” “Don’t send a notification if the form’s incomplete.” “Cap the list at 50 rows.” They’re easy to forget because they live in your head as things that go without saying. Saying them anyway is often the difference between building once and building three times.
Context: explain the why when it changes the how
3B doesn’t need your life story, but it does want the context that actually changes the build. “This goes to the on-call manager, so keep the summary short” tells it something a bare instruction can’t. The rule of thumb: give context when it affects a decision 3B has to make, and skip it when it doesn’t.
Putting it together
Here’s the same request with all four working at once:
Build an app where people submit equipment requests through a form and IT sees them in a list they can filter by status (structure). Each row should show the requester, the item, and the submission time, and a new request posts those same details to #it-requests (specificity). Only show requests from the last 30 days, and don’t post anything if the form’s incomplete (constraints). The Slack note goes to the on-call manager, so keep it to a couple of lines (context).
You don’t need to label the parts like I have here. You just want all four in there somewhere.
Before you send a prompt, give it a quick read back: is the order clear, are the details named, are the limits set, and does 3B know anything it needs that isn’t obvious from the words? When the answer’s yes, you get to spend your time reviewing a build instead of wrestling one into shape.
One thing worth flagging before you go big: “complete” isn’t the same as “all at once.” When a task’s too large for a single prompt, you still describe the whole picture, you just build it in stages. That’s the next piece.
What’s next: Breaking complex tasks into steps, for when the thing you want is too big to fit in one tidy prompt.