AI is removing the middle class of software engineering — what it means for freelancers
By Arash Latifi — Founder, The DevArt
A summary of Florian Herrengt's viral post and its 937-comment Hacker News discussion: why AI doesn't make weak engineers better, just faster at compounding damage — and how freelancers and small teams stay above the line.
TL;DR — Florian Herrengt's post (1,014 points, 937 comments on Hacker News) argues AI didn't make problem-solving cheap, only code production cheap — and since damage now compounds at unprecedented speed while understanding it hasn't sped up, engineers split into two groups: those with technical judgment (worth more) and those without (worth less or replaced).
The post's story: 7 PRs on a Monday morning
Herrengt sets the scene: a team with a healthy engineering culture, everyone coding with AI. Monday morning, 7 PRs to review; the first is +24,506 / -3,938 lines with an AI-generated description. The code "works" — you pull the branch and it runs. And that's exactly the trap: to the untrained eye, it works. So they keep going, PR after PR, until nobody — not even the author — knows how anything works.
It's like buying a luxury car on a credit card: you see the car, not the debt. Until a bug comes back for the fourth time and you're both sitting there watching an endless wall of Claude text, neither sure whether any of it is true.
The post is fair about one thing: the problem isn't AI, it's using AI as a substitute for understanding. The author says plainly that he uses AI heavily every day and has no interest in going back to writing everything by hand.
Why "bad engineers always existed" doesn't apply this time
The most common pushback in the comments was exactly that: weak engineers have always been a liability. The post's answer: there used to be a speed limit — the damage a weak engineer could do was bounded by how fast a human could type. Now they can produce 10,000 lines of working code before lunch. The key line:
The speed at which bad decisions compound has changed completely while the speed at which you can fix them has not.
And the "AI output is like compiler assembly" analogy gets a sharp reply: a compiler preserves semantics and makes no decisions; an LLM makes dozens of architecture and abstraction decisions on your behalf. Assembly isn't readable because it contains no new decisions.
What the HN discussion added
The 937 comments sharpened the argument with real, current experiences:
- "Productivity" can be theft from teammates: if you open 10 PRs a day but three engineers spend two days reviewing, correcting, and redoing them, you didn't become 10x — you moved work onto the scarcest, most expensive people on the team.
- Process doesn't save you either: code review was designed for a world where producing massive change was impossible. A green CI with full coverage still misses behaviors nobody thought to test.
- Even compilers-of-software feel it: Oracle banned AI code from the JDK with three reasons — reviewer burden, stability, and unsettled IP ownership. (Commenters noted GraalVM, at the same company, uses a Linux-style policy: allowed, but the human submitter is accountable.)
- Juniors split into two kinds: Herrengt describes two juniors who got better because of AI — they use it to understand, not to skip understanding. In the same stretch, seniors who gave up trying to understand became much worse.
- On the future: commenters split between "wages drop and entry gets harder" (the H-1B debate surfaced too) and "the better-tools cycle repeats." The post takes a clear bet: salary spread widens — the best get faster with AI, the rest get cheaper or replaced.
The two paths from here
| | The average AI user (vibe coder) | The engineer with technical judgment | |---|---|---| | Relationship to AI output | Ships it and moves on | Understands what was produced and why | | PRs | Large, many, AI-described | Small, reviewable, with reasons | | When the bug comes back | "Let me ask Claude" | Knows where the data comes from | | Market value | Competes with the model itself → falling | AI makes them faster → rising | | Effect on the team | Consumes everyone's review time | Catches risk before merge |
A checklist to stay above the line
- [ ] Never push a PR you can't explain line by line — even if AI wrote it
- [ ] Break big changes into small pieces; refuse (as author or reviewer) PRs above a few hundred lines
- [ ] Question every new abstraction AI introduces: "why is this needed here?" — no good answer, remove it
- [ ] Before merging, answer three questions: where does the data come from? what if the migration fails? who maintains this in six months?
- [ ] Intentional tech debt is fine — but know it's debt and have a payoff plan
- [ ] Use AI to build understanding (ask why, probe scenarios), not to skip it
- [ ] If you're the reviewer, rejecting an oversized PR is part of your job, not extra strictness
What this means for freelancers and small teams
The freelance market isn't exempt — arguably less so, since clients often have no in-house engineer to check AI output:
- Pricing by "typing code" is over. If you quote by coding hours, you compete with tools that do it far cheaper. What you sell now is the decision: architecture, tooling choices, risk foresight. The post's line: "Today, implementation is cheap. You are paid to make good decisions."
- Delivery with understanding is your edge. The client who had an app vibe-coded today is stuck in six months with code nobody comprehends. Cleaning up those projects — one commenter predicted "the next decade of software consulting will be defined by repairing the Big Ball of Mud" — is a fresh market.
- Small is an advantage, if you're deliberate. The post's warnings target large, long-lived systems. If your project is small, isolated, and easy to replace, ship fast and move on. The red line is anywhere the project must live for years.
FAQ
Q: Should I use AI less?
No — that's not the post's point either; the author uses it heavily daily. The distinction that matters: AI as a building tool (fine) vs. AI as a substitute for understanding (disaster). Simple test: if you can't explain the code you pushed from memory, it isn't ready to merge.
Q: I'm a junior — does this mean my career is doomed?
The opposite, by the post's own examples: juniors who use AI to understand beat seniors who gave up on understanding. Getting into the field is genuinely harder — that part isn't disputed — but the path changed: instead of typing fast, build judgment and use AI to accelerate learning, not replace it.
Q: My team or client pressures me to ship faster?
The post is blunt: someone who ships less but can be trusted beats someone fast whose changes leave you wondering what surfaces later. If you believe something will cause real problems, raising it is part of the job — but stay flexible: when there's a real business trade-off, compromise and record the debt.