I use AI assistants almost every day now. They save me time. I am not going to pretend they do not. But something happened in the last year that worries me, and a report from January put numbers on it.
GitClear analyzed millions of lines of code and published their findings early this year. The short version: code churn is going up. Churn means code that gets written and then changed or deleted very soon after, usually within two weeks. They also found more copy paste style code and less refactoring. Code that gets moved and reused in a clean way is going down. Code that gets duplicated is going up.
This matches what I see in real pull requests. AI assistants are very good at producing code that looks done. It compiles. It has nice variable names. It even has comments. And that is exactly the problem. Code that looks done gets a softer review. The reviewer relaxes. The eyes slide over it.
The review muscle got weaker at the worst moment
Here is the trap. Before AI assistants, when a junior developer wrote 300 lines, you knew a human struggled with every line. The struggle left fingerprints. Weird names, strange structure, places where you could feel the confusion. Those fingerprints told the reviewer where to look.
AI code has no fingerprints. It is smooth everywhere. The bug, when there is one, is wearing a nice suit. It does not look like a bug. It looks like the rest of the code.
So my position is simple. If your team adopted AI assistants and kept the same review process, your review process is now weaker. Not because the process changed, but because the input changed. More code is flowing through, and the code hides its problems better.
Linus Torvalds has this brutal honesty about code quality that I always respected. He does not care how the code was produced or who feels good about it. He cares if it is correct and if it will be maintainable in five years. We need a little of that energy right now. It does not matter that the AI wrote it in four seconds. If it is wrong, it is wrong. “But AI suggested it” is not a defense in a postmortem.
The business math nobody does
I care about this because of money, not because of code beauty. Over the years I learned that nobody pays for beautiful code. People pay for working software. And here is the math that gets skipped.
A bug shipped fast is still a bug. The speed of writing it does not reduce the cost of supporting it. Every bug that reaches production becomes support tickets, and support tickets cost real payroll. Someone in support triages it. Someone in engineering gets interrupted, context switches, investigates, fixes, deploys, and writes the incident note. A bug that took 10 saved minutes to write can easily burn 10 engineering hours downstream, plus the trust of the customer who hit it.
When I ran my own agency in Brazil for eleven years, this lesson was painful and direct. We were small. When we shipped a bug, the client called my phone. There was no layer between the mistake and the cost. I could see exactly how a sloppy Friday deploy turned into a lost weekend and sometimes a lost contract. Big companies have more layers, so the cost is hidden in dashboards, but it is the same cost.
What I think teams should actually do
Not abandon AI tools. That ship sailed, and honestly the productivity is real for boilerplate, tests scaffolding, and exploration. What I push for on my team is adapting the review process to the new reality.
A few concrete things that work for us:
- Treat AI generated code with the same suspicion you treat code from a brand new hire. Competent looking, unproven.
- Ask the author to explain the code in the PR description. If they cannot explain it, they should not merge it. This one rule catches a lot.
- Watch churn on your own repos. If code is getting rewritten two weeks after merge, your reviews are approving things too easily.
- Be extra careful with duplicated logic. AI loves to generate a fresh copy instead of pointing you to the existing function. Five copies of the same logic means five places to fix the next bug.
Martin Fowler makes the case in Is High Quality Software Worth the Cost? that the real cost of software is in the changing, not the writing. AI made the writing almost free. That means the changing is now an even bigger share of the total cost. Logical conclusion: review and design matter more today, not less.
The irony is fun if you think about it. The tool that writes code fast makes the slow human review more valuable, because the review is now the only step where someone is actually thinking about whether this code should exist at all.
I tell my team this: the AI is a very fast typist with no skin in the game. It will not be on call when this breaks. You will. Review like the pager is yours, because it is.
Speed is great. Speed in the wrong direction is just getting lost faster.
Pax et bonum.