I was talking to a CTO recently who told me he had banned AI code generation on his team. His reasoning was simple. He did not trust the output. He said the code was sloppy and he could not afford to let it into production.

I asked him how he caught sloppy human code. He paused. He said they had code review. I asked him if it worked. He paused again.

The answer was no. It did not work. It never worked. The team had been shipping sloppy human code for years. The AI ban was not about quality. It was about comfort. He was comfortable with human slop because he was used to it. AI slop was new and therefore unacceptable.

The nostalgia bias

There is a belief that human code is good and AI code is bad. That before AI, we were all writing clean, well-structured, tested software. That the slop problem is an AI problem.

This is not true. It is not even close to true. We call it legacy for a reason.

I have spent over 24 years reading other people’s code. I have seen things that would make most developers quit. The backdoor web page with a textarea and a submit button that ran shell commands on the server. That pattern is way more common than you think.

The same pattern exists with SQL. A web page with a textarea that ran arbitrary SQL against a production database. Built by a developer who was tired of waiting for the DBA team. Used by everyone who knew about it and were proud of this backdoor.

How about the Java method that was over 1500 lines of if-else statements. The author had added a comment at the top that said “Do not touch this method“. It was the main entry point for an ERP SaaS product in an industry that you would think has more regulation that it really does.

Then we have the same utility function reimplemented in six different files across the same repository. Each implementation was slightly different. Each one had a subtle bug. The total time spent writing them was probably two hours. The total time spent debugging the differences was probably two weeks.

That is human slop. That is what we produced when the bottleneck was typing speed and we had all the time in the world. None of this was written by AI. All of it was reviewed by humans. All of it shipped.

What changed is not the quality of the output. What has changed is the speed at which we see it.

The review pipeline is the bottleneck

If your team cannot catch bad code in review, the author does not matter. You could have a team of the best engineers in the world or a team of AI agents. The result is the same. Bad code makes it through because the pipeline is not designed to stop it.

I have seen the numbers. The average code review catches somewhere between 30 and 50 percent of defects. The rest make it through. They make it through because reviewers are tired. Because they are in back-to-back meetings. Because they trust the author. Because the diff is too large. Because the deadline is tomorrow.

The chat about AI code quality is a distraction from this reality. Your pipeline was already leaking. AI just made the leak bigger.

I have seen teams with four-stage review processes that still shipped the same bugs. The process was there. The artifacts were there. The sign-offs were there. None of it mattered because the review was a formality. Everyone clicked approve because that was the culture. The process was theater.

The thing we all lie about

Here is the part that gets me. Every engineering team I have ever worked with talks about code quality. They have standards. They have review processes. They have testing requirements. They have documentation guidelines.

Almost none of them actually follow through.

The README that was last updated when the repo was created. The test suite that covers three percent of the codebase that the team calls covered. The code review that was a rubber stamp because the reviewer was in back-to-back meetings and just wanted to move on.

Teams that require 80% test coverage and then count empty test files as coverage. Teams that require two approvals on every pull request and then approve each other’s changes without reading them. Teams that have a documentation standard and then accept a one-line comment as documentation.

We all lie about this. Not maliciously. We genuinely believe we are doing better than we are. The gap between what we claim and what we deliver is wider than most people want to admit.

AI can actually help with this. It can generate the tests we never wrote. It can document the code we never documented. It can close the gap between what we say we do and what we actually do. But that requires admitting there is a gap in the first place.

The real question

The argument about whether AI code is good or bad is a distraction. It is the wrong question. The right question is whether your engineering system can handle the throughput.

If your team cannot catch a backdoor textarea in a code review, it does not matter who wrote it. If your test suite cannot detect a regression, it does not matter whether the code came from a human or a model. If your deployment pipeline ships whatever lands on main, the source of the code is irrelevant.

AI did not create the slop problem. It just made it impossible to ignore.

The teams that will win are not the ones with the best prompts. They are the ones with the discipline to handle higher throughput. Better review. Better tests. Better scaffolding. The same stuff that always mattered, but now it matters more because the pipeline is moving faster.

What to do about it

Stop looking at the author. Look at the code.

If you review a pull request and you cannot tell whether it was written by a human or an AI, you are doing it right. If you are more lenient on human mistakes because you understand the context, you are doing it wrong. The context does not matter. The code does.

Judge the output. Not the source. Not the excuses. Not the good intentions. The code.

If this is you, stop it. Your team is shipping bad code because you are too busy feeling sorry for the person who wrote it.

AI does not need your sympathy. It needs your standards. And so does your team.

AI Disclaimer: Gemini Nano Banana Pro was used to generate the photo – Monty Python Holy Grail (1975)