私のAIコーディングエージェントが壊れ続けていた理由 — 私が変えたこと

6週間前、私のAIコーディングエージェントはゴミのようなコードを生成していました。

コンパイルは通るものの、何も機能しない関数を書いたり、間違った理由でテストをパスさせたりしていました。一つのバグを修正したかと思えば、新たに3つのバグを生み出していました。

エージェントに問題があると思っていました。しかし、それは間違いでした。問題は、私自身の規律の欠如にありました。

私はエンジニアリング業務の40%でAIエージェントを使用しています。リファクタリング、テスト生成、バグ調査などを任せています。コードベースが乱れていたとき、AIはその乱れを3倍に悪化させました。

AIは規律の代わりにはなりません。AIは、あなたがすでに持っているものを増幅させるだけなのです。

出力を改善するために、私がワークフローをどのように変更したかを以下に示します。

  • テストは状態ではなく、振る舞いを検証しなければならない。 「assert user is not None」のようなテストを書くのはやめましょう。それは嘘をついているようなものです。テストは「assert user.email == expected_email」のように、具体的なデータをチェックすべきです。テストが脆弱であれば、AIはその隙を突いてきます。

  • すべてのdiffを読み込む。 以前の私は、コードを見ずにリファクタリングを受け入れていました。その結果、循環参照や乱れたアーキテクチャを招いてしまいました。なぜその変更がより優れているのか説明できない場合は、拒否してください。

  • 状態を明示的にする。 キャッシュやセッションの扱いをAIに「推測」させてはいけません。これらはプロンプトやスキーマの中で定義してください。推測された状態は、本番環境をクラッシュさせるサイレントバグの原因となります。

  • エージェントによる変更に対して、自分でテストを書く。 エージェントがコードを変更するたびに、まず人間が作成したテストを書くようにしています。これには15分かかりますが、数時間のデバッグ時間を節約できます。

  • 明確な失敗（Loud failures）を求める。 変更がテストをパスしてもロジックが壊れている場合、システムがそれを検知できるようにしなければなりません。「テストが通ったからリリースしよう」という考えを、有効な指標として決して受け入れないでください。

結果：

  • 週あたりのバグ数が5個から1個未満に減少。
  • デバッグ時間が週6時間から1時間に減少。

エージェントは変わっていません。変わったのは私です。

AIエージェントを使用しているなら、まずコードベースを修正してください。テストを改善し、状態を明確にし、レビューを厳格にしましょう。

エージェントは鏡です。増幅させるに値するものを、あなた自身が持っているか確認してください。

Source: https://dev.to/susiloharjo/my-ai-coding-agent-kept-breaking-what-i-changed-4l5f

Optional learning community: https://t.me/GyaanSetuAi