Google DeepMind 负责人：软件工程的新规则丨Beyond Coding
公众号名称：晚点再听LaterCast
作者名称：Capihom
发布时间：2026-06-05 22:28
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
“工程师仍然需要能够进入 IDE 并编辑代码。”
“每两周、每三个月、每六个月，可能做到的事都会改变。”
“你可以外包智能，但不能外包理解。”
这期采访的是 Logan Kilpatrick，Google DeepMind AI Studio 的产品负责人。对话从 Google I/O 上的 Antigravity、Gemini CLI 和 agent manager 讲起，很快转向一个更贴近工程团队的问题：当模型开始稳定写代码，工程师每天的价值会挪到哪里。Logan 的判断很克制。IDE 不会立刻消失，代码也不会变得无关紧要；变化发生在工作重心上，写代码的成本下降以后，评审、上下文、测试、产品判断和理解系统的能力，会被放到更亮的位置。
IDE 不会消失，入口会变多
主持人先问了一个很多工程师已经感到的变化：如果 agent 能生成代码，配上足够的 guardrail 和 harness，开发者还需要一直盯着编辑器吗？Logan 没有顺着“IDE 已死”的说法往下讲。他的说法更像一次重心迁移：软件构建方式正在演化，工具数量有时变少，有时变多。Antigravity 的故事也在这里出现，开发者可以在 IDE、agent manager、CLI，甚至 Gemini API 里的 managed agents 中使用同一套能力。Google 把 Gemini CLI 往集成 CLI 收拢，也来自开发者反馈：别再让大家穿过 50 个 AI 产品找入口。
“工程师仍然需要能够进入 IDE 并编辑代码。”
Logan 认为，开发者未来会把更多时间放在 IDE 外面，比如通过 agent manager 分配任务、跟踪计划、检查结果。但调试、阅读关键改动、修正边界条件，仍然需要编辑器里成熟的工具链。**工程师的桌面不会只剩一个聊天框，工作入口会变成一组可以切换的控制台。**这和十年前开发工具从本地编辑器、命令行、代码托管、CI 服务不断组合起来一样，是工具形态继续变化，而非工程能力被一次性抽走。Antigravity 还牵出一个细节：Gemini CLI 开源了，Antigravity 暂时没有。Logan 的解释很务实，开源有运营成本，团队如果要做就要认真投入；眼下更像速度和团队经验的取舍，而不是藏着什么秘密能力。
PR 和 CI 会先堵起来
代码生成速度上来以后，瓶颈不会消失，只会移动。Logan 说自己在 Google 内部已经有很强感受：他现在经常写代码，生成的代码质量也合理，压力很快落到负责 review 的工程师身上。过去代码评审工具的默认前提，是人写代码，人提交 PR，人解释改动。agent 参与以后，PR 可能变得更密、更快、更长，评审工具本身就需要重做。
“负担已经迅速转移到了很多不同的地方。”
Jeff Dean 也和 Logan 提过另一个迁移方向：工具执行。就算有人能立刻看完你的代码，CI 时间还在，测试还要跑。好的 agent engineer 可能会写更多测试，测试越完整，执行成本越明显。**团队要开始量化软件生产链路里的新堵点：review 等多久，CI 跑多久，测试失败返工几次，agent 哪一步最常卡住。**Google 过去就重视内部工程效率仪表盘，这种文化在 agent 时代会变得更实用。
如果团队只庆祝生成了多少代码，很快会看错指标。更该看的，是从用户需求到合并上线的总周期有没有缩短，review 负担有没有被重新分配，测试失败能不能被 agent 自己解释并修复。模型把第一段路跑快以后，后半段流程会暴露出以前被写代码速度掩盖的问题。
便宜模型要进入真实工作台
主持人提到一个工程负责人每天都会碰到的问题：大家都说 AI 让工程师更有效，但成本也在上升。他拿 Claude Code 的 Opus plan 举例，高端模型先做推理和计划，再交给轻量模型执行。Logan 对 Gemini 3.5 Flash 的兴趣也放在这里：如果同一个更便宜的模型既能规划又能执行，开发者体验和成本结构都会变得更顺。
“这是 3.5 家族的第一次迭代，也是我们第一次做模型、产品、harness 的共生。”
Logan 承认，过去 Gemini 模型常被反馈“纸面表现好，真实用例里没那么好”。Google 过去一年多在认真修这个差距，把模型训练、产品 harness 和实际开发者反馈放到同一个飞轮里。**模型评测不再只看 benchmark 分数，还要看它在 AI Studio、CLI、agent manager 这些产品里能不能稳稳完成工作。**这对工程团队的启发也很直接：别只问模型聪不聪明，要问它在你的 repo、测试、权限、部署流程里能不能跑通。
工程团队落地时，harness 要被当成模型能力的一部分，而非外层包装。它决定 agent 能读到什么、能执行哪些命令、失败时怎么回滚、什么时候把人拉回来。便宜模型如果没有这样的工作台，很容易只停在 demo；一旦和真实权限、测试、日志、代码搜索接起来，成本优势才会进入每天的工程节奏，工程负责人也更容易把效果和账单一起看清楚，预算和排期讨论也会更有依据，团队复盘也会更准。
品味会决定少开多少会
谈到今天还重要的工程技能，Logan 先提到 taste。这里的品味更接近一种判断力：问题该怎么被拆、该让 agent 做什么、什么时候需要拉人讨论。用户报了一个 bug，优秀工程师能判断修复路径、边界和风险，也知道该把哪些上下文交给 agent。很多软件工作卡在人的沟通循环里：有人说想要 X、Y、Z，团队来回确认，写计划，再开始做，再拿给用户看。
“品味就是知道什么时候需要来回沟通，什么时候不需要。”
有些 ping pong 很必要，能避免团队做错方向；有些只是因为没人敢下判断。**agent 让实现变快以后，判断哪些讨论可以省掉，会变成工程师的真实杠杆。**Logan 说他合作过的优秀工程师，往往很会回答这个问题。新手学习工具会有投入期，可能三个月，也可能六个月；但如果团队已经准备好上下文、权限和治理结构，上手速度会短到按天计算。
AI Studio 一天补齐上下文
Logan 给了一个很具体的内部经历。他和 AI Studio 工程团队说，希望用最少的人类设置，让 agent 拿到足够多的工程信息，能在 AI Studio 代码库里做改动。团队当天就搭好了一整套 skills，他运行一条命令，agent 就获得了接近团队工程师应该拥有的上下文。当天，Logan 已经能在 AI Studio 代码库里提交生产代码改动。
“我运行了一条命令，然后我的 agent 拥有了每个团队工程师都应该有的上下文。”
这个速度并不只靠模型聪明，还靠团队原来就有 agent rails、治理结构和适合接入 AI 工具的技术栈。Logan 也提到，他加入 Google 后本来减少了工程工作，因为 Google 内部基础设施和外部世界差异很大，学习曲线很陡。AI coding 把他重新带回真实生产代码改动里。**组织能否让新人或跨团队工程师迅速产生影响，取决于代码库给 agent 和人准备了多少可用上下文。**主持人补了一层组织视角：公司往往把跨团队的大改动交给最被信任的工程师。agent 时代如果能缩短“飞进团队、做完研究、开始改动”的时间，这种高级工程师的影响面会被继续放大。
代码库需要 agent coverage
主持人提出一个词：agent experience。一个工程师带着自己的工具栈进入某个团队，能多快熟悉代码库？repo 里哪些东西能帮助他尽快产出？Logan 顺着这个想法提出 agent coverage。过去团队会看 test coverage，衡量代码被测试覆盖了多少；现在也该问 agent 拥有多少上下文，能理解它正在操作的系统到什么程度。
“你需要同样的东西给 agent，就像代码测试覆盖率一样，那就是 agent coverage。”
这些上下文包括系统为什么这样建、工程师讨论过的设计取舍、UI 功能的 design review 会议记录、相关 chat thread。模型没有这些也能做出一些聪明动作，但给得越多，跑得越快。Logan 甚至说，这里值得有人去建一家公司。最好的系统还要持续更新上下文，因为软件每天在变。未来的 repo 不只存代码、测试和文档，还要存 agent 可以读取、验证、继承的工作记忆。
提交代码时别丢证据包
Antigravity 里 agent 生成的 artifact，让 Logan 看到另一个变化。agent 做完任务后，会留下计划、walkthrough、checklist，列出 50 件它做过的事、跑过的测试、检查过的路径。但代码一旦 commit，这些内容常常消失。评审者看到的还是 diff，而不是完整的工作过程。过去开发者的 proof of work 很简单：写出代码，通过 CI 里的测试。现在生成代码本身不再是最稀缺的部分，proof of work 也该变化。
“过去开发者的工作证明是写代码，并让 CI 的测试通过。现在工作证明已经不同了。”
主持人提到有人在尝试 spec-driven development，把 spec 也作为改动的一部分提交，让评审者检查过程和 guardrail。Logan 很喜欢这条路径，因为软件构建方式正在被重新试验。三年前，很多团队只是沿用公司既有流程；现在大家会试十种方法，看 spec、harness、artifact、review checklist 哪一种更能支撑 agent 工作。未来 PR 可能不只是一组代码差异，还会附带计划、约束、测试证据和 agent 的执行记录。
生成变简单，理解更值钱
对很多工程师，写代码本身也承载着手艺感。主持人说，有些人很享受 craft，代码生成正在拿走一部分满足感。Logan 的回应回到最早学软件的原因：他兴奋的地方是解决问题。计算机科学训练让人以系统方式看世界，就像学法律的人会用另一套结构理解社会规则。今天不再亲手敲每个字符，并不会削弱这种看世界的能力。
“你可以外包智能，但不能外包理解。”
Logan 还提醒，能力边界正在高速移动。每两周、三个月、六个月，可能做到的事都会变，人需要重置自己的雄心水平。主持人提到 I/O 展区里一个游戏 demo：人把想法写下来，经过几轮往返，游戏就跑出来了。Logan 说，人类最难的部分就是更新想象力。他把个人项目的门槛抬到“迷你公司”级别，因为过去缺时间、缺团队、工程能力不够的限制正在松动。
求职和作品集也会受影响。开源曾经是 permissionless 的 proof of work，年轻工程师可以不用先拿到实习机会，就去别人的代码库里做有意义的贡献。现在个人还可以直接构建完整项目，自己定义问题、叙事、产品和进入市场的方式。**但如果把真实用户放进一个自己并不理解的系统，风险也会一起放大。**Logan 最后那句很适合贴在工程团队墙上：你可以借模型处理智能密集的部分，但理解仍然要留在自己手里。
写在最后
这期对话给工程师的安慰不在于“岗位安全”，而在于价值还有地方可去。少敲一些代码以后，判断力、上下文组织、测试意识、评审能力和对系统的理解，会更像日常硬功夫。与其把 agent 当成替身，不如把它当成放大器，先把自己最想保留的那部分能力练得更清楚。
内容来源：“The New Rules of Software Engineering (Google DeepMind Lead)“丨Beyond Coding（嘉宾：Logan Kilpatrick）
原视频：https://www.youtube.com/watch?v=eljeO33Mk2M
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣
内容效果不满意？点此反馈