Claude Code向けEvanFlow、HNが刺さったのは自動化より制御感

Hacker NewsがEvanFlowに反応したのは、TDDが今さら新しかったからではない。むしろ前提が変わったからだ。コーディングエージェントがコードを書けること自体は、もう多くの人が認めている。次の問題は、それをどう制御するかだ。READMEによれば、EvanFlowはClaude Codeの上に16個のスキルと2個のサブエージェントを重ね、brainstorm → plan → execute → iterate → stop というループを回す。ここで一番大事なのは最後の stop だ。売りは自律性ではなく、止まる構造にある。

設計を見ると、その意図はかなりはっきりしている。EvanFlowはTDDを後工程の確認作業にせず、各コード作業の内部規律として扱う。1つの failing test を書き、最小実装で green にし、そのテストを安全網にしたまますぐ refactor する。大きめの計画では coder-overseer の並列構成に分かれ、実装担当はコードを書き、read-only の overseer は修正せずにレビューだけを行う。さらに設計承認、計画承認、反復後レビューのチェックポイントがある。多くのエージェントデモが摩擦を消す方向へ寄るのに対し、こちらは意図的にブレーキを前面に出している。

HNのコメントもそこを見ていた。懐疑的な側は、Claude Codeの公式スキルでも十分にTDDは回せるので、新しさは大げさではないかと言う。支持する側はラッパーの存在より、そこで強制される規律を評価していた。特に刺さっていたのは、複数エージェントの一番厄介な失敗だ。各ブランチの unit test は通っても、マージした瞬間に境界面が壊れる。そのため touchpoint ごとの integration test を本当の契約として扱うべきだという指摘があった。つまり、見られていたのは機能数より運用の安全性だった。

だからこのスレッドは新製品紹介というより、ワークフロー論争として読まれた。HNが今議論しているのは、エージェントが役に立つかどうかではない。役に立つとして、その先で scope creep や context drift、無責任な自動化をどう抑えるかだ。EvanFlowの魅力は、能力の誇示ではなく、止まる場所を先に決めている点にある。危険なのは能力不足ではなく停止点の欠如だという見方に、HNはかなり納得していた。