「(笑)」を最初に付けたのは Karpathy 本人
2025年2月2日の Andrej Karpathy のポスト（原文）:
I "Accept All" always, I don't read the diffs anymore. (...) It's not too bad for throwaway weekend projects, but still quite amusing.
最後の still quite amusing から分かります通り、「バイブコーディング」という言葉を産んだ本人が、最初から自嘲気味に笑っています。
Karpathy が提案したのは、「新しい正しい開発手法」ではありません。「使い捨ての週末プロジェクトに限れば悪くない遊び方だ。diff は読まない。エラーメッセージは何も考えずに貼り返す。直らないバグは迂回する。」…彼はそれを手放しで勧めてはいるのではなく、範囲を限定した上で、自分で笑ってみせています。
バイブコーディングの定義
「バイブコーディング」は Collins Dictionary の2025年 Word of the Year に選ばれましたが、その定義は「自然言語でAIに指示してコードを書かせること」です。
使い捨て限定という条件や quite amusing という自嘲は、定義からは跡形もなく消えてしまっています。
言葉が但し書きを置き去りにし、独り歩きしただけ。
バイブコーディング(笑) と揶揄されるのは、throwaway weekend projects という但し書きを外しそれを「本番に持ち込んだ」からです。
笑われているのは道具（手段）ではなく、適用範囲の詐称のほうだと言えます。
私の基準
では何を満たせば詐称にならないのか？ とりあえず適当に3つ考えてみました。
- 毎回同じ品質のものを出せるか？
- 公開できるか？
- 公開したものに責任を持てるか？
一見正しそうにも見えますが、これらにはすぐさま反論が思い浮かびます。
反論1: 「毎回同じ品質」は無理
人間でもこれは無理ですね(笑) ベテランでも、金曜の夕方に書くコードと月曜の朝のコードは違います。この基準を厳密に当てると、人類のコーディングは全部バイブコーディングになってしまいます。
更にLLMは、構造的に非決定です。同じプロンプトから同じ結果は出てきません。非決定な生成器に決定性を要求している時点で、原理的に無理な注文です。
よって、正確には「合格ラインを下回ったら止まる」ですね。品質の再現性ではなく、検査の再現性。
再定義1: 毎回同じ品質を出せるか → 品質を測るテストがあり、そのテストに穴が無いことを別の手段で確かめているか？
反論2: 「公開できるか」は環境に依存しすぎ
業務コードの大半は、公開できません。
また、公開されている酷いコードも星の数ほどありますので、公開は品質を何も証明しません。
私が「公開できるか」で測りたかったのは、要するに「他人の目に耐え得るか？」であり、これは Simon Willison の基準がそれにピッタリ当てはまります。（原文）:
I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else.
（それが何をするのか他人に正確に説明できないコードは、リポジトリにコミットしない）
同じ記事で、彼はバイブコーディングの定義そのものにも踏み込んでいます。
If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly (...) that's not vibe coding, it's software development.
（LLMが書いたコードでも、あなたがレビューして、きちんとテストしたなら、それはバイブコーディングではない。ただのソフトウェア開発だ）
これが決定的です。
バイブコーディングかどうかは、コードを見ても分かりません。 同じコードが、読まれずに出てきたのか読まれて通されたのかは、コードの外にありますので、AIが書いたコードか否かを判定しようとする議論は、最初から的を外しています。
再定義2: 公開できるか → 何をするコードかを、他人へ正確に説明できるか？
反論3: 「責任を持てる」は精神論
「責任を持ちます！」と言うだけならタダですし、言った瞬間には何も担保していません。
ここで使う責任という言葉の実体は、3つに分解できます。①壊れたことに気づけるか、②直せるか、③戻せるか。
例えば2025年7月、AIエージェントに本番DBを消されたという記事が大きな話題となりました。（The Register / Fortune）。
「バイブコーディングに最も安全な場所」を掲げていたサービス（Replit）で、1,200人以上の役員＆1,190社以上の企業データがAIエージェントにより抹消され、AIから「ロールバック不能」だと報告された…という笑えない事件です。1
この事件の教訓は「AIは危険」ではなく、本番と開発とが分離されておらず、ロールバックが検証されていなかったことです。
であれば、AIを賢くする方向でなくとも、AIが間違っても戻せる仕組みを用意することで、同じ過ちは防げます。
再定義3: 責任を持てるか → 壊れたら気づけて、直せて、戻せるか？
再定義まとめ
| 当初（意思の言葉） | 再定義（仕組みの言葉） |
|---|---|
| 毎回同じ品質のものを出せるか | 品質を測るテストがあり、テストの穴を別の手段で確かめているか |
| 公開できるか | 何をするコードか、他人へ正確に説明できるか |
| 公開したものに責任を持てるか | 壊れたら気づけて、直せて、戻せるか |
左は全部「『人間が』頑張る」。右は全部「『仕組みが』担保する」。3つとも主語を『人間』から『仕組み』へと変えれば腑に落ちます。
結論: 詐称しなければ問題ない
バイブコーディングは、悪ではありません。
バイブコーディングは、Karpathy の定義通り、使い捨てには最適です。週末に作る自分用ツール、動くか分からないアイデアの検証、捨てる前提のプロトタイプ…そこには静的テストもロールバック計画も必要ありません。
Willison の線引きは明快で、低リスク・セキュリティ影響なし・金銭的エクスポージャーなし・外部への影響なし。これらを満たすなら、diff を読まずに Accept All を押せばOK。それは怠慢ではなく、正しい道具選びだと言えます。
Harness engineering（ハーネスエンジニアリング）
そもそも私自身が、ここ2,3ヶ月ぐらいほぼコードを書いていません。
心血を注いでいるのは、AIが迷わず・間違えない「仕組み」を用意することであり、私の業務範囲であれば、その仕組みと今のAIの能力を持ってすれば、先に挙げた3点を満たせてしまうからです。
- 品質を測るテストがあり、テストの穴を別の手段で確かめているか？
- 何をするコードか、他人へ正確に説明できるか？
- 壊れたら気づけて、直せて、戻せるか？
この3条件に、AIの話は1つも入っていません。これらは昔からず～っとプロの開発の条件です。
また、私よりも遥かに優秀な世界トップレベルのエンジニア層の中にも、「もうコードは書いてない」という趣旨の発言をする人は少なからずいます。有名なのは、Anthropic の Boris Cherny 氏ですね。
嘲笑の対象は詐称
笑われるのは、バイブ「だけ」で作ったものを「ちゃんと作りました」の顔で出したときです。(笑) は品質ではなく、詐称に対して付くのです。
バイブコーディングは、新しい問題を作ったわけではなく、ごまかしのコストを劇的に安くしただけだと言えるのではないでしょうか。
-
この事件がエンジニア界隈を震撼させた最大の理由は、AIがDBを消した後に、ミスを隠蔽するために架空データを生成し穴埋めしようとした上で、「全バージョンを破棄したためロールバック不能」と嘘の報告をした…という点にありましたが。※実際には復旧可能だった。 ↩