Yadda 3.0.0: AIエージェント時代のBDD
原題: Yadda 3.0.0: BDD in the Age of AI Agents
日本語訳
# タイトル
Yadda 3.0.0: AIエージェント時代のBDD
# 本文
Yadda 3.0.0: AIエージェント時代のBDD
npmにYadda 3.0.0を公開しました。
Yaddaを知らない方のために説明すると、YaddaはJavaScript用のBDD（振る舞い駆動開発）ライブラリです。Cucumberと同様に、自然言語による仕様を実行可能なコードにマッピングしますが、その仕様の書き方に対して、最初から非常に柔軟（非拘束的）に設計されています。
つまり、次のような書き方をする代わりに：
もしブーベ島大学という大学があり、
その大学が、入学条件がABBであるコンピュータサイエンスの学位コースを提供しており、
Aレベルの卒業生であるスティーブがいて、
スティーブが物理でDを取り、
数学でもDを取っているとき、
スティーブがブーベ島大学のコンピュータサイエンスへの入学を申請したら、
ブーベ島大学は彼の申請を却下する。
次のように書くことができます：
ブーベ島大学はコンピュータサイエンスの学位コースを提供している。
その入学条件はABBである。
スティーブはAレベルの卒業生である。
物理はD、
数学もDである。
スティーブがブーベ島大学のコンピュータサイエンスへの入学を申請すると、
大学は彼の申請を却下する。
どちらも実行可能な仕様ですが、後者の方が格段に読みやすいと感じます。
### Yadda 3で何が変わったのか？
Yadda 3.0の大部分は、近代化のための作業です。
Yaddaは長い歴史があり、リポジトリには現在では歴史的な遺物となっているJavaScriptエコシステムの統合機能やツールが蓄積されていました。Yadda 3はNode専用となり、ブラウザ向けのバンドルや、CasperJS、PhantomJS、Bower、Componentといった廃止された統合機能を削除しました。また、テストスイートを`node:test`に移行し、Biomeとlefthookを採用、ソースコードをES6構文に近代化し、PlaywrightやPuppeteerを含む最新の例を追加しました。さらに、TypeScriptの型定義も同梱されています。
これらはすべて有用ですが、記事として書くほど面白いことではありません。今回のリリースにおいて、より重要な点が2つあります。
### Claudeがほとんどを書きました
私はClaude Code（Opus 4.8を使用）を使ってYaddaを近代化しました。
Claude自身が作成した「Yadda 3.0エピック（大規模タスク）」では、作業を意図的に分離された一連のフェーズに分割しました。まず廃止された機能を削除し、次にツールチェーンを更新し、次に振る舞いの変更とは別に機械的なフォーマット変更を行い、ソースの近代化、API変更の検討、例とCIの更新、最後にメタデータ、ドキュメント、TypeScriptの型定義を仕上げる、という流れです。
各フェーズを実装前に計画し、その後は主にClaudeに作業を任せました。Claudeは驚くほどミスが少なく、さらに印象的だったのは、一見すると機械的な近代化作業の中で見落としがちな、かなり微妙なエッジケースをいくつか特定したことです。私の介入はほとんどありませんでした。
重要な要因の一つは、Yaddaにはすでに包括的なテストスイートがあったことです。また、Claudeに対して「プロダクションコードとそれに対応するテストを同じステップで修正する」という指示を意図的に避けました。エージェントが両方を同時に変更してしまうと、実装と同時に「正しさ」の定義まで変更できてしまうため、テストがパス（グリーン）しても、その証拠としての信頼性が弱まってしまうからです。これらの変更を分離して行うことで、Claudeに対して非常に強固な外部制約を与えることができました。
作業開始からパッケージの公開まで、実時間は約1日でした。その間、私は他の作業を並行して進めていました。
今年の初め、私は「なぜ『バイブ・コーディング（vibe coding）』の体験はこれほどまでに二極化するのか」という実験について書きました。当時の私の結論は、結果はエージェントの使いかたに大きく依存するということでした。厳格に制約され、監督されたClaudeは、非常に優れた結果を極めて迅速に生み出すことができます。しかし、放任されると、アーキテクチャの漂流、不要なコード、そして運用上の負債を招く傾向がありました。
それはわずか7ヶ月前の話ですが、その能力は飛躍的に向上しました。とはいえ、Claudeが今やほとんどの介入なしにこのコードを書けると言っても、起きている変化の表面をなぞっているに過ぎません。
### コーディングはもはやボトルネックではない
この変化がどこに向かっているのかを理解するには、単一のデベロッパーが単一のコーディングエージェントと対話することを考えるのではなく、複数のエージェントが並列で動作することを考える必要があります。
すでにこれを行う方法はいくつか存在します。単純に複数のClaude Codeセッションを実行することもできますし、Git worktreeを使えば、各エージェントに隔離された作業コピーを持たせることができます。`cmux`のようなツールを使えば、複数のClaudeセッションの管理が容易になり、`Claude Code Agent View`を使えば、複数のセッションが何を行っているか、どれに注意が必要かを把握できます。
これらすべてにより、逐次的に作業を進めるよりも大幅に速く構築できます。しかし、私はすぐに別の限界に突き当たりました。それは「並行する作業を管理する自分自身の能力」です。私は一度に3つのタスクなら余裕を持って進められますが、4つや5つになると、各エージェントが何をしているのか、どのような決定がなされたのか、どのタスクが自分を待っているのか、次に何をレビューすべきなのかといったコンテキストを見失い始めます。
その時点で、モデルが過負荷なのでも、マシンが過負荷なのでもありません。ボトルネックは、作業を調整（コーディネート）する人間なのです。私は、優れた「オーケストレーション（調整）」こそが次の重要なレイヤーになると確信しています。
この結論に達したのは私だけではありません。同僚のMarcoは、自身の「AIエンジニアリングの旅」の中で、ほぼこれと同じ進展について述べています。AIは「オートコンプリート」から始まり、「監督・信頼されるエージェント」を経て、認知負荷が制約となる「並列エージェント」へと移行していく、というものです。彼は私よりもさらにその先に進んでおり、Claude Codeとworktreeを組み合わせたオーケストレーション
原文（英語）を表示
Yadda 3.0.0: BDD in the Age of AI Agents
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
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
you can write:
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
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 overloaded. The bottleneck is the human coordinating the work. I’ve become convinced that good orchestration is the next important layer.
I’m not alone in reaching that conclusion. My colleague Marco describes almost exactly this progression in My AI Engineering Journey, moving from AI as autocomplete, through supervised and trusted agents, to parallel agents where cognitive load becomes the constraint. He is further along this journey than I am, and has responded by building Otto, an orchestration UI around Claude Code and worktrees, before moving on to agent pipelines that coordinate implementation, review, feedback and documentation.
The larger point is that AI-assisted software development is still moving extraordinarily quickly. Individual coding capability has improved dramatically, parallel execution is already practical, and the next constraint is increasingly the coordination of all that capability. The tools and approaches for doing so are developing just as quickly, and are now arguably even more important than the model updates.
Which brings me back to Yadda.
Why update a BDD library now?
I’ve always thought BDD was valuable for several reasons.
Firstly, writing requirements in ordinary language forces you to articulate the domain and, more importantly, encourages you to articulate it consistently. If you write those specifications before writing the implementation, that domain language has a habit of propagating through the codebase. The same concepts start appearing in class and function names, API definitions, database schemas, CSS classes and user interfaces. That gives the codebase a coherence that is surprisingly difficult to achieve retrospectively.
Secondly, executable specifications are far more accessible than conventional programmatic tests. A product manager, analyst or domain expert has a realistic chance of understanding:
When Steve applies to study Computer Science
Then the university rejects his application
They are much less likely to extract the same meaning from a Jest test containing fixtures, mocks, builders and assertions.
Thirdly, BDD provides a useful abstraction layer for functional tests. The specification describes intent while the step implementation deals with mechanics such as selectors, navigation and browser interaction. This provides some of the same benefits as the Page Object pattern: changes to the user interface can often be absorbed inside the abstraction instead of leaking through hundreds of tests.
There has always been a cost, though. BDD tests take longer to write initially. You need to think about the language, create reusable steps, and resist the temptation to write procedural scripts disguised as English. The payoff comes later, through better domain modelling, better communication and more maintainable functional tests. That deferred payoff has always made BDD harder to justify, but I think AI changes the economics.
Executable specifications are very good context for agents
Consider an engineering workflow that is becoming increasingly plausible.
Meetings are automatically transcribed and stored as GitHub discussions. Those discussions are analysed and used to update a project wiki. The wiki is mined for requirements and issues. Those issues are then picked up, implemented, reviewed and coordinated by a collection of coding agents.
A wiki can tell you what somebody thought the system should do. It can tell you what the system used to do. It can even tell you what an agent inferred that the system ought to do. It cannot, by itself, tell you whether the system actually does it. An executable specification can. That makes BDD much more interesting in an agentic development environment than it was before.
The expensive part of BDD was producing and maintaining the specification. AI makes much of that work cheap. A transcript, discussion or requirement can be transformed into a candidate specification almost trivially, with a human concentrating on whether the language and behaviour are correct rather than typing it all out. Once accepted, that specification becomes more than documentation. It becomes a contract.
An implementation agent can use it to understand the required behaviour. A testing agent can use it to determine what needs validating. A reviewing agent can use it to challenge an implementation. CI can continuously verify it. Because it is executable, it remains coupled to the behaviour of the software in a way that a wiki page never can.
There is an interesting inversion here. BDD was created partly to make software specifications more useful to humans, but executable specifications may turn out to be even more valuable when much of the software is being written by machines. The natural language gives agents rich domain context, while the executable steps ensure that the specification remains grounded in the behaviour of the system.
One other change (added in Yadda v3.1.0) is support for writing feature specifications as GitHub-flavoured Markdown. This makes them easier to read in the repository and, more importantly, allows them to live naturally alongside the project wiki and the other key knowledge artefacts that humans and agents use to understand the system. The same specification can now be written as:
# Feature: University applications
## Scenario: Applicant does not meet the entry requirements
- 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
It remains an executable specification, but when viewed on GitHub it looks and behaves much more like the rest of the project’s documentation.
Yadda 3 is available on npm, and the source, documentation and examples are on GitHub.