この記事で Addy Osmani は、1 年間のプロジェクトを通じて LLM を使ったコーディングのためにたどり着いたワークフローを説明し、それを一連の教訓にまとめている。彼はこのアプローチを、より規律ある「AI 支援エンジニアリング」と呼んでいる。つまり、AI を積極的に使いながらも、生み出されたソフトウェアに対する責任は持ち続けるということである。その前提は、LLM を使ったコーディングはボタンを押せば済む魔法ではなく、良い結果を得るには新しいパターンを学ぶ必要があるということ、そしてモデルは自律的な意思決定者としてではなく、明確な指示、コンテキスト、監督を必要とする強力なペアプログラマーとして扱うのが最善だということである。
教訓は計画からレビューまでに及ぶ。仕様と計画から始めること、小さな単位で作業すること、モデルが必要とするコンテキストをすべて与えること、モデルを意図的に選ぶこと、コーディングエージェントを監督下で使うこと、すべてをテストしてレビューすること、頻繁にコミットすること、ルールと例でモデルを調整すること、そしてモデルを自動化で取り囲むことである。記事は締めくくりに、そのアプローチを AI 自動化ソフトウェアエンジニアリングではなく「AI 拡張ソフトウェアエンジニアリング」と表現し、人間のエンジニアが引き続き「ショーの監督」であるとしている。
要点
- 記事は、AI とブレインストーミングした詳細な仕様から始めることを勧めている。要件とエッジケースが具体化されるまでモデルに質問させ、それを spec.md にまとめ、コードを書く前に推論モデルにそれを段階的なプロジェクト計画へと変換させる。
- 作業を小さく反復的な単位に分割し、計画のステップを 1 つずつ実装してそれぞれをテストすることを主張している。大きな一枚岩の出力を求めると、一貫性がなく重複したコードが生まれがちだからである。
- コンテキストを詰め込むこと（関連するコード、API ドキュメント、制約、避けるべきアプローチ）を強調し、コードベースをモデル向けに 1 つのテキストファイルへまとめるツールに触れるとともに、何が対象範囲外かをモデルに明示的に伝えるよう述べている。
- Claude Skills は、指示、スクリプト、ドメインの専門知識を、ツールが自動的に適用する再利用可能な能力としてパッケージ化し、壊れやすい繰り返しのプロンプトを置き換えるものであるため、有望だと述べている。
- タスクごとに最も適したモデルを選び、あるモデルが行き詰まったら別のモデルに切り替え、ときには 2 つを並行して動かして相互にチェックすることを勧めている。著者は、Gemini を好む理由の一部は Google でそれに携わっていたためだと明かしている。
- CLI のコーディングエージェント（Claude Code、OpenAI の Codex CLI、Gemini CLI を挙げている）と、クラウド VM 上で作業してプルリクエストを作成する非同期エージェント（Google の Jules と GitHub の Copilot Agent を挙げている）を説明し、エージェントに機能全体を無人で構築させるのではなく、監督下で使っていると述べている。
- 中心的なルールは、LLM の出力を決して盲信しないことである。AI が生成したコード片はすべて、ジュニア開発者が書いたものであるかのように読み、実行し、テストする。著者は、コードをマージしたりリリースしたりするのは、それを理解してからに限ると述べている。
- 書く・テストする・直すという緊密なループはテストの存在に依存するため、エージェントは強力なテストスイートを持つコードベースで最もよく機能すると論じ、AI 支援のレビューも勧めている。例えば、1 つ目のモデルが書いたコードを 2 つ目のモデルに批評させるといった方法である。
- 著者のデバッグと品質のループで Chrome DevTools MCP を使い、ブラウザが実行時に見ているものへのアクセスをエージェントに与えていることを説明している。
- AI の誤りを巻き戻せるように、また履歴をモデルへの状況説明に使えるように、極めて細かい粒度のコミットを「セーブポイント」として行うことを勧め、さらに別々の AI セッションをそれぞれ独自の Git ワークツリー で並行して動かすことを勧めている。
- CLAUDE.md や GEMINI.md のようなルールファイル、カスタム指示、望むスタイルのインライン例によってモデルを方向づけることを勧めている。
- CI、リンター、型チェッカー、コードレビューボットを戦力を何倍にもするものと捉え、それらの失敗をモデルにフィードバックすることで、自動チェックが AI の出力を正直に保つようにする。
- AI は既存の専門性を増幅すると論じている。確かな基礎を持つ人は生産性を高める一方、それを持たない人は混乱を増幅するだけかもしれない。そのため、スキルを鈍らせないよう、定期的に AI なしでコードを書くことを提案している。
背景
これらの推奨は主に著者自身の経験に基づいており、記事全体を通じて引用やリンクされている他の実践者の公開された体験談によって補われている。仕様を先に立てる計画は 仕様駆動開発 に近く、記事はバイブコーディングや非同期コーディングエージェントについての著者の以前の文章にリンクしている。記事の最後では、AI 支援エンジニアリングに関する著者の O’Reilly の書籍 Beyond Vibe Coding を紹介している。