計画の曖昧さが技術負債を生むと記事が指摘

問題はタイミングにある。コーディングエージェントがすでにコードを書き始めると、計画に残った曖昧さは、その箇所で読み込んだ狭いコンテキストだけに基づく判断になってしまう。だからこそ、独立した計画フェーズを設け、これから触るコードを読み、主要なツールやライブラリがすでにどう解決しているかを確認し、ドキュメントでは決まらない挙動をテストするよう求めている。

また、計画を真実の源ではなく仮説として扱い、実装中も計画と実際のコードを照らし合わせ続けるよう指示し、計画を書いた後でコードを読むのをやめないようにしている。変更を要所に集約すれば、分岐点ごとに同じ変更を繰り返す必要がなくなり、依頼されていない機能の追加やついでのリファクタリングは避けるべきとする。

繰り返し出てくるテーマは権限だ。修正のやり取りが2巡を超えたら、計画に追記するのではなく全体を書き直す。最終的な関門はユーザーの承認であり、実装中に方針が変わった場合はその時点で再度承認を求めるよう指示している。