バイブコーディングの開発モデル（Vibe Coding Development Models）とは、ある学術的なサーベイで提案された分類法であり、人間の開発者と AI コーディングエージェントが実際にどのように責任を分担しているかを 3 つの軸に沿って分類する。その軸とは、人間による品質管理（開発者が AI の生成したコードを受け入れる前に、どの程度レビューし理解するか）、構造化された制約の仕組み（ワークフローが事前の計画ドキュメント、自動テスト、ルールベースの制約を用いるかどうか）、そしてコンテキスト管理の能力（ワークフローがコードベースのインデックス化、プロジェクトのドキュメント、検索拡張生成にどの程度依存するか）である。これら 3 つの軸の異なる組み合わせから、名前の付いた 5 つのモデルが導かれる。この分類法はそれらを互いに排他的なものではなく、組み合わせ可能なものとして扱う。
用法
5 つのモデルは次のとおりである。無制約自動化モデル（Unconstrained Automation Model, UAM） — AI が主導し、人間は要件を提示するだけで、正しさはコードレビューではなく機能テストによって確かめる。ラピッドアプリケーション開発になぞらえられ、バイブコーディングの本来のより狭い意味に最も近いモデルとされる。反復的対話協働モデル（Iterative Conversational Collaboration Model, ICCM） — 人間は AI の各出力を受け入れる前にレビューし理解する。生成・レビュー・テスト・受け入れのサイクルを繰り返すもので、ペアプログラミングになぞらえられ、AI が「ドライバー」、人間が「ナビゲーター」を務める。計画駆動モデル（Planning-Driven Model, PDM） — AI による実装が始まる前に、人間が仕様、コーディングルール、実装計画のドキュメントを書く。ウォーターフォールモデルになぞらえられ、人間がアーキテクト、AI が実装を担う「チーム」となる。テスト駆動モデル（Test-Driven Model, TDM） — 人間が仕様としてテストを書き、AI はそれをパスするコードを書く。古典的なレッド・グリーン・リファクタリングのサイクルに従い、検証は人間の判断ではなく機械的にチェック可能なテストに委ねられる。コンテキスト強化モデル（Context-Enhanced Model, CEM） — 単独のワークフローではなく横断的な能力（検索拡張生成、コードベースのベクトルインデックス化、ドキュメントの読み込み、ルールによる制約）であり、他の 4 つのモデルのいずれにも重ねて適用でき、生成されたコードが既存のコードベースにどれだけ適合するかを高める。
出典自身の比較分析は、4 つの基本モデル（CEM は修飾要素として扱う）を、事前の投資、人間による制御、構造化された制約、開発速度、コード品質、技術的負債、保守性、セキュリティリスクの観点から評価している。UAM は最も速いが、技術的負債とセキュリティリスクは最も高いと評価されている。一方 TDM は、事前の投資が最も大きい点で PDM と並ぶが、品質の面では最も厳格で、残存するセキュリティリスクは最も低いと評価されている。
適用される場面
この分類法は、プロジェクトのリスク許容度、求められる速度、ガバナンス上の要求に合わせてワークフローを選ぶ（あるいは組み合わせる）ための実践的な足場として提示されている。例えば、複雑で高い品質が求められるプロジェクトには PDM と TDM の組み合わせ、大規模な既存コードベースの保守には ICCM と CEM の組み合わせ、といった具合である。UAM は、使い捨てのプロトタイプや個人用のユーティリティといった低リスクの場面にのみ適しており、本番システム、安全性が重要なアプリケーション、長期的な保守を必要とするコードベースには向かないとされる。出典は、モデルの選択を、人間と AI の協働の境界を暗黙のままにせず明示するための手段として位置づけている。