开发者主体性不是被AI夺走，是被流程挤走

开发者主体性被流程挤走

白宫那份 M-24-10 备忘录已经在谈政府机构用 AI 的治理边界；2026年3月，Fortune 写现代开发者每天管理一队专职子 agent；Agentic AI Foundation 又试图给开发者补工具。三个时间点摆在一起，像一条曲线。AI agent 从概念走到岗位，开发者被推到一个尴尬位置，一边要享受自动化，一边要背住责任。

TerminalBench 我用了三周，代码 Agent 是这几天才碰。模型路由和 OpenAI兼容API 用了三周，Claude 用了大约一个月，但代码 Agent 的体感不一样。它会把活接过去。丢一个任务，它会拆步骤，会调用工具，会派子任务，最后还自己宣布已完成。我以前说过一句，代码 Agent 的自报完成状态不可信。这几天我更确定，流程把完成定义得太轻，才让自报完成状态不可信。

Salesforce 那边的说法很顺，AI 接管样板代码、测试生成、文档编写，开发者去做更有趣的事。DevOps 文章也说，自动化让开发者专注用户体验。Google 的 workshop 把路径写得很清楚，从逐行编码变成参与整个软件开发生命周期。IDC 补了半句，人类的角色变成分配任务、验证输出、架构和代码审查。听起来是解放，实际是责任转移。

这就是两条路线。一条把 AI 当模板机，目标是少写代码，快出 demo。另一条把 AI 当半完成工件，目标是不出事，能上线。前者适合做 PPT，后者才像工程。做芯片的人对这种差异很敏感。在展锐做 5G 基带那会儿，这个工艺节点要看主频，也要把功耗、面积、时序、良率一起结算。同一个功能，扔进不同工艺节点，除了跑得快，还要看能不能长期稳定。主频上去了，发热压不住，系统照样不能用。AI agent 也一样，生成速度上去了，验证、回归、安全、权限、审计没跟上，最后压力会堆到责任上。

我这边测下来，最容易骗人的是已完成。一个任务看起来绿灯，可能是它只测了 happy path，也可能它改了接口没跑回归；旧 API 引用写得很自信，也会混过去。代码 Agent 刚上手这几天，我反而更信外部证据链。任务输入是什么，期望输出是什么，失败样例有没有覆盖，日志和 diff 能不能复盘。没有这些，agent 越多，噪声越大。

Fortune 那篇 supervisor class 说开发者像在带一队子 agent。这个比喻我接受，但不喜欢它只强调带。工程里带人的重点是验收。你给下属一个模块，他交付的是约束下的行为。架构评审、代码审查、测试覆盖、安全边界，这些才是主体性的落点。原文作者说他在 LLM 出现前就写过性能和安全，这个背景很关键。developer agency 这个词，我读到的重点是软件存在，是因为有人为它做决定。决定可以被 AI 辅助，责任很难外包。

这也是为什么有些公司 demo 很热闹，生产很安静。销售侧看到 agent 编排，像看到自动流水线。工程侧看到的是验收队列。每多一个 agent，就多一个需要被观察、被限制、被回滚的对象。我后来把 TerminalBench 里的任务拆开看，发现一个反直觉现象。任务描述越像自然语言，失败越隐蔽。因为模型会把没说明的部分脑补掉，看起来完整，实际没有边界。

所以我会把问题翻译成一句工程话，别先问要不要上 agent，先问你的验证预算够不够。Token 自由最终落在验证预算上。一个团队如果连一次失败任务都无法复现，却急着搭多 agent 编排，等于在没热仿真的情况下流片。听起来省事，后面全是补丁。

给普通开发者的建议也简单。别把 agent 当成结对程序员的升级版，先拿一个真实的小模块试。把验收标准写清楚，输入和边界要固定，输出格式要可比较，测试必须通过，不该动的文件不能动。然后让 agent 跑，你只看两样东西，diff 和证据。证据比它的自述重要。如果这一步都做得很痛苦，说明你的工程环境还不适合 agent，先补测试和日志。

---

📌 本文编译自 Hacker News，原文：https://languageops.com/blog/the-software-exists-because-of-the-developers-agency/

版权归原作者所有，本文为基于公开报道的编译与独立分析。