9月9日、IEEE Spectrumが「Will Junior Engineers Learn Enough in an AI-First Coding World?」と題した記事を公開した。AIコーディングツールの普及によってジュニアエンジニアの学習機会が失われつつある現状と、各社がとる対応策について詳しく紹介されている。
「ジュニアを育てなければ、シニアも生まれない」
AIが書いたコードのレビューが新たなボトルネックになっている。Sonarが1,100人以上の開発者を対象に行った調査では、AI生成コードのレビューに「より多くの労力が必要」と回答した開発者が**38%に上り、61%**が「AIのコードは一見正しく見えるが信頼性が低い」と答えた。
この状況を象徴するのが、AIビデオ生成プラットフォームのSynthesiaだ。2025年11月、同社の118人のエンジニアがClaude Code（Anthropicが提供するターミナル上で動作するAIコーディングエージェント）などのツールを全面導入した結果、プルリクエスト（コードの変更提案）の数が前年比120%増となり、そのうち**95%**がAI生成コードを含む。CTO Peter Hillは「AIによるコード生成を完全に信頼できる水準になるかどうか、正直わからない」と述べている。
コードの品質問題も深刻だ。SynthesiaではAIツールが既存のコードの存在に気づかず同じ関数を重複して生成するケースが頻発し、同一関数が10バージョン存在する事態も確認されている。その都度、エンジニアが重複を特定・削除し、再発防止のためにAIエージェントを再学習させる作業が発生する。
そのコア的な懸念は、エンジニアの育成にある。Bonterra（非営利団体向けソフトウェアプロバイダー、エンジニア約290人）のCTO Tanuja Korleplaは端的に言い切った。
「If the industry stops hiring juniors, the industry stops producing seniors（ジュニアの採用をやめれば、シニアも生まれなくなる）」
— Tanuja Korlepla, Bonterra CTO
AIコードレビューの現場
各社はAIコードの品質問題に対し、独自の仕組みで対処している。
生成前に仕様書を書く
Amazonのモバイルショッピングアプリの刷新を担当するシニアプリンシパルエンジニアのMcLaren Stanleyは、AIにコーディングを始めさせる前に詳細な「スペシフィケーション（仕様書）」を書くことの重要性を強調する。仕様書の記述漏れにより、AIエージェントがSwiftの誤ったバージョンで2万5,000行のコードを生成してしまったことがある。バージョンを切り替えると600件のエラーが発生し手に負えなくなったため、コードを破棄して仕様書を修正し、エージェントを再実行した。正しいコードが生成されるまで要した時間はわずか15分だったという。
AIエージェントで一次レビュー
AWS（Amazon Web Services）のシニアプリンシパルエンジニアDavid Yanacekによると、AWSではエージェントが動作確認・元の設計との照合・セキュリティチェックを担い、人間のレビューはその後に行う体制をとっている。
BontreraではAI導入から3ヶ月でプルリクエストが3倍に膨れ上がり、レビュー対象のコード量は10倍になった。同社のエージェントはコードを設計書・セキュリティルール・コーディング規約・アクセシビリティ要件と照合し、信頼度スコアを出力する。スコアが低い場合や問題が検出された場合、また決済・個人データなどのセンシティブな領域は必ず人間がレビューする。ただし、人間のレビューが「承認のポーズ」にならないかという懸念もある。ソフトウェアコンサルタント会社Making SenseのチーフAIアーキテクト JD Raimondiは、エンジニアが「動くことは確認したが中身は理解していない」という状態で承認する「theater approval（形式だけの承認）」に陥るリスクを指摘する。
コードの説明責任を開発者に戻す
Temporal（ワークフローオーケストレーション基盤を提供するオープンソースプラットフォーム）では「Send Back（差し戻し）」ポリシーを導入。コードを提出するエンジニアは、AIエージェントの設計判断や例外処理の方針を自分の言葉で説明できなければならない。できなければレビュアーが差し戻す。CEO Samar Abbasはこう述べる。
「We refuse to let code review become a dumping ground for unchecked model outputs（コードレビューを未検証のモデル出力の捨て場にすることは断固拒否する）」
— Samar Abbas, Temporal CEO
ジュニアエンジニアの育成をどう守るか
各社の対応はそれぞれ異なる。
IBMのアプローチは、AIをジュニアの「レベルアップ装置」として使うことだ。オートメーション・AI担当ゼネラルマネージャーのNeel Sundaresanによると、新卒エンジニアにかつてはシニア向けだったプロダクト開発を担当させ、AIが実装とテストを支援する。失敗した場合は、ジュニアが原因を特定して修正しシニアに渡す。この方法でジュニアが**70〜80%**のシニア業務をこなせるという試算だ。
Making Senseのアプローチは、ジュニアをAI出力のチェック係に限定しないことだ。「なぜその機能が必要か」「どう動くべきか」という上流の意思決定にジュニアも参加させ、コードを書く経験は減っても判断力を鍛える場を確保している。
Bonterraのアプローチは、かつてジュニアが担っていた定型的なコーディングタスクをエージェントに移譲しつつ、ジュニアには成果への責任を持たせること。エージェントへの指示出し・出力の検証・最終的な責任を取る経験が、新たな育成の場になると位置づける。
AIコーディング時代に求められる視点
AIが書くコードが増えるほど、エンジニアに求められるのは「書く力」より「判断する力」になる。各社の事例が示すのは、育成の仕組みを意図的に設計しなければ、ジュニアは「AIの出力を承認するだけの係」に陥りかねないという現実だ。仕様を書く・差し戻す・説明責任を持たせるといった具体的な制度設計が、その歯止めになっている。自社のAI導入を進めるエンジニアリングマネージャーや開発組織のリーダーにとって、ツールの選定と同時に「ジュニアがどこで失敗し、何を学ぶか」を設計に組み込むことが、次世代のシニアを生み出す鍵になるだろう。
詳細はWill Junior Engineers Learn Enough in an AI-First Coding World?を参照していただきたい。
