Stephen Cresswell、Claude支援の1日間の再構築を経て、Yadda 3を出荷
長年のJavaScriptメンテナーは、Claudeが作業の大部分をこなし、既存のテストスイートがそのエージェントによる正しさの再定義を阻んだと述べている。
By RuntimeWire Staff · Published
Primary source: Signal Over Noise
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 は、Claude Code を使って JavaScript テストライブラリを約1日で近代化した後、8月15日に Yadda 3.0.0 を公開し、続けてバージョン 3.1.0 と GitHub-flavored Markdown で書かれた実行可能な仕様のサポートを追加しました。
これらのリリースは、AI を用いたソフトウェア開発に関するより大きな議論に対する具体的な事例を提供します:信頼できるコーディングエージェントには書き換えられない制約が必要であり、エンジニアにとっての新たな課題は、作業のコントロールを失わずに複数の有能なエージェントを調整することです。
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
Cresswell はリポジトリのドキュメントによれば 2012 年以来 Yadda を保守してきました。彼の GitHub プロフィールは amqplib、Rascal RabbitMQ クライアント、Systemic 依存性注入フレームワーク、Marv データベースマイグレーションツールなどにわたる多年の Node.js インフラの仕事を示しています。Stack Overflow のプロフィールは彼を Haven の Head of Engineering として記載し、BDD、JavaScript、Node.js に長期間注力していることが分かります。
Yadda は自然言語の仕様を実行可能な JavaScript 関数にマッピングします。これは CucumberJS と似た領域を占めますが、開発者が仕様を書く際に各ステップを Cucumber の Given、When、Then 構造に無理に当てはめることを強制しません。Yadda は独自のランナーを出荷する代わりに、node:test、Mocha、Jasmine といったテストランナーにプラグインします。
近代化ではブラウザ向けのバンドリングや CasperJS、PhantomJS、Bower、Component といったツール向けの統合が取り除かれました。Yadda 3 は現在 Node.js 20 以上を必要とし、自身のテストを node:test に移し、Biome と lefthook を採用し、ソースを ES6 構文に更新し、Playwright と Puppeteer の例を追加し、TypeScript 定義を含んでいます。
これらの変更は、Yadda を新製品にすることなく何年分もの JavaScript の歴史を一掃します。リポジトリはランタイム依存がゼロのパッケージ、約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 は自身の注意力が制約資源になっていることに気付きました。彼は決定、レビュー、ブロックされた作業に関する文脈を見失う前に、快適に追えるのは3つ、場合によっては4つか5つのタスクまででした。
"The bottleneck is the human coordinating the work," Cresswell wrote in his release essay.
その観察は、なぜ小さな BDD ライブラリがその利用者層を超えて重要なのかを説明します。Cresswell は一つのエージェントを使って長年にわたる近代化作業を1日に圧縮し、テストがガードレールとして機能しました。彼の次の制約は並行作業の監督でした。エンジニアリングの仕事は、契約を定義し、変更を分離し、コンテキストを保全し、どの証拠がマージに十分に強いかを決める方向へとシフトします。
Yadda は、これらの契約の一つを人が読みやすく、機械が実行可能にするための Cresswell の試みです。パッケージ自体は依然として特殊化された JavaScript テストツールです。そのリリース背後にある開発手法がより大きな貢献です:メンテナーがエージェントに変更の順序、狭い範囲、そして静かに書き換えられない正しさの基準を与えると、エージェントは速く動けます。