Codex 爆発後に学んだ 5 つのエンジニアリングの教訓

最初の現実のシナリオ: プロトタイプから本番環境まで、Codex コードが突然「メモリを失う」

昨年の夏、私は Codex を使用して API 呼び出しコードを自動的に生成する内部ツールのプロトタイピングに取り組みました。最初の 2 週間の結果は驚くべきものでした。Codex は、自然言語記述に基づいて実行可能な Python スクリプトを直接出力でき、コーディング時間を約 60% 節約できました。しかし、このプロトタイプを製品化しようとすると、問題が発生しました。同じプロンプト ワードで、Codex は構文エラーを生成し始め、主要なパラメーターを省略し、さらには存在しない関数を作成しました。最も壊滅的なのは、requests.post がまったく存在しない requests.send と書き込まれていたことです。半日丸々デバッグに費やし、最終的にそれがコンテキスト オーバーフローであることを発見しました。Codex のコンテキスト ウィンドウはわずか 8K でした。プロジェクトのコードと会話履歴が一定の長さに蓄積されると、最初に合意された API の詳細を「忘れ」始めます。

このシーンを見て、Codex は「コードを書く人 AI」ではなく、「ローカルのコンテキストに基づいてコードを推測するエンジン」であることに気づきました。出力の品質は、提供する情報の鮮度と正確さに大きく依存します。

私の判断方法を変えたいくつかの結論

このプロジェクトを完了した後、私は「Codex がエンジニアの代わりになれる」という幻想を完全に捨てました。 3 つの重要な結論:

1. Codex はローカル パターン マッチングには優れていますが、グローバルな一貫性には不向きです。 5 行で美しい関数を記述できますが、プロジェクト全体で変数の名前付けとエラー処理スタイルが統一されることは保証できません。同じタスクの異なる部分に複数のプロンプトを与えると、矛盾した結果が生じる可能性があります。
2. コンテキスト管理と迅速なエンジニアリングは厳しいしきい値です。 「要件を明確に書く」ほど簡単ではありません。コンテキスト サイズを積極的に制御し、タスクをセグメント化し、注釈を使用してキー制約をアンカーする必要があります。このステップが適切に行われない場合、Codex 出力はガベージになります。
3. テスト容易性と再利用可能性は 2 つの異なる次元です。 Codex 生成されたコードは多くの場合テスト可能 (単体テストに合格可能) ですが、再利用は困難です。完全な関数を小さな構成可能なモジュールに分割するのではなく、一度に生成する傾向があります。ロジックを変更する必要がある場合、多くの場合、関数全体を書き直す必要があります。

遭遇した落とし穴と修正計画

** 落とし穴 1: コード レビューを Codex に過度に依存する**。私が書いたコードを Codex にレビューしてもらえば論理エラーが見つかるだろうと思っていましたが、実際には存在しないバグが「でっち上げ」られたり、実際の境界条件が無視されたりすることがよくありました。たとえば、ファイル読み取り関数をレビューすると、Codex には「例外処理がありません」と表示されますが、実際のコードには明らかに try-except があり、コンテキストは認識されません。

訂正: Codex はスタイルのチェックと名前付けの提案にのみ使用してください。ロジックのレビューは手動または専用の静的解析ツールに依存する必要があります。

ピット 2: Codex 出力をコード ベースに直接送信します。あるとき、Codex によって生成された並べ替えアルゴリズムはテスト データでは完全に機能しましたが、None を含むリストを入力するとクラッシュしました。テストデータが NULL 値の状況をカバーしていないためです。

訂正: 必須の事前チェックリストを作成します:

• 入力境界チェック (空、極値、特殊値)
• 既存コードとのインターフェース互換性チェック（関数シグネチャ、戻り値の型）
• エラー処理の整合性チェック (すべての例外パスが処理されているか?)
• パフォーマンスのベースライン比較 (生成されたコードは元のソリューションよりも 2 倍以上遅いですか?)

ピット 3: グローバルな変更が必要な場合は、Codex を使用してバッチ再構築を行います。 Codex を使用して、プロジェクト内のすべての print を logging.info に変更したいと考えています。その結果、変更の半分でコンテキストがオーバーフローしますが、後半は変更されず、コンパイルが失敗します。

訂正: リファクタリング タスクは小さなステップに分割する必要があり、一度に 1 つのモジュールのみを変更し、各変更後に CI 検証を使用する必要があります。 Codex に一度に 5 つを超えるファイルのコンテンツを与えることは禁止されています。

最初に従うべき最も価値のある手順: Codex 出力プリフライト リストを作成する

Codex をワークフローに統合しようとしている場合、最初のステップは、さらなる機能を追求することではなく、厳密な 出力プリフライト チェックリストを確立することです。私のチームは現在、次のチェックリストを使用しています。

• コードにはハードコーディングされた機密情報 (API キー、パスワード) が含まれていますか? ——Codex はトレーニング データからキーを「記憶」することがあります。
• 未定義の依存関係や関数はありますか? -- import チェックを実行して、すべての外部呼び出しが明示的にインポートされていることを確認します。
• 例外処理は、ドキュメントに記載されているすべてのエラー タイプをカバーしていますか? ——APIを調整する際は特に重要です。
• 既存のコードのスタイル ルール (PEP 8、Go fmt) と一致していますか? —— Codex に依存せず、リンターを使用して自動的にチェックします。
• 単一のテスト カバレッジはプロジェクトの要件を満たしていますか? ——Codex 生成されたコードには、エッジケースのテストが欠けていることがよくあります。

このリストをチーム Wiki の最初のページに記述し、Codex によって生成されたコードを送信する前に各項目を渡す必要があります。面倒に思えるかもしれませんが、これでオンラインでの事故の 90% を防ぐことができます。

いつ投資を継続し、いつ路線を変更する必要がありますか?

シーンへの投資を継続:

• タスクは、データベース CRUD、API カプセル化、データ変換スクリプトなど、反復的な固定モード コーディングです。
• 安定した明確なプロンプトを提供できます。コンテキストは 4K トークンを超えず、コード ベースには統一されたコーディング標準があります。
• チームは、Codex エラーを迅速に発見して修正するために、事前検査およびテストのプロセスを確立しました。

ただちにルートを変更するよう合図します:

• Codex で文法エラーまたは意味エラーが頻繁に発生するようになり、プロンプトの単語を変更しても問題は改善されませんでした。これは通常、コンテキストがウィンドウの外に出たか、タスク自体が複数のファイルを理解する必要があることを意味します。
• 入出力には、支払いやセキュリティ認証を伴うコアロジックなど、厳密な一貫性とバージョン管理が必要です。
• Codex によって生成されたコードを保守する方が、コードを手動で記述するよりも時間がかかることがわかりました。これは、生成されたコードが理解しにくく、変更されるたびに書き直す必要があるため、コードを頻繁に変更する必要があるシナリオでよく発生します。

実際の意思決定のケース: 私の同僚は Codex を使用して WeChat 支払い統合モジュールを生成しました。最初の生成には 2 時間かかりましたが、その後の支払いインターフェースの変更により、Codex の再生成には 4 時間かかり、まだ発見されていない署名エラーが存在しました。最終的に彼は手書きで書くことに決めました。これにかかる時間はわずか 6 時間で、その後の修正も容易になりました。

概要

Codex は強力なコード補完ツールですが、その機能は見た目よりもはるかに限定的です。ローカルでパターン化された、コンテキストが安定したタスクにのみ適しています。本当のエンジニアリングの価値は、Codex にさらにコードを書いてもらうことではなく、Codex の出力を安全に実装できるプロセスを確立することにあります。 Codex をチームに導入することを検討している場合は、まずそのプリフライト チェックリストを作成してください。

次に、エージェント エンジニアリングにおけるコンテキスト管理、プロンプト エンジニアリング、評価戦略を体系的に習得したい場合は、高品質のオリジナルの有料記事と AI の高度なプログラミング コースに注目してください。