コードカバレッジを越える — Marlene Mhangami (Microsoft) が見せる behavior-first TDD with Playwright MCP (AI Engineer Europe 2026)

AI Engineer Europe 2026 (London) — Marlene Mhangami / Microsoft 2026/05/16

マルレーヌ・ムハンガミ / Marlene Mhangami · 03:10 「Clean code bases amplify AI gains、 unchecked AI in code base amplifies entropy。 14 倍の commit 急増の中で、 これが勝敗を分ける」

AI Engineer Europe 2026 (London、 2026/05/16 公開、 約 19 分 45 秒)。 講師は Marlene Mhangami (Microsoft & GitHub の Senior Developer Advocate、 Core AI 部門)。 GitHub Octoverse 最新データ (年間 14 倍に commit 急増中) を起点に、 Stanford 研究 (Clean code base が AI productivity gain を決める) を経由して、 Behavior-first TDD with Playwright MCP Marlene Mhangami が AI Engineer Europe 2026 で提案する開発フロー。 従来の unit test 中心 TDD は AI 時代に self-affirming test 問題で壊れるため、 Playwright (Microsoft 製 end-to-end testing framework) + MCP server を使って behavior 単位で TDD を回す方式。 red-green-refactor の red と green は AI 高速化、 refactor 段階に人間が時間を注ぐ、 という時間配分の逆転が特徴 を、 Tailspin Toys デモで 実演する 現場知見。

Marlene Mhangami の AI Engineer Europe 2026 講演は、 2026 年に GitHub が観測している commit 量 14 倍急増 (年間 140 億 commit 予測) の中で 「ただ書く量が増えるだけ」 を防ぐための test 設計を扱う。 起点は Stanford の 120,000 人開発者調査 ── AI productivity gain は code base の清潔さに比例し、 unchecked な AI 投入は entropy を加速させる、 という不都合な真実。 「PR 数だけ増えて refactor で時間を食う、 結果 1% しか改善しない」 という failure mode を proactively avoid する手法が、 本講演の中核。

MEMEX 編集視点で重要なのは、 これが Laurie Voss (Arize) の Ship Real Agents での 「eval は AI engineer にとってのテスト」 という思想を、 非 AI 製品 (= 普通の web アプリ) 側でどう実装するか という補完軸で示している点。 Voss は AI 製品の eval、 Marlene は AI 生成コードの eval ── 両方とも 「AI が走った後の品質をどう担保するか」 の話。

「TDD は 2014 年に死んだ、 でも AI 時代に蘇る」

Marlene の歴史的整理: 2014 年、 Rails 創始者 DHH が 「TDD is dead」 をブログで宣言。 過度な unit test 中心主義の弊害が業界全体で意識された。 主な批判:

  • Implementation detail を test する ── メソッド名 rename で test が壊れる、 機能は同じやのに
  • Self-affirming test ── AI に test 生成させると、 通すための test を書きがち、 behavior 検証になっていない
  • Code coverage 信仰 ── 100% coverage でも production で壊れる

解は Ian Cooper が提唱した 「behavior-driven TDD」 ── stable contract (API、 export された module) や final behavior (price 計算結果) を test し、 internal refactor で壊れない test を書く。 これは Pedro Rodrigues (Supabase) の skill 設計 3 原則 での 「opinionated workflow を skill に encode」 と同じ思想 ── behavior という最も stable な layer に anchor を打つ。

Red-green-refactor の時間配分が逆転する

AI 時代の TDD の新しい姿:

  • Red (失敗 test 作成) ── 従来は人間が時間かけて書いた、 AI 時代は数秒
  • Green (test を通すコード生成) ── 従来は数時間、 AI 時代は数分
  • Refactor (品質向上) ── ここに人間の時間が集中する

これが Marlene の core thesis。 「AI が書いた code を人間が review し、 architecture や読みやすさを整える」 工程が、 開発者の最大の付加価値になる。 これは Karpathy の Software 3.0 / Agentic Engineering での 「abstraction layer が一つ上がる」 主張と完全に整合する。

Playwright + MCP ── Behavior を測る武器

Microsoft の Playwright は元々 end-to-end testing framework (Python / TypeScript / C# 等対応)。 2025-2026 で 3 つの統合手段が成熟:

  • Playwright MCP server ── agent が直接 browser を駆動できる
  • Playwright CLI ── 既存 setup と統合
  • Playwright Agents ── `agent.md` ファイルで planner / generator / healer の 3 agents を install

Demo: Tailspin Toys (架空のおもちゃ EC サイト) に 「search bar + sidebar filter」 機能追加。 Marlene は GitHub Copilot CLI から:

  1. WorkIQ skill で Outlook の機能要求メールを CLI に取り込む
  2. 「red-green TDD で進めて、 まず failing Playwright test を書け」 と指示
  3. Agent が codebase を analyze、 Playwright test を生成 (search field の placeholder 検索、 入力、 filter ボタンクリック等)
  4. Test を実行 (browser headed mode で screenshot 録画)、 fail を確認
  5. 機能 code を生成して test を pass させる
  6. Pass 後、 Marlene が refactor 段階に時間を投入

ここで重要なのが 「test は behavior を見る」 ── 「Furby を search すると Furby 結果が表示される」 「特定 price 帯 filter で対応 toy のみ残る」 という ユーザー視点。 implementation detail ではない。 これによって AI が refactor で internal を書き直しても、 test は壊れず、 behavior 担保が続く。

Best practices ── 4 つの現場知見

Marlene が最後に提示する実用 tips:

  1. Playwright screenshots を PR に添付 ── reviewer が機能の実際の見た目を確認できる、 ブラックボックス AI コードの説明可能性向上
  2. Headless mode で CI 統合 ── ブラウザ表示なしで test 実行、 GitHub Actions / Azure Pipelines で常時走らせる
  3. Commit before agent edits ── AI が大量変更する前に git commit、 失敗時の roll back を保証
  4. One feature, one test ── 1 feature 1 test に絞ると agent が confused にならない

State management が複雑な admin panel 系の質問に対して Marlene は 「Playwright Agents の `agent.md` を使え、 state 系の specialized instructions が built-in」 と回答。 必要なら API 直接 test も組み合わせる。 つまり Playwright は browser-based、 backend API は別 layer で test する hybrid 戦略を推奨。

編集所見 ── 「14 倍の commit 量」 にどう対応するか

この講演を MEMEX で取り上げる視点は 3 つ。

(1) GitHub Octoverse データの strategic 意味。 2025 年 1B commit → 2026 年 14B 予想 = 14 倍。 これは software 業界全体の 「production rate」 が 1 年で桁違いに変化したことを示す唯一の hard data。 同じ期間で Intercom が 9 ヶ月で 2x throughput 達成PFF が 2 ヶ月で 25x deploy / 10x output 達成。 個別企業の数字が業界全体の commit 量と一致する。 これは構造的変化の証拠。

(2) 「品質 vs 速度」 の二項対立が消える。 Marlene の Stanford 研究引用 ── 「clean code base + AI = 大幅な productivity gain、 unchecked AI = entropy」 ── は、 2026 年の開発組織の最も重要な分岐点。 PR 数だけ追う organization は AI の恩恵を 1% しか取れない、 test infrastructure に投資した organization は 10-25x の差を取る。

(3) Microsoft / GitHub プラットフォーム戦略の core piece。 Playwright + Copilot CLI + WorkIQ (M365 統合) の組み合わせは、 GitHub が 「単なる code host」 から 「AI-native 開発プラットフォーム」 への変貌を完成させつつあることを示す。 Anthropic $350B 評価額の構造 での Microsoft × Anthropic 統合 (Azure に Claude が乗る) と並行して、 GitHub 側でも AI 統合が進んでる。

動画の構成

  • (00:00) 自己紹介、 Microsoft & GitHub Core AI 部門
  • (01:00) GitHub Octoverse 2025 ── 年 1B commit、 2026 予測 14B
  • (02:10) Stanford 120k 開発者調査の核心結論
  • (03:30) TDD の歴史 ── 2014 「dead」、 Simon Willison が red-green 復活
  • (04:30) 過剰な code coverage の罠 (implementation detail、 self-affirming)
  • (06:00) Behavior-first TDD の解 ── stable contract に anchor
  • (07:00) Playwright の紹介、 多言語対応
  • (08:00) Red-green-refactor の時間配分逆転
  • (09:00) Playwright MCP / CLI / Agents の 3 連携
  • (10:30) Tailspin Toys demo 開始 ── WorkIQ で要求取り込み
  • (13:00) Failing test 生成、 実行、 機能実装、 pass まで
  • (16:00) Best practices 4 つ
  • (17:30) Q&A ── state 管理 + Playwright Agents、 モバイル / desktop 対応

出典