After Running Five Coding Agents, the Bottleneck Shifts from Writing Code to Acceptance

Addy Osmani recently wrote an article about coding agents. A coding agent is an AI assistant that can read code, modify code, and run commands; tools like Claude Code are typical examples. His judgment is straightforward: if every day you’re picking tasks, writing instructions, delegating, following up, and accepting results, you’re already doing management. Here, management means making other people’s work produce results, regardless of title.

Running more sessions easily creates the illusion that the work has already been handed off. In replies to the tweet, someone noted that after running more agents, the bottleneck moved from writing code to a queue for acceptance. If acceptance criteria aren’t written clearly, the more agents there are, the more rework there is. This observation is closer to daily reality than a list of tool features.

Addy puts self-verification first. Every task should have a runnable check—tests, builds, type checks are all fine, and UI changes can use screenshots. The agent should execute, check, fix failures, and then submit results and evidence. Without verification, the only signal it has is that it looks done. In the tweet replies, someone set a rule for their bot: after clicking a button, it must submit a screenshot proving the page actually changed; reporting only a diff doesn’t count as done.

Task instructions should fill in information the repo doesn’t contain: why it’s being done, what the business constraints are, what not to do, and what counts as success. There’s no need to repeat what can be read in the code. Addy gives an example: change “make the dashboard faster” into more specific instructions: under organizations with 10k+ members, p95 load time should be below 2 seconds; explain that enterprise admins open it every day and slow loading is the largest source of support tickets; constraints are not changing the schema and preserving the API response shape; scope excludes UI changes and full-page caching; the check is to run a specified performance script and provide before/after numbers. It’s the same when making a page for an outside contractor: if you only say “make it faster,” they can only guess.

If the same mistake is corrected twice, it should be written into shared rules or skills. Too many rules will conflict with each other, and old constraints also need to be cleaned up after model upgrades. Ordinary preferences should be written as guidance; security requirements that must be followed should use enforcement mechanisms. Addy’s article mentions that prompts, CLAUDE.md, and skills are requests the model can consider, while hooks, deny rules, and admin settings are requirements that are always enforced. In most cases, let the agent judge for itself; reserve hard limits for things that cannot bend.

The upper limit for parallelism is often human attention. Addy says that most days he runs four or five background agents and a few local sessions, and some days even that feels like too much. Before starting unattended tasks, you need to clarify completion conditions, verification methods, permissions, run limits, deliverables, and approvers. Try new workflows on a small scale first. All tests passing doesn’t mean a feature is worth building; product trade-offs, security boundaries, and release decisions are still the human’s responsibility. Measure delivery cycle time, rework, and rollbacks—don’t just count how much code the agents wrote. In the tweet replies, someone joked that in the past, getting promoted to supervisor came with a raise; now you spin up a few agents and become a manager, but your salary doesn’t go up a cent and you have to pay more subscription fees.

Acceptance evidence needs to be specific. In the tweet replies, someone mentioned that an AI once told them an X post had been scheduled, when it was actually still in drafts. They wanted to see the date and time in the scheduling queue. The words “done” don’t explain anything. Another person said that two agents had different understandings of the completion criteria for the same ticket, so the ticket should be fixed first. This is the same thing Addy talks about with context and acceptance criteria.

Addy also cautions in the article that the management analogy has limits. Managing people is harder; having managed five agents doesn’t mean you can manage five people. Agents don’t have real experience, only notes stored on a machine. They push back less, and people are more likely to overtrust them. Low redo cost is an advantage—you can have them produce two or three options to compare. But things like security, compliance, and product judgment still require a human signature.

The article concludes by saying you don’t have to want to be a manager, but engineers who use agents well will learn to manage. Opening more windows easily creates the illusion that the work has been handed off. The real sign of handoff is when it comes back with results you can verify.

Original links: meng shao's tweet Addy Osmani's article Addy's tweet