The junior's pull request appeared fantastic. They had made clean commits, maintained a tidy structure, and all the tests were passing. But after starting to read it, I couldn't put it down for three hours as I rewrote almost the entire thing in my mind.
The productivity lie
We keep saying AI made everyone faster. What it actually did was move the hard part somewhere else. Writing bad code used to be slow. The code now comes quickly, comes confidently, and is wrong more often than it is right. The slowness has not disappeared, it has just moved to my email inbox. As Porter, an expert quoted in a 2026 CIO.com report, noted: "If there's a bottleneck in the process, it becomes less about writing the code and more about checking the code that's been written."
The numbers are brutal
It's not just old people complaining. The data supports it. In July 2025, Faros AI monitored more than 10,000 developers on 1,255 teams. Individual output jumped hard: 98% more PRs, 154% larger PR sizes. It seems like a success. However, the time it takes to conduct reviews increased by 91%. Having to write more code, more complex code that requires double the time for testing, is not a productivity improvement. It simply shifts the cost with a nice image. Uplevel Data Labs actually analyzed nearly 800 engineers using Copilot in September 2024. Found no significant change in PR cycle time or throughput. But 41% more bugs were shipped into the repos. š¬
Why it's worse than junior code
A junior who writes something wrong typically writes it in a timid fashion. The uncertainty is palpable. AI produces inaccurate information with great confidence. A study conducted at Purdue University in August 2023 examined the responses provided by ChatGPT to 517 technical questions from Stack Overflow. 52% were factually incorrect. What's even more frightening is that 39.34% of the time, people chose AI answers because they were more confident, believing they were more likely to be correct, and didn't notice the errors unless they actually copied the code and tested it in an IDE. So now I have to test everything by myself. It's almost the same amount of work as writing the code. Lisle, a software engineering leader, also captured that dynamic well in the same CIO.com piece: AI is, he said, "like having a junior developer who can write a very large amount of code very quickly... it doesn't understand the code and the broader context. It often does the opposite of what you ask it to do."
The trust gap nobody wants to admit
A Sonar survey from January 2026 polled 1,100 IT professionals and found that 96% said they do not have complete trust in code produced by artificial intelligence. Almost 40% of the respondents indicated that it requires higher effort to review AI code compared to that of their human colleague. Think about it for a moment. The tool that was intended to save time for reviewers has actually resulted in increased costs in terms of reviewer time. Additionally, technical debt has been accumulating directly within the codebase. GitClear analyzed hundreds of millions of lines. Code churn more than doubled from a pre-AI baseline of 3.3% to a projected 7.1% in 2025. API evangelist Kin Lane put it in simpler terms saying "I don't think I have ever seen so much technical debt being created in such a short period of time during my 35-year career in technology."
What I actually think
The bickering between generations about who is more adaptable, veterans or juniors, is misguided. The underlying change is about determining who bears the cost of being overly confident and incorrect. Here's what I can't stop thinking about:
ā AI didn't make juniors productive. It made their output harder to verify. ā Volume went up. Trust went down. Someone has to reconcile that, and it's the reviewer. ā "Faster to write" and "faster to ship" are not the same sentence. I don't oppose AI. In our small group, it is very helpful for the mundane tasks. I used to act like a PR full of generated code was almost done. That's the easy part. The real productivity hack is that we simply shifted the workload to the one person who couldn't turn it down. So, let me ask you. When you are going through the code that is generated by AI and that has been written by a colleague of yours, are you reviewing the code or making silent modifications to it? If the latter is the case, then who can be considered as the real author of that code?
Top comments (1)
Exactly the conclusion I came to. AI is a senior dev's tool, not a junior's. Because a senior knows code review, they can self-correct as they develop with AI, vs a junior trusts too much and reviews too little... When the junior is asked about their implementation, they ask AI, they dont answer from memory. That's why you cant even ask the source, because the source was Claude, by proxy... That proxy wall is what prevents you from truly diagnosing it, all you see is green test passes and UI that looks fine, but you need to manually go and click everywhere.
That's the dynamic shift I think we're heading towards. Seniors can write code with AI 10x faster, while maintaining a higher degree of accuracy. Juniors are getting cut out of the job, when they should actually have been shifted into the QA role for Seniors' work. That way a senior can push out 10x the work and 10 juniors can click through it and flag anything not quite right, maybe run Claude to just give an implementation plan to fix it and explain the findings. That way QA grows along with the code generation, while AI is used sparingly and in qualified hands.
Result is cleaner code in every PR and a thorough review stage that teaches juniors how to do the job of 2030, reviewing AI compiled code and seeing where it breaks while looking fine.