有些话现在很容易点燃技术圈：AI Agent 会写代码了，开发者是不是又成了业务的减速带？

Tuhin Nair 最近写的文章，真正有意思的地方不在于反驳 AI，而是拆开了一个更扎手的问题：很多资深开发者判断没错，却说服不了业务方。原因很简单，也很尴尬——他们讲复杂度，业务听不懂；业务要降低不确定性，开发者没有接住。

这不是沟通鸡汤。它指向的是软件团队里最常见的目标错位：一边要更快知道市场要不要，另一边要防止系统变成没人敢碰的黑箱。

冲突不在态度，在两条业务循环

一家公司通常同时跑两条循环。它们都重要，但恐惧不同。

循环追求什么最怕什么常见动作
市场探索循环速度、反馈、验证不确定性发功能、测需求、看转化
客户服务循环稳定、可维护、可演进复杂度控制变更、复用系统、减少隐患

产品经理、创业者、销售团队，更多站在第一条循环里。他们急着知道用户要不要、客户买不买、方向对不对。晚一周，可能就少一轮反馈。

资深开发者更多站在第二条循环里。他们怕的不是多写几行代码，而是系统被临时逻辑塞满。一个特殊分支、一个绕开的接口、一次“先这样吧”，今天是提速，明天可能就是排查不完的坑。

所以那句经典冲突会反复出现：

业务说：“能不能快点上线看看？”

开发者说：“这会增加维护成本。”

这句话通常没错，但没打中。业务方问的是“怎么更快降低不确定性”，开发者答的是“这样会增加复杂度”。频道错了，再正确也像拒绝。

更有效的表达不是继续加码警告，而是换成：

“能不能先试一个更快的办法？”

这句话把门打开了。它承认业务要速度，也把工程判断带进来：少写一点，复用一点，延后一点，拆小一点。

资深开发者的价值就在这里。不是多造功能，而是知道哪些功能现在不用造，哪些可以借现有系统试出来，哪些只需要一个按钮、一张表、一个人工流程先验证。

“欲速则不达”放在软件里并不玄。真正拖慢团队的，往往不是一开始慢了半天，而是把每次试错都沉淀成长期负债。

AI 让试错更快，也让责任边界更硬

AI 的加入让这件事更尖锐。

Nair 并没有否认 AI 的价值。AI 很适合加速 Speed 版本：生成原型、拼界面、写脚手架、把一个市场想法更快摊到桌面上。对市场探索循环来说，这很有用。

但 Scale 版本不是“代码能跑”这么简单。有客户在用，有账单在跑，有历史逻辑，有边界条件。系统要能被理解、审查、修复、演进。

AI 可以生成很多代码，但不会替公司承担后果。

这就是我不太买账“AI 让资深开发者过时”的地方。它把写代码等同于做软件，把产出等同于负责。这个等号太粗糙。

更接近现实的变化是：AI 让初稿变便宜，让取舍变昂贵。

未来的资深开发者更像编辑和守门人，不只是作者。作者负责产出，编辑负责判断：哪些代码进入主系统，哪些留在实验田，哪些重写，哪些丢掉。

这不是把资深开发者神化成保守派救世主。他们也有问题。很多人确实不会翻译自己的判断。

只会说“技术债”“维护成本”“架构不优雅”，业务方很难自动听成：这会拖慢下一轮验证，会提高服务风险，会让客户问题更难定位。

该换一种说法：

开发者常说业务更容易听懂的说法
这会增加维护成本这样会让后面每次验证都更慢
这里有技术债这个做法会把试错结果绑进长期系统
架构不太优雅现在可以先试，但别直接进主链路
需求还不清楚我们先做一个更小实验，验证最关键假设

这不是话术美容。它是责任对齐。

如果业务要速度，技术负责人就不能只说“不”。要给出更小的试法。如果开发者担心复杂度，也不能只把风险留在工程内部。要把后果翻译成速度、成本和客户影响。

真正受影响的是技术负责人和业务负责人

对资深开发者和技术负责人来说，接下来最该改的不是姿态，而是工作流。

每个新需求都可以先问三件事：

  • 能不能不用写新代码，先用现有系统验证？
  • 能不能把实验代码和生产代码隔开？
  • 如果验证失败，删除成本有多高？

这三问比单纯争论“要不要做”更有用。它把讨论从立场拉回设计。

对产品经理、创业者和业务负责人来说，也要补一课：快不是把所有想法都塞进主系统。真正的快，是用最小代价换最大反馈。

如果只是催开发“先上再说”，短期看省时间，长期看是在让客户服务循环替市场探索循环还债。账不会消失，只会换个部门结算。

更现实的做法是把需求分成两类：

类型适合怎么做谁负责兜底
Speed 版本快速原型、小范围实验、可丢弃实现产品和技术共同定义验证目标
Scale 版本进入主系统、可维护、可审查、可演进技术负责人对稳定性和复杂度负责

这张表不复杂，但很多团队就败在这里：实验代码一路绿灯，最后混进生产系统；临时方案没人回收，最后变成默认架构。

历史上很多技术扩张都这样。铁路、电力、互联网平台都经历过类似阶段：早期拼速度，后期拼治理。类比不完全一样，但权力结构很像——谁控制基础设施，谁就必须承担长期秩序。

软件系统也是基础设施。AI 让铺轨更快了，但轨道通向哪里、能不能检修、出事谁负责，还是人的问题。

接下来真正该观察的，不是 AI 能不能再多写一点代码。这个方向大概率还会继续进步。

更关键的是团队有没有能力把实验和生产分开，把速度债和复杂度债分开，把“想快点试试”变成“用更小、更可回收的方式试试”。

能做到这一点，AI 是放大器。做不到，AI 就是复杂度加速器。

所以资深开发者的价值没有自动消失，但也不会自动被看见。你得把工程判断翻译成业务语言：更快验证、更少返工、更低服务风险。

代码会越来越便宜。可理解、可负责、可持续的代码，会越来越贵。