AI Is Killing the Middle Class of Software Engineering

The 25,000-Line Pull Request

Picture this: it's Monday morning. You grab a coffee, open your laptop, and find 7 pull requests waiting for review. You open the first one. It's 24,506 lines added, 3,938 removed. The description was written by Claude. Your team — since Friday — has shipped more changes than they used to make in a month.

This isn't a hypothetical. It's the opening scene of a blog post by Florian Herrengt that hit the top of Hacker News this week with 755 upvotes and 700+ comments. And it struck a nerve because it describes something a lot of engineers are living through right now but haven't quite found the words for.

The thesis is simple: AI didn't just speed up software development. It removed the speed limit on bad engineering. And that's hollowing out the middle.

The speed limit is gone

Here's how software engineering used to work, even at mediocre companies. Somebody wanted to build a feature. They'd talk about it, sketch out an approach, maybe argue about architecture for an afternoon. A junior developer would implement it over a few days. A senior developer would review it, catch the obvious problems, and eventually it would get merged. The process was slow, yes. But the slowness was a feature, not a bug. It gave people time to think.

Now? Someone can prompt an AI agent for a few hours and open a PR that restructures half the codebase. They can add Kafka to the stack, denormalize the database, introduce new abstractions — all in an afternoon. And here's the thing that makes it dangerous: to the untrained eye, it works. You pull the branch, you test it, and you get something that looks functional. So they keep going.

Herrengt compares it to buying a luxury car on a credit card. You don't see the debt. You just see the car.

The debt is real though. It's technical debt compounding at a speed that makes the old "move fast and break things" era look like a leisurely stroll. A person can generate 20,000 lines of code in an afternoon, but someone still has to sit there and understand what those lines do. And by the time you've untangled one bad architectural decision, five more PRs have been merged.

Nobody knows how anything works anymore

The most painful part of Herrengt's piece is the anecdote about asking a colleague where data comes from in a feature they built last week. The answer: "Hmm... actually I don't know. Let me ask Claude." Then they sit together watching an endless wall of text scroll by, neither of them sure if any of it is accurate, while Claude seems very confident.

This is the part that should scare you. Not because Claude is wrong (though it might be), but because the developer who built the feature has no idea how it works. They delegated not just the implementation but the understanding. When you ask them about a design decision, they send you a link to a Claude conversation. Somewhere in that conversation — buried between Claude recommending one architecture, apologizing, changing its mind, the developer asking it to reconsider, and fifteen more rounds of changes — is apparently the rationale behind the code you're now maintaining.

"Which part should I read?" "Probably all of it."

There's a difference between "nobody fully understands large systems" (always true) and "nobody on the team knows how the thing they built last week works" (new and terrifying). In the past, even in messy codebases, there was usually someone — that grizzled engineer who'd been there for years, who could explain the data flow, who knew which services talked to which and why. Now they ask an LLM because they genuinely don't know. And the LLM's confidence is not the same as correctness.

The middle is disappearing

Here's Herrengt's core argument, and it's the one that got 755 upvotes: AI pushes salaries and roles further apart. The bar for being employable is now "whatever the current best model can do." If you can't contribute beyond what Claude or GPT can produce on their own, you're not adding value — you're adding code.

Strong engineers have become more valuable, not less. AI lets them move faster. They can prototype, iterate, and ship at a pace that used to require a whole team. The AI handles the grunt work while they focus on architecture, trade-offs, and the judgment calls that actually determine whether software scales.

Weak engineers have become actively dangerous. Not because they're bad people — but because AI amplifies whatever they do by 10x. Bad architectural decisions, unnecessary complexity, poorly designed abstractions — all of that now ships at the speed of a prompt. In the past, the review process would catch most of it. Now the volume is so high that reviews have become rubber stamps.

And the middle? The competent-but-not-exceptional engineer who reliably turned specifications into working code? That's the role being squeezed. If your job is essentially taking a JIRA ticket and converting it into code without contributing much else — architecture decisions, domain expertise, engineering judgment — then yes, that category of developer is going to get hammered.

One commenter on the HN thread put it bluntly: "I think the field is basically over as a long term career unless you are truly exceptional." That's probably too pessimistic. But the direction is clear.

The HN comment section is the real story

The Hacker News discussion on this post is itself a fascinating document. Here are the threads that stood out:

The "I'm the manager now" realization. Multiple engineers described the same experience: they're no longer writing code so much as managing an AI that writes code. They spend their time correcting, adjusting, steering — managing the process rather than implementing. One person said: "Claude is better than any team of developers I've ever had working under me." Herrengt's response was sharp: a manager isn't normally the person deciding how software should be architected. You delegated your technical judgment to an LLM. You stopped doing the most important part of your engineering job.

The entry-level pipeline is broken. Several commenters pointed out that between AI and competitive job markets, it's never been harder to land an entry or mid-level software engineering job. Which means the pipeline that produces senior engineers is broken. If juniors can't get jobs, where do seniors come from in five years? This is a real structural problem that nobody has an answer for.

The "good engineers always existed" counter-argument. Some commenters pushed back, saying the article has rose-tinted glasses. Before AI, nobody wrote tests to a reasonable standard. Documentation was rare. People left and took their knowledge with them. The codebase was a mess before AI too. This is fair — but the speed of mess creation is categorically different now.

The acid fascism analogy. Someone dusted off an old quote about LSD: "LSD makes smart people smarter and stupid people jump out of windows." Same energy. AI is a multiplier. If you're a negative number, multiplying doesn't help.

What actually makes someone valuable now?

If implementation is cheap — and it is — then what are companies paying six-figure salaries for?

The answer is the same as it's always been, just with less room to hide. You're paid to make good decisions. To understand trade-offs. To know when to say "no, we don't need Kafka here." To architect systems that can evolve without collapsing under their own weight. To evaluate whether the LLM's recommendation is actually sound or just sounds confident.

The engineers who will thrive are the ones who use AI as a force multiplier for their judgment, not a replacement for it. They'll use agents to prototype fast, generate boilerplate, explore approaches — but they'll still know why they made each decision and be able to explain it without sending you a Claude link.

The ones who will struggle are the ones who've confused "the code works" with "the code is good." Those are very different things, and AI is exceptionally good at producing the former while being indifferent to the latter.

The practical takeaway

If you're an engineer reading this and feeling the squeeze, here's the honest framing: stop competing with AI on implementation. You will lose. An LLM can write a CRUD endpoint faster than you, and it doesn't need coffee breaks.

Compete on the things the LLM can't do. Understanding the business problem well enough to know what not to build. Having the architectural intuition to spot a bad abstraction before it ships. Being the person who can explain why the system works, not just the person who prompted it into existence.

And if you're building with AI agents — and at this point, who isn't — the discipline matters more than the tool. Constrain your PRs to stay small and reviewable. Question every new abstraction the agent introduces. Never merge something you can't explain. The engineers who do this are the ones who wrote the counter-arguments in that HN thread: "my PRs touch 12-15 files max, they're still human-reviewable, and they work."

That's not ludditism. That's just engineering.

---

We're building CopperRiver for the engineers who want to use AI agents without surrendering their judgment. It's a desktop AI assistant that runs locally — browsing, executing commands, reading files, automating the tedious stuff — while you stay in control of the decisions that matter. Check it out.