「LLMは熟練者ほど得をする」GitHub Copilotエンジニアの指摘

プロンプトのコツをまとめた記事を何本読んでも、返ってくるコードの質は変わりません。

その理由を1本のエッセイで説明した現役エンジニアがいて、Hacker Newsで1,393ポイント、566コメントまで伸びました。

種明かしは、数学者Terence Taoさんのやたら短い質問文にあります。

数学者Terence Taoの短すぎる質問が示すもの

Terence Taoさんが、ヤコビアン予想（Jacobian Conjecture）の反例をめぐってChatGPTと交わした対話ログが公開されています。

そのログを読み込んだSean Goedeckeさんが、素人との違いを3点挙げています。

1. メッセージが極端に短い。前置きも役割設定もなく、要点だけ
2. 出力が怪しいとき、正面から否定しない。「これは期待していたより複雑に見える」と押し戻す
3. 次にどこへ進むかをモデルに聞かない。飛躍も提案も自分でやる

面白いのは、この3つがどれもプロンプト技術ではないところです。

「ここは複雑すぎる」と言えるのは、答えがもっと単純な形をしているはずだと数学の側で分かっているからです。

短く書けるのも同じ理由で、必要な情報が何かを既に知っているから削れます。

Taoさんの対話の質を支えていたのは、プロンプトの型ではなく数学そのものでした。

Sean Goedeckeとは GitHub Copilotを書いている現役エンジニア

Sean Goedeckeさんはオーストラリア・メルボルンを拠点にするソフトウェアエンジニアです。

Zendeskで5年ほど働いてStaff Engineerになり、2021年にGitHubへ移りました。

いまはCopilotのチームでStaff Software Engineerを務めていて、著書に『Software Engineering after the Vibe Shift』があります。

LLMを毎日使う側であり、LLMを載せた製品を作る側でもある。この二重の立ち位置が、今回の論の重みになっています。

LLMs reward expertise

www.seangoedecke.com

ボトルネックはモデルではなく人間

エッセイの中心はこの一文です。

the human is the bottleneck, not the model

（ボトルネックはモデルではなく人間だ）

難しいのはモデルが知らないことではなく、自分がどんな解を欲しいのかをモデルに伝えることだ、という主張です。

もう一文あります。

the most important skill in prompting is expertise in the domain you're prompting for

（プロンプトで最も重要なスキルは、そのプロンプトが扱う領域の専門性である）

Goedeckeさんはこれを2010年代と比べます。

CSSが書けなければ、詳しい同僚に頼むか、自分の問題そのものの答えがネットに落ちていることを祈るしかなかった。

いまはモデルがその穴を埋めてくれます。

だから差がつくのは穴を埋めたあとの部分で、そこには専門性しか残っていません。

全員が同じモデルに話しかけている以上、「プロンプトが上手い人」という優位はもう消えかけている、とも書いています。

コードベースの理解がプロンプトの質を変える

Goedeckeさん自身の経験として挙がるのが、GitHubのコードベースを扱うときの話です。

If you have a good theory of your codebase, you can push the LLM much harder than if you have no familiarity

（自分のコードベースについて良い理論を持っていれば、馴染みがない場合よりずっと強くLLMを押し込める）

つまり「no, I think it could be simpler here（いや、ここはもっとシンプルにできるはずだ）」と言い返せるかどうかで、引き出せる量が変わります。

私が仕様設計とテスト設計に時間を使っているのは、まさにここです。

知らないコードベースを触っているときは、出てきた実装が妥当かどうか判断できないので、そのまま受け取るしかありません。

逆に設計意図を握っていれば、余計な抽象化が1枚挟まった瞬間に「その層は要らない」と返せます。

同じモデル、同じ課題でも、この一往復があるかないかで最終的な差し引きが変わります。

Hacker Newsで割れた賛否

566コメントは一枚岩ではありませんでした。

賛成側は経験談が中心です。実装の細部はLLMが強い、ただ問題領域を理解していないと道具として効かない、という声が並びました。

懐疑側の指摘は鋭くて、もっともらしいけれど自分たちにはまだ価値があると安心させてくれる主張には疑いを持ったほうがいい、というものです。

最も刺さる反論はこれでした。

検証器を書けるだけのドメイン知識があれば、それ以上は必要なのか。検証器さえあれば、あとは計算資源の問題では

出力の正しさを機械的に判定できる領域なら、確かに人間の理解は要らなくなります。裏を返せば、判定を自動化できない領域にだけ専門性の出番が残る、とも読めます。

批判側は「熟練者に効くのは当たり前で、プロ向けのエッセイとしては目新しくない」という見方でした。

この批判には半分同意します。当たり前のことが、なぜかAIコーディングの文脈でだけ忘れられている、というのが実態に近いと思います。

議論の全体はHacker Newsのスレッドで読めます。

「2倍の壁」と「スキル問題」に繋がる話

ここ最近、別々の人が同じ絵を違う角度から描いています。

Jacob O'Bryantさんの「LLMコーディングは2倍止まり」論は、自動フィードバックループのない領域では倍率が伸びないという話でした。

Biff作者Jacob O'Bryantが語るLLMコーディング2倍論

Clojure WebフレームワークBiffの作者Jacob O'BryantさんがHacker Newsで注目を集めています。主張は端的で「LLMコーディングの生産性向上は2倍が現実的な上限で、10倍化はもう来ない」というもの。モデルをさらに賢くしても効きが薄い理由と、Claude Codeで私が実測した数字を...

aimanavo.com

Andrej Karpathyさんの「スキル問題」告白は、新しい抽象層を組み合わせきれていないのは自分の側だ、と認めるものでした。

Karpathyが告白した「スキル問題」とSoftware 3.0の抽象層地図

agents、subagents、skills、hooks、MCP、LSP。名前を追いかけるだけで頭が疲れます。そのモヤモヤに、Andrej Karpathyさんが2025年末「10倍出せるはずなのに出せていないのは、明確に自分のスキル問題だ」と一撃を刺しました。列挙された新しい抽象層をOSの三層構造で読み解いて...

aimanavo.com

そこに今回、人間の理解が上限を決めているという見立てが加わりました。

3つとも、上限を決めているのはモデルではないと言っています。

専門性が効くなら 何を鍛えるか

Taoさんの3つの振る舞いを、そのままコードの側に置き換えるとこうなります。

1. 触っているコードベースの「理論」を先に作る。どこが境界で、なぜこの設計になったのかを言葉にできる状態にしておく
2. 出力を「複雑すぎる」と判断できる基準を持つ。単純な答えの形を先に想像しておかないと、複雑さには気づけません
3. 次の一手をモデルに聞かない。方向はこちらが決めて、実行だけ任せる

モデルがこの先どれだけ賢くなっても、ここは人間側に残ります。

プロンプト集を増やすより、この3つのほうが効きます。

そして専門性は、いま目の前にあるコードを深く読むことでしか増えません。