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

Clojure WebフレームワークBiffの作者Jacob O'BryantさんがHacker Newsで注目を集めています。

主張は端的で「LLMコーディングの生産性向上は2倍が現実的な上限で、10倍化はもう来ない」というもの。

モデルをさらに賢くしても効きが薄い理由と、Claude Codeで私が実測した数字を突き合わせて考えます。

Jacob O'Bryantとは何者か

Jacob O'Bryantさんは、Tybaのソフトウェアエンジニアで、ソロ開発者向けのClojure WebフレームワークBiffとニュースリーダーアプリYakreadを長年運用している開発者です。

GitHub - jacobobryant/biff: A Clojure web framework for solo developers.

A Clojure web framework for solo developers. Contribute to jacobobryant/biff development by creating an account on GitHub.

github.com

Biffは"A Clojure web framework for solo developers"を掲げ、JUXTとClojurists Togetherから助成を受けたOSS。

YakreadはBiffで構築された実プロダクトで、意図的にコードベース1万行超をオープンソース化しています。

VC資金でハイプを煽る立場ではなく、副業で自分の道具を作り自分で運用してきた現場側の書き手。

この立ち位置が「10倍」言説への冷静な距離感につながっています。

2倍が現実的な上限という主張の中身

2026年7月25日公開のエッセイ「2x, not 10x: coding with LLMs in 2026」でO'Bryantさんはこう書きます。

"further model improvements alone are unlikely to get us to a 10x productivity boost over the dark ages of 2025."

（モデル性能のさらなる向上だけでは、2025年以前と比べて10倍の生産性には届かない）

なぜ上限を2倍と見積もるのか。

O'Bryantさんは、2026年のLLM普及加速の主因を「automated feedback loops（著者の言葉を借りれば自動フィードバックループ）」で信頼できる精度に達したことだと定義します。

ボタンを作って動かして直して、を短いサイクルで自動で回せる閾値を、モデルが既に越えたという見立てです。

そのうえで階段の比喩を出します。

"to walk up a set of stairs you need to be tall enough to get up at least one step at a time, but being so tall you can take two or three steps at once matters a lot less."

（階段は一段ずつ上れる背の高さがあれば足りる。それ以上背が高くて2〜3段まとめて上れても、効果は大幅に小さい）

閾値さえ越えれば、その先の性能向上は「1段が2段になる」程度で、10倍になる話ではない、と。

実装完了は80%から20%に変わった

特に刺さるのが次の一節です。

"A working implementation used to mean a task was 80% done; now it's more like 20%."

（動く実装ができた時点で、以前はタスクの80%完了と見なせた。今は20%完了くらい）

動くコードを書くこと自体はLLMが安くしてくれました。

その分、レビュー・仕上げ・保守性確保・仕様との突き合わせが、相対的にタスクの主体になったという含意です。

体感でも合います。

Claude Codeにファイルを渡せば数分でPRの叩き台が出てくる時代、書く速度は明らかに上がりました。

ただ、そこから「本番に出せる状態」までの手数は減っていません。

むしろ増えている作業もあります。

HNで198ポイント 賛否の中身

このエッセイは執筆時点でHacker News 198pt・158コメントを集めています。

反応は割れました。

反論側の主軸は3つ。

1: 得意領域なら10倍以上出る。

特にWebフロントエンドや個人開発では「LLMがなければ着手すらしなかった案件」ができるようになった、という声。
2: そもそもコーディングは全工程の4分の1程度。

計画25%・実装25%・テスト25%・レビュー25%とすれば、実装だけ2倍になっても全体では焼け石に水（アムダールの法則的指摘）。
3: レビュー基準が下がっている。

1年前なら通らなかったコードが今は通っている。

体感の生産性向上が品質の目減りで相殺されているという懸念。

賛成側は「アイデア試行の裾野が広がった」「複数設計を並行検証できる」といった、倍率では測れない価値を挙げる方向。

O'Bryantさんへの正面反対というより「そもそも倍率で測るのが違う」という論点ずらしに近いです。

Claude Codeで実際に測ったら何倍だったか

私が業務システム系の案件で毎日Claude Codeを回して感じているのは、O'Bryantさんの数字にかなり近い、という感覚です。

書く速度だけを切り取れば3〜5倍出ることもあります。

テンプレコード・データ整形スクリプト・単純なCRUD周りは特に速い。

ただ、案件全体で1週間の完了までを含めて測ると、2倍前後に落ち着きます。

理由はO'Bryantさんの通り。

動く実装が出るまでが速くなった分、レビュー・型調整・データ移行の整合・エッジケース検証といった「動いた後の作業」が相対的に肥大化しています。

レガシー資産と接続する案件では、この後半戦の比重が7割を超えることも普通です。

過去に「Claude Codeで3〜5倍」と紹介した数字もあります。

あれは書く速度に閉じた数字で、案件全体の倍率ではない、と今なら注釈を入れるところ。

O'Bryantさんの2倍論はこの注釈と整合します。

何倍を追うより フィードバックループを作り込む

エッセイの締めが印象的です。

"But in the mean time, I'll stick with my hand-crafted READMEs."

（それまでは、手作業で書いたREADMEを使い続ける）

モデルがさらに賢くなるのを待つのではなく、今のLLM能力を前提に、人間側の工具・プロセスを再構成する。

O'Bryantさんが自分のフレームワークで実践してきた立場そのものです。

私の答えも同じで、「Claude Codeで何倍か」を議論するより、次のサイクルを短くする仕組みに投資したほうが確実にリターンが出ます。

テストが1コマンドで走る、ログが1画面で読める、READMEがエージェントに読ませて成立する構成。

この地道な準備が2倍を4倍に持っていく現実的な道です。

10倍を待つ暇があったら、今の2倍を確実に自分の環境で出せる形に落とし込むほうが、はるかに速く効きます。