AI コーディングが人気になってから、私は5つの工学の教訓を学びました

AIがコードを生成する実際の現場と初めて遭遇

昨年、私はレガシーなSpring Bootマイクロサービスを引き継ぎ、内部ユーザー認証モジュールをOAuth 2.1に移行する必要がありました。 チームは3人しかおらず、期間は3週間でした。 当然のことながら、AIプログラミングツール(カーソル+GPT-4)を使って作業を速くしようと思いました。 最初は順調に始まりました。AIは新しい認証フィルター、トークン保存層、構成クラスを生成し、合計約800行のコードでルート、例外処理、テストをカバーしました。

しかし、統合テスト中に問題が発生しました。AIがSecurityFilterChainの設定と2つの@Order注釈が競合し、一部のAPIエンドポイントが認証を回避する原因となりました。 さらに隠されたのは、JwtAuthenticationConverterのヌルポインタで、AIは欠けているclaimsフィールドを扱いません。 これら5つの問題を解決するには、手作業で書くよりも時間がかかりました。なぜなら、まず自分自身AIの「思考」を理解する必要がありました。習慣的にOptionalを使いますが、必ずしも一貫しているわけではありません。

このシーンで気づいたのはこうです。AI コーディングの最大の落とし穴は、コードを書けないことではなく、書かれたコードを直接信頼できると誤って信じてしまうことです。

4 判断のあり方を本当に変える結論

**まず、コードレビューはスキップできませんが、レビューの対象が変更されています。 ** 以前、同僚コードのレビューを行い、論理とスタイルに焦点を当てました。 次に、AIコードをレビューし、境界条件、例外パス、既存システムとの暗黙的結合に焦点を当てます。 AIは「見た目が正しい」コードを生成するのが非常に得意ですが、しばしばnull、アウトオブバウンズ、タイムアウトなどのコーナーを見逃しがちです。 後のアプローチはこうです:AIコードをマージするたびに、3種類の質問を具体的にチェックしました。1) すべての入力および出力パラメータに対する非零仮定; 2) すべての分岐条件に対するデフォルト挙動; 3) すべての非同期操作のタイムアウトおよび再試行。

**第二に、移行タスクは段階的に置き換えるべきであり、完全に書き直すべきではありません。 ** OAuth移行中に私が犯した最大のミスは、AIにモジュール全体の置き換えコードを一度に生成させたことです。 より良い方法は、まずAIに新旧認証の両方に対応した「プロキシフィルター」を生成させ、徐々にトラフィックを削減させることです。 各ステップはロールバックポイントとして古いコードを保持します。 この教訓を学ぶのに2日間残業しました。

**第三に、プロンプト構造は出力の品質に直接影響します。 ** 単に「OAuth 2.1構成を生成する」だけではありません。 後に3つの課題を修正しました:1) 問題の文脈(フレームワークのバージョン、既存の構造、制約)を明確にすること; 2) 特定の出力フォーマット(クラス名、メソッド署名、コメントスタイル); 3) 避けるべき落とし穴(例えば、非推奨APIを使用しないことや新しい依存関係の導入など)。 効果が大幅に向上し、エラー率は少なくとも40%減少しました。

**第四に、AIは「0から1」に適しており、「1から0.9」よりも適しています。 ** プロトタイプ、足場構築、デモコードはAIの強みであり、 しかし、既存のシステムに細かい修正を加える必要がある場合、AIは既存の論理を簡単に壊してしまいます。 今は使用シナリオを分離しています:新機能プロトタイプはAIを使用し、既存の修正は手動のままです。

踏み越えた落とし穴、そして修正された道

最大の落とし穴:**AIで生成されたコードに対して独立したテストレイヤーが設定されていません。 ** 私は直接AIにコードを生成させ、既存のテストスイートで実行させます。 しかし、AIによって生成されるコードは、既存のテストではカバーされていない特別なモックデータや設定を必要とすることが多いです。 その結果、テストは合格しましたが、統合は失敗しました。 解決策は、ai-generated/ディレクトリを作成し、まずそのディレクトリにすべてのAIコードを配置し、独立したユニットテストと統合契約テストを作成し、それらをパスした後にメインコードベースに統合することです。

もう一つの落とし穴:**過度な信頼AI「説明」 ** 「なぜこれをするのか?」と尋ねると、AIは合理的に聞こえる理由を提示しますが、時にはそれが幻想です。 AIが@Transactionalの伝播挙動を説明する際、その推論は古いSpring 5の挙動に基づいており、プロジェクトはSpring 6のJakartaネームスペースを使用しています。 今は公式書類を確認するか、AIを同時に引用してもらう必要があります。

もし似たような仕事をしているなら、最も価値のあるステップはまずコピーすることです

**「AIコードアクセスチェックリスト」を設定し、AIからコードを受け取った後、以下の項目を手動で確認してください。

1. すべての外部入力(パラメータ、環境変数、設定ファイル)のデフォルト値は妥当か?
2. すべての例外パスは飲み込まれますか?(空のキャッチブロックやログは復元されません)
3. すべての非同期通話にはタイムアウト設定がありますか(特にネットワークリクエストの場合)?
4. 生成コードがプロジェクトにない新しい依存関係を導入しませんか(インポートとビルドファイルを確認してください)?
5. コードスタイルはチームの既存の標準(インデント、命名、コメントパターン)に準拠しているか?

モニターの隣に全チームメンバーのリストを貼っておきました。 使用から2週間でオンライン失敗率は約35%減少しました。

いつ投資を続け、いつ方向を変えるべきか

継続的な投資条件:**アクセスリストを通過した後、AIによって生成されたコードを見ると、手書き量の30%未満の修正量が記載されています。 ** もしあなたのシナリオが新しいモジュールの作成、サンプルコードを書く、テストケースの作成、SQLやスクリプトの生成であるなら、これらはAIの快適な領域であり、使い続けてもよいでしょう。

ルート変更のシグナル:**AIコードを書く時間の2倍以上を修正するか、3つの新しいバグを引き起こす1つのバグを修正してください。 ** 例えば、OAuthの移行中に設定のデバッグAIに4時間費やしましたが、最終的には諦めて1.5時間かけて自分で書き直しました。 このシナリオは、現在のタスクがAIの能力境界を超えていることを示しており、多くの場合、レガシーシステム、複雑なコンテキスト依存関係、または非標準的な構成が関わっています。

他に明確に止めるべき状況が2つあります。1) AI(複雑なラムダチェーンや抽象的なブリッジパターン)によって生成されるコードロジックが理解できないこと; 2) AIによって生成されたコードには、完全にテストできない外部依存関係が含まれています(例えば、モックせずにサードパーティAPIを直接呼び出す場合など)。 現時点では手動で実施する方が安全です。