バイブコーディングするならCでやれば？
(stephenramsay.net)- バイブコーディングは実際によく機能するが、書き手自身が理解していないコードが生まれるという点で、プログラミングの本質的な楽しさが薄れてしまう
- すべてのプログラミング言語は機械ではなく人間の便宜のために設計された道具であり、安全性・抽象化・可読性といった利点も結局は人間が考えるための構造である
- それなら**AIが書くコードに人間親和的な言語は本当に必要なのか？**という問いから、機械親和的でAI中心の新しい言語 VOPL(Vibe-Oriented Programming Language) を提案
- この言語には、実行可能な擬似コード、文芸的プログラミングの拡張、あるいは自然言語ベースの特定文法を持つ形など、さまざまな可能性が含まれる
- ストアドプログラム方式コンピュータの初期のように、新しい計算パラダイムへの抵抗は繰り返される歴史であり、バイブコーディングもその流れの次の段階かもしれない
プログラミングとバイブコーディングの緊張関係
- プログラミングは私にとって仕事ではなく楽しみであり、1990年代後半から続く情熱の対象である
- 25年間プログラミングを教えてきており、非専攻者をプログラマに変えることを最も誇りに思っている
- プログラミングでは問題解決の過程を自分で理解する楽しさを重視している
- 一方でバイブコーディング(vibe coding) は、AIがコードを代わりに書く過程であり、書き手が結果を完全には理解できない状態を招く
- 「チートしている（もちろんそういう面もあるが）」ようでもあり、しかし正確には言い表しにくい形で後味の悪さを感じさせる
- コーディングそのものの楽しさをかなり奪っているように思える
- それにもかかわらず、バイブコーディングは高品質な実用システムを作り出せるほどによく機能する
- 検索の代替にとどまらず、自分で解くのが面倒な問題も正確に解決する
- AIは人間よりもバグ追跡やメモリ管理に長けており、プログラムのアイデアをAIに投げたときに返ってくる結果に何度も驚かされる
言語はもともと人間のための道具
- Abelson & SussmanのStructure and Interpretation of Computer Programs にあるように、プログラミング言語は人間のための表現手段である
- コードは「人が読むためのもの」であり、機械は可読性を必要としない
- すべてのプログラミング言語は人間の思考と表現を助ける媒体として設計されている
- Rustの安全性、C++の抽象化、Goの並行性などは機械ではなく人間の便宜のための機能である
- メモリ管理・並行性・型安全性などは、人間の思考の構造を支えるための抽象化にすぎない
- したがって、AIがコードを書く時代には、人間中心の言語設計は不要になるかもしれない
それならAIにこうした言語は必要か？ : 「Cでバイブコーディングしろ」という提案の意味
- バイブコーディングでは、人間はすでにコード全体を完全には理解していない状態でプログラムを書いている
- この状況では、人間親和的な文法を維持する理由は弱くなる
- 人間親和的な言語の代わりに、機械親和的な言語(Cやアセンブリ) で直接書くほうが合理的かもしれない
- AIはCのundefined behavior、メモリ解放、オフバイワンなどを人間より精密に管理できる
- コンパイラが最適化をよりうまく行うのと同じように、人間より正確なコード実行管理能力を示す
- そこで疑問が生まれる: AIが使うのにより適した言語が必要なのではないか？
- なぜわざわざPython・Rust・C++のような「人間中心」の言語でバイブコーディングをしなければならないのか？
VOPL(Vibe-Oriented Programming Language) の提案
- バイブコーディングを前提にした言語なら、次のような可能性が考えられる
- 実行可能な擬似コードに近い超高水準言語
- 文芸的プログラミングの完成形のように、人間は記述だけを行い、AIが機械コードを生成する形
- 自然言語のように見えながら、特定の「慣用表現」を持つ構造
- 「goroutine」の代わりに、日常語ベースの並行性表現(slang) のような概念
- AIが問題を正確に理解し、すばやく実行コードを生成できるように、機械中心の表現体系を設計する方向性
- 新しい言語をAIに学習させるという問題はあるが、現在でも多くの開発者がAIに擬似コードを投げて対話するようにコードを作っており、
何らかの形のVOPLはすでに学習されている可能性もある
プログラミングという行為の変化
- 「手でコーディングすること」は、将来のバイブコーダー教育ではモンテッソーリ式の基礎教育のように扱われる可能性もある
- Photoshop以前の手描き訓練や、紙に等式を解く訓練が電子計算機の時代にも教育課程として残っているのと同じように
- 新しいパラダイムの到来への抵抗は、歴史的に繰り返されてきた
- ストアドプログラム方式コンピュータ導入初期の反発事例(ENIAC → EDVAC)
- Grace Hopperでさえ「機械が機械の命令を書くことはできない」という批判と戦った歴史がある
結論的メッセージ
- バイブコーディングはすでに現実であり、未来の開発は言語そのものの再設計を求めるかもしれない
- 人間中心言語の時代から、AI中心言語への転換可能性が真剣に議論されるべき時点に来ている
“Same vibe, as the kids say.” — 今どきの言い方をするなら、同じバイブだ
4件のコメント
言語モデルでコーディングしながら、機械に近い表現を勝手に魔法のように作ってくれると信じるなんて、虫がよすぎますね
制約があるほど、その制約の中でうまく仕事をします
AIがコードを書くとしても、サービスに対する責任は開発者が負うべきでしょう。自分で理解できないコードに責任を持てるのか、疑問です。
「vibe coding をするとしても、結果をレビューできるようにするには、自分がよく分かっている言語でやるべきだ」
コメント欄にとても重要な一文がありますね。
Hacker Newsの意見
ソフトウェア開発という職種が本当に多様だと改めて感じた
私はバックエンド、特にAPI開発をしているが、生産性の最大のボトルネックは、たいていの人が要件をきちんと定義できないことにある
PMに聞くと話をはぐらかし、フロントエンド開発者はバックエンドがAPIを出すのを待っている
結局いちばん難しいのはコーディングではなく、要件を発見し解釈する思考プロセスだ
本当のプログラミングとは、自分が設計したシステムを実装して命を吹き込む行為だ
会社で単にコードを書く仕事を『Programming』だと勘違いすると誤解が生じる
ただし、大規模な商用ソフトウェア開発の経験はあまり多くなさそうだ
彼が語る「プログラミングの未来」の予測は魅力的だが、産業的な文脈ではやや限界があるかもしれない
（参考: Stephen Ramsayの紹介）
結局重要なのはマインドセットと、どれだけ技術に触れているかだ
LLMは私の生産性を大きく高めてくれる — 特にアーキテクチャ的な思考法を持つ私にとっては
以前なら数か月かかっていたものを、今では数時間で作り上げられる
最近はLLMで古いShockwave Lingoコードを現代的な言語に翻訳し、レガシーゲームを復元している
結局、vibe codingが未来だというなら、それはAIが完全ではないという前提を含んでいる
想像上のAIの能力と限界を恣意的に設定した瞬間、議論そのものが曖昧になる
ステークホルダーと4、5回は会議しないと明確にならない
Cでvibe codingをやってみたが、それでもやはりCは好きになれない
AIが人間のようにメモリ解放を忘れて、あとで修正していた
Rustでやるとずっと楽しく、言語の依存関係エコシステムを理解することこそ本当の実力だ
AIはこうした「書物的知識」を素早く探索するのに役立つ
Cではメモリ解放の有無をいちいち確認しなければならなかったが、Rustではそうした心配がほとんどない
vibe codingをするとしても、言語の安全装置があるRustのほうがはるかに良いと思う
Pythonの人間に優しい機能はAIにも役立っている
今ではAIのおかげでUIやユーティリティを新しく作るのがずっと簡単になり、
C++で性能が重要な部分だけ実装するのも簡単になった
GDBで自分でデバッグしていたら、ずっと時間がかかっていただろう
文字列処理やポインタ管理のような不快な部分を代わりにやってくれるので満足している
コンパイラが生成したコードのほうが常に効率的だが、AIのミスを学習の機会にしている
ローカルLLMでもメモリ解放のような検証を自動化できる
最近「Why AI Needs Hard Rules, Not Vibe Checks」という議論があった
(リンク)
Rustがvibe codingに向いている理由は、型とライフタイムの保証のような無料の検証機能があるからだ
こうした検証がなければ、LLMは安全でないコードを簡単に作ってしまう
抽象化は人間だけでなくLLMにも必要だ
すべての関数、変数、型、例外を厳密に仕様化しなければならない言語だ
書くには不便だが、読むことと検証がしやすい構造になるだろう
コードの実行経路ではなく意図を保つ翻訳の難しさを扱っている
Shellcheckのようなツールでも初心者を専門家にしてくれる
RLで改善するには、コードの整合性を自動で判断できなければならない
Prologのような論理ベースの言語が再評価される必要がある
LLMがバグの多いコードを出すなら、言語が違っても結果は似たようなものだ
最初はvibe codingに驚かされたが、すぐに終わりのない修正ループが精神をすり減らした
まるでアルゴリズムフィードをスクロールするように集中力を奪っていく
今は自分でコーディングし、退屈な部分だけChatGPTに任せている
しかも学ぶこともない
こうすると要件を明確にできるし、別のAIにも簡単に乗り換えられる
LLMがメモリリークのないCコードを作れるのか疑わしい
人間の開発者でもミスする領域なのに、学習データの質が低いLLMはさらに危険だ
segfaultが出るプログラムをvibe codingで作るなら、それは時間の無駄だ
ほとんど壊れず、常にコンパイルが通る
人間は疲れるが、LLMはそうではない
良いCコードで再学習させれば改善の余地がある
AIがCでundefined behaviorを避けるって？ 信じがたい
人間のようにミスするよう訓練されたモデルなら、同じバグを出す可能性が高い
最も可能性の高いトークンを予測するので、ありがちなミスは減る
クラッシュの原因もよく見つけてくれた
ZigやRustのような現代的な言語のほうがずっと良い
vibe codingが私を不快にさせる理由は、単に「ズル」のように感じるからではない
プログラミングは魂のこもった芸術だ
問題の解き方は人それぞれで、それが創造性だ
vibe codingはその創造性を機械が吸い取ってしまう行為のように感じられる
結局、考えることも、決めることも、ミスすることも、すべて機械が代わりにやってしまう
「vibe-oriented programming language(VOP)」を作ろうという提案があった
しかしLLMのための言語なら、むしろ厳格で冗長であるべきだ
すべての条件と例外を明示しない限りコンパイルされないようにすべきだ
人間には不便でも、LLMには混乱を減らす利点になる
人間が概念を説明し、AIがそれをコードに変換する構造が必要だ
一度コンパイルが通れば、ほとんどいつも正しく動いた
vibe codingをするとしても、結果をレビューできるようにするにはよく知っている言語でやるべきだ
そうでないなら、いっそbrainfuckで試してみたほうがいいかもしれない
「じゃあx86アセンブリでやってみたら？」という質問には、
「自分でレビューして拡張できなければならない」という理由で断っていた
純粋なvibe codingは思考実験にすぎず、現実的な目標ではない
いつかAIがQAまで担えるようになるかもしれないが、今のところは安全な言語と人間の検証が必須だ
こういう議論に疲れるほど長くこの業界にいる開発者になってしまった