AI is removing the middle class of software engineering?
AI is removing the middle class of software engineering?
AI 正在消灭软件工程的中产阶级吗？
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.
时间回到 2020 年。你是团队中最资深的成员，负责代码质量和架构。你建立了一套良好的工程实践，仔细审查经验不足同事的 PR，并努力维护一个健康的代码库。然后，你休了个假。当你回来时，代码库已经乱成一团。每个人都在没怎么留意的情况下合并了彼此的 PR，有人为了省事给数据库增加了一堆反规范化的新表，还有人没经过任何充分论证就往技术栈里塞了 Serverless 或 Kafka。没关系，你还能修补。
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.
快进到 2026 年。你没休假，这只是一个普通的周一早晨。你泡了一杯好咖啡，打开电脑，发现有 7 个 PR 等着你审查。你打开第一个：增加了 24506 行，删除了 3938 行，附带了一些由 AI 生成的、关于这些代码“应该”做什么的描述。不知何故，你的团队从周五到现在所做的改动，比你以前休假几周时做的还要多。
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.
AI 移除了速度限制。AI 让那些工程文化薄弱的项目失败得更快。曾经，人们会坐下来讨论如何实现某个功能。现在，他们只需要给 AI Agent 发几个小时的提示词，就能提交一个 PR。这种工作方式最悲剧的地方在于，在外行看来，它是“能用”的。如果你拉取分支并进行测试，它大概率能跑通。于是他们怎么做？他们不断重复，一次又一次。直到项目达到一个没人知道它是如何运作的地步。
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.”
这就像有人刷信用卡买了一辆豪车。你看不到债务，只看到那辆看起来很棒的车。但随后用户开始报告一个奇怪的 Bug。这已经是你们团队第四次尝试修复它了——我是说，第四次让 AI 去修复它。不幸的是，似乎连 Fable（假设的 AI 工具）也搞不定。你去找负责这个功能的同事：“数据是从哪来的？”“嗯……其实我不知道。让我问问 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.
你们坐在一起，看着屏幕上出现无穷无尽的文本。你们俩都不知道这些内容是否正确，但 Claude 看起来非常自信。“要不开启 ultracode 让它再检查一遍？”这需要一点时间。你们开始聊起 X（原 Twitter）上的最新八卦。终于，答案出来了。“这逻辑说得通吗？”“我不确定。”“这功能不是你上周才写的吗？”沉默。
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.
“还是让 Claude 修吧。”“好，我设个循环和目标，让它一直跑，直到确认一切正常为止。”“听起来不错。”“其实我今天的 Fable 使用额度用完了，明天再跑吧。”你又去倒了杯咖啡，走回电脑前。现在还有 13 个 PR 等着你审查。你看到一些看不懂的代码，于是给作者发消息：“为什么要在这里这么写？”他们发给你一个链接。那是一个 Claude 的对话记录。
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.
在那段对话中，埋藏在 Claude 自信地推荐架构、道歉、改变主意、你的同事再次要求它重新考虑以及另外 15 轮修改之间，似乎就是这段代码背后的设计决策。“我该读哪一部分？”“可能得全读一遍。”这听起来耳熟吗？每当我谈论这个话题时，总有人告诉我，反正从来没人能完全理解大型系统。确实如此。你本就不需要理解每一个服务和每一个数据库。但至少以前有人懂，并且能向你解释。现在，他们去问大模型，因为他们自己根本不知道。
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.
在每个团队中，都有让项目得以实现的有能力的人。也有那些本质上让其他人工作变得更困难的人。现在，任何人一天产出的代码量都比过去一年还要多。在上面的故事里，每个人都在失败：提交 25000 行代码 PR 的工程师本应在 Agent 达到这个规模前就叫停。他们本应理解代码在做什么，将工作拆解成更小的部分，并质疑它引入的每一个新抽象。
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…
审查者本应拒绝审查如此庞大的代码，而不是妥协。添加 Kafka 的人本应能准确解释为什么需要它。构建该功能的人本应能解释数据来源，而不是发一个 Claude 的对话链接。那问题出在哪？直接用 AI 修不就行了？嗯，没那么简单……
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.
在有人反驳之前，我得说明：这并不意味着技术债总是坏事。关键在于你要意识到这是一种捷径。无论如何，撤销一个错误的决定很难，非常难。例如，让大模型给数据库增加一堆表和列需要多久？10 分钟？但一旦你开始在里面存储数据，你就不能直接删掉它们。你必须制定迁移计划，确保不干扰系统，因为每天都有人在付费使用它。你必须考虑如果迁移失败该怎么办，确保不会留下孤立的外键。修复它实在太难了，即使使用最先进的模型也是如此。而且在你修复的过程中，更多的 PR 不断涌入。更多的代码、更多的抽象、更多的决策。一个人一下午就能生成 2 万行代码，但你仍然得坐在那里去理解这些代码到底在做什么。当你理清一个错误决定时，另外五个错误已经合并进去了。