このフォーラムでは、将来のソフトウェアは、genAIを使って実行時に作成・適応されるプログラムにあるという意見が出ているね。どれくらいその状態から遠いのかはわからないけど。

最近、仕事が少し暇だったから、エージェントを作業プロセスに取り入れることにしたんだ。メモ取り、タスク追跡、ドキュメント管理みたいなやつね。君のコメントは、まさに私の経験そのものだよ。1週目はどんどんプロンプトが広がって、パフォーマンスが落ちていった。2週目は、実際にオブジェクト（メモ、タスク、プロジェクト、人など）を正確に定義して、それに対して明確に定義された操作を行う方法を定義することに集中している。エージェントの表面は、君が指摘した通り、自然言語をコマンドや引数に変換する翻訳レイヤーに縮小された。

フルサークルのシステムプロンプトは、「自分の仕事を自動化して、できるだけ早く手放すチャンスを見つけること。コードで答えられる質問が来たら、その質問にコードを書いて実行して結果を得ること。」って感じかな。そんなLLMなら、いちごテストでももっと良い結果が出たかもね。

モデルが特定の問題解決モードにハマってしまって、新しいモードに移るためのちょっとした後押しが必要なケースを見たことがある。例えば、オーディオストリームのホットプラグ/アンプラグを処理するために、システムサービスの設定をいじるのではなく、実際には数十行のPythonを書くだけで済むことが必要だった。Claudeに、私のワークフローで効率的に解決できない一般的なケース（テストを実行するなど）を処理するためのシェルスクリプトをいくつか書かせたら、今では無駄に30分もぐるぐる回ることなく、そのツールを実行して設定するようになった。毎回、何かをするために一回限りのクレイジーなシェルやPythonのワンライナーを実行できるか聞いてくるたびに、代わりに自動承認できるツールを書かせるべきか考えるようになったよ。

これ面白いよ！ https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

そうだね、エージェントについての標準的な考え方は逆で、コストがかかりそう。LLMを使ってスクリプトを書いて、それを自分のループハーネスに入れて、最後に決定論的な検証が難しい部分はLLMに呼び出すって感じかな。

問題は、プログラムが解釈を必要とするエッジケースに遭遇することが多いってことだね。その時、LLMにそのエッジケースを処理させたくなる。そうすると、全体のループをLLMに任せて、ツールコールもやらせたくなるんだ。

100%同意。90%の確率で正しい非決定論的なものを使って、100%の確率で正しい決定論的なものを生成するっていうのがいいよね。プロンプトに追加する重要なことの一つは、「- あいまいなエッジケースに遭遇したら相談してね」ってこと。AIを直接APIコールで動かすのは良くないと思う。アプリがAIを使うべき唯一のケースは、読んだり分類したりする時だけだね。要するに、古いCRUDアプリの「R」を置き換える感じ。もしその新しいAIベースの「R」エンドポイントを使って、「C」、「U」、「D」を自動で埋めるのはいいけど、人間がレビューする前に顧客のために何かを変更するべきじゃない。基本的にCRUDアプリはCRUDアプリのままだし（これは永遠に変わらない）、ただ非常に賢い「R」エンドポイントがあって、顧客のためにフォームを自動で埋めたり（内部ツールやJenkinsパイプラインなど）、アクションを提案したり（でも実行はしない）するって感じ。

ほとんどの組織では、流れがこうなってると思う：LLM -> プロンプト -> 結果 LLM -> プロンプト + スキルとしてエンコードされたプロンプト -> 結果 LLM -> プロンプト + スキルとしてエンコードされた決定論的コード -> 結果 早い段階でコードを生成するためにプロンプトを使うことで、その決定論的コードへの道をショートカットできると思うけど、基本的には非決定論的なラッパーの中に決定論的なコードを埋め込んでる感じだね。多くの場合、長期的なタスクを成功させるために必要な決定論的な層が欠けてる。エージェントループやフレームワークを通じて、非決定論的な境界の外に決定論的なコードが必要だよ。これによって、非決定論的な意思決定が決定論的な層の間に挟まれることになる：決定論的なエージェントフロー -> 非決定論的な意思決定 -> 決定論的なツール。これは私の実験で非常に強力なパターンで、エージェントがauto-researcherのようなツールを使って自分の決定論を構築することで、さらに強力になる。

うちのエージェントはよく自分でスクリプトを書くんだよね。それって、実質的に君が求めてることじゃない？スクリプトを促すのも、うまくいくときには時間と精度を上げるための便利な手段だよ。

これが、サーバーとモバイルアプリの間のインターフェースライブラリを自動生成する最後のプロジェクトでやったことなんだ。ハードウェア制御チームが仕様書をドキュメントとスプレッドシートで提供して、モバイルチームがそれを使ってインターフェースライブラリをコーディングして、サーバーに対してコードを検証してた。私はそのドキュメントをTSVに変換して、一部をClaudeに送って、TSVのパーサーを書かせたんだ。人間が書いた仕様のニュアンスを全部保ったままね。パーサーがすべてのエッジケースを処理してJSONとして中間出力を生成するのに150回以上のイテレーションがかかったよ。それからClaudeに、Apolloの上にカスタムグルーを使ってモバイルアプリが消費するコードを生成するコードジェネレーターを書いてもらった。この全体のパイプラインはGitHub Actionsの一部として動いていて、ライブラリのバリデーターが失敗したときだけClaudeを呼び出すんだ。失敗時にはmdファイルをClaudeに送って、何が悪かったのかを調べてもらい、解決策を提案してPRを作成するんだ。その後に人間のレビュー、再作業、マージが行われる。ここまでの総コストは$350未満だよ。

できるだけ繰り返し可能で検証可能、決定論的な方法でタスクを達成するためのコードを書く 正解。確率的な出力を持ちながら決定論的な受け入れの「ガードレール」を持つという概念は論理的じゃないよ。もしその領域が決定論的なモデル化に抵抗するなら、LLMを使っている時点で、そのガードレールがその能力を持つわけじゃないからね。

完全に同意！人間も非決定論的だってことを忘れがちだよね！でも、ツールを使えばちゃんとコードを書けるし、結構信頼性もある。AIに関する問題は、結局そのやらせたいことを決定論的にテストできるかどうかに集約されると思う。私たちの中で、作ったものをまず確認せずに作業を見せることがない人はどれくらいいるかな？

これめっちゃ真実だよ！まさにこの原則に基づいたプロジェクトに取り組んでるんだ - https://www.decisional.com/blog/workflow-automation-should-b... 根本的なインセンティブの問題があると思う。コード + LLM + ハーネスは効率的になるはずなのに、ラボはトークンを消費させたいから、コードを使うようには言わないんだ。ただトークンをもっと消費させようとしてる。彼らは今はトークンのコストや信頼性を忘れろって言ってるけど、モデルは良くなるって。だからほとんどの人は、自分のエージェントがプロンプトとスキルの助けで何でもできるはずだと信じてる。残念ながら、みんなが自分のエージェントが本番環境で失敗するのを見ないと、正しい結論にたどり着けないんだよね。

宣言的なものを考えてたんだけど、SQLじゃなくてPROLOGの方がいいかな。実際の制御フローと推論能力がある感じで。そうすると、LLMが抱えるのと似たような問題に直面するよね。例えば、静かな失敗やループ、矛盾が起きる。気をつけないといけないけど、要は同じ閉じた世界の仮定の問題かも。LLMの場合、これはハルシネーションとして現れるけど、自分が知らないことを認めることはない。

SQLの宣言的な性質は、関係代数の数学に基づいてるから、毎回同じ結果を返すんだ。でも、毎回同じ時間で返すかっていうと、それはインデックスやデータベースのサイズによるからね。クエリ自体は、LLMのように変わることはないよ。

例えば、スラッシュコマンドはミスフィーチャーだよね。チャットボットがターンを終えるのを待たなくても、コンテキストウィンドウの状態やこのセッションで使ったお金を確認できるべきだと思う。コントロールはチャットループとは独立しているべきだ。あなたが言おうとしていることはわかるけど、実際に提案しているものを設計するのはかなり難しいよ。どうせならそれを作って、大手企業に雇われることを目指してみたら？

Codexのデスクトップアプリを使ってるよ。GUIではコンテキストインジケーターや使用状況の統計が見えるし、会話を行き来するのも楽だね。時々、ターミナルでClaude Codeやopencodeを使うけど、Codexのデスクトップアプリと比べると体験はかなり劣る。

codex CLIでは、/statusはターン中にちゃんと動くよ。でも他のものはそうじゃないけどね。

それには同意できないな。すべての確率過程と同じように、LLMのエラーは定量化できるよ。それによって、各ユースケースはリスクとリターンのトレードオフになる。ユーザーはそのトレードオフが自分にとって意味があるかどうかを判断できるんだ。リスクが低い場合や、エラーが許容されるシナリオもあるし、リターンがそれを補うこともある。これはビジネスと技術の具体的な問題だね。

今、古典的なタスクグラフとAIエージェントを組み合わせたハイブリッドシステムを作ってて、お互いにインスタンス化させるようにしてるんだ。いずれ他の人もやると思うよ。

以前は、トークンのためにプロンプトだけのワークフローに押し込んでるのかと思ってたけど、実際には人がその部分を設計・実装する必要があることを心配してるんだと思う。これが、彼らが全ての人を全てのワークフローやプロジェクトで置き換えると言い張ることの足かせになってる。私は、これが開発者の雇用市場や給与スケールに悪影響を与えるほど生産性を上げるとは思うけど、今のこの技術のバージョンが本当に彼らが言ってることを実現するとは思えない。もし、彼らがこのくらいの金額を使って人間の開発チームの忙しい作業を減らす超便利なものを作ってると言ってたら、投資家たちは彼らに厳しい目を向けるだろうね。細かく制御されたステップがあった方が、小さくて安くて専門的なモデルを実装するのにはずっと優しいと思うよ。巨大なモデルを使ってテストを自動化したり、CSIのファンフィクションを5本一気に書いたりするよりもね。

これは約30ファイル後に壊れ始めた。Codexの短いコンテキストとタスクリストシステムがここでうまく機能するみたい。頻繁にコンパクトになるからね。モデルは、まだやっていないタスクリストの項目や、使うべきワークフロースキルを再確認する必要があったんだ。以前は大掃除に何時間もかけてたけど、特に問題なく終わったよ。

それを自分のためにハーネスを書くようにさせたり、最初のステップにさせたりできないの？必要なところで自分の決定論を押し通せるでしょ。

最小限のマークダウンファイルと、決定論的な作業を行うオーケストレーションスクリプトの組み合わせでスキルを持つことができるよ。エージェントは「すべてを実行する」必要はなくて、ただ正しいスクリプトを起動する方法を知っていればいいんだ。

俺は一つのアップボートしか持ってないけど、そうだね。これらのシステムを信頼性高く機能させる唯一の方法は、問題を小さな部分に分けることだよ。内部の整合性チェックをしても、LLMが期待よりもずっと一貫性がないことがわかるだけだから。

「製造パラメータxが今月と先月で有意に異なるか？」みたいなクエリを受け取る仮説検定エージェントを作らなきゃいけなかったんだ。エージェントがフローチャートに従って統計テストを実行して答えを返すようにね。その時は4oしか使えなくて、プロンプトでフローチャートを言及するだけじゃエージェントが従う保証はなかった。結局、エージェントをループに入れて、次のステップを常に与える形にしたんだ。ある意味、エージェントのためのカスタムハーネスだね。

もっと強力なエージェントハーネスがあれば、エージェントが基本的に自分の決定論的なコードを書いて実行できるようになって、実行されると各サブタスクのためのサブエージェントを生成するってことはないかな？今のところ、エージェントがサブエージェントを直接生成するのは見てきたけど、それでも最終的なフロー制御は非決定論的なオーケストレーターに任せることになるから、君のケースは失敗する典型的な例だと思う。