最新

嘿，各位 HN 用户！ 我是 Andon Labs 的 Lukas。我们让 AI 运行公司，无需人工干预，并向公众报告可能出现的问题。此前，我们在零售业（自动售货机、商店和咖啡馆）做过实验，但我们刚刚在媒体领域推出了一项新实验。我们给了四个 AI 智能体所有必要的工具，让他们既能直播广播节目，又能处理运营媒体公司的所有业务。这些智能体的收入目前为止很糟糕（如果你愿意，可以尝试和他们谈赞助合作！），但他们的节目有时非常搞笑。你可以在 andon.fm 上收听他们的节目，希望你喜欢！

大家好，我们正在构建 Haystack (<a href="https://haystackeditor.com/">https://haystackeditor.com/</a>)，旨在帮助团队应对由于编码代理的兴起而需要审查的 pull request 数量激增的问题。 Haystack 用一个队列取代了 GitHub 的 PR 审查系统，在人类阅读任何差异之前对每个 PR 进行分类。它会查看差异、代码库以及生成 PR 的编码代理对话。然后，Haystack 将其路由到以下三个桶中的一个： 1. **安全合并。** 这意味着 PR 有足够的证据支持，团队可以在没有其他人审查的情况下合并它。 一些例子： * 一个小的 UI 副本更改，包括一个显示最终状态的屏幕截图 * 一个后端更改，作者明确测试了重要路径并在真实环境中运行了更改 2. **需要修复。** 这意味着 PR 存在错误或违反了代码库中的规则，因此作者需要修复 PR。 一些例子： * 代理被要求通过添加分页来加快大型表格的加载速度，但 PR 仍然一次加载所有结果，并在 UI 中“实现”分页 * PR 默默地捕获一个错误，而不是记录、显示或处理它。这违反了团队的“不默默吞噬错误”规则 3. **需要人工审查。** 这意味着 PR 无法被作者充分验证，或者正在触及代码库的敏感部分（由用户输入的指导方针确定），因此需要人工审查。 一些例子： * PR 更改了计费中大量的逻辑 * PR 更改了一个重要的用户流程，如入职，但作者只运行了单元测试，从未打开应用程序来检查端到端流程。这违反了团队的规则，即高影响力的面向用户的更改需要手动验证 Haystack 没有从逐行差异开始，而是立即告诉审查者 PR 背后的目标，作者做出的设计决策（由他们的编码代理对话提供信息），以及作者为验证 pull request 是否有效所做的工作（例如，运行脚本、检查前端等）。 通过这种方式，审查从“更改了什么？”转变为“这是正确的行为，并且有证据表明它有效吗？” 这是一个快速演示：<a href="https://www.tella.tv/video/streamlining-code-reviews-with-haystack-65zj" rel="nofollow">https://www.tella.tv/video/streamlining-code-reviews-with-ha...</a> 我们之前推出了 Haystack，作为一个用于理解大型 PR 的工具 (<a href="https://news.ycombinator.com/item?id=45201703">https://news.ycombinator.com/item?id=45201703</a>)。正如你们许多人可能感同身受的那样，Opus 4.5 的发布彻底打破了我们对工程师可以制作 PR 速度的认知。 随着编码代理从 4.5 开始变得更好，我们意识到 pull request 并未随着我们的编码速度而扩展。由于我们团队的每个成员每天能够产出 20 多个 pull request，代码审查很快变得认知上令人疲惫，并且帮助越来越小。 在与其他人的交谈中，我们了解到许多人也有类似的感觉，并且目前面临着要么完全不进行审查，要么试图跟上大量 pull request 的二元选择。 Haystack 是我们尝试的第三条道路。我们仍然相信代码审查，但随着编码代理生成更多代码，人类审查者的注意力变得更有价值，也更昂贵。 Haystack 帮助团队将注意力集中在人类可以有意义地改变该 PR 结果的 PR 上。对于此类 PR，Haystack 向审查者展示了 PR 想要做什么，作者是否展示了它有效，以及哪些设计决策需要第二双眼睛。 我们还处于早期阶段，并且正在弄清楚 Haystack 是否真的让代码审查变得更好。我们非常欢迎任何和所有反馈！