HN 日本語サマリー

← 一覧へ戻る
プログラミング

Yadda 3.0.0: AIエージェント時代のBDD

Yadda 3.0.0: BDD in the Age of AI Agents (stephen-cresswell.com)

46 pointsby scresswell24 コメント

要約

Yadda 3.0.0のリリースが発表され、このJavaScript BDDライブラリはAI、特にClaudeによるコード生成で大幅に近代化されました。著者は、AIがソフトウェア開発のボトルネックをコーディングから人間の調整へと移行させていると論じ、AI支援開発におけるBDDの価値を再確認しています。

全文翻訳

Yadda 3.0.0: AIエージェント時代のBDD npmにYadda 3.0.0を公開しました。YaddaはJavaScript向けのBDDライブラリです。Cucumberのように、日常言語の仕様を実行可能なコードにマッピングしますが、仕様の書き方についてより自由度が高いようにゼロから設計されています。これは、以下のような記述の代わりに: 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 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 どちらも実行可能な仕様です。私は後者の方が読みやすいと感じます。 Yadda 3で何が変わったのか? Yadda 3.0のほとんどは近代化の取り組みです。Yaddaは長い間存在しており、リポジトリには現在では歴史的な curiosities となっているJavaScriptエコシステムのパーツのためのインテグレーションやツールが蓄積されていました。Yadda 3はNode専用となり、ブラウザバンディングやCasperJS、PhantomJS、Bower、Componentといった廃止されたインテグレーションを削除し、テストスイートをnode:testに移行し、Biomeとlefthookを採用し、ソースをES6シンタックスに近代化し、PlaywrightやPuppeteerを含む最新の例を追加しました。TypeScript定義も提供されるようになりました。これらはすべて有用ですが、特に興味深い話題ではありません。リリースに関して、私がより重要だと考える点は2つあります。 Claudeがその大部分を書いた 私はClaude Code with Opus 4.8を使ってYaddaを近代化しました。Claudeによって書かれたYadda 3.0のエピックは、作業を意図的に分離された一連のフェーズに分割しました:廃止された機能の削除、ツールチェーンの更新、挙動の変更とは別に機械的なフォーマットの実行、ソースの近代化、API変更の検討、例とCIの更新、そしてメタデータ、ドキュメント、TypeScript定義の完了です。私たちは実装前に各フェーズを計画し、その後、Claudeに作業を任せました。Claudeは驚くほど少ない間違いしか犯さず、さらに印象的だったのは、当初は機械的な近代化に見えた作業中に見落としがちだった、かなり微妙なエッジケースを特定したことです。私はほとんど介入しませんでした。重要な要因の一つは、Yaddaがすでに包括的なテストスイートを持っていたことです。また、Claudeに本番コードとその対応するテストを同時に変更するように依頼することは意図的に避けました。エージェントが両方を同時に変更すると、緑色のテストスイートは証拠としての価値が低下します。なぜなら、実装と同時に「正しい」の定義を変更できるからです。これらの変更を分離することで、Claudeはより強固な外部制約を持つことができました。作業開始からパッケージの公開まで、経過時間は約1日でした。私はその間、他のことも並行して行っていました。 今年の初めに、vibeコーディングの経験がなぜこれほど二極化するのかという実験について書きました。その時の私の結論は、結果がエージェントの使用方法に大きく依存するということでした。厳密に制約され、監督されたClaudeは、非常に迅速に非常に良い結果を生み出すことができました。自由に任せると、アーキテクチャのドリフト、不要なコード、運用上の負債に傾倒する傾向がありました。それはわずか7ヶ月前のことですが、その能力は飛躍的に進歩しました。それでも、Claudeがほとんど介入なしにこのコードを書けるようになったと言うことは、変化の表面をかすめたにすぎません。 コーディングはもはやボトルネックではない これがどこに向かっているのかを理解するには、単一の開発者が単一のコーディングエージェントと会話することを考えるのをやめ、代わりに複数のエージェントが並行して作業することを考えるのが役立ちます。これを行う方法はすでにいくつかあります。単純に複数のClaude Codeセッションを実行できます。Git worktreesを使用すると、各エージェントが分離された作業コピーに対して作業できます。cmuxのようなツールは、Claudeセッションのコレクションの管理を容易にし、Claude Code Agent Viewは、複数のセッションが何をしているか、どれに注意が必要かを見る別の方法を提供します。これらすべてにより、シリアルに作業するよりも大幅に速く構築できますが、私は比較的早く別の限界に達しました。それは、並列作業を管理する私の能力です。私は同時に3つのタスクを快適に進めることができ、時には4つか5つです。それを超えると、各エージェントが何をしているのか、どの決定が下されたのか、どのタスクが私を待っているのか、次に何をレビューする必要があるのか、というコンテキストを失い始めます。その時点で、モデルが過負荷になるわけでも、マシンが過負荷になるわけでもありません。ボトルネックは、作業を調整する人間です。 良いオーケストレーションが次の重要なレイヤーであると確信しています。この結論に達したのは私だけではありません。私の同僚であるMarcoは、AIをオートコンプリートとして、次に監督された信頼できるエージェント、そして認知負荷が制約となる並列エージェントへと移行する過程を、My AI Engineering Journeyでほぼ正確に描写しています。彼は私よりもこの旅の先を進んでおり、Claude Codeとworktreesを中心としたオーケストレーションUIであるOttoを構築し、その後、実装、レビュー、フィードバック、ドキュメントを調整するエージェントパイプラインへと移行しました。 より大きなポイントは、AI支援ソフトウェア開発は依然として驚異的な速さで進歩しているということです。個々のコーディング能力は劇的に向上し、並列実行はすでに実用的であり、次の制約はますますすべての能力の調整となっています。それを行うためのツールとアプローチは、同じように急速に開発されており、現在ではモデルの更新よりも重要であると言えるかもしれません。 Yaddaに戻ります。 なぜ今BDDライブラリを更新するのか? 私は常にBDDがいくつかの理由で価値があると考えてきました。第一に、日常言語で要件を書くことは、ドメインを明確に表現することを強制し、さらに重要なこととして、それを一貫して表現することを奨励します。実装を書く前にそれらの仕様を書くと、そのドメイン言語はコードベース全体に広がる習慣があります。同じ概念がクラス名や関数名、API定義、データベーススキーマ、CSSクラス、ユーザーインターフェースに現れ始めます。これにより、コードベースに、後から達成するのが驚くほど難しい一貫性が生まれます。第二に、実行可能な仕様は、従来のプログラムによるテストよりもはるかにアクセスしやすいです。プロダクトマネージャー、アナリスト、またはドメインエキスパートは、以下を理解する現実的なチャンスがあります: When Steve applies to study Computer Science Then the university rejects his application フィクスチャ、モック、ビルダー、アサーションを含むJestテストから同じ意味を抽出する可能性ははるかに低いです。第三に、BDDは機能テストのための有用な抽象化レイヤーを提供します。仕様は意図を記述し、ステップ実装はセレクタ、ナビゲーション、ブラウザインタラクションなどのメカニクスを処理します。これはPage Objectパターンと同じ利点の一部を提供します。ユーザーインターフェースの変更は、しばしば数百のテストに漏れ出すのではなく、抽象化の内部で吸収できます。 しかし、常にコストがかかっていました。BDDテストは最初に書くのに時間がかかります。言語について考え、再利用可能なステップを作成し、英語を装った手続き型スクリプトを書く誘惑に抵抗する必要があります。ペイオフは後で、より良いドメインモデリング、より良いコミュニケーション、そしてより保守性の高い機能テストを通じて訪れます。その遅延されたペイオフは常にBDDを正当化するのがより困難にしてきましたが、AIが経済を変えたと思います。 実行可能な仕様はエージェントにとって非常に良いコンテキストです。 ますます現実的になりつつあるエンジニアリングワークフローを考えてみましょう。会議は自動的に記録され、