海外のプログラミングコミュニティで、興味深い議論が盛り上がっています。
あるマネージャーが採用したジュニア開発者についての相談です。
その開発者はAIを使ってプログラミングを学びました。
コードを高速に書けます。
テストも通ります。
見た目も問題ありません。
しかし、本番環境で何かが壊れると、完全に手が止まってしまうというのです。
スタックトレースを読めない。
ロジックを追跡できない。
コードが実際に何をしているのか理解していない。
これは一人のマネージャーの愚痴ではありません。
AI時代における開発者育成の本質的な課題を浮き彫りにしています。
「Vibe Coder」という新しい現象
コミュニティでは、このような開発者を「Vibe Coder（バイブコーダー）」と呼ぶ声が上がりました。
コードを書くことはできます。
動くものは作れます。
しかし、保守ができないのです。
投稿者の体験は具体的でした。
ペアプログラミングを試みても、そのジュニア開発者はエラーをAIに貼り付けます。
そして、返ってきた修正をコピーするだけ。
なぜ壊れたのか、なぜその修正で直るのかを理解しようとしません。
プルリクエストの説明を求めると、コードが「何をするか」は説明できます。
しかし「どう動くか」は説明できません。
「この部分はClaudeが書いた。エッジケースを処理している」と言います。
どんなエッジケースかと聞くと「わからない。でもテストは通っている」と答えるのです。
実はAI以前から存在した問題
興味深いことに、多くのベテラン開発者がこう指摘しました。
「この問題は新しくない。AIが新しい顔をつけただけだ」と。
AI登場以前、同じタイプの開発者はStack Overflowからコードをコピーしていました。
理解せずに貼り付け、動けばよしとする。
エラーメッセージをGoogleに入れて、最初に出てきた解決策をそのまま適用する。
そういう人たちです。
ある開発者は経験を共有しました。
「AIより前に採用した『シニア』でも、デバッグがまったくできない人はいた」と。
表面的な症状だけを直そうとして、根本原因を探ろうとしない。
そういう人はいつの時代もいたのです。
ただし、AIによって状況は変わりました。
そのような開発者が生成できるコード量が劇的に増えたのです。
理解していないコードの山が、より速く、より大きく積み上がるようになりました。
採用プロセスの問題という視点
コミュニティの一部は、問題の矛先を投稿者自身に向けました。
「そもそもなぜ採用した？」という疑問です。
技術面接でデバッグのテストをすれば、このような候補者は落とせたはずです。
既知のバグを含むコードを渡し、目の前で修正させる。
AIなしで問題を特定させる。
こうした手法は、AI時代の面接でより重要になっています。
あるコメントは辛辣でした。「コードが何をしているか理解していない開発者を採用できてしまう面接プロセス自体を、デバッグすべきでは？」
進歩の自然な流れという反論
一方で、まったく異なる視点もありました。
「これは技術の進歩そのものだ」という主張です。
ある開発者はこう書いています。
「『コンパイラを使っている開発者を採用したが、機械語で何が起きているか説明できない』と言っているようなものだ」と。
かつてアセンブリ言語を知らない開発者は信用されませんでした。
メモリ管理を理解しない開発者は半人前とされました。
しかし今、多くの開発者はガベージコレクションに任せきりです。
それが問題とは思われていません。
jQueryやBootstrapが登場したときも同様でした。
それらがなぜ動くか説明できない開発者は多かった。
ライブラリを接続し、基本コマンドを覚え、動けばよしとしていました。
「コードを理解する」という概念自体が、時代とともに変化しているのかもしれません。
AIを「教師」として使うという解決策
最も建設的な提案は、AIの使い方を変えるというものでした。
AIにコードを書かせるのではなく、AIに教えてもらうのです。
電気技師からプログラマーに転向した人の体験談が印象的です。
彼はAIを使って2年間でJavaScript、TypeScript、Pythonを学びました。
しかし、やり方が違います。
ファイルは1000行以下に保ちます。
各ブロックに自然言語でコメントを書きます。
「このコードは何をしているか」を自分の言葉で説明します。
デバッグも自然言語で行い、問題が解決するまでAIに質問を続けます。
このプロセスを通じて、パターンを学んでいくのです。
別の開発者はこう提案しました。
AIは何度言い換えを頼んでも嫌な顔をしません。
「まだわからない、別の説明を」と繰り返し頼めます。
「5歳児に説明するように」と頼めます。
「もう一つ例を」と何度でも頼めます。
重要なのは、AIに問題を解かせないことです。
プログラミング学習中は、AIのコード補完を使わない。
代わりに家庭教師として使う。
概念を説明してもらい、理解を確認してもらい、疑問を解消してもらう。
この使い方なら、AIは学習のゲームチェンジャーになります。
「理解」を確認する具体的な方法
あるコメント投稿者は、自分なりの学習法を共有しました。
AIが生成したコードを受け取ったら、それを自分の言葉で説明する文書を書きます。
その説明をAIに見せ、理解が正しいか確認してもらいます。
間違っている部分があれば、そこを深掘りします。
フローチャートやダイアグラムをAIに生成させたら、スクリーンショットを取るのではなく、自分の手で描き直します。
draw.ioでもいい、紙でもいい。
コピー＆ペーストは新しい概念の定着を助けません。
「なぜこうなる？」という質問を「どう直す？」より優先します。
修正方法だけでなく、根本原因を理解することに時間を使うのです。
認知的負債という概念
ある若手開発者は、自分が直面した問題を「認知的負債（cognitive debt）」と表現しました。
AIが書いたコードは、常に「他人のコード」です。
自分で書いたコードは脳に刻まれます。
デバッグも早い。
しかしAIのコードは、たとえガイドラインを与えても、本当の意味で自分のものになりません。
コードレビューでAIの出力を確認しても、翌日には何を確認したか覚えていません。
昔は、どのプロジェクトでどの実装を使ったか記憶していました。
だから高速にデバッグでき、ホットフィックスも素早く出せた。AIコーディングでは、これが難しくなります。
この問題を解決するため、この開発者はワークフローツールを作りました。
AIの出力速度を意図的に遅くし、各ステップで理解を確認させます。
速さを犠牲にして、オーナーシップを構築する仕組みです。
シニア開発者の責任
投稿への返答の中で、見逃せない指摘がありました。
「そのジュニアは単にジュニアだ。何を期待していた？」
ジュニアを採用するのは、育成する意図があるからです。
AIを使うこと自体は問題ありません。
AIが何をしているか理解していないことが問題なのです。
具体的な対応策として、プルリクエストのマージ前に質問を続けることが挙げられました。
コードの説明を求め、答えられなければマージしない。
事前に調べていなくても、コードを読んで大まかな流れを説明できるべきです。
それでも改善しないなら、従来通りの対応になります。
改善計画を立て、それでもダメなら契約を見直す。
これはAI特有の問題ではありません。
Stack Overflowをコピーしていた時代と同じ対処法です。
10年後の懸念
コミュニティでは、長期的な懸念も共有されました。
ある企業は、過去2年間ジュニアの採用を止めています。
シニア開発者にAIサブスクリプションを与える方が、コスト効率が良いからです。
バグも少ない。
しかし、10年後にシニアはどこから来るのでしょうか。
シニアは生まれるのではなく、育つのです。
ジュニアを排除している企業は、将来のシニア不足をどう考えているのでしょうか。
ある投稿者は冷笑的に答えました。
10年後のことなど誰も考えていない。 今お金を稼いで去る。 それが上の世代が我々にしたことで、我々が次の世代にすることだ
別の投稿者は、アシモフのSF小説『ファウンデーション』を引用しました。
技術司祭のクラスが、仕組みを誰も覚えていない帝国の機械を維持している。
奇妙で古めかしい儀式が、世代を超えて受け継がれる。
「20年後の我々がそれだ」と。
この問題にどう向き合うか
コミュニティの議論から見えてくるのは、問題の多面性です。
これはAI固有の問題ではありません。
しかしAIが問題を加速させ、可視化しました。
理解せずにコードを生産する人の出力量が、劇的に増えたのです。
解決策は複数あります。
採用プロセスを改善し、デバッグ能力を面接で確認する。
AIを単なるコード生成器ではなく、教育ツールとして使う方法をジュニアに教える。
コードの「オーナーシップ」を意識させ、提出したコードには自分が責任を持つという文化を作る。
同時に、「理解」の定義自体が変わりつつあるという現実も受け入れる必要があります。
コンパイラの出力を理解しなくても開発者として成立するように、AIの出力を完全に理解しなくても価値を生み出せる未来が来るかもしれません。
ただし、その未来はまだ来ていません。
現時点では、コードを理解できない開発者は、保守もデバッグもできません。
本番障害に対応できません。
チームの負担になります。
AIは道具です。
道具を使いこなすには、その道具が何をしているか理解する必要があります。
電卓を使うにも、基礎的な数学の理解が役立つように。
AIでコードを学ぶこと自体は問題ではありません。
AIにコードを理解させることなく、自分の理解を放棄することが問題なのです。
まとめ
海外のプログラミングコミュニティで交わされた議論は、AI時代の開発者育成における本質的な課題を示しています。
「Vibe Coder」と呼ばれる現象は、AI以前から存在した問題の加速版です。
しかし、その影響範囲と速度は、かつてないレベルに達しています。
解決策として最も支持されたのは、AIの使い方を変えることでした。
コード生成器としてではなく、教師として使う。
説明を求め、理解を確認し、疑問を解消する。
プライベートな家庭教師を24時間持てることは、本来とてつもない特権のはずです。
採用プロセスの改善、コードオーナーシップの文化構築、そして「理解」の新しい定義の模索。
これらが、AI時代のチーム運営に必要な取り組みとなるでしょう。
技術は進歩します。
その進歩に取り残されないためには、ツールに使われるのではなく、ツールを使いこなす姿勢が求められます。
AIを活用しながらも、自分の頭で考え、自分のコードに責任を持つ。
その原則は、どれだけ技術が進んでも変わらないのかもしれません。
