用人工智能产出（代币消耗和代码行数）来衡量工程师的表现是个坏主意。生成的代码和消耗的代币并不能等同于影响力。一名员工工程师可能大部分时间都在非编码活动上（润色愿景文档、审查复杂的拉取请求、影响其他团队、辅导他人），而仍然能比一位撰写了双倍数量拉取请求的工程师产生更大的影响。在《高产出管理》中，安迪·格罗夫将其描述为杠杆效应。领导者的产出不仅限于他们直接产生的工作，还延伸到他们所赋能的整个组织。格罗夫称培训是领导者可以进行的最高杠杆活动之一。随着工程师的资历提升，他们的评估更多地基于同行反馈以及他们所主导或参与工作的实际影响，而不是所产生的有影响力拉取请求的数量。从历史上看，这在资历与直接技术产出之间创造了反向关系。随着工程师变得越来越资深，他们被期待在编码之外找到杠杆。但人工智能已经改变了我们的实践，我认为这种情况不再成立。没有人知道与智能体编程的正确方法。长期以来，软件工程的实践稳定到足以让高级工程师可以不再主要进行编码而仍然与软件的制作保持一定联系。当然，语言、基础设施和框架时不时会发生变化，但基本原则仍然成立。人类与软件之间的主要接口是集成开发环境（IDE）和终端。工程师设计系统、编写代码、审查拉取请求、测试、发布，并构建CI/CD。然而现在，我们进入了一个积极重新审视人类意图与软件之间接口的时期。没有已定的方式来与编码代理构建，技术领导者需要对新的生产方式有直接经验。以下是一些我个人正在思考的开放性问题（不详尽）：关于代码审查：工程师是否应该阅读所有代码？我们是否应该主要审查测试和结果行为？依赖人工智能解释代码更改是否可以？一次AI代码审查是否足够，还是我们需要多个检查点？关于上下文管理：AGENTS.md中应包含什么？什么是有效的上下文窗口？代理是否允许自行调用技能？关于代码库：大型语言模型（LLM）是否应该维护代码库的维基？Markdown计划是否应该存储在库中？代码库的策划和组织仍然重要吗？关于自主性：我们是否应该与代理作为副驾驶合作，还是让它们独立工作？我们是否应该采用规格驱动开发？代理是否应该有自己的身份，还是代表用户行动？代理是否应专注于编码，还是连接到像GitHub和Jira这样的外部服务？与此同时，每天都有新工具出现。这里有一些工具类别（同样，不详尽），我一直在尝试：用户界面：终端、终端复用器、代理图形用户界面、差异查看器、工件查看器；代理委派：工具、插件、技能包、协调器、任务管理器；安全性：沙盒、使用前钩子、凭证库、凭证代理。我认为我们还未达成一致的生产软件构建标准。这些问题无法通过工程原则推理得到答案。它们是经验性问题。你必须针对真实的代码库运行代理，找出让它们失败的方法。你必须建立自己首选的技术栈，构建自己的定制工具，并准备好三个月后将这些全部抛弃、重新开始。否则，你无法发展出明智的立场。二手报告、演示或文章都不足以支撑。资历应该产生更多的产出。一名工程师使用编码代理来完成任务。技术领导者现在有了更广泛的任务：寻找有效的方式去集体利用编码代理。代理表现良好的地方在哪里？它们在哪些方面失败？它们需要什么上下文？人类应该审查哪些内容？哪些控制应该是确定性的？团队中应该标准化什么，应该留给各个工程师做什么？要影响这些决策，你需要大量的第一手经验。员工和首席工程师应该进行实验，尝试新工具，并在真实问题上最大限度地推动模型。这不可避免地会留下可观的人工智能产出痕迹：消耗的代币、代码行数、失败的原型和被放弃的分支。通过实验，我得出了一些结论：关于上下文窗口：即使是最强大的模型，如Fable和Sol，仍然会犯很多错误并忽略指令。这在较长的上下文窗口中尤为明显。因此，我得出了代理具有有效上下文窗口的结论。我仍然不确定这是什么，我怀疑它不是一个固定数字，而是极大程度上取决于任务。尽管如此，我现在将我的上下文窗口限制在50%，在超过20%后会触发警告。关于自主性：