「モデルや理論が必要だと思わないプログラマーと、LLMが自分たちを速くしていると報告している人たちの間には強い相関関係があると思う。」私は、コンピュータや関連技術から完全に離れているときに、ソフトウェアプロジェクトでより多くの価値を生み出せるという経験がある。自分が何を求めているのかが明確だと、コードがどれだけ早く進むかは驚くべきことだよ。この時点でLLMは非常に役立つことができる。なぜなら、その幻覚がすぐに自分の視点でフラグを立ててくれるから。もし自分が何を求めているのかわからなければ、これがどう機能するのかは見えない。私は、毎日何時間も真っ白なキャンバスを見つめる理由が本当に理解できない。LLMはあなたを解放して正しい方向に進ませるかもしれないけど、むしろ無駄な追跡に引き込まれる可能性が高いと思う。私が解決した最後の10/10の難しい問題は、たぶんキッチンで玉ねぎを切っているときに起こった。

「理論構築」 LLMが生成したコードの「理解の負債」をプログラミングを理論構築と結びつけたのは洞察に満ちているね。これはプログラミングの活動を超えて、思考や理解のプロセス全般に当てはまると思う。LLMが生成したコンテンツ、文章や視覚芸術も含めて、これはコードに相当するもので、表面的には最終結果として人々が見るものだ。でも、もし人がその生産に関与していないと、何を意味し、どう機能するのかの理論を構築することはできない。詳細を通じて全体をまとめることができないと、表面的な理解しか得られない。たとえLLMが進化してこの「理論構築」を自分で行えるようになったとしても、人間が関与しない人工的な理解に何の意味があるのか？それは非常に役立つかもしれないし、価値もあるかもしれないけど、最終的には機械に考えさせる方が便利になって、人々は理解するスキルを失っていくかもしれない。

これが、AIコーディングで他の同僚よりも少し成功している理由の一部だと思う。LLMが出る前のワークフローは、何かのクソみたいなバージョンを素早く作って、理解を深めるために再構築する（場合によってはプロトタイプを捨てることも）って感じだった。多くの思想的リーダーがこの一般的なアプローチ（迅速なプロトタイピング、継続的なリファクタリングなど）について語っているけど、多くのエンジニアは抵抗を示して、アプローチを考えた上で「正しく」作りたいと思ってる。あるいは、何かをさっと作り出して捨てずに、最初のクソみたいなものを修正することに苦労している。AIを使うと、このループがずっと楽になる。何かの3つの並行実装を作るのも安上がりだし、システムが面白いと思う機能を追加するのを許可する別のものを作ることもできる。これを比較して、要件や関心の分離、大きなシステムとの統合方法を考えた「プログラムの理論」を構築するのに使える。AIにそれを作らせて、出力をしっかりレビューすれば（何を作るべきか大体わかっていれば、時間もかからない）、すごくうまくいくよ。

完全に同意だね。かつて、元の開発者たちが突然消えて、新しいチームが引き継いだプロジェクトに関わったことがあるんだけど、すべての制度的知識が失われてしまったんだ。元の設計を理解するのに、無駄に時間をかけてしまった。理解が深まるまでにかなりのバグを導入してしまったけど、頭をぶつけながらも多くの設計問題を修正したよ。結局、ほとんど書き直されて、元々計画されていなかったことをするように拡張されたんだけど、そのプロセスは本当に苦痛だった。

プログラミングは「達成したいこととその方法」だね。線形プログラミングや動的プログラミングのように。 > モデルや理論が必要だと思わないプログラマーと、LLMが彼らを速くしていると報告している人たちの間には強い相関関係があると思う。これは面白い予測だね。根本的な原因に関係なく相関が得られると思うよ。ほとんどのプログラマーはモデルや理論が必要だと思っていないし、ほとんどのプログラマーがLLMが速くしていると報告しているから。でも、それを考慮に入れると、逆のことが真実である理由もいくつかあるかもしれない。LLMによって最も速くならないと感じるプログラマーは、主にコードを書くことが貢献だと感じている人たちかもしれないし、正しいモデルを見つけることを仕事と考える人たちは、コードを正しい順序に整えるという雑務がなくなるから、より速くなる可能性がある。

そうだね。業界はドメイン特有の知識やコード特有の知識の必要性、開発者が残ることの価値を軽視してたと思う。開発者が「理論構築」や共有に時間を使うこともね。全てのコーディングチームを入れ替えて、同じ開発ペースで進めると思ったら大間違いだよ。コードが比較的良くて、新しい開発者がそれなりにスキルがあってもね。特に「アーキテクチャモデル」レベルのドキュメントが不足してるときは。まあ、LLMがそれをめちゃくちゃなレベルに押し上げてるけど。もし全てのコーダーが自閉症の天才幼児で、毎月新しい幼児チームに入れ替わったらどうなるんだろう。

LLMのおかげで、僕たちには良くなったよ。ジュニア開発者がコミットするコードの質が向上した。

キャリアの中でいくつかのレガシーアプリケーションに関わってきたけど、プログラミングの他の多くの問題と同じように、この問題の最も重要な解決策は良いモジュール化だと思う。そうすれば、新しいチームがモジュール同士の相互作用を高いレベルで理解できるし、変更が必要なときは関わるモジュールだけを理解すればいい。理想的には一つずつね。だから、全体のアプリケーションの詳細な理論を一度に作る必要はないんだ。LLMを使ってみて分かったのは、良いモジュール化の原則と実践を守れば、LLMがあればあまり知らないコードベースでも作業を始めやすくなるってこと。ナビゲートしたり、「必要な分だけ」理解したり、特定の変更をするのにすごく助けてくれる。でも、これはLLMが自動でやることじゃない、少なくとも僕の経験ではね。やっぱり人間が良い、一貫したモジュール化を強制する必要がある。

プログラマーがモデルや理論が必要だと思わないことと、LLMが彼らを速くしていると報告していることの間には強い相関関係があると思う。僕もランポートに強く同意するけど、なぜAIが元のチームやプロジェクトを引き継ぐチームの「理論構築」プロセスに役立つと思わないのか、ちょっと気になるな。つまり、コードベースやアルゴリズムを理解することについてね？全ての知識を置き換えるわけではないけど、ギャップを埋めることはできると思う。

実際、LLMによって開発者がスピードアップしている（つまり、単にコードの行数ではなく、保守可能な成果物の出力を増やすこと）というのは、彼らが取り組んでいるシステムの理論をしっかり持っている人たちだと思う。少なくとも今のところ、LLMは「どうやって」の部分では素晴らしいけど、「何を」「なぜ」を理解するためのコンテキストが欠けていることが多い（それが書かれていなかったり、彼らのトレーニングデータにあまり含まれていなかったりするから）。

LLMを使うと、複雑すぎる解決策を避けるのは簡単だよ。まず、プロンプトは直接的にして、LLMが無駄に複雑なものを作らないようにすること。次に、常に問題をできるだけシンプルに解決するためのルールや学習、コンテキストを加えるべきだね。最後に、生成後にLLMに解決策の複雑さを減らすように促すことができるよ。

「ボトルネックになっちゃう（それじゃ意味がない）」 [...] ボトルネックがレビューだけになる方が良いよね、コーディングとレビューの両方じゃなくて。これのためにたくさんのツール（リンティング、ファジング、テストなど）が開発されてると思う。今起こっているのは、プロジェクト全体を設計するのが苦手で、コードをすぐに読み取ったり分析したりするのが苦手な人たちが、もっと上手くならなきゃいけなくて、文句を言ってるってことだと思う。私はそういう仕事が好きだけどね。彼らは適応するよ、そんなに難しくないから。

エージェント用のさまざまな指示.mdファイルを使って、共通の問題や避けるべき落とし穴を更新してるよ。それにコーディングスタンダードのドキュメントへのリンクもね。GeminiやClaudeは少なくともそれとうまく連携してるみたいだけど、時々間違いもする（例えば、c++のautoを使わないのはよくあること。コンテキストのマークダウンファイルには使わないように明記されてるのに）。モデルが改善されて指示処理が上手くなるにつれて、もっと良くなると思う。これが「解決策」だとは言わないけど、ある程度は役立つよね。「バイブコーディング」から離れて、コードの一般的な構造やユニットの相互作用にもっと気を使うべきだと思う。AIには生の構文を埋め込んだり、文字を打ったりすることだけを任せればいい。これでもまだ大きな生産性の向上だけど、エンジニアとしては機能ごとに細かく指示を出してる感じ。ちょうどいい妥協点って感じだね。

そうだね、「LLMが生成したコードをレビューして理解する時間を取るだけ」ってのは、新しい「悪いコードを書かなければバグは出ない」っていうのと同じだよ。業界全体で、バグを出したくないのに何年もバグを書いてきたから、この作業はスケールするのが不可能だってみんな知ってる。AIのコードを全部レビューして良いコードか確認するのも、同じようにスケールしないよ。うまくいかないし、業界がそれを理解するのに5～10年かかるだろうね。

「私は vibe coding をやったことがある」 なんで？冗談半分で言ったつもりだったけど、誰も本気でコードをレビューしなくてもいいとは思ってないよ。すぐにスパゲッティ状態になっちゃうから、誰も「vibe coding」を数時間以上続けられるとは思えない。今、LLMが返してくれたものをレビューして、慎重に形を整えて次に進むのは、私のプログラミングにすごく役立ってる。でも、LLMが正しいコンテキストを持っていたかどうかを慎重に確認する必要があるね。そうじゃないと、盲目的にLLMが渡してくれたものを受け入れることになる、いわゆる「vibe coding」になっちゃう。

その技術的じゃないエンジニアリングマネージャーたちはどこにいるんだろう？どうやってビジネスに残ってるのかも不思議だ。15年以上、本当に技術的じゃないマネージャーを見たことがないよ。

マネージャーをCTOやCEO、ビジネスオーナーや投資家に報告するかな。

それをデバッグするには、2倍賢いものが必要だよ。 もしかしたら、LLMの「中間」と「高」レベルの思考モードの違いかもね。ちなみに、存在しなきゃいけない複雑な関数については、LLMに意図やアプローチを説明するコードコメントを書かせてるよ。

完全にそうとは言えないけど、運転手になる必要があるね。主にClaude Codeを使ってるけど、時々バカなミスをすることがある。大抵は問題を修正するように頼むと直してくれるけど、たまに「間違った方向に進んでるよ」と言って、書いたコードのどこに問題があるか教えなきゃいけないこともある。つまり、デバッグは同じ「知能」レベルでできるけど、LLMは自分が何をしているのか本当に理解してないから、自分では理解できないエラーを起こすことがある。経験的には、ジュニアプログラマーと一緒に働いてる感じだね。彼らはコードを書けるけど、何が間違ってるのか分からないっていう。

もう一つ大きな違いがあるんだ：自然言語にはあいまいさが組み込まれてる。プログラミング言語に解析のあいまいさがあったら、それは大きなバグと見なされるけど、自然言語ではそれがほぼ特徴になってる。詩や含み、その他の微妙なコミュニケーションを可能にするんだよね。

ほとんどのプログラマーは低レベルのアセンブリや機械語を理解してない。 生計を立てるためにJavaScriptを書くほとんどのプログラマーは、JavaScriptでアプリケーションをスケールさせる方法を本当に理解してない。スケールできる機能を実現するためには、抽象化のレイヤーに依存しているんだ。彼らはブラウザの主要APIであるDOMを全く理解してないし、多くの人はブラウザ外のNode APIも理解してない。外部の観察者から見ると、まさに「オフィス・スペース」の質問が浮かぶよね：ここで何をしていると思う？ ソフトウェアとは全く関係ない人に説明するのは変な感じだ。ソフトウェアにいる私たちは、これに慣れすぎていて、この狂気を避けられない現実として当然に受け入れてる。皮肉なことに、あなたのコメントの観点から言うと、JavaScript開発者にこの基本的な知識の欠如を指摘すると、アセンブリとの比較がよく出てくる。まるでJavaScriptを書くことが機械語を書くことと同じように思えるけど、その職業の多くの人にとっては、両者は遠く離れた現実なんだ。LLMの導入は完全に理にかなってる。誰もこのコードがどう動くか知らないなら、機械に書かせることに害はないよ。なぜなら、根本的な認識に違いがないから。

自然言語の仕様が役立つと思うけど、厳密な意味論を持つ中間的な記述レイヤーが必要だと思う。例えば、Rustを使ったLLM駆動のコーディングでは、強い型システムがより緩やかまたは未型付けの言語で発生する無効な状態を防いでくれるから、成功することが多い。時間はかかるけど、LLMはコンパイルできる状態に達するためにcargo checkサイクルを繰り返す必要があることが多い。でも、一度コンパイルできれば、変更はほとんど正しいことが多い。Rustコミュニティには「コンパイルできれば、おそらく動く」という言葉がある。もちろん論理バグはまだたくさんあるけど、間違いの可能性の範囲は狭い。理想的なのは、LLMが実装しなければならないアプリケーションの意味論を非常に厳密に定義したもので、それが実装と照らし合わせてチェックできることだね。つまり、依存型を持つ非常に厳格なプログラミング言語で、前提条件や後提条件が散りばめられているようなもの。LLMは自然言語の説明を形式的な仕様に変換するのを手伝うことができるけど、その仕様が実装を駆動するべきだと思う。

違いは、自然言語での高い抽象化へのジャンプだけじゃないんだ。根本的に違う何かなんだよ。以前のツール（アセンブラ、コンパイラ、フレームワーク）は、チェックできて数学的に検証もできるハードコーディングされたロジックに基づいて作られてた。だから、立っているものを信頼できた。でも、LLMでは、安全に構築された塔から不確実性、推測、幻覚の世界に飛び込むことになる。

なんだか、多くの非常に賢いAI起業家が、ロスレスデータ圧縮の限界という概念を理解していない。もしアイデアが情報を失わずにさらに削減できないなら、どんなAIでもそれを圧縮することはできない。だから、Slackやメール、Jiraの効率に関する失敗したスタートアップがたくさんあるんだ。半分の時間、重要な情報を見逃したかどうかわからないから、ソースに戻る必要があって、成功裏に要約された情報で得た利益を無駄にしてしまうんだ。