【Ask HN】LLMコーディング、今のままで満足してる？「プロンプト地獄」を抜け出す新しい活用法を教えて！

正直なところ、今のLLMを使ったプログラミング体験にちょっと閉塞感を感じていませんか？自分はClaude CodeやCodexを日常的に使っていますが、自分でコードを書いている時に味わえるあの「フロー状態」に、AIを使うとどうしても到達できません。AIは「思考のための自転車」であるはずなのに、今の使い方は数分おきに急ブレーキをかけられる自転車に乗っているような感覚です。止まって、待って、レビューして、またプロンプトを投げる……この繰り返しに疲れてしまいました。今主流の「プロンプト入力→回答待ち」というループとは根本的に異なるアプローチを模索している方はいないでしょうか？個人的には、Tab補完モデルのような仕組みの方が、方向性としては正しいと感じています。現在進行形で面白い取り組みをしているスタートアップや、個人的な実験プロジェクトなどがあれば、ぜひ共有してください！

「自分でコードを手書きしていたときのようなフロー状態には、なかなか入れないね」。今の新しいフロー状態ってのは、10個のターミナルタブを異なるgit worktreeで開いて、それぞれのタブが何のためのものだったかを必死に思い出そうとすることだよ。

エージェントベースのグラフ型ワークフロー実行エンジン兼フレームワークを作ってるんだ。ハーネス（harness）の概念を完全に抽象化・汎用化したもので、『ノード/エージェント』はハーネス（cc、codex、open code、piなど）とモデルを組み合わせたものとして定義してる（いろんなモデルとハーネスの組み合わせをテストしてるんだ）。単純なものから複雑なものまで一連のタスクがあって、ワークフロー（初期ノードとその振る舞いのセット）を定義し、それぞれのタスクを各ハーネス・モデルの組み合わせに割り当てて実行させてる。ワークフローには、ワークフローグラフを修正したり新しいノードを作成したりできるエージェントやノードを含めることも可能。他のノードがタスクを分割して別ノードにサブタスクを投げることもある。現時点ではほとんど実験段階だね。タスク完了までの実時間（ウォールクロックタイム）や、トークンとコストの合計などのメトリクスを収集・追跡してる。これによって、異なるタスクに対して各ハーネス・エージェント・モデルがどれくらいの能力やパフォーマンスを発揮するかがかなり把握できるし、自作のハーネスのテストやドッグフーディングにも役立ってるよ（これもテスト対象のハーネスの一つで、今のところ一番効率的かな）。今のところ最大のボトルネックは、この広大なテストマトリクス（タスク・ハーネス・モデルの組み合わせ）にかかるトークンコストだね。いずれは全部リリースしてオープンソースにしたいと思ってる。

まさに同じ問題に直面したよ。複数のエージェントを別々のターミナルで立ち上げてみたけど、余計にフロー状態が乱れるだけだった。でも、一ついい回避策を見つけたんだ。

「ウォーキング・コーディング」。略してウォークディング（Walkoding）だ。

ハーネスを使って、あるいは自分で作って、それをTelegramに読み込ませて外に出る。ソロキャンプに出かけながら機能実装をいくつもリリースできたよ。座りっぱなしで退屈することなく、作業に集中できるんだ。

本当に解放感があるから、すごくおすすめだよ。

自分は「ハーメチック（密閉された）エージェント」と呼んでいる手法を使ってる。完全にサンドボックス化されたエージェントたちが、同じ仕様書をもとに別々にコードとテストを書くんだ。コードを書くエージェントはテストの内容を見られないし、テストを書くエージェントはコードの内容を見られないようになっている。こうすることで（コードとテストの間での確証バイアスを避けて）、より品質の高いものが作れると考えているからだ。ただ、通常エージェントがRAGで参照するような仕様書やガイドを抽出する必要があるから、セットアップはかなり面倒だね。

まあ、コーディングというよりは人（エージェント？）のマネジメントに近いかな。コードを書くというより、プロセスを構築してデバッグしている感じ。ハーメチック・エージェントを動かすために、使っているエージェントたちに対してイライラしたり議論したりすることにかなりの時間を使ってるよ（まあ彼らと議論しても仕方ないんだけど、別の通常エージェントに彼らのログを読み込ませて、サンドボックス内の文脈をどう改善できるか分析させたりはしてる）。

自分も同じ経験があって、AIを使った個人開発が嫌になったことが何度もあるけど、それでも懲りずに戻ってきちゃうんだ。最近使っているFableと最新のSonnetはかなり良くて、いい感じだよ。頻繁に停止して追加プロンプトを求められることなく、大きな機能の実装まで長時間動いてくれる。今一番フロー状態に入れているのは、大きな機能セットの計画を立てるときに、Claudeのウェブアプリを壁打ち相手にしているときかな。コードは書かせずに、質問を投げてもらって、自分がまだ深く考えられていない部分を明確にしてもらうよう指示するんだ。そうすると実装計画が非常に詳細に出来上がるから、FableやSonnet 5と相性が抜群。その後はPCから離れて他のことをしていても、『止まってないか確認しなきゃ』とか『突っつかないと』という強迫観念に駆られなくて済む。終わった後に変更内容をレビューしてQAとテストを行って、次のタスクを計画する。この問題は解決に向かっているみたいで、本当に素晴らしいよ。

自分も例に漏れず、ここ20年で所有してきたPCパーツをドラゴンの巣窟みたいに溜め込んでいるオタクの一人だ。実用的なものはできるだけホームラボに組み込んだけど、それでも過去10年以上のGPUが山ほど余ってる。

そこで、VRAMが3GB以上あるやつを全部ネットワーク上のいろんなマシンに載せてみることにした。LLMが動かせそうなものは何でもね。異種混合LLMの群れ（スウォーム）をコーディングタスクに投入する実験をやってるんだ。llama3.2:3bのような小さなモデルからQwen3.6:27bのdenseモデルまで、10種類以上のユニークなモデルを動かしてる。

今のところ結果は…興味深いね。コーディング自体はそこまで良くないけど、スウォームに意見を募るやり方は『驚くほど』うまくいった。10個のユニークな視点をまとめて要約させるのはめちゃくちゃ役に立つ。スウォーム同士に『議論』させる機能を加えたら、結果はさらに面白くなったよ。

最終的なゴールは、どのモデルがどのタスクに優れていて、どのマシンがどのモデルを動かせるかを学習し、リクエストを最も効率的な場所にインテリジェントに振り分ける自律的なルーティングネットワークだ。

RTX 6000を買う余裕はないけど、今あるGPUの山で小さなモデルを動かすことはできる。現時点では期待通りとはいかないけど、他の面ではかなり便利だと分かった。そのうちコーディングもうまくいくようになって、スウォームが自ら自己改善できるようになればいいんだけどね。

Venkatesh Raoが言ってたアイデアなんだけど、その時に選ぶ仕事の種類を、今の気分に合わせる（あるいは、やるべき仕事に最適な気分に自分を持っていくきっかけを見つける）という考え方がある。

自分の性格の側面や、あり得る気分の状態に合わせたペルソナをいくつか作っておいて、それぞれに対応させるんだ。役割を定義するというより、作業スタイルのようなものかな。それぞれにプロンプトを書いておく。

エージェントがアクセスできるタスクリストを作って、そこに自分のペルソナも読み込ませる。

そして、タスクを一つ選んで、各ペルソナのレンズを通してその仕事を構成するように指示し、『どれがいいか選んで』と自分に問いかけさせるんだ。

これを毎朝実行するようにスケジュールして、自分の直感で選んだものに従ってみる。

これでプロンプト応答ループの反対側に身を置くことになり、エージェントがあなたに回答を求めてくる状態になる。これならすぐにフロー状態に入れるはずだよ。

このプロンプトを試してみて：
『メインタスクに取り組んでいる間、これまで文脈を共有した並行サブエージェントを立ち上げて。サブエージェントは質の高い質問を考え、zenityのようなダイアログツールを使ってユーザーに提示して。ダイアログツールの機能をフル活用して、段階的でインタラクティブなユーザー体験を作るように入力をカスタマイズすること。回答に合わせて質問を適応できるよう、一度に聞く質問は少しだけに抑えて』。

こうすればメインエージェントが動いている間も退屈せずに済むよ。サブエージェントの回答をメインスレッドに統合するようにさらにカスタマイズしてみて。

確かにフロー状態とは別物だし、恋しくなるよね。

AIとの付き合い方について、いくつか試行錯誤してメリットとデメリットをまとめてみたよ：

• AIに解決させて結果を信頼する：思考をアウトソースするので、コードの理解を失う。うまく動くかもしれないし、動かないかもしれない。大抵は動くけど、コードはどんどん汚くなっていく。

• AIに解決させて結果をレビューする：結果を理解する助けにはなるし、AIが失敗したときに修正しやすくなる。でも結局思考をアウトソースしているし、自分で解決策を考えない分、コードとの繋がりは薄れる。それに何より、レビュー作業はソフトウェア開発の中で一番退屈な部分だ。

• 自分がコードを書いて、AIにレビューさせる：これが一番バランスがいいと思う。速くはならないけど、品質は上がるはず。AIはレビューが得意で、人間が見落とす問題をよく見つけてくれる。量より質を求める解決策だね。コードだけでなく、特に顧客向けの財務報告書のような、ミスの許されない文書作成には重要だと思う。

• AIに解決方法を指示する：書くのはAIだけど、より密にこちらがガイドする。自分は大抵これに行き着く。これが一番いいコードになると思ってる。コードの内容をより深く理解できている実感があるし、もっと大規模なコードも扱える。AIの挙動は逐一チェックして、提案や前提が間違っていれば言い返す。スピードと品質のバランスとしては悪くない。

• フルエージェントモード：全部AI任せにして、複数のエージェントを同時に走らせる。制御もメンタルモデルも失う。AIがやっていることを信じるしかない。正解することもあれば、そうでないこともある。そのコードを自分で二度と触らなくて済むことを祈るしかない。でも、確かに速い。

Warpで2〜5個のタブを開いてる。iterm+tmuxをうまく使ってBoris Chernyみたいな体験をしたいんだけど、設定をいじってもtmuxでスクロールバックが壊れたり、コピペがうまくいかなかったりと問題があって……。

必要に応じてタブごとにgit worktreesを使い分けてるよ。

あと、git pushのフックでコードのdiffを複数の先端モデルにセキュリティ監査させてる。FAIL/CLOSED条件付きで、両方のモデルがOKを出さないと通らないようにしてある。

また、コードの短縮や不要なコメント、過剰な例外ハンドリングの削除などをAIに要求する工程も入れてる。これで大体コードが半分になるし、このプロセスは再現性がある。

基本はClaude codeかcodexを、プラグインを最小限にして使ってる（HUDとかfrontend designくらい）。もしトークン数や処理速度が10倍か100倍あればもっと活用できるんだけどね。マルチタスクをしていても、Claude 3.5やFable 5の処理待ち時間が長くて……。

その待ち時間を使って、詳細なフォローアップや関係ないプロンプトを書き込んだりしてるよ。