モデルは毎日改善されてるよ。人々はトレーニングやハードウェアの効率を向上させるための数千の異なる最適化を見つけてる。2025年6月の今が改善が止まる時期だなんて信じられない。限界に近づいているかもしれないけど、それは急に進歩が止まるのではなく、シグモイド曲線になるはず。

この3ヶ月でモデルはかなり改善された。でも、もう3年も「もしかして、もう限界に達してるかも？」って言ってる人がいるよね。

99%のケースで、明日は昨日と同じようになるって意味で「必然的」だよ。LLMは何年も継続的に改善されてきた。驚くべきことは、さらに改善されないことだよ。研究を少しでも追っていれば、しばらくは改善されるって分かる。商業モデルにまだ全てのブレークスルーが反映されてないからね。「テクノユートピア的決定論」じゃなくて、明らかに見える軌道なんだ。一方で、もし改善されなかったら、全体の観察には大きな変化はないよ。それはちょっとした細かいことを言ってるだけ。厳密なプロンプトの遵守とプロンプトのアーカイブがプログラミングのやり方を変える可能性があるっていう観察は本当だし、過去に何度も見た現象でもある。もうコンパイラのアセンブリ出力を保存してる人はいないしね。文章には確かに有効な批判があって、過度に楽観的だと思う。ほとんどの非自明なプロンプトはまだ不十分に指定されていて、複数の実装が可能で、必ずしも正しいわけじゃないから。それはもっと有用な批判で、LLMの改善とは全く関係ないんだ。

コンピュータの性能が上がれば、処理が速くなって、コンテキストも増えるよね。

皮肉なことに、もしAIが今後5〜10年で大半のコードを書くって理論を信じるなら、その後何をトレーニングするの？自分自身？「必然的に良くなる」って理論的な軌道は、人間が質の高いトレーニングデータを生産している場合にだけ当てはまる気がする。コードLLMが生成するコードの質は、言語やプロジェクトの成熟度や普及度に非常に比例してるよ。

プロンプトを実際のソースコードとして扱ったらどうなる？ そんなことはしないよ。プログラミング言語とは違って、自然言語は曖昧だから、ソフトウェアを完全に指定するには不十分なんだ。

ほとんどの人がプログラミングするときに「ソフトウェアエンジニアリング」をしてるわけじゃないと思う。WordPressやDreamweaverみたいなプログラミングの世界もあって、そこでのミスの影響はあまり重要じゃないしね。LLMは決定論的な出力に設定することもできるよ。

言ってること自体はあまり良くないアイデアだけど、ちょっと工夫すれば期待できそうだね。LLMでコードを生成して、そのコードに対してテストを書く。テストはLLMを使っても自分でやってもいい。もちろん、実際にプログラムを動かすためには実際のコードをコミットする必要があるけど、生成したプロンプトのチェーンもどこかに保存しておく。で、（記事に書いてある通り）もっと良いモデルが出てきたら、そのチェーンを再実行する。たぶん「このプロジェクトを効率重視で作って」や「Rustでこのプロジェクトを作って」みたいなプロンプトを使う感じかな。新しいコードベースに対してテストを実行して、スイートが通れば、かなり改善されたコードベースで進められる。これが、以前生成したコードをLLMに渡して「可読性を改善して」って言うのと違うのは、新しい（より良い）LLMが前のLLMの「悪い」決定の文脈に縛られないから。もちろん、実際にはそんなに簡単じゃないけど、テストはすべてをキャッチするわけじゃないし（ファズテストや完全カバレッジでほとんどの問題は捕まえられるけど）、プログラマーはそれをすべてキャッチするかのように扱うことが多いから、やる価値はあるかもしれないね。

私の仕事は、ほぼ完全に生成されたコードのプロジェクトに10年以上関わってきた。AIが生成したわけじゃなくて、実際のプロジェクトの作業はコードジェネレーターを作ることなんだ。私たちがすぐに学んだことの一つは、生成されたソースコードを実際のソースコードと同じリポジトリに置くのは持続可能じゃないってこと。変更をレビューする性質が全然違うからね。もう一つすぐに分かったのは、生成されたコードを修正しようとするのは持続可能じゃないし、100%生成されたコードベースを目指すのも無理だってこと。その結果、プロジェクトを大幅に再設計して、生成されたコードの任意の場所に手作りのコードを注入する必要があった。さらに、コードジェネレーターに変更があるときは、機能フラグを設ける必要があるってことも学んだ。誰かが古い動作に依存していたからね。

もっとひどい。モデルは決定論的じゃないんだ！ランダム性をコントロールするために温度値を使って、局所的な最小値から逃げるためにね！再生成されたコードは、動作が異なるかもしれないし、異なるバグが出るかもしれない（最悪の場合）、全く動かないかもしれない（最良の場合）。

明らかな再現性の欠如とは別に、もう一つの問題はナビゲート可能な構造がないことだ。もうコマンド+クリックや「使用例を表示」や「定義を表示」ができなくなった。

アイデアはいいけど、ドキュメントとテストの両方をコミットすべきだね。それがあれば、自由にコードを再生成できるから。

プロンプトと一緒に包括的なテストシステムをコミットすべきだと思う。プロンプトは、ある意味で高級プログラミング言語がアセンブリに対して持っていた役割みたいなものだよね。再現性には重要な違いがあるけど、長期的にはそれほど問題にならないと思う理由を考えてみることもできる。もちろん間違っているかもしれないけど。俺は https://pollinations.ai を運営していて、月間400万人以上のアクティブユーザーをかなり安定してサポートしてる。ほとんどAIでコーディングされてるんだ。約1年前から大きな人間のコミットはないよ。コードベースをチェックしてみて。ごちゃごちゃしてるけど、LLM以前の俺のコードベースよりはマシだと思う。プロンプトとコードのテストが中期的な解決策になると思う。人間は異なるアーキテクチャのアイデアをテストするのにもっと時間を使って、レビューやテストに大きな変更が伴うような大きな変更にも関与するようになるだろうね。

それに、コミットはシステムの現在の状態に依存してるからね。「{dependency}を段階的に廃止することで脆弱性を取り除く」って、次の世代のコードがそのライブラリに全く依存しないかもしれないのに、何の意味があるの？「{method}のパフォーマンスを改善する」って、次の世代が全く違う実装を使ってたらどうなるの？まったく意味がないよね。ただのvibecodersのスクリプトがコードベースに外挿されてるだけ。

プロンプトがコードを生成するかどうか、事前にわからないよね。

なんでそれが面白いのか分からない。これは雰囲気でコーディングしてる話じゃないし、Kenton Vardaのコーディングセッションだよ。後でKenton Vがこの記事を書いてないって更新されたけどね。

この議論は、これらの技術がシニアエンジニアの生産性を劇的に向上させるから、ジュニアエンジニアの需要が激減するってこと。ジュニアエンジニアのパイプラインがなくなると、ジュニアからシニアへの道筋が大きく萎縮する。要するに、既存のシニアエンジニアがAIを使って従来のシニア・ジュニアチームを上回ることができるようになって、ジュニアエンジニアが雇用を確保できなくなるってことだ。この文章にはその議論を覆すものはないと思うよ。

エンジニアとツールの境界がぼやけてしまう。君が言いたかったのは「エンジニアとそのツールが一体化する」ってことだと思うけど、俺はそれを面白い侮辱として読んじゃった: 「あいつは自分をエンジニアだと思いたがってるけど、完全にツールだよね。」

プロンプトエンジニアたちは、これをソフトウェアエンジニアの陳腐化が迫っている証拠として指摘するかもしれない。注目を集めようとするジャーナリストやブロガーがそうするのかもしれないけど、プロンプトエンジニアはプロンプトの限界をよく理解しているから、そんなことはしないと思う。

そうだね、AIに最初に与えられたプロンプトは経験豊富な開発者が作ったもので、APIがどうあるべきか、どう使われるかを正確に指示するコードの塊だった。プロセスの最初のステップからして、経験豊富な開発者が関わる必要があったんだ。

責めるのは好きじゃないけど、この記事全体は悪くないのに、ここはちょっと臭いなと思った: 「この透明性は、gitの履歴を変更の記録から意図の記録に変えて、人間の推論と機械の実装をつなぐ新しい形のドキュメンテーションを作り出します。」

人間のメモを作って、Claudeに要約と編集を頼んで、最後に手動で編集したよ。いくつかの文（下の臭い文みたいなの）はClaudeからのもので、自分の考えと合ってたらそのまま使ったけど、大半はスタイルや文体のために変更した。まだ試行錯誤中なんだ。スタイルには全然合わないし、手動編集しても「AIっぽい匂い」がするのはその通り。でも、時間は節約できる。プロンプトは基本的に「昔のブログ投稿とAI生成のコミットを読んだメモを元に、得た洞察をまとめた一貫した記事にしてほしい」って感じ。

そうそう、誰がコードを書いたのか、誰がそれを報告したのか、頭が混乱しちゃった。ほんとごめんね。LLMの医者に行って、脳を修理してもらうよ。

このコードベースに半分集中して5日くらい費やしたよ（でも、いつも誰かに邪魔されてるけどね）。約5000行あるよ（コメントやテスト、ドキュメントも含めてね、ちゃんと数えるべきだよ）。どこで1時間あたり7行なんて出てくるの？

つまり、君とLLMが一緒に1時間あたり7行のつまらないコードを書いたってことだね。彼らの返答はこうだよ。>「AIでライブラリを作るのに数日かかった。」>「手書きだと数週間、場合によっては数ヶ月かかると思う。」>「とはいえ、これはかなり理想的なユースケースだね：明確なAPI仕様を持つよく知られたプラットフォームでの、よく知られた標準の実装。」コードの行数を時間あたりで測るのはひどい指標だよ。それに、すでに書かれたコードを批評する方がずっと簡単だしね！