The Hidden Cost of AI-Generated Code

There is a comfortable story about AI and software development in which code gets cheaper and everything downstream stays the same. It is half true, and the half that is false is where all the interesting problems live.

Writing a first draft of code did become dramatically cheaper. What nobody accounted for is that the cost did not disappear — it moved to stages that were already fully occupied.

Where the cost went

Review. Someone still has to read the code and decide whether it is correct. That capacity is human, it did not double, and it is now the most common bottleneck in teams that adopted AI assistants early. The symptom is a growing queue of changes waiting for attention, which gets misdiagnosed as people being slow to review rather than as arithmetic.

Testing. Test suites cost the same per run and are now run far more often. Worse, a test that fails intermittently — one run in twenty — is background noise at a dozen changes a day and a daily interruption at forty. Trust in the suite erodes, and once people start ignoring failures on principle, the suite has stopped doing its job.

Building. Continuous integration spend tracks change volume directly. Many teams have watched this become a significant line item without anyone making a decision, because it grew a few percent a month for two years.

Recovering. More changes means more chances that one of them is bad. The machinery for catching and reverting a bad change safely was designed for a lower change rate in most organisations.

Dependencies. This one is specific to generated code. Asked to parse a date, a model will happily reach for a library rather than writing four lines. It has no opinion on whether that library is maintained, whether its licence works for your business, or whether it appeared last week from an account with no history.

Why it is hard to see

Every individual developer genuinely feels faster, and is not mistaken. The slowdown happens between people rather than within them — in queues, in waiting, in reconciliation. There is no single person whose experience contains the problem, which is why it tends to be discovered from a spreadsheet rather than from a complaint.

The other reason is that the standard measurements hide it. Most teams measure how long a change takes from when the ticket was created, which is dominated by prioritisation. That number actually improves slightly when writing code gets faster, so the dashboard reports progress while the thing everyone can feel gets worse.

What actually helps

The mechanical things, first, because they are cheap and quick:

• Run only the tests that a change could affect, rather than the entire suite
• Verify your dependency cache is actually faster than building from cold, which is not always the case
• Revisit machine sizes that were chosen during a debugging session and never touched again
• Turn off development environments outside working hours
• Prune test matrices to the combinations customers actually use

Then the part that people avoid, because it is a decision rather than a configuration: work out how much review capacity you actually have and what you intend to do about the gap. Split large changes automatically, since review effort grows worse than linearly with size. Decide explicitly which categories of change genuinely need two humans. Use model assistance for the mechanical pass — formatting, missing error handling, absent tests — so that human attention goes to design and correctness.

Generated code arriving faster than people can review it is not a tooling problem waiting for a tool. It is a policy question currently being answered by queue length.

Measuring it honestly

Measure from merge to production, not from ticket to production. Count rollbacks as failures even when nobody declared an incident. Track continuous integration cost and duration per change as trends. And split pull request time into two numbers — waiting for first review, and first review to merge — because that split tells you immediately whether your problem is capacity or process.

Longer version with the full argument, engagement models and vendor questions: DevOps Services Company: How to Choose the Right Partner in the AI Era

Frequently Asked Questions

Does this mean AI coding assistants are not worth using?

No. The productivity gain in authoring is real. The point is that capturing it end to end requires investing in the stages that did not get faster, and most organisations have not because the constraint moved somewhere they were not measuring.

What is the single cheapest fix?

Running only the tests a change affects. It reduces cost and duration simultaneously and is usually a week of unglamorous mapping work rather than anything technically difficult.

How do I know if review is my bottleneck?

Measure time from change opened to first review separately from time from first review to merge. If the first dominates, it is capacity. Most teams have never separated these and assume the problem is the build system.

Can AI review the AI-generated code?

For the mechanical pass, usefully so. For design judgement and subtle logic errors, not reliably. Treat it as a filter that reduces what humans must look at, not as a substitute for a human reviewer.

Is dependency drift a real risk or a theoretical one?

Real and growing. Enforce policy at merge time with a clear exception path, generate a software bill of materials on every build, and scan for secrets before the commit lands rather than during an audit.

Should small teams worry about any of this?

The mechanical fixes are worth an afternoon at any size. The structural work — paved paths, platform investment — starts paying off somewhere around fifty engineers, though service count matters more than headcount.