Writing Tasks an Agent Can Actually Finish
The anatomy of a great agent task: goal, context, constraints, and a definition of done. Includes before/after rewrites of real prompts.
Hand two people the same coding agent and the same codebase, and one gets a clean, working change in ten minutes while the other gets a sprawling mess. The difference is rarely the model. It's almost always the task. "Fix the login" and a well-written task produce wildly different results from the exact same agent.
The good news is that writing tasks agents can finish is a learnable, repeatable skill with a simple structure behind it. In this lesson you'll learn the four parts of a strong task (goal, context, constraints, and a definition of done), see four before-and-after rewrites of real prompts, learn how to size tasks so they actually finish, and leave with a template you can paste into any coding agent.
Why vague tasks fail
When a task has gaps, the agent fills them with guesses. Those guesses are reasonable defaults, the kind of thing that's right for an average project, but they aren't your intentions. Each gap is a small coin flip, and a vague task has many of them.
Take "make the dashboard faster." The agent has to guess which dashboard, what "faster" means (page load? a slow filter? the first query?), whether it may add a caching library, whether it may change the database schema, and when to stop. It might add a dependency, rewrite three queries, and refactor a component, all reasonable in isolation and none of it what you wanted.
The second failure is subtler: without a definition of done, the agent stops when it feels done. It finishes when the code looks plausible, not when the problem is verifiably solved. That's how you get "Fixed!" on a bug that still reproduces.