私たちはAIでsalty.pokerを構築しました。誰も見ていなかったその部分。

10日間で22回のビルドセッション。

各セッション：Claude Codeエージェントが100ページの仕様書に基づいて作業 — コードベースの現在の状態を読み込み、割り当てられた仕様モジュールを取り、コードを書き、サービスを接続し、マイグレーションを実行し、コミットする。見積もり会議なし。スコープの議論なし。会議室でのJiraチケット論争なし。

これらのセッションの成果は、20のマイクロサービス、リアルタイムテーブルエンジン、トーナメント管理、複式仕訳帳、KYC検証、不正検出、アニメーションカードとチップスタックを持つPixiJSレンダリングのポーカーテーブルでした。

変更履歴には出荷されたものが記録されています。この投稿はその後に起きたことについてです。

コードが書かれた後に本当に起きること

正しいコードを書くことと動作するシステムを持つことは、二つの異なることです。コードはユニットテストを通過します。サービスは隔離状態で正しく動作します。しかし、すべてを接続すると — ウェブアプリ、テーブルエンジン、リアルタイム接続、認証、データベース — 失敗の表面積は、どのテストスイートも完全に予測できないほど速く増加します。

先週がまさにそのフェーズでした。エンドツーエンドテスト。本物のログイン、本物のロビー、本物のテーブル、本物のプレイヤーが着席。

テーブルビューが読み込まれ、席があるべき場所に空のキャンバスが表示されました。バイインダイアログなし。ロビーに戻る方法なし。ポーカーゲームがあるべき場所に空白の画面。

ロビーには、ページ全体の高さを埋めるように伸びたテーブルカードがありました。一つのCSSのデフォルト値 — 行にアイテムが一つしかなく、ストレッチ動作を上書きしていない場合のCSS Gridの動作です。

これらのバグのどれも人間が書いたものではありませんでした。AIセッションがテーブルビューを書きました。AIセッションがロビーを書きました。それでもバグでした。見つけ出し、根本原因を追跡し、修正する必要がありました。

それでもなぜこれが最良の道なのか

どう壊れたかの話の前に：10日間でエンドツーエンドテストにいるという事実こそが話の本題です。

以前の二つの会社が、従来のやり方でどれだけ時間がかかるかを教えてくれました。テストするものができる前に数ヶ月。最終製品に似たものをテストするまでにさらに数ヶ月。

私たちは10日間でそのギャップを埋めました。テストフェーズが難しい部分です。私たちはその中にいます。

このシリーズの続き

これは4つのうちの最初の投稿です。来週にわたって、テスト中に実際に見つかったものを詳しく見ていきます — フルスタックが動くまで見えなかったルーティングバグ、コードの変更を静かに無視していた開発環境、すべてのナビゲーション試みをリダイレクトループに送っていた認証ガード。

より深い方法論については、The Salty Koreanで書いています。

Stay salty.