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

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

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

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

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

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

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

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

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

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