Ninety Percent of the Problems Are AI-Generated

A CTO I work with has done something unusual. For eight months he has reviewed every commit that passes through the team's CI/CD pipeline. Every pull request. Every code change. Not spot checks — everything.

His conclusion: ninety percent of the problematic code is AI-generated.

Not ninety percent of all code. Ninety percent of the problems.

What Nobody Wants to Hear

This is what makes the finding uncomfortable: the tools work. They do exactly what they are supposed to. They generate code quickly, in large volumes, with high syntactic quality. The code compiles. It passes basic tests. It looks professional.

And it creates technical debt at a rate no manual developer could have achieved.

This is not an argument against AI. It is an argument for stopping the practice of treating AI-generated code as if it were free.

The Multiplier Cuts Both Ways

I have written before about how AI amplifies what you already know. That a senior developer with the right tools becomes extraordinary. That is true. But what I did not emphasize enough was the other side.

A developer who does not understand the task, who cannot interpret requirements, who does not see architectural consequences — that person did not get better from AI. That person became more dangerous.

Before, that developer produced mediocre code slowly. Now the same person produces mediocre code at a rate that floods the system. More files, more modules, more dependencies — everything generated, nothing reviewed, all of it technical debt.

The CTO put it this way: "The ones who can express themselves clearly and understand the task get good results. The ones who can't create bigger problems with AI than without it."

That is what is missing from the industry narrative. AI does not make everyone better. AI makes everyone faster. And faster in the wrong direction is worse than slow in the right direction.

Technical Debt, 2026 Edition

Technical debt is nothing new. Every development team lives with it. But the 2026 version looks different.

Traditional technical debt accumulates gradually: shortcuts under time pressure, half-finished solutions that become permanent, documentation that never gets written. You can see it coming. You can manage it.

AI-generated technical debt arrives immediately and at volume. A junior developer who asks an LLM to generate an entire module in one afternoon creates more technical debt than the same developer would have produced manually in a month. The code looks clean. It follows conventions. But the assumptions are wrong, edge cases are missing, and the architecture does not fit the rest of the system.

And the worst part: it does not show up in a surface-level review. The code looks professional. You have to understand the system to see that it is wrong. And if you understand the system well enough to see it — then you would not have needed AI to write it in the first place.

The Guidelines Nobody Followed

The CTO had done his part. He had created a development skills package. Architecture standards. Defined application layers. Use case templates with actors, flows, business rules. Everything documented, everything distributed to the team.

Almost nobody followed them.

Not because they were poor. Not because they were unclear. He does not know why — because the feedback never came. Nobody said it was difficult. Nobody said it was not working. Nobody said anything at all.

That is the quiet disaster. You build the structure. You share it. You wait for it to be adopted. And you discover eight months later, by reviewing every line of code, that it was never used.

Without a feedback loop there is no adoption. Without adoption there is no structure. Without structure there is technical debt.

What the Numbers Actually Say

Ninety percent of the problems are AI-generated. That says three things:

It says the tool is neutral. AI generates exactly what you ask for. If you ask for the right things with the right context and the right understanding you get extraordinary results. If you do not, you get extraordinary problems.

It says review is not optional. The CTO found the problems because he read every line. In a team without that review the same code would have passed unnoticed. The checkpoint is not a step in the process — it IS the process.

It says training is not about the tools. Nobody on the team needed to learn more about AI. They needed to learn more about how to express a task, follow an architecture, and validate a result. That is not AI training — it is professional development that happens to involve AI.

The Year We Stop Pretending

2024 was the year everyone started using AI. 2025 was the year everyone talked about productivity gains. 2026 should be the year we stop pretending AI only creates value.

It creates value — enormous value — in the right hands. But in the wrong hands it creates technical debt faster, more elegantly, and harder to detect than anything we have seen before.

Ninety percent of the problems are AI-generated. That is not an accusation against the tools. It is a reminder that the tools are only as good as the person using them.

You still own every line.

In series 6 I wrote that you cannot validate what you do not understand. This is the proof: a CTO measured it.

See also: The Checkpoint Is the Job (series 11) and AI Forces You to Think Harder (series 12).

Mindtastic on why domain knowledge multiplies AI output — Domain knowledge multiplies AI output.