この記事（「良いバイブコーディングの実践：見逃してはいけないこと」）は、日々の開発で AI を使うことについての以前の考察を、あるソフトウェアエンジニアが引き継いで書いたものである。その中心的な主張は、タイピングというボトルネックが取り除かれても、システムがひとりでに流れるようになったわけではなく、ボトルネックが移動しただけだというものである。エージェントがテストの通る数百行のコードを数分で納品できるようになると、制約はその成果物の検証になり、その量を 1 行ずつレビューできる人間はいない。
そこから著者は、開発者の役割が「象牙の塔のアーキテクト」、つまり仕様を書いて実装者に渡すアーキテクトの方へと回帰したと論じる。違いは、開発者がなお実装を検証する点であり、そのため開発者はアーキテクトであると同時にレビュアーでもある。エージェントはどこで止めるべきかを知らないので、本番に出せるほど十分に良いかどうかの判断は完全に人間のものだとされる。記事は、軽蔑的な意味合いを取り除いた バイブコーディング を、本質的にはこのサイクル、つまり仕様を定め、トレードオフを整理し、実行をモデルに任せ、結果を検証するサイクルとして扱っている。品質はエージェント自体からではなく、エージェントを操作する人から生まれるという立場である。
記事の大部分は、これを機能させるために著者が実践している一連のプラクティスであり、計測ではなく著者自身の経験に基づいている。
要点
- 記事は、レビューの帯域幅は変わらないまま産出量だけが加速したため、AI によって開発のボトルネックが実装から検証へ移ったと論じる。
- 1 行ずつ読む代わりに自動化された品質シグナル（循環的複雑度、メソッドやクラスのサイズ、依存関係の数、結合度）を用いることを勧めつつ、メトリクスは証明ではないとしている。著者の経験では、隠れた N+1 クエリのようなパフォーマンスバグが自動レビューを繰り返しすり抜け、シニアエンジニアが読まなければ見つからなかった。
- 生成されたコードを非決定的なもの（同じ仕様を何度か実行すると異なる結果が得られうる）として扱い、決定性は厳格なアサーションによって出力の側で強制しなければならず、強力なテストが実行間のずれを捕捉すると結論づけている。
- バイブコーディングされたプロジェクトがしばしば省略する本番運用の基本（可観測性、フィーチャーフラグ、アラート、監査証跡）は、エージェントが毎日コードを変更する状況では重要性が下がるのではなく、むしろ高まると述べている。
CLAUDE.md、Copilot の指示ファイル、バージョン管理されたスキルといったプロジェクトの指示ファイルを「天井ではなく床」と表現している。それらはエージェントにプロジェクトの規約を守らせるが、出力が正しいことを保証するものではない。- コードについては、大きなモデルで計画して安価なモデルで実行するというやり方に反対し、コード、計画、アーキテクチャにはより良いモデルに費用をかけることを勧めている。それ以外の用途では安価なモデルで問題ないとしている。
- 計画を第一級の成果物として扱っている。著者はエージェントに Markdown で計画を提案させ、実行前にそれをレビューして調整する。また、仕様駆動のワークフローを「教科書どおり」ではなく選択的に適用する。間違った計画はただのテキストにすぎないが、間違ったコードはすでにコミットになっている、というのがその理由である。
- より厳しい自動ガードレールを求めている。90% を超えるカバレッジと 90% を超えるミューテーションスコアの組み合わせ、関数やクラスのサイズに対するより厳格な静的解析の上限、強力なリグレッションテストである。AI が書いたテストはテストのように見えて何もテストしていないことがあり、エージェントは触るよう頼まれていないファイルをしばしば編集する、とも指摘している。
- 手動 QA は AI の産出量にスケールしないとし、重要なフロー（お金、認証、アカウント作成、データ削除）には自動化されたエンドツーエンドテストが必要であり、手動 QA は新機能の探索的テストのために残すべきだと論じている。
- 行単位ではなく判断単位でレビューすることを勧めている。人間のレビューを、境界、契約、認証、永続化、外部呼び出し、依頼されていない変更に集中させ、それ以外は自動化されたガードレールに任せるということである。
- LLM には停止基準がなく、常に何かしら改善点を見つけてくるため、計画もコードも際限なく過剰設計されうると警告している。スコープと受け入れ基準が十分かどうかは人間が決めなければならない。
- 著者が AI が繰り返し生み出すのを目にしている 3 つのバグパターン（N+1 クエリ、非同期シーケンスにおける競合状態、有効期限のないキャッシュにおけるメモリリーク）を挙げ、それぞれに対する自動チェックを提案している。クエリ数のアサーション、プロパティベーステストと並行実行テスト、ヒーププロファイリングを伴う負荷テストである。
背景
この記事は著者自身の日々の利用に基づいて書かれた一実務者の記述であり、推奨事項の大半はデータではなくその経験に依拠している。記事は自らのプラクティスを厳格な方法論ではなく選択的な適用と位置づけ、厳格な仕様駆動開発をスクラムになぞらえて、チームはうまくいくものを取り入れ、残りは無視するものだとしている。また、運用の継続性に関する懸念も提起している。AI ツールは有料でレート制限のあるサードパーティのサービスなので、それが使えないときでも、開発者は自分の手でコードを読み、デバッグし、書けなければならない。検証を新たな制約とする記事の診断は、レビューのボトルネック としてより形式的に記述されているのと同じ圧力である。