Codexのようなものが成功したのは、その成果を「検証」するものが存在したからだよ。既存の非LLMソフトウェア、つまりコンパイラやリンター、コードアナライザーのコレクションね。もう一つの要因は、プログラミング言語の文法が非常に限られていて定義されていること。そういう制約の下では、外部ツールを使って自分を検証するテキストジェネレーターを作るのがずっと簡単だったんだ。生成されたストリームが意味を持つまでループで検証することができるからね。そして、もう一つ「成功した」業界は、出力を検証する必要がないところ。エラーが許容されるか、無関係な場合だね。事実データがあまり含まれていないテキスト、例えばフィクションやビジネス用語、スパムとか。あるいは、特定のピクセルの色がどれでもいいような画像。大まかな一致で十分なんだ。でも、その二つのオプション以外では、あまり他の業界で不正確な言葉やメディアジェネレーターをスケールで使えるところはないよ。内容のないビジネスメールの循環的な書き方や解析？それならいいけど、他にはあまりないね。

テキストを扱う能力の他にも、コーディングがLLMに非常に適している理由はいくつかあると思う。LLMがコンパイラのようなツールにアクセスできるようになったら、何がうまくいくか、何がダメかについての迅速で正確なフィードバックをもとにコードを反復することができるようになったんだ。失敗したテストやコンパイラエラーでもね。これを、パワーポイントのデッキを作成するようなタスクと比べてみて。LLMへのフィードバック（もしあれば）は遅くて、ずっと正確じゃないし、「良い」とされるものはせいぜい主観的だよ。もう一つの例は、LLMが既存のコードを読み解くのが非常に得意になったこと。これは印象的で非常に役立つ能力だけど、コードは私たち人間が意図を表現する最も正確な方法の一つなんだ。何百万回もほぼ決定論的に実行できる指示としてね（バグは別として）。私たちのコードは、非常に小さな語彙と人間の言語よりもずっと簡単な文法を持つ、徹底的に文書化された言語で書かれている。これを、ドイツ語でのZoomコール中にメモを取って、内輪ネタや中断、欠けたコンテキストを理解しようとするのと比べてみて。だけど、最も重要なのは、開発者はLLMにとって最もフレンドリーな人間でなければならないってこと。タスクを小さく分解して、「メモリ」にフィットするようにコンテキストを注意深く管理・キュレーションしたり、より専門的なタスクを持つ小さなエージェントを調整したり、彼らが互いに、そして私たちのツールと話すための新しいプロトコルを作ったり…。プログラミングのように聞こえるかもしれないけど、実際にそうなんだ。

よく考えられた記事ではなく、進展を軽視している。 > 業界は2025年が重要な年になると楽観的である理由があった。過去数年、AIエージェントのClaude CodeやOpenAIのCodexは、多段階のプログラミング問題に対して驚くほど優れた能力を持つようになった。Claude Codeが2025年に登場したことを忘れがちだ。2025年にリリースされたモデルやエージェントは、本当にその力と能力を証明した。予測は間違っていなかった。私は文字通り、コードエージェントを「火をつけて忘れる」ように使っている。Claude Codeは、個人的な問題やプロジェクトを解決するための非常に強力なエージェントインターフェースだ。多くの問題に対するUXとして使っている。これは本質的に、自分でその場で修正できるソフトウェアだ。ほとんどの人は、この劇的なパラダイムシフトをまだ理解していない。まだいいアナロジーは思いついていないけど、Claude Codeを主要なインターフェースとして使う感覚を最もよく表す言葉は「インテリジェンスエンジン」だと思う。例を挙げると、Claude Codeを中心にいくつかのシステムを作ったけど、最新のものは株式ポートフォリオ管理のためのものだ（これは楽しい問題領域で、少し知識があるから）。基本的には、Claude Codeを使ってそのドメインのためのツールを自分で作る感じだ。これがどのように進んだかを見せるね。Claudeと私はプロセスと役割の一般的な流れをブレインストーミングする。その後、各役割が必要とするデータを考え、合理的な価格でそのデータを持っているプロバイダーを調査する。APIキーを購入して、Claudeがツールを接続する（この場合、約140のAPIエンドポイントのためのPythonスクリプトとエージェントのドキュメント）、その後エージェントを構築し、プロセスを呼び出す「スキル」の初期バージョンを作成する。これはこんな感じだ：マクロ経済学者/ストラテジスト -> ファクトチェッカー -> 証券ソーサー -> アナリスト（4種類くらい） -> ファクトチェッカー/統合者 -> ポートフォリオマネージャー。最初の段階では100%完璧ではなく、LLMアプリケーションを構築する際の専門知識に頼らなければならないけど、今はこの研究プロセス全体をオーケストレーションできるClaude Codeのインスタンスがあるし、その場でアドホックな変更もできる。今はこのシステムを約5回の重要なイテレーションを経て進化させたけど、「アプリ内」でできる。もしその一部がうまくいかないなら、メインエージェントにその場で再配線させるだけだ。これは問題に取り組む全く新しい方法だ。

2023年のAiderを忘れないでね。

ちょっと混乱してる。Claudeは数年前のものだよね。

この記事のどれだけが真実で、どれだけがAIによって幻覚されたのか気になる。

同意だね。具体的な答えを見たことがないし、明確でシンプルな言葉で説明できる結果もない。

ここで話しているのは「エージェンティック」なコーディングについてだよ：これは銀の弾丸でもなく、「もうコーディングを知らなくても大丈夫」なツールでもない。今年はClaude Codeを使ってたくさんの作業をした。週に「チケット1枚」くらいのReact開発者から、チームを管理しながら新しいフロントエンド機能セットを出荷する人間に成長した。LLMを使ってこれらの機能を迅速にプロトタイプし、歴史的に一人の開発者では手に負えなかったシンプルな問題の障壁を取り除き、ビジネスの本質的な部分と競合する「あったらいいな」のバックログをクリアにした。このプロトタイピングと「十分に良い」開発は、私の小さな組織にとって非常に影響力があった。難しい問題は分散システム間の複雑な相互作用、サービス間のモニタリング、そして多くの低レベルのマシントラフィックから来ている。LLMのおかげで簡単な問題を解決でき、最も生産的な時間を使って人々と協力して難しい問題を簡単な問題に分解し、後で解決するか、チームの誰かに手伝ってもらうことができる。LLMを使って他の人のコードベースに入り込み、古い技術的負債をリファクタリングし、何年も前のゴミやコピー＆ペーストで埋まったテストスイートを強化することもできた。テストだけでも、LLMはコードにエッジケースを投げかけて、あなたが仮定したこととエントロピー機械が投げかけるものを見比べるのに非常に価値がある。LLMは単独では10倍の生産性向上をもたらすものではない。彼らは100%の確率で、いくつかの問題を合理的で扱いやすい方法で解決できず、しばしば時間を無駄にする愚かなことをする。けれども、彼らは確実に参入障壁を下げ、「純粋な単一技術」（つまりバックエンドのみ、フロントエンドのみ、「Kubernetesを知らない」などの限られた範囲の）ソフトウェアエンジニアを退けることができる。ソフトウェアという分野は「問題を解決する機能的で安全なシステムを構築する」から「200kのバイクシェディングJIRAチケットを作成し、それを管理するために製品チームの軍隊が必要になる」へと大きくシフトしているから、LLMは10年前のように全体のチームのように動くために必要なツールを持つ人々にとって価値がある。