ここ数週間、Claudeを使ってかなり本格的にコーディングを行ってきた中から、いくつかのランダムなメモを共有します。

コーディングのワークフロー LLMのコーディング能力が最近向上したことに伴い、多くの人々と同様に、私も11月時点での「80%手動+自動補完、20%エージェント」というワークフローから、12月には「80%エージェントによるコーディング、20%編集+微調整」へと急速に移行しました。つまり、私は今、文字通り英語でプログラミングをしており、少し気恥ずかしさを感じながらも、どのようなコードを書くべきかを「言葉」でLLMに指示しています。プライドは少し傷つきますが、ソフトウェアに対して「コードアクション」という大きな単位で操作できる利便性は、総合的に見てあまりにも有益です。特に、この方法に適応し、設定を整え、使い方を学び、エージェントができることとできないことを頭の中で整理できるようになればなおさらです。これは、約20年のプログラミング経験の中で、私の基本的なコーディングワークフローにおける間違いなく最大の変化であり、それがわずか数週間の間に起こりました。他のエンジニアの2桁パーセント（10%以上）にも同様のことが起きつつあると予想していますが、一般層におけるこの変化への認識はまだ1桁パーセント（数%）程度にとどまっているように感じられます。

IDE／エージェントスウォーム／ミスの可能性 「もうIDEは不要である」という過剰な期待も、「エージェントスウォーム（多数のエージェントの連携）」という過剰な期待も、現時点では行き過ぎだと私は考えています。モデルは間違いなく依然としてミスを犯しますし、本当に大切にしているコードがあるなら、私はその挙動を、大きくて見やすいIDEを横に並べて監視します。ミスの性質は大きく変わりました。もはや単純な構文エラーではなく、少し不注意でせっかちなジュニア開発者が犯すような、微妙な概念的エラーです。最も一般的なミスのカテゴリーは、モデルがこちらに無断で間違った仮定を立て、それを検証することなくそのまま進めてしまうことです。また、モデルは自身の混乱を管理せず、明確化のための質問をせず、不整合を表面化させず、トレードオフを提示せず、本来すべきであるにもかかわらず反論をせず、と依然として少しへつらいすぎます。「計画モード（plan mode）」にすれば状況は改善しますが、軽量なインライン計画モードのようなものが必要です。さらに、モデルはコードやAPIを過度に複雑にしたがり、抽象化を肥大化させ、作業後にデッドコードをクリーンアップしない、といった傾向もあります。モデルは、非効率的で肥大化し、壊れやすい構造のコードを1,000行にわたって実装することがありますが、こちらが「うーん、代わりにこうすればもっとシンプルにできるんじゃない？」と指摘すると、モデルは「もちろんです！」と言って即座に100行に削ってくれます。また、当面のタスクとは関係がない（直交している）場合でも、副作用として、気に入らない、あるいは十分に理解していないコメントやコードを変更したり削除したりすることがあります。これらすべての問題は、CLAUDE.md の指示を通じて修正しようといくつかの単純な試みを行ったにもかかわらず発生しています。しかし、これらの課題を差し引いても、全体としては計り知れないほど大きな進歩であり、手動コーディングに戻ることは到底考えられません。要するに、誰もが独自の開発フローを構築しつつあり、私の現在のフローは、Ghosttyのウィンドウやタブで左側にいくつかのClaude Codeセッションを開き、右側にコードの閲覧と手動編集用のIDEを配置するというものです。

粘り強さ エージェントが何かに執拗に取り組む様子を見るのは、非常に興味深いものです。彼らは決して疲れず、決して意気消沈せず、人間ならとっくに諦めて日を改めるような場面でも、延々と挑戦し続けます。何かと長い間格闘した末に、30分後に見事勝利を収めるのを見るのは、「AGIを感じる」瞬間です。スタミナこそが仕事の核心的なボトルネックであり、LLMを手にすることでそれが劇的に解消されたのだと実感させられます。

生産性の向上 LLMの支援による「生産性の向上」をどのように測定すべきかは明確ではありません。確かに、自分がやろうとしていたことに対する作業スピードは劇的に上がったと感じますが、主な効果は、やろうとしていたことよりも「はるかに多くのこと」を行うようになる点にあります。なぜなら、1）以前ならコーディングする価値がないと判断していたあらゆる種類のものを実装できるようになり、2）知識やスキルの問題で以前は手を出せなかったコードにも取り組めるようになるからです。したがって、これは単なるスピードアップというよりは、むしろ「能力の拡張」と呼ぶ方がはるかに適切かもしれません。

レバレッジ（てこ） LLMは、特定の目標を達成するまでループ処理を繰り返すことに非常に長けており、ここに「AGIを感じる」魔法の大部分が存在します。何をすべきかを指示するのではなく、成功基準を与えて、そのプロセスを見守りましょう。まずテストを書かせ、それをパスさせるようにします。ブラウザMCPを使ってエージェントをループの中に組み込みます。まず、ほぼ確実に正しいと思われる愚直な（ナイーブな）アルゴリズムを書かせ、その後、正しさを保ったまま最適化するように指示します。命令型から宣言型へとアプローチを変更することで、エージェントをより長くループさせ、レバレッジを高めることができます。

楽しさ エージェントを使うことで、コーディングが「より」楽しくなるとは予想していませんでした。なぜなら、隙間を埋めるような退屈な単純作業の多くが排除され、残るのはクリエイティブな部分だけになるからです。また、開発が滞ったり行き詰まったりすること（これは楽しくありません）が減り、エージェントと手を携えて前進する手段がほぼ常に存在するため、より大きな勇気を持って取り組むことができます。一方で、他の人々からは逆の意見も聞いています。LLMによるコーディングは、「プログラミングそのものが好きだったエンジニア」と「ものを作ることが好きだったエンジニア」で評価が分かれることになるでしょう。

スキルの退化 手動でコードを書く能力が、自分の中で少しずつ衰え始めていることにすでに気づいています。「生成（コードを書くこと）」と「識別（コードを読むこと）」は、脳における異なる能力です。プログラミングに伴う細かな（主に構文上の）詳細の多くは、自分で書くのには苦労したとしても、コードをレビューするだけであれば問題なく行えます。

スロップ（ごみコンテンツ）の黙示録 私は、2026年がGitHub、Substack、arXiv、X/Instagram、そして一般的なすべてのデジタルメディアにおいて、AI生成の「スロップ（ごみコンテンツ）」が氾濫する年になると覚悟しています。また、真の具体的な改善の裏で、AIのバズワードを利用した生産性の「劇場的演出（やってる感）」がさらに増えることも予想されます（これ以上増える余地があるのかは疑問ですが）。

疑問 私の頭に浮かんでいるいくつかの疑問：

• 「10倍エンジニア」（平均的なエンジニアとトップエンジニアの生産性の比率）はどうなるか？ この差は「劇的に」広がる可能性があります。
• LLMを武器にすることで、ゼネラリストがスペシャリストを凌駕する場面が増えるか？ LLMは、大局的な戦略（マクロ）よりも、隙間を埋める作業（ミクロ）がはるかに得意です。
• 将来のLLMコーディングはどのような感覚になるか？ StarCraftをプレイするようなものか？ Factorioをプレイするようなものか？ それとも音楽を演奏するようなものか？
• 社会のどれほどの部分が、デジタルな知識労働によってボトルネックとなっているか？

要約（TLDR） 私たちはどこに行き着くのでしょうか？ LLMエージェントの能力（特にClaudeとCodex）は、2025年12月頃に何らかの一貫性の閾値を超え、ソフトウェアエンジニアリングおよびその関連分野にパラダイムシフトを引き起こしました。「知能」の部分は、ツールや知識との統合、新たな組織的ワークフローやプロセスの必要性、そしてより一般的な普及といった、それ以外のすべての要素よりも突然かなり先行しているように感じられます。業界がこの新しい能力を消化・吸収するにつれて、2026年は非常にエネルギーに満ちた1年になるでしょう。