如果你要求一个模型去解决一个复杂的问题，它可能会完成其中的一部分，但最终会停下来等待进一步的输入——比如一个问题、一个状态更新信息，或者需要进一步说明的请求。
当一个代理想要开始执行某项任务时，它会在
current_tasks/目录下生成一个文本文件来“锁定”这项任务。如果有多个代理试图同时处理同一项任务，Git的同步机制会强制其中一个代理选择另一个任务。
在大多数情况下，Claude会自动选择“下一个最明显需要处理的问题”。当遇到无法解决的bug时，它通常会记录下所有已经尝试过的解决方法以及尚未完成的任务。
多个代理程序同时遇到同一错误，从而导致各自生成的修复代码相互覆盖，这一问题十分严重，尤其在Linux内核中表现得尤为明显。为了解决这个问题，Carlini利用GCC作为编译工具：每个代理程序使用GCC来编译内核代码中的某个随机子集，而Claude的编译器则负责处理剩余的部分，并且只针对那个被选中的子集来优化输出结果。
经过两周的时间以及大约2万美元的开发成本，最终开发出了一个包含10万行代码的编译器。这个编译器能够通过GCC设定的99%的测试用例，而且能够编译FFmpeg、Redis、PostgreSQL、QEMU等程序，甚至还能运行Doom游戏。
Carlini的这一尝试在网络上引发了广泛的讨论，人们的反应从积极支持到持怀疑态度不等，同时也引发了关于这项技术在实际应用和哲学层面的更多探讨。
X平台用户@chatgpt21指出，虽然这确实是一项了不起的成就，但仍然需要人类工程师不断重新设计测试用例，当各个代理程序相互干扰导致开发工作出错时还要搭建持续集成管道，而当所有16个代理程序都陷入同一个错误中时更得想办法解决这些问题。
另一方面，@hryz3强调这些代理程序是“根据被要求复现的同一段代码进行训练”的。更讽刺的是，@TomFrankly还写道：
他们花了2万美元购买代币，结果只是生成了一些存在于训练数据中的代码而已，这些代码本来就是他们用来进行训练的吧？
微软的Steve Sinofsky进一步对“Claude在两周内完成了人类工程师需要37年才能完成的工作”这一说法进行了说明，他指出：
GCC的开发过程并没有花费37年时间。早在1987年，它就已经能够满足当时语言发展的需求了。在之后的37年里，GCC随着语言、平台、库以及优化和调试技术的发展而不断进化。
@WebReflection还指出了这场讨论中的另一个有趣角度，他问道：
在这段开发过程中，究竟有多少开源贡献被纳入了最终的产品中？因为如果不对那些为这些项目做出贡献的开源代码进行回馈，未来就再也没有专家的代码可以作为参考了。
@RituWithAI总结了这一现象可能对软件开发领域产生的影响：
我们正在进入这样一个时代：对于一个能力出众的开发者来说，最重要的能力不再是解决复杂错误的能力，而是设计自动化测试工具和反馈机制的能力——这样就可以让16个并行运行的程序实例来帮助自己解决问题。
最后需要指出的是，卡林尼本人也暗示过，能够如此轻松地生成代码所带来的潜在风险，以及人们需要采取“新的策略”才能在这个环境中安全地行事。