- VibeコーディングはAIの助けを借りて直感に従ってコードを素早く書く手法であり、最終的には理解できないコード、つまりレガシーコードを残すことになる
- レガシーコードとは誰にも理解できないコードのことで、技術的負債や保守上の問題を招き、新機能を追加する際のエラー発生可能性も高い
- Vibeコーディングはプロトタイプや短期プロジェクトには迅速な開発手段となりうるが、長期的に保守する必要があるプロジェクトには不向きである
- 非専門家が大規模プロジェクトをVibeコーディングするのは、子どもにクレジットカードを渡すようなものという危険性がある
- 2025年においても、AIとともに開発する際には慎重さと理解度を保つことが重要である
Vibeコーディングとは何か
- Andrej Karpathyは**"Vibeコーディング"**という用語を、AIがコードを書き、ユーザーがコードそのものの存在を忘れるほど気にしないプログラミング手法として定義している
- このアプローチは、開発者が書かれたコードの内部をまったく理解していなくても成果物を得られる点で、従来のソフトウェア開発とは異なる
レガシーコードの問題と技術的負債
- 誰にも理解できないコードは、すでにレガシーコードである
- こうしたコードは維持・保守に多くの時間を要し、バグや新機能追加の際にも問題が大幅に増える
- プログラミングの本質はコードを大量に作ることではなく、概念的な理論を構築することだと強調している
Vibeコーディングとプロトタイピング
- Vibeコーディングはプロトタイプ開発や使い捨てプロジェクトにおいて、素早い着手と開発を可能にする
- もし後続の保守が必要ないのであれば、コードの内部を知らなくても大きな負担にはならない
- そのため開発速度を大幅に高め、新しいアイデアを試すのに非常に適している
Vibeコーディングの理解度スペクトラム
- Vibeコーディングは、開発者のコードに対する理解度が低いほど、よりVibeに寄ったやり方になる
- 基本的に、エンジニアが要件をより明確に理解するほど、Vibeコーディングの度合いは下がる
- 非プログラマーがWebとネイティブアプリの違いや、データの保存方式も分からないままコーディングを依頼すると、一般により多くのVibeコーディングが発生する
非専門家による大規模Vibeコーディング: クレジットカードに似ている
- 非専門家がVibeコーディングで大規模プロジェクトを作り、それを維持しようとするのは、仕組みを理解しないまま子どもにクレジットカードを渡すことに近い状況である
- 最初はすべてが簡単に見えるかもしれないが、その後に莫大な保守コストと問題がついてくる
- 結局「請求書」が届いたとき、問題解決能力が不足していれば、むしろ状況を悪化させる可能性がある
2025年のAI時代における真剣な開発
- Andrej Karpathyは、AIとともに進める開発では慎重さと注意深さ、そして既存コードについて継続的に学ぶ姿勢が不可欠だと強調している
- AIの過剰な自信から身を守り、良いコードと悪いコードを見分ける人間の判断力が重要である
- 単にAIに任せるのではなく、必ずコードを自分で読み、理解しなければならない
Val TownのAIツール活用
- Val TownはTownieというAIアシスタントを通じて、コード作成、実行、確認、反復的な改善プロセスを自動化している
- TownieはVibeコーディングに適したツールであり、用途に応じて自由に使うことも、厳格に制御することもできる
- AIとともに開発する方法は非常に速いペースで進化しており、複雑なソフトウェア開発において理論的土台の重要性は今後も変わらない
非専門家による無分別なVibeコーディングへの警告
- 非プログラマーが数千ドルを費やして巨大なアプリアイデアをVibeコーディングするのは、良い方法ではない
- 最終的には、誰であってもコードの内部を直接読み、分析する人間の目が必要であり、理解不能なレガシーコードを修正するより、最初から作り直して適切に設計するほうが効果的である
結論と助言
- 複雑なソフトウェアを構築する際には、理論的基盤が中核となる
- AIの進化によってプログラミングのやり方は急速に変わっているが、人間の開発者の専門性は依然として重要である
- 非専門家がAIで大規模アプリを作ろうとするなら、結局はコード全体を読み直し、一から作り直したほうがよい場合もある
12件のコメント
クレジットカードを子どもに渡すのと同じだという比喩
適切な比喩ですね
あるいは、子どもにナイフを渡すことにも例えられるかもしれません
AI生成コードにコメントまで付けてくれて、コードフロー図なども描いてくれるコード生成AIが出てくれば、ある程度は助けになるでしょうね。
かなり共感できる話です。実際に一部は自分でも経験していたりしますし……
モデルの性能変化によってこのあたりがどう変わっていくのかも気になります。
あまりにもその通りな話で、思わず膝を打ちました。コードを知らない人はバイブコーディングをすると「わあ」となりますが、コードを知っている人は「なぜ？ こんなふうに？」となります。
コメント欄の状態がひどいですね
では、自動車はその内部構造をすべて理解するまで永遠に乗れないということですか？
内部構造を理解しないまま自動車を作ること = バイブコーディング
乗ることはできるでしょう。でも、作ることはできないでしょう。
手法や技術の問題だと考えて、ただAIを使わずにオーガニックな手書きコーディングをすべきだと言う人たちは、工学電卓ではなくそろばんを弾いたり、Excelの関数を使わずに手書きで作成するのが真理だと言う人たちのように見える
それは誤った比喩です。工学用計算機は、計算機やExcelと同じように、入力値に応じて結果が正確に出ます。もしAIがユーザーの予測した結果をそのまま出力するのなら、これまで数多く登場してきた新技術とそこまで大きく異なる技術ではなかったはずです。時間がたつほどセキュリティとハルシネーションへの懸念が大きくなる理由でもあります。つまり、Gen AIはコントロールできないということです。現在のLLMの限界を理解し、適切な場所で使われるべきです。
現在、バイブコーディングはまだ黎明期であり、来年や再来年には成熟した開発方法論になると見ています。DevOps が AIDevOps になるように、AI Agile または Vibe Agile になるだろうと思います。
Hacker Newsの意見
非開発者の友人についての話。友人は昨年、自力でSaaSをコーディングしてローンチし、ほとんどマーケティングなしで口コミとインバウンドだけで収益を上げ始めた。開発にはReplitとSupabaseを使っており、顧客からのフィードバックを受けながらアプリがどんどん複雑になっていったことを考えると、本当にすごいと思う。私の考えでは、この市場には既存の事業者が2社いて、友人がはるかに安い月額料金でよりモダンな製品を見せたため、その2社は面白くなかったのだと思う（既存製品はどちらもWindows向けデスクトップソフトウェア）。そこで彼らはハッカーを雇って友人のSaaSを攻撃させたが、このハッカーたちは金銭要求なしで攻撃していた。不運にも、友人は経験なしに急いでコーディングしていたため、脆弱性が多かった。第一に、フロントエンドコードにユーザー一覧が露出しており、ハッカーは全顧客にメールを送ってしまった。第二に、ハッカーがStripeキーを入手し、全顧客に返金処理を行った。第三に、今でもハッカーがXSS攻撃を試みており、時々フィールドに
<script>alert()</script>のようなタグが現れる。私の結論は、経験のない人がvibe-codingをすると、すぐに技術的負債が積み上がるということだ。しかし同時に、この友人がエンジニアリング経験なしで数か月のうちに事業性のある製品を証明したという事実には驚かされる。今は開発者を雇って補強中だ。このような粗くてセキュリティ脆弱なコードで、数百ドルの投資だけで十分なビジネスの可能性を実証できたのだから、結局その過程には価値があったと思う競合他社の仕業だと仮定するのは、むしろ責任逃れのように思える。実際には、単に自動化された脆弱性スキャナがサイトを見つけ、あまりに杜撰だったのでハッカーが侵入して悪ふざけした、という方がもっとありそうだ。インターネット接続されたサービスでこういうエクスプロイトトラフィックをよく見る人なら分かるはず
これは、エンジニア経験なしに家を建てて、誰かが来てただ蹴っただけで崩れてしまったのと道徳的には同じことだ。問題はvibeコーディングそのものではなく、重要な意思決定をするために必要な知識が不足していることにある。こうした問題は法的責任の問題にまで発展しうる
市場に既存の事業者がすでにいたのなら、事業性の証明にわざわざこんなMVPが必要だったのだろうか。本質的には、安く提供すれば人々が既存の供給者から乗り換えるかどうかを試す必要はない。友人が得た教訓は、一部の顧客は当初料金を払うだろうが（リピート率のデータはない）、最終的には本物の製品を作るために人を雇わなければならず、そうなると価格競争力も落ちるだろうという点だ。本格的にマーケティングへ投資しなければならない段階になれば、悩みは多くなるはずだ。結局また思い知らされるのは、アイデアだけでは何の価値もなく、実行力こそが肝心だということだ
君の友人が大した責任も負わずに事業を続けられること自体が、この業界の根本的な問題だ。もしソフトウェアが他の工学分野のように厳格に管理される世界なら、開発者や企業は顧客情報流出に対して法的責任を負わざるを得なかったはずだ
事業そのものは証明できたとしても、顧客の立場では利益ではなく損失かもしれない。お金を払って使いながら重要なデータをセキュリティ上脆弱な場所にさらし、製品がまともに動いているかどうかすら不明な状況だからだ。今後は開発者を雇って補うというが、思っているほど簡単ではないはずだ。AIが学習資料や生産性、学習ツールとして使われるなら賛成だが、人間が途中で介在しなければ恐ろしい結果物になりうる
以前にも、非開発者やジュニア開発者がMicrosoft AccessやExcelなどで簡単にアプリケーションを作って配布した例は何度もあった。そのときも限界や拡張性の問題、運用の悪夢は多かったが、同時にこうした流れが登場したことで、専門開発者たちもより良いソリューション開発に拍車をかけた。PCが大衆化したときも同じで、メインフレーム開発者たちはPC世界の「めちゃくちゃ」なコードを見て愕然としたものだ
私はほぼ30年以上ソフトウェアエンジニアとして働いてきて、この投稿のコメントを全部読んだ。だが、vibe codingを批判するほぼすべての根拠は、私がこれまで見てきた「人間が書いた」あらゆるコードベースにも同じように当てはまると思う（もちろん例外はある）
捨てるために作るプロトタイプの何が悪いのか分からない。事業開始において最も重要な段階だ。レガシーコードも同じだ。実際に収益を生んでいるコードの大半は、その組織内の開発者から見ればすでにレガシーと見なされている可能性が非常に高い
冗談で、trunkにマージされた瞬間から全部レガシーコードだ、という言い方がある
少しは同意するが、vibe codingの問題は、ろくに調査もせず、既存コードベースの構造や必要なソリューションが何かも研究しないまま、無理やり突っ込めてしまう点だ。昨日だけでも、Rustに不慣れな同僚がvibe codingで新機能を作ったが、表面上は「動いて」いても実際にはひどいものだった（tokioのasyncコンテキストで同期I/O、ロック、自前チャネル実装など）。すでに安全な非同期抽象化があるのに、新しく間違った抽象化を作ってしまっている。自分で調べるか先に助けを求めていれば、既存コードの例を参考にできたはずだ
すべてのコードはいつかレガシーコードになる。私がジュニアだった頃から、同僚のジュニア開発者たちが書いた数多くの本番スクリプトやサービスコードをレビューしてきた経験からすると、こういう絶対主義的な見方は行き過ぎだ。この問題はほとんどの組織で繰り返される。LLMベースのコード品質を批判する文章を書くのも理解できるが、キャリアを通じて他人が作ったシステムを修正・拡張・リファクタリングしてきた開発者なら、この現実をもっとよく知っているはずだ。ソフトウェアエンジニアリングの世界に、機械工学のような一貫性、認証、責任、実質的な結果に対する厳格な基準と法的リスクが導入されない限り、この論争に大きな意味はない。現代IT産業そのものが、まったく逆の哲学、つまり「agile」「素早く作って、壊れても構わない」に基づいている。素早く、設計を最小限にして頻繁にリリースし、問題があればロールバックし、障害が起きても「仕方ない」とする空気だ。ソフトウェアはおもちゃのように扱われている。1%だけがきちんとやっていると自負するかもしれないが、大半はそうではない
今、面白いことが起きている。エンジニアリングをよく知らない人たち、そしてある程度は知っていても正しく説明しない人たちまでが、オンラインで誤ったナラティブを広めている。彼らは、ジュニア開発者が10倍生産的になり、PMですら自分でコードをデプロイしていると主張する。だが少し目を閉じて、そういう状況から生まれたコードを想像してみれば、それは100%レガシーコードであり、捨てられるコードだ。問題の本質は、AIやPMがFigmaから直接コードを吐き出す能力でも、ジュニアがプロンプトを乱発することでもない。期待と実態が乖離する本当の理由は、本来何年もかけて議論し定義されてきた用語や概念を、きちんと区別できていないからだ。
リーンプロトタイプとdisposableプロトタイプ（MVPですらない）は別物だ。MVPは、リーンプロトタイプの検証が成功して初めて作れる。製品はMVPともまた別だ。
vibe codingツールはdisposableプロトタイプを素早く作るには最高で、LLM搭載IDEは本物の製品を作るのにより適している。現段階では、本当のエンジニアだけがLLMプロンプトでリーンプロトタイプをコーディングできていて、他の人たちはdisposableコードで動く単純なソフトウェアを作っているだけだ
「製品はMVPと違う」と言ったが、この言葉を自分が働いたほぼすべての会社に伝えたい。最近は取締役会やCレベルが「今四半期中にとにかく何か出せ」という姿勢であふれていて、開発者はMVPを作ったらすぐ次のプロジェクトへ移ってしまう。本当にvibe codingかどうかに関係なく、現実には機能が豊富に見えれば、実際の品質に関係なくビジネス指標は上がる。実のところ、本物のエンジニア（今ではこういう人たちを「開発者」と呼ぶようだ）が主体的にプロトタイピングする環境は多くない。ゲーム業界や一部のテック企業でしかあまり見ない。大半はひたすらMVP作りに集中している。vibe codingは、MVP量産の速度を上げるだけで、そのぶん品質が犠牲になる
「用語の定義」が実体なく混用される傾向は、この10年で業界内ではっきり強まってきた。これらの用語はもともと、数多くの本や議論、長い時間をかけたさまざまな論争を通じて文脈が積み重なってきた言葉だ。熟練開発者が一つの単語を使うとき、その中にはそれまでの経験と議論の文脈がすべて詰まっていた。ところが新しく入ってきた人たちは、その文脈なしに表面的に単語だけを「コピー」して、意味も定義せずそのまま使ってしまう。結果として、誰も各用語が本来何を意味していたのか、なぜその状況にふさわしい言葉なのかを把握できなくなる。たとえば、"'agile', 'technical debt', 'DevOps', そして最新の ‘vibe coding'" などだ。HNには semantic driftについての投稿 も上がっていた。ソフトウェア業界ではよくある現象だ。
技術的な例としては、JavaScriptで 'object'、'JSON'、'dictionary'、'hashmap' を全部混同して使うケースがある。本来それぞれ意味が違うのに、JS開発者にはただの 'object' として通ってしまう。だから、言語的・概念的な解像度が一つの「ピクセル」にまで潰れてしまうようなものだ
昔は開発者同士で、コードに対する「構え」が違うと話していた。だが今は、誰もコードを理解できないことで生じる開発者の疲弊がものすごく増えている。以前なら、こういう状況ではエンジニアが前に出て壊れた部分を使えるように直し、アーキテクトが複雑さを減らす、といった対応があった。今はLLM時代になり、100倍のコードが流れ込んでくるのに、エンジニアやアーキテクトはこの流れから完全に排除されている。これが私たちが肌で感じている現状だ。
もしこの問題を解決するテスト手法（TDD MCPサーバー、DDD MCPサーバー、あるいは何らかのワークフロー／アーキテクチャでもいい）を考案できれば、兆ドル級スタートアップになれる可能性がある。コードレビューの効率を大幅に高め、スケールできるツールが切実に求められている
まず「動くソフトウェア」の定義をもっと明確にすべきだと思う。たとえばLLMが作ったUIはどれも似たように見え、微妙に間違っていたりバグが潜んでいたりする。ユーザーテストを一度やればすぐ問題が露呈する。また、生成UIはすでにトレンドに執着するだけで、新しい何かを生み出せないこともある
大企業の社内向けコードの書き方を見たことがあるか？ vibe codingと大差ない。むしろLLMをペンテスト通過向けにチューニングすれば、何かしらやろうとはする。大企業はただ気にしていないだけだ
実際のところ、すべてのコードはレガシーだ。だからvibe codingがコードを速く大量に生み出すからといって、特別なわけではない。結局、誰にも理解できない「自分の手で書いたコード」も同じくらいひどい。すべてのコードは、保守の観点では結局ただの重荷だ。ライブラリも問題を減らしてくれるにすぎず、頻繁に変わるものやインターフェースが古びたものは、さらに最悪のレガシーになる。
長くコードを書いてきた人ほど、結局のところ答えは「作る量を減らすこと」、つまり全体として必要性そのものを減らすことだという結論に行き着く。あらゆる複雑さは結局、「未来の自分が覚えていない問題」になる。実際には要件もその都度変わるし、専門家が語る要件でさえ間違っていることがある（そしてその「専門家」が自分自身であることさえある）
「すべてのコードはレガシー」という主張には同意しない。中には小さくて、開発者がいまだに頭の中ですべてを把握している、完全に「ライブ」なコードもある。レガシーの実質的な定義は、大規模でありながら組織内に現在のオーナーが誰もいないコードだ。vibeコードは生成された瞬間にその二つの条件をすでに満たしている
レガシーとは、もはや利害関係者が残っておらず、保守も文脈把握も難しくなった状態を指す
できるだけ少ないコードで問題を解決したい。コードが自分の問題にならない状態を作るのが肝心だ。抽象化がどれだけ「漏れるか」が重要で、今LLMが作る抽象化はかなりひどい。今後どこまで改善するかは分からない。
もっと面白く、簡単で、安くコードを理解できるツールに投資したい。友人のGlenが参考になるかもしれないプロジェクトをやっている: https://glench.github.io/fuzzyset.js/ui/
Geoffrey Littが言うように、LLMは私たちのコード理解を助ける一時的な可視化ツールやデバッガーなどを作る方向で、ずっと有用かもしれない
すべてのコードにリスクはあるが、すべてがレガシーというわけではない。vibe codingされたコードは、そもそも文脈や持ち主がないので、最初からレガシーになる感じがする
すべてのコードがレガシーかという反論に対して言えば、自分が非常に深く理解しているプロジェクトで、バグの原因を一発で特定でき、新機能の実装を頭の中で描けるなら、それはレガシーではない
私の考えでは、「コードを数学として見る時代」は終わった。現実世界と結びついた十分に大きなソフトウェアは、数学的証明のように完全に真であることを保証できない。現実のシステムは、形式的保証、経験に基づく設計、実験的テスト、ノウハウ、パフォーマンス基準などに依存する工学的産物だ。
この傾向は最小のスクリプトにまで広がっていくだろう。大半のソフトウェアは数学的に証明される必要すらない。ただ目的を達成すればいい。プログラミングの職人的な側面は十分に認めるが、もうその部分は手放すべき時だ。
結論として、未来は次の二択のどちらかになる
10万行、50,000件のテストですべての要件を保証するが、誰にも読みにくいプログラム、総コスト5万ドル（APIトークン費用）
人間が直接設計し、30,000行、3,000件のテスト、洗練された抽象化で、同じ要件を満たす、総コスト30万ドル（開発者人件費）
私がソフトウェアの消費者なら、細かい内情には興味がなく価格だけを見るなら、間違いなく6倍安い方を選ぶ
新たな外部要件による変更が必要になったときを考えるべきだ。そういう場合、そのソフトウェアがビジネスの中核なら、すぐにベンダーを切り替えざるを得なくなる。だからB2BでもB2Cでも、保守とサポートは必ず重要になる。ソフトウェアは常に変化へ対応できなければならない
つまり「このコードは私とCopilotだけが理解していた。今ではCopilotだけが知っている」という冗談も出てくるわけだ
「現実世界と結びついた十分に大きなシステムは数学的に正しいと証明できない」という点については、形式検証に携わる人たちは激しく反論するかもしれないし、内心では同意するかもしれない
その二つのシナリオなら、バージョンアップ時にどちらがより安く、より速いかを問うべきだ。今のところは人間開発者モデルの方が安いと思うが、将来は断言できない
実際には、その二つの選択肢のどちらもほとんど見たことがない
究極の発展段階は、人間が読む必要すらない、完全に機械指向のプログラミング言語なのではないかと思う。LLMがわざわざPythonやSwiftのような、人間にとって分かりやすい言語へ変換する必要があるだろうか。単にそのまま動く結果だけがあればよく、もはや保守という概念自体が無意味になる。まだその段階ではないが、いつかはここへ向かう気がする
良いソフトウェアとは、常に保守され続けるものだ。新しい要求は際限なく出てくるのだから、一度機能を出したら永遠に終わり、という考え自体が冗談だ。将来の変化を見越して作られたコード、テスト、ドキュメントが重要なのはそのためだ。LLMが無意味なブラックボックスコードを量産するなら、それほど恐ろしいことはないと思う。LLMが人間並みのコーディングに到達し、それを誰も気にしなくなる、というのはSFの領域だ。コーディングは、実際に役立つソフトウェアを作る全工程の一部にすぎない
実際、機械語がすでにそういうレベルではないか？ LLMは人間が読むインターフェースに最適化されているから、JSONは作ってもBSONはほとんど使わない
これがいったいどんな問題を解決するのか疑問だ。生み出される問題の方は明らかだが
まるでLLMが人間向けのコードを学習し、それをそのまま出力し、またコードを回して望む動作を得る、一種の「伝言ゲーム」のようにも思える。本当に行動そのものを直接生成できないのだろうか、という気もする
人間に読みにくい言語なら、Malbolgeが代表的だ。実際、最初の "Hello World" プログラムも遺伝的アルゴリズムが作り出した
原著者です。皆さんと話せるのを楽しみにしています
‘vibe coding’ という用語はあまりにも完璧な表現だ。まるで「クラウドコンピューティング」がとても広い意味に拡張されたのと同じだ。もともとは必要に応じてEC2インスタンスを立ち上げ、仕事が終われば破棄することを意味していたのに、その比喩があまりに直感的だったため、Gmailでさえ全部「クラウド」と呼ばれるようになった。