LLM正在侵蚀我的软件工程职业生涯，我该怎么办？

LLM正在侵蚀我的软件工程职业生涯，我不知道该怎么办。我是一名软件工程师，今年完成了10年的专业经验。我的职业生涯始于Web前端工程师（当时调试前端代码对我来说更容易，所以我选择了这条道路），但很快就转向了（Web）后端，再也没有回头。

由于一系列巧合，一旦我进入后端开发，我最终担任了财务、簿记和支付处理领域的软件开发职位，在那里我拥有很大的自主权，并与产品经理和利益相关者建立了密切而坦诚的关系。

我学到了很多关于该领域以及如何有效地为其编写程序的知识：PCI合规性、复式分类账、托管、对账、支付生命周期、银行转账幂等性等。很明显，我应该专注于成为该领域的专家，作为一名专业人士脱颖而出，并在一个显示出对领域专家需求日益增长的领域脱颖而出。

第一个被侵蚀的支柱：领域特定知识。去年，我被财务领域的一家公司雇用。到目前为止，我曾在一些公司工作过，这些公司的运营/产品确实具有强大的支付和财务成分，但这些公司不仅仅是以财务为重点的公司。

那家公司也全心全意地拥抱AI，所以我从第一天起就获得了ChatGPT和Claude Enterprise账户，并被鼓励使用它们进行研究、探索甚至编码，尽管有警告说，我仍然应该审查并负责每一行进入生产环境的代码。

我的第一个项目之一涉及重新设计遗留的在线支付系统，它很混乱。他们雇用我是因为（除其他外）我之前构建此类系统的经验，并信任我完成这项任务。

与我迄今为止工作过的其他公司不同，他们希望我在编码前编写的“设计文档”能够被工程师和产品经理阅读——所以它们不应该是技术深度剖析，而更像是架构视图。我在最少的人工智能帮助下写了我的第一份设计文档——当时我甚至称LLM为“随机鹦鹉”，我不再持有这一观点——并交付了它。

我重视我的知识，并认为没有LLM可以取代它。然后我的经理联系了我：尽管你以良好的速度交付代码，但你花了太长时间来交付这些设计文档。你在使用AI吗？你应该更多地使用AI。“这行不通”，我心里想，但还是同意了。

当时的模型没有我们现在的模型那么好，但它们确实为我的写作甚至决策提供了很好的加速。

然后我开始意识到：我多年来积累的所有知识——实现之间的权衡、收购如何运作、如何构建幂等性以防止双重收费等等——一切都变得毫无用处。尽管这些模型仍然需要一些引导，但它们能够将如何构建此类系统的各个点联系起来，这是最困难的部分，只有经过多年的实践经验后才会在大脑中形成。

这是我的第一个震惊。不过，我想，它们可以做到这一点，因为网上有大量关于这些系统如何运作的文章以及所有技术文档，还有博客文章解释如何将技术工具应用于该领域。对于人类来说，可能需要很长时间才能学习所有这些，但这是训练数据，所以模型可以掌握。

模型永远不会擅长的事情，而这也是人类的亮点，就是调试！我积累了在生产环境中调试竞态条件和分布式系统的良好经验。这是我获得长期就业机会的保证。第二个被侵蚀的支柱：调试和分布式系统。因此，在LLM开始擅长编写文档并帮助规划实际实现之后，它们变得擅长编码。

它始于2025年下半年，随着Claude Code的大肆宣传，然后Codex出现了等等。虽然在此之前我每天都使用LLM编写单元测试，但我还不相信它们能编写完整的实现。

下一步自然是在编写代码时引入更多AI。老实说，我喜欢它。我喜欢将东西发布到生产环境并看到用户高兴，就像我喜欢编码一样，所以我用我喜欢的一件东西换取另一件我也喜欢的东西，这是公平的。

LLM变得越来越擅长编码，但它仍然无法调试（当时或人类留下的）混乱，所以我仍然有一个比操控机器人更重要的角色——这是就业机会的门票。一切看起来都很好。然后是MCP、代理工作流和Claude 4.5，天空开始塌陷。

Claude 4.5，说实话，没那么好。在提供堆栈跟踪和一些上下文的情况下，它解决了大约60%的错误（在大多数情况下，只需启用Sentry MCP的Sentry链接）。有时它给出了一个听起来看似合理但完全错误的解决方案。

然而，这一次，我不再怀疑机器了。我看到Claude Code一次性解决过去需要1天全职调试的错误。当然，还没有全部，但模式很明确。然后来了4.6、4.7、GPT 5.5、Opus 4.8和DataDog MCP……现在我有了可以一次性解决分布式系统中错误的CLI。

这些错误是我过去无法解决的。需要2天全职调试的错误。跨缺乏分布式可观测性的分布式系统的错误。

90%的错误现在都是一次性解决的，包括奇怪的竞态条件、意外的边界情况、第三方集成问题、未记录的API边缘情况等等。我几乎不必干预。当然，我仍然可以就业，因为必须有人审查代码并操控机器人。但我现在只是另一个现成的工程师。

我没有另一位高级工程师操控LLM无法比拟的领域专业知识。我所有的金融和支付领域专业知识、所有的调试直觉和分布式系统知识，现在都是可提示的。我们被教导说，通才和专家永远都有自己的角色。但现在市场正在将每个人塑造成通才。

这本身并不是一件坏事，除非你仔细研究供需经济学：如果每个人都是通才，那么如果没有需求匹配，通才的价格就会下跌。我们都知道需求正在枯竭。第三个支柱，尚未被侵蚀的支柱：代码质量和架构。不过，我仍然有一个支柱：代码质量和软件架构——现在被简化为所谓的“品味”。

在我的职业生涯中，我总是喜欢重构，总是珍视好的代码，并为此在冲刺中协商时间。DDD、六边形架构、整洁架构，你知道所有的流行语。我喜欢这个话题，我喜欢讨论如何塑造代码库的权衡和不同想法。我真的很喜欢它。

这是最后一根支柱。只是没有人关心了。代理在保持代码库组织性方面做得非常糟糕。如果你不引导它们，它们会比你想像的更快遇到循环依赖问题。会重复代码。添加不必要的注释。混淆纯函数和副作用。无视SOLID原则。

这应该会让人类保持就业，只是这种技能现在被简化为“品味”这个词。但这不仅仅是重新命名，该行业正在走向一个代码组织不再那么重要的世界。当然，人类应该引导代理防止带有循环依赖图的意大利面条式代码库。

我们不想要F级代码库——不损坏某些东西就不可能触碰。但是C级或D级？现在没问题了。没有人需要A级或B级代码库了，因为它们是为LLM而设计的，而不是为人类阅读。我不想争论这本质上是好还是坏。如果源代码现在是为机器而不是为人类而编写的，那么针对它们实际上可能是可以的。

但这