Start With A Finish Line
A chat prompt can be loose because the model only has to answer. A coding agent needs a finish line because it can act: read files, edit code, run commands, open tools, and sometimes hand pieces of work to sub-agents. If your request is vague, the agent does not merely give a vague answer. It may spend time exploring the wrong files, make edits you did not want, or loop on a test it cannot fix.
An agent-ready task begins with the outcome, not the activity. Instead of “clean up the auth flow,” say “make password reset return the same generic message whether the email exists or not, update the existing tests, and do not change login behavior.” That gives the agent a result it can compare against the code. You are not writing a perfect spec. You are giving enough shape that the agent can decide what work belongs inside the task and what does not.
This matters because agents operate inside a context window, the set of instructions, files, logs, and conversation they can currently see. Context is limited. If you make the agent infer the goal, constraints, and success criteria from scattered hints, you spend that context on confusion. A strong request preserves context for the actual work.
Name The Boundaries
Once the finish line is clear, add the boundaries that protect the rest of the project. Tell the agent which files, modules, commands, or product areas are likely involved. Also say what is out of scope. A useful boundary sounds like: “Start in `src/billing/` and `tests/billing/`. Do not modify database migrations. If a migration seems necessary, stop and explain why.”
This is not micromanagement. It is process design. A human teammate knows when a change has crossed into payments, security, or release infrastructure because they understand the organization around the code. A first-time agent does not have that judgment unless you give it rules. “Never edit generated files,” “ask before touching production config,” and “do not change public API names” are examples of decision rights, not mere preferences.
Boundaries are especially important when using tools. A tool is any capability outside text generation: file search, a shell command, a test runner, a browser, a database inspector, or an MCP server. MCP, or Model Context Protocol, is a way to connect agents to external systems through standardized tools. More tools make an agent more capable, but they also increase the ways it can do the wrong thing confidently. Good boundaries turn tool access into leverage instead of risk.
Ask For A Plan The Agent Can Verify
After the goal and boundaries, require a verification method. Agents are strongest when the task can be checked by something more concrete than taste. Ask for the exact tests, commands, logs, screenshots, or manual checks that should prove the work. If you do not know the right command, say: “Find the relevant verification command and run it. If none exists, explain the smallest check you performed.”
A good request might include: “Before editing, inspect the related tests and tell me the plan. After editing, run the narrow test file first, then the full package test if the narrow test passes.” This creates a loop: inspect, plan, change, verify. It also gives the agent permission to spend time understanding the harness around the model. The harness is the environment that makes the agent effective: repo structure, tests, scripts, project rules, and repeatable workflows.
Some tasks cannot be fully verified by automation. UI polish, naming, tone, product judgment, and “does this feel right?” are taste-heavy. For those, do not ask for full automation. Ask the agent to prepare options, make a small change, or produce a comparison for human review. The failure mode is operational debt: lots of plausible agent output that passes syntax checks but does not match the product.
Use Sub-Agents For Parallel Work, Not Shared Confusion
When a task has independent parts, ask the agent to launch sub-agents. A sub-agent is a separate worker with its own context, usually given a narrower assignment. This is useful for parallel code review, comparing implementation approaches, scanning separate modules, or having one agent write while another critiques. Because each sub-agent is less anchored by the main chat, it may notice different risks.
Sub-agents need tighter instructions than the main agent, not looser ones. Give each one a role, input, output, and stop condition. For example: “Launch three sub-agents: one inspect tests for existing patterns, one inspect the API layer for side effects, one inspect docs for behavior promises. Each should report findings only, with file references, and make no edits.” That prevents three workers from trampling the same area or duplicating effort.
Parallel work costs more tokens, but token thrift is not the same as engineering efficiency. Spending more can be rational if it produces useful completed work, especially on independent investigations. The waste pattern is different: agents repeating the same search, debating ambiguous goals, or generating competing edits without a merge plan. Concurrency works when the work units are separable and the reports can be reconciled.
Tell It When To Stop
The last part of an agent-ready task is the stopping rule. Agents are often trained to be helpful, which can turn into guessing. Say when it should ask you, skip something, retry, or stop. Useful rules include: “If tests fail for unrelated reasons, report the failure and do not fix unrelated code,” “retry a flaky command once,” “if the change requires a schema migration, stop,” and “if you cannot identify the relevant owner file in 10 minutes, ask me for direction.”
Stopping rules matter most for long-running or unattended work. If you want the agent to work while you are away, write exception handling as if you were delegating to a junior developer: what to do when assets are missing, tests fail, commands hang, dependencies are absent, or requirements conflict. The more autonomy you want, the more explicit the fallback rules must be.
The central habit is simple: do not ask an agent to “work on” something. Ask it to finish a bounded job. State the goal, name the files and constraints, define verification, decide what belongs to humans, and give stop conditions. That turns a coding agent from a chat box with shell access into a worker operating inside a process you control.
Key takeaways
- State the desired end state before naming tasks or tools.
- Give file, module, and safety boundaries so the agent knows what not to touch.
- Require verification through tests, commands, logs, screenshots, or a clear manual check.
- Use sub-agents only for separable work with distinct roles and outputs.
- Add stop conditions for uncertainty, risky changes, failing tests, and missing context.
- Keep subjective product judgment as a human validation zone unless you can define a concrete check.