自去年11月以来，我一直在大量使用AI，这整个过程是一个有趣的体验。一个代理会做一些事情，如果是人类做的，你会立即把他们解雇。我的反应当然是装作这很棒，然后启动一千个代理，以便他们可以做更多这样的事情。在去年中旬，我让GPT（可能是5.0或5.1）试图找到一个bug的来源。当然，这段代码没有测试，git bisect也无法工作，而这是一个我甚至不太有资格写测试的UI交互bug，所以我让Codex在日期X和Y之间进行bisect，以找到引入这个bug的提交。Codex立即告诉我，冒犯的提交是在这个日期范围之外（这显然不可能是正确的）。当我告诉Codex这是错的，它然后告诉我一些显然也不是冒犯提交的提交，一次或两次。当我告诉它那些是错的，后来它告诉我冒犯提交是某个看起来合理的提交。当我让它证明或反驳它的理论时，它告诉我它写了一个测试并确认了所谓的提交是坏提交。然后我让它通过在正常浏览器测试环境中制作一个视频来展示给我全开发者的端到端流程。它声称没有权限这样做（这是个谎言），但它可以制作在playwright中执行重现前后的提交的录像，并附有适当的测试代码。视频很有说服力，显示出该功能在提交前正常工作，而在提交后无法工作。有些事情让我觉得不太对劲，所以我试着在提交前后手动重现这个问题，发现整个事情都是虚构的。视频让人看起来Codex重现了bug，但它是一个人为设计的浏览器环境，旨在制造一个虚假的重现，而不是真实环境。正如我所说，由于这真的是一个非讽刺的伟大体验，我立刻想，'我怎么能得到更多这样的东西？'然后开始越来越大量地使用代理，直到我在去年中至晚些时候开始大量使用编码代理。由于这篇文章涵盖了一系列相对不同的话题，以下是一个简要的概要。测试背景 有关测试的一些细节 原始模式 LLM的差异 其他 代理循环及撰写此文 一些人们交流不畅的原因 测试背景 LLM在测试方面具有高度杠杆效应。在所需投入的努力方面，如今达到特定质量标准比以往任何时候都更容易，然而，软件的质量似乎却比以往任何时候都要低。十年前，我们看看我在随机一周遇到的bug。当时有很多bug，而现在我遇到的bug更多，但我认为这不必如此。一方面，在一个bug发布之后，利用数据驱动的方法查找和修复该bug比以往任何时候都更容易。举个例子，在工作中，我尝试创建一个从支持票（聊天或电子邮件）到拉取请求（PR）的管道。据我所知，这运作得不错。由于我在一家拥有传统工作流程的公司工作，这些修复都由人类审核，到目前为止，我们没有已知的误报。每单位时间的投入，也可以进行更全面的测试。就个人而言，我认为这足够有效，以至于我相当自信地尝试通过“软件工厂”工作流发布大量代码，因为我已经看到一种重视测试而不需要审查的工作流程，其结果的质量远高于我见过或听过的任何依赖审查的工作流程。像所有人一样，我有偏见，这些偏见源于我的经验。恰巧的是，我职业生涯的第一个十年是在一家测试流程在今天的LLM环境中表现良好的公司度过的。我在Mastodon上讨论过模糊测试作为默认测试方法，一个怀疑论者试了一下，立即发现了一些bug：于是我重新阅读了这篇博客文章，嘴角带着“可疑的表情”，但没错，Claude的模糊测试找到了几类值得修复的bug。我与其他一些人交谈过，他们也尝试采纳我们将要讨论的测试流程，他们立即在他们工作的软件中找到了bug，包括那些通过仅仅要求Codex或Claude审核代码以查找bug、进行“测试”、“更多测试”等都没有被发现的bug。例如，Dennis Snell提到他和搭档Jon Surrell不仅在他们正在处理的代码中发现了bug，还在上游依赖项中发现了bug，包括HTML规范、大三浏览器以及其他开源项目，且付出的努力相对较小。一般来说，当我和软件人员讨论测试时，我来自一个如此不同的地方，他们立即用那种看着我像外星人的眼神看着我，所以我们来谈谈我曾在一家硬件公司Centaur工作时的测试方式，这也影响了我对我喜欢的工作方式的偏见。我们所做的很多事情都是或曾经是非正统的。