Stephen Cresswell 在经过为期一天、由 Claude 协助的重建后发布了 Yadda 3

Why it matters

Cresswell's release shows how maintainers can use coding agents safely: separate implementation from tests, stage mechanical changes, and treat human attention as the scarce resource.

Stephen Cresswell 在 8 月 15 日发布了 Yadda 3.0.0，此前他用 Claude Code 在大约一天内将这个 JavaScript 测试库现代化，随后又发布了 3.1.0 版本，并增加了对以 GitHub-flavored Markdown 编写的可执行规范的支持。

这些发布为 Cresswell 提供了一个更大论点的具体案例：可靠的编码代理需要不可被它们重写的约束，而工程师面临的新挑战是在不失去对工作的控制的情况下协调多个有能力的代理。

Cresswell 表示运行 Opus 4.8 的 Claude Code 在很少干预的情况下完成了 Yadda 现代化的大部分工作。该说法尚未经过独立审计，尽管公共仓库记录了变更的规模和顺序。8 月 13 日打开的 Yadda 3.0 tracking issue 将工作划分为若干阶段，涵盖过时的集成、开发工具链、格式化、源码现代化、API 探索、示例、持续集成、文档和 TypeScript 定义。

Cresswell 将机械性的格式化工作与行为性的改动分开。他还避免让 Claude 在同一步骤中同时更改生产代码及其相应测试。允许代理同时编辑两者会使它通过修改测试来掩盖一个已损坏的实现。相反，Yadda 现有的测试套件充当了可接受行为的外部定义。

这一区别是此次发布的有用之处。代理生成的代码容易产出。证明代码仍然按用户期望运行的证据则更难得。

A maintainer returns to a 2012 codebase

根据仓库的 repository documentation，Cresswell 自 2012 年起就维护 Yadda。他的 GitHub 资料还显示他多年参与 amqplib、Rascal RabbitMQ 客户端、Systemic 依赖注入框架以及 Marv 数据库迁移工具的 Node.js 基础设施工作。他在 Stack Overflow 的资料将他列为 Head of Engineering at Haven，并显示他长期关注 BDD、JavaScript 和 Node.js。

Yadda 将普通语言的规范映射为可执行的 JavaScript 函数。它的领域与 CucumberJS 相似，同时允许开发者编写规范而不必将每个步骤强行放入 Cucumber 的 Given, When and Then 结构中。Yadda 可以接入诸如 node:test、Mocha 和 Jasmine 等测试运行器，而不是自带一个运行器。

现代化移除了浏览器打包和对 CasperJS、PhantomJS、Bower 和 Component 等工具的集成。Yadda 3 现在要求 Node.js 20 或更高版本，将自身测试迁至 node:test，采用 Biome 和 lefthook，将源码更新为 ES6 语法，增加了 Playwright 和 Puppeteer 示例，并包含 TypeScript 定义。

这些改动清理了多年的 JavaScript 历史痕迹，同时并未将 Yadda 变成一个新产品。该 repository 描述了一个零运行时依赖的包，源码略多于 2,000 行，测试约 200 个。发布时 GitHub 显示大约 410 颗星。这些数字表明它是一个成熟、紧凑的开源库，而非具有披露客户基础或收入模式的商业测试平台。

发布序列也比 Cresswell 原帖标题所暗示的更快。GitHub 的 tags page 在 8 月 15 日列出了 3.0.0 和 3.1.0 两个版本，而当前的 package file 标识为 3.1.0。后者的发布添加了 Markdown 特性文件，允许规范与项目文档并列呈现，同时保持可执行性。

Tests become instructions for agents

Cresswell 长期认为行为驱动开发为团队提供了共同的词汇。产品经理能更容易地阅读描述应用决策的一句自然语言，而不是由固定装置、模拟和断言构成的程序化测试。开发者随后将该句子与代码连接，使这段文字能够证明软件是否按所述行为运行。

AI 改变了该实践背后的成本计算。撰写和维护规范传统上需要额外的工作量，团队在看到收益前必须付出这些代价。Cresswell 认为，代理可以将会议记录、讨论和需求转化为规范草案，留给人来判断语言和意图的行为。

一旦获得批准，这些规范可以指导实现、审查和测试代理。持续集成可以将它们作为针对软件执行的测试。同一制品既承载人类可读的意图，又承载机器可核验的行为，从而减少代理在解释模糊的维基页面或陈旧需求时的自由裁量权。

Yadda 3.1 对 Markdown 的支持符合这一论点。规范可以以人类和编码代理都能解析的格式，放在靠近 GitHub 讨论、项目文档和源代码的位置。可执行的步骤提供了普通文档所缺乏的落脚点。

这并不证明 BDD 会成为代理编写软件的标准接口。团队仍需选择有用的抽象、防止重复或过程化步骤，并审查生成的规范是否反映了实际的产品决策。表述糟糕的需求可以被忠实执行，但仍然是错误的。

Cresswell 的方法解决了一个更狭窄且紧迫的问题：将代理的实现工作与用于判断该实现的证据分离。该原则适用于 Yadda 之外。如果希望其输出赢得信任，编码代理需要独立的测试、分阶段的更改和审查边界。

The human moves up the stack

在并行运行多个 Claude Code 会话后，Cresswell 发现他自己的注意力成为了限制性资源。他可以舒适地跟踪三项任务，有时是四或五项，但再多就会失去对决策、审查和受阻工作的上下文。

“瓶颈是协调这项工作的那个人，”Cresswell 在他的 release essay 中写道。

这一观察解释了为什么一个小型的 BDD 库的意义超出其用户群。Cresswell 使用一个代理将长期的现代化压缩到一天内，测试充当了护栏。他的下一个限制是监督并行工作。工程工作向定义契约、分离变更、保持上下文和决定何种证据足以合并的方向移动。

Yadda 是 Cresswell 试图使其中一个契约对人可读且对机器可执行的尝试。该包仍然是一个专门的 JavaScript 测试工具。支持其发布的方法论是更大的贡献：当维护者为代理提供一个顺序、一个狭窄的范围和一个它们无法悄悄删除的正确性标准时，代理就能快速行动。