一番面白いのは、LLMが安くて小さくなって、アプリが内蔵できるようになった時だね。ユーザーの入力や使用パターンに基づいて、コードを調整できるようになる。

すべての会社のすべての従業員が新しい働き方を採用することを期待するのは無理だと思う。それが競争の仕組みじゃないから。もしエージェントAIがいいアイデアで、生産性が上がるなら、誰かのスタートアップが他を圧倒するのを期待すべきだよね。もしそれが10倍の生産性をもたらすなら、今すぐにでも見られるはずだと思う。多くのスタートアップは、競合に勝つためにエージェントAIを使って1年経ってるから。

中長期的にはこの増加するコードの流入に対応できるシステムをどう作るか考えなきゃ。 なんで？「コードをもっと早く書く」必要があるの？システムが飽和するまで？できるからって、やるべきとは限らないよね。

リンク先の記事も一緒に読む価値があるよ。実際のプロダクションでエージェントを運用していると（デモじゃなくて、数週間無人で実行されるワークフロー）、難しいのはコードの量やトークンコストじゃない。状態の継続性なんだ。エージェントは自分の履歴を幻覚する。長いループで50〜60ターンを超えると、大きなコンテキストウィンドウがあっても、早い情報を軽視し始めて、すでに解決した問題を再解決しようとする。ファイルベースのメモリで明示的に取得する方が、コンテキスト内に詰め込むよりも信頼性が高いんだ。見た目はあまり良くないけど、長い実行に対しては予測可能だよ。もう一つの難しい部分は、失敗の隔離。エージェントのワークフローが12のステップの7でエラーになったら、6から再開したいよね。ゼロからやり直すのは避けたい。ほとんどのフレームワークはこれを後回しにしてる。アイデンプトステップでのチェックポイントと再開は、運用的にずっと安定してる。習慣だけじゃなくて、インフラのメンタルモデルも変えなきゃいけないね。プログラムを書くんじゃなくて、再生成されるコードの周りに信頼性の足場を構築してるんだ。

完全に同意だね。「組織的習慣」っていうのは、まさにそこを言いたかったんだ。ソフトウェアプロジェクトの計画、整理、提供の仕方が根本的に変わると思う。でも、どれくらい変わるかはまだ自分でも分からないから、書く準備はできてない！

このスピードで出荷を続けたいのか？ それって本当に望んでることなのか？ 爆発的な下痢のように機能を吐き出すのは、俺は望んでないな。

職場でこの話をしてたんだけど、もしAIコーディングの約束が実現して、納品スピードが上がったら、ビジネスの他のすべての側面のスループットを大幅に増やす必要があるよね。

ここに来てくれて嬉しいよ！（ちょうどブルースカイでサンドボックスについて連絡したところなんだ - ガンドリン）。君の仕事をフォローしてるし、同意するよ。素晴らしいオープンソースの仕事を基にした、しっかりとしたオーディエンスを持つ君や他の人たちが、開発者だけでなくビルダーになる非開発者たちのメンタルシフトのために支援してくれることを願ってる。彼らのミニマリスティックなビルディング体験に注目していて、私や他の伝統的な開発者がボトルネックにならず、エンドツーエンドで力を与えられるようにしたいんだ。AI評価がその道の大きな部分だと思っていて、異なる分野がついに理解のギャップを埋めたプロダクトデザインのストーリーを持てるようになることを願ってる。

フォーカスは下流にあるけど、上流はこのスピードアップに対応できてるのかな？リンクされたブログ記事は産業革命と比較してるけど、産業革命ではスピードアップが上流での革新を引き起こしたんだよね。最初の革新は機械織りだった。ボトルネックは糸だった。それが自動化されて、ボトルネックは綿の生産になり、それも機械化された。だから、コードを書く速度を上げる本当のボトルネックは上流にあるのかもしれない。何を作るかの要件が、それに合わせて進んでいけるのかな？

確かに、実際にエディタにコードを打ち込むことがソフトウェアエンジニアリングの難しい部分でも価値のある部分でもなかった。価値は、うまく機能するアプリケーションを設計できることから来るんだ。パフォーマンスやセキュリティの面でも合理的であることが大事。

1億ドルを集めたからって、いいアイデアがあるわけでもないし、みんなが好きなアイデアでもないし、金を稼げるアイデアがあるわけでもないよ。

俺たちは、少しずつ方向を変えることの価値を過大評価してる罠にはまってる気がする。出力は全部同じ脳から出てるから、誰かがたまたま良いプロンプトを思いついて、時間をかけて考えたことを一発で解決しちゃうことを止めるものは何もないよね。コードの質は同じだし、もし指示を出すことが、昔のやり方でコーディングするのと同じくらいになったら、意思決定も同じだよ。

新しいスキルは、安価な入力を価値のある成果に導く技術をマスターすることだ。これには強く同意する。最初は「エージェント工学」がソフトウェアを書くことだと思ってたけど、実際には特定の問題を解決するためのカスタムツールをすぐに反復できる能力だって気づくのに時間がかかった。でも、解決したい本当の問題から自分を解放し始めると、エージェント工学の部分はあんまり面白くなくなる。問題を解決して、エージェントにちょっと頼むだけで素早く改善できるって気づくのはいいけど、基本的には問題解決に集中するべきだよね。それなのに、たくさんの人が複数のエージェントを使って、あまり努力せずに何かを作ることについて話してるのを見かける。まるでエージェントのコード自体に価値があるかのように。これは、ソフトウェアが価値を持っていた何十年も前の名残だと思う（今でも高く評価されてるけど利益の出ないソフトウェア会社がたくさんあるのがその証拠）。アラン・ワッツの有名な言葉を思い出すよ。> メッセージを受け取ったら、電話を切れ。もし本当にAIを活用してユニークで潜在的に破壊的なことをしているなら、「AI」部分はすぐにあまり面白くなくなって、注意を向けるべき焦点ではなくなるはずだ。

別の見方をすると、バックホーで溝を掘るのが安くて早くなったからって、たくさんの溝を掘って金持ちになれるわけじゃないよね。

コードは安くなった。シンプルなコードは安い。もっと複雑なコードは安くないかもしれない。細部に注意を払う理由は、複雑さが重なっていくからで、最も安価なクリーンアップは何かを書くときで、壊れたときではない。この最後の部分はまだ完全には整理されてないけど、今のところ。これ以上の改善を期待しない理由はあるのかな？それに関わらず、今はたくさんのコードが安くて、製品を作るのは楽しいけど、これが短期的な利益以上にはつながらない気がする。基準を下げると、10倍のものが得られて、10倍のノイズが増える。さらに下げると、100倍になっていく。

「良いコードにはコストがかかる」と「良いコードを提供するのは、[無料]よりも依然としてかなり高価だ」と言うように気をつけた。もっと美しい表現の「良いコードは高価だ」とは言わなかったのは、エージェントを使うことで良いコードがそれほど高価ではなくなると思っているからだ。良いコードを得るためにはまだ積極的に努力しなきゃいけないけど、コーディングエージェントが細かい編集を代わりにやってくれると、時間がずっと少なくて済む。エージェント工学は良いコードを生み出すべきだと強く信じている。もし速く進んでいるのに結果が悪くなっているなら、プロセスを見直して修正できるところがあるか考える価値があるよ。

スパゲッティコードは昔からあったけどね。

コンピュータプログラミングは安いけど、ソフトウェアエンジニアリングは高い。

確かに「良いコード」に対する市場のインセンティブは今までで最悪だけど、生成されたコードの decent な部分を良いコードに移行するコストが、最初から良いコードを書くよりも悪いとは思わないな。

私の経験では、エージェントを使って良いコードを書くのは手書きよりもずっと手間がかかる。手で書くと、自分が書いた各行の理由をしっかり理解できるからね。AIを使うと、毎回のクローズを評価して、なんでそこにあるのか考えなきゃいけない。ジュニアのコードレビューをする時も、彼らが各行を含める理由があるという信頼感がある（彼らが一瞬でもAIを使っていないと仮定してね）。でも、Codexに関しては全くそうじゃなかった。先月はエージェントを通じて大半の仕事をしたけど、その成果物をレビューした後、思いもよらないエッジケースやバグを見つけてしまった。人間が引き起こすとは考えられないようなものだよ。もちろん、出力をもっとよくレビューするのは私の責任だけど、AIに簡単にバグチケットを投げることで得られると思っていた利点は、スケーラブルなプロジェクトを持ちたい時にはすぐに消えちゃう。

コストと作業量は変わらないと思う。変わったのは効率だ。以前は人々がバイトを手動でプログラムしなければならなかった。そこにCが登場して、開発をスムーズにしてくれた。Pythonを使えば、数行でシンプルなデバッグ用UIサーバーが書ける。特定のタスクを数時間で完了できるフレームワークもある。すべてをゼロからプログラムする必要はない。コードが多ければ多いほど、すべてが速くなる。仕事の大部分が終わっているからね。私たちは加速しているけど、まだ9時から5時の仕事をしている。

基準を下げると、生成されたコードを書くのは早くて簡単、しかも安い。でも、LLMで同等の品質のコードを生成するよりは安くないよ。

LLMはタイピングを安くするけど、推論を安くするわけじゃないんだよね。LLMはコードをコピペしたり、標準のエラーメッセージを使って問題をトラブルシューティングするコストを下げてくれる。特定のことをするためにフレームワークの使い方をStack Overflowで探す代わりに、モデルにプロンプトを投げればいい。使っている言語について何も知らなくても、フィードバックループを活用できるんだ。LLMは、フレームワークの使い方を学ぶためにドキュメントを読む必要があるような、ソフトウェア開発の面倒な作業のコストを下げてくれる。自分が何をしているかは知っておく必要があるけど、車輪を再発明する必要はないよ。

趣味以外のプロジェクトでは、コードのコストは動いているシステムを壊すことにあったんだ（本物のバグによるものか、何らかの暗黙の前提の変更によるものかは問わず）。それがコードの変更を信じられないほど高くしていた - しばしば元の実装よりもずっと高く。厳しいように聞こえるかもしれないけど、プロジェクトのライフサイクルを通じて、1人1日10行というのは生産される行数の高めの見積もりなんだ。人間がタイプするのが遅いからじゃなくて、しばらくすると、壊さないように以前書いた行を変更することが全てになってくるから。LLMは、制約やテストが適切に指定されていれば、人間よりもずっと得意なんだよね。

消えはしないけど、戦闘構成やドキュメント、構文、似たようなアプローチを比較する時に、いくつかの場面で楽になるよね。過去には、すごくシンプルなツールを使っているか、十分にスキルを上げている人じゃないとボトルネックになってた人たちを、今は多くの人が力を得られるようになってるのがすごく面白いと思う。これらの2つのことはまだ変わらないけど、探索や他のレイヤーでの進行速度はかなり速くなった。エントロピーやセキュリティ、システムテスト、自動化の基本が不足している問題も出てくるけど、取り組む価値のある良い問題だと思う。私は評価にすごく注目してるんだ。経済学者たちにエンドツーエンドでコーディングできる力を与えたいから、そのためにボトルネックにならないようにしたいんだ。誰もがビルダーになれるように、非伝統的な開発者と職業としての開発者が共通の言語を持つことが大事だと思う。異なるオーディエンスに話しかけたり、すべてを解決してくれるというハイプに立ち向かうのは難しいけど、挑戦することでかなり進展できるよ。

コードを書くコストは非常に安いけれど、特定のコードベース（私の仕事で扱っている何百万行もあるモノレポなど）でそれが機能するかをレビューして検証するコストは非常に高い。私もそう思う。コードを生み出すのは簡単だけど、そのコードが全くのクソじゃないことを確認するのは全く新しい挑戦であり、懸念事項だ。LLM以前もコードレビューは手間がかかっていたけど、今はコードが全く違う方法で生成されていて、時には自分の能力を超えようとするバイブコーダーからの監視がほとんどない場合もある。だから、明らかに失敗するような大規模な変更が生成されて、流れは止まらないんだ。

エージェントに機能を変更するように頼んで、他の機能を壊さないと100%確信できるようになったら、コードの見た目なんて気にしなくなる。そのハードルは不合理に高い。今、もしシニアエンジニアに成熟したコードベースで機能を変更するように頼んだら、他の機能を壊さないという確信はせいぜい70%くらいだ。テストは助けになるけど、限界がある。

手作業で新しい変更を加えるつもりはないから、これは関係ないよ。AIを使うからね。

すべての盛り上がりは、コードを生産する速さに集中している。でも、実際のボトルネックは、意図を明確に指定するコストが常に高いことだ。それが、変更可能でテスト可能、正確な結果を得るために必要で、価値をもたらすものを作るために必要なんだ。

現在のLLMベースのエージェントは、変更しやすいコードを生成しているのか？彼らは生成している。私はもはやコードを書いていない。私がコミットするすべては100%エージェントを使って生成されたものだ。そして、それは私のコードベースに既にあるコードや、クリーンコードや良いプラクティスについての指示に基づいてコードを生成する。もしLLMからメンテナブルなコードが得られないなら、それはこの理由だ：ゴミが入ればゴミが出る。

LLM（大規模言語モデル）について100%確信は持てないけど、評価の周りに適切なエンジニアリングを施せば、許容できる品質レベルに達するかもしれない。開発コンセプトとしてトレーサーバレットを推進すべきだと思うし、捨てられることを前提にしたプロトタイプよりも、良いものになるはず。クリーンルームでの自動ポーティングは、混沌とした探索的プロトタイピングセッションの後に良いパターンになると思う。

LLMに機能を変更させたりバグを修正させたりするのが常にあるんだ。鍵は、LLMとそのコンテキストをマイクロマネジメントして、変更を読み取ることだね。バイブコーディングよりは遅いけど、手動でコーディングするよりは速いし、動作するメンテナブルなソフトウェアが得られるよ。

「コードは書くのが簡単だけど、読むのは難しい」ってことを付け加えたいな。だから、複雑な実装を隠して高レベルのコードを提示するために抽象化レイヤーが設計されてるんだ。でも、LLMはコードを書くのも読むのも得意なんだよね。ただ、いつ止めるべきかが分からないのが難点で、早く終わらせて壊れたまま放置したり、過剰にエンジニアリングして不要なものを追加したり、難しすぎて重要でないものを削除したりすることがある。TDD（テスト駆動開発）のアプローチが彼らにはすごく合ってると思う。高レベルの機能仕様を与えて（Gherkin仕様を覚えてる？）、それを通すように指示するんだ（彼らが書く中間コードのユニットテストも含めて）。それから、他の高レベルのテストを実行して何も壊れていないか確認して、最後にリファクタリングする。最近は、機能の各ステップに対してスクリーンショットを生成するように指示してるから、UIフローをすぐに評価できるようになった（サイモン・ウィリソンのロドニー・ツールに触発されて）。今は、コードが読みやすいかどうかや変更しやすいかどうかを気にする必要がなくなった。LLMが詳細を処理してくれるからね。「Feature Xを実装しました」と言った時に、その機能のために書いたステップが実際に期待通りのことをしていて、UIがユーザーのニーズに合っているかだけを確認すればいいんだ。

現在のLLMベースのエージェントは、変更しやすいコードを生成するの？ うん、それが目標なら、エージェントと作業しながらその目標を達成するための手順を踏めばね。つまり、彼らにどうやってプロンプトを出すかを考えたり、良い例を提供したり（既存のパターンを模倣するから、将来の変更に対応できるように設計されたコードベースで作業する方がうまくいくよ）しながら、彼らが何をしているかを見守って、「それをXのように書き直して」って言えるようにすることだね。 > エージェントに機能を変更するよう頼んで、他の機能を壊さないと100%確信できるようになったらね。だから、赤/緑のTDDを使うように言ってるんだよ: https://simonwillison.net/guides/agentic-engineering-pattern...

そういうプロジェクトでは、コードから始めることは絶対にないんだ。仕様から始める。時には仕様に数日かけることもある。仕様が明確になったら、コーディングを始めるけど、これは全く別のモンスターだね。基本的には一般的なワークフロー（仕様 > チケット > グルーミング > コーディング; だいたいそんな感じ）とあまり変わらないけど、すべてがAIを使ってる感じ。

どのソフトウェアプロジェクトもこんな感じだよね…