What agent coding actually changes about a codebase

The common claim about coding agents is that they write more code faster. That is true and it is the least interesting thing about them.

The change that actually reorganises how a team works is smaller and stranger: some instructions can now be acted on without a person reading them first. Not all. Some. And the line between the two is not where people expect.

Two kinds of task, and they were always different

"Make the header better" and "the header overlaps the hero below 380px — fix it without changing the spacing above 640px" are both tasks. They have always been different kinds of thing, and every team has quietly known this.

The first carries judgement. Somebody has to decide what better means, and that decision is the work. The second carries an instruction precise enough to act on, and — this is the part that matters — a way to tell whether it worked.

Before agents, the distinction was informal. Both went in the same tracker, and a human read each one and supplied whatever precision was missing. That human was doing invisible translation work, constantly, for free.

Agents make the distinction load-bearing. An agent given the first task will do *something*, and the something will be plausible, and you will not know whether it was right until you look. An agent given the second either satisfies the condition or does not.

So we split the list

We keep two: tasks for people and tasks for agents. Not two priorities on one list — two lists.

The agent list has a hard requirement: every item states what to change and how to know it worked. If you cannot write the second half, it does not go on that list. It goes on the human list, where the first job is to work out what the actual condition is.

This sounds like bureaucracy. In practice it is the opposite: it makes the agent list runnable without a human triaging each line, and it stops the human list being padded with things nobody ever intended a person to do.

The traffic between them goes both ways

Things move. Something you filed as needing judgement often turns out to be specifiable once you have looked at it for five minutes — and that five minutes of looking *is* the human work. The output of thinking about a fuzzy task is frequently a precise one.

Going the other way: an agent task that keeps failing is usually not a bad agent. It is a task whose success condition was wrong, which means the person who wrote it had not finished thinking.

What this does not solve

Agents are good at work with a checkable end state and bad at work whose difficulty is deciding what the end state should be. Almost everything genuinely hard about software is the second kind.

We have not found that changing. What changed is that the first kind stopped consuming the attention of people who should be doing the second kind — and the way you capture that is by being explicit about which is which, in the tracker, where the work actually lives.

The uncomfortable part

Writing a good agent task is harder than doing a small change yourself. For anything trivial, you should just do it.

The return arrives when the same class of task recurs, when it needs doing across forty files, or when the checkable condition is something you wanted written down anyway. That last one is underrated: a precisely specified task is a test that has not been written yet.