Stop prompting, start briefing: how to delegate real work to AI

When someone tells me AI gave them garbage, I ask to see what they typed. It is almost always one sentence. "Make the website faster." "Write me a landing page." "Fix the bug." Then they conclude the model is overhyped and go back to doing everything by hand. The model was fine. The instruction was the problem. Nobody would hand a contractor a one-line WhatsApp message and expect a finished kitchen, but that is exactly how most people talk to the most capable tools they have ever had access to.

The fix is a shift in posture. Stop writing prompts. Start writing briefs.

A prompt asks, a brief delegates

A prompt is a question you throw at a chat box and hope. A brief is what you would hand a competent freelancer you are paying by the hour: what the job is, what done looks like, what they must not touch, and where to find everything they need. The mental model matters because it changes what you write. You would never tell a freelancer "make it better" and walk away. You would also never dump forty pages of background on them for a two-hour task.

AI agents sit in exactly that frame. They are fast, capable, tireless, and completely dependent on you for context and judgment about what matters. Treat every session like a delegation, not a conversation, and the quality of what comes back changes overnight.

Say what done means before any work starts

The single highest-leverage line in any brief is the success criteria. Before the AI writes a single line of code or copy, it should know how the result will be judged. "Done means the contact form sends an email, shows an error state when it fails, and the existing tests still pass." That one sentence does more work than three paragraphs of description, because it gives the agent something to verify against instead of a vibe to aim for.

This is the same rule I hold my own setup to. In the constitution file I load into every Claude Code session, one of the standing rules is: state the success criteria you will verify against before starting, and loop until every criterion is met. Without that, the agent stops at "probably works." With it, the agent has a finish line it can actually see.

Constraints matter more than instructions

Here is the counterintuitive part: what you tell the AI not to do usually matters more than what you tell it to do. Models are eager. Ask one to fix a bug and it will happily refactor the three files next to it, rename some variables it found ugly, and reformat the whole folder while it is in there. Every one of those uninvited changes is a fresh chance to break something that worked.

So the brief names the boundaries. Touch only these files. Do not upgrade any dependencies. Match the existing style even if you would write it differently. Do not touch the payment code at all. A tight boundary does not limit the agent, it focuses it, the same way a clear scope of work protects both you and the contractor from the renovation that never ends.

Give it the context it cannot guess

The model knows a great deal about the world and nothing about your business. It does not know your customers message you on WhatsApp instead of email, that your checkout has a quirk you handled two months ago, or that your brand never uses exclamation marks. If a detail lives only in your head, the AI does not have it, and it will fill the gap with the most statistically average assumption on the internet.

The cheapest way to transfer context is to point at examples. Here is a page that already looks the way I want. Here is the last proposal that won a client. Here is how we wrote the last three product descriptions. An example of what good looks like beats paragraphs of adjectives every single time. And for anything you find yourself explaining twice, write it down once in a standing document the AI reads every session, so the third explanation never happens. That is what a proper memory setup is for.

If two readings are plausible, that is your fault

When an instruction can be read two ways, a human colleague asks which one you meant. A model, by default, picks one and commits with full confidence. If it picks wrong, you burned the whole cycle, and the failure was in the brief, not the model.

Two habits fix this. First, reread your brief hunting for double meanings before you send it. "Update the pricing page" could mean new numbers, new layout, or new copy. Second, explicitly invite the question: tell the agent that when two readings are plausible, it should ask instead of guessing. Good agents honour that instruction. One clarifying question costs seconds. A confidently wrong afternoon of work costs a lot more.

The five-part brief I actually use

Every brief I hand to an AI agent, whether it is a coding task or a piece of writing, carries the same five parts:

• The task. One or two sentences on what needs to exist that does not exist now.
• Done means. The concrete criteria the result will be checked against. If you cannot write this line, you are not ready to delegate the task.
• Constraints. What must not change, what must not be touched, and which conventions to follow.
• Context. The files, examples, and background the agent cannot guess. Point at what good looks like.
• Verification. How the agent should prove the work is done: run the tests, show the output, screenshot the page. A claim of done is not evidence of done.

Writing this takes five minutes. Skipping it costs an hour of back-and-forth or, worse, a plausible-looking result that quietly does the wrong thing.

One job per brief

The other failure mode is the kitchen-sink request: fix the bug, and also redesign the header, and also can it load faster. Bundled asks produce bundled mediocrity, and when something breaks you cannot tell which change did it. Scope each brief to one outcome. Small, verified steps compound. Ten clean sequential tasks beat one sprawling request every time, and if a task feels too big to write a single "done means" line for, that is the signal to split it before you delegate it.

This is a transferable skill

Notice that nothing above is really about AI. Success criteria, constraints, context, verification: that is just competent delegation, the thing good managers and good clients already do. The people getting the most out of AI right now are not prompt wizards with secret incantations. They are people who already knew how to hand work to someone else and get it back done properly. The skill transfers in both directions, too. Learning to brief an AI well will make you better at briefing people.

The model will keep getting smarter without your help. The brief is the part you control. If you want AI agents set up to do real, verified work for your business rather than impressive demos, send a brief. I will read it the same way the agent would.