A senior engineer I respect recently told me he was leaving his job. Not for more money. Not for a better title. He was leaving because every pull request he reviewed had become a fight against AI-generated code that looked perfect on the surface and was architecturally incoherent underneath.
He's not alone. The conversation about AI-generated code quality has shifted hard in 2026. The initial excitement about productivity gains? It's curdled into a growing, uncomfortable realization: we're building software faster than ever, and a lot of it is garbage.
I've spent 14 years shipping production systems. I've survived rewrites, scaled teams, and debugged enough distributed failures to fill a book. And I'm telling you directly: the AI code quality crisis is real, it's accelerating, and most teams won't realize the damage until it's too late.
The Trap of Polished-Looking AI-Generated Code
Here's the thing nobody's saying about AI-generated code: it doesn't look bad. That's precisely the problem.
When a junior engineer writes poor code, you can see it. The naming is off, the structure is awkward, the patterns are inconsistent. You catch it in review because it looks wrong. AI-generated code doesn't give you that signal. It comes out syntactically clean, well-commented, and formatted like it was written by someone who read every style guide ever published.
But clean syntax is not the same as sound architecture. I reviewed a pull request last month where the AI generated a perfectly reasonable service class that completely ignored the bounded context the rest of the team had spent weeks establishing. The code compiled. The tests passed. And it introduced a coupling that would take months to untangle.
Jono Herrington, writing on dev.to, nailed it: "Weak engineers with AI still produce weak output. Just faster." He describes watching teams adopt AI tooling, see initial velocity gains, and mistake speed for health. The metrics look good for a sprint or two. Then the accumulated weight of unchecked decisions starts showing up. Refactors that should have been caught in review. Patterns that diverge across the codebase. Technical debt that formed silently because everyone was moving too fast to notice.
This is one of those things where the boring answer is actually the right one. The problem isn't AI. The problem is that we've confused code generation with software engineering.
Does AI Understand Your Software Architecture?
Short answer: no.
AI-generated code quality degrades not because the models are stupid, but because they have no understanding of your specific system. They don't know your team's conventions. They don't know that you chose event sourcing for the order service but CRUD for the inventory service, and why. They don't know that your team agreed to avoid inheritance in the domain layer. They generate statistically plausible code based on training data, and that code often contradicts the deliberate architectural choices your team made.
I've seen this pattern play out across three different organizations in the past year alone. A team ships fast with Copilot or Claude for a quarter. Everything feels great. Then someone tries to refactor a module and discovers four different patterns for the same concern, none of which align with the ADRs the team wrote six months ago. I wrote about this exact phenomenon in my piece on why AI-generated code gets rewritten within weeks. The data is damning.
Herrington's colleague, who runs a CMS platform, put it bluntly: "Sh*t in, sh*t out. AI doesn't solve the decades of issues that distributed teams present." The tool doesn't fix coordination problems. It doesn't fix unclear ownership. It doesn't fix architectural decisions that get revisited every quarter because nobody aligned on the tradeoffs.
Martin Fowler has been talking about this tension in his recent work on AI in software development. His core point resonates with something I keep coming back to: the value of software engineering has never been about writing code. It's about making decisions under uncertainty. AI accelerates the typing. It doesn't accelerate the thinking.
[YOUTUBE:h6T3g2iI4oE|The State of AI in Software Development in 2024]
How AI Coding Tools Are Stunting Developer Growth
This is the part that keeps me up at night. The architectural debt is bad enough. But we're also hollowing out the pipeline of engineers who could eventually fix it.
Julien Avezou, a software engineer writing on dev.to, highlights research on cognitive offloading — the phenomenon where relying on external tools weakens critical thinking and impairs long-term skill formation. He references an experimental learning study reported in Psychology Today that found learners who relied heavily on AI while acquiring complex skills like coding formed "substantially fewer new skills" than those who completed the same tasks without AI assistance. When the goal is learning, offloading key steps to AI "considerably reduces" skill formation. That finding should alarm anyone who manages engineers.
I've shipped enough features to know that the debugging struggle is where real engineering intuition forms. When you spend three hours tracing a race condition through a distributed system, you learn something that no AI tool can teach you. You build a mental model of how systems fail. That model is what separates a senior engineer from someone who can prompt an LLM.
The current generation of junior engineers is being robbed of that struggle. Not on purpose. But the effect is the same. When every coding task starts with "let me ask Copilot," the neural pathways that form through wrestling with a problem never develop. We're creating a workforce that can generate code but can't debug it, can't reason about it, and can't make the architectural judgment calls that determine whether a system survives its second year in production.
As I discussed in my piece on what's left for software engineers when AI writes the code, the answer is judgment. Judgment only comes from experience. There are no shortcuts.
The Rise of Code Slop (and Design Slop)
Adrian Krebs published a fascinating analysis showing that Show HN submissions on Hacker News have tripled in recent years, and they increasingly share a generic, sterile aesthetic he calls "Design Slop." He built a scoring system to detect AI design patterns: Inter font everywhere, "VibeCode Purple" color schemes, glassmorphism cards, identical feature card grids with icons on top, badge-above-hero layouts. His automated analysis of 500 Show HN landing pages confirmed what anyone browsing the site could already feel. A creeping sameness.
Design slop is the visual canary in the coal mine for code slop. If the UI looks like it was generated by the same model with the same defaults, what do you think the code underneath looks like? I've audited vibe-coded applications and found the same security nightmares repeating across projects: hardcoded secrets, missing input validation, authentication bypasses. Same generic patterns. Same generic vulnerabilities.
Code slop is AI-generated code that is syntactically correct, superficially clean, and architecturally meaningless. It compiles. It passes basic tests. And it creates a codebase that no human can reason about because it wasn't built with any coherent intent.
The tool didn't create the problem. It revealed how little structure was there to begin with.
That line from Herrington's piece has been stuck in my head for weeks. It captures the real issue: AI doesn't degrade engineering culture. It exposes and accelerates whatever culture already exists. Teams with strong architectural discipline use AI as a force multiplier. Teams without it are just generating debt faster.
How Should Teams Review AI-Generated Pull Requests?
So what do you actually do about this? I'm not going to tell you to stop using AI coding tools. That ship has sailed, and honestly, used well, they're genuinely useful. But the way most teams are using them is wrong.
Change what code review means. The old code review checklist — does it work, is it tested, is it readable — is insufficient for AI-generated code. You need a new question: does this code fit our architecture? Not "is this code good in isolation" but "does this code respect the decisions this team has already made?" That's a fundamentally different kind of review, and it requires reviewers who understand the system deeply enough to spot divergence.
Treat all AI output as a first draft. I've started telling my teams to think of AI-generated code the way you'd think of a Stack Overflow answer from 2019. It might point you in the right direction. It is not production-ready copy-paste. Every AI-generated block needs to be read, understood, and adapted to your specific context.
Protect learning time for junior engineers. This one is non-negotiable. If you manage a team, create space where junior engineers solve problems without AI assistance. Not because AI is bad, but because the struggle of solving problems independently is how engineering skill actually forms. Avezou's recommendation aligns with the research: delay AI support until a solid base of independent proficiency is built.
Invest in architectural documentation. If your team doesn't have clear ADRs, style guides, and pattern libraries, AI-generated code will fill that vacuum with whatever the model's training data suggests. Your architecture needs to be explicit enough that a reviewer can point to a document and say "this PR violates decision #47." Without that, you're just hoping the AI guesses right.
The Next Two Years Will Separate the Disciplined From the Drowning
Here's my prediction: by the end of 2027, the gap between teams that use AI with architectural discipline and teams that use AI as a code factory will show up in customer-facing metrics. Uptime. Bug rates. Time-to-feature. The companies that treated AI-generated code as a first draft will be shipping confidently. The companies that copy-pasted their way to velocity will be drowning in rewrites.
The AI-generated code quality problem isn't a tooling problem. It's a discipline problem. The tools will keep getting better at generating plausible code. They are not going to get better at understanding your specific system, your team's decisions, or the tradeoffs you made last quarter. That's your job. It's always been your job.
The engineers who thrive in this era won't be the ones who generate the most code. They'll be the ones who can look at generated code and say, with confidence, "this doesn't belong here." That skill — architectural judgment — is about to become the most valuable thing in software engineering. And it's the one thing AI can't generate for you.
Originally published on kunalganglani.com
Top comments (0)