Autocomplete is not the interesting part
Most people meet a coding model as a fancy autocomplete. You type half a line, it finishes the line, you hit tab. That is fine. It saves keystrokes. It is also the least valuable thing the model does, and if that is all you use it for you will conclude the hype is empty and go back to typing everything yourself.
The skill worth learning is different. It is delegation. You hand a whole task to something that works fast, takes you completely literally, and has no idea what you actually meant unless you said it out loud. In other words, you manage it exactly like a capable junior who started yesterday.
That comparison is not a cute metaphor. It is the operating manual. A good new hire is smart and quick and will absolutely build the wrong thing if your instructions were vague, because they fill the gaps with guesses. So will the model. The fix in both cases is the same. Write a brief that leaves fewer gaps.
The four-part brief
Over time the briefs that actually work all have the same four parts. I write them in this order every time.
What I want. One or two sentences of the actual goal, in plain words. Not the implementation, the outcome. "Add a retry with backoff to the upload function so a flaky network does not lose the file."
Where the material is. Point at the exact files, functions, or examples. A junior wastes an afternoon guessing which file you meant. The model does the same, except in seconds, and hands you a confident change to the wrong place. So say it. "The function is uploadFile in storage.js. There is an existing backoff helper in utils/retry.js, use that one."
What must not change. This is the part people forget, and it is the part that saves you. State the invariants. "Do not change the function signature. Do not touch the tests. Keep the existing log lines." Without this, a literal worker will happily improve things you never wanted touched, because nobody told them the blast radius.
What done looks like. Describe the finished state so both of you can check it. "Done means the upload retries three times with growing delays, the existing tests still pass, and there is one new test for the retry path." Now the work has a definition you can hold it against.
Before and after
Here is a real shaped example. The vague version first.
"Clean up the user settings code."
That is a wish, not a brief. Clean up how? Which code? Clean by whose taste? A junior would ask three questions before starting. The model does not ask, it guesses, and you get a sweeping rewrite that renames variables you liked, reorders functions for no reason, and quietly changes one default that breaks a test at the far end of the repo. Now you are reviewing a hundred lines of change to find the ten that matter.
The briefed version.
"In settings/user.js, the loadSettings function reads three config values with almost identical blocks. Collapse those into one helper. Keep the function name and its return shape exactly. Do not change any default values. Do not touch other files. Done means loadSettings is shorter, behavior is identical, and the settings tests still pass."
Same model. Same task, really. Completely different result, because the second one closed the gaps the first one left open. The change comes back small, scoped, and easy to read in thirty seconds. That short review is the whole game.
Check the work like a new hire
You would never let a brand new hire merge to main unread, no matter how sharp they seemed. Same rule here. The model is fast and literal and sometimes confidently wrong, which is precisely the junior profile, so you read every diff before it lands.
Reading the work is not a tax on delegation, it is the part that makes delegation safe. And a tight brief makes the reading cheap. When you said what must not change and what done looks like, review becomes a checklist. Did it stay inside the lines. Does it match the done state. Yes and yes, ship it. Something drifted, hand it back with one more sentence, the same way you would coach a junior after a first draft.
The people who get the most out of these tools are not the ones with secret prompts. They are the ones who already know how to delegate to a human and simply pointed that skill at a faster worker. Clear brief, tight scope, stated invariants, a check at the end. That is management, and it turns out management is the skill.
This is also why we teach by doing the work rather than watching lectures. You cannot learn to write a good brief by hearing about briefs. You learn it by shipping a real task, watching the literal worker take one of your fuzzy sentences at face value, and tightening it. Do that ten times and the four part brief stops being a checklist and becomes how you think.
AGINE Academy is an independent product by AGINE AI (not affiliated with Anthropic). We teach building with Claude by doing the work, not watching lectures.
Top comments (1)
The "what must not change" section is the part most teams under-specify, and it is probably more valuable than adding another paragraph of implementation guidance. Pointing the model to
uploadFileinstorage.jsand the existing helper inutils/retry.js, or preservingloadSettingsdefaults and return shape, turns review into an evidence check instead of a taste debate. For a founder or engineering lead, the useful metric is not generated code volume but review time plus escaped rework-the brief is working when both shrink without widening the blast radius.