信頼できるユーザー、Jia Tanみたいな。

この方向性のすべてが大好きだけど、推論コストが異常に高いのが残念。モデルがリリースされたらすぐにコモディティ化されるから、トレーニングコストは気にしないんだけど。推論コストが下がったら、モデルをトレーニングしている企業が重みを公開するインセンティブがなくなるんじゃないかと心配してる。推論収入がトレーニングコストを回収するところだからね。どちらにしても…パフォーマンスあたりの推論価格にもっと革新が必要だよ。ソフトウェアとハードウェアの両方で。ソフトウェアの革新がコモディティハードウェアで推論を解放するのが理想だけど、それは難しいかも。でも、今日の最先端ハードウェアが明日のコモディティハードウェアになるから、いつかは実現するかもしれないね。Taalasが2ヶ月のリードタイムでモデルをハードウェアに焼き付けることができれば、それは大きな進歩だけど、問題がハードウェアのボトルネックに移っただけだから、まだ無駄だよね。安く生産できるゲームボーイのカートリッジのようなものが見られると思うし、それがベースモデルに差し込まれて専門性を高めることができると思う。でも、アナログコンピューティングに戻って、電圧差を巧妙に利用するような、もっと過激なアイデアを追求している人がいるのかも気になる。私には難しすぎるけど、直感的には電圧スパイクを0や1に減らすのはエントロピーを無駄にしているように感じる。

ユーザーとして、ソフトウェアの実際の（人間による）創造からかなり離れているから、考えてみると、どっちでもあまり気にしないんだよね。例えば、Hacker Newsの記事を見てみると、誰かがプログラムしたカスタムアプリで読んでいて、そのアプリはHacker Newsにホストされている記事を引っ張ってきている。すべてはどこかのサーバーを通じて、仕様に従ってワイヤーを通って運ばれている。私にとって、これは印象派の絵画や心を打つ詩ではなくて、それを創造した存在が私からはかなり遠くにあるから、もはや人工的かもしれない。90年代の子供でサイバーセキュリティについて少し知識があるから、もしかしたら言及したもののドキュメントやソースコードを調べることもできるかもしれないけど、興味があればの話だね。

でも、ユーザーがまともなチケットを書くことに近づいてる感じは数十年経ってもないよね。

そういうフィードバックループは、ゴミが入ればゴミが出るっていうのを指数的に悪化させるだけだよね。「ロボットは自分で作ったり修理したりする」っていうトロープだけど、ロボットがエージェントなんだよね。

Anthropicは、Bunの買収を受けてすぐにバックエンドホスティングを始めると思う。基本的にClaudeからビジネス全体を運営して、ソフトウェアのニーズに合わせてClaudeコードで作った特注アプリを共有するのが理にかなってるよね。

ユーザーは、ソフトウェアが本来何をすべきかについて、しばしば間違った考えを持っていて、全体像が見えていないんだよね。

その未来が見えないんだよね。3ヶ月前はその考えに完全に賛成だったけど、今は一歩進むごとにミスが増えていくのに気づいた。行き詰まってしまって、誰もがそのメンタルモデルを持たなくなる。AIが解決できないビジネス上の難題ってないの？それとも、すごく遅くて、正しいアイデアが見つかるまで17個のアイデアを提示するだけとか。俺は一番高いモデルを使ってるけど、AIの性質がその進展を妨げるかもしれないし、目覚めた会社もあれば、後から目覚める会社もあると思う。ミス率が高すぎるんだよね。そして、そのミス率を下げるために導入したシステムもミス率があって、複雑さと必要な探索時間を増やすだけ。多くの人が、12月の初期採用者たちの状態にいると思う。AIは、きちんとメンテナンスされたコードベースで機能的な機能を実装できるけど、自分でメンテナブルなコードを書くことはできない。実際、コードを書くのを手伝ってもらうよりも遅くなるから、手伝ってもらうと、もっと状況を把握できて、小さな問題をすぐに止められる。すべてを素早く繰り返せるし、1ヶ月間アイデアを開かなかったら、ある時点で地獄になった。今は3万行削除して、見えてくる問題の量が目を開かせる経験だった。スケールしないパフォーマンスの問題、冗長性、バグ、検証レイヤーに対する逃げ道、四重に増えた型。今はAIの出力をもっと注意深く監視できるけど、やっぱり自分で書いた方が早い。だって、一つのタスクだから。AIを使ったタイピングは、俺の脳より遅くないし。それに、FAANGが生産ラインごとに300ドル支払ってることを考えると、ここで本当に何を達成しようとしてるのか、スピードは問題じゃなかったんだ。優れたコーダーは、1日に10行の生産ラインを書く。正確性やアーキテクチャが問題なんだよね。それを解決するには、時間が経つにつれて機能追加がしやすくなるような、しっかりした基本ブロックを構築することが必要なんだ。

ハハ、これのバージョンをSPECしたばかりだよ。簡単な静的ウェブサイトがあって、数人に更新してもらいたいんだ。だから、信頼できる3、4人のユーザーに、更新をリクエストするためのサイト内チャットインターフェースへのアクセスを与える予定。次に、開発環境を立ち上げて、エージェントが変更を加えて、PRを作成し、ブランチのプレビューリンクをユーザーに返す感じ。非技術的なステークホルダー向けのエージェント駆動のCMSってところかな。うまくいくか見てみよう。

こういうタイプのチケットはできると思うけど、信頼できるユーザーの仮定がかなり重要だね。今のLLMのアーキテクチャでは、これ以上良くなるとは思えない。フィードバックメカニズムはいろいろできるけど、LLMは意識がないから、状況を理解して導く人間がいない限り、ドリフトは避けられないよ。でも、今でも特定の種類のクソアプリを使えば、かなり自動化できると思う。それが俺たちの職業の大部分を占めてるんだ。