Traeデバッグツールのループが頭打ちになる地点
ソースコードからデバッグするエージェントは、読む・考える・編集することはできますが、観測することはできません。観測を提供しているのはあなた自身であり、それも記憶に頼った文章としてです。この経路は狭く、あなたが気づいたことだけを運び、関係ないと判断したものを落としてしまいます。そして落ちた部分こそが重要であることは少なくありません。
頭打ちは、あなたの説明から立てられる仮説をエージェントが出し尽くしたときに訪れます。入力が改善されていない以上、ラウンドを重ねても状況は変わりません。
この影響を特に受けやすい3種類のバグ
タイミング
データが届く前に描画が走る、あるいはコンポーネントが消えた後にリクエストが完了する。
差分を見ても分かりませんが、実際に動く様子を見れば一目瞭然です。
残留した状態
何かがリセットされていないために、1回目の操作は成功し、2回目は失敗します。
まっさらな状態から始める再現手順では、決して現れません。
環境の不一致
コードは正しく、環境のほうが食い違っています。変数の欠落、古いキャッシュ、異なるデータといった具合です。
エージェントは、そもそも壊れていないコードを修正し続けます。
観測のステップを追加する
自分が見たものを説明する代わりに、デプロイ済みのアプリケーションを実際に動かし、何が起きたかを報告させます。そうすればエージェントが受け取るのは、記憶ではなく記録になります。何を試したか、アプリが何をしたか、どこで両者が食い違ったか、という記録です。
セットアップによってその能力がエージェントに組み込まれ、あなたが伝えるのを待つのではなく、自ら証拠を生成して読み取れるようになります。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、TestSpriteのダッシュボードからも同じセットアップを利用できます。CLIのその他の機能については、以下を参照してください: CLIリポジトリ。
頭打ちを破る2つの問い
まっさらな状態から始めても失敗しますか？ 失敗するならロジックの問題です。2回目以降だけ失敗するなら残留した状態が原因であり、ここまでのコードレベルの仮説はすべて見当違いだったことになります。
別の環境でも失敗しますか？ 同じビルドが2つの場所で異なる挙動を示すなら、コードの編集は止めてください。環境どうしの差分こそがバグです。
どちらも低コストで答えが出せ、その答えが意外なものであれば、セッション全体の方向が変わります。
修正後も再現手順を残す
バグを目で見るために作ったケースは、その再発を止めるチェックになります。会話とともに削除せず、変更のたびに実行してください。
重要なのは仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かが判断しなくてもすべての変更がチェックされます。ダッシュボードから設定する GitHub App がその役割を果たし、ワークフローの内側で実行する GitHub Actions のステップでも同じことができます。
エージェントが似たような修正案を出し続けるのはなぜですか？
入力が変わっていないからです。新しい観測がなければ、言い回しを変えながら同じ仮説空間を探り直すことしかできません。
ログをもっと貼り付けるべきですか？
情報は多いほど役立ちますが、ログが示すのはコードが下した判断であって、ユーザーが体験したことではありません。実際のアプリケーションに対して実行することで、ログが残す空白を埋められます。
これはTrae特有の問題ですか？
いいえ。ソースコードからデバッグするエージェントは、どれも同じ死角を抱えています。ワークフローは異なっても、欠けているステップは同じです。
安定して再現できない場合はどうすればよいですか？
その断続性そのものが発見です。同じケースを何度か実行して比較してください。4回に1回失敗するフローはタイミングか状態の問題であり、それだけで調査範囲は大きく絞り込まれます。
修正は別途検証する必要がありますか？
はい。同じ推論によって提案され、そのまま確認された修正には、独立した証拠がありません。修正後の挙動は、何かが実際に観測する必要があります。