動くコードがすぐ出てくる高揚感は変わらないのに、「完成した」と感じるまでの距離感だけが変わった——という海外エンジニアの体感を軸に、AIコーディングで速くなる作業と速くならない作業の境界線を考える。
「なぜ体感ほど速くならないのか」を客観的な受け入れ基準の有無という1つの軸で説明する視点と、自分のタスクを「効きやすい」「効きにくい」に仕分けるためのチェックリスト。
個人ブログ「obryant.dev」に投稿された「2x, not 10x: coding with LLMs in 2026」という記事が、Hacker Newsで172ポイント集めて話題になった。主張はタイトルの通りシンプルで、「LLMコーディングは10倍速ではなく2倍速だ」というものだ。
著者が挙げる一番印象的な変化は、数値ではなく感覚の話だ。「動くコードができた」という瞬間が、以前は体感で"8割終わった"ことを意味していたのに、今は"2割"程度の意味しか持たなくなったという。AIに実装を頼めば数分でそれらしく動くコードが出てくる。だがそこから先——構造の見直し、ドキュメントとの整合、エッジケースの洗い出し——にかかる時間は以前とほとんど変わらない。「動く」までの距離が縮んだ分だけ、「動く」の先にある工程の存在が相対的に大きく見えるようになった、という話だ。
これは筆者だけの感覚ではない。このブログで以前扱ったZOZOの1年間の工数実測でも、「体感は3人分、実測は0.58人月」という同じ方向のズレが報告されていた。実装が一瞬で終わる体験は強く記憶に残るが、レビューや調整にかかる時間は変わらない——ボトルネックが「書く」から「人間が確認する」へ移っただけなのに、体感は「書く」の速さで全体を評価してしまう。obryant.devの記事は、この同じ現象を個人の開発体験の側から言語化したものといえる。
著者はこの頭打ち感を、階段を上る動作にたとえて説明している。
階段を上るには、脚を1段分の高さまで上げられればいい。3段分・5段分を一気に飛び越える力は、ほとんどの場面で不要だ。著者は、LLMのコーディング能力が「実用的なレベル」という1段目を超えた時点で採用が一気に進んだとみている。その後さらにモデルが賢くなっても、体感できる恩恵は最初の1段目ほど大きくならない。
著者の仮説は、LLM採用が加速した理由を「自動化されたフィードバックループの中で確実に動くレベルに達したこと」に置く。テストが通る・ビルドが通る・型チェックが通るといった機械的に判定できる基準がある作業は、AIが結果を自分で確認しながら反復できるため急速に速くなった。逆に言えば、そういう基準が存在しない作業では、いくらモデルが賢くなっても同じようには伸びない。
ここが核心。速くなったかどうかを分けているのは「モデルの賢さ」ではなく、その作業に客観的な受け入れ基準があるかどうかだった。基準があれば人間のチェックを介さずAIが自走できる。基準がなければ、最終的な判断はいつも人間に戻ってくる。
著者が挙げる具体例を、「速くなる」「速くならない」で並べ直すとはっきり分かれる。
「ボタンを1つ作って、クリックしたら期待通りに動く」のような、成果物を見れば良し悪しがすぐ判定できるタスク。反復フィードバックがそのまま効くため、AIが自力で収束させやすい。
「これはもっと保守しやすい構造か？」「このドキュメントの説明は正確か？」といった問いには、機械的に判定できる正解がない。著者はこうした判断は今のLLMではまだ信頼性不足だとしている。
著者自身が試した具体的な工夫として、「READMEやドキュメント、コメントを書かせない」という指示を与えると出力の質が上がったという話も紹介されている。文章生成のような"それっぽく見えるが検証しづらい"出力をAIに任せると、かえって質の低い成果物が増えるという実感だ。逆に構造改善のような反復作業は、期待していたよりずっと時間がかかったとも述べている。全体として著者は、AIコーディングは「インタラクティブなチャットで相談しながら進める」段階から、「あらかじめ仕様を宣言的に書いておく」段階へ移りつつあると捉えている。
ここで挙げた数値（10倍速でなく2倍速、完成度8割→2割）はいずれも著者個人の観測であり、統制された計測ではない。だが「客観的な受け入れ基準の有無」という切り口は、他人のタスクにも自分のタスクにも当てはめて検証できる。AIに何かを渡す前に、次の3点で仕分けると期待値のズレを減らせる。