LLM でソフトウェアを書く方法:実践的なマルチモデルワークフロー
2026年3月10日、Stavros は大規模言語モデルでソフトウェアを構築するための最も正直で実践的なガイドを発表しました。ハイプ記事ではありません。複数の納品済みプロジェクトでテストされた、実際のワークフローです。
出発点:プログラミングではなく「ものづくり」
Stavros は、プログラミング自体を目的としないという区別で議論を再構成します。彼が気にするのは「ものを作ること」です。LLM はプログラミングを直接的な構築に近づけることで、この方程式を変えました。
彼はこのアプローチで複数のプロジェクトを構築・維持しています。Stavrobot という個人アシスタント、音声メモデバイス、アートクロックプロジェクト、Pine Town という小さな町のシミュレーションなどです。
3つのモデルアーキテクチャ
1. 計画モデル(アーキテクト)
最初のモデルはアーキテクトとして機能します。コードを書く前に最大30分をこのモデルとの対話に費やします。重要な指示:明示的に承認するまで実装を始めないこと。
2. 開発モデル(実装者)
計画が承認されると、より安価なモデルが実装を担当します。このモデルの裁量は限定的——計画を実行するだけで、再設計はしません。
3. レビューモデル(複数のレビュー担当者)
実装後、Stavros はコードを複数のレビューモデルに通します。Codex、Gemini、Opus を使用。多様性が重要——異なるモデルが異なる問題を捕捉します。
人間がエージェント指示を書く
Stavros はエージェント指示を手書きします。LLM にスキルファイルを生成させません。人間が制約を定義し、モデルがその中で実行します。
効果が良い場所
マルチモデルワークフローは、Stavros が技術スタックをすでに理解している場合に最も効果的です。この文脈では、LLM は生産性の乗数として機能します。
失敗する場所
馴染みのない領域では、ワークフローの効果が大幅に低下します。間違った設計判断が蓄積し、理解不足のアーキテクチャによる技術的負債が膨らみます。
実践的な要点
計画と実装を分離する。異なる役割に異なるモデルを使う。レビュアーを多様化する。指示は自分で書く。馴染みのある領域に留まる。累積的なエラーに注意する。