ソフトウェアエンジニアは、自分が書かず、完全に理解もしていないコードをリリースする立場に置かれることが増えています。MetaのエンジニアであるAli Hamieは最近の投稿でこの変化を指摘し、AI生成コードを扱う経験を「ブラックボックス」のように感じると表現しました。この緊張の核心はAIのスピードにあります。モデルは数秒で数千行のコードを生成できるため、従来の行単位の検証という慣行は、AIが提供するはずの速度を損なうボトルネックになりかねません。これにより、エンジニアはすべての詳細を監査するために速度を落とすか、あるいは勢いを維持するためにコードのブロックを「ゴム判子（形式的な承認）」で通すかというジレンマに直面しています。
この画像は、Ali HamieがAI生成コードに関して述べた「ブラックボックス」のジレンマのソースを表している。
この変化を管理するために、一部の開発者は「アーキテクチャ」重視のエンジニアリングへの移行を提唱しています。AIモデルにシステム全体を設計させるのではなく、まず厳格な抽象化とアクターの階層を作成し、コンポーネントがどのように相互作用するかを高レベルで決定してから、実装のギャップを埋めるためにAIを使用することを提案する人々がいます。このアプローチにより、エンジニアはすべての内部ロジックを熟知していなくても、システムの責任範囲のメンタルマップを維持することができます。また、エンジニアの役割はデフォルトで「プリンシパル・エンジニア」へと進化していると主張する者もいます。人間が設計と制約を提供し、AIは詳細を実装するジュニア開発者として機能するのです。このパラダイムでは、主な責任はコードを書くことから、システムを設計し、厳格なテストを通じて出力を検証することへと移行します。
しかし、この移行は長期的な安定性とスキルの保持に関して重大なリスクをもたらします。深い検証なしに高レベルの意図に基づいてコードをリリースする「バイブ・コーディング（vibe coding）」の傾向に対する批判者は、「責任の欠如」を警告しています。もし午前3時にピーク負荷でシステムが故障した場合、確率的なモデルは責任を取ることができません。それをリリースした人間がデバッグできなければならないのです。また、第一原理から構築する基礎を欠くことで、次世代のエンジニアが深いコードレビューを行う能力を失うという「スキルの衰退」への懸念もあります。これらのリスクを軽減するために、多くの実務家は「信頼せよ、しかし検証せよ」というモデルを強調しています。そこでは、徹底的なテストスイート、自動ゲート、そしてAIを構築を支援するシステムの可視化や説明のために特化して使用することに焦点が移り、「ブラックボックス」を安全に管理できる程度まで透明性を確保することを目指します。