簡単に検証できないなら、LLMは得意じゃないよ。

「二つの異なる目的の最適化はできない」というのが根本にあると思う。機能要件だけなら、実質的にプログラム合成の一種をやってることになるし、RL（強化学習）はそれをかなりうまく最適化できる。機能要件と非機能要件が混在していると、モデルに不完全な仕様を与えていることになって、ユーザーの意図を推測して空白を埋めなきゃいけなくなるんだ。だから、欲しいコードのスタイルの例をプロンプトに追加するのがめちゃくちゃ効果的なんだよね（このアドバイスはantirezに感謝！）。

彼らが使った最強のフロンティアモデル、GPT 5.2でも、エージェントプログラミングにはほとんど使えないと思う。こういうモデルの弱点を分析するのにはあまり興味がないんだけど、私の経験上、モデルが強くなるにつれて多くの弱点は完全に消えるからね。特に、何をしてほしいかを伝えれば。さらに、受け入れ基準が増えると失敗率が上がるのは驚くべきことじゃないよね。

うーん、これが本当だっていう経験談はあるよ。Opusとインタラクティブにプランを考えていると、何度か互換性のない解決策が出てきたことがあって、追加のコンテキストや要件を加えると、元のアーキテクチャに「アンカー」して適応するのが難しくなる傾向があるんだ。時々、元のプランに変更をこっそり入れようとすることもあるし。

明示的なアーキテクチャルールに従わされるとパフォーマンスが落ちる どんなに優れたモデルでも、生成されたコードのスタイルに関するルール（このくらいインデントする、こういうパターンで名前をつける、など）に従うのが難しいんだよね。どんなにAIファーストのコーダーでも、そういうことが珍しくないって認めるはず。でも、それでも彼らはこれらのモデルが毎回詳細な仕様に従うと思い込んでいるんだ。

プロンプトが「アラインメント」や「ガードレール」を強制しようとするときに見られる同じ問題かもしれない。パフォーマンスが落ちるんだ。どうやら、大きな解決策の領域が到達不可能になってしまったみたい。例えば、約1年前の画像生成モデルに「ガードレール」を適用すると、みんな同じように見えるようになる。ストーリー生成モデルも、標準的な名前だけを使うようになる。それが去年の話。フロンティアモデルでも同じことが起こってるのかな？

AIアシストで書かれた本でも似たようなことに気づいたよ。最初はまあまあだけど、章が進むにつれて各章の始まりが前の章の終わりを繰り返すようになって、明らかにLLMの特徴が増えてくる。進むにつれて、前の内容の繰り返しに頼ることが多くなるんだ。著者が後の章に対してあまり注意を払わなくなって、編集にも力を入れなくなる可能性もある。Amazonに大量にあるけど、LLMはまだちゃんとした文章を書くレベルには達してないね。

Pythonがデフォルトで動的型付けだと思ってる人がいるのが信じられない。強い静的型付けは何年も前からPythonで選べるオプションなのに、普通はそれがデフォルトであるべきだよね。