自分のコードベースを理解して、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だけじゃダメだよ。道具がうまくいかない時や新しい道具が出てきた時に役立つからね。