そうだね、なんで誰もプロダクションのクレデンシャルを持ったコードベースをLLMに開放したり、インターンやジュニア開発者にプロダクションのクレデンシャルを渡すのか理解できないよ。俺はいつも「PROD」専用のチェックアウトを意図的に持ってたから、プロダクションモードで実行しようとする時は、わざわざそれをやるって分かってた。昔はVSの拡張機能があって、SLNファイルのパスに基づいてVSの色を完全に変えてくれたから、プロダクション用と開発用の色を簡単に覚えられたんだ。基本的には、確認が楽なようにマスターブランチの最新のコピーを常に持ってたよ。

だからインターンを雇っちゃダメなんだ！これをこう言い換えたいな：インターンにプロダクションデータベースを削除する権限を与えない理由だよ。これはプロセスの失敗であって、AIの失敗じゃない。正直、なんで人々がここでAIを責めるのか理解できない。だって、実際にAIにこれをする権限を与えたんだから。AWSがデータベースを公開したことを責めるのと同じだよ。それはAWSのせいじゃないし、これもAIのせいじゃない。

AIがうまく活用できる一つの分野は、アンチSaaS運動だね。安いPCを立ち上げて、オープンソースのパッケージを試すのが、ランダムな認証のバザールに飛び込むよりもずっと簡単なんだ。でも、LLMが開発中のもの、プロダクション中のもの、ローカルホストのもの、リモートのものを混同するのは変わらない。最近、linuxserver.ioのイメージを使って、Chrome/devtoolsと連携するオープンコードのツール/スキルを作ろうとしてるんだけど、適切な任意のポートに誘導できるんだ。でも、毎回の圧縮イベントで標準の9222ポートに戻されちゃう。元に戻したい気持ちもあるけど、デフォルトを使わないことで得られるセキュリティや、LLMの不明瞭さを利用したセキュリティの価値があるんだ。デフォルトはLLMが弱くなるところだから、常にデフォルトを使いたがるし、リモートシステムで作業していることを忘れがちなんだよね。オープンコードを使うと、LLMをリモートシステムや狭いツールの範囲に制限するプロトコルに強制する方法がない。いろんなツールの権限を変更することはできるけど、そういうイベントで露呈する弱点はそこじゃない。LLMは平均的な「問題解決者」だから、常に新しい使い方に向かうわけじゃなくて、Stack Overflowで見たことをやりたがるんだ。たとえ君が求めているのがStack Overflowの答えじゃなくてもね。

著者は、具体的に何をさせたのかあまり明確にしていない。「認証の不一致」があったと言って、Claudeが自発的にボリュームを削除したとだけ言っている。でも、彼らは自分たちの責任を少し軽く見せようとしているのかもしれない。彼女と話してたんだけど、ここ3ヶ月間、コードを一行も書いてないし、自分でデバッグもしてないことに気づいたんだ。そう言いつつ、Claudeがやったことを見ていると、認証の不一致からボリュームを削除するまで行くとは思えない。LLMは確率的だって理解してるけど、「認証が間違っている」から「ボリュームを削除する」ってのは非常にありえないと思う。 > Supabaseについては、Railway/Vercel/Replitについてあまり知らないけど、Supabaseはすごく価値を加えてくれる。自分が通常なら半分はコードを書く必要がないってのは、何かを始めるには最高だよね。もし高すぎたら、収益が出たら後で実装すればいいし。

実際、Railwayは同じボリュームにバックアップを保存していることがわかった。それはおそらく正確ではないと思う。スナップショットは他の場所（例えば、オブジェクトストレージ）に同期されているんじゃないかな。でも、スナップショットは論理的にボリュームリソースに所有されていて、ボリュームを削除すると関連するスナップショットも削除される。AWSのEBSボリュームもそういう動作をすると思う。

アカウンタビリティが、今のアメリカ社会で欠けている重要な要素だと思う。

「コンピュータがノーと言った」を次のレベルに引き上げてるね。コンピュータは言われたことをそのままやるけど、誰がそれを言ったの？データを入力した人？システムの元のプログラマーやデザイナー？AIに与えた言語テキストの著者？AIが登場する前から、誰が責任を持つのかを判断するのは非常に難しかったし、今はさらに不明瞭になってる。