Mike Arnaldi wrote a thought-provoking piece titled "The Death of Software Development." I respect Mike a lot. Effect is brilliant work, and his analysis of the current AI moment is sharper than most. But I think he's missing something critical.Mike Arnaldi 写了一篇发人深省的文章，题为《软件开发的终结》。我非常尊重 Mike。Effect 的工作非常出色，他对当前人工智能浪潮的分析也比大多数人更为敏锐。但我认为他忽略了一个关键点。

My Workflow Has Changed我的工作流程已经改变

Let me be clear: I'm not here to argue that AI isn't transforming our industry. It is. My own workflow has changed dramatically.我要明确一点：我并不是要争辩人工智能没有在改变我们的行业。它确实在改变。我自己的工作流程也发生了巨大的变化。

When an issue lands in my queue today, my first instinct is to throw it at AI. Security vulnerabilities in Node.js or Undici. Bugs in Fastify. New features for Platformatic. AI handles the implementation. I've shipped dozens of fixes this way in the past few months.如今，当我的待办队列中出现问题时，我的第一直觉就是把它交给人工智能。无论是 Node.js 或 Undici 中的安全漏洞、Fastify 中的错误，还是 Platformatic 的新功能，人工智能都能处理实现过程。在过去几个月里，我已经通过这种方式发布了数十个修复程序。

But here's the thing Mike glosses over: I review every single change. Every behavior modification. Every line that ships.但关键在于 Mike 忽略了一点：我会审查每一个变更。每一个行为修改。每一行发布的代码。

The Bottleneck Has Shifted瓶颈已经转移

Mike writes that he built a Polymarket analysis tool in 2 hours, writing zero lines of code, reviewing zero lines of code. He presents this as a triumph.Mike 写道，他在 2 小时内构建了一个 Polymarket 分析工具，期间没有写过一行代码，也没有审查过一行代码。他将此视为一项成就。

I see it differently.我的看法则不同。

My ability to ship is no longer limited by how fast I can code. It's limited by my skill to review. And I think that's exactly how it should be.我发布产品的能力不再受限于我的编码速度，而是受限于我的审查能力。我认为这恰恰是它应该有的样子。

When I fix a security vulnerability, I'm not just checking if the tests pass. I'm asking: does this actually close the attack vector? Are there edge cases the AI missed? Is this the right fix, or just a fix? When I ship a new feature, I need to understand if it fits the architecture, if it maintains backward compatibility, if it's something I can stand behind.当我修复一个安全漏洞时，我不仅仅是在检查测试是否通过。我还会问：这真的堵住了攻击向量吗？人工智能是否遗漏了边缘情况？这是正确的修复方案，还是仅仅是一个修复？当我发布一个新功能时，我需要了解它是否符合架构，是否保持了向后兼容性，以及我是否能为它背书。

The moment I stop reviewing is the moment I stop being responsible for what I ship.当我停止审查的那一刻，就是我不再为所发布内容负责的那一刻。

The Bloomberg Terminal Question彭博终端的问题

Mike asks: "If an idiot like me can clone a product that costs $30k per month in two hours, what even is software development?"Mike 问道：“如果像我这样的白痴都能在两小时内克隆一个每月收费 3 万美元的产品，那么软件开发到底是什么？”

I'd ask a different question: who's responsible when that clone has a bug that causes someone to make a bad trade? Who understands the edge cases? Who can debug it when it breaks in production at 3 AM?我会问一个不同的问题：当那个克隆产品出现错误导致某人进行错误交易时，谁负责？谁了解那些边缘情况？当它在凌晨于生产环境中崩溃时，谁能进行调试？

The Bloomberg Terminal isn't expensive because the code is hard to write. It's expensive because there are people who understand financial markets, regulatory requirements, data integrity, and system reliability standing behind it. People who have spent years building mental models about what can go wrong.彭博终端之所以昂贵，并不是因为代码难写。而是因为它背后有了解金融市场、监管要求、数据完整性和系统可靠性的人员在支撑。这些人花费了数年时间构建关于可能出现问题的心理模型。

Forty Years of Practices Need Rethinking四十年的实践需要重新思考

Mike is absolutely right about one thing: forty years of best practices are now outdated. The patterns we relied on, the team structures we built, the processes we followed. All of it needs to be reconsidered.Mike 有一点说得完全正确：四十年的最佳实践现在已经过时了。我们所依赖的模式、我们建立的团队结构、我们遵循的流程，所有这一切都需要重新考量。

Code review processes designed for human-written code? Need rethinking. Sprint planning based on human typing speed? Obsolete. The assumption that more developers means more output? Questionable.为人类编写的代码而设计的代码审查流程？需要重新思考。基于人类打字速度的冲刺规划？已经过时。认为开发人员越多产出就越多的假设？值得怀疑。

I've been in the Node.js ecosystem long enough to see "best practices" come and go. But this is different. This isn't a new framework or a new paradigm. This is a fundamental shift in how code gets produced. Anyone pretending we can keep doing things the old way is in denial.我在 Node.js 生态系统中待的时间足够长，见证了“最佳实践”的兴衰。但这与以往不同。这不仅仅是一个新的框架或新的范式。这是代码生产方式的根本性转变。任何假装我们可以继续沿用旧方法的人都是在自欺欺人。

Software Engineers and Architects Are More Crucial Than Ever软件工程师和架构师比以往任何时候都更重要

Mike argues that while software development is dead, software engineering is alive. I completely agree. Engineers are now "designing higher-order systems" and "building techniques." The role of software engineers and architects is more crucial than ever.Mike 认为，虽然软件开发已死，但软件工程依然存在。我完全同意。工程师们现在正在“设计高阶系统”和“构建技术”。软件工程师和架构师的角色比以往任何时候都更加关键。

What's gone is the role of the programmer who takes a task from Jira, does it, and clocks off for the day. That job is gone. AI can do that now, faster and cheaper.消失的是那种从 Jira 接收任务、完成任务然后下班的程序员角色。那份工作已经不存在了。人工智能现在可以更快、更廉价地完成这些工作。

But I think there's more to it. Reviewing and assessing code done by others is what we have done in open source since forever. As a maintainer of Node.js, Fastify, Pino, and Undici, and as Chair of the Node.js Technical Steering Committee, I spend most of my time reviewing pull requests from contributors I've never met. I don't write most of the code that ships. I review it, I assess it, I decide if it's good enough. This isn't new to me. AI is just another contributor now.但我认为事情远不止于此。审查和评估他人完成的代码，是我们开源领域一直以来都在做的事情。作为 Node.js、Fastify、Pino 和 Undici 的维护者，以及 Node.js 技术指导委员会的主席，我大部分时间都在审查我从未谋面的贡献者提交的拉取请求（pull requests）。我并不编写大部分发布的代码。我审查它、评估它，并决定它是否足够好。这对我不新鲜。人工智能现在只是另一个贡献者而已。

I've also shipped contributions that I did not fully understand. I regret them fondly. Every maintainer has done this at some point. And every time, it comes back to bite you. The bugs are harder to fix. The behavior is harder to explain. The technical debt compounds. This is why review matters. This is why understanding matters.我也曾发布过自己并未完全理解的贡献。我对此深感遗憾。每一位维护者在某个时刻都做过这种事。而每一次，它都会回来反噬你。这些错误更难修复。其行为更难解释。技术债务不断累积。这就是审查的重要性所在。这就是理解的重要性所在。

Yes, I design systems. But more importantly, I provide judgment. I decide what should be built, how it should behave, and whether the implementation matches the intent. I catch the cases where the AI confidently produces something that looks right but isn't. I understand the context that no prompt can fully capture.是的，我设计系统。但更重要的是，我提供判断力。我决定应该构建什么、它应该如何表现，以及实现是否符合意图。我能捕捉到人工智能自信地产生看起来正确但实际错误的情况。我理解任何提示词都无法完全捕捉到的上下文。

This isn't a new skill. It's the same skill senior engineers have always had. The difference is that now it's the primary skill, not one of many.这不是一项新技能。这是资深工程师一直以来都具备的技能。不同之处在于，现在它是首要技能，而不是众多技能之一。

The Real Question真正的问题

Mike says that "the average software developer is not even close to understanding the extent of this change." I agree. But I think the misunderstanding cuts both ways.Mike 说“普通软件开发人员甚至根本不了解这种变化的程度”。我同意。但我认为这种误解是双向的。

Some developers underestimate AI. They think their job is safe because AI makes mistakes. They're wrong. AI is already good enough to handle a huge portion of routine coding work.一些开发人员低估了人工智能。他们认为自己的工作是安全的，因为人工智能会犯错。他们错了。人工智能已经足够强大，可以处理很大一部分常规编码工作。

But some AI enthusiasts overestimate the transformation. They think the human in the loop is a temporary limitation, a bottleneck to be optimized away. I think they're wrong too.但一些人工智能狂热者高估了这种变革。他们认为“人在回路中”是一个暂时的限制，是一个可以被优化掉的瓶颈。我认为他们也错了。

The human in the loop isn't a limitation. It's the point.人在回路中不是一种限制。它是核心所在。

When I ship code, my name is on it. When there's a security vulnerability in Undici or a bug in Fastify, it's my responsibility. I can use AI to help me move faster, but I cannot outsource my judgment. I cannot outsource my accountability.当我发布代码时，我的名字就在上面。当 Undici 出现安全漏洞或 Fastify 出现错误时，那是我的责任。我可以使用人工智能来帮助我提高速度，但我不能外包我的判断力。我不能外包我的问责制。

What I'm Actually Worried About我真正担心的是什么

My worry isn't that software development is dying. It's that we'll build a culture where "I didn't review it, the AI wrote it" becomes an acceptable excuse.我担心的不是软件开发正在消亡，而是我们最终会形成一种文化，即“我没有审查，是人工智能写的”成为一种可以接受的借口。

I've been maintaining open source projects for over a decade. I've seen what happens when people ship code they don't understand. It's not pretty. And the scale of damage possible when you can generate code at AI speed is much larger than when you're limited by typing speed.我维护开源项目已经超过十年了。我见过人们发布自己不理解的代码时会发生什么。那绝不是什么好事。而且，当你可以以人工智能的速度生成代码时，可能造成的损害规模要远大于受限于打字速度时的情况。

The Industrial Revolution comparison is apt, but not in the way Mike suggests. The Industrial Revolution didn't just make goods abundant. It also created new categories of industrial accidents, new forms of pollution, new ways for things to go wrong at scale. It took decades to develop the safety practices, regulations, and cultural norms to handle industrial-scale production responsibly.工业革命的类比很贴切，但并不是 Mike 所暗示的那样。工业革命不仅使商品变得充裕，也创造了新的工业事故类别、新的污染形式，以及事物在大规模运作时出错的新方式。我们需要几十年的时间来发展安全实践、法规和文化规范，以负责任地处理工业规模的生产。

We're at the beginning of that process for AI-generated software. And the answer isn't to remove humans from the loop. It's to get much better at the review part.我们正处于人工智能生成软件这一进程的开端。答案不是将人类从回路中移除，而是要在审查环节做得更好。

The Path Forward前进之路

I'm not arguing against using AI. I use it every day. I'm more productive than I've ever been.我不是反对使用人工智能。我每天都在使用它。我的效率比以往任何时候都高。

But I've accepted that my bottleneck is now review, not coding. And I'm working on getting better at it. Faster pattern recognition. Better mental models for common failure modes. More efficient ways to verify behavior.但我已经接受了这样一个事实：我的瓶颈现在是审查，而不是编码。我正在努力提升这方面的能力。更快的模式识别。针对常见故障模式更好的心理模型。更有效的行为验证方法。

This is the skill that matters in 2026. Not prompting. Not "agentic infrastructure." Judgment.这就是 2026 年最重要的技能。不是提示词工程。不是“代理基础设施”。而是判断力。

Mike's right that things are changing fast. But the human in the loop isn't a bug to be fixed. It's a feature to be protected.Mike 说得对，事物变化很快。但人在回路中不是一个需要修复的 Bug，而是一个需要保护的特性。