AI is removing the middle class of software engineering?
TL;DR
AI didn't create bad engineers. It removed their speed limit. Anyone can now generate tens of thousands of lines a day. Understanding and reviewing a change is as slow as ever. The author argues this pulls pay apart. The few people who know what the system does get paid more. The rest get priced out.
The article
- In a typical 2026 scene, a senior engineer comes back from a weekend to seven PRs. One of them is +24,506 lines. The engineer who wrote a feature can't say where its data comes from without asking Claude. Design decisions live only in long Claude conversations.
- AI makes projects with a weak engineering culture fail faster. To an untrained eye the generated code works. So teams keep piling on code until nobody understands the system.
- Bad decisions are cheap to make and expensive to reverse. An LLM can add database tables in ten minutes. Once real data lives in them, removing them needs migrations, rollback plans and care for foreign keys. By the time one bad decision is untangled, five more have been merged.
- Tests, CI and code review haven't gone away. But they were built for a world where producing huge changes was impossible. If the people validating changes are the bottleneck, there are three options. Teams can generate less, find a better way to validate, or accept lower quality.
- The author expects pay to spread further apart. The bar for being employable is whatever the current best model can do. Good engineers become more valuable. The rest become cheaper or get replaced. He thinks the same will happen in other knowledge work.
- An updated objections section answers the comment thread. An LLM is not a compiler, because it makes design decisions rather than translating code with fixed meaning. A 10-PR-a-day engineer may just be moving work onto reviewers. He would rather work with two juniors who use AI to understand things than with seniors who stopped trying.
Why it matters
Worth reading in full for leads and reviewers dealing with floods of AI-generated PRs. The opening story is a recognisable scene to show management. The objections section answers the usual pushback in one place, such as 'just fix your process', 'you're anti-AI' and 'it's like a compiler'.
The discussion
A huge, mostly sympathetic thread full of first-hand stories. CPU usage climbed from Claude-written HTTP clients, 14k-line PRs turned out to be 5-line config changes, and managers ranked people by token spend. The author replied to dozens of comments, and many of those replies ended up in the article. The main arguments were whether bad engineers or managers' incentives are the real culprit, and whether understanding the system still matters. Others asked what this means for the job market. Long side debates on leetcode interviews and licensing software engineers took up a lot of space.
AI multiplies bad engineers' blast radius
A bad engineer who once struggled to make code compile can now ship thousands of plausible lines that pass CI, most commenters agreed. One staff engineer traced exponential CPU growth to engineers who 'ship whatever Claude gives them', and others said AI multiplies negative skill too. A minority argued that AI limits the damage from bad engineers, since it writes tidier code and more tests than they would. Others replied that the damage is in the architecture, which bad engineers don't notice.
Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests.
If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
Blame the incentives, not the engineers
Many commenters pushed the problem up the chain, to managers who measure tickets closed, lines changed and now AI spend. The careful engineer then looks like the weak one, and pushing back can get you called toxic. Several described leaders who openly don't care about quality, QA teams cut to pay for LLM bills, and executives vibe-coding products themselves. The author agreed that companies are measuring the wrong thing but held that refusing bad changes is still part of the job.
If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.
I got DMed by management recently asking if I was anti-AI because I had the lowest spend on the team as the lead, y'know, the one that has to review all the slop my peers are generating.
Can process replace understanding?
AI-first teams described moving the work to an 'agent layer' of detailed coding standards, review skills and test batteries, so humans only skim PRs. The author replied that the difficulty of writing code used to be a safeguard, and green CI can coexist with a system nobody understands. Some said careful plans keep even a 25k-line diff understood, and a few asked what QA practices the complainers had before. Others predicted that reviewing code will go the way of reading compiler output, an analogy the author rejected because LLMs make design decisions.
But the real work is not in the "development layer", it's now in the "agent layer".
You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.
Where good engineers come from
A long branch blamed the 2010s 'learn to code' and bootcamp push for filling the industry with people who never cared about the craft. Bootcamp graduates pushed back, and some saw the push as a way to drive down wages. That branch spun off into long debates about leetcode as a hiring filter and whether software engineering should be licensed like civil engineering. A sharper worry was that AI breaks how people improve, with fewer junior roles and failures that feel like the tool's fault.
A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal.
I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.
The job market and the missing middle
Several read the title as mid-level jobs disappearing, which the article barely covers, and some predicted lower pay and a career only for the exceptional. Skeptics asked where the vibe-coded products that beat established software are, and whether any layoffs really trace to AI rather than interest rates. An H-1B branch argued over foreign labor, and others called the lost jobs ticket-to-code work, a layer they expect to shrink.
We keep hearing this, but where is the Photoshop killer written by a gas station attendant? Where is the PayPal alternative written by a retired nurse?
Again this is not about the soldiers in the army being bad of incompetent, those are excuses. The real reason is that it takes a lot to train and maintain a soldier.
Consensus
AI speeds up writing code, not understanding it. Whoever submits or approves a change must be able to explain it. Huge PRs nobody understands are a real and growing problem. Teams that keep changes small and reviewable do fine.
Dissent
A large group argued this is a management, incentive or process failure that AI doesn't cause, since bad code shipped before too. Others said nobody really understood large systems before AI either. AI-first teams said strong standards and verification make deep review unnecessary.