コーディングワークフローの変化
- 2024年11月には 80% 手動+オートコンプリート、20% がエージェントコーディングだったが、12月にはこの比率が逆転し、80% がエージェントコーディング、20% が修正/タッチアップへと移行
- 実質的に 英語でプログラミング している状態になり、LLMにどんなコードを書くかを言葉で指示する形
- プライドが傷つく部分はあるが、大規模な「コードアクション」単位 でソフトウェアを扱える力があまりにも有用
- これに適応し、設定し、使い方を学び、何が可能で何が不可能かを把握すれば、さらに効果的になる
- 約 20年間のプログラミング経験で最大の基本的コーディングワークフローの変化 であり、それがわずか数週間で起きた
- かなりの数（二桁パーセント）のエンジニアにも同様のことが起きていると予想するが、一般大衆の認識は一桁前半のパーセント程度と推定
IDE/エージェントスウォーム/エラーの可能性
- 「もうIDEは不要」 や 「エージェントスウォーム」 に関する誇張は、現時点では大げさだと思う
- モデルは依然としてミスをし、本当に重要なコードがあるなら 鷹の目で監視 する必要があり、横に大きなIDEを開いておく必要がある
- ミスの性質が変化している。もはや単なる 文法エラー ではなく、少し不注意でせっかちなジュニア開発者がやりそうな 微妙な概念的エラー になっている
- 最も一般的なエラータイプは、ユーザーの代わりに 誤った前提 を置き、確認せずそのまま進めること
- 追加の問題点:
- 混乱を管理できない
- 明確化を求めない
- 不一致を表に出さない
- トレードオフを提示しない
- 反論すべきときに反論しない
- いまだにやや おべっか的(sycophantic) な傾向がある
- プランモード では改善するが、軽量なインラインのプランモードが必要
- コードやAPIを 過度に複雑化 する傾向もあり、抽象化を肥大化させ、作業後に死んだコードを整理しない
- 1000行にわたって非効率で肥大し脆弱な構造を実装することがあり、「こうしてはいけないの？」と聞くと「もちろんです！」と言って即座に100行へ縮める
- 作業と無関係でも、気に入らない、または十分に理解していない コメントやコードを変更/削除 することがまだある
- CLAUDE.md に指示を書いて簡単に修正を試みても、こうした問題は起きる
- こうした問題があるにもかかわらず、それでもなお 純粋に巨大な改善 であり、手動コーディングに戻るのは非常に難しい
- 現在のワークフロー: 左側の ghostty ウィンドウ/タブ で少数のClaude Codeセッションを動かし、右側の IDE でコードを確認して手動編集
粘り強さ(Tenacity)
- エージェントが休まずに何かに食らいつくのを見るのは非常に興味深い
- 疲れず、くじけず、人間なら後日に回してとっくに諦めていた状況でも試し続ける
- 何かと長時間格闘した末に 30分後に最終的に成功 するのを見ていると、「AGIを感じる」瞬間 のようだ
- スタミナが作業の核心的ボトルネック だと気づかされ、LLMを手にするとそれが劇的に増える
速度向上
- LLMが支援することの「速度向上」をどう測るべきかは不明確
- やろうとしていたことが確かに はるかに速くなった感覚 はあるが、主な効果は やろうとしていた以上のことをはるかに多く行うようになる こと:
- 以前ならコードを書く価値がなかったあらゆるものをコード化できる
- 知識/スキルの問題で以前は手を付けられなかったコードにもアクセスできる
- 速度向上ではあるが、より大きな部分は 拡張(expansion) なのかもしれない
レバレッジ
- LLMは特定の目標を満たすまで ループを回すことに卓越 しており、これが「AGIを感じる」魔法の大半
- 何をするかを指示するのではなく、成功基準 を与えて見守るべき
- テストを先に書かせ、それを通過させるべき
- ブラウザMCP とループに入れるべき
- 正確性が非常に高そうな ナイーブなアルゴリズムをまず書かせ、正確性を保ったまま最適化を依頼
- 命令型から宣言型 へアプローチを変えると、エージェントはより長くループを回し、レバレッジを得る
楽しさ
- 予想していなかったのは、エージェントと一緒だとプログラミングが より楽しくなる こと
- 穴埋め式の退屈な作業が取り除かれ、創造的な部分 だけが残る
- 詰まり/停滞（楽しくない状態）が減り、より多くの勇気 を感じるようになる — いつでも一緒に前向きな前進を実現する方法があるからだ
- 反対の感情を持つ人たちもいる。LLMコーディングは コーディングそのものが好きなエンジニア と 作ることが好きなエンジニア に分けることになる
退化(Atrophy)
- 手動でコードを書く能力が徐々に 退化 し始めていることに気づく
- 生成（コードを書くこと） と 判別（コードを読むこと） は脳内で別の能力
- プログラミングに関わる細かな文法上の詳細のため、書くのに苦労してもコードレビューは問題なくできる
スロパカリプス(Slopacolypse)
- 2026年は GitHub、Substack、arXiv、X/Instagram、そして一般にあらゆるデジタルメディアにわたって スロパカリプス（低品質なAI生成コンテンツの氾濫）の年 になると予想
- 実際の真の改善に加え、さらに多くの AI誇大宣伝的な生産性劇場 が現れるだろう（そんなことがまだ可能なのか？）
問い
- 「10Xエンジニア」に何が起きているのか？ — 平均的なエンジニアと最高のエンジニアの生産性比率は？ この比率は 大きく増加 する可能性がある
- LLMで武装すると、ジェネラリストがスペシャリストをますます上回る ようになるのか？ LLMは穴埋め（ミクロ）よりも大戦略（マクロ）のほうがずっと苦手だ
- 未来のLLMコーディングはどんな感覚だろうか？ StarCraft をしているようなものか？ それとも Factorio をしたり、音楽を演奏したりする感覚だろうか？
- 社会のどれほどの部分が デジタル知識労働 によってボトルネック化しているのだろうか？
TLDR
- ClaudeとCodex などのLLMエージェント能力が、2025年12月ごろにある種の 一貫性の閾値 を超え、ソフトウェアエンジニアリングおよび関連分野に 相転移(phase shift) を引き起こした
- 知能の部分が突然、他のすべて — 統合（ツール、知識）、新しい組織ワークフローの必要性、プロセス、より一般的な普及 — よりかなり先行しているように感じる
- 2026年は、業界が新しい能力を消化する 高エネルギーの年 になるだろう
15件のコメント
この記事の内容をもとに、Claude Code の動作を改善する skills バージョンも公開されたようです。
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
ずっと抱いている疑問ですが、すでに手作業のコーディングが身についている人たちがLLMを監督するのはよいとしても、新しく学ぶ人たちはLLMが作ってくれるコードだけを見ていて、これが正しいのかどうか判断するのは難しい気がします。
昔アセンブラで書いていた人たちは、コンパイラが出てきたときに、こんなひどいアセンブリ出力を吐くコンパイラをどうして信用できるのか、みたいなことを考えたのでしょうか。
そのときもCで書きながら、アセンブリ出力が思いどおりになるよう誘導しつつコーディングしていたのでしょうし。
AI時代もさらに発展すれば、人の監督なしに自然言語で完成品がうまく出てくるようになるのか、気になります。
人がコードを書いていた時代でも、勉強していないと何が間違っているのかわからなかった気がしますね（笑）
アセンブリの専門家たちは今でもコンパイラをけなします。結局重要なのは、極限の最適化が必要な状況ではそうしたスペシャリストが必要だということで、これをAIに当てはめてみると、AIがどれだけ発展しても極限までうまく書ける人に勝つのは難しいかもしれません。とはいえ、一般的なレベルではすでにどんな人間もAIには勝てませんが。もう一度アルファ碁モーメントのように、アルファコード対決があったら面白そうです。
生成されたコードを分析し、理解しようとする努力があるなら、問題ないように思います。
コンパイラは少し異なる概念で、ルールベースでアセンブリを生成するため決定論的な領域です。そのため、いったんレビューすれば次に同じ問題が再発することはありませんが、LLMは確率的な領域なので、問題が再発する余地があります。
この確率的な正確性がさらに発展すれば100%近くになるのかもしれませんが、自然言語による要求自体が不正確であれば、結局結果も不正確になります。そう考えると、
良い完成品は結局のところ人間にかかっているのではないかと思います。私も学生の頃からLLMに触れてきたジュニアの人たちが心配なんですよね。ジュニア採用の候補者プールが少し悪くなった気もするのですが、また証明するのは難しくて……
個人的には、CSの知識さえあればそれほど大きな違いはないんじゃないかと思います。
あるいは、今の自分の使い方が、手がものすごく速くてコードを全部打ってくれる相手とペアプログラミングしているような感覚だから、そう感じるのかもしれません...
結局、深く開発していくと抽象化レイヤーの内側を知る必要が出てくるものですが、
自然言語プロンプトと生成されたコードの間の隔たりは大きすぎて、プロンプトからLLMの抽象化レイヤーの内側に入り込むのは難しそうです。
今の私たちは、頭の中にあった仕様の概念をプロンプトとしてLLMに伝え、その後に書かれたコードを読み直して検証するやり方なので、
他人が書いたコードをレビューする形に近く、抽象化の内側に入っていく感覚はあまりありません。
自分は20%をあまりにも軽視していたんだなと思います。
最近、AIでは解決できないバグに遭遇して……万能ではないのに、万能であるかのように考えていたと気づかされました。
あっ…（笑）
とても共感しています。最近のプロジェクトで10万行ほどコミットしており（実際のコード量はそれ以上です）、平均して2〜3個のエージェントを使っています。私はコードの95%ほどをエージェントに書いてもらっている感じです。
しかし、依然としてテストやデッドコードについては管理が必要であり、テストケースやテスト成功条件の詳細も必要です。何をどこまで行うのかの管理が重要です。そのためには、プランだけでなく、ハーネスを作るアーキテクチャやRulesなどの設定を継続的に更新していく必要があります。
Hacker Newsのコメント
エージェントが疲れずにひたすら試し続ける様子を見るのは興味深い
GPUやNPUが熱を持って回り、私たちは普段なら共有しないようなデータまで渡している
今は便利な取引に見えるが、長期的には依存性と社会的問題が大きくなる危険がある
結局はこの巨大なゲートキーパーに従属する構造になりかねない
AIと一緒に働いていて、脳の衰えより大きな問題は自己満足と無気力に変わっていくことのように思える
最初は速い結果にドーパミンが出るが、繰り返すほどAIがプロジェクトの方向を勝手に引っ張っていく感じになる
結局、自分が望んでいた創造的な実験は消え、AIの潜在空間の重力に吸い込まれていく
これはまるで** doomscrolling **のように、次の出力を見たくなり続ける中毒的なループだ
RustとBevyでマルチプレイヤーゲームを作っているが、コードは動いていても自分が理解していないコードになってしまう
以前なら道具を完全に理解してここまで来ていたはずなのに、今は半分動くゲームを作ったもののECSが何かも分からない
保守や緊急対応を考えると、これは本当に危険な状態だ
私たちは今やモデルを学ぶことに集中し、自分で考える方法を忘れつつある
LLMの使い方は絶えず変わるため、結局は終わりのないランニングマシンの上に立っているようなものだ
長いブランクがあっても感覚は残っていて、また乗ればすぐ戻る
LLMが分からないとただ諦めて、ドキュメントを読もうとしない開発者が増えている
実際にドキュメントを読んでスクリーンショットまで見せても、「これで合ってるのか？」と疑う
短い快感のために延々とプロンプトを投げ、「今度は何が出るだろう」と待つようになる
LLMコーディングは、『コーディングが好きな人』と『ものを作るのが好きな人』を分けるきっかけになっている
私は結果を作るのが好きなビルダー型なので、この変化が楽しい
一方でコーディングそのものを楽しむ人たちは、この流れに居心地の悪さを感じる
プログラミングの魅力は問題を構造化し、自分で実行する過程にあった
今は「自分がコーディングしているのではなく、指示している感じ」で、興味が薄れている
過去にもコンパイル vs インタープリト, 型付き vs 型なし, 高速デプロイ vs 保守性といった対立があった
結局、成功したソフトウェアは混沌とした初期段階から安定した拡張段階へ移る過程を経る
AIがこの過程を助けるのか、むしろ複雑にするのかはまだ確信が持てない
単に成果物ではなく、システム構造を組み立てる過程に面白さを感じる
人間のチームメンバーには責任と信頼があるが、LLMにはそれがない
AIが10倍の生産性向上をもたらしうるという考えは興味深い
DevOpsは開発と運用の協業のやり方を変え、高性能なチームを生み出し、これがチーム版の10Xに近い効果につながった
AIコーディングをうまく使うには、DevOpsのように継続的改善、ワークフロー変更、自動化/検証によって信頼を積み上げる過程が必要だ
DevOpsも新しい概念の学習やチーム文化の変化が必要で広く浸透しにくかったように、AIコーディングも学習/文化の変化がなければ10Xの潜在力があっても適応は遅れるかもしれない
定着のためには教育とエンジニアリング文化の変化が必要だ
LLMは大規模コードベースでは役に立たないと感じた
特に複雑で相互作用の多いコードではほとんど助けにならない
既存の大規模で複雑なコードベースに入れるのは、綿密なレビューが付く限定的な変更でない限り危険だ
単純な構造でファイル一覧を渡し、エージェントに実装を任せるやり方は印象的だが、複雑さが増すほど、成果を出すにはプロンプトもますます細かな指示へと下りていかなければならない
以前のモデルと違って、今では複雑なモノレポでも実質的な助けになる
新しいチームメンバーが同じ情報で働いた場合より優れているかを比較してみるべきだ
商用の社内コードベースは顧客要件に合わせた反復開発で汚くなり、初期の前提と要求が徐々にずれて技術的負債が生まれる
LLMを使ってヘルパー分離、モジュール化、リネームのようなリファクタリングで現在の要件に合うよう整理すれば、その後のエージェントの動作もより予測しやすくなる
要件/受け入れ基準/ユーザーストーリーをMarkdownで整理し、計画を細かく書かせてから実装に進む段階的な流れが必要だ
AIの粘り強さと体力が人間の限界を超える地点は印象的だ
研究でも**知能より粘り強さ（grit）**の方が成功とより密接だと言われる
LLMは予算が許す限り無限の粘り強さを持つ
ここ数か月、AIの性能がむしろ後退したように感じる
ルールを忘れ、過剰な計画と過設計のコードを生成する
ただしフロントエンド（HTML + Tailwind）では依然として有用だ
IDEやエージェントスウォームへの過剰な期待は時期尚早だと感じる
iPhoneアプリを作りながら、Claudeの英語プロンプトベースのコード生成力に感嘆した
> LLMコーディングは、コーディングそのものが好きなエンジニアと、ものを作るのが好きなエンジニアに分かれることになる。
私も周りで聞く話を総合すると、結局こう分かれる気がします。