A team ships fast with AI coding tools. Then a bug shows up that nobody, not even the AI, can fix. Someone has to go find the one person who remembers how the feature actually works.
That scene opens a post by software engineer Florian Herrengt, “AI is removing the middle class of software engineering.” He describes a team stuck on a bug for the fourth time, still asking AI to fix it, then finally asking a teammate where the underlying data even comes from. Herrengt writes:
“This project has become so convoluted, with so many layers and services, that no one on your team could possibly start to understand what’s going on.”
His conclusion from that scenario:
“AI makes projects with weak engineering culture fail much faster.”
Who Herrengt is
Herrengt is a software engineer who writes about engineering practice and AI-assisted development on his own blog and in public code repositories. Public sources conflict on his current employer, so this article does not assert one.
What he gets right, and where it’s incomplete
Herrengt’s central claim is about speed, not talent. AI coding tools remove the old limit on how much code one person can produce in a day. For an engineer who understands the system they’re building, that limit removal is a gift: more of their judgment gets shipped, faster. For an engineer who doesn’t fully understand what they’re building, the same tool multiplies how much unreviewable code piles up before anyone notices a problem.
That distinction holds up. Code review capacity hasn’t scaled with code production capacity. A senior engineer who used to review a few hundred lines a day from a junior teammate now has to make sense of AI-assisted output that can run into the thousands, often across systems that engineer didn’t design.
Where the post is thinner is on what happens next. Herrengt argues the best engineers get “more valuable” and become “almost impossible to hire” for weak teams, while:
“Good engineers have become more valuable because AI lets them move much faster. They don’t need as many people around them just to do the implementation work anymore.”
That’s a prediction about hiring markets and team structure, not something the post demonstrates with data. It’s a plausible read of one team’s experience, not a measured trend across the industry yet.
Why it’s notable
This post spread fast because it names something builders are already feeling: AI didn’t remove the need for engineering judgment, it raised the cost of not having it. A team with strong code review habits, clear ownership, and people who actually understand their own systems can absorb AI-generated code safely. A team without those habits gets the same speed boost applied to its worst instincts.
What it means for builders
Before you measure AI’s impact on your team by how much code shipped this week, check whether anyone could explain that code to a stranger next month. If the answer is no for a growing share of your codebase, you have a comprehension problem, not a productivity win.
Herrengt’s fix isn’t a tool. It’s the same discipline that mattered before AI: code review that actually reads the code, ownership that doesn’t dissolve the moment a feature ships, and a bias toward systems a team can explain, not just systems that work today. AI makes skipping that discipline faster than ever. It doesn’t make skipping it safe.
End of article