AIにコードを書かせた瞬間、画面の前のエンジニアは何をしているのか。
答えを待っている。承認している。コピーしている。
「動いた」と言っている。
速くなった。でも何かが消えた。
vibe codingが広まって、コードを書く速度は上がった。ツールの補完が賢くなり、プロンプト一つでボイラープレートが消えた。それは事実だ。反論するつもりはない。
ただ、速度と引き換えに、あるプロセスが静かに省略されている。
デバッグのとき、自分でコードを読む時間。設計するとき、なぜその構造にするかを言語化する時間。動かなかったとき、どこがどうおかしいかを自分の頭で追跡する時間。
これらは全部「時間がかかること」だった。だから、削られた。合理的に、自然に、誰の決断でもなく。
「動くからヨシ」は正解になった
AIが生成したコードはだいたい動く。完璧ではないが、使える。
だから「動くからヨシ」は、今や正しい判断になっている。レビューで「なぜこの設計にしたの？」と聞くのは、むしろ非効率の指摘として返ってくる。「AIが出したやつを選んだ。動いてる。問題ある？」
問題はない。動いているから。
だがそれを繰り返していくと、ある問いが立てられなくなっていく。「なぜ動くのか」という問いだ。
「なぜ動くか」を言えない人間が量産されている
これは技術の敗北ではない。むしろ技術の勝利の副産物だ。
ツールが賢くなるほど、人間がその仕組みを理解しなくても結果が出る。医薬品の作用機序を知らなくても薬は飲める。エンジンの構造を知らなくても車は運転できる。それと同じことが、コードにも起きている。
問題は、エンジニアはエンジンの設計者であるはずだ、という点だ。
医者が薬の成分を知らなくても困らない場面はある。でも外科医が「とりあえずAIに任せたらこの手術の手順が出てきたので従った」と言ったら、誰かが怖いと思うはずだ。
エンジニアリングにも、その怖さがじわじわ近づいている。
スキルは「使わない」と消えていく
デバッグ力は、デバッグをやり続けなければ落ちる。設計の勘は、設計を試みなければ鈍る。
問題は、これらが急に消えるわけではないことだ。
今日AIに任せたからといって、明日すぐにデバッグができなくなるわけではない。でも一年後、二年後、「あれ、このスタックトレース、なんでここでこうなってるんだっけ」と自分の頭で追えなくなっている人間が静かに増える。
誰も気づかない。動いてるから。
その頃にはAIがもっと賢くなっているから、余計に問題が見えない。デバッグ力が落ちていることを、デバッグせずに済む環境が隠してくれる。
この構造が怖い。
「問う機会」が設計から消えている
研修でよく聞く言葉がある。「アウトプットよりプロセスを評価する」。
でも今、プロセスへの介入が急速に省略されている。プルリクのレビューで問われるのは「動くか」「テストが通るか」「セキュリティ上の問題があるか」だ。「なぜこのアルゴリズムを選んだか」「この変数名はどういう意図か」を問う余裕が減っている。
それは悪意のある変化ではない。ただ、速くなったから。速くなると、問う時間が「コスト」に見えてくる。
問う機会が設計から消えると、問う力を育てる土台が消える。
私が気になっているのは、十年後だ
五年後のエンジニアリングチームを想像してほしい。
vibe codingで育ったメンバーが主力になっている。動くコードを速く出せる。でも「この設計の根拠を説明してほしい」という問いに、答えられない人間が今よりずっと多い。
それでも仕事は回る。AIがあるから。
では、AIが出した答えが間違っていたとき、誰がそれに気づけるのか。本番環境でじわじわ起きている不整合を、誰が追えるのか。新しい制約が生まれたとき、既存の設計のどこをどう変えるべきか、誰が判断できるのか。
「動くからヨシ」の積み重ねが、その問いに答えられる人間を減らしている。
スキルは使わないと消える。使う機会が設計から消えると、スキルを保てる人間は、意識的にコストをかけてその機会を自分で作るしかなくなる。
それをやれる人間と、やらない人間の差が、数年後に静かに開く。
速度は全員に配られた。でも問う力は、自分で守らないと消えていく。