自去年11月以来，我一直在相当程度上使用AI，这整个过程都是一种有趣的体验。一个智能体会做一些事情，如果是人类来做的话，你马上就会解雇他们。当然，我的反应是表现得像这很棒，并迅速启动一千个智能体，让它们做更多这样的事情。在去年年中，我让GPT（可能是5.0或5.1）试图找出一个bug的来源。自然，这段代码没有测试，git bisect不起作用，而且这是一个UI交互bug，我甚至没资格为其编写测试，于是我让Codex在日期X和Y之间进行二分查找，以找到引入此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，而且还“在上游依赖项中，包括HTML规范、大三浏览器和其他开源项目”，所需努力相对较低。一般来说，当我与软件人员谈论测试时，我从如此不同的地方出发，他们立即用异样的眼光看着我，所以让我们谈谈我在Centaur这家硬件公司工作的测试经历，这些经历塑造了我对工作方式的偏见。我们做过的一些事情是或曾经不正统的。