技术负责人应该产生最多的AI代码痕迹

用AI耗尽量（令牌烧毁和代码行数）来衡量工程师是个坏主意。代码生成和代币消耗并不等同于影响力。员工工程师可以把大部分时间花在非编码活动上（润色愿景文档、审查复杂拉取请求、影响其他团队、指导他人），但影响力仍比写了两倍PR的工程师大。

在高输出管理安迪·格罗夫称之为杠杆。领导者的产出不仅仅体现在他们所产出的工作上，还直接体现在他们在整个组织中所能实现的成就。

格罗夫称培训是领导者能执行的最有杠杆效应的活动之一。

工程师资历越高，评估时更多基于同伴反馈及其领导或贡献的工作影响力，而较少基于有影响力的公关数量。历史上，这导致资历与直接技术产出呈反比。

随着工程师资历提升，人们期望他们能找到除编码以外的筹码。

但人工智能改变了我们的实践，我认为现在情况已不再如此。

没人知道怎么正确地和智能体一起编程

很长一段时间里，软件工程的实践足够稳定，高级工程师可以从主要编程中脱离，而不会完全脱离软件的制作过程。当然，语言、基础设施和框架时有变化，但基本原则依然成立。

人与软件的主要接口是IDE和终端。工程师设计系统、编写代码、审查拉取请求、测试、发布和构建CI/CD。

然而，现在我们已进入一个积极重新审理人类意图与软件界面的时期。使用编码代理构建尚无固定方法，技术领导者需要亲身体验新的生产方式。

以下是我个人正在努力解决的一些未解问题的非详尽清单：

关于代码审查：

• 工程师应该阅读所有代码吗？
• 我们是否应该主要复习测试和由此产生的行为？
• 依赖AI来解释代码变更可以吗？
• 一个AI代码审查够用吗，还是需要多个门？

关于情境管理：

• 包含什么AGENTS.md?
• 什么是有效的上下文窗口？
• 特工是否应该被允许自行调用技能？

关于代码库：

• LLM 应该维护代码库的维基吗？
• Markdown 计划应该存储在仓库里吗？
• 代码库的策划和组织仍然重要吗？

关于自治：

• 我们应该让客服作为副驾驶，还是让他们单独工作？
• 我们应该采用以规格为驱动的开发吗？
• 代理应该有自己的身份，或者代表用户行动吗？
• 客服应该专注于编码，还是应该连接到像GitHub和Jira这样的外部服务？

与此同时，每天都有新工具出现。以下是我一直在尝试的一些工具类别（同样不是穷尽的）：

界面：

• 航站楼
• 终端复用器
• 代理图形界面
• 差分观察器
• 文物观察器

代理代表团：

• 安全带
• 插件
• 技能包
• 编曲者
• 任务管理器

安全：

• 沙盒
• 工具使用前的钩子
• 凭证库
• 凭证代理

我认为我们离构建生产软件的标准方法还远未达成一致。这些问题无法通过工程原理的推理来回答。它们是实证问题。

你必须让代理与真实代码库对抗，并找到方法让它们失败。你必须建立你偏好的代码栈，构建自己的定制工具，并准备好抛弃一切，三个月后重新开始。

否则，你无法形成一个智能的立场。二手报告、演示或文章是不够的。

资历排序应该能产生更多排气

工程师使用编码代理完成任务。技术领导者现在承担更广泛的任务：寻找有效方法来集体利用编码代理。

代理在哪些方面表现良好？哪些地方存在缺陷？他们需要什么上下文？人类应该审查哪些内容？哪些控制应是确定性的？哪些应在团队内部统一标准化，哪些应留给各个工程师负责？

要影响这些决策，你需要大量第一手经验。员工和首席工程师应该进行实验，尝试新工具，并全力推动模型面对真实问题。这必然会留下大量AI废气的痕迹：烧毁的代币、代码行、失败的原型和被遗弃的分支。

以下是我通过实验得出的一些结论：

• 关于上下文窗口：即使是最强大的模型，如Fable和Sol，也仍然会犯很多错误并忽视指令。这种情况在较长的上下文窗口中尤为明显。因此，我得出结论：代理有一个有效的上下文窗口。我仍然不确定那是什么，我怀疑它并不是一个硬性数字，而是很大程度上取决于任务本身。尽管如此，我现在将上下文窗口限制在50%，超过20%后会触发警告。
• 关于自治：现在的模型非常代理化。他们会提交PR，推送到主平台，还会构建你没要求的功能。当代理说明含糊不清时，这一点尤其明显。我最近删除了整个模型栈，从零开始时才发现这一点。我清除了所有技能和AGENTS.md我停止使用我的规范驱动开发（SDD）框架。我现在正在用指令护栏和确定性钩子和工作流重建我的框架。明确的任务前期能减少意外，让代理更可预测。
• 关于代码审查：人工审核代码仍然很有价值。当规范或说明没有具体说明决策时，代理常常会填补空白，这常常导致过度设计的解决方案、你没要求的测试，甚至是糟糕的代码。他们通常也不会告诉你，除非你主动询问。你可能根本不会问，因为你一开始忘了把代码写进规范里。如果某件事很关键，发布PR前扫描代码绝对是必要的。人工代理之间的理解正在发生大量创新，我也在密切关注这个领域。
• 关于维护代码库：代理使用 grep 来构建代码库的上下文。如果你的代码库不可被 grepp，代理将难以加载完成任务所需的所有上下文。代码库是可被 grepp 的，当一个懂得领域词的代理可以通过搜索找到一个概念及其配线，而无需阅读整个文件。我经常让代理根据“名字意味着其字面意思”、“副作用有明显的所有者”和“目录有单一状态责任”等原则来审计我的代码库。我不存储 Markdown 文件（比如spec.md因为这些文件最终会被 grep 发现，然后加载不需要的上下文。
• 关于AI评测：代理在首次实现规范时会引入漏洞。让独立的QA代理门实现能有效发现漏洞。来自不同型号系列的QA代理通常能产出更好的结果。但QA代理往往吹毛求疵，所以仍然需要人工门槛来限制修复问题，否则代理会过于苛刻，引入不必要的“纵深防御”。

需要注意的是，我通过自己做一些个人项目得出了很多结论。在我的专业工作中，我对经纪人管得很严，因为我拥有的很多东西都很关键。

AI的排气并不是贡献

高代币消耗本身并不能证明任何东西，也绝不应成为性能目标。我想说的是，严肃的实验会产生明显的疲惫。如果你在测试前沿模型、构建工具束、比较工作流程、研究代理失败，并推动代理面对难题，你会消耗代币并生成代码。

高AI耗尽并不证明某人是技术领导者，但那些制定技术方向的人低AI耗尽度应当引发质疑。

过去，高级工程师可以依赖委派来建立组织影响力，因为其底层实践已被充分理解。而在当今世界，实践本身就是被设计的东西。因此，委派实验意味着委托出你自己判断的来源。

一个新的错误是认为资历意味着你不再需要那么多与软件制造过程的直接接触。也许我们的实践会趋于稳定，这也可能再次成立。