AI 编程 5.0 · 必读 2026-08-11 · 文章

AI is removing the middle class of software engineering

Florian Herrengt 用一个 2026 年软件团队场景解释 AI coding 的结构性后果:agent 把产出速度上限拿掉,25,000 行 PR无人能解释的数据流靠 Claude 会话追溯设计决策会让弱工程文化更快崩盘文章的重点不是工程师会不会消失,而是判断力review 能力和系统理解会涨价,中间层产出型工程师会被压缩

打开原文回到归档

AI is removing the middle class of software engineering

Source: https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html
Author: Florian Herrengt
Original date: 2026-08-11
Added by: AAIF daily-intake-evening 2026-08-13

摘要

Florian Herrengt 用一个 2026 年软件团队场景解释 AI coding 的结构性后果:agent 把产出速度上限拿掉,25,000 行 PR、无人能解释的数据流、靠 Claude 会话追溯设计决策会让弱工程文化更快崩盘。文章的重点不是“工程师会不会消失”,而是判断力、review 能力和系统理解会涨价,中间层产出型工程师会被压缩。

English Summary

The article argues that AI coding removes the speed limit from weak engineering cultures: teams can generate huge PRs and layers of architecture faster than anyone can review or understand. The durable skill that becomes more valuable is engineering judgment, not raw code production.

入库理由

  • quality_score: 5
  • category: coding
  • tags: ai-coding, software-engineering, agentic-coding, engineering-culture
  • one_liner: AI coding 把产出速度上限拿掉后,工程判断力比写代码速度更稀缺。

Obsidian evidence excerpt

# AK-RSS-Digest(89源精选)· 2026-08-13

> 89 源覆盖技术、AI、写作、安全、文化等。本次筛选 50 个候选,最终入围 5 条。
> 评分依据:原文正文(不靠标题/摘要/源声誉/模型记忆)。所有摘要两句话内,点评基于证据。
> 昨日(2026-08-12)已收录:Ed Zitron Don't Look Up / Pluralistic Model collapse / OTel / 经济学人 AI 写作 / Zuck 宣言。本日侧重昨日未入选的新条目。

---

## 1. Florian Herrengt:AI is removing the middle class of software engineering
- 标题:AI 移除了软件工程的中产——快速 PR 时代里真正会涨价和真正会降价的人
  评分:8.4/10
  推荐语:把 "AI 把编程速度拉到失控" 这件事讲成了一组 2026 年的工程师现场——7 个 PR 一天、25,000 行 diff、Claude 自信回答但没人能判断真假,对一线工程团队极有带入感。
  摘要:原文用一个虚构但细节扎实的团队勾勒出"AI 移除速度上限"后的崩盘链条:25000 行 PR 进 review、数据来源要 Claude 回答、修复 bug 靠多日循环 agent、坏决策累积到没人能复原;作者结论是 AI 让好工程师更值钱、让差工程师更便宜,而不是工程师普遍值钱。
  链接:https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html

## 2. Simon Willison (博客):"Stealing Reasoning Traces from Proprietary LLM APIs"
- 标题:论文发现 OpenAI/Anthropic/Google 的加密思维链可以回灌弱模型解出原文
  评分:8.5/10
  推荐语:把"加密链式思维"的安全性打穿成一个具体可复现的 prompt-injection 攻击,并且把"模型把自己推理痕迹当权威上下文"这件事直接抛到台面——对做 red team / agent 防御的工程师必须读。
  摘要:原论文(alphaxiv 2608.09867)发现同一家族模型共用加密密钥,导致 frontier 模型的 reasoning 块可以被喂回 Haiku 类弱模型,prompt 诱导输出未加密的原 thought;所有模型在漏洞报告后都已封堵,但截获的 GPT-5.5 原始推理片段(如"Need app.css truncated")首次公开。
  链接:https://simonwillison.net/2026/Aug/11/stealing-reasoning-traces/

## 3. Sophie Alpert (via Simon Willison):There are no lossless transformations of natural-language text
- 标题:让 ChatGPT 帮你改稿是单向信息损耗——这是 Clay 团队的官方 AI 写作政策
  评分:8.2/10
  推荐语:Clarity 比典型的"AI 别用了" / "AI 随便用" 都更落地:把"你必须为每句话负责" / "长文不是更好" / "读者时间 > 你的时间" 这些原则变成具体的可执行政策,AI 协作团队可以直接照搬。
  摘要:全部四条原则是"为每句话站桩 / 写作就是思考 / 写稿时间 > 阅读时间 / 长 ≠ 好"——核心是"自然语言没有无损变换":每次改写都改变意义,如果改写者没有最细的脑内模型,信息就丢失;引一句"个人化在标准 loss 函数下就是带弯路的回归均值"。
  链接:https://sophiebits.com/2026/06/25/there-are-no-lossless-transformations-of-natural-language-text

## 4. Gary Marcus:Circular financing reaches new heights
- 标题:华尔街的钱用来帮 Nvidia 客户买 Nvidia——Jim Chanos 隔空附议
  评分:7.6/10
  推荐语:把 Nvidia 最后一轮 $500B 融资归属、NVDA 5Y CDS 翻倍、Chanos 暗示"2031 国会听证"三个证据拼成单页短文,比 Ed Zitron 的长版更适合在群里直接转图——同时支持 Ed Zitron 上条"70% AI 营收押注两家不可持续实验室"的判断。
  摘要:作者引用 The Information 表格展示 NVIDIA 用同一笔资金循环买自家 GPU 的结构;Ho

Fetched source body

AI is removing the middle class of software engineering

作者: Florian Herrengt
发布时间: 2026-08-11T00:00:00+00:00
原文链接: https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html

It's 2020. You're the most senior person on your team, in charge of code quality and architecture. You've set up good engineering practices, you thoroughly review PRs from people who are less experienced than you and work hard to maintain a healthy codebase.

Then at some point, you go on holiday. When you come back, the codebase is a mess. Everyone merged each other's PRs without really paying much attention, someone added a bunch of new tables to the database to denormalise it because it was easier and they added serverless or Kafka to the stack without any solid evidence that they needed either.

It's okay. You can fix this.

Fast forward to 2026. You haven't been on holiday. It's just a normal Monday morning. You make yourself a nice coffee, open your computer and find yourself with 7 PRs to review. You open the first one: +24506 -3938 lines, accompanied by some AI-generated description of what they're supposed to do. Somehow, your team has made more changes since Friday than they used to make while you were away for a few weeks.

AI removed the speed limit

AI makes projects with weak engineering culture fail much faster.

There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

The most tragic aspect of this way of working is that, to the untrained eye, it works.

If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.

Just like someone buying a new luxury car on a credit card. You don't see the debt. You just see the car that looks great.

But then users start to report a weird bug. It's the 4th time your team has been trying to fix it. I mean... asking AI to fix it. Unfortunately, it seems like not even Fable can figure it out.

You go talk to the person who worked on this feature.

  • "So where does the data come from?"
  • "Hmm... actually I don't know. Let me ask Claude."

You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true but Claude seems very confident.

"Let's just turn on ultracode and ask it to double-check?"

This one will take a while. You start talking about the latest drama on X.

You finally get an answer back.

  • "Does this make any sense to you?"
  • "I'm not sure."
  • "Didn't you build this like... last week?"

Silence.

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.

So, what do you do?

Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.

And what are you even thinking about? It would end up in the exact same state again in just a few months anyway.

  • "Let's just ask Claude to fix it."
  • "Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works."
  • "Sounds good"
  • "Actually, I ran out of Fable usage for today so I'll run it tomorrow"

You grab another coffee and walk back to your computer. You now have 13 PRs left to review. You see something you don't quite understand, so you message the person who wrote it.

  • "Why are we doing this here?"

They send you a link. It's a Claude conversation.

Somewhere in that conversation, buried between Claude confidently recommending one architecture, apologising, changing its mind, your coworker asking it to reconsider again and another 15 rounds of changes, is apparently the design decision behind this code.

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

Does this sound familiar?

Whenever I talk about this, someone eventually tells me that nobody ever fully understood large systems anyway. It's true.

You were never expected to understand every service and every database. But at least someone did and would explain it to you.

Now they ask an LLM because they don't actually know themselves.

Powered by EmailOctopus

You can't afford bad engineers anymore

In every team, there are competent people who make the project possible. There are also people who essentially make it harder for everyone else. And now anyone can produce more code in a day than they used to in a year.

In the story above, everyone is failing:

  • The engineer opening a 25,000-line PR should have stopped the agent long before it got there. They should have understood what it was doing, broken the work into smaller pieces and questioned every new abstraction it introduced.
  • The person reviewing it should have refused to review something that large instead of giving in.
  • The person adding Kafka should have been able to explain exactly why it was needed.
  • The person who built the feature should have been able to explain where the data came from without sending a link to a Claude conversation.

But what's the problem then? Just use AI to fix it. Well, it's not that easy...

Before anyone jumps on this, none of this means technical debt is always bad. The important part is that you know it's a shortcut.

Anyway, reverting a bad decision is hard. Very hard.

For example, how long would it take an LLM to add a bunch of tables and columns to the database? 10 minutes?

But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.

And while you're fixing it, more PRs keep coming in. More code, more abstractions, more decisions. A person can generate 20,000 lines of code in an afternoon, but you still have to sit there and understand what those lines actually do.

By the time you've untangled one bad decision, five more have been merged.

The new AI economy

Of course, bad engineers were always a liability.

It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.

The difference is that there used to be a limit to how fast you could do it.

Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.

Ask yourself why companies are paying six-figure salaries for engineers in London or San Francisco in the first place.

If all they needed was someone who could turn a specification into working code, why were they paying that much when they could already get it done cheaply elsewhere?

Why are the tech companies claiming that "software is solved" still paying top salaries to attract the best people they can?

My bet is that AI pushes salaries further apart. To be employable, there's a bar you have to clear and that bar is whatever the current best model du jour can do.

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.

At the same time, bad engineers have become much more expensive to hire.

I wrote about this before when I said the vibe coder career path is doomed.

You need to contribute beyond what everyone already gets by giving an agent a prompt.

If you lack the judgment required to evaluate the LLM's recommendation, asking for more judgment doesn't solve the problem.

At some point, someone still has to know what is going on. And that's the most valuable person on the team.

The people who don't will become much cheaper to hire or get replaced entirely while the money gets funnelled towards an increasingly smaller number of people who can actually be trusted.

I don't think this is going to be limited to software engineering either. I believe the same thing is going to happen across most knowledge work. AI will make the best people much more productive and the bad ones almost impossible to hire. Before, there was a good chance someone would catch their bad decisions before they went too far. Now they can make changes faster than anyone around them can realistically review or understand them.