AI Coding Agents Produce More Code, Not Always

AI coding agents are generating more code, while developers still have to review, integrate and maintain what they produce. That leaves companies with an awkward measurement problem: a tool can make the repository look busier before anyone knows whether users got working software.

The rise in code output has an obvious appeal. If an agent can take a request, inspect a codebase and draft a patch, a developer gets a head start. Give that agent a longer sequence of tasks, and it may handle work that previously required several rounds of typing and searching. But each extra patch also enters a system with requirements, existing dependencies, tests and people who will inherit the result. Shipping is where the speed claim has to cash out.

A Patch Has a Long Way to Go

Consider a hypothetical request to add a setting that lets users turn off a notification. An agent could create the interface, update an API and write a test. The code might compile and still miss the user's actual problem: perhaps the setting needs to apply across devices, or the notification comes from a second service the agent never touched. A reviewer has to catch the gap, clarify the requirement and decide how the change fits the rest of the product.

That example isn't an argument against generating the first draft. A useful draft can save time. It shows why counting drafts gives an incomplete picture of the work. A commit records a change to a repository; a dependable feature has to survive use outside the circumstances its author anticipated. Tests can catch specified failures. They cannot supply a missing requirement that nobody articulated.

Earlier development tools, from code completion to low-code platforms, also reduced the effort of producing code. Agents extend that bargain by taking on longer chains of work. That creates more room for useful automation, especially when a task is well defined and its result is easy to check. It also gives a mistaken assumption more opportunities to spread before a person sees the finished patch.

The strongest case for agents is practical. A developer who spends less time on a routine change can spend more time investigating a user problem, reviewing a risky integration or designing the next feature. Teams with strong tests and clear constraints may be able to put generated work through a reliable checking process. The gain would show up as shorter delivery times for software that meets the same quality bar, with less total effort across the team. That is a much stronger claim than a higher commit count.

The Review Queue is Part of the Bill

Code review is often treated as the final checkpoint after the productive work. With agents, it can become the scarce resource. If one person can generate several plausible patches in the time it once took to write one, someone still needs to understand what each patch changes and why. Approval without that understanding turns review into a button; careful review takes time that belongs in any productivity calculation.

The burden depends on the work. A contained edit with clear tests may be quick to verify. A change that crosses services, touches old assumptions or alters what users see asks much more of a reviewer. Teams could therefore report faster code generation and slower delivery at the same time, without either observation being wrong. Work has moved from drafting into checking, debugging or integration.

Dexter Horthy's automated software factory corrupted his codebase, a concrete illustration of the risk when generated changes outrun human oversight. One case cannot predict what will happen in every team. It does make a useful question hard to dodge: who is responsible for noticing when an agent's locally plausible work damages the larger system?

The same concern about software quality applies to "superhuman" AI coding. Faster production can leave teams with more code to understand and maintain. Whether that cost outweighs the saved drafting time will depend on the task, the safeguards and how much rework appears later. A patch that gets merged today can create a bill that arrives months from now.

What a Useful Scoreboard Would Count

A team evaluating coding agents needs to follow work past the merge button. Time from request to a feature users can actually use is one measure. Review time, failed tests, defects found after release and time spent correcting or maintaining a change belong beside it. So does the total human effort involved, including work by people who didn't prompt the agent.

Those numbers need context. A team tackling harder features might see more defects even while improving its process. A shorter review time could reflect clearer patches, or reviewers paying less attention. Counting the number of accepted agent patches has a similar problem: acceptance says a change crossed a threshold, not whether it solved the right problem. Comparing similar types of work over time, and checking quality after release, would give managers a better basis for judging a tool than repository activity alone.

This is the organizational version of the AI productivity question. When one task gets faster, a company benefits only if the rest of the workflow can absorb the output without an equal or larger increase in effort elsewhere. For software, that workflow includes product decisions, security checks, testing, deployment and support. Optimizing the most visible step can make a dashboard prettier while the queue at the next step grows.

The people using the software belong in that assessment too. A feature that ships quickly but behaves inconsistently still asks users to spend time figuring it out or working around it. Product teams have to decide which requests deserve to become code in the first place. An agent can help implement an answer; it cannot settle competing user needs simply by producing a polished patch.

Speed Needs a Destination

Teams can make an agent's work easier to judge by defining the task and its boundaries before generation begins. Clear requirements, constraints and testing frameworks give reviewers something to check against. The need for structure becomes more pressing as agents take on longer tasks: an ambiguous instruction at the start can shape every change that follows.

That structure has a cost of its own. Someone must write the requirements, keep tests relevant and update constraints as the product changes. For straightforward, repeated work, the preparation may pay for itself many times over. For a one-off request whose purpose is still being debated, generating implementation options could be quick while deciding what to build remains the longest job.

None of this requires treating agents as either a software factory or a liability. Their value will vary across tasks and teams. A good evaluation asks where they save time, where they shift it and who carries the maintenance burden after a patch ships. If a repository fills up faster next quarter, the useful question is what reached users, how well it worked and what it took to keep working.