「Slackを20分でクローンした！」
SNS上でこうした投稿を見かける機会が増えました。
AIにプロンプトを投げるだけでアプリを作る。
いわゆる「バイブコーディング」が話題です。
Reddit上でもこのテーマは大きな議論を呼んでおり、賛否が真っ二つに割れています。
本記事では、その議論を参考に、バイブコーディングの可能性と限界を整理してみましょう。
プロトタイプは簡単。昔からそうだった
あるRedditユーザーが的確な指摘をしていました。
新規プロジェクトをゼロから始めるのは、昔から簡単だったと。
20分ほどではなかったかもしれないけれど、難しくはなかった。
AIはファンタジー小説の第1章も上手に書ける。
でも、既存シリーズの途中に新しい章を挿入するとなると話は別です。
前後の整合性を保たなければならない。
前者はコンテキストが少なく、制約もほとんどありません。
一方、後者は膨大な文脈と無数の制約が絡み合います。
この違いが、小さなスクリプトと既存のエンタープライズアプリで品質が全然違う理由だと。
この指摘には説得力がありました。
見えている部分は全体の0.5%にすぎない
チャットUIを作るのは難しくありません。
メッセージを送受信できる画面なら、AIの力を借りれば短時間で完成するでしょう。
しかし、Slackのようなプロダクトが本当に解決している問題は、UIの裏側にあります。
あるエンジニアの投稿によると、3大陸にまたがって200ミリ秒以内でメッセージを配信するのは簡単ではありません。
メッセージの順序保証、結果整合性、プレゼンスシステム、大規模検索。
こうした目に見えない技術基盤が山のように必要だそうです。
年収30万ドル以上のエンジニアたちが日々取り組んでいるのは、まさにこの部分。
チャット画面の色やレイアウトを調整しているわけではありません。
別のコメントではDocuSignの例も挙がっていました。
「DocuSignをクローンできる！」と言う人がいる。
けれど、署名の法的有効性を国ごとに担保するコンプライアンス対応は非常に複雑です。
ほとんどの人は、その複雑さを想像すらしていないと。
「でも、大半のアプリはそこまで必要ない」
ここで議論が面白い方向に動きます。
高評価を集めた反論がこうでした。
現実には、ほとんどのアプリがFortune 500のSLIを満たす必要なんてない。 中小企業向けなら、コンテナ化してCloud RunとCloudSQLに載せればいい。 月400ドル程度で十分なパフォーマンスが出る
この意見には多くの賛同が集まりました。
確かに、すべてのプロジェクトがSlack級のスケーラビリティを求めているわけではない。
たとえば、50人規模の社内ツールを作りたいだけの場合。
年間3万ドル以上のSlackライセンスを払い続けるより、自社用のチャットツールをAIで作るほうが合理的かもしれません。
実際、あるユーザーはTrelloの年間契約を解約したと報告していました。
バイブコーディングで代替ツールを作ったところ、自社に必要な機能だけで十分だったからです。
両陣営は互いの話を聞いていない
議論の中で最も的を射ていたコメントがありました。
「両陣営は互いの論点をすれ違いにしている」という指摘です。
1時間でエンタープライズレベルの製品を作れると思っている人は間違っている。
でも同時に、反対側も間違っている。
小規模ビジネスや個人がSalesforceのライセンス料を払う必要がないケースは、世の中に山ほどあるからです。
このすれ違いの構造は、ダニング=クルーガー効果とも無関係ではないでしょう。
バイブコーディングで動くものが出来上がった瞬間、「自分はソフトウェア開発を理解した」と錯覚してしまう。
しかし本当に難しいのは、その先にあります。
保守、セキュリティ、エッジケースへの対応。ここが本番なのです。
本当の失敗ポイントは「保守」にある
スケーラビリティの議論は、実はやや的外れかもしれません。
あるシニアエンジニアの投稿が核心を突いていました。
プロジェクトが失敗する本当の原因は、多くの場合「保守」にある。
バイブコーディングで週末にv1を作ること自体は可能だ。
でも3週間後にバグが出たらどうなるか。
コードが何をしているのか理解していなければ、ただ闇雲にAIへプロンプトを投げ続けるしかない。
やがて、AIがバグを修正するより速く新たなリグレッションを生み出すようになると。
AIを使ったコーディングで成果を出している人には共通点があるそうです。
それは「AIなしでも自力で作れるが、遅くなるだけ」という人たち。
退屈な部分をAIに任せつつ、AIが生成したコードをちゃんと読んで理解している。
差がはっきり出るのは、何かが壊れたとき。
再生成ではなく本物のデバッグが必要な場面で、実力の差が露呈するわけです。
バイブコーディングの適切な位置づけ
議論全体を俯瞰すると、バイブコーディングの適切な立ち位置が見えてきます。
MVPやプロトタイプの構築には極めて有効です。
あるユーザーは、バイブコーディングで3週間のうちにWebページから本格的なアプリケーションまで到達したと報告しています。
この段階では完璧さは求められません。
大事なのは、アイデアの検証とユーザーからのフィードバック収集です。
別の興味深い視点もありました。
ある政治学専攻の学生が、議会法案を分析するAIツールをCursorで構築した話です。
コンピュータサイエンス専攻なら、技術的にはもっと上手く書けたかもしれない。
しかし「分析ツールとして何が本当に必要か」というドメイン知識では、この学生のほうが圧倒的に詳しかった。
技術実装はAIに任せ、プロダクトの方向性は人間が握る。
このパターンにこそ、バイブコーディングの真価があるのかもしれません。
一方、本番環境で真剣に運用するプロダクトには、やはりエンジニアリングの知識が不可欠です。
あるコメントが分散システムについて語っていたのが印象的でした。
AIが生成した微妙なエラーは、分散環境では孤立したまま留まらない。
複合的に蓄積して、最終的にアーキテクチャ全体が自重で崩壊すると。
AIは道具であり、魔法ではない
議論の中で、ある年配のエンジニアがこんな趣旨のことを書いていました。
過去の産業革命で、工場や電気や鉄道をここまで擬人化したことはなかった。
ハンマーが自分で釘を打つ日は来ない。
人間は空を飛べないが、飛行機は飛べる。
でも飛行機と人間を対立軸で語る人はいなかったと。
AIも同じだという主張です。
非常に高度で革命的なツールであることは間違いない。
しかし意図を持つのは、あくまで人間の側です。
何を作るべきか。
なぜ作るのか。
その判断は、依然として人間の仕事なのです。
年収30万ドルのエンジニアたちもAIを使っている。
ただし、使い方が違う。
バイブコーディングではなく、AIをツールとして扱う「エージェンティック・エンジニアリング」とでも呼ぶべきアプローチです。
そのやり方で、より複雑で高品質なシステムを構築しているわけです。
まとめ
バイブコーディングは、ソフトウェア開発への参入障壁を劇的に下げました。
去年までコードを一行も書けなかった人が、動くプロトタイプを作れるようになった。
これは紛れもない革命です。
ただし、プロトタイプと本番プロダクトの間には依然として大きな溝がある。
スケーラビリティ、セキュリティ、保守性、エッジケース対応。
これらの課題は、プロンプトを工夫するだけでは消えません。
最も生産性が向上するのは、熟練エンジニアがAIをツールとして使う場合です。
非エンジニアがAIでエンジニアを丸ごと置き換えようとする場合ではない。
Reddit上の議論が示しているのは、この現実でしょう。
もちろん、AIの進化速度を考えると、この状況がいつまで続くかは誰にもわかりません。
ただ少なくとも今の時点では、「何を作るべきか」「なぜそう作るのか」を判断する人間の役割は、まだなくなっていないのです。
