LLMs are eroding my software engineering career and I don’t know what to do

大语言模型正在侵蚀我的软件工程职业生涯，我感到束手无策

06 Jun, 2026 2026年6月6日

I’m a software engineer, completing 10 years of professional experience this year. I started my career as a web frontend engineer (it was easier for me to debug frontend code back then, so I chose that path), but shortly transitioned to (web) backend and never looked back. 我是一名软件工程师，今年正好满十年工作经验。我的职业生涯始于 Web 前端工程师（当时对我来说调试前端代码更容易，所以我选择了这条路），但不久后我就转型到了后端开发，并从此深耕于此。

Through a series of coincidences, once I stepped into backend development, I ended up working in software development roles in the domains of finance, bookkeeping and payment processing, where I had great autonomy and a close and candid relationship with Product Managers and stakeholders. I learnt a lot about the domain and how to effectively write programs for it: PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, bank transfer idempotency, etc. It was, then, obvious that I should focus my career on becoming an expert on that domain to stand out as a professional and differentiate myself in a field that showed signs of an increasing need for domain specialists. 机缘巧合之下，进入后端开发领域后，我开始从事金融、记账和支付处理领域的软件开发工作。在那里，我拥有极大的自主权，并与产品经理及利益相关者保持着密切而坦诚的合作关系。我学到了很多关于该领域的知识，以及如何有效地编写相关程序：PCI 合规性、复式记账、托管、对账、支付生命周期、银行转账幂等性等。当时显而易见的是，我应该专注于成为该领域的专家，以便在专业上脱颖而出，并在一个日益需要领域专家的行业中实现差异化竞争。

The first pillar to erode: domain-specific knowledge

第一根支柱的崩塌：领域特定知识

Last year, I got hired by a company in the finance workspace. So far, I had worked on companies that do have a strong payment and finance component to their operations/offerings, but that were not solely finance-focused companies. That company also embraced AI wholeheartedly, so I got ChatGPT and Claude Enterprise accounts from day one and was encouraged to use them for my research, exploration, and even coding, albeit with a warning that I should still review and own every single line that made it into production. 去年，我被一家金融领域的公司录用。此前我工作过的公司虽然在运营或产品中拥有强大的支付和金融组件，但并非纯粹的金融公司。这家新公司全心全意拥抱人工智能，所以我从入职第一天起就获得了 ChatGPT 和 Claude 企业版账号，并被鼓励将其用于研究、探索甚至编码，尽管公司也提醒我，必须对进入生产环境的每一行代码进行审查并负责。

One of my first projects involved reworking the legacy online payment system, which was a mess. They hired me for (among other things) my previous experience in building that and trusted me with the task. Different from the other companies I had worked for so far, they wanted the “Design Docs” I write before coding to be readable by both engineers and product managers - so they shouldn’t be a technical deep dive and more of an architectural view. 我的首批项目之一是重构遗留的在线支付系统，那简直是一团糟。他们聘用我（除其他原因外）正是看中了我之前构建此类系统的经验，并放心地将这项任务交给了我。与我之前工作过的公司不同，他们要求我在编码前编写的“设计文档”既要让工程师看懂，也要让产品经理看懂——因此，这些文档不应是深度的技术剖析，而应更多地呈现架构视角。

I wrote my first one with minimal AI assistance - I even called LLMs “stochastic parrots” at the time, a view I no longer hold - and delivered it. I valued my knowledge and thought no LLMs could replace it. Then my manager reached out to me: even though you’re delivering code at a good pace, you’re taking too long to deliver those Design Docs. Are you using AI? You should use more AI. 我几乎没用 AI 辅助就写完了第一份文档——当时我甚至称大语言模型为“随机鹦鹉”（现在我已不再持有这种观点）——并提交了它。我非常看重自己的知识储备，认为没有任何大语言模型可以取代它。然而，经理随后找到我：虽然你交付代码的速度很快，但编写这些设计文档花的时间太长了。你在用 AI 吗？你应该多用用 AI。

“No way this will work”, I thought in my head, but agreed. The models at that time were not as good as the ones we have now, but they did provide a good speed-up on my writing and even the decision-making. And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless. Even though the models still needed some steering, they could connect the dots on how to structure such systems, which was the hardest part that only develops in your brain after years of hands-on experience. That was my first shock. “这怎么可能行得通”，我心里想，但还是答应了。当时的模型虽然不如现在强大，但确实在写作甚至决策方面提供了很好的加速。随后我开始意识到：我多年来积累的所有知识——实现方案之间的权衡、收单业务的运作方式、如何构建幂等性以防止重复扣款——这一切似乎都变得毫无用处。尽管模型仍需要一些引导，但它们已经能够串联起如何构建此类系统的逻辑，而这正是过去需要多年实战经验才能在大脑中形成的、最困难的部分。这是我受到的第一次冲击。

But sure, I thought, they can do that because there’s plenty of articles on the web on how that shit works along with all the technical documentation, and we have blog posts explaining how to apply the technical tools to the domain. For humans, it may take a long time to learn all that, but that’s training data so the models can pick it up. What the models will never be good at, and that’s where humans will shine, is debugging! I had accumulated a good experience debugging race conditions and distributed systems in production. That was my ticket to long-term employability. 但我转念一想，它们能做到这一点，是因为网上有大量关于这些东西如何运作的文章，还有各种技术文档，以及解释如何将技术工具应用于该领域的博客文章。对于人类来说，学习所有这些可能需要很长时间，但这些都是训练数据，模型完全可以吸收。模型永远不擅长的，也是人类能够发光发热的地方，就是调试！我在生产环境调试竞态条件和分布式系统方面积累了丰富的经验。那是我长期就业的保障。

The second pillar to erode: debugging and distributed systems

第二根支柱的崩塌：调试与分布式系统

So, after LLMs started getting good at writing docs and helping plan the actual implementations, they became good at coding. It started in the second half of 2025 with the Claude Code hype, then Codex came and so on. Although I was using LLMs for writing unit tests every day before that, I wasn’t trusting them to write the full implementation yet. The natural next step was to introduce more AI into writing code. And honestly, I liked it. I like shipping things to production and seeing users happy as much as I like coding, so I was trading one thing that I like for another one that I also like, it was fair. 在大语言模型开始擅长编写文档并协助规划实际实现方案后，它们变得擅长编码了。这一切始于 2025 年下半年 Claude Code 的热潮，随后是 Codex 等等。虽然在此之前我每天都在用大语言模型编写单元测试，但我还不信任它们能编写完整的实现代码。顺理成章的下一步就是引入更多的 AI 来编写代码。老实说，我喜欢这样。我喜欢将产品交付到生产环境并看到用户满意的样子，就像我喜欢编码一样，所以我用我喜欢的一件事换取了另一件我也喜欢的事，这很公平。

LLMs were becoming good at coding, but it still couldn’t debug the mess left behind (by them or by the humans), so I still had a role that was bigger than steering the robot - a ticket to employability. Everything seemed fine. Then came the MCPs, the agentic workflows and Claude 4.5 and the sky started to fall. 大语言模型在编码方面变得越来越出色，但它们仍然无法调试留下的烂摊子（无论是它们自己留下的还是人类留下的），所以我仍然扮演着比“操控机器人”更重要的角色——这是我就业的保障。一切似乎都还好。直到 MCP（模型上下文协议）、代理工作流和 Claude 4.5 的出现，天开始塌了。

Claude 4.5, to be honest, wasn’t that good. It solved like 60% of the bugs given a stack trace and some context (a Sentry link with Sentry MCP enabled was all it took in most cases). Sometimes it gave a solution that sounded plausible but was totally wrong. This time, however, I stopped doubting the machines. I saw bugs that in the past would easily take 1 day of full-time debugging being one-shotted by Claude Code. Of course, not all of them yet, but the pattern was clear. 老实说，Claude 4.5 并没有那么强。给定堆栈跟踪和一些上下文（在大多数情况下，只需一个启用了 Sentry MCP 的 Sentry 链接），它能解决大约 60% 的 Bug。有时它给出的解决方案听起来头头是道，但完全是错的。然而这一次，我不再怀疑机器了。我看到那些过去需要全职调试一整天才能解决的 Bug，被 Claude Code 一次性搞定。当然，并非所有 Bug 都能如此，但趋势已经很明显了。

Then came 4.6, 4.7, GPT 5.5, Opus 4.8 and the DataDog MCP… Now I have CLIs that one-shots bugs across distributed systems for me. Bugs that I couldn’t solve in the past. Bugs that would take 2 days of full-time debugging. Bugs across distributed systems that lack distributed observability. 90% of the bugs are one-shotted now, including bizarre race conditions, unexpected corner-cases, third-party integration issues, undocumented API edge cases, everything. I hardly have to intervene. 接着是 4.6、4.7、GPT 5.5、Opus 4.8 以及 DataDog MCP……现在，我拥有了可以为我一次性解决分布式系统 Bug 的命令行工具。那些我过去无法解决的 Bug，那些需要全职调试两天才能解决的 Bug，那些缺乏分布式可观测性的分布式系统中的 Bug，现在 90% 都能被一次性解决，包括离奇的竞态条件、意想不到的边界情况、第三方集成问题、未记录的 API 边缘情况等等。我几乎不需要干预。

Of course, I’m still employable because someone has to review the code and steer the robot. But I’m just another off-the-shelf engineer now. I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distrib… 当然，我仍然有工作可做，因为总得有人去审查代码并操控机器人。但我现在只是一个随处可见的普通工程师。我没有任何领域专长是另一个操控大语言模型的资深工程师所无法比拟的。我所有的金融和支付领域专业知识，所有的调试直觉和分布式……