導入 — 英語仕様という錯覚
- 「十分に詳細な仕様はコードだ」という文章に触発されて書き始めた。英語の仕様は直感的には精密に見えるが、実際に実装しようとすると曖昧さが露呈する
- 「すべてのものは、それを精密にしようとするまでは曖昧である」— バートランド・ラッセル
- プログラミングは文章を書くことのように、やりながら少しずつ鋭く研ぎ澄ましていく反復的な営みである（このエッセイも無数の草稿を経ている）
バイブコーディング — なぜ動き、なぜ危険なのか
- AI が英語→実行可能コードへの変換をますます速く、うまくこなすようになり、英語レベルの「雰囲気(vibe)」でコードを作れるようになった
- AI が作った成果物に反応しながら — 「ボタンをあっちに移して、もっと青くして」— 徐々に精密化していくプロセス
- 「バイブコーディング」という表現が完璧な理由は、英語レベルのバイブを保ったまま、AI の出力によって思考を鋭くしていくことだからだ
- 核心的な問題: バイブが精密な抽象化であるという錯覚を与える。 機能が増えたりスケールが大きくなったりすると、抽象化が破綻し（leaky abstraction）、予想外のバグで一日が丸ごと台無しになる
実例 — Dan Shipper のバイブコーディングアプリ
- Dan Shipper がバイブコーディングで作ったテキストエディタアプリがバイラル化し、サーバーがダウンした
- 原因: 「リアルタイム共同編集(live collaboration)」は直感的には簡単そうに見えるが、実際には悪夢のような複雑さを持つ
- 私たちはみな Google Docs や Notion を使ったことがあるので、「リアルタイム共同編集」があたかも精密に仕様化されたもののように感じてしまう。なぜそうではないのかを事前に見抜くのは極めて難しい
- 著者自身も 10 年前、共同編集エディタを作ろうとして予想外の複雑さという悪夢を経験した。何が難しかったのか？ もう覚えていない！ それ自体が問題の一部だ — 複雑さは退屈で、考えたくなくて、細部やエッジケースを記憶しにくい
- 例: Slack が通知を送るかどうかを決める古典的なフローチャート — これほどの複雑さが「通知を送る」のような単純な言葉の裏に隠れている
抽象化 — 複雑性を扱う唯一の道具
- 人間の脳の根本的な限界: 一度に処理できるのは 7±2 個だけ
- 7 個を超えるものを扱う唯一の方法は、複数のものを一つに圧縮(compress)すること。これを再帰的に無限に繰り返せるので、人間は無限の複雑性を扱える。この圧縮の段階こそが**抽象化(abstraction)**である
- 「抽象化の目的は曖昧になることではなく、絶対的に精密になりうる新しい意味のレベルを作ることだ」— ダイクストラ
- Sophie Alpert が Slack の悪名高い通知フローチャートを巧みな抽象化によってはるかに単純にリファクタリングした事例
- プログラミングで最も良い部分は、より良い抽象化を少しずつ作り、複雑性を征服していくことだ。ReactJS や TailwindCSS がそれぞれの領域で成し遂げたように
- 共同テキストエディタが本質的に複雑だというのは、ただより良い抽象化を探し続けなければならない、という意味にすぎない
AGI — それでも良いコードは消えない
- 1 年後、2 年後、5 年後、10 年後、100 年後を思い描くと、AI はますます良く、速く、安くなり、いつか機械知能が人間と見分けがつかなくなる時点（AGI）が来る
- AGI の世界はバイブの世界のように見えるかもしれない。カパシ級の天才を 100 人、月額 $1000 で使えるなら、面倒なディテールをなぜ気にする必要があるのか？
- 「これは本当にばかげた話だ。」 こうした考えは、技術が到来する前だからこそ成り立つ、抽象的に可能なだけの思考にすぎない
- そのレベルの知能にアクセスできるなら、もっと多くのスロップを量産するために使う人は 0% だ。そんなわけがない
- 私たちが混同している理由は、コードがソフトウェア生産のためだけのものだと（誤って）考えているからだ。コード自体も中核的な成果物である。うまく作られたコードは詩(poetry)だ
- 「誰も『バイブライティング』なんて言わないだろ？」 — 文章の世界で ChatGPT が偉大な小説家やジャーナリストを置き換えると誰も信じていない。コードも同じなのに、実行されるコードの「神秘性」のせいで錯覚が生まれる
- AI は（以前よりはましになってきたとはいえ）ひどいコードを作る。私たちはみなそれを知っている。AI を使うのは、悪いコードにもかかわらず使うのであって、悪いコードだから使うのではない
- Simon Willison の言葉: 「AI はより良いコードを作る助けになるべきだ」
- AGI が来たら最初にやるべきことは、最も難しい抽象化の問題を解くことだ。より良い抽象化を作り、複雑性をもっと深く理解し、征服すること
- AI が賢くなるほど良いコードの必要性がなくなる？ それは ChatGPT でさらに多くのスロップを量産しようと言っているのと同じだ
- 実例: Opus 4.6 が Val Town のフルスタック React フレームワーク（vtrr）を作る際、未解決の問題をワンショットで解決した。50 行のシングルファイルなフルスタックアプリのデモがその成果だ
結論 — コードはまだ始まったばかりだ
- 社会の 99% は「コードは死んだ」に同意しているように見える。昨日もポッドキャスターの Sam Harris が「みんなコーディングは死んだことに同意している。もう誰もコーディングを学ぶ必要はない」と自信たっぷりに語るのを聞いた
- 「これは悲しい。印刷機の発明を前に『ストーリーテリングは死んだ』と言うようなものだ。愚か者め、コードはまだ始まったばかりだ。AI はコーディングにとって途方もない祝福になるだろう。」
- 締めくくりの引用:
- 「形式記号を使う義務を負担と見るべきではなく、それを使えることを特権と見るべきだ。そのおかげで学生たちは、かつては天才にしかできなかったことをできるようになった」— ダイクストラ
- 「母語を『自然に』使えるということは、ナンセンスであることが明白ではない文を簡単に作れる、ということにすぎない」— ダイクストラ『自然言語プログラミングの愚かしさについて』
- 「ソフトウェア設計には二つの方法がある。一つは、あまりに単純にして欠陥が明白に存在しないようにすること。もう一つは、あまりに複雑にして明白な欠陥が存在しないようにすることだ」— トニー・ホーア
- 「代数記号によって小さな空間に圧縮された意味の量が、私たちがそれを通じて行う推論を容易にする」— チャールズ・バベッジ
7件のコメント
協調編集の話に行く前に、1人で使うエディタを1つまともに実装するだけでも、カーソル処理、undo/redoスタック、IME入力など、予想外の複雑さがあふれています。文中で指摘されているように、「直感的には精密に感じられる仕様」の落とし穴が、エディタほどよく表れるソフトウェアもありません。結局、簡単そうに見えるものは簡単なのではなく、その複雑さをうまく抽象化して隠しているのです。
実際、AnthropicがデモとしてCコンパイラを作った理由も、やはりコンパイラは仕様が正確で、テストケースもしっかり整備されているからだったのでしょう。同時に、とても難しそうにも見えますし。
コンパイラをいくつか作ってみて、今取り組んでいるものもありますが、バイブコーディングという観点で見ると、エディタも試してみたものの、コンパイラのほうが簡単に感じられました。お書きになったとおり、仕様はそれほど正確ではなく、ユーザーによる変数も多いと感じます。テストもしにくいです。
仕様が重要になるのは確かですが、以前から仕様をすべて細かく書いてあらゆる状況をカバーするのは不可能だと思っています。仕様もまたコードのように、作業しながら磨いていく方向がまだ良いと思いますが、複数のエージェント同士でそうやらせればいいのではないかとも思います。ですが、結局は人の介入なしには、学習した状況や知識を超えることができないので、まったく新しい状況や機能は難しいのではないかと思います。
ロボット掃除機が最初に出たとき、ロボットのために床にある物を片付ける「簡単な掃除」をしなければならないと聞いたときの感覚です。AIのために詳細な仕様を書くのもかなりの手間で、AIのために仕事をしているように感じます。
IDE も PR もみんな死んだのに、コードは復活したんですね？
コードは単純系において、論理的に最も正確な仕様だ。
しかし現実世界は複雑系であるのが落とし穴だ……結局、データだけがその中でまだ最も正確な仕様だ。
他の検証方法で代替できるかを見る必要があると思います。フロントに近いほど、ブラウザの動作によるE2Eだけでも問題なく動作すると検証できるでしょう。しかし、バックエンド、そしてインフラに近いコードであるほど、コードレビューが必須になると思います。そうでないと、目に見えないトランザクションの開始と終了や
apiコールが飛ぶなどの副作用を検証するのが難しいでしょうから。ブラウザには、E2Eでも捉えられない問題が山ほどあります。