My agents write the code now. So what am I supposed to do?

Manveer Singh — Mon, 12 Oct 2026 16:29:41 +0000

On a normal day I have several agents running at once. One is building a feature. Another is writing its tests. A third is chasing a bug. A fourth is reviewing what the first one wrote.

I am not typing code. Most days now, I barely do. So the question I keep coming back to is simple: while they work, what am I supposed to be doing? This is my working answer. It is not finished, and I would like yours.

Not watching

Watching an agent work feels like work. The terminal scrolls, tests go green. It is the progress bar of 2026.

I suspect it is also more tiring than it looks: it asks for attention without giving you anything to do with it. The Pragmatic Engineer's 2026 survey heard something related: some engineers get more flow from AI tools, others say that starting many more tasks in parallel keeps them context switching and knocks them out of flow.

Agents run in parallel. Attention does not. So I spend it one level up, on three jobs.

1. Feed the queue

A vague ticket gets you confident, plausible, wrong code, fast. So while one batch runs, I write the next task properly. A shape that works for me:

## Task: <one sentence, the user-visible outcome>

Context the agent cannot know:
- why this exists, who asked, what we tried before
- the module that looks wrong but is like that on purpose

Done means:
- <behaviour 1, testable>
- <behaviour 2, testable>
- existing tests still pass; new tests cover both

Edge cases I already expect it to miss:
- <the one from last time>

Out of scope:
- <the tempting refactor next door>

Karpathy's Sequoia talk has a clean example of why the "context" block matters: his agents matched users across Stripe and Google by email address, which works until someone has two emails. Coding skill does not catch that. Product knowledge does. In his words: "You can outsource your thinking, but you can't outsource your understanding."

2. Build the harness

Every correction is a choice: fix this task, or fix every future task. The second means turning the correction into something the next run inherits.

In practice that is three kinds of artefact, in rising order of strength:

Artefact	Example	Strength
A rule in the project instructions	"Never call the payments client outside the service layer."	The agent usually follows it
A test	A test that fails when the rule is broken	The agent cannot call itself done until it passes
A gate in the workflow	The agent stops at "ready for human review" and cannot merge	Holds even when the agent is confidently wrong

A rule is a request. A test is a fact. A gate is a guarantee. When something matters, move it down the table.

What I have not figured out is how to know the harness catches what a careful reviewer would. A green run proves the rules were followed, not that the rules were the right ones.

And one thing no harness holds: accountability. An agent cannot be accountable. A person can, so somewhere in the system there has to be a name, and it is not the agent's.

3. Go to the customer

When building was slow, the build was the constraint. Now a feature can take an afternoon, so the expensive questions are "should we?" and "did it change anything for the person it was built for?"

I have not solved the second one. Shipping on time used to be a reasonable proxy for doing well; it proves very little now. The real signal is whether the customer behaves differently, and that is far harder to observe than a green pipeline.

It changes what is worth building, too. Customers are getting agents of their own. Some will not want to open your app at all; they will want their assistant to do it. An MCP server or a clean API may matter more to them than the next screen.

The small factory

An engineer running agents is running a small factory. You own the input (specs), the line (the harness) and the one question the factory cannot answer: does anyone want what comes out?

We automated the part of the job everyone could see, and kept the part nobody could.

Try it next time you start an agent: before you check on it, write the next task. Before you fix its mistake, ask whether the fix belongs in the harness.