"Fix the build" is not a task: how to hand work to a coding agent
On this page
You type "fix the build" into a coding agent and go to make tea. When you come back, the build passes. The agent got there by deleting the failing test.
Technically, that's a fix. It's also a good reminder that a coding agent does what you asked, not what you meant. The more independently it works, the more that gap matters.
Three ways to work with an agent
AI coding help has moved from suggesting the next line to doing several steps of work by itself. Each step along that path changes how much structure the task needs.
| Pattern | What it does | Who steers | Structure needed |
|---|---|---|---|
| Autocomplete | Suggests small completions as you type. | You, keystroke by keystroke. | Very little. You see every suggestion. |
| Pair programming | Explains code, debugs, drafts tests and compares options with you. | You, turn by turn. | Enough context for a useful conversation. |
| Delegation | Works towards a goal over several steps and returns a result. | The brief you wrote before you left. | A clear goal, boundaries, validation and a reviewer. |
Autocomplete can stay lightweight because you are watching. Delegation is different. You are not there to notice when the agent decides that the quickest route to a green build goes through your test suite.
There are two more patterns worth naming. A review checkpoint is where the agent prepares evidence, such as a pull-request summary or investigation notes, and a human makes the decision. A human-led workflow is the right choice for production approvals, ambiguous requirements and work nobody clearly owns. Keeping a workflow human-led isn't a failure. It shouldn't become permanent if the workflow can be made clearer.
The five-point readiness check
Before you delegate, check that the task is:
- Clear. You can state the goal in one plain sentence.
- Bounded. The scope has edges: these files, this service, this failure.
- Context-supported. The agent has the logs, tickets, files or docs it needs.
- Verifiable. Someone can check whether the result is correct.
- Reviewable. A human can accept, revise or reject the output.
If a task fails any of these, delegating it won't save you time. You will spend the saving reconstructing what the agent did.
Before and after: a real one
Here's a weak brief I actually wrote. In September I was working with a coding agent on schoolCRM, my school operations platform: a Go API, an Angular admin portal and PostgreSQL. The agent had just got the Go integration tests running locally, and it reported one failure: Test_Home/create-401-wronguser expected a 401 but received a 403.
I replied:
fix it
Two words, with a real question hiding in them: is the test wrong, or the API? To its credit, the agent asked that question itself. Its plan was to "determine whether the test or API contract is wrong", then make "the smallest behavioral fix". It also set its own finish line. It would stop "once the failing assertion passes".
That finish line is the problem. Here's what it did:
- It found that the API returns 403 when a signed-in user tries to create a record they aren't allowed to create. That's correct. A 401 means "who are you?" A 403 means "I know who you are, and no."
- It changed three create tests to expect 403.
- The commit hook then failed on Staticcheck warnings in unrelated code, so it narrowed the hook to check only the Go packages that had changed.
- It committed and pushed everything as
fix: scope Go hook checks to changed packages.
The assertion passes. But the same wrong-user request on the update and delete routes still returns 401, because their middleware hard-codes it. The agent noticed this and reported that those cases "remain 401". The tests now describe an inconsistent API instead of flagging it.
Nothing the agent did was reckless. It did exactly what "fix it" allowed. Here's the brief I should have written:
Test_Home/create-401-wronguserexpects 401, but the API returns 403. Decide which status is correct for a signed-in user who lacks permission, and check whether the update and delete routes agree. List the files you inspected. Change test expectations only if the API behaviour is correct. Don't change the Git hooks. If the routes disagree, stop and report before you edit anything.
The second version is longer, but every extra sentence does a job:
- Goal: decide the correct status, not just turn the test green.
- Context: the failing test and the two status codes.
- Boundary: test expectations only, and no hook changes.
- Output: the files inspected and a verdict for each route.
- Review: a stop point if the routes disagree.
That's the whole delegation brief. It takes a minute to write. The inconsistency it would have caught stayed in the codebase until November.
Pick the pattern from the work
It's tempting to use the most autonomous mode for everything because it's the most impressive. Choose the pattern from the condition of the work instead:
| If the work… | Use |
|---|---|
| Needs you to explore, learn or steer continuously | Pair programming |
| Passes the five-point check | Delegation |
| Supports a human decision but shouldn't make it | A review checkpoint |
| Includes a production approval or high-risk judgement | A human-led workflow |
| Is broad, vague or missing context | Improve the task first |
The last row matters most. "Clean up the service" or "improve this module" can touch public behaviour, dependencies and design choices. Those requests aren't ready for any agent. They aren't ready for a new colleague either.
What stays with you
An agent can explain code, draft changes, scaffold tests, summarise logs and write investigation notes. These decisions stay with a person:
- design and architecture direction
- whether a change is good enough to merge
- the root cause behind an incident
- whether test coverage is acceptable
- whether something is ready to release
A useful rule of thumb: delegate bounded work, and keep judgement, approval and accountability with a person.
The next time you're about to type "fix the build", write the brief a new colleague would need instead. If they could finish the task from it without deleting anything you'd miss, so can the agent.