Yadda 3.0.0: BDD in the Age of AI Agents | Signal Over Noise

Yadda 3.0.0: BDD in the Age of AI Agents<br>I’ve just published Yadda 3.0.0 to npm.

For anyone unfamiliar with it, Yadda is a BDD library for JavaScript. Like Cucumber, it maps ordinary language specifications to executable code, but it was designed from the ground up to be much less prescriptive about how those specifications are written.

That means that instead of writing something like:

Given a university, The University of Bouvet Island<br>And The University of Bouvet Island offers a degree course in Computer Science with entry requirements of ABB<br>And an A-Level graduate, Steve<br>And Steve has a D in Physics<br>And Steve has a D in Maths<br>When Steve applies to study Computer Science at The University of Bouvet Island<br>Then The University of Bouvet Island rejects the application

you can write:

The University of Bouvet Island offers a degree course in Computer Science<br>The entry requirements for which are ABB<br>Steve is an A-Level graduate<br>With a D in Physics<br>And a D in Maths<br>When Steve applies to study Computer Science at The University of Bouvet Island<br>They reject his application

Both are executable specifications. I find the second considerably easier to read.

What’s changed in Yadda 3?

Most of Yadda 3.0 is a modernisation exercise.

Yadda has been around for a long time, and the repository had accumulated integrations and tooling for parts of the JavaScript ecosystem that are now themselves historical curiosities. Yadda 3 is Node-only, removes browser bundling and obsolete integrations such as CasperJS, PhantomJS, Bower and Component, moves the test suite to node:test, adopts Biome and lefthook, modernises the source to ES6 syntax, and adds current examples including Playwright and Puppeteer. It also now ships TypeScript definitions.

All useful, but not especially interesting to write about. There are two things about the release that I think are much more significant.

Claude wrote most of it

I modernised Yadda using Claude Code with Opus 4.8.

The Yadda 3.0 epic, which was itself written by Claude, broke the work into a series of deliberately separated phases: remove obsolete functionality, update the toolchain, perform mechanical formatting separately from behavioural changes, modernise the source, explore API changes, update examples and CI, then finish the metadata, documentation and TypeScript definitions.

We planned each phase before implementing it, and then I largely let Claude get on with the work. It made remarkably few mistakes and, more impressively, identified some fairly subtle edge cases that would have been easy to miss during what initially looked like a mechanical modernisation. I made very few interventions.

One important factor was that Yadda already had a comprehensive test suite. I also deliberately avoided asking Claude to modify production code and the corresponding tests in the same step. If an agent changes both simultaneously, a green test suite becomes weaker evidence because it is free to change the definition of “correct” at the same time as the implementation. Keeping those changes separate gave Claude a much firmer external constraint.

From starting the work to having the package published was roughly a day of elapsed time, and I was doing other things in parallel.

At the beginning of this year I wrote about an experiment asking why experiences of vibe coding were so polarised. My conclusion then was that the results depended enormously on how the agent was used. A tightly constrained and supervised Claude could produce extremely good results very quickly. Left to its own devices, it tended towards architectural drift, unnecessary code and operational debt.

That was only seven months ago, and the capability has moved on enormously. Even so, saying that Claude can now write this code with very little intervention barely scratches the surface of what is changing.

Coding is no longer the bottleneck

To appreciate where this is going, it helps to stop thinking about a single developer having a conversation with a single coding agent and instead consider several agents working in parallel.

There are already several ways to do this. You can simply run multiple Claude Code sessions. Git worktrees let each agent work against an isolated working copy. Tools such as cmux make running a collection of Claude sessions more manageable, while Claude Code Agent View provides another way of seeing what multiple sessions are doing and which ones need attention.

All of these let you build significantly faster than working serially, but I fairly quickly hit another limit: my own ability to manage the parallel work. I can comfortably keep three tasks moving at once, and sometimes four or five. Beyond that, I start losing the context of what each agent is doing, which decisions have been made, which task is waiting for me and what I need to review next.

At that point, the model is not overloaded and the machine is not...