AIとの作業で頭がパンクする問題を、gitで管理する「優先度キュー」で解決した
How I Fight AI Brain Fry
Claude CodeやCodexをターミナルで使うと、返信待ちの間に別のタスクを始めて20本ものスレッドを頭のRAMに抱え込む羽目になる。著者はこれを「順序」と「コンテキスト」の問題と捉え、チケットをmarkdownファイルとしてコードと同じリポジトリに置く仕組みを作った。エージェントがサイクルごとに調査・ビルド・検証を回し、人間の判断が必要な項目だけが優先度付きリストで届く。1件ずつ開いて判断し、キューに戻して閉じる——この「閉じる」動作が集中力を守る鍵だという。
その「閉じる」という行為こそがすべてのコツだ。チケットは「覚えておくべきこと」として私の記憶にぶら下がり続けることはない。コンテキストも一緒に閉じられる。
HNでの議論
207- eterm
あまり多くを同時にこなそうとせず、たとえ「アイドル」状態でも以前より生産的であることを受け入れるように学んだ。休憩を取り、充電し、リフレッシュし、振り返る時間は重要だ。
だから一度に最大2つか3つのことに制限している。もしそれらがすべて長時間のセッション中なら、まあ仕方ない。すぐにまた深く戻れると分かっているから。
でも「もう1セッションだけ」始めたくなる誘惑がある。特にプロファイリングを改善してパフォーマンスを向上させるようなことだ。それは超生産的に感じるが、しばしば「アイドル」を感じないようにするためだけだったりする。
- sollewitt
これは問題の一部を解決するだけだ。残りの半分はこうだ：よし、3つのチャットを進めていると、ある時点で3つの1万行を超えるCLをレビューしなければならないことに気づく。しかも同僚からレビューを頼まれているコードもある。
これまで行ったすべてのレビューで、過学習や脆い解決策、統合ではなく付け足されたものを発見してきたので、コードレビューを諦める気はない。しかしそれが本当のボトルネックであり、3つあるのは1つよりずっと悪い。私のコンテキストと理解が薄まり、少し混乱するからだ。
コードを着地させるまでの時間を計測したい。直列で1つずつ進める方が、複数を並行して進めるより速いのではないかと疑っている。並行は速く感じるが、コードレビューに時間がかかる。
- docheinestages
そもそもなぜ複数のスレッドを並行して始めるのか？待ち時間が問題なら、その1つのタスクを複数のステップに分割すべきかもしれない。そうすればより低い品質でより多くの出力が生まれるだけだ。人間の思考能力は何も変わっていない。1つのことに集中してやり遂げよう。
- hetspookjee
私もこの種のフォーマットを試したが、セッションが提供してくれる豊かなコンテキストが欠けていて定着しなかった。具体的には、HTMLファイルで可能な図やその他の素敵なフォーマットがないことだ。しばらくLinearを間のブローカーとして試したが、すぐに爆発してナビゲートが面倒になり、すぐに同期がずれてしまった。トークンのオーバーヘッドも高かった。
現在は、プロジェクトに紐づいた1つまたは複数のエージェントスレッドに作業させ、eleventyを多用してマークダウンファイルとしてレンダリングする、トークン消費の非常に少ないスキルを用意している。それとthisbit.ai（私が作り、まだ開発中）を組み合わせて、記事のすべてのビットにコメントや音声を付け、エージェントにそこから再び引き継がせている。
また、codexもClaude codeも、Gemini（Argon 4）の素敵なTUIレンダリングには全く及ばない。
- silcoon
問題はコンテキストスイッチングだと思う。「AIのおかげで3つの異なるタスクを同時に進められる」というのは本当に力強く感じられるが、現実には数分ごとに思考プロセスが中断されるなら、1つのタスクに深く集中することは不可能だ。
画面の前でアイドル状態になっていると、エージェントが注意を必要とする通知を送るまでの54秒を埋めるために、何か別のことを見つけなければ、気を紛らわせるものを探さなければと感じる。これは健康的ではないし、人間の脳の働き方でもない。
長く中断のない深い集中のセッションこそが、これまで人間が最高の仕事を生み出す助けとなってきた。
- gb2d_hn
みんながこの新しい問題の世界に対する自分なりの解決策を構築しているのを見るのは興味深い。私の場合はマークダウンノートを強化することだった。https://app.etherpk.com を拡張して、すべてのタスク（プレーンなマークダウン）をそのwikilink（複数可）の下でカンバンボードに表示できるようにした。MCPサーバーがノートグラフとやり取りする方法を知っている。タスクへの参照をコピーしてエージェントに渡すと、エージェントはそこからタスクの下のブロックで作業する。つまり、画像やexcalidrawの描画など、本当に豊かなコンテキストを事前にエージェントに与えることができ、エージェントは作業しながらタスクを更新できる。すべてがカンバンボード上にあることで、タスクから離れて本当に注意が必要なものに取り組み、また戻ってくるのが容易になる。これをherdrと組み合わせると非常に生産的だった。脳が焼き切れるのをまだ見守らなければならないが、助けにはなっている。このアイデアを売り込めているかは分からないが、著者が提案しているような様々なシステムを実験した後、何かをつかんだ気がしている。製品化を進めている。オンボーディングはもう少し簡素化する必要があるが、ローカルグラフなら無料で使える。
- AnotherGoodName
私はもうtmuxからエージェントに付属するアプリに移行した。
主な理由は、進行中のワークストリームの概要と、タスクとサブタスクのツリー（エージェントセッションの分岐ツリーを持てる）をそれぞれ独自のセッションとして持てる能力だ。これらのアプリはtmuxセッションにリモート接続もできるので、ワークフローの変更というよりはプレゼンテーションの変更にすぎない。マルチメディアの入出力も良い。
まだ完璧ではないが、未来の開発環境がますますジョブ管理に焦点を当てるようになるのは明らかだ。どんなジョブが進行中か？それらのジョブは互いにどう関係しているか？何があなたの注意を必要としているか？
- plasticchris
インタラクティブな共同テキスト編集が登場したときのことを覚えているかい？
未来はこれだろう。ただしインタラクティブな共同エージェントセッションであり、pi durableのようなものはすでにその方向に向かっている。