A blog post by developer Florian Herrengt has been sitting near the top of Hacker News for some time now, and the reason it's stuck there instead of scrolling off in a day is that it's not really an opinion piece — it's a mechanism, described clearly enough that people keep arguing about it instead of moving on. His argument, compressed: AI didn't make bad engineers less dangerous. It made them faster, and a bad engineer who can produce 10,000 lines of working-but-wrong code before lunch does more damage in a week than one who used to be bottlenecked by typing speed.

I went looking for whether that thesis actually holds up against real numbers instead of just vibes-based agreement in a comment section, and it mostly does — with one important correction to the panic version of the story.

The mechanism, in Herrengt's own terms

His core claim is that implementation used to be the expensive part of software engineering, and now it isn't — review and understanding are. Generating code got nearly free. Comprehending what got generated, catching the premature database denormalization or the tool adopted for the wrong reason, and reverting it before data starts flowing through the mistake, is still slow human work that hasn't gotten any faster. Once bad architectural decisions are live, and data depends on them, undoing them gets exponentially harder — and AI just means more of those decisions get made and shipped before anyone senior even sees them.

His conclusion is a bifurcation, not a collapse: engineers with strong judgment become significantly more valuable because they're the ones who can evaluate what a model produced and keep a system coherent. Engineers whose main economic value was careful, correct implementation — historically, the actual "middle" of the profession — lose the thing that made them employable, because that specific skill is what got automated first.

What the numbers actually say about the review bottleneck

This part checks out, and it checks out harder than I expected. Faros AI's 2026 engineering report, pulling data from roughly 22,000 developers across 4,000 teams, found that under high AI adoption, median time spent in PR review is up 441.5% and average PR size is up 51.3%. Bugs per pull request are up 54%. Meanwhile, PRs merged without any review at all are up 31.3% — meaning the safety net that's supposed to catch exactly the failure mode Herrengt describes is fraying at the same time the volume going through it is spiking.

A separate JetBrains behavioral study tracked via IDE telemetry found developers using AI tools performed roughly 100 delete/undo actions per month, against 7 per month for developers not using AI — a 14x gap in rework, which is a fairly direct proxy for "generating things that turn out to be wrong and have to be walked back." And a CodeRabbit analysis of 470 open-source pull requests found AI-generated code produces 1.7x more issues than human-written code, with logic and correctness errors specifically up 75%. None of this is "AI writes bad code" in the abstract — it's that more code is moving through review at once, review capacity didn't scale with it, and the gap is where Herrengt's "bad engineer moving faster" scenario actually lives.

Where the data gets more careful than the panic headline

Here's the correction. The instinct after reading Herrengt's post is to assume junior and mid-level roles are simply disappearing across the board, and that's not quite what's happening — Stanford's Digital Economy Lab published a study in August 2026 using ADP payroll data from November 2022 through June 2026 that's worth reading precisely because the researchers were careful not to overclaim. Employment among workers aged 22-25 in the most AI-exposed occupations now sits about 19% below where it would be if it had tracked employment among similarly-aged peers in less-exposed fields. That gap has widened steadily since August 2025. Women, who on average work in more AI-exposed roles, are affected more.

But the study's own explicit conclusion is: "We do not see widespread, economy-wide job displacement associated with AI." Experienced workers in the same exposed occupations show no comparable gap at all. This is a targeted effect concentrated in one age band and one category of task — not, yet, the sweeping "the middle class of the profession is gone" story the panic version tells. It's closer to what Herrengt is actually arguing than the headline version of his post: the erosion is real, it's measurable, and it's specifically hitting the segment doing routine, judgment-light implementation work — which is exactly the segment he calls "the middle class."

What the Hacker News thread actually agrees and disagrees on

The top-voted comment on the thread doesn't dispute the thesis, it reinforces it: a bad engineer now "amplifies their bad engineering x10" with AI assistance, and garbage-in-garbage-out applies to generated code exactly the way it always applied to copy-pasted Stack Overflow answers, just at higher volume. Where the thread actually splits is on what to do about it. One recurring argument is professionalization — licensing software engineers the way law and accounting license practitioners — with the counterargument being that licensing regimes create cartels and slow down exactly the kind of fast iteration that makes software different from those fields. A second recurring thread blames the "learn to code" bootcamp era for flooding the market with engineers who never got the mentorship that used to turn junior into senior, which is a separate, older problem AI is now compounding rather than causing. A third argues the entire leetcode interviewing model was already a bad filter for the judgment Herrengt says now matters most, with one engineering manager describing dropping it entirely in favor of pairing candidates with the actual team on a real problem, and admitting "85% of my team would fail" the leetcode version of their own interview.

What I'd actually take from this if I were early-career right now

The honest read isn't "don't become a software engineer." It's that the traditional path — get hired as a junior, spend a few years doing careful, well-supervised implementation work, gradually earn the judgment that makes you senior — is the exact pathway getting squeezed, because the "careful implementation" step is the one that got cheap. The Stanford data says that pathway is measurably narrower right now for people in their early twenties in the most exposed roles. It doesn't say the profession stopped needing judgment. If anything, every number in this piece points the other direction — review, architectural coherence, and knowing when a generated 10,000-line PR is quietly wrong are worth more than they were three years ago, not less. The skill that's disappearing is "being valuable purely for typing correct code quickly." That was never actually the hard part of the job. It just used to be the part that was slow enough to hide behind.