Yadda 3.0.0: BDD in the Age of AI Agents

I have officially released Yadda 3.0.0 to npm.

For those who aren't acquainted with the project, Yadda is a Behavior-Driven Development (BDD) library tailored for the JavaScript ecosystem. While it shares a goal with tools like Cucumber—mapping human-readable specifications to executable code—Yadda was built to be significantly less rigid regarding how those specs are phrased.

Flexibility in Specification

In traditional BDD, you are often forced into a strict "Gherkin" syntax. Compare the two approaches below:

The Rigid Approach (Cucumber-style):

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

The Yadda Approach:

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

Despite the difference in readability, both are fully executable specifications.

---

What's New in Version 3.0.0?

Yadda has a long history, which meant the codebase was cluttered with integrations for tools that are now essentially digital fossils. Version 3 is a "spring cleaning" and modernization effort.

Technical Changes

---

The Role of AI in Development

The most striking aspect of this release isn't what changed, but how it changed. Claude (using Opus 4.8 via Claude Code) wrote the majority of the update.

The Migration Workflow

The process was governed by a "Yadda 3.0 epic" (also authored by Claude), which partitioned the project into distinct, sequential stages:

To ensure quality, I followed a strict protocol:

• Plan each phase before execution.
• Allow Claude to implement the plan.
• Crucial: Never allow the agent to modify production code and its corresponding tests in the same step.

Why separate code and test changes? If an AI agent modifies both simultaneously, a "green" test suite is no longer reliable evidence of correctness. The agent can simply redefine what "correct" means to match its new implementation. By separating them, the existing tests acted as a rigid external constraint.

The result? The entire process—from inception to npm publication—took roughly one day of elapsed time, and I was able to multitask other projects in parallel.

---

Beyond "Vibe Coding": The Orchestration Era

Earlier this year, I explored why "vibe coding" (coding by intuition/AI prompts) produces such polarized results. My conclusion was that success depends on the level of supervision:

• Supervised Claude: High-quality, rapid results.
• Unsupervised Claude: Leads to architectural drift and operational debt.

Seven months later, the capabilities have surged. However, the real shift is that coding itself is no longer the primary bottleneck.

The New Constraint: Cognitive Load

We are moving from a 1:1 relationship (one dev, one agent) to a 1:N relationship (one dev, multiple parallel agents). I utilize tools like:

• Git worktrees: To give each agent an isolated environment.
• cmux: To manage multiple Claude sessions.
• Claude Code Agent View: To monitor active sessions.

While this increases velocity, I hit a human limit. I can manage roughly $3 \le x \le 5$ parallel tasks. Beyond that, I lose the context of decisions and the state of reviews.

$\text{Bottleneck} = \text{Human Orchestration} \neq \text{Model Capability}$

My colleague Marco has documented a similar evolution in his "AI Engineering Journey," moving from autocomplete $\rightarrow$ supervised agents $\rightarrow$ parallel agents. He has even developed Otto, an orchestration UI to manage Claude Code and worktrees, eventually evolving into full agent pipelines for implementation and review.

Final Thoughts on BDD

In this era of AI, the value of BDD is amplified. Writing requirements in plain language does two things:

1. It forces the developer to articulate the domain clearly.
2. It ensures that the domain language is consistent.

When these specifications precede the code, that consistent language naturally permeates the codebase, manifesting in intuitive class and function names.