「バイブコーディング（vibe coding）」は、この wiki で最もよく使われる語の 1 つだが、その意味について各ページの見解は一致していない。あるページは、この語を 1 つの狭い基準、すなわちソフトウェアを作る人がコードを読むかどうかに限定する。別のページは、レビューの有無にかかわらず、主にモデルとの対話によって作られたソフトウェアすべてにこの語を使う。3 つ目のグループは、この語を、いずれ別の実践に取って代わられる初期段階の名前として使う。このページでは、それらの答えと、それぞれを誰が示しているか、その背後に何があるかを整理する。どれが正しいかは決めない。ページ同士が食い違う箇所では、その食い違いこそがこのページの記録するものである。
造語の由来
この語の出どころについては、各ページの見解が一致している。バイブコーディング は、2025 年 2 月初めにこの語を作ったのは Andrej Karpathy だとしている。Karpathy の説明は、バイブス（雰囲気）に完全に身を委ね、コードが存在することさえ忘れるというものだった。すべての差分を読まずに受け入れ、エラーメッセージを何のコメントも付けずにそのまま貼り付け、モデルが直せないバグは回避するか、消えるまで適当な変更を頼む。2 つの出版社と 3 人の著者が「バイブコーディング」の意味を理解していない はそのツイートを全文引用している。同記事が強調するのは 2 つのフレーズ、「コードが存在することさえ忘れる（forget that the code even exists）」と「使い捨ての週末プロジェクトなら悪くない（It’s not too bad for throwaway weekend projects）」である。Cursor は、Karpathy が説明した環境を記録している。Sonnet モデルで動く Cursor Composer に、タイプするのではなく音声で話しかけるというものだ。
ほかにもいくつかのページが、この語を Karpathy に帰している。
- バイブコーディング対エージェント型コーディング：エージェント型 AI の基礎と実践的な含意
- バイブコーディング：人工知能との会話を通じたプログラミング（2025 年 2 月の彼の投稿を「Karpathy の正典（the Karpathy canon）」と呼んでいる）
- AI プログラミングツールの進化とバイブコーディングについて
- Claude Code を活用した予測可能なバイブコーディング戦略
- Vibe Vibe
- 本当に「ポチッ」で全部できるのか？ — 保守的な開発者が AI エージェントでプロダクトをリリースして気づいたこと
2025年のアウトプットふりかえり は、ソフトウェアの書き方の転換を 2025 年 2 月に位置づけている。同記事は、その月のある 1 つの発表がバイブコーディングを話題の的にしたとし、その月を、人間が運転席から助手席へ移った月としてまとめている。
各ページは、語の由来については食い違っていない。食い違っているのは、この語が Karpathy の説明をどこまで引き継いでいるかである。
答え 1: バイブコーディングとはコードを読まないことである
最もはっきりと線を引いた答えは、Simon Willison によるものだ。AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） は、この語を 1 つの観察可能なテストに還元する。バイブコーディングとは、LLM が書いたコードをレビューせずに、LLM でソフトウェアを作ることである。LLM が書いたコードでも、その後レビューされ、テストされ、理解されたものはソフトウェア開発であり、LLM が関与したかどうかは問題にならない。AI 支援型プログラミング は、この狭い語が属する包括的なカテゴリーを示している。
Willison は、この狭い読み方をバイブコーディングへの攻撃ではなく、その擁護として提示している。
- コンピュータサイエンスの学位もブートキャンプの経験もない人々にとって、プログラミングへの高い障壁を下げる。
- 経験のある開発者にとって、LLM についての直感を養う最良の方法である。
2 つの出版社と 3 人の著者が「バイブコーディング」の意味を理解していない で、彼はこの区別を「死んでも譲れない一線（a hill I am willing to die on）」と呼んでいる。さらに、バイブコーディングはソフトウェア開発者ではない人々のためのものであり、すでに開発者である人々のためのものではないと付け加えている。
Willison は 2026 年になっても同じ線を守っていた。
- Agentic Engineering Patterns（エージェント型エンジニアリングのパターン）について書く は、この語を元の定義、すなわちコードにまったく注意を払わないコーディングという意味のまま保っている。今日この語は非プログラマーと結びつけられることが多い、とも述べている。
- バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている は、これを、コードをまったく見ず、場合によってはプログラミングの仕方すら知らず、結果を動くかどうかだけで判断することだと説明している。
ほかのページも、同じ境界を採用するか言い換えている。
- AI プログラミングツールの進化とバイブコーディングについて は、Karpathy の投稿を 4 つの点として読む。コードが存在することを忘れること、小さなエラーでさえ AI を通じて直すこと、AI が書いたものをレビューしないこと、そしてそれが使い捨てのプロジェクトなら構わないと受け入れることである。バイブコーディングをめぐる議論の多くは、2 つの異なる実践を区別していないことから生じている、と同記事は論じている。
- バイブコーディング：実践、性能、生産性、リスク ── 最先端レビュー は、定義に Willison の境界を採用している。バイブコーディングを際立たせるのは、生成されたコードから開発者が離れていることであり、検証は出力が動くかどうかによって行われる。この境界に従えば、開発者がなおレビューとテストを行う対話型 IDE のワークフローは、本来の意味でのバイブコーディングからは外れる。
- SWE-chat: 実環境における実ユーザーとコーディングエージェントのインタラクション は、狭い読み方を測定可能なものにしている。コミットされたコードの 99% 超をエージェントが書いたセッションをバイブコーディングとして数え、その割合が 3 か月の観察期間のうちに約 20% から 40% 超へと倍増したと報告している。
- ソフトウェアエンジニアリングのループにおける人間とエージェント は、「ループの外にいる人間（humans outside the loop）」、つまり how のループをエージェントに任せることを、バイブコーディングの一般的な定義と呼んでいる。
- バイブコーディング は、Andrew Connell の説明を記録している。バイブコーディングはコードの所有権を AI に委ねる。エージェント型エンジニアリングは、開発者のエンジニアリング上の判断を運転席に据えたままにする。
- AI ネイティブなエンタープライズ・ソフトウェアエンジニアリングの基盤としての仕様駆動開発 は、AI 支援型の実践の 2 つの原型の 1 つとして、バイブコーディングを仕様駆動開発と対置する。バイブコーディングでは、仕様はワーキングメモリと会話履歴に散らばった暗黙の意図としてしか存在せず、受け入れは振る舞いの観察的なサンプリングに帰着する。同論文は「統制されていない（ungoverned）」という語を、明示的な契約との照合ではなく振る舞いのサンプリングによって受け入れが決まる実践に限定しており、「AI 支援そのものに対してではない（not to AI assistance as such）」としている。
答え 2: バイブコーディングとは対話によってソフトウェアを作ることである
2 つ目のグループのページは、開発者が出力を読み、舵を取る作業も含めて、プロンプト主導の開発全般にこの語を使う。
-
バイブコーディング対エージェント型コーディング：エージェント型 AI の基礎と実践的な含意 は、バイブコーディングを、開発者が生成された各部分をレビューし洗練させる能動的な共同制作者であり続ける、人間中心のモデルとして定義する。これを、自律的なエージェントが複数ステップのタスクを計画・実行する エージェント型コーディング と対置している。バイブコーディング は、この説明が Karpathy の「コードが存在することさえ忘れる」ではなく、通常のレビューを伴う AI 支援型プログラミングに近いと指摘している。
-
バイブコーディング：人工知能との会話を通じたプログラミング は、バイブコーディングを、主にコード生成モデルとのやり取りを通じてコードを書くことと捉える。実践の意味がまだ定まっていなかったため、対象に含める唯一の基準は、プログラマー自身が自分の活動をバイブコーディングと表現していることだった。同研究が観察したコードレビューは、存在しないのではなく、素早く、印象に頼ったものだった。
-
サイコロを振ってソフトウェアを作る：バイブコーディングの質的研究 は、バイブコーディングを、主にプロンプトを通じてソフトウェアを作ることと定義する。この語が、自律エージェントへの全面的な委任から、手作業での編集や点検を伴うエージェント支援型のエンジニアリングまで、幅広い実践を包む傘になっていると指摘している。
-
大規模言語モデルによるバイブコーディングのサーベイ は、これを、実装を「1 行ずつのコード理解ではなく結果の観察によって（through outcome observation rather than line-by-line code comprehension）」検証することと定義する。ところが同サーベイは、この語のもとに 5 つの開発モデルを分類しており、元の定義に最も近いと呼ぶのはそのうち 1 つだけである。バイブコーディングの開発モデル は、その 1 つを Unconstrained Automation Model と名づけ、残りを挙げている。対話型の協働、計画駆動、テスト駆動、そしてそのいずれにも追加できるコンテキスト強化の層である。大規模言語モデルによるバイブコーディングのサーベイ は、このサーベイの枠組みを、意図を述べて品質を判断する人間、プロジェクト、コーディングエージェントの三者関係として紹介している。
-
ソフトウェア開発におけるバイブコーディング：多声的文献レビュー は、36 の文献がこの語をどう枠づけているかを数えている。
枠組み 文献数 割合 社会技術的な開発実践 25 69% 自然言語からコードへの開発、またはプロンプトベースの開発 24 67% エージェント型または半自律的な開発 18 50% コパイロットまたはペアプログラミング 7 19% 同レビューは、バイブコーディングを、検証が取り除かれるのではなく別の場所へ移される反復的な制御システムとして読んでいる。
-
バイブコーディングについての不都合な真実 は、これを広く、すべての行を自分で書くのではなく AI と対話することによってソフトウェアを作ることと定義している。
-
ソフトウェア開発の新時代：バイブコーディングからエージェント型エンジニアリングへ は、欲しいものを説明し、AI が生成したコードを受け入れ、エラーメッセージが出ればそれをチャットに貼り付けて AI に直させることと定義している。
-
Claude Code を活用した予測可能なバイブコーディング戦略 は、Karpathy の意図的に極端な定義から出発するが、実際にはこの語はもっと広く使われていると述べる。同ガイドが扱うのは、LLM が生成を主導する一方で、開発者がコードを読むモードである。
-
バイブコーディングのベストプラクティス：見逃してはいけないこと は、この語から軽蔑的な意味合いを取り除いている。バイブコーディングを、仕様を定め、トレードオフを整理し、実行をモデルに委ね、結果を検証するサイクルとして扱っている。
-
pj-double: メルカリの開発生産性向上に向けた挑戦 — AI-Native化が辿り着いたASDDとプロセス変革の全貌 は、バイブコーディングを、AI に段階的に指示を送り、その出力を見ながら軌道修正することと説明している。これは手放しの実践ではなく、同期的で対話的な実践である。
-
Agent-Spec 駆動開発 は、メルカリの CTO が ASDD を「直感的な」バイブコーディングと対比していることを記録している。
-
エージェント型コーディングのためのミザンプラス: コンテキストエンジニアリングの方法論としての入念な準備 は、バイブコーディングを支配的なワークフローパターンと呼ぶ。開発者が意図を述べ、エージェントがコードを生成し、食い違いは反復的な修正によって直される。
-
AI による仕様駆動開発：新しいオープンソースツールキットを使い始める は、これを、目標を説明すると、正しく見えるが完全には動かないことの多いコードが返ってくるものだと説明している。
-
コードの前にコンテキストを：実践におけるバイブコーディングの経験報告 は、本番志向の 2 つのシステムにおける「対話型（conversational）」のバイブコーディングを調査している。
-
バイブコーディングはオープンソースを殺す は、AI エージェントがオープンソースのコンポーネントを選んで組み合わせることによってソフトウェアを作ることを、バイブコーディングとして出発点に置いている。その際、ユーザーはそれらのコンポーネントのメンテナーと関わらないことが多い。
いくつかの製品やチュートリアルも広い意味でこの語を使っており、中には肯定的に使うものもある。
- Vibe Vibe は、バイブコーディングを、プログラミングの素養がない学習者のための AI プログラミングとして扱い、「Coder から Commander へ（from Coder to Commander）」と言い表している。
- Cloudflare VibeSDK は、自らをオープンソースのバイブコーディングプラットフォームと称している。
- VibeCraft と コードを書かない人のためのプログラミング：VibeCraft の仕組み は、チャット駆動のアプリビルダーを、汎用アシスタントを使ったバイブコーディングの限界への応答として提示している。
- ソフトウェアエンジニアリング：神話を打ち破り、バイブコーディングを迎え入れよう！ は、AI がソフトウェアエンジニアリングにもたらした新しいアプローチの 1 つとして、バイブコーディングを紹介している。
- 「ソフトウェアエンジニア」としての Ralph Wiggum は、自らのループ手法を「完全に手放しのバイブコーディング（full hands-off vibe coding）」と呼んでいる。
2 つの答えが分かれるところ
レビューは実践の一部か
ここで 2 つの答えは互いに排他的になる。Willison のテストでは、コードがレビューされる作業はどれもバイブコーディングではない。広い意味をとる 2 つの文献は、レビューを実践の内側に置いている。
- バイブコーディング対エージェント型コーディング：エージェント型 AI の基礎と実践的な含意 は、各部分のレビューを定義に組み込んでいる。
- バイブコーディング：人工知能との会話を通じたプログラミング は、分析したすべてのセッションで軽いレビューを観察した。
マテリアルからの離脱（Material Disengagement） は、この食い違いの経験的な側面を述べている。調査されたセッションでは、プログラマーはなお差分に目を通し、直接編集やデバッグを行っていた。ただし、それは常態としてではなく選択的にだった。コードはマテリアル（素材）であることをやめてはいなかった。
サイコロを振ってソフトウェアを作る：バイブコーディングの質的研究 は、実践者自身のあいだでの食い違いを報告している。厳密な定義を主張する人もいれば、バイブコーディングと従来のソフトウェアエンジニアリングのあいだに境界を設けること自体を拒む人もいた。
誰がそれを行うのか
Willison は、2 つの出版社と 3 人の著者が「バイブコーディング」の意味を理解していない と Agentic Engineering Patterns（エージェント型エンジニアリングのパターン）について書く において、バイブコーディングをプロの開発者ではない人々と結びつけている。広い意味の側では、コードを書かない人のためのプログラミング：VibeCraft の仕組み が技術的な素養のない人々向けの製品を作っている。Vibe Vibe はプログラミングの素養がない学習者を対象としているが、従来のプログラマーも想定読者に含まれている。
VibeSec の清算 は、「市民ビルダー（citizen builder）」、すなわち AI を使ってものを作る非技術系のユーザーが作ったプロトタイプを取り上げている。エージェント型 AI のためのモデル AI ガバナンス・フレームワーク のガバナンスフレームワークは、エージェントを使ってバイブコーディングするユーザーには、コードの堅牢性をレビューするためのソフトウェアエンジニアリングの専門知識が欠けている可能性があると警告している。自動化バイアス は、同じケースを、自分が承認するものを判断する専門知識を持たない監督者の例として使っている。
経験的研究が見ているのは、別の母集団である。
- バイブコーディング：人工知能との会話を通じたプログラミング のコーパスには、非プログラマーが含まれていなかった。バイブコーディングにはプログラミングの専門知識が必要だという同研究の知見は、それを持つバイブコーダーについてのみ成り立つ。
- サイコロを振ってソフトウェアを作る：バイブコーディングの質的研究 は、プロのプログラマーと、正式な訓練を受けていない人々の両方をバイブコーダーとして数えている。
- プロの開発者はバイブしない、コントロールする：2025 年におけるコーディングでの AI エージェント利用 は、経験のある開発者はバイブコーディングをしないことを見いだしている。彼らは計画と監督を通じて、設計と実装の主導権を保っている。
カテゴリーか段階か
いくつかのページは、この語を、維持すべきカテゴリーとしてではなく、移行の最初の段階として使っている。
- ソフトウェア開発の新時代：バイブコーディングからエージェント型エンジニアリングへ は、これを、ほとんどの人が最初に通過するフェーズと呼んでいる。
- バイブコーディング は、これをプログラミングパラダイムの発展における 1 つの段階として扱い、その段階はチーム規模では不安定だと論じるハンドブックの章を記録している。
- 2026 年のソフトウェアエンジニアリングの最先端に AI が与える影響 は、2025 年初めにはバイブコーディングが主流だったが、今では人々はその代わりに コンテキスト駆動エンジニアリング やエージェント型エンジニアリングについて語っているとしている。
- Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ は、未来を「大規模なバイブコーディングではなく（not vibe coding at scale）」検証されたエンジニアリングとして描いている。
- エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする は、バイブコーディングを 4 つのパラダイムの 1 つとして扱い、そこへの移行を、説明責任、検証、オンボーディングの点で後退的だと呼んでいる。
- エージェント型コーディング は、エージェント型コーディングをバイブコーディングの代替ではなく、それを補完するものとして提示している。この説明では、バイブコーディングによる探索的なプロトタイピングが後のフェーズにつながっていく。
- Sequoia Ascent 2026 のまとめ は、Karpathy 自身の 2026 年の枠組みを伝えている。バイブコーディングは底上げ（raises the floor）をもたらし、エージェント型エンジニアリングは天井を引き上げる（raises the ceiling）。
バイブコーディングではないものに与えられた名前
語を狭く保つと、残りを指す語が必要になる。以下の各ページは、それぞれ異なる語を提案するか使用している。
名前同士も互いに競合している。バイブエンジニアリング は、同じ考えについては「エージェント型エンジニアリング（agentic engineering）」が優勢になりつつあるようだ、という Willison の 2026 年 2 月の追記を記録している。エージェント型エンジニアリング は、この語が「バイブコーディング」が 2 つの異なる活動を覆ってしまうのを止めるために提案されたこと、そして「バイブエンジニアリング」をめぐる数か月の議論の後に登場したことを述べている。
仕様駆動開発とは何か？ 実践者のためのガイド（と、使わないほうがよい場合） は、各手法が真実をどこに置くかによって、関連する線を引いている。バイブコーディングでは、それは最後のプロンプトである。TDD ではユニットテスト、BDD では振る舞いの例、仕様駆動開発では承認された仕様である。
狭い線は保たれているか
狭い陣営のページ自身が、その立場が劣勢になっていることを報告している。
- 意味の拡散（Semantic Diffusion） は、Willison が 2025 年 3 月に、Martin Fowler のこの用語をバイブコーディングの受け止められ方に当てはめたことを記録している。この語の定義は、広まるにつれて弱まっていた。
- 2 つの出版社と 3 人の著者が「バイブコーディング」の意味を理解していない は、この語をプロの仕事に使った 2 冊の本をきっかけとしている。Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond と、後に改題された Beyond Vibe Coding である。同記事は、この議論にはおそらく負けたと認めている。
- Karpathy の返答は、バイブコーディング と 意味の拡散（Semantic Diffusion） が記録するところによれば、定義が落ち着くには時間がかかるというものだった。彼は、自分自身が全面的なバイブコーディングをすることはめったにない、とも付け加えた。
2026 年までには、この侵食は反対側からも見えるようになっている。
- バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている は、Willison が本番の作業も含めて、エージェントの書く行をもはやすべてはレビューしていないことを報告している。彼は自分の実践の中で 2 つのカテゴリーの境界がぼやけつつあると述べ、そのリスクを逸脱の常態化（normalization of deviance）と名指している。
- ソフトウェアエンジニアリングのループにおける人間とエージェント は、仕様駆動開発のいくつかの解釈は、バイブコーディングとほとんど変わらないと述べている。
- 仕様駆動開発 は、バイブコーディングのソリューションではないと説明されながら、人間のチェックポイントなしに単一のプロンプトから実行するとバイブコーディングのように振る舞う、ある仕様駆動のプラグインを記録している。
- プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 は、エビデンスの裏づけがなければ、エージェント向けのプロセスフレームワークは、用語を増やしただけでバイブコーディングを制度化するにとどまるおそれがあると警告している。
それぞれの答えが適するとする場面
どちらの読み方でも、各ページはおおむねバイブコーディングの居場所を、プロトタイプ、個人用ツール、使い捨ての作業に置いている。違うのは、何がそれを排除するかである。
レビューの欠如。 狭い陣営の反論は、誰もコードを読まないという点にある。
- AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） は、その条件として、リスクが低いこと、秘密情報と個人データに注意を払うこと、他のサービスにかける負荷、そして課金に厳格な上限を設けることを挙げている。
- Claude Artifacts は、同記事が挙げる、読まれていないコードが到達できる範囲を制限するサンドボックスの例である。
- Cursor は、同記事が挙げる、安全柵がはるかに少ないツールの例である。
- バイブコーディングとエージェント型エンジニアリングが、望む以上に近づいている は、バイブコーディングを、バグが自分だけを傷つける個人用ツールにはすばらしいが、他人のためのソフトウェアを作る場合にはひどく無責任だとしている。
構造的な限界。 広い意味を使うページは、別の点を指摘している。
- 仕様の欠如。 バイブコーディングについての不都合な真実 は、バイブコーディングで作られたプロジェクトが 3 か月ほどで壁にぶつかると報告し、その原因を仕様なしに作ることに求めている。同記事のルールは、ユニットテストや機能テストで出力を検証できるなら、その範囲はバイブでやってよいほど小さい、というものだ。
- アーキテクチャ。 コードの前にコンテキストを：実践におけるバイブコーディングの経験報告 は、バイブコーディングがスキャフォールディングには信頼できるが、テナント分離、アクセス制御、非同期処理については、それらを明示しない限り信頼できないことを見いだした。委任不可領域 は、そうした領域を名指している。
- チームへのスケーリング。 エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする は、5 つの限界を挙げている。再現不可能性、監査不可能性、移転不可能性、レビューの飽和、ノイズのスケーリングである。
- 実践の共有。 pj-double: メルカリの開発生産性向上に向けた挑戦 — AI-Native化が辿り着いたASDDとプロセス変革の全貌 は、バイブコーディングの同期的な性質のせいで、各開発者の判断がチャットログの中に取り残され、透明性も再利用性もないままになると指摘している。
ほかのページは、具体的なコストを挙げている。
- 信頼の負債（「バイブコーディング」をやめ、新世代のソフトウェアエンジニアリングを受け入れよう による）
- 高速統合の負債
- コンテキストモメンタム
- サイコロを振る（Rolling the Dice）
- レビューのボトルネック
- VibeSec の清算 のセキュリティインシデント。これが セキュリティコンテキストファイル につながった
- Antigravity CLI と SDK による AI 支援コードレビュー のセキュリティレビューの前提
- バイブコーディングはオープンソースを殺す がモデル化した、オープンソースのメンテナーへの影響
実践者も、自分の仕事から同じ限界を述べている。
- AI に t-wada の TDD を頑張らせる は、放置されたバイブコーディングが使いものにならない出力をしばしば生むことを見いだしている。
- エージェント型 AI はシンプルに：ソフトウェア開発のための実践的ワークフロー は、長期的に予想される問題を理由に、バイブコーディングを見送っている。
- 2025 年の AI コーディングのトレンド：エージェントによる 10 倍の生産性増幅の下で広がる「粪围」 は、AI が既存の習慣を増幅する様子が最もはっきり現れるのはバイブコーディングだと見ている。
- AI 時代における開発チームの組織化 - Part III は、統制の甘いバイブコーディングを、保守の難しい「AI スロップ（AI slop）」と結びつけている。
- ACP プロトコル＋複数の AI コーディングエージェント：企業の研究開発のための新たな生産性プラットフォーム は、人が自分のコードに責任を持ち続けるエンタープライズの仕事を、バイブコーディングのデモと対比している。
- メルカリ Web モノレポでエージェントを飼いならす（AGENTS.md で再述）は、プロジェクトがバイブコーディングで書かれた CSS には頼れないと述べている。
- ソフトウェア開発 PBL における AI エージェントを用いた仕様駆動開発の導入に関する実践報告 は、アプリケーション開発を教える授業には、バイブコーディングより仕様駆動開発のほうが適していると判断している。
- 新しいソフトウェアライフサイクル は、境界線を AI の利用そのものではなく、検証に置いている。
両陣営のいくつかのページは、肯定的な論拠も示している。
- AI ネイティブなエンタープライズ・ソフトウェアエンジニアリングの基盤としての仕様駆動開発 は、アイデア出し、プロトタイピング、学習、アクセシビリティにおいて、バイブコーディングを正当なものと認めている。
- バイブコーディング は、バイブコーディングによって非エンジニアがプロトタイプを自然言語で表現できる、という Connell の主張を記録している。
それぞれの答えの裏づけ
狭い答えは、測定ではなく議論に基づいている。AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） は明確に定義をめぐる記事であり、Karpathy の文言と著者自身の実践を根拠として挙げている。
広い答えは主に経験的研究やサーベイの文献が使うものであり、その文献はまだ新しい。
- 配信されたセッションの研究。 バイブコーディング：人工知能との会話を通じたプログラミング は、プログラマー自身がそう表現した場合にのみセッションをバイブコーディングとして数えたので、測っているのは固定された定義ではなく、人々がこの語をどう使っているかである。サイコロを振ってソフトウェアを作る：バイブコーディングの質的研究 は、自らを、何をバイブコーディングとみなすべきかの定義ではなく、スナップショットだとしている。
- 文献レビュー。 ソフトウェア開発におけるバイブコーディング：多声的文献レビュー は、自らのコーパスを、初期段階の提案中心のものであり、その 40% がグレー文献だと説明している。大規模言語モデルによるバイブコーディングのサーベイ は、この実践についての経験的研究には縦断的な検証が欠けていると指摘している。
- 新しく、争いのある用語。 AI ネイティブなエンタープライズ・ソフトウェアエンジニアリングの基盤としての仕様駆動開発 と エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする はどちらも、自らの中心的な用語を、新しい、あるいは争いのあるものと呼んでいる。
定量的な知見は、いずれもまず定義を採用し、それに照らして測定している。
- SWE-chat: 実環境における実ユーザーとコーディングエージェントのインタラクション は、99% のしきい値を使っている。
- バイブコーディング：実践、性能、生産性、リスク ── 最先端レビュー は、Willison の境界を使っている。
したがって、あるページの数値は、そのページ版のこの語を測ったものであり、ほかのページが使うこの語を測ったものではない。