Ilya Razenshteyn发布Substack 文章

我访谈了大约二十几位研究员、工程师、研究/工程经理等，询问他们/他们的团队在工作中如何使用编程智能体。然后我加入了自己的观点和热门评论，写了一篇 Substack 文章（链接在下一条推文中，如果您订阅我会非常高兴；当然，这篇文章是免费的，以后的任何文章也都是免费的！）试图对比社交媒体上的炒作，还原软件工程/行业研究的真实现状。

总结（3. 和 4. 是最重要的！）：

1. 模型、框架、工作流：别在花哨的工作流上浪费时间，它们并不真正起作用。使用原生的 Claude Code / Codex（或者如果你是微软粉丝，使用带有 Claude / GPT 模型的 Copilot），或许在一些非常特殊的情况下使用子智能体。写一份设计文档，然后规划变更，然后实施，然后合并。清洗、冲洗、重复。不要被网上那些试图向你推销他们新框架或工作流这种万灵药的人所动摇。这些东西（一般来说）都不起作用。

2. 正确性/测试/阅读或不阅读代码：如果你做了以下三件事之一，不阅读代码是可以的。a) 一次性的东西/演示，你只需要在一个输入上运行。b) 可测试/可验证的东西，例如 GPU 内核。c) “方向正确”即可的东西（ML / 数据工作 / 研究代码）。在其他情况下，特别是如果你需要任何程度的可维护性/可靠性，或者你的代码是面向客户的，阅读代码仍然是必要的。阅读测试并引导模型编写更好的测试也是一个好主意。通常最好使用不同的模型来审查另一个模型编写的代码。即使你批准 PR 而不做任何更改，阅读仍然有助于未来更高效的提示。

3. 团队动态：如果我们不小心，智能体真的会破坏团队动态。两个最大的问题是“垃圾泛滥”，随着时间的推移，所有的 PR / 电子邮件 / Slack 消息最终都变成了难以阅读的垃圾，以及“过度建设”，我们正在构建和发布无用的东西以获得认可或作为一种拖延的形式。其他不太严重但仍然重要的问题包括：减少沟通、对想法保密、思维多样性下降、想法的模式崩溃、信任 LLM 胜过信任人。

4. 行动呼吁：我们真的需要小心维护团队合作和协作。我们仍然需要“组队猎猛犸象”，但随着编程智能体的出现，这变得越来越困难。总的来说，许多由智能体引起的问题源于短视的短期思维，比如“我们还有几年时间，直到我们的工作完全自动化，所以我可以尽可能多地提取价值，其他人都见鬼去吧”。虽然有些可以理解，但我认为抵制这些冲动很重要，哪怕只是为了你自己的理智。

[完全披露：直到两个月前，我还在 OpenAI 工作，我的工作直接为 Codex 做出了贡献，我是编程智能体的忠实粉丝。]