- プログラミング向けAIは既存のコンパイラと似た役割構造を持つ
- 英語のプロンプトは、プログラミング言語として不正確で非効率的な性質を持つ
- AIの生産性向上効果は、実際には誇張または誤認される傾向がある
- AIツールは開発プロセスを変えるが、真の革新はより良い言語とツールから生まれる可能性がある
- LLM導入が開発者の代替を意味するわけではなく、むしろ現在の開発環境の限界を反映している
AIとコンパイラの類似性
- 筆者は年を重ねるにつれて、もはや他人を説得しようとする試みをやめた
- 多くの人は真実には関心がなく、自分に利益をもたらす信念だけを追う現象を強調している
- 「Perception is reality（認識こそ現実）」を主張する人々への批判を示している
- 自動運転車に投じられた数十億ドルが誤った信念による浪費だと指摘している
- AIがコーディングできると信じる見方は、コンパイラがコーディングしていると考える見方に近い
AIコーディングはコンパイラと同じモデル
- プログラミングAIの最適なモデルはコンパイラだという主張を説明している
- ユーザーはプロンプト（コード）を入力し、その結果としてコンパイルされた出力を受け取る
- プロンプトを英語で入力する点は異なるが、英語には明確性の欠如や仕様の不在など、さまざまな欠点がある
- 新しい仕事や複雑な作業を行うとき、結局はプロンプトの冗長さが増していく
- AIの出力は非決定的であり、プロンプトの一部を変えると全体の結果に影響する
AIコーディングに対する批判的視点
- AIコーディングが好意的に見えるのは、現在のツール、言語、ライブラリの貧弱さが理由である
- 「AI」技術によって、以前より優れた検索、最適化、パターン抽出ツールが可能になった
- 実際にコーディングしているのはプログラマー自身であり、コードを書くという行為の言語が変わっただけである
- LLMが開発者を代替できる会社があるとすれば、それは会社のコードベースと採用基準が非常に低い状態であることを意味する
- AIはコンパイラやスプレッドシートのように、段階的に一部業務を代替できる
AIはツール、最終的にはより良い言語・ライブラリが必要
- AIに対する道具としての視点から、多くの思考と注意が必要であることを強調している
- 誤った期待や幻想に投資することで、数十億ドル規模の浪費が起きている
- 「vibe coding」のような虚偽の生産性ツールに対する市場の過剰反応に言及している
- AIが実際に生産性を20%高めるという錯覚があるが、実際には19%遅くなるという研究（論文）結果を引用している
- 真の進歩はプログラミング言語、コンパイラ、ライブラリの革新から生まれうる
1件のコメント
Hacker Newsの意見
私はもうすぐ50歳で、90年代後半からプロとしてコードを書いてきた。頭の中にプロジェクトがすぐに思い描けて、何を作るべきかも正確にわかっている。給料もかなり高いほうだ。見た目にはAI反対派の典型のように見えるかもしれないが、実際は違う。何でも作れるが、あらゆる基礎的な作業にはうんざりすることが多い。だからAIを使って退屈な部分を素早く通過し、自分が好きな核心の作業に集中できる点が本当に気に入っている。AI開発は、ジュニアとミドルレベルの間くらいの開発者に、数文で考えを伝えて1時間分の仕事をさせるのに似ている。ただし、実際のジュニアが成長できなくなって将来のシニア開発者の層が縮小する点は真剣に考えるべき問題だが、これは別の問題だ
私はAIを使って退屈な部分を速攻で片付けると言ったが、経験豊富なシニア開発者の中には、むしろ険しい部分が怖くてAIに否定的な人もいる。多くの開発者は退屈で簡単なパートに心理的な安全を見いだしているが、AIが導入されると仕事そのものが絶え間ない困難の連続になってしまうことがある。長年の経験だけあって実力は不足しているシニアなら、挑戦的な仕事を立て続けに任されるとすぐ燃え尽きる。企業はAIを導入してとにかく速度だけを上げようとするが、人間には認知的な休息が必要だという点を見落としている。きつい仕事ばかりが残るのは人にとってよくない。もちろん、反復的で簡単な仕事に飽きている開発者は、AIとともに再生できる。結局は個人ごとに違うアプローチが必要だ
私もあなたより少し若いが、考えはほとんど完全に同じだ。むしろもっと極端かもしれない。面白いアイデアを実現するコードを書くことよりも、アイデアを出して実験すること自体が楽しいと感じるようになった。だからコーディングは必要だからやってきただけで、本質的にやりたいことではない。自分のアイデアを実現したければ、仕方なくコードを書いてきた。AIはブレインストーミングの相手として非常に優秀だ。おべっかを使わないよう頼めば、自分がオーバーエンジニアリングしているときに本当に率直に指摘してくれる。デバッグも本当にうまい。だから私はコンピュータに言葉で説明しながらアーキテクチャや方法をブレインストーミングし、仕様を作ってからAIに実装を任せる。もし考えが間違っていれば、AIと反復的に素早く改善する。反復があまりにも速いので、失敗しても構わない。間違った設計でも以前ならコード全体を変える必要があってそのまま耐えていたが、Agentic codingツールのおかげでコードベース全体の変更も問題ない。新しい技術分野にも専門家ではなかったが、AIのおかげで効果的に参入し、すぐに実力を伸ばせた。正直、今がプログラマー人生でいちばん幸せだ。ツールは毎週、時には週に何度も良くなっている
私の経験とも完全に一致する。私も同じくらいのキャリアだ。私はAIを個人作業にも会社の業務にもどちらにも積極的に活用している。第一に、AIは偏見の少ないアイデア相談役になってくれる。速いフィードバックループと方向性の検証が本当に不可欠だと感じる。第二に、タイピングと時間を節約してくれる。『基本作業』は一度に指示すれば少なくとも80%は完璧に処理してくれる。100%完成ではないが、節約される時間のほうがはるかに大きいので絶対的に得だ。AIを使うときは常にガードレールを設け、指示をできるだけ具体的かつ詳細に伝え、成果物は必ず自分で確認する習慣がついてきている
経験は10年ほど少ないが似た立場だ。ただ、私はあまり共感できない。どこかのパートが退屈になってくる頃には、すぐ自動化・一般化するのがとても難しくてチャレンジングなので、実際には退屈な仕事がほとんどなくなる。むしろ自分で直接タイプしたほうが速い。中間でも単純でもないパートで自分でコードを書いていると、より良い構造や自動化のアイデアが浮かぶ。そのおかげで、むしろ渡してしまいたいコードはほとんどない。そしてこういう考え方ができたのは、一つの会社に長くいたからだと思う。もし新しいコード作業をずっと続けていたなら、考えは違っていたかもしれない
私も50代で、90年代からコーディングしてきて、一生で3回は使い切れないくらいの金も稼いだ。30年のキャリアの中で、最高の開発者たちに共通する特徴があった。それは『完璧な怠け者』であることだ。少し変かもしれないが、優れたエンジニアの共通した特性は怠け者であることしかなかった。怠けがどうやって生産性につながるのか不思議なくらいだ。理由は、繰り返し作業を必ず自動化するからだ。同じことを2回やるなら、必ず3回目の自動化が必要だという鉄則を学んだ。AIの登場で、自動化の水準そのものが完全に変わった。以前はできなかったあらゆる作業まで自動化できるようになった。AIの活用法を数え切れないほど見つけ出し、私だけでなく怠け者の同僚たちも本当にうまく使っている。今ではAIなしの仕事そのものが想像できない。『魔法』だからではなく、私のような怠け者のために、自動化できる作業をAIが全部代わりにやってくれるからだ
これはHacker Newsでよく見られるAI関連の集団思考の極端な例だと思う。Geohotは上位99.999%の開発者かもしれないが、彼が理解していない残り99.999%の開発者は、引き続きもっと基礎的な仕事をしている。専門家のパラドックスだ。もし全員が専門家レベルだったなら、彼らは専門家ではなかったはずだ。AIのように振る舞う開発者をたくさん見てきた。自分が作ったコードベースさえ説明できず、一貫して管理もできない。まるで航空宇宙エンジニアが、Kinder Surpriseのおもちゃを作る人に流体シミュレーションを知らないといってからかうようなものだ
HNがAIに否定的だと思っていることに驚く。私から見ると、コメントや人気記事を見るかぎり、HN全体は技術にかなり楽観的だと感じる
自動運転会社を創業した人がこんな立場を取るのも、非常に一貫性がないように見える。もしAIモデルがコードを書けないなら、運転というもっと難しい仕事を代替できるのか疑問だ
記事の前半でもうこの点の説明は出てくる。さまざまな一般的なプログラミングワークフローはあまりにもありふれているから可能なのであって、新しいことをやるには言語レベルと同じくらい詳細に説明しなければならない、というのが要点だ
航空宇宙分野で働いているが、ここのエンジニアたちも別に優れているわけではない。でも心配しすぎる必要はない。会社ではこういう人たちは何の害も与えないポジションに回されて、たいてい管理職になる
Geohotが本当に上位99.999%の最高の開発者なのかはわからない。"プログラミングAIの最適モデルはまさにコンパイラだ。プロンプト（=コード）を与えると、コンパイルされたコードを出してくる。たいていのIDEのようにフィードバックを返してインタラクティブに使うより、プロンプト調整→再コンパイルのほうがよい。" これが本当に正しいのか疑問だ
議論の核心の一つは、『プログラミングの種類』をもう少し具体的に定義する必要があるということだ。ロボットが何かを作るのに『ロボットは良いか、悪いか？』とだけ聞いても意味がないのと同じで、『何を対象に？』という問いが前提になってこそ議論が進む
この文章にはいろいろ問題があると思う。第一に、『AIコーディングはコンパイラだ』という主張だが、コンパイラは仕様に従って言語を決定的に変換する一方で、LLMコーディングツールは制約（テスト、型、リンター、CIなど）の下で反復的にコードを検索・生成・修正するプログラム合成器だ。実際、SWE-bench Verified のような大規模なオープンソースのIssueもエンドツーエンドで解決している。第二に、『プログラミング言語は英語だ』という主張。現実にはコード、テスト、仕様、API、JSONスキーマ、diff、IDEツールなどの組み合わせであり、英語はただの接着剤にすぎない。著者は最も弱いインターフェースだけをつまみ食いして攻撃している。第三に、非決定性が問題だという主張。現実にはfuzzingやSAT/SMTなどに確率的要素は多いが、最終的な決定性と正確性は外部仕様（テスト、型システム、CIなど）から来る。そして、LLMが人気なのは言語やライブラリが悪いからだというのは誤った二分法だ。たとえばRustやTypeScriptのように言語が良くなっても、LLMは依然としてAPI検索、レポジトリのトレース、反復コードの作成、マイグレーション、テスト作成、リファクタリングなどで役に立つ。最後に、『もっと良い言語やコンパイラを作れ』という代案しか示していないが、すでに現代のチームはAIとの組み合わせで大きな価値を得ている。だからAIコーディングやLLMを『プロンプトで操作する魔法のような英語コンパイラ』と無条件に信じるのではなく、自分なりの制約（型、テスト、CIなど）を基準に手伝ってくれる『ジュニアのペアプログラマー』のように活用するほうが、はるかに現実的だ
（投稿者本人）この意見に同意する。もしブログ記事をこう書いていたら人気は出なかった気がする。『LLMコーディングツールは探索ベースのプログラム合成器だ』という説明は、私の考えでは事実上コンパイラの定義にかなり近い。ただし、大半のコンパイラが十分な探索をせずヒューリスティックに大きく依存しているのは、ランタイム統合がされていないからにすぎないと思う。『エンジニアリングツールには非決定的なものが多い』というのはその通りだが、たとえばSATソルバでランダム性が導入されて解決時間が変わっても、正しさ自体には影響しない。ファザー（fuzzer）はテスト目的なので、本質的に完全性は期待されていない。本番環境に導入されたファザーは見たことがない。『決定性は外部のテストや仕様から来る』という主張には完全に共感する。私が夢見ているのは、実装方法ではなく振る舞いを仕様だけで記述する言語だ。Halideのscheduleの概念をより一般化した感じだ。コンピュータが実装方法を自分で見つける。こうしたツールをAIが提供できると思っている。それは必ずしもLLMである必要はなく、厳密な仕様が必須だ。それ自体が結局プログラミングなのだ。この観点から、AIを『魔法の英語コンパイラ』と見ることには反対だ。ツールの強みと限界を認識しながら作業補助の手段として使うなら、本当に良いワークフローになる
卓越した返答だ。全面的に同意する
こういう問題のある文章を書いたのが意外ではない。投稿者がGeorge Hotz、つまりGeohotだからだ
私はOpenpilotもclaude codeもよく使う。二つのツールをほぼ同列に見ている。Openpilotは高速道路など単純な状況では何時間も本当にうまく走る。claude codeは直感的なリファクタリング、ボイラープレート、スキャフォールディング、git bisectなどの反復作業を、私の入力なしでもこなす。どちらも結局『運転手』を置き換えるものではない。claude codeはプログラミングにおけるレベル2自動運転のような存在だ
METRの研究はタイトルのおかげで非常に人気を集めた。実際に精読した人は少ないように思う——かなり長かったからだ。しかしデータでは、CursorやAIの活用経験が最も多い一人にだけ50%の速度向上が観測された。慣れた後にこそ成果が際立つことを示唆している。また、小規模サンプルでは統計的な変動も大きい。その後、別の一人の速度差が誤記録だったと訂正されたが、それでも結果の意味をめぐる疑問は残る。研究で測定された非効率の要素は、改善されたLLMや並列エージェントなど、発展した技術によって十分解消できる部分だ。研究当時に使われたのは従来のClaude 3.7時代で、Claude Code以前の時点だった。実際に20%仕事が減ったような『体感』も十分に重要な価値だ。楽しく働ければ時間はあっという間に過ぎる
AIラボがこれまでAIを過剰に売り込みすぎてきた問題だ。『AIは本当に考えている、単なるパターンマッチングではない』というスローガンが多い。私はAIツールを作り使う立場として、むしろパターンマッチングベースの『次トークン予測器』として扱う見方のほうがずっと役に立つと感じる。文脈に無駄な情報をたくさん入れると、AIが一般化に失敗することが多い。これは結局、パターンマッチングと次トークン予測そのものだ。『AI技術が今日の非常に良いツールに貢献できる』とは思うが、これは大量の探索・最適化と既存パターンの再利用による結果だ。たとえばClaude codeに単純なCRUD APIを書かせると1分で出てきて、私の時間を1時間も節約してくれる。何十万回もすでに実装されたアルゴリズムを頼めば、すぐ正確なコードを出してくれる。AIを自分の専門領域でだけ使えば本当によく動く。それ以外では結果はいまひとつだ
これは知能（intelligence）の段階差の問題だ。知識ではなく、根本的な思考力の差だ。私たちは特定の仕事に必要な認知的努力を過小評価している。しかし、ときにはAIが思ったより『思慮深い』振る舞いを見せることもある。そういうときは本当に魔法のように感じる
CRUDやボイラープレートは、実のところツール化でもある程度は解決できる。だがAIでしかできないことも多い。たとえば、私がトレースレベルのログ全体をテストしながら分析しなければならないとき、何百行も自分の目で追うのはものすごく時間がかかるが、AIに『テストを実行して原因を見つけて』と言えば、十分使える結果が返ってくる。最近ではこれがいつも最初のステップになっている
あなたの意見にもある程度の真実はあると思う。だがビジネスの世界には『秩序再編への渇望』が非常に強い。膨大な資金が短期間で大きな収益を求め、ファンドマネージャーはトレンドを追えなければクビになる。CIOやCEOも同じだ。AI導入競争は核兵器競争のように、すでに止められない。本質的には誰にとっても良いことではない。だが他のみんなが飛び込むので、自分だけやらないわけにはいかない。自動車が登場する前でも、人間は十分幸せだった。しかし自動車によって都市は再編され、建物と建物の間はどんどん離れ、通勤も日常になった。AIも同じように、私たちが働く文脈そのものを変えてしまう。今や誰もがAIを使うべきだという期待が生まれ、ある時点では『基本必須』のように感じられる。さらに言えば、科学技術が生み出した商品のうち、本当に人間の『必需品』だったものはほとんどない。技術が問題を作り出し、それを解決策として売り込むのだ。問題はもともとなかったのに、ソリューションが出てきて初めて問題になる。これこそがビジネスを動かす核心の原動力だ
AIコーディングに関するオピニオン記事のかなりの部分は、非常に経験豊富なソフトウェアエンジニア、いわゆる『アイボリータワー』の視点から書かれているように見える。（当該研究も『経験豊富なオープンソース開発者16名』だけを対象にしている）しかし非専門家にとっては、こうしたツールはとてつもなく価値がある。私にも多少のコーディング経験はあるが、本業ではない（視覚芸術家だ）。以前なら数日かかっていたことを、午後半日で終えられる。2か月前に仕事を辞めてゲーム開発に集中しているが、予算に余裕はないもののClaudeとChatGPTは絶対に維持している。また、夜中の1時にベッドで何かアイデアを書き留めて、すぐCodexに投げておき、朝起きて動かしてみるのは本当に魔法のようだ。以前は『これが本当に最善の方法なのか？』という不安のせいで始めるのをためらっていたが、今はリファクタリングが簡単なのでそうした不安が消えた。コードを直接書くことだけでなく、心理的ハードルを下げてくれる効果も大きい。もちろん、批判の多くが実際にはこのツールのマーケティングの誇張や、『これでもうエンジニアはみんなクビになる』という言説に向けられていることも理解している
私は72歳で、40年間開発者として働いてきた。以前ほど超集中はできないが、AIのおかげで今もなお何かを作っている。私がプロジェクトの仕様を組み、エージェントが実装からテストまで担当する。今では楽しみのためだけにコーディングしている