AIプログラミングのこの波では、概念が飛び交い、ツールは毎日のように名前を変えるが、根っこはそこまで玄学（げんがく）でもない。
Agentは魔法ではなく、本質は不安定なLLMに「構造化された制約」（Harness）を一枚かぶせて、出力をより制御可能にすることだ。Claude CodeやCodexもこの路線。
1）まずLLMを見抜く：ただ次のTokenを推測しているだけ
これを理解すると、多くの「玄学問題」は玄学ではなくなる。
コンテキストをどう与えるかで偏り、どう誘導するかで進む方向が決まる。
だからプロンプトが「フォーマット崇拝」から「自然な表現」へ向かうのは必然だが、問いの立て方は依然として硬い実力だ。
2）Promptは無用になったのではなく、「誘導を減らし、フィードバックを重く」すべき
- いきなり解決策を詰め込まず、まず現状と目標を伝え、モデルに視点を出させる；
- 問題主導で反復：結果を見る → 間違いを指摘 → 指示を書き直す → 新しい会話で検証；
- キーワードを固定しすぎると、かえってモデルを溝に連れていきやすい。
一言で言うと：経路のコントロールは少なめに、結果の検証は多めに。
3）AGENTS.mdは重要だが、「緊箍咒（きんこしゅ）大全」にするな
コミュニティにある超長文の「必須/禁止/原則」は、ほとんどがノイズだ。
制約を詰め込みすぎても、たいてい安定するのではなく鈍くなる。
グローバル指示がやるべきなのは、境界とツール説明であって、文体の調教ではない。
4）「新しい用語マーケティング」に引きずられるな
RAG、Context Engineering、MCP、Skills……
多くは旧問題の新しい包装か、Promptの規格化に過ぎない。
追うべきは「言葉」ではなく、本当に摩擦を減らし、デリバリーまでの道のりを短くできるかだ。
5）並行開発には上限がある：2タスクが大多数の限界
3〜4つのAgentを走らせると効率的に見えるが、実際は脳のキャッシュが爆発する。
通知が鳴り続けるのはフローを切って、「自分は忙しい」という錯覚を作るだけ。
おすすめ：通知は切って、能動的に進捗を確認する。
通知に受動で反応する＝リズムに支配される；能動的に巡回する＝自分がリズムを掌握する。
6）ファイルが記憶：コンテキストを「頭」から「ファイルシステム」へ移す
CLI Agentはテキスト検索のロジックにより依存する。
Agentを安定させるのは祈りではなく、検索可能で再利用できるプロジェクトドキュメントだ。
ファイルは最終実行に向けて書き、過程のゴミを詰め込まない。
本質は、モデルのコンテキストと注意力の先天的な弱点を補うことだ。
7）プロセス簡略化：先に計画、次にコーディング
今の2ステップは実用的だ：
- 何度も議論して計画を固める（PLAN / plansディレクトリ）
- 最終計画に沿ってコードに落とし込み、実装ドキュメントを蓄積する（docsディレクトリ）
計画ファイルはアンカー、コードは成果物。
8）結果志向：「優雅な過程」より「検証可能なデリバリー」を見ろ
「Agentに手取り足取りでコードを書かせる」から「自分は方針と受け入れ基準を管轄する」へ。
途中の小さなミスは急いでつつかず、レビュー段階でまとめて直す。
コード品質は感情で判断するのではなく、テストと追跡可能な構造で担保する。
核心目標は一つだけ：It just works.
9）マインドセットを更新：実行者から管理者へ
Codexは「外部脳＋ラバーダック（小黄鸭）」として使う：あなたは問題分解、基準設定、トレードオフ判断を担当し；
それは大規模実行を担当する。
Agentを神扱いするな、玩具扱いするな——それは増幅器であり、あなたの判断力も、あなたの混乱も増幅する。
10）誤った実践の教訓
- 盲目的に「長時間 autonomous 実行」を追っても意味は薄い；
- 本当に価値があるのは、人手介入を減らし、安定デリバリーの確率を上げること；
- 他人のPrompt/Skillsを丸写しすれば立ち上がりは速いが、あなたのプロジェクトに適合するとは限らない；
- 最も効果的な成長ルート：実行プロセスを見張り、失敗の根因を見つけ、自分の方法論を反復する。
