We Handed the Punch List to an Agent. The Hard Part Was the List.

On a Friday morning we handed a coding agent a list of seven items and went to work on other things. By Monday, six branches were merged to main, the database migrations were pushed, and two older branches had been closed without shipping anything. One merge conflict got resolved by hand.

That reads like a post about how fast agents have gotten. It is not. The speed was the least interesting thing that happened.

The list took longer to write than most of the items took to build

The list did not come from a brainstorm. It came out of a review call with the client, followed by a line by line pass through the original agreement and the project board, sorting everything that had been raised into what was already inside the phase we sold and what belonged in a later one. That sorting took real hours and produced a short document. Seven items stayed in. Several larger requests moved out and will be quoted separately.

What made the seven workable was not that they were small. It was that every one of them was already a decision. A checkbox in a settings panel that resets to the default on every visit instead of staying where you set it. A logo that renders on the printed document but not in the settings screen, because two parts of the app were reading the same piece of branding from two different places. A sales representative field that has to exist on every record from the moment it is created, selectable from the team, changeable later. One status list shared across two record types, with each status carrying a won, lost or open category, and every status change written down so that reporting built next year has real history to draw on.

None of those sentences is "clean up that section of the app." Each one has a beginning, an end, and a way to tell whether it is finished. Hand an agent that, and you get exactly that. Hand it "clean up that section of the app" and you get something plausible that misses, and now you have to read all of it to find out how.

This is the part that never shows up in a demo of a coding agent. Output quality tracks input specificity almost linearly, and writing a genuinely unambiguous list is slow human work that mostly consists of making decisions you had been putting off.

The item we kept

One thing on the list never went to the agent. A user could open a record, read it, and not save changes to it, with nothing on screen indicating that anything was wrong. Nobody knew why. The first plausible explanation turned out to be wrong, which is normal and also expensive, because a wrong theory that partly works sends you further in the wrong direction than no theory at all.

A senior engineer took it. Not because the fix was hard to write. The fix was to remove something. Writing the fix was maybe five percent of the work. The other ninety five was forming a theory, reproducing the failure, killing the theory, and forming another one, with a real user waiting on the other end.

That is the split, stated plainly. Hand over the work where the hard thinking is finished. Keep the work where the hard thinking is the work. It has very little to do with how difficult the code is. Some of the delegated items touched more files than the bug did.

The two branches that shipped nothing

In that same stretch, two older open branches were closed without merging. Somebody looked at them and decided the work was no longer needed, either because the requirement had changed or because a different change had made them redundant.

Throwing work away is the least celebrated activity in software and one of the most valuable. It is also the thing an agent will not do for you. Give a coding agent a branch and it will finish the branch. It holds no opinion about whether the thing on the other end is still worth having, whether the client changed their mind three weeks ago, or whether shipping it would create a second way to do something the app already does one way. That opinion is the job. It produced zero lines of code and it was the most valuable call in the batch.

Same story with the merge conflict. Parallel work collides on shared files, and a person who knows which of the two versions is right has to sit down and reconcile them. Same with the order of operations at the end: the database migrations had to land in the right relationship to the code that depends on them, which is a rule we adopted after learning it the hard way on a different build.

The bottleneck moved. It did not disappear.

The conversation about coding agents has quietly shifted. The question used to be whether a model could produce code you would actually ship. The question engineering leaders are working on now is how many agents one person can direct and review at once. Every branch an agent opens is a branch a human has to read. Speeding up the writing step does not remove the reading step. It fills the queue faster.

That is a real argument for a small senior team over a large mixed one. If review is the constraint, you want to be staffed for review: fewer people, more of them able to look at a diff and say what is wrong with it. We are not fast because our agents are better than anyone else's. We are fast because there is a short distance between the person who wrote the list and the person who reads the result, and both of them have shipped software before.

What to ask instead of "do you use AI"

Every shop says yes now, so the question separates nobody. These are better, and you can ask all of them on a first call.

• What do you hand an agent, and what stays with a person?
• Who writes the list it works from, and when do I get to see that list?
• Who decides that something does not ship?
• What happens when two changes collide?
• Whose name is on what went to production?

The answers will tell you more than any tooling slide. A shop that can describe its split has thought about it. A shop that says it uses AI to move faster has told you nothing, and has probably not decided who is accountable when the fast thing is also the wrong thing.

The delivery speed you get out of an AI accelerated team is not really a property of the model. It is a property of how much of the work is already well defined, and how much review capacity sits behind it. Which means the founders who get the most out of a team like ours are the ones who can say precisely what done looks like for the next thing. That has not gotten easier. It has only gotten more valuable.