自分のコードベースを理解して、LLMの出力を見るのが俺のやり方だ。そうすると、バイブコーディングじゃないよ。バイブコーディングの核心、ほぼ唯一の要件は、コードを見ないことなんだ。製品の結果だけを見る。

デンマークでCSの学生の外部試験官をやってるけど、君とは意見が違う。業界で必要なのは、自分で考えられるソフトウェアエンジニアで、ビジネスとやり取りできて、そのニーズを理解できる人たちだ。そして、彼らはコンピュータの仕組みを理解している必要がある。今得られているのは、大量生産されたコーダーで、古い設計やソフトウェア構築の方法を教えられているから、それを叩き直さなきゃいけない。人々が組み立てラインのようにコードを書けるかどうかは特に気にしない。ボトルネックを特定して解決できるかどうかが大事なんだ。ビジネス価値を迅速に提供できるかどうかもね。抽象化を行うタイミングを知っている（ほとんどないけど）ことも重要だ。クソみたいなコードが年間2ドルのコストで済むなら、毎時間それに費やすのが100-200ドルになることを知っている開発者が欲しい。君のカリキュラムはここら辺とは違うかもしれないけど、ここでは正直、30年前に教わったことと同じことだ。実際のコンピュータサイエンスの部分はほとんどなくなって、さらに多くのOOPやデザインパターンのクソみたいなものに置き換わっている。とはいえ、今の学生にCSを教える方法が全くわからない。多くの学生がChatGPTやClaudeを使うだろうから、君が何をしても関係ない。ここでの成績の統計を見ているとそう感じる。最初の9年間は、俺はよく調整された採点者だったけど、ここ1年半くらいは、通常、最高点か最低点のどちらかで、その間は何もない。これが俺を本来いるべき場所から外れさせているけど、ここにいる全員の統計的な調整に合っている。俺はCS教育の成果しか見ていないけど、年を取った今でも、当時LLMがあったらどれだけ手を抜いていたか想像できる。インターネットがもたらしたすべての気晴らしを言うまでもない。

ウエイトリフティングみたいなもんだよね。フォークリフトを使ってもできるけど、自分の力をつけたいならフォークリフトじゃダメなんだ。これが学問におけるAIの根本的な問題だと思う。肉体的な作業には「痛みなくして得るものなし」ってのが当てはまるのはみんな知ってるけど、学びにも同じことが言えるよね。もちろん、職場では結果を出すことが重要になるから、学びとは違う側面もあるけど、それでも高いレベルの思考ができる人は必要だよ。

教える内容は少し適応する必要があるかもしれない。コードがどう動くかを教えることは、コーディングの仕方を教えるよりも重要だ。ほとんどの学術的なコンピュータサイエンティストは、プログラマーとして特にスキルが高いわけではないしね。少なくとも、私は自分が学術的でなくなってから（博士号を取得した後）そのほとんどを学んだ。これでいいんだ。プログラミングを学ぶことは、コンピュータサイエンスを勉強する副産物であって、核心的な目標ではない（これはいつも明確に理解されているわけではない）。ここでの良いアナロジーはアセンブラでのプログラミングだ。1980年代に初めてコンピュータを手に入れたとき、機械語レベルでプログラムを手動で作成するのは非常に一般的だった。特にゲームに関してはね。90年代後半にはほとんど消えてしまったけど、Roller Coaster Tycoonのようなゲームは、そういう風にコーディングされた最後の成功例の一つだった。C/C++が主流になって、今ではほとんどのゲームスタジオがエンジンをライセンスして、C#やLUAのような言語でたくさんの作業をしている。私はアセンブラプログラミングを意味のある量やったことがない。私がコンピュータサイエンスを学んでいた時（94-99）には、ほとんど関連性のないスキルになっていた。2年目に、架空のCPUのためのインタープリターを作ったことがある。私たちのコンパイラの授業は、Eric Meyerのような人たちが教えていて（後にMSでF#のようなものに取り組んだ）、彼らはそれを機会にして、みんなに関数型プログラミングを教えようとしていた。振り返ってみると、それは実際に良いスキルだった。関数型プログラミングへの関心が10年後にかなり高まったからね。このアナロジーのポイントは、コンパイラは重要なツールだってこと。コンパイラをアセンブラで作ることができることよりも、どうやって機能するかを理解する方が重要だよ。多くの人はコンパイラに関わることはないし、自分のオペレーティングシステムやデータベースを作ることもない。でも、どうやって機能するかを理解するのは役立つ。コンパイラがどう機能するかを教える目的は、プログラミング言語がどのように作られ、どんな制約があるかを理解することなんだ。

簡単なことをうまくやってくれないことがあって、余計にイライラするよ。僕はWindows開発をやってるけど、GDIのことはまだ混乱する。メモリDC、互換DC、DIB、DDB、DIBSECTION、bitblt、setdibitsとかね… AIもこの辺はダメだよ。比較的簡単なタスクを手伝ってもらおうとすると、ほぼ毎回、選んだ理由を説明させると問題が見つかって謝って、ぐるぐる回ってる。あるAI（どれか忘れたけど）なんて、PetzoldのWindowsプログラミングの本を参照するべきだって言われたこともあるよ。もう手伝えないってさ。」

100%同意だね。でも、25年の開発経験がある身としては、もう退屈な部分をあまりやらなくて済むのは本当にありがたいよ。

教師として、学生がコードを書くことを学ぶためのテクニックってありますか？

金属加工の授業について読んだことがあるんだけど、先生が最初に各生徒に金属のブロックとヤスリを渡して、そこからレンチを作らせるんだって。成功したら、次は機械工具の使い方を学ぶって感じ。金属を切る感覚を養うのが目的なんだ。 -- 僕の木工の先生は、手動の平面を使う方法を教えてくれた。薄くて透明になるくらいの木を削れるようになったんだ。それで、二つの板をほとんど見えない隙間でつなげられるようになった。ジョインターではそこまで上手くできなかったよ。

そうだね！自分でやってみるか、道具が何をしているのかをよく観察してから使うのが一番だよ。HDLで機能するプロセッサを全部作る必要はないけど、デジタルロジックやコンピュータアーキテクチャの基本は理解しておくべきだよ。OSをアセンブリで書く必要はないけど、アセンブリがバイナリにどう変換されるかや、リソース管理、IPC、ファイルシステムの基本を理解するのは、低レベルの仕事をするなら必須だね。CS専攻なら、アルゴリズムやデータ構造は絶対必要だし、独学やブートキャンプでフロントエンド開発を学んでいるなら、HTMLやDOM、イベント、CSSの仕組み、JSのコアコンセプトを学ぶべきだよ。Reactだけじゃダメだよ。道具がうまくいかない時や新しい道具が出てきた時に役立つからね。

（自動テストスイートがリファクタリングが正しく機能したか確認するのを手伝ってくれるよ。だって、元の機能を作ったときに自動テストスイートを構築させたんだから、そうだよね？）わからないな、もしかしたら俺は基準が高すぎるのかもしれないけど、一般的にLLMが生成したテストスイートは、過剰に決定されている部分と不足している部分があると思う。過剰に決定されているのは、いくつかのテストが実装の詳細に焦点を当てているからで、不足しているのは、人間がテストするような概念的なことをテストしていないからだ。それを言うと、似たような人間が書いたテストもたくさん見かけるから、エージェントの意図は理解できる。君はこれがLLMから良い結果を得る理由だと言ってるから、将来的にどうやってこれを実現しているのか詳しく教えてくれるといいな。

それは君の仕事だ。まさにその通り。AI支援の開発は、全か無かじゃない。私たち全体として、また個人として、AIと人間の適切な組み合わせを見つける必要がある。

自分で全てのコードを打ち直す（俺の解釈では「手書き」）のは、エージェントの管理スキルがないから、彼らに作った混乱を片付けさせられないというのは、短絡的に感じる。エージェントコーディングと自分で書くのを行ったり来たりする中で、ますます「罪悪感」を感じるようになってきた。エージェントが自分の望むようにコードを構造化しなかったり、全体的なクリーンアップが必要なとき、俺のフラストレーションが爆発して、手動でコードを書いたり、従来のツール（IntelliJ）を使ってリファクタリングするのに時間をかけすぎてしまう。今のツールでは、こういった作業の一部はまだ必要だと明らかに感じているけど、特定のタスクが本当に自分の手動介入を必要としているのか、エージェントがもっと早く管理できるのかを自分に問いかけている。この行き来を管理する方法を知ることは、君が主張している見解を強化している：エージェントコーディングツールを使いこなすためには練習して本当に理解する必要があるし、ただ文句を言って「十分に良くなる」まで待つのは完全に間違いだ。今の時点で、彼らはすでに本当に良いんだから、管理する方法を知っていれば。

コードを自分で全部打つのに戻るのは、エージェントにどうやって混乱を片付けさせるかを指示するスキルがないからって、ちょっと視野が狭いと思う。もしくは、そのスキルは今の最先端技術の一時的な副産物で、将来的には役に立たないから、今磨くのは無駄だよね。エージェントは混乱を作るべきじゃないし、少なくともちゃんと機能してればそうなるはずだし、もし人々がかなりの時間をかけてそれを片付けているなら、自分でコードを書けばよかったんじゃないかな。

記事にはこう書いてあった: 「だから、ほとんどのことを手書きに戻ったんだ。驚くことに、AIよりも速くて、正確で、クリエイティブで、生産的で、効率的なんだよ。すべてのコストを考慮に入れたらね。少なくとも彼は「ほとんどのこと」と言ってた。僕も「ほとんどのこと」を手でやってたけど、Opus 4.5が出てからは変わった。今は、以前は一週間かかってたことを数時間でやってくれる。でも、これはただのプロンプトを出して忘れるようなものじゃなくて、手助けが必要なんだ。それに、彼がどのエージェントを使ってたのか全然わからない。OpenAI、Gemini、Claude、何かローカルなやつ？サブスクリプションなのか、トークン単位で払ってるのか？僕が使ってる方法だと、これが200ドルのClaude Maxサブスクリプションだからこそ元が取れてる。もしトークンにお金を払ってたら（また言うけど、めちゃくちゃ高い）、破産してたよ。」

小説は創造的なアウトプットに関するもので、エンジニアリングは多くのルールや要件を理解し、それを満たすロジックを書くことに関するものだから。後者は出力がより明確に定義されているんだ。

昨日これを書いたけど、あなたの観察にさらに関連性があると思う：— 私は、人間が理解できない実装の完全にバイブコーディングされたアプリを使うことは絶対にないし、ましてやお金を払うことはない。あなたが本を読んでいるときもアプリを使っているときも、あなたは作者とコミュニケーションをとっている。作者は、あなたが作品を探索する際に何を考えているかを予測することで、あなたとの共通の人間性を通じてコミュニケーションをとっている。作者は、予測される反応や思考を取り入れ、計画している。最終的に、作者は読者に対して暗黙のメンタルモデル（あるいは感情状態や感覚を喚起することさえ）を伝えている。最初の問題は、これらの経路やエッジケースの多くは実際の実装まで明らかでないことで、時にはその過程で、全体の製品が最初から再仕様化された方が良いと作者が気づくことがある。この機会は、ハンズオンアプローチがなければ失われる。二つ目の問題は、人間のタッチが少ないほど、ユーザーに伝えられるメンタルモデルが一貫性を欠くことになる。仕様やプロンプトの集合はメンタルモデルを構成しないから。これが、作品とやり取りする際に潜在的な混乱や認知的摩擦を生むことがある。

「じゃあ、どうして10kLoCのバイブコーディングされたコードベースがエンジニアリング的に良いと思うの？」私は、フルLLMの支援を受けてサイドプロジェクトを1年間コーディングしている（そのプロジェクト自体はそれよりずっと古い）。基本的に、TrimbleでCADソフトウェアを開発して10年以上経ち、今は違う役割と会社に移行した。だから、依存症者のように、もちろんCAD技術の開発を続けたかった。CADソフトウェアがどうあるべきかはほぼ分かっている。でも、組み立てるのは本当に大変なんだ。LLMを使えば、膨大なボイラープレートが必要な要件をスピードランできる。手作業でやるのに比べて、その速度は驚異的だ。時々、LLMが全くのゴミを出力することもある。その場合は出力を受け入れず、やり直す。最も難しい部分はコーディングではなくデザインだ。エンジニアがデザインを担当する。時々、難しいディテールに数週間や数ヶ月かかることもある（これはサイドプロジェクトだから、家族もいるし）。デザインがクリアになれば、LLMの出力がデザインに合っているかどうかは明らかだ。良いデザインができれば、機能やボイラープレートのスピードランを始められる。もしWindowsのPCがあれば、私の現在の公開アルファを試してみて。バグは私の責任で、LLMのせいじゃないよ：https://github.com/AdaShape/adashape-open-testing/releases/t...

この問題の捉え方、いいね。AIの使い方を自己評価するのにも良い方法かもしれない。小説をバイブライティングしてみて、どれだけ一貫性があるか見てみて。バイブコーディングについての証言がこんなに幅広い理由の一部は、実際に得意な人がいるからだと思う。それを測る方法があったら便利だよね。

200ページのバイブライティング小説を読んで満足したことある？僕はないけど、息子はあるよ。GPT 4.5が書いた二つの別々の小説でね。（モデルには、一度に一章ずつ生成するように頼んで、各ステップで小説の全体のアウトライン、キャラクター、これまでの各章の要約を与えたんだ。）

いいポイントだね。それに、OPが説明してることは、僕がAIでコーディングを始めた最初の数ヶ月に経験したことだ。 「コードは良さそうだけど、クソだ」って段階を乗り越えて、今はうまくいってる。解決策は、リサーチや計画の段階で一緒に作業して、提案された変更を全部並べさせて、クソな部分には反論することだよ。全体的に良さそうなリサーチドキュメントができたら、「実行」を押すんだ。

その言葉はその時に作られたけど、実際にはClaudeコードやカーソル、コパイロット、他のツールを使ってもっと前からやってた人たちがいるんだ。ただ、その時はまだ言葉がなかっただけ。

著者はその言葉をAI支援コーディングを意味するために使ってる。それはバイブコーディングという言葉よりも前から存在してるよ。

2023年にGPT-4にGPT-4を使ったPythonプログラマーを設計・構築させたことがあるよ。それは自己修正ができて、ブートストラップフェーズの後に自分で拡張していったんだ（その時はGPT-4の指示に基づいてコードの部分をコピー＆ペーストしてた）。完全に自律的ではなかったし（信頼性はちょっと低かった -- 例えば、コードをプログラム的にコードフェンスから取り出さなきゃいけなかった）、完全にオリジナルでもなかった（ほとんどをAuto-GPTから盗んだんだけど、トークン制限のためにASTに直接操作してた）。ここでの僕の重要な洞察は、GPTに自分が使うAPIを設計させたことなんだ。これがLLMsの仕組みから考えても理にかなってると思う。存在しない関数を求めさせて、それをどうやって求めたかに基づいて作らせるんだ。そうすると、デザインが期待にぴったり合うんだ。GPT-4は今、自己修正するAIコードを非常に危険だと考えていて、それについて話すのが嫌みたい。Claudeの安全フィルターは数ヶ月前から似たような会話をシャットダウンし始めて、ユーザーにもっと頭の悪いモデルに切り替えるように提案してる。最近のモデルの一世代か二世代が自己複製に関してしきい値を超えたみたいで、研究所がびっくりしたみたい。公にこのことを聞いたことはないけどね。