程序员不再写代码：当AI智能体接管了编程

从写代码到当“调度员”

一位程序员描述了自己工作方式的剧变：过去的工位很简单——一块屏幕、一只鼠标、一块键盘。而现在，同一张桌子上的屏幕被分成十个窗口，每个窗口里“蹲着一个AI智能体”等待派活。他说自己一整天“一行代码都没写”，不是偷懒，而是“根本不用写了”。

这并非个例。Claude Code 的创造者 Boris Cherney 透露，他在本地开五个终端标签页，网页端还同时跑着五到十个 Claude；Cockroach Labs 联合创始人 Peter Mattis 也表示，同时处理五到十个智能体，带来的认知负担比较合适。Linear 工程师 Dima 说得更直白：以前一只鼠标、一块键盘、一块屏幕，物理上就不可能同时干好几件事，现在这个限制没了。

于是，程序员的角色正在从“编写者”转变为“调度员”——给这个智能体下指令，切过去看那个的结果，再切回来。

编辑器的退场与数据佐证

如果程序员不再亲手敲代码，那承载代码的编辑器又去了哪里？据这位UP主的梳理，Codex、Cursor、JetBrains 都在往智能体的方向演进，传统编辑器正在悄悄退场。

一个颇具说服力的数据来自 GitHub：智能体创建的合并请求（PR）数量已经超过了人类。换句话说，在 GitHub 上由 AI 提交的 PR 已经比人提交的还多。

前亚马逊工程师 Steve Yegge 把程序员使用 AI 的程度分成了八级：第一级完全不用 AI；第四级不看代码、只跟智能体对话；第五级彻底扔掉编辑器；第八级自己写编排器，同时指挥三十个甚至上百个智能体。他坦言，有些非常优秀的工程师还停在一二级，仍然非常仔细地检查 AI 写的每一行代码——“我真的非常同情他们。”

Steve Yegge 的八级分类体系值得单独解释。第一、二级代表传统开发者，仍亲手编写大部分代码，最多将 AI 当作高级搜索引擎；第三级开始让 AI 生成代码片段，但逐行审查；第四级不再直接读代码，通过自然语言与智能体对话来验证功能；第五级彻底抛弃 IDE/编辑器，完全在终端或对话界面工作；第六、七级开始自动化测试与部署流程；第八级则自建"编排器"（orchestrator）——即一段程序或脚本，用于并行调度几十乃至上百个 AI 智能体同时工作，工程师本人只监控整体进度和最终结果。这一分级的意义在于：它揭示了 AI 工具的使用不是二元的"用/不用"，而是连续谱系，不同级别的生产力差距可能高达数十倍，由此也带来工程师之间日益扩大的能力鸿沟。

没人看得过来的代码审查

效率暴涨带来了新问题：十个 AI 写得飞快，谁来审查这些代码？

UP主用了一个生动的比喻：合并请求像流水线上的快递，一个接一个砸到面前。第一个认真写了三条评论，第十个只扫了一眼，第一百个直接盖章通过。一位工程师道破了“全行业公开的秘密”——所有人都在演一场代码审查的戏。面对五到十倍的审查量，没人跟得上，大家只好选择阻力最小的方式：放弃真正的审查，给所有东西都盖上“通过”的章。

结果是什么？工具创作者 Mario Zechner 说“一切都坏掉了”——98% 的可用率正在成为常态而非例外，就连一些大型服务也是如此，用户界面里冒出各种奇奇怪怪的毛病，这些本该被测试团队提前发现。

更讽刺的是，程序员并没有因此变轻松。Dima 说，总有另一个智能体在等你回复。刚开始，别人一天的活他一小时就干完了；但现在大家默认你得同时干好几件事，AI 省下的时间又被更多的活填满了。

合并请求（Pull Request / PR）是现代软件协作的核心机制：开发者在独立分支上完成功能开发后，向主代码库发起"合并申请"，由同事进行代码审查（Code Review），确认逻辑正确、无安全漏洞、符合规范后，方可合入主干并最终部署上线。代码审查长期被视为保障软件质量的最后一道人工防线——它不仅捕捉 bug，也传递架构思想与团队规范。当 AI 将 PR 提交速度提高五到十倍，而审查者的时间与注意力无法同比例扩张时，这道防线便会在无声中崩塌。工程师在形式上完成审查动作，却无法真正理解代码意图，实质等同于将质量控制外包给了 AI 自身——而 AI 生成的代码恰恰最需要人类的批判性审视。

有些事AI还是改不了

尽管变化剧烈，作者走访一圈后发现，有四件事 AI 暂时没能颠覆。

团队结构没变。 Anthropic 被认为是最 AI 化的公司之一，但那里的 Katelyn Less 说，他们仍然维持“两块披萨团队”的规模，每个团队负责一块软件的持续迭代和值班，形态与以前差不多。

复杂项目的规划照样靠人。 规划复杂项目依然需要反复讨论，甚至要翻出两年前的旧文档来参考。

测试的分量没减。 Bun 的创造者 Jared Sumner 表示，AI 基本写了所有代码，也基本写了所有测试，但花在测试上的时间依旧和写代码差不多——你得有办法确保代码值得信任。

最终拍板的还是工程师。 产品经理和设计师依然不会直接把代码发布到生产环境，作者问了一圈，一家都没找到。能不能上线，最后还是工程师说了算。

累的时候，想想为什么入行

面对这种高速运转，Peter Mattis 给出的建议是：累的时候提醒自己当初为什么进入这个行业。他是因为喜欢“构建东西”，而现在，可以构建得更快了。

这或许是整篇讨论里最朴素也最耐人寻味的注脚——工具在变、角色在变、效率在变，但构建的热情，依然是支撑程序员走下去的底层动力。至于“你在第几级”，恐怕每个开发者都要给出自己的答案。