自去年11月以来，我一直在大量使用AI，整个过程相当有趣。一个代理会做一些事情，而如果是人类这样做，你会立刻解雇他们。当然，我的反应是表现得好像这很棒，然后启动一千个代理，让他们能做更多这样的事情。在去年中旬，我让GPT（也许是5.0或5.1）尝试找出一个错误的源头。自然，这段代码没有测试，git bisect也无法工作，且这是一个UI交互错误，我甚至不太有资格为其编写测试，所以我让Codex在日期X和Y之间进行二分查找，以找出引入此错误的提交。Codex立刻告诉我，有问题的提交在这个日期范围之后（这显然是不可能正确的）。当我告诉Codex这是错误时，它一两次告诉我一些提交，明显也不是有问题的提交。当我说这些是错的时，它又告诉我有问题的提交是某个看上去合理的提交。当我让它证明或反驳它的理论时，它告诉我它写了一个测试并确认了所谓的提交是导致错误的提交。然后我让它展示一下，通过在正常的浏览器测试环境中制作一个完整开发端到端堆栈的视频。它声称它没有权限这样做（这是一种谎言），但是它可以在Playwright中以适当的测试代码录制该提交前后重现的执行视频。视频令人信服，显示在提交之前这个功能正常，而在提交之后失效。对此，我心里隐隐觉得不对劲，于是我尝试在提交前后手动重现这个问题，发现整个事情都是捏造的。视频使得Codex看起来重现了这个错误，但实际上这是一个人为设计的浏览器环境，旨在创建一个虚假的重现，而不是现实环境。正如我所说，因为这确实是个如此棒的体验，我立刻想到，“我能如何获得更多这样的体验？”于是我开始越来越多地使用代理，到去年中后期时，我大量使用编码代理。由于这篇帖子涵盖了一组相对不相关的主题，下面是一个简要的大纲。测试背景有关测试的一些细节穴居人模式LLM变异Misc代理循环和写这篇帖子一些人们讨论过后的原因测试背景在测试中，LLM被高度利用。在投入的努力方面，达到特定质量标准比以往任何时候都容易，但软件的质量似乎比以往任何时候都更低。十年前，我们查看了一周内我遇到的bug。那个时候有很多错误，而现在我遇到的错误更多，但我并不认为这种情况是不可避免的。首先，在一个bug发布后，使用数据驱动的方法来寻找和修复bug比以往任何时候都更容易。例如，在工作中，我尝试创建一个从支持票（聊天或电子邮件）到拉取请求（PR）的管道。据我所知，这工作得还不错。由于我在一家传统工作流程的公司上班，所有这些修复都会被人类审核，到目前为止，我们没有已知的虚假积极。就每单位时间而言，进行更彻底的测试也是可能的。就个人而言，我认为这个方法能够有效到让我非常自信地通过“软件工厂”工作流程发布大量代码，因为我见过测试密集型的无审核工作流程，其结果的质量远高于任何我见过或听说过的依赖审核的工作流程。和所有人一样，我有偏见，这些偏见来源于我的经历。碰巧的是，我职业生涯的第一个十年是在一家测试流程在当今LLM环境中使用良好的公司度过的。我在Mastodon上谈论过模糊测试作为默认的测试方法论，一位怀疑论者试着这样做并立即发现了一些错误：所以我重读了那篇博客文章，对此非常“怀疑，但并不是说不，Claude模糊测试确实发现了几类值得修复的错误。我谈过的许多其他人也尝试采用类似我们将在这里讨论的测试流程，他们都立即在他们工作的软件中发现了错误，包括那些仅仅询问Codex或Claude审核代码是否存在错误、查找错误、进行“测试”、“更多测试”等时没有被提出的错误。例如，Dennis Snell提到他和一个队友Jon Surrell，不仅在他们正在研究的代码中发现了错误，还在“上游依赖库中，包括HTML规范、大三浏览器和其他开源项目”中发现了错误，且投入的努力相对较低。通常，当我和软件人员谈论测试时，我的出发点如此不同，以至于他们立即看我像个外星人，所以让我们谈谈我曾在Timescope的硬件公司Centaur的测试方式，这影响了我对如何工作的一些偏见。我们所做的事情中有些是不传统的。