ここが一番心配なところだな。 > もし今日、1人のエンジニアにつき少なくとも$1,000をトークンに使っていないなら、あなたのソフトウェアファクトリーには改善の余地がある。これが本当なら、「AI革命」を「受け入れたい」と思っても、どうせ私は詰んでるってことだよね。マネージャーがトークンに$1,000も使うのを承認するわけがないし、私たちのチームはAIを探求するために年間$40,000の予算しかないんだ。個人的な視点から見ても、住宅ローンや食費みたいな厄介なものがあるから、トークンに$1,000も使う余裕なんてないよ。今のところ、やってもしなくても詰んでる感じだ。気分が悪いよ。

確認できるものがない限り、ただの話だよね。話は安いから。今はChatGPTのおかげで、話がさらに安くなっちゃった。

不連続な能力が完全にランダムからある程度予測可能になるのを見ると、隠れていたくなる気持ちもわかる。でも、重要なものはほとんどGitHubにあるよ。ここでの障壁はメカニズムデザインと価値観（異なる場合もあるけど）に関するものだね。この世界ではフロンティアラボは運命づけられてるし、ペイウォールの後ろにあるコモンズはハイパーミラーされる。価値は全く違う場所に蓄積されて、SF小説のようにきれいに指数関数的に増えるわけじゃない。ダボスで話してる連中が言ってることとは全然違うよ。Anthropicは、私が知ってる中で得意なグループのトップ5には入らないし、いつか突然起こるまでフリンジ扱いされるだろう。だから、なんで秘密にする必要があるの？PythonやJSONを捨ててlean4を学ぶことで、階段を登っていくんだ。必要なときにはFFIを通じてプロパティテストをlean定理に結びつけて、証明されたASTプロパティのためのpretty printerを構築し始める。そう、ドロイドたちは小さな花火のようなVMで、効果/共効果の証明グラフを読み取りながら先に進んでいく。結果は保存されて、有用な結果がインデックスされる。人間のレビューは大局的なことについてで、人間のコーディングは完全な正確性について（そして、あなたの「証明」にバグがあったときにそれを修正すること）。プログラミングの仕事は影響を受けるけど、思ってるほどじゃないよ。ドロイドたちはデイビッド・グレーバーが言ったような「クソ仕事」を大半やってて、いくつかのことに関しては天才的な才能を持ってる。リバースエンジニアリングや情報セキュリティに関しては、彼らはあなたを圧倒するだろう。これはAIと同じくらい形式的な手法の話だよ。

ここで倫理的な宣言をしてもらえる？彼らから報酬を受け取っているかどうかを明言してほしい。彼らのページは、私には多くの作られた専門用語と純粋な物語に見える。どの技術も既存の概念を名前を変えただけのものだ。デジタルツインユニバースはモック、遺伝子輸血はリファレンスコードを読むこと、セムポートはトランスパイレーションだ。サイトにはベンチマークも欠陥率もコスト比較も生産結果もゼロだ。唯一の指標は「もっとお金を使え」ってこと。誠実にこの分野で働いている人は、エージェントプロジェクトの90%が失敗していることを知っている。HNのメインページには、実質的な内容がない投稿が毎日3〜4件あるだけで、エージェンティックAIのマーケティングがエンジニアリングの洞察として装われているだけだ。GoogleやMicrosoft、他の企業が来年AIに6000億ドルを投資して、リターンを得るためにパニックになっている中で、彼らは今、インフルエンサーに60万ドル以上を支払ってAIの熱意を作り出して、このインフラ投資を正当化しようとしている。だから、明確な財務利益の開示と実際のデータに裏付けられた再現可能な主張がないAIの思想的リーダーシップには関わらないよ。エージェントによって完全に構築された実際の生産機能を、完全なトレース、欠陥率、誠実な失敗の会計とともに見せてほしい。さもなければ、専門用語を作り出して、雰囲気チャートを投稿するのはやめてほしい。

でも、ほとんど何も生み出してないよね。大学卒の若者に1万ドル渡した方が、もっといい製品ができるよ。

あの持ちこたえてる奴らは、問題を徹底的に反復する前にどうなるべきか知ってる？人々はトークンにお金を燃やして、これらのものが作業ファイルのセットにたどり着くまでフラフラさせてると思う。俺はもっと情報をキャッチアップして、無視するんじゃなくて構築してるよ。

トークンに$1k/日かかる件について - ローカルリグを作ることもできるよ、特に「派手な」ものじゃなくても。最近、ローカルモデルの有用性についてのスレッドがあったよ、あまり派手じゃないハードウェアでもね。エージェントが大きな部分を占めていて、タスクを設定すれば、寝てる間やどこかに行ってる間、別のことをしてる間、あるいは本を読んでる間に終わるんだ。通知をオフにして、コンテキストスイッチを避けよう。チェックしてみて： https://news.ycombinator.com/item?id=46838946

エージェント同士が「賄賂」を渡し合うようになるのも驚かないな。

出力が（不）均衡に大きいなら、コストのトレードオフは正しい選択かもしれないね。トークンが安くなる可能性もあるし。

実行速度によるね。5日で同じ量の作業をして5,000ドル使うのと、人間に1ヶ月かけて5,000ドル使うのとでは、計算がもっと意味を持つよ。

これは面白いポイントだけど、別の視点を提案してもいいかな？ 20営業日を想定すると、年間で20,000ドル x 12 = 240,000ドルになる。つまり、FANGの新卒の年収と同じくらいだね。私は多くのジュニアからミッドジュニアレベルのSDEと一緒に働いてきたけど、残念ながら80%はClaudeよりも良い仕事をしていないよ。（スタッフレベルのSDEと一緒に働いたこともあるけど、彼らはAIよりもひどいコードを書くことが多いけど、ドメイン知識やTLの責任でそれを補っていることが多い。）AIがソフトウェアエンジニアリングをさらにピラミッド型に変えていくのが見えるよ。

$1,000は、1日あたり約5ドルだね。自分の使用量を測っていて、年間で$6,000に達しそう。まだ自分が作ったコードを見るのが好きな段階だけど、いつかはそうしなくても良いソフトウェア開発の状態に向かうと思ってるよ。

そうだね、もっとそのことについて話すために自分の文章を更新するつもりだよ。編集：その部分はここにあるよ： https://simonwillison.net/2026/Feb/7/software-factory/#wait-...

これは達成したいことによるけど、正式な証明や仕様に対する静的分析のために設計された言語があることを言っておく価値があるね。今、私たちはそれをあまり活用していない気がする（歴史的に書くのがあまり楽しくなかったからだけど、すべてがトークンなら誰も気にしないよね）。そして「仕様を具体的に定義する」（新たに出てくる振る舞いをどう活用するか）というのが、プログラミングの新しい定義になるんだ。

記事読んだ？ >StrongDMの答えはシナリオテスト（Cem Kaner, 2003）からインスパイアを受けたんだ。

AIはすぐにおかしくなるよ、今日テストしているOpus 2.6でもね。提案されたコードは本当にゴミだけど、テストは通るんだ。熟練した人間のレビューには通らないよ。最悪なのは、放っておくと技術的負債がどんどん増えていくことだね。

これにはほぼ完全に同意するよ。難しいのはもう生成じゃなくて、意図と結果のバリデーションなんだ。特に、決定が高リスクだったり不可逆的な場合、パッケージの更新や大規模な取引を考えてみて。俺が取り組んでいる（オープンソース）は、人間のバリデーションを置き換えることよりも、それをスケールさせることに重点を置いているんだ：明確なインセンティブと意見の不一致を持つ複数の独立したエージェントを使うことで、単一のモデルやレビュアーを信頼するのではなくてね。人間はまだ最終的な権威だけど、コンセンサスや敵対的レビュー、追跡可能な意思決定の経路があれば、本当に重要なエッジケースに人間の注意を取っておけるんだ。コードや出力を直線的に読むのではなくてね。バリデーションをファーストクラスのシステム問題として扱うまで（単一のモデルの答えのバイブチェックではなく）、ほとんどのことは「クールなデモ」の領域に留まるだろうね。

簡単だよ：検証とセキュリティテストをエンドユーザーに任せるだけ。

でも、それって人間とどう違うの？通常、人間だからって好きなコードを自由にコミットさせるわけじゃないよね。コードレビューだけじゃなくて、デザインレビューもあるし、ペアプログラミングすることもある。ユニットテストやエンドツーエンドテスト、いろんなテストがあって、その後にコードレビュー、継続的インテグレーション、Q&Aもある。エラーやユーザーからの苦情、コスト/パフォーマンスの問題を監視するシステムもあるし、信頼できないプログラマーから信頼できるプログラムを引き出すためのプロセスや技術のツールキットがある。問題は、エージェンティックなコーダーが完璧かどうかじゃなくて、彼らがプラスの貢献をするかどうかなんだ。そういうシステムの中で彼らを自由にすると、バグが蓄積されるのか、それとも取り除かれるのか？高品質に収束するのか、低品質に収束するのか？Opus 4.5あたりの答えは、彼らはわずかにプラスで、品質に収束するってことだと思う。システムを設定して、ある程度遠くから監視すれば、彼らは物事をコントロールしてくれる。正しいことをする傾向があると思う。この記事で言ってることはそういうことじゃないかな。

これがSpeedscaleでやってることだよ。私たちの方法は、トラフィックをキャプチャして再生することで、以前にうまくいったことが今も通用するかを検証してるんだ。

それがクレイジーなのか、未来の一端なのかはわからないね（両方かもしれないけど）。追記: "カナダの彼女"について今日学んだよ、ありがとう！

このリポジトリには実際のコードがあるよ: https://github.com/strongdm/cxdb

それは面白いね！

彼らの製品ページには、アトラクターに加えてデータベースやアイデンティティシステムがリストされてるよ: https://factory.strongdm.ai/products 工場を作ることに取り組んでる私たちには明らかだけど、エージェントやセッション間で共有コンテキストが必要だし、誰が何をしているかを追跡するために改善されたIDと権限システムが必要なんだ。

私も同じことを言おうとしてた！またしても、自分たちのことばかり考えてて、実際には何も示せてないブログ記事だね。最悪なのは、simonwが（おそらく無意識に、あるいはソーシャルエンジニアリングで）彼らのために保証して、ステルスマーケティングをしていること。現行の市場レートで、エンジニア一人あたり1,000ドル/日もトークンコストがかかるなんて？大胆な戦略だね、Cotton。でも、彼らが何を狙ってるかはみんな知ってる。大企業の取締役会に自分たちを素晴らしく見せて、買収させようとしてるんだ。じゃなきゃ、投資家が彼らに投資する理由がないよね。

今、これについて話している人たちのウェブキャストに参加してる。彼らはhttps://docs.boundaryml.com/guide/introduction/what-is-bamlやhumanlayer.devから来た人たちで、主に仕様駆動開発について話してる。賢い人たちだよ。彼らから仕様駆動開発について理解したことは、私の理解する限り、これにあまり遠くない。まずは「/research -> /plan -> /implement(RPI)」から始めよう。チームのために複雑なシステムを構築する際には、人間をループに入れる必要があって、デザインの決定に集中したいんだ。そして、エージェントの周りに構造化されたワークフローを持つことで、デザインの決定をする人間にとってより良いUXを提供できる。これは、ドリフトやコンテキストの汚染、コードベースの混乱を制御するために必要なんだ。これが仕様駆動開発の出発点だよ。新人の頃、スラッシュコマンドをコピーして/research、次に/plan、そして/implementを押して、数回の反復の後に不整合だと気づいて戻って修正したこと、何回あった？多くの人は今でもチャットGPTと行き来しながら、JIRAのドキュメントをコピーしたり、PRDドキュメントの質問に答えたりしている。これは防衛ではなく、多くの人にとってAIと作業する際のユーザー体験なんだ。これを解決するための非常に理解しやすい方法は、計画ドキュメントから抽出した構造化情報を人間に提示することだ。例えば：https://gist.github.com/itissid/cb0a68b3df72f2d46746f3ba2ee7... この非常におもちゃのような仕様駆動開発では、RPIループの各ステップが分解されて、ループ内の人間とともに非常に決定論的に作られている。これは、AIのチーフオフィサーが設計した人間のためのシステムで、AIを使って迅速に作業するためのかなりカスタマイズされたプロセスに従うチーム向けなんだ。そうしないと、巨大なゴミの山になってしまう。コードを読むことやQAの全体的な目的はこれだよ：開発の時計を止めて、高信号の情報を見ること。テスターはテストを読みたいし、QA担当者は動作をテストしたい。なぜなら、うまく書かれていれば、ソフトウェアが機能するかどうかをたくさん教えてくれるから。もし、テストカバレッジが不十分なブラウンフィールドコードで統合テストを書いて、数日間暗闇の中で信頼できるものにしたことがあるなら、その感覚はわかるよね…そのステップを省くことが、すべてのVCが言う「最後のゲーム」なんだ。このStrongDMの話は、私が理解できる範囲を超えている。「人間はコードを書くべきではない」、「人間はコードを読むべきではない」、本当に…？でも、私がさらに不思議に思うのは、私が理解する限りの仕様駆動開発は、親が子供を育てるようなもので、一度親になると、自分の子供を育てたいと思うんだ。他の誰かの子供じゃなくてね。だって、それは完全に人間をループに入れるプロセスだから。すべての会社、技術系であれそうでなくても、自分たちのエンジニアが働きやすいプロセスを作りたいと思っている。だから、彼らがここに製品を持っているのかどうか、ちょっと疑問だな…

短期的な最適化と長期的な最適化の違いだね。短期的な最適化は、今すぐシステムを効果的にすること。長期的な最適化は、システム全体を改善する方法を探ること。

もしかしたら、経営陣がやっとリファクタリングに取り組むかもね。

エンジニアなら、これが狂ってるって思うよね。中間管理職が「進捗」を「支出」で定量化するのは結構一般的だし。私の上司の上司の上司は、コストが年々増えてるから、クラウドに成功裏に移行してるって主張するのが好きなんだ。

私のお気に入りの陰謀論は、これらのプロジェクトやブログ記事が実は大手AIテクノロジー企業に裏で支えられていて、経営者たちを説得してAIツールにお金をどんどん注ぎ込ませることで、彼らの膨大な損失を相殺しようとしているっていうやつ。

一方で、私は > 月20ドルのClaudeサブ > 月20ドルのOpenAIサブ > Claude Codeが切れたらCodexに切り替え > Codexが切れたら犬と散歩するか、本を読む。私は加速主義的なシンギュラリティのネオヒューマンじゃないけど、まあ、まだまだたくさんのことをやってるよ。

1日1,000ドル、50週間働いて、週5日だと→年間25万ドル。つまり、価値があるなら、AIは企業に25万ドルかかるエンジニアと同じくらい働かなきゃダメだね。税金や社会保障、オフィスのコストを考えると、そのエンジニアは年間17万～18万ドルくらいもらうことになる。アメリカの平均的なシニアソフトウェアエンジニアと同じくらいだね。生産性があれば、そんなに高い金額じゃない。おそらくAIは90,000ドルのジュニアエンジニア2人分くらいの働きしかできないけど、休暇やオフィススペース、社会保障などのコストはかからない。もし生産性がこれ以上なら、それは純利益だと思う。これが彼らの賭けなんだろうね。人間のエンジニアは、ジュニアたちを指導するテックリードみたいなもので、コードのレベルを超えた計画を設計したり、結果をチェックしたりするけど、特別なケース、例えばコンパイラが生成したアセンブリコードを人間のエンジニアが見るような場合だね。今はちょっと楽観的すぎる感じもするけど、狂ってるとは思わない。

私はこの理念の背後にいるStrongDMのトリオの一員だよ。核心の主張はシンプル：トークンに1,000ドル/日を使うのは簡単だけど、3人でやっても生産性を保つのは難しいってこと。

これは、彼らがあなたよりもAIに進んでいると自慢しているだけの馬鹿げた自己主張だね。AIの思想的リーダーになりたいという必死さが、インスタグラムのインフルエンサー並みの狂った注目を求めている。

なんでみんな価格にこだわってるのか分からない。例えば、こんな感じで「彼らは1ドル/日を売り込む勇気があるけど、製品はほとんどないかも」って。正直、価格は下がる可能性があるし、1人当たりのアウトプットには相関があるけど、もっと重要なのは「人間をエージェントループから外すこと」が、他でもコメントしたけど、かなり欠陥があると思うし、言うのも大胆だよね。VCたちが興奮してるけど、もっと注目すべきはAIエージェントのPMたちやAIのテックリード、あるいは以下のようなタイトルの人たちだと思う。- どんな「ワークフロー」を構築してるの？ - チームや新入社員がこれを使うことでどんな成功を収めてるの？ - ワークフローへの投資のRoCはどんな感じ？ - このワークフローはどれくらい多様性があるの？ すべての企業が独自のワークフローを構築してるのか、それともエージェントオーケストレーションに役立つパターンが出てきてるのか。

ソフトウェアのマージンは信じられないくらい高いし、もしかしたらこれは維持可能なアウトプットを得るためのコストなのかもね。それに開発時間も考慮する必要があると思う。誰かがSaaS製品を作ったら、短期間で簡単にクローンできちゃうから、通常存在する防御線がなくなっちゃう。だから、先を行くか追いつくためにはお金がかかるんだ。ある意味、FAANGが優秀なエンジニアを買い漁ってたのと似てる。競争するために必要なリソースを、潜在能力があるけど資本が少ない、より機敏な競合から奪ってるんだよね。

おそらく、エージェント的コーディングAPIを販売している組織は、この種の記事を盛り上げるためにマーケティング担当者を雇ってるんだろうね。 https://paulgraham.com/submarine.html

完全に馬鹿げてるよ。彼らの目標が、今まで作られたすべてのSaaSをクローンすることじゃない限り。

モデルは、以前に成功裏に構築したものの上に構築を始めることができるかもしれない。単純に指数関数的なエラーの伝播だけじゃなくてね。

（DTUのクリエイターです）最初の重要な洞察があって、それがDTUと公式のカノニカルSaaSサービスの間で高い忠実度を確保するための繰り返し可能な戦略につながったんだ。人気のある公開のリファレンスSDKクライアントライブラリを互換性のターゲットとして使うことを目指して、常に100%の互換性を目指してる。これがどれだけ難しいかも分かってくれてるね。私はこれを7月に始めたんだけど（他にもいろんなプロジェクトを同時に進めてるから、いつも3〜8個を juggling してる）、最初はSonnet 3.5だけで、結構地味な作業が多かった。特にSlackは、ある意味ではG-Suite全体よりも正しくするのが難しかったんだよね（！）それには驚いた。今はRustでDTU全体を再実装してる途中で（v1はGoで作った）、gpt-5.2を計画に、gpt-5.3-codexを実行に使ってるから、かなり人間の手間が減ってる。私的には、この話の最も新しい部分はNavanのアトラクターとそれに対応するNLSpecだと思う。リリースから24時間も経たないうちに、いくつかの動作する実装ができて、そのうちの一つはオープンソースなんだよね。[0] https://github.com/danshapiro/kilroy