Yi-Hung Chou、Boyuan Jiang、Yi Wen Chen、Mingyue Weng、Victoria Jackson、Thomas Zimmermann、James A. Jones による、ACM International Conference on the Foundations of Software Engineering（FSE ‘26）の論文である。 バイブコーディング（コードを書くのではなく主にプロンプトによってソフトウェアを作ること）という 用語が、自律型エージェントへの完全な委任から、依然として手作業での編集や検査を伴うエージェント支援型の エンジニアリングまで、さまざまな実践を包む総称になっていることを踏まえ、実務家が実際にバイブコーディングを どう定義し、どう取り組んでいるのかを問う。著者らは研究対象の人々を「バイブコーダー」と呼ぶ。これには、 プロのプログラマーと、正式な訓練は受けていないが自分の必要のためにソフトウェアを作る「ヴァナキュラー」な プログラマーの両方が含まれる。
著者らは、公開されている YouTube 動画にシュトラウス派のグラウンデッド・セオリーを適用した。対象は、ライブ 配信またはほとんど編集されていないコーディングセッション 7 本（約 16 時間、254 のプロンプト）と、実務家が バイブコーディングについて振り返る意見動画 13 本（約 5 時間）である。動画はキーワード検索で選び、その後、 経歴、問題領域、ツールのばらつきが最大になるよう目的的サンプリングを行った。その中には経験のない コーダーを対象とした 2 回目の検索も含まれる。コーディングチームは、開発者、ソフトウェアエンジニアリングの 研究者、プロダクトデザイナー、プロダクトマネージャーで構成された。質的分析を補うため、ライブ配信における 2,439 のアクティビティに注釈を付けて時間配分を測定し、またすべてのプロンプトを意図によってコード化して、 コーダーが新たな情報なしに要求を繰り返す頻度を測定した。
その結果得られたフレームワークは、5 つのエンティティ（バイブコーダー、プロンプトとコンテキスト、ラッパーと ツール、基盤モデル、成果物）と、3 つの繰り返し現れるアクティビティ（要件と設計、実装とデバッグ、評価）を 記述する。その中心的なイメージは、どのようなアプローチであれ、バイブコーダーは生成の確率的な性質に 向き合わなければならず、そのためデバッグや改良が「サイコロを振る」ように感じられるというものである。
要点
- 振る舞いは、ほぼ完全に AI に頼りコードを一切検査しないコーダー（ある人は 5 時間近くにわたって一度も ファイルを開かなかった）から、差分を読み生成されたコードを手直しするコーダーまで、スペクトラムを なしていた。一部の実務家はバイブコーディングの厳密な定義を主張し、他の人々はバイブコーディングと 従来のソフトウェアエンジニアリングの境界そのものを否定した。
- AI への信頼は 3 つの形をとった。目的的な信頼（視聴者へのパフォーマンスとして出力を吟味せずに 受け入れる）、不本意な信頼（不満を抱えながらも AI に従う）、そして最も多かった選択的な信頼（いつ AI に 頼り、いつ介入するかを調整する）である。
- バイブコーダーは、特定のラッパーやモデルをタスクに割り当てて組み合わせる、機会主義的なワークフローを 築いていた。ユーザーには見えないままモデルに渡されるコンテキストや隠れたトークンコストといった、 ツールの不透明な振る舞いは、正確なメンタルモデルの形成を妨げた。
- 専門知識と AI への依存度によって形作られる、成果物についてのコーダーのメンタルモデルは、プロンプトの 書き方、評価、信頼に影響した。コードを知っている、あるいは読んだことのあるコーダーは、具体的な コンテキストを伴う、より指示的なプロンプトを書いた。
- デバッグや機能の改良など、決定論的であるはずのタスクが確率的に感じられた。著者らは、新たな情報なしに 同じ意図のプロンプトを出し直すことを サイコロを振る（Rolling the Dice） と呼ぶ。AI への依存度が高い 2 人のライブ配信者はプロンプトの 40% 近くをこれに費やしたのに対し、コードを検査するコーダーや関連する 背景を持つコーダーはたいてい 20% を下回っていた。あるコーダーは 1 時間にわたり、エラーメッセージだけから なるプロンプトを 31 回連続で送った。
- 確率的な変更を抑えるために、コーダーは取り消し、バージョン管理、小さな段階的変更、自動テスト、リンター を用いた。
- 多くのコーダーは出力に応じて新たな要件を立てており、著者らはこれを探索的プログラミングになぞらえて いる。しかしコーダーはたいてい、代替案を探すのではなく最初に生成された出力を受け入れるか改良しており、 著者らはこれをデザインの固着と読んでいる。
- 生成を待つ時間は、すべてのライブ配信を通じてセッション時間全体の 20% 以上を占め、あるセッションでは 半分を超えた。コーダーはマルチタスクをしたり、プロンプトを並行して送ったりして対処した。外部リソースの 確認に費やした時間は 5% 未満だった。
- モデルにすでに何を共有したかを把握し続けることは繰り返し現れる課題だった。一部のコーダーは、進捗 ファイル、指示ファイル、外部のメモリグラフにそれを外部化していた。
補足
著者らはこの研究を、何をバイブコーディングとみなすべきかの定義ではなく、スナップショットとして提示して いる。すべてのデータが英語の YouTube 動画に由来し、Python と JavaScript が大半を占めていること、そして ライブ配信のパフォーマンス的な性質のために、レガシーコード、ガバナンス、長期的な保守を伴う業界の現場へ 知見がどこまで転用できるかが限られうることを認めている。
ツール設計者に向けては、送信したプロンプトを IDE 内で要約すること、応答をユーザーの専門知識に合わせる こと、プロンプトが並行して実行されるときの競合解決を支援すること、エラーメッセージとターミナル出力を 自動的に取り込むこと、そしてラッパーの隠れたコンテキスト、システムプロンプト、トークンコストをより透明に することを提案している。教育者に向けては、一般的な原則を教えてから AI とともにそれを適用するという 演繹的な教育が依然として不可欠だと論じている。学習者が正しい問いを立て、最適でない出力を見抜くには 十分な知識が必要だからである。