130万行、週630本のPR:バイブコーディングされたコードベースを保つ方法

2026年7月、Robert C. Martin 氏は、自分のコーディングエージェントが生成したコードをもう読んでいないと書いた。

この発言は大きな注目を集めた。だが彼の仕事のやり方を理解するうえでは、投稿の残りの部分のほうが重要だ。Martin 氏はエージェントの周囲を、ユニットテスト、Gherkin による受け入れテスト、QA 手順、ミューテーションテスト、カバレッジチェック、品質メトリクスで固めている。コードはその仕組みを通過することで彼の信頼を得る。

数か月前にも彼は同じ趣旨のことを述べていた。実装を精査するのではなく、テストカバレッジ、依存関係の構造、循環的複雑度、モジュールサイズ、ミューテーションテストの結果を見る、と。これがレビューそのものを放棄したという意味に受け取られたとき、彼はこう補足した。「レビューは山ほどしている。ただコードは読んでいないだけだ」

彼のコメントは、AI 比重の高いソフトウェア開発における実践的な問題を言い当てている。コーディングエージェントは、人が読める速度を超えて変更を生み出せる。生成されるコード量がチームのレビュー能力を超えた時点で、行単位の目視確認だけを信頼の根拠にし続けることはできない。

vm0 でも、この8か月間まったく同じ問題に取り組んできた。 リポジトリの実装の大半はエージェントが書いており — 通称でいえばバイブコーディング — そのコードが本番で何をするかについては、6 人のエンジニアが引き続き責任を負っています。

要点

vm0 はバイブコーディングされたコードベースです。実装の大半はエージェントが書き、本番での挙動については 6 人のエンジニアが責任を負います。8 か月時点でリポジトリは 1,329,170 行、1 週間で 630 本のプルリクエストがマージされました。行ごとのレビューだけでは支えきれない品質を、次の 5 つの仕組みが支えています。

• 環境の収束。 エンジニアとエージェントは同じ dev container で作業し、プルリクエストごとに専用のデータベースブランチを持てます。エージェントで通ったコマンドは人でも通ります。
• 実行可能な制約。 厳格な TypeScript、約 135 の型付き API 契約モジュール、Oxlint、ESLint、アーキテクチャルール。CI は警告を一切許しません。機械的に判定できる規則はレビュー任せにしません。
• 境界に置くテスト。 ピラミッドではなくテスティングトロフィー。モジュールの公開境界を通した結合テスト、実物の PostgreSQL とマイグレーション、モックは外部システムのみ。テストコードはリポジトリの約 36 パーセントです。
• 完結したフィードバックループ。 エージェントはアプリとデータベースを起動し、マイグレーションを実行し、実ブラウザを操作したうえで、実行したコマンド、テストした経路、スクリーンショットを報告します。プルリクエストのマージ時間の中央値は約 53 分です。
• 継続的な掃除。 Knip がデッドコードを決定的に取り除き、日次ワークフローがリンターでは名指しできない AI スロップを片付け、十分な頻度で再発したパターンは Lint ルールか型に昇格します。

バイブコーディングとエージェンティックコーディングの違い

バイブコーディングとは、LLM にコードを求め、出てきたものを実行し、修正を頼み、生成されたコードそのものには目を向けないやり方です。Martin Fowler の定義は意図的に狭く、「コードが存在することを忘れる」という表現が強調されています。試作品、使い捨てのソフトウェア、影響の小さい小さなツールに向いています。

エージェンティックコーディング(Fowler はエージェンティックプログラミングと呼びます)は、結果を保守するつもりのチームがとる形です。エージェントがリポジトリを読み、ファイルを編集し、テストを実行し、長時間自走する一方で、人は構造と挙動の責任を持ち、実行が残した証拠 — テスト結果、品質シグナル、プレビュー、本番の挙動 — を確認します。

違いはモデルがどれだけ書いたかではなく、人の注意がどこに向くかです。

	バイブコーディング	エージェンティックコーディング
エージェントの自律性	プロンプト、実行、再プロンプト	リポジトリを読み、編集し、テストし、反復する
誰がコードを読むか	誰も読まない	リスクのある箇所は人が読む
何を検証するか	出力が正しく見えるか	型、契約、テスト、プレビュー、本番シグナル
向いている用途	試作品と使い捨てのツール	保守期間のあるソフトウェア
典型的な失敗	誰も理解できないコード	量に対して検証が弱すぎる

リポジトリを編集するエージェントは、より大きな変化の一部にすぎません。非開発者向けの側面については別途まとめています。

vm0 をバイブコーディングされたプロジェクトと呼ぶことが多いのは、その言い方が「主に AI が書いたソフトウェア」の通称になったからです。Fowler の用語ではエージェンティックコーディングに近いものです。エンジニアが実装を打ち込む量は以前より減りましたが、アーキテクチャ、保守コスト、本番の挙動は引き続き自分たちのものです。

コード生成が速くなるほど、その責任の多くは開発環境、型システム、テストスイート、自動化された保守ワークフローへ移っていきました。

バイブコーディングされたコードベースの 8 か月

vm0 のリポジトリは2025年11月に作成された。直近の週次エンジニアリング規模レポートの時点で、およそ8か月半が経っていた。

リポジトリの中身は次のとおりだ。

指標	件数
空でない論理行	1,329,170
プロダクション行	850,913
テスト行	478,257
ソースファイル	5,549
テストファイル	1,327
パッケージ	44
main ブランチのコミット	14,005

これらの数値は、2026年7月20日から26日の週について、モノレポから直接計測した週次エンジニアリング規模レポートによるものです。

テストコードは計測対象コードベースの約36パーセントを占めた。これはコード量の比率であってテストカバレッジの数値ではないが、検証のまわりにどれだけの実装が積み上がっているかの感触は伝わる。

直近の丸3週間で、6人のエンジニアがそれぞれ541、640、631のコミットを行った。7月20日〜26日の週には、GitHub 上で630件のプルリクエストがマージされた。うち556件は6人のエンジニアによるもので、残り74件はリリース自動化によるものだ。

プルリクエストを開いてからマージされるまでの中央値は約53分。90パーセンタイルはおよそ7.4時間だった。

この変更速度では、人によるレビューは依然として有用だが、品質システム全体を支えることはできない。変更のライフサイクルの複数の地点で、独立したシグナルが必要になる。

現在の私たちのアプローチには5つの繰り返しテーマがある。環境の収束、実行可能な制約、境界に着目したテスト、完結したフィードバックループ、そして継続的な掃除だ。

開発環境を dev container で収束させる

再現しにくい不具合の多くは、プルリクエストには決して現れない状態から生じる。

開発者の手元には、文書化されていない環境変数、グローバルにインストールされたツール、古い設定ファイル、何か月も動き続けているデータベースがあるかもしれない。人はそうした細部に慣れてしまう。エージェントは通常それらを見ることができない。

私たちは段階的に、ホストマシンを標準の開発環境として扱うのをやめた。エンジニアもエージェントも dev container の中で作業する。開発イメージにはプロジェクトのツールチェーン、PostgreSQL、pgvector、Chromium、ブラウザ自動化ユーティリティが含まれる。

CI は、同じマルチステージ Dockerfile 系列からビルドされた、バージョン管理済みのツールチェーンイメージ上で動く。開発イメージと CI イメージは目的が異なり、本番はさらに別のデプロイ形態を持つ。有用なのは収束という性質だ。ツールのバージョン、依存関係、ランタイムの前提が明示的でバージョン管理されている。

ここから素直な期待が導かれる。エージェントが実行するコマンドは、同じ開発コンテナ内でエンジニアが再現できるべきだ。開発中に通ったチェックは、CI でも極めて近いツールチェーンの下で走るべきだ。

同じ考え方をデータにも適用している。プルリクエストのプレビューごとに専用のデータベースブランチを持たせ、実際のマイグレーションとシード処理を実行できる。エージェントはデータを作成し、変更し、破壊的なテストを繰り返せる。開発者の既存データベースを借りることも、別のプルリクエストの状態を引き継ぐこともない。

環境の変更はリポジトリを通じて伝わる。ツールのアップグレード、ブラウザのバージョン、データベース拡張は、アプリケーションコードと同じ流れでレビューされ、展開される。

エンジニアリング基準を型と Lint ルールで実行可能にする

文章として書かれた基準は、設計判断の理解を助ける。だが、とくに長時間のエージェントセッションにおいて、すべての変更がその判断に従うことを保証する力は弱い。

安定したルールは、信頼できる形で表現できる限り、型システム、リンター、CI に埋め込む。

vm0 は strict と noUncheckedIndexedAccess を含む厳格な TypeScript 設定を使っている。パッケージによっては、未使用値や暗黙的な return に対する追加チェックも有効にしている。

API には、tRPC の型機構と Zod スキーマで構築した、スキーマファーストの型付き REST 契約レイヤーを用いている。Drizzle がデータベースアクセスと TypeScript の型を結びつける。このレビュー時点で、リポジトリには約135の契約モジュールがあった。

これらの選択は、誤ったプロダクト判断を捕まえてはくれない。ただしインターフェースのずれは早期に表面化させる。フィールドやレスポンスが変わると、関連する呼び出し側は静的解析の段階で失敗しやすい。そこで出るエラーは、通常エージェントが次のイテレーションで使える程度には具体的だ。

リントは第二のルール群を担う。プラットフォームは Oxlint、型を意識したチェック、ESLint に加え、プロジェクト固有のアーキテクチャルールを実行する。CI は警告をひとつも許さない。無期限に残せる警告は背景ノイズになりがちで、背景ノイズは人にもエージェントにも簡単に無視される。

問題が繰り返されたときは、そのチェックがどこに属するかを検討する。

1. 型システムで表現できるか。
2. リンターや構造解析ツールで正確に検出できるか。
3. リポジトリ全体にまたがる意味的な判断が必要か。

最初の2つは、あらゆる変更に対して高速で決定的なフィードバックを返す。3つ目の群は、本記事の後半で述べる定期実行ワークフローで扱う。

AI 生成コードで誤りを招きやすいパターンを絞り込む

言語機能の中には、正当な用途を持ちつつ、脆いエージェント生成コードに頻出するものがある。

try/catch はエラー境界をぼかしうる。エージェントが失敗に遭遇したとき、catch ブロックとフォールバックを足すのは、元のエラーを失いながら現在の経路を動かし続ける安易な手段になる。Promise の .then() や .catch() を async/await と混ぜると、制御フローが複数のスタイルに散らばる。

React の useEffect は状態管理で同種の問題を生む。状態のコピー、2つの真実の源の同期、データモデルからは見えにくい順序依存の符号化に使われがちだ。

中核となる Web プラットフォームでは、これらのパターンを既定で制限している。正当な理由のある例外は、その理由を明示したうえで残してよい。

中核 Web プラットフォームのプロダクションコードには、現時点で useEffect が存在しない。依存関係と副作用をより明示的にモデル化するために、ccstate をはじめとする副作用のないパターンを使っている。モノレポの他の箇所、主に共有 UI とデスクトップのコードには、少数のプロダクション useEffect 呼び出しが残っている。主張の適用範囲は重要だ。

これらのルールは、このリポジトリで繰り返された失敗から生まれた。あるパターンが同じ保守上の問題を何度も生むなら、それをレビュー時の指針から実行可能な制約へと移す。

モジュール境界でテストする: ピラミッドではなくテスティングトロフィー

vm0 は一般的なテストピラミッドに従っていない。私たちのテストガイドが描くのはテスティングトロフィーだ。土台に静的解析、主役の層に統合テスト、そして重要なユーザージャーニー向けに少数のエンドツーエンドテストを置く。

ユニットテストは比較的少ない。セキュリティに関わるロジック、アルゴリズム、ステートマシンに絞って使う。ビジネス上の振る舞いの大半は、モジュールの公開境界を通してテストする。

API テストは契約を通じて実アプリケーションを呼び出す。テストデータは実用的な範囲でプロダクションのエンドポイント経由で用意し、アサーションは公開された振る舞いに対して行う。内部サービスに直接手を伸ばしたり、データベーステーブルを書き換えたりはしない。それは現在の実装とテストを結びつけてしまうからだ。

内部インフラは、コストが妥当な範囲では実物のままにする。

• PostgreSQL と pgvector
• データベースマイグレーション
• ファイルシステム
• 内部サービス
• 外部システム境界でのモック

これらの統合テストは、高度に隔離されたユニットテストより遅く、より完全な環境を必要とする。その代わり、「テストが通った」と「実際のデータベースでこの操作を実行できる」との隔たりを縮めてくれる。

境界テストは大規模な内部リファクタリングの余地を残す。エージェントはモジュールを組み替え、サービスを分割し、データアクセス層を変更できる。その間も公開された振る舞いは守られる。

Uncle Bob は異なる配合を好み、ユニットテスト、Gherkin、ミューテーションテストを重視する。共通する原則は独立した検証だ。コードを生成したプロセスが、そのコードが動くと主張する唯一の根拠であってはならない。

コーディングエージェントに完結したフィードバックループを与える

初期のコーディングエージェント実行は、見慣れた報告で終わることが多かった。コードを変更し TypeScript は通りました。アプリを起動してページを確認してください、と。

これでは開発ループの半分がエンジニアの手元に残る。誰かがデータベースを用意し、サービスを起動し、ブラウザを開き、データを作り、失敗を観察し、それをエージェントに説明し直さなければならない。

いまのエージェントは、その作業の多くを自分でこなせるだけの開発環境を持っている。アプリケーションとデータベースを起動し、マイグレーションを実行し、テストデータを作成し、プルリクエストのプレビューを開き、実際のブラウザ操作を行える。

ブラウザ検証は、型チェックや API テストではうまく覆えない一群の問題を捕まえる。壊れたナビゲーション、いつまでも終わらないローディング状態、完全なフローでしか現れない権限エラー、そして見た目のリグレッションだ。

実行の最後に、エージェントは実行したコマンド、テストした経路、観察した内容を報告する。UI の変更ならスクリーンショットも添えられる。エンジニアはその証跡を確認してから、自分でプレビューを開くかどうかを判断できる。

スクリーンショットはテストではなく、他の不具合がないことの証明にもならない。それでも、エージェントの文脈を再構成するコストを下げてくれる。小さな UI 変更なら、再現手順と最後のスクリーンショットのほうが、「たぶん直っているはず」というメッセージよりはるかに有用だ。

エージェントの仕事の質は、人を待たずに得られるフィードバックの量に大きく左右される。

トランクベース開発でブランチを短く保つ

高速なコード生成は、大量のブランチ在庫を生みうる。

長命なフィーチャーブランチは、マージ競合、重複作業、古びた文脈を溜め込む。プルリクエストが大きくなるほど、レビューは難しく遅くなる。私たちはトランクベース開発を採用し、ブランチを短く保ち、main を中心に継続的に統合する。

main ブランチのルールでは次を要求している。

• 変更にはプルリクエストを用いる
• 線形の履歴と squash マージ
• マージキュー
• Turbo、Rust、セキュリティのチェック
• 必須ゲートの慣習的なバイパス禁止

自動化も同じ経路をたどる。エージェントがプルリクエストを作成してよく、低リスクな保守タスクでは自動マージを有効にしてもよいが、変更は依然として CI とマージキューを通過する。

プルリクエストの大きさと寿命は、1週間で630件がマージされ得た理由の一端を説明する。小さな変更は文脈が少なく、検証しやすく、プロダクト作業や別の自動修復と衝突しにくい。

リポジトリのガベージコレクションとしての Knip: デッドコードを削る

コード生成は自然とファイルと抽象を増やす。削除には別途プロンプトが要ることが多い。

リファクタリング後、古いファイルがリポジトリに残ることがある。機能を削除しても、エクスポート、依存関係、エントリポイントが取り残されることがある。こうした残骸はテストを壊すことは稀だが、時間とともにコードベースを見通しにくくする。

私たちは Knip を使って、未使用のファイル、エクスポート、依存関係、エントリポイントを見つける。TypeScript はコードが妥当だと確認してくれる。Knip はそれがまだシステムに参加しているかを問う。

この残骸はコーディングエージェントにとって追加のコストになる。リポジトリは彼らにとって最も重要な文脈源のひとつだ。時代遅れのヘルパーや放棄された実装は、次にそれを読むエージェントには承認済みのパターンに見えかねない。

デッドコードの削除は、将来の実行に与えられる入力そのものを改善する。Knip はこの作業の決定的な部分を、日常的な品質チェックにできる速さでこなす。

AI スロップを掃除する定期ワークフロー

Knip と ESLint には明確な限界がある。劣化の多くの形態は、プロジェクトの文脈と意味的な判断を必要とする。

この残渣を指す実務的なラベルとして、私たちは「AI スロップ」を使っている。不要なフォールバック、重複した抽象、公開境界を迂回するテスト、あり得ない状態に対する防御的な分岐などだ。個々は無害に見えるかもしれない。だが積み重なると、リポジトリは理解しづらくなり、将来のエージェントに悪い手本を与えてしまう。

vm0 上の複数の定期ワークフローが、これらのパターンを走査している。

日次の AI スロップ掃除は新たな残渣を探し、確信度が高くリスクの低い修正を少数だけ選ぶ。他のワークフローは、内部サービスに手を伸ばす API テスト、React と ccstate のアンチパターン、安全に扱える技術的負債を点検する。

各ワークフローは変更範囲を狭く保つ。プルリクエストを開き、あとは通常の型チェック、リントルール、テスト、マージキューに委ねる。自動マージが設定されたプルリクエストでも、同じゲートを通過しなければならない。

これらのワークフローは、一度にすべての技術的負債を片づけようとはしない。日々の小さなバッチのほうが、数か月おきの大掃除より検証しやすく、混乱も少ない。

定期ワークフローが同じパターンを十分な頻度で見つけるようになったら、そのチェックを ESLint、Knip、あるいは型システムへ移すことを検討する。意味的なワークフローは、より安価な決定的チェックに変える前に、ルールを観察し磨く場として機能する。

これらの定期的な vm0 ワークフローはスケジュールで動きます。

不安定なテストの失敗を自動修復に変える

もうひとつのワークフロー群は、GitHub Actions の失敗を起点とする。

main ブランチやマージキューでテストが失敗すると、ワークフローがログを読み、フレーキーさの証拠を探し、リトライ、タイミング、環境要因を確認する。証拠が特定の修復を裏づけるなら、テストか実装を更新し、プルリクエストを開き、CI の全経路をもう一度走らせる。

リトライで通ったからといって、元の失敗が無害になるわけではない。リトライボタンに頼るチームは、赤いビルドへの信頼を少しずつ失っていく。そうなると、失敗したチェックもまた背景ノイズの一種になる。

自動修復ワークフローは、断続的な失敗を追跡可能なコード変更へと変える。診断、パッチ、検証はプルリクエスト上に残り、目に見える。リスクの高い変更はエンジニアが確認でき、証拠の強い狭い修正はマージキューを進める。

現在の品質システムは、大きく3つの層からなる。

段階	仕組み	主な関心事
記述時	TypeScript、契約、Drizzle、ESLint	型エラー、インターフェースのずれ、既知のコードパターン
マージ前	Knip、統合テスト、実データベース、プレビュー、マージキュー	デッドコード、モジュールの振る舞い、完全なランタイム結果
マージ後	スケジュール実行・イベント駆動の vm0 ワークフロー	AI スロップ、意味的アンチパターン、フレーキーテスト、アーキテクチャのずれ

各層は互いを養う。ワークフローが見つけた問題は静的ルールになりうる。CI や本番で見つかった失敗はテストや新しいエンジニアリング指針になりうる。

エージェントを回し続けるにはコストがかかります。その下げ方については別の記事で書きました。

AI 生成コードのレビューで人の注意をどこに向けるか

vm0 のエンジニアは今もコードを読む。とくにアーキテクチャの変更、セキュリティに関わる作業、決済、データマイグレーションではそうだ。「決してコードを読まない」をチームの規則にはしていない。

変わったのは注意の配分だ。コードを読むことは、契約、テスト境界、プレビューの挙動、スクリーンショット、品質メトリクス、ワークフローの診断と並ぶひとつのシグナルになった。

いくつかの判断は、依然として経験に基づく見極めを要する。

• 要件が完全かどうか
• モジュール境界をどこに置くべきか
• どの失敗が回復可能か
• 不具合がどれだけの事業影響を生みうるか
• セキュリティモデルが適切かどうか
• 現在のルールが覆えていない新しい失敗パターンは何か

エンジニアはエージェントを取り巻く環境の整備も担う。問題が繰り返されたときは、型制約、リントルール、テスト、定期ワークフローのどれを追加するかを決める。開発システムそのものが、重要なエンジニアリング成果物になった。

読みやすいコードは今も大切だ。次の読み手はエンジニアかもしれないし、別のエージェントかもしれない。もつれたコードは文脈を多く消費し、将来の変更の範囲を広げ、検証の信頼性を下げる。

デザイン側でも同じ変化が起きており、design-as-code によって視覚的な判断が同じリポジトリと同じレビュー経路に入りました。

セキュリティと、速度を上げない変更

速度は一様には行き渡りません。vm0 には自分のペースで進む変更の短いリストがあります。セキュリティに関わる作業、決済、データ移行、アーキテクチャ上の判断です。これらは誰が(あるいは何が)書いたかにかかわらず、エンジニアが一行ずつ読みます。

AI 生成コードのセキュリティリスクは、私たちの経験では、珍しい脆弱性よりも「もっともらしいが誰も責任を持っていないコード」にあります。効くのは、一貫して適用された場合の、ごく普通の対策です。

• 普段は控えめにしか使わない単体テストを、セキュリティに関わるロジック、アルゴリズム、状態機械には意図的に使います。
• テストがモックするのは外部システムの境界だけです。内部インフラは実物のままなので、内部の約束を壊す変更は本番ではなく CI で落ちます。
• エージェントは dev container の中で、プルリクエストごとのデータベースブランチに対して作業します。開発者のマシンでも共有データベースでもありません。
• マージキューと必須チェックには常用の迂回路がありません。エージェントが開き自動マージを指定したプルリクエストも同じです。
• try/catch は既定で制限しています。目の前の経路を通すためにエージェントが足したフォールバックに、失敗が飲み込まれないようにするためです。

資格情報の扱いは別の設計問題で、答えも別にあります。トークンをエージェントの手の届かないところに置くブローカーパターンについては、専用の記事で説明しました。

これだけで生成コードが安全になるわけではありません。人の判断だけが唯一の防波堤になる変更の範囲を狭め、その範囲を明示するということです。

これらの数字が示さないこと

週次レポートはリポジトリの規模と提供速度を示す。ただしそれ自体は、本番の信頼性を示すものではない。

ランタイム品質への影響を評価するには、可用性、本番エラー率、インシデント件数、変更失敗率、ロールバック頻度、平均復旧時間が要る。CI がグリーンであることは、デリバリープロセスの一部分を語っているにすぎない。

私たちはこうした成果指標を引き続き整備している。エンジニアリングの実践はシステムがどうリスクを扱うかを説明し、本番データはその扱いがどれだけうまく機能しているかを示す。

よくある質問

バイブコーディングとは何ですか バイブコーディングとは、LLM にコードを求め、返ってきたものを実行し、修正を頼み、生成されたコードを読まないやり方です。Fowler の定義は意図的に狭く、「コードが存在することを忘れる」ことが前提です。試作品、使い捨てのソフトウェア、影響の小さいツールに向いています。

エージェンティックコーディングとは何ですか エージェンティックコーディングは、より長く走る AI 支援開発の形で、エージェントがリポジトリを読み、ファイルを編集し、テストを実行し、長時間自走します。人はアーキテクチャと挙動の責任を持ち続け、書かれた行そのものではなく実行が残した証拠を確認します。

バイブコーディングとエージェンティックコーディングの違いは何ですか 著者ではなく注意の向け方です。バイブコーディングではコードが検査されません。エージェンティックコーディングではエージェントが自走する一方、エンジニアは周辺の証拠 — テスト結果、品質シグナル、プレビュー、本番の挙動 — を確認します。vm0 は普段バイブコーディングと呼ばれますが、Fowler の用語ではエージェンティックコーディングです。

AI スロップとは何ですか AI スロップとは、AI 生成コードが残す残渣です。不要なフォールバック、重複した抽象、公開境界を迂回するテスト、あり得ない状態への防御的な分岐など。一つひとつは無害に見えます。積み重なるとリポジトリは理解しにくくなり、次のエージェントに悪い手本を与えます。

週 630 件のプルリクエストで AI 生成コードをどうレビューするのですか 一行ずつは読みません。vm0 では人のレビューを判断が要る場所に振り向けます。アーキテクチャ、セキュリティに関わる作業、決済、データ移行です。それ以外は仕組みが支えます。厳格な型と契約、モジュール境界での結合テスト、プルリクエストごとのプレビューにある実データベース、ブラウザ検証、Knip、常用の迂回がないマージキューです。

大規模なバイブコーディングのベストプラクティスは何ですか vm0 で 8 か月もったのは次の 5 つです。エージェントと人が同じコマンドを実行できるよう開発環境を収束させること。標準を文書ではなく型・リンター・CI で実行可能にすること。実物のインフラに対してモジュール境界でテストすること。ブラウザを含む完結したフィードバックループをエージェントに与えること。そして、たまの大掃除ではなく継続的に片付けることです。

AI 生成コードのセキュリティリスクは何ですか よくあるリスクは珍しい脆弱性ではなく、もっともらしいのに誰も責任を持たないコードです。vm0 はセキュリティに関わる作業、決済、データ移行を人のレビューに残し、そのロジックには単体テストを意図的に使い、テストでは内部インフラを実物のままにし、失敗を飲み込む try/catch のようなパターンを制限し、必須チェックの常用的な迂回を許していません。

AI 生成コードは技術的負債を生みますか 特定の種類の負債を生みます。まだコンパイルが通りテストも通るのに、システムには参加していないコード。そして、どのリンターにも名指しできない意味的な残渣です。決定的に判定できる部分は Knip が取り除きます。残りは定期ワークフローが日々小さなバッチで扱い、十分な頻度で再発するパターンは Lint ルールか型制約になります。

vm0 のコードのどれくらいを AI が書いているのですか 実装の大半です。2026 年 7 月 20 日から 26 日の週にマージされた 630 本のプルリクエストのうち 556 本は 6 人のエンジニア名義、残りはリリース自動化によるもので、その中身のコードの大部分はエージェントが書きました。エンジニアが持ち続けているのは、アーキテクチャ、制約、本番の挙動です。

テスティングトロフィーとは何ですか。なぜピラミッドではないのですか テスティングトロフィーは、静的解析を土台に、結合テストを主要な層とし、重要な経路に少数の E2E テストを置く形です。vm0 が採るのは、モジュールの公開境界を通したテストなら、エージェントが内部の実装を組み替えても挙動を守り続けられるからです。厚い単体テスト層ではそうはいきません。

AI が書いたリポジトリでデッドコードをどう見つけますか コード生成はファイルと抽象を増やしますが、削除はたいてい別の指示が要ります。vm0 は Knip を定期チェックとして走らせ、使われていないファイル、エクスポート、依存、エントリポイントを洗い出します。TypeScript はコードが妥当かを確かめ、Knip はそれがまだシステムに参加しているかを問います。デッドコードで効くのは後者です。

バイブコーディングされたコードは本番で安全ですか 誰が書いたかではなく、何がそれを検証しているかによります。求めるシグナルは変わっていません。型と契約、公開境界を通したテスト、実物のインフラ、そして緑でなければならないパイプラインです。この記事の数字はリポジトリの規模と提供速度を示すもので、本番の問いに答えるのは可用性、エラー率、変更失敗率であり、それらは今も集めている最中です。

8か月を経て

8か月は、最終的な手法を宣言するには早すぎる。モデル、エージェントのツール、リポジトリは変わり続け、私たちのルールとワークフローもそれに合わせて変わる。

すでに明らかな変化がひとつある。コード生成が速くなるにつれ、環境、制約、テスト、フィードバックの仕組みが品質の負担をより多く引き受けるようになった。エンジニアは実装を打鍵する時間を減らし、振る舞いを定義し、境界を設計し、検証を改善する時間を増やしている。

vm0 のコードベースはこれからも大きくなる。Knip が決定的な残骸を取り除く。静的ルールが、すでに理解している失敗パターンを塞ぐ。統合テストがモジュールの振る舞いを守る。定期ワークフローが、まだ機械的に表現できない劣化を扱う。

コードは今も重要だ。ただ私たちは、その変更が main ブランチに属するか、そして実装をリポジトリに残すべきかを判断するために、より多くの機械実行可能な証拠を使うようになった。