Giving an agent a task it can actually finish

Compare two instructions:

• "Look at checkout.py"
• "Fix the bug where checkout.py charges tax twice when a coupon is applied — add a regression test"

The first tells the agent where to look but not what success looks like. The second gives it a concrete goal and a way to verify it (the test). An agent can plan against the second; the first leaves it guessing what you actually wanted changed, if anything.

The clearest tasks name how you (or the agent) will know the work is done: "the test suite passes," "the new endpoint returns a 200 with the expected JSON shape," "the function handles an empty list without raising." This isn't extra formality — it's what lets the agent check its own work in the loop from the previous page, instead of stopping after the first edit that merely looks reasonable.

If there are things the agent shouldn't touch — a file that's intentionally untyped, a dependency you don't want added, a pattern the rest of the codebase avoids — say so up front. "Don't add new dependencies" or "keep this backward compatible with the v1 API" prevents a technically-correct-but-unwanted solution. Agents follow the instructions they're given; they don't know your unwritten team conventions unless something tells them.

Repeating the same constraints in every single task gets old fast, and most agentic tools support a project-level rules file (commonly AGENTS.md, or a tool-specific equivalent) that's automatically included as context for every task in that repository. This is the place for standing instructions: "use pnpm, not npm," "tests live next to the file they test," "never edit files under generated/," "prefer editing existing files over creating new ones." Writing a good rules file once pays off on every task afterward — it's the agentic-coding equivalent of a style guide the agent actually reads.

Very large, multi-part asks ("redesign the auth system") force the agent to make many unstated judgment calls, which is exactly where plans drift from what you meant. Breaking a big goal into a few concrete, checkable steps — even if you hand them over one after another in the same session — keeps you able to review each step's diff before the next one builds on it. This mirrors ordinary engineering practice: small, reviewable changes beat one enormous one, whether a human or an agent is writing them.

If you want a new API endpoint to follow the exact same pattern as three existing ones, say so and point at one: "follow the same structure as routes/users.py." Agents are very good at pattern-matching from a concrete example in front of them — much better than inferring an unstated convention from scratch.

1. Goal — one sentence, concrete and checkable
2. Where — the file(s) or area involved, if known
3. Constraints — anything it must not do or must preserve
4. Verification — how you'll both know it worked (a test, a manual check, an expected output)

Not every task needs all four written out, but when an agent goes sideways, it's almost always because one of these was missing or implicit.