2025年初、私たちのプラットフォームチームが各リポジトリにAIコーディングアシスタントを採用した時、生産性の向上が期待された。私が予想しなかったのは、最も価値のある教訓が成功ではなく失敗から来るということだった。約4,200件のマージされたプルリクエストをレビューし、AIがコード作成において意味のある役割を果たしたケースを確認した後、現れた像は私が読んだほとんどのマーケティング資料と矛盾していた。この技術の背後にある経済的動きは否定できない、ただ6440億ドルのAIインフラへの投資が硅谷とその先の資本の流れを変革しているが、これらのツールを使って生産ソフトウェアを送る日々の現実は、キーノートプレゼンテーションが示す以上に混沌としており、より細やかで、結局のところより面白い。これが私たちが学んだこと、変えたこと、そして始める前に誰かが教えてくれていたかったことを。

生産性の数字は本物だが、誤解を招いている

私たちの内部テレメトリデータによると、AI支援が標準的な慣行になった後、個々の開発者が行ったコードの量が行数で26％から55％増加しました。これは明確な勝利のように聞こえますが、限られた文脈ではそうです。ボイラープレートの生成、テストの骨組み、APIクライアントのラッパー、日常的なリファクタリングは、数時間から数分にまで短縮されました。私たちのチームの若手エンジニアが、従来のワークフローでは6週間かかっていた古いETLパイプラインを3日で書き直しました。

しかしコード量は正しい指標ではなく、ほぼすぐにそれを知っていました。4ヶ月目には、前年比でインシデント率が31％上昇しました。リバートは増え、解決までの平均時間は長くなりました。アフターポストモアムを掘り下げると、パターンが現れました：回帰はほとんどAIが生成したコード自体の破壊的なバグではありませんでした。それは微妙な統合失敗、モデルが知ることのできないエッジケース、そしてローカルで動作するがシステムの他の部分で無記名の規約を違反する提案を受け入れることで蓄積された複雑さでした。

METRによる広く配布された研究によると、慣れ親しんだコードベースを扱う経験豊富な開発者は、AIアシスタントを使用していると実際に19％遅くなり、20％速くなると信じていたにもかかわらず。METRのAI開発者生産性に関するランダム化対照試験の結果 は、成熟したサービスのメンテナンスから緑地の作業を分離した後、私たちが観察したデータと一致しました。生産性の話は完全に文脈に依存し、AIが輝く文脈は、大多数のシニアエンジニアが時間を費やす文脈ではありません.

チェックリストのボトルネック：私たちに警告されなかったもの

AIの採用が私たちに強いる最も大きな運用変更は、コードレビューの完全な再構築だった。開発者が20分で800行の見かけ上の合理的なコードを生成できるようになった時、ボトルネックはすぐにそして永続的に、それをレビューしなければならない人に移った。私たちのシニアエンジニアたちは3ヶ月以内に疲弊し始めた。レビューキューは成長し、PRsは数日間放置された。人々は変更をスタンプで押すようになり、その量が慎重なレビューを不可能にしたからだ。

最終的に、私たちはワークフローを逆転させることでこの問題を解決しました。著者は現在、5分以内の録画動画で、AI支援による変更について審査者に案内する必要があります。コードが何をするのか、なぜこのアプローチが選ばれたのか、そして手動でどのように検証したのかを説明するのです。動画の要件は官僚的に聞こえるかもしれませんが、2つのことを成し遂げました。著者に生成したコードを実際に理解させることで、危険な知識のギャップを閉じたのです。また、審査者に時間を尊重する出発点を与えたのです。審査の速度は6週間以内に回復し、マージされたコードの品質も測定可能なほど向上しました。

実際に効果的な方法

1年間の実験の後、AIツールの恩恵を受けるチームと、その出力に溺れるチームに分かれた数少ない実践があった。これらは革命的なものではないが、一貫して適用するために必要な規律が、実際の区別となった。

生成前の厳格な仕様の方が、プロンプトエンジニアリングの技巧よりも重要です。アシスタントを呼び出す前に詳細な受容基準、型シグネチャ、例入力を書いたエンジニアは、自然言語で意図を説明したエンジニアよりも劇的に良い結果を得ました。このモデルは文字通りの意思疎通を重視する協力者です。曖昧な指示を与えると、しばしば自信を持って曖昧なコードを生成します。

テストファーストのワークフローは、どのような非 trivia の変更においても不可欠になりました。実装を生成する前にテストを書くことで、型システムが単独で行っていたことを達成します：検索空間を制限し、出力が正しいかどうかの客観的なサインを提供します。このステップをスキップしたチームは、本番環境で静かに失敗する可能性のあるコードをデバッグすることに終わりました。

建築の境界でのAI支援と強制された人間のチェックポイントの組み合わせは、無秩序なシステム設計へのゆっくりとしたずれを防いだ。サービス境界を越えるコード、新しい公開APIを定義するコード、または認証や認可ロジックを変更するコードを書くには人間が必要である。この領域ではモデルは提案することはできるが、作成することはできない。このルールだけで、それを導入しなければ出荷されるはずだったいくつかの危険なケースを防いだ。

可観測性への投資は何度も利益を生みました。あなたのリポジトリ内のすべてのコードの起源を完全に信頼できない場合、生産環境で問題を迅速に検出できる必要があります。私たちは今年の後半、トレース、構造化ログ、アラートに関する支出を倍増しました。コストは大きかったです。それをしない場合のコストは破滅的でした.

突然価値が高まったスキル

一年間にわたってチームが適応していく様子を見ることで、AI支援環境においてどの工学的スキルが複合的に発揮され、どのスキルが減退するかが明らかになりました。これは、強い開発者とは何を構成するかについての長年の前提を逆転させる光景でした。

コードを慎重に速く読むことがチームで最も価値のあるスキルになりました。300行の差分をスキャンして不審なブロックを二つ見つけられるエンジニアは、単にテストに頼るエンジニアの十倍生産的でした。デバッグスキルも価値を得ました。なぜなら、AIが生成したバグは通常、標準的なトラブルシューティングのヒューリスティクスに抵抗する、見慣れない形で現れるからです。

システム設計とアーキテクチャの判断はより重要になった。モデルはお求めの個々のコンポーネントを生成することができるが、実際のシステムが必要とするコンポーネント、それらがどのように相互作用するべきか、あるいはどのトレードオフが価値があるかを教えてはならない。成功したエンジニアは、ある全体のシステムを頭の中に保持し、AIを一貫した全体に合う実装の方向へ導く人々だった。

逆に、APIの構文を覚えること、フレームワークの慣用句を暗唱すること、あるいはボイラープレートを素早くタイプすることの能力は、一瞬でほぼ無価値になった。これらのスキルを自分のアイデンティティの基盤と築いてきたエンジニアたちが最も大きな適応の難しさを感じた。これらをソフトウェア構築の本質的な作業の余分なものとして扱ってきたエンジニアたちは、変化にほとんど気づかなかった

私が過去の自分に伝えたいこと

もし私が2025年1月にこれらのツールをリリースしていた自分に一つのメッセージを送れるなら、それはこうだ：技術は難しい部分ではない。難しい部分は、根本的に異なる生産機能を中心に、あなたのチームのレビュープロセス、品質基準、スキル開発経路を再構築することだ。この変革を勝ち取るチームは、最良のモデルや最も賢いプロンプトを持っているチームではない。AIアシスタンスを真剣な組織的変化として扱い、それに応じた投資をするチームだ。他のすべての人は、誰も完全には理解できないコードをより多くリリースし、伝統的なリファクタリングでは償えないような種類の負債を蓄積し、そして最も悪い瞬間に何か重要なものが壊れたときにそのコストを発見する。