我々はこうコーディングする！

エージェントは常に自信満々です。バイブコーディングでも、トークンマキシングでも、その出力はスロットマシンと変わらず、成功でも失敗でも関係なく、膨大な量の計画とコードを吐き出します。ここで本当の問題は、計画や実装の失敗ではありません。エージェントが人のレビューできる量を超えて吐き出すこと、そしてそれを放置するほど、すべてが少しずつ壊れ始めることです。

人が壊れる。 結局、AIの過剰な出力は人を二つの選択肢へと追い込みます。読むのを諦め、どうにかなるという妄想の中で、無責任なバイブコーディングが積み上げた技術的負債と脆弱性に自滅するか。あるいは、すべての計画、すべてのコード変更に追いつこうとして過負荷に直面し、心身を壊すか。エージェントは人の都合など気にかけないため、人間が消化できるチェックポイントを用意してはくれません。

プロジェクトが壊れる。 制御されない出力が積み上がるほど、次のセッションがそれを学習し、複雑さは指数関数的に増していきます。こうして悪循環が始まります。エージェントにさらに多くの場当たり的な対応を強い、トークンの消費量はいっそう増え、そこから派生した問題を片づけるために、より多くのイテレーションを浪費させます。やがてプロジェクトは、予算もスケジュールも守るのが難しくなっていきます。

世界が壊れる。 すべてのAIコンピューティングは実際のハードウェア上で動きます。「もっと多くのコンテキスト、もっと多くの再試行」は、コンピューティングと電力、水を音もなく虚空へ注ぎ込みます。誰も集計しない費用は無料のように感じられるため、人々はためらいなくさらに浪費し、世界はいっそう蝕まれていきます。

naholoの助け方

naholoは、体系的にレビューできるチェックポイントを導入し、あなたとエージェントがより効率的に、そしてストレスなく開発できるよう支えます。naholoは次のようなチェックポイントを提供します。

• WARNING ORDER (準備命令, /warno) : 概念的・アーキテクチャ的な判断をレビュー／修正できます。
• OPERATION ORDER (作戦命令, /opord) : WARNING ORDER をコミット一つ分（一般的に5ファイル以内）のタスクに刻み、コードレベルの変更ではなくモジュールレベルの契約に集中してレビュー／修正できます。
• After-Action Report (事後報告) とコード変更（/splash） : タスクがどのように実装されたか、計画から外れた箇所はどこかを確認できます。前の段階でモジュール単位の契約がすでにレビューされているため、コードレビューは簡単かつ迅速に行えるはずです。

作戦が終わると、/exfil によってその作戦で使われたエージェント使用統計がアップロードされ、実際の数値をもとに計画と開発プロセスを改善できます。