A task handed to the agent in a single phrase looks like the fastest form of work. "Fix the bug", "add a filter", "speed up the list" - short, clear, sent. The temptation is that it really is faster to write the request that way. But the speed of writing and the speed of getting the result you need are different things, and confusing the two is what costs the most afterward.
The naive move is natural because we carry over to the agent the habit of talking to a colleague. A living person makes do with a hint: they know the project, remember yesterday's conversation, see your face and will ask again if something is unclear. With that model in mind a short phrase looks sufficient - surely the other side will build out the rest on its own, as the person at the next desk would.
It breaks where the agent has none of your shared history, yet must still fill the gaps of the task with something. Given no goal, it will guess one from the wording; given no constraints, it will treat as allowed everything not forbidden; given no criteria, it will declare done the first thing that compiled. Guesses do not cancel the work - they steer it, and you get a carefully made wrong thing. After that you argue not with the agent but with its conjecture, the one you left unanswered.
Hence the working frame: a strong task is a contract of five fields, and each closes its own class of guesses. The goal - an observable change in behavior, not the name of a technique. The context - the entry point, the issue, versions and relevant files. The constraints - what must not change, compatibility requirements, the zone of risk. The acceptance criteria - concrete scenarios by which the task counts as closed. The verification - the commands, the manual scenario or the artifact by which the result is proven.
Let us separate the fields by meaning, because they are often confused. The goal answers "what will become different on the outside": not "add a cache" but "a repeat request for the same report returns without hitting the database". The context is not a retelling of the task in your own words but supporting points: the file and line where the symptom is visible, the issue number, the version in which it reproduces. The constraints outline the perimeter of the untouchable: which signatures and data formats must not change, which compatibility to hold, where the zone of heightened risk is. The criteria are not a restatement of the goal but a list of situations that must line up: empty input, maximum volume, concurrent access. The verification is not the promise "I tested it" but a concrete way to see it: a command with an expected exit code, a scenario in the browser, an artifact file.
Why five, and not three or ten. Fewer, and a gap for a guess opens again: with no constraints the agent will rewrite the neighbor "while it was at it", with no criteria it will stop too early. More, and the fields start duplicating one another, while surplus detail blurs the signal no less than emptiness does. Five is the minimal set that closes the four typical gaps of interpretation plus the way to prove the gap is actually closed.
The price of filling these fields is a few minutes before the start, and it seems excessive on a small task. But this price is paid once and up front, whereas the price of skipping is paid at the end and with interest: reading someone else's diff, rolling back what went the wrong way, a second pass with the clarification you should have given at once. The more autonomous the surface and the longer the turn, the more this difference works in your favor. There is a side benefit too: the filled fields outlive the session itself - they become a record of what was done and why, one you return to during review, during a rollback, or when someone else picks up the task a week later.
This does not mean every remark must be dressed as a contract. On a trivial inline edit through Command the five fields are redundant: the goal is obvious, the verification is a glance at the diff. The frame pays off where uncertainty or reach grows: multi-step work in Devin Local, a long task in the cloud, anything that touches more than one file. The rule is simple - the size of the contract is matched to the cost of a mistake, not written out of habit.
You can check the quality of the task itself before sending it, with one test: can the agent, having read the contract, name what it will prove the result with. If the verification field is empty or reduces to "it should work", the task is not ready - you will not be able to tell the done from the claimed. A good formulation is one from which the acceptance criterion and the way to verify are read off literally, with no fabrication on your part.
The typical failures repeat the skipped fields one for one. No goal - you get a solution to the wrong problem. No constraints - you get "improvements" in places you asked to be left alone. No criteria - you get "done" on half the scenarios. No verification - you get a word instead of a proof. The sign of all of them is the same: the argument is about what was meant, not about what is visible in the diff. Fill the five fields in advance, and there is nothing left to argue about.