見出しは、AIがソフトウェアエンジニアを不要にすると繰り返し報じている。私はそうは思わない。真のリスクは、機械がエンジニアリングを乗っ取ることではない。エンジニアが「考える」という困難な作業を止めてしまうことだ。
ソフトウェア開発とは、単に構文を入力することではなかった。常に、複雑さを頭の中に保持し、失敗のパターンを理解し、完璧な選択肢がない中でトレードオフを行うことだった。AIはコードを生成するスピードを変えたが、なぜ人間が介在（human in the loop）する必要があるのかという理由は変えていない。むしろ、明晰な思考の価値は高まり、より希少なものとなった。
初稿はエンジニアリングではない
ChatGPTやClaudeを、隣に座っているシニアエンジニアのように扱うジュニア開発者が増えているのを目の当たりにする。彼らはチケットの説明を貼り付け、回答をコピーし、テストを実行して、コミットする。コンパイルが通れば、タスクは完了だ。このループは速く、摩擦がなく、そして危険だ。
AIを使うこと自体が問題なのではない。私も使うし、私が知る最も生産的なエンジニアたちも使っている。問題は、AIがその場における唯一のエンジニアになったときに始まる。「動くから」といって最初の解決策を受け入れるのは、エンジニアリングではない。それは、ユーザーやビジネス上の制約、あるいは深夜2時にスタックが崩壊した時の状況さえも理解していないモデルに、判断をアウトソーシングしているのだ。
大規模言語モデルは、完全に間違っているときでさえ、不気味なほどの自信を持って回答を提示する。あるエンジニアが、スケーラブルなアーキテクチャの設計をAIに依頼した。モデルは、実際の商品には存在しない機能に基づいた、詳細で権威ある提案を返してきた。それは正しく見え、内部的な整合性も取れていた。しかし、全く役に立たなかった。危険なのは、AIがハルシネーション（幻覚）を起こすことだけではない。あまりにも多くの人々が、そのハルシネーションを信じてしまうことだ。なぜなら、彼らにはその嘘を見抜くためのコンテキスト（文脈）がもはや欠けているからだ。
摩擦から学ぶ
ジュニア開発者から、システムを任せられる人間へと成長させてくれたものは何かを考えると、暗記した構文などは思い出さない。思い出すのは、システム停止（アウトレージ）だ。手動で追跡しなければならなかった低速なクエリ、本番環境の負荷下でのみ発生したレースコンディション、そしてローカル環境と本番環境の違いによって引き起こされたデプロイの失敗だ。
学習が起こるのは、デバッグの時だ。コードを手動でステップ実行すると、システムが実際に失敗する理由が見えてくる。ボトルネックがどこに現れるかを発見する。ユーザー10人のデモから、1万件の同時リクエストを処理する本番システムへと移行したときに、アーキテクチャがどのように振る舞うかを学ぶ。きれいに構成されたデモと本番環境がいかに異なるかを、身をもって理解するのだ。
そうした知識のどれも、生成された回答を受け入れることから得られるものではない。問題と格闘することから得られるものだ。もしAIがあらゆる苦労を取り除き、コードを書き、バグを修正し、失敗の理由を説明してしまうとしたら、次世代のエンジニアはどうやってシニアとしての経験を積めばいいのだろうか？ 経験とは、ダウンロードできる証明書ではない。それは、本番環境でのインシデントやデプロイの失敗から築き上げられる「傷跡（scar tissue）」なのだ。摩擦を取り除いてしまえば、成長も失われてしまう。
判断力は生成力を凌駕する
しばらくの間、業界はプロンプトエンジニアリングを履歴書に書くべき最新のスキルとして扱っていた。しかし、それは本質を完全に見失っている。AIが飽和した環境において最も価値のある能力は、選択肢を生成することではない。どの提案を拒絶すべきかを知ることだ。
私が一緒に仕事をしている優秀なエンジニアは、プロンプトを大量に書くのではない。彼らは最も困難な問いを投げかける。リファクタリングがいつ隠れた依存関係を生むかを知っている。生成されたテストが「ハッピーパス（正常系）」をカバーしている一方で、顧客データを破損させるようなエッジケースを無視していることを見抜く。彼らは、完璧に正しいコードを見ても、「このコードは正しいが、アーキテクチャが間違っている」と言うことができる。
その最後の一文が、二つの全く異なる文化の境界線だ。「AI支援型エンジニアリング」とは、脳で意思決定を行いながら、スケルトンの作成、パターンの探索、ボイラープレートの自動化にマシンを使うことを意味する。「AI依存型エンジニアリング」とは、マシンに運転を任せてしまうことを意味する。多くの組織は、短期的には速く感じられるため、静かに依存へと傾いている。しかし、「速い」ことは「正しい」ことと同じではない。
人間にしかできない仕事
AIは開発ライフサイクルのほぼすべての部分を加速させることができますが、人間がしっかりと担い続けるべき核心的なプラクティスが存在します。システム設計には、コスト、レイテンシ、信頼性、そして将来の保守性といった、相反する制約のバランスを取ることが求められます。アーキテクチャレビューは、組織の記憶と、二次的な影響を予測する能力に依存します。メンターシップには、自分が警告している失敗モードを実際に経験し、苦労してきた人物が必要です。深い製品理解は、トレーニングデータを読むことからではなく、ユーザーと対話し、実際の現場での振る舞いを観察することから生まれます。
エンジニアリングにおける判断力とは、そうした経験の積み重ねです。それは、たとえコードレビューを通過したとしても、「金曜日の午後に移行作業を行うのはリスクが高すぎる」と告げる静かな声です。今行うパフォーマンスの最適化が、後にセキュリティホールを生むかもしれないと感じる直感です。LLMには直感はありません。あるのはパターンです。パターンは有用ですが、判断力ではありません。
現在採用を行っている企業は、単にAIツールを使いこなすのが上手い人たちを最適化の対象とすることをやめるべきです。AIに異を唱えられる人材を採用してください。生成された出力を立ち止まって注意深く読み、なぜそれに同意できないのかを説明できる候補者を探してください。生成されたコードが、本番環境の複雑で混沌とした現実に直面したとき、システムを健全に保ち続けてくれるのは、そのようなエンジニアなのです。
指針なき加速
AIをアクセルペダルだと考えてください。〜を備えた車において