LLMs正在侵蚀我的软件工程职业生涯，我不知如何是好

# LLM 正在侵蚀我的软件工程职业生涯，而我不知道该怎么办 来源：https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/ *2026年6月6日* 我是一名软件工程师，今年将满10年专业经验。我的职业生涯始于Web前端工程师（那时前端代码调试对我来说更容易，所以我选择了这条路），但很快转向了（Web）后端，从此再也没有回头。 机缘巧合之下，踏入后端开发后，我最终在金融、记账和支付处理领域的软件开发者岗位上工作，期间拥有极大的自主权，并与产品经理和利益相关方保持着密切且坦诚的关系。 我学到了**很多**关于该领域的知识，以及如何为其高效编写程序：PCI合规性、复式记账、第三方托管、对账、支付生命周期、银行转账幂等性等等。 因此，很自然地，我决定将自己的职业生涯专注于成为该领域的专家，从而在专业上脱颖而出，并在一个日益需要领域专家的领域中让自己与众不同。 ## 第一根被侵蚀的支柱：领域专用知识 帕韦尔·切尔温斯基（Pawel Czerwinski）在Unsplash上的红黑白抽象画 去年，我受雇于一家金融领域公司。此前，我工作过的公司虽然业务/产品中确实包含强大的支付和金融组件，但它们并非纯粹以金融为核心的公司。 那家公司也全力拥抱AI，所以入职第一天我就获得了ChatGPT和Claude企业账户，并被鼓励用它们来做研究、探索甚至编码，但同时也被警告：我仍需审查并对自己最终投入生产的每一行代码负责。 我最初的几个项目之一是重新设计遗留的在线支付系统，那是一团糟。他们雇用我（除其他原因外）主要是因为我之前有构建此类系统的经验，并信任我来完成这项任务。 与我之前工作过的其他公司不同，他们要求我在编码前编写的“设计文档”既要让工程师看得懂，也要让产品经理看得懂——所以它们不应该是技术深潜，而更像是一种架构视图。我写第一份文档时几乎没怎么用AI辅助——那时我甚至把LLM称为“随机鹦鹉”，现在我不再这么看了——然后交付了。 我珍视自己的知识，认为没有LLM能替代它。 然后我的经理找到了我：尽管你代码交付速度不错，但交付这些设计文档花的时间太长了。你用AI了吗？你应该多用AI。 “这不可能行得通”，我心里想，但还是同意了。那时的模型不如现在的好，但它们确实显著加快了我的写作速度，甚至帮助了决策。 然后我开始意识到：我多年来积累的所有知识——实现间的权衡、收购如何运作、如何设计幂等性以防止重复收费，一切——都变得毫无价值。尽管模型仍需要一些引导，但它们已经能够将如何构建这类系统的要点联系起来，而这正是需要多年实践经验才能在头脑中形成的最困难部分。**那是我第一次受到冲击。** 但当然，我想，它们之所以能做到，是因为网络上关于这些系统如何运作的文章以及所有技术文档浩如烟海，而且我们有博客文章解释如何将技术工具应用于该领域。对人类来说，学习所有这些可能需要很长时间，但那是训练数据，所以模型可以掌握。 模型永远无法擅长的、也是人类能够闪耀的地方，就是调试！我在生产环境中调试竞态条件和分布式系统方面积累了丰富的经验。那是我长期就业的通行证。 ## 第二根被侵蚀的支柱：调试与分布式系统 叶戈尔·科马罗夫（Egor Komarov）在Unsplash上的粉黄抽象故障艺术 于是，在LLM开始擅长编写文档和帮助规划实际实现之后，它们也逐渐擅长编码了。这一趋势始于2025年下半年Claude Code的热潮，接着Codex等工具也相继出现。虽然在此之前我每天都会用LLM编写单元测试，但我还不信任它们能完整实现功能。 接下来的自然步骤就是在编写代码时引入更多AI。说实话，我喜欢这样。我既喜欢将代码交付到生产环境并看到用户满意，也喜欢编码本身，所以我只不过是用一种我喜欢的东西换另一种我也喜欢的东西，很公平。 LLM变得越来越擅长编码，但它们仍然无法调试（无论是由它们还是人类）留下的混乱，所以我仍然拥有一个比单纯“操控机器人”更重要的角色——一张通往就业的通行证。 一切似乎都还好。 然后，MCP、智能体工作流以及Claude 4.5出现了，天开始塌了。 老实说，Claude 4.5并没有那么好。给定一个堆栈跟踪和一些上下文（在大多数情况下，只需启用Sentry MCP并提供Sentry链接），它大约能解决60%的bug。有时它给出的解决方案听起来可行，但完全是错的。 然而这一次，我不再怀疑机器了。我亲眼看到那些过去需要一整天全职调试的bug，被Claude Code一次性搞定。当然，还不是*全部*，但模式已经很明显了。 接着是4.6、4.7、GPT 5.5、Opus 4.8以及DataDog MCP……现在我有了CLI工具，可以一次性解决跨分布式系统的bug。那些我过去解决不了的bug，那些需要两天全职调试的bug，那些缺乏分布式可观测性的分布式系统中的bug。现在90%的bug都能一次性解决，包括古怪的竞态条件、意想不到的边缘情况、第三方集成问题、未记录的API边界情况，等等。我几乎不需要干预。 当然，我仍然有就业机会，因为总得有人审查代码、操控那个机器人。但现在我只不过是一个*现成的工程师*。我没有任何领域专业知识是另一位操控LLM的高级工程师无法匹敌的。我所有金融与支付领域的专业知识、所有通过汗水和泪水换来的调试直觉和分布式系统知识，现在都变成了*可提示的*。 我们曾被教导说，通才和专才总会有自己的角色。但现在市场正把每个人都塑造成通才。这本身并不是坏事，但当你从供需经济学角度审视时，如果人人都是通才，而需求跟不上，通才的价格就会下降。而我们都清楚，需求正在枯竭。 ## 第三根支柱——尚未被侵蚀的那一根：代码质量与架构 史蒂夫·A·约翰逊（Steve A Johnson）在Unsplash上的红方块图 不过，我还有一根支柱立着：代码质量与软件架构——现在正被简化为所谓的“品味”¹（https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/#fn-1）。 在我的职业生涯中，我一直喜欢重构，一直珍视好的代码，并在冲刺中为其争取时间。DDD、六边形架构、整洁架构，你知道所有这些流行词。我喜欢这个话题，喜欢讨论其中的权衡以及如何塑造代码库的不同想法。我*真的*很喜欢它。 这是最后一根立着的支柱。但问题是，已经没人在乎了。 智能体在保持代码库整洁方面做得非常差。如果你不引导它们，很快你就会遇到循环依赖问题。它们会重复代码，添加不必要的注释，混淆纯函数和副作用，无视SOLID原则。 这应该能让人类保持就业，但问题在于，这项技能现在被简化为“品味”一词。但这不仅仅是重命名，行业正在朝着代码组织不那么重要的方向演进。 当然，人类应该引导智能体，以防止出现带有循环依赖图的意大利面条式代码库。我们不想看到那些一碰就碎的`F`级代码库。但`C`级或`D`级？现在没问题了。再也没有人需要`A`或`B`级别的代码库了，因为它们是为LLM而非人类阅读而写的。 我不想争论这是好是坏。如果源代码现在是为机器而非人类阅读而写，那么以机器为目标可能确实没问题。 但这又是我另一根专业知识支柱正在被侵蚀。我在这方面积累的大量知识不再那么有价值了。我花在上面的所有时间——读书、做实战练习、与其他工程师讨论、编写架构决策记录——正在变得无用。 ## 现在怎么办？ 我仍然有工作，并且可以预见自己（至少在这家公司）在未来一段时间内仍有工作。但我不知道从长远来看该作何感想。 我花了10年（考虑到非专业经验可能更久）来精通那些价值越来越低的东西。我最后的专业支柱现在被贬低为一种“品味”，恐怕也撑不了多久了。 而且我知道，不仅仅是我是这样。大约8个月前，我现在的公司进行了一轮裁员（据他们说与AI无关）。一些出色的前同事被裁了，现在还在找工作。他们中的大多数都面临着我上面概述的同样问题：他们的领域专业知识已不足以脱颖而出。 公司现在正在为几个职位重新招聘，而领域熟悉度已不再是强大的差异化因素。我们过去列出的是“软件工程师 - 领域”。现在只是“软件工程师”，团队分配要在接受offer之后才能确定。 当然，这对那些从未有机会深入某个领域、现在却获得更好就业机会的优秀工程师来说是好事，但想到其他那些倾注毕生精力积累领域知识的优秀工程师现在却在同一条赛道上竞争，也让人感到悲哀。 现在，要长期保持我的就业能力，唯一的出路似乎是将我的领域专业知识转移到LLM不那么容易擅长的东西上。但还有什么呢？ 我曾考虑过回到大学，学习数学、统计学、高级机器学习，并申请前沿实验室的研究岗位。但问题在于，我的国家没有前沿实验室，仅有的几家实验室申请者爆满，而家庭原因使得移居另一个国家变得困难。等我能够负担得起这个转变时，RSI（重复性劳损？注：此处RSI可能指“重复性劳损”，但结合语境可能指其他含义，原文未解释，保留RSI）可能已经让研究人员过时了。 也许我该考虑把木工爱好变成职业…… --- **更新（6月7日）**：这篇帖子火了。我又写了一篇帖子，回应社交媒体上的一些评论，并扩展了我的部分论点。你可以在这里阅读（https://human-in-the-loop.bearblog.dev/replies-to-comments-on-my-llms-are-eroding-my-career-post/）。 --- --- 1. 参考此处（https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic#:~:text=design%20decisions%20that%20require%20organizational%20context%20or%20%E2%80%9Ctaste.%E2%80%9D）、此处（https://pakodas.substack.com/p/how-to-be-a-30x-ai-engineer-with-a-taste#:~:text=The%20word%20that%20keeps%20coming%20up%20is%20%E2%80%9Ctaste.%E2%80%9D）和此处（https://davegriffith.substack.com/p/what-do-engineers-mean-when-we-say）。请不要将此视为对以上任何帖子内容的认可。↩（https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/#fnref-1） \#ai（https://human-in-the-loop.bearblog.dev/blog/?q=ai）\#llm（https://human-in-the-loop.bearblog.dev/blog/?q=llm）\#软件工程（https://human-in-the-loop.bearblog.dev/blog/?q=software%20engineering）