AI時代の真の上級者は「最も速く書く人」ではなく、「最も上手く疑う人」
AI時代において重要なのは、「書く速さ」ではなく「疑う力」です。
AIが書いたコードをそのまま貼り付けて、「とりあえず動いた」と安心していませんか？その裏で、見えないバグや設計の歪みが潜んでいるかもしれません。
生成AIの登場で、プログラミングの世界は大きく変わりました。かつてはコードを書く速さや知識量が評価されていましたが、今は違います。
AIに
「ログイン機能を作って」
「Unityでマルチプレイを実装して」
「このエラーを直して」
と指示すれば、数秒でそれらしいコードが返ってきます。
では、AI時代に価値が下がるものは何でしょうか。それは、「書くこと」だけを強みにした力です。
AIは速い。でも、正しいとは限らない
AIは驚くほど速くコードを書きますが、もっともらしく間違えるという弱点があります。しかも、誤りでも正しそうに見えるのが厄介です。
例えばAIは、
- 存在しないAPIを使う
- 異なるバージョンの書き方を混ぜる
- NullReferenceExceptionの原因を外す
- 危険な非同期処理を書く
- ネットワーク同期で競合を生む
といったコードを生成します。ここで危険なのは、「AIが書いたから正しいはず」と思い込むことです。
AI時代に価値が上がるのは「疑う力」
AI時代の差は「書く速さ」ではなく、疑う力の深さで生まれます。ある人はAIの出力をそのまま使い、ある人は動かなければ聞き直します。本当に強い人は、コードを見る前から仮説を立てます。
- なぜこの設計なのか
- なぜ singleton が必要なのか（本当に必要か）
- なぜ static なのか（状態管理として適切か）
- 本当に null の原因はそこなのか
- クライアントではなくサーバ側ではないか
- 競合条件はないか
こうした問いを立てられる人は、コードを書く前に設計の矛盾に気づきます。つまり強い人は、コードを書く人ではなく、仮説を立てて検証する人です。これはAIが苦手な領域です。
疑う力は「実装」にも向ける
設計だけでなく、実装レベルでも「違和感を持つ力」が重要です。例えばAIが生成した1000行のコードの中に、
player = FindObjectOfType<Player>();があったとします。一見問題なさそうですが、強いエンジニアは立ち止まります。
- Scene切替後も存在保証はあるか
- Awakeの実行順はどうか
- Multiplayerで複数Playerがいたらどうなるか
- 毎回シーン内を探索して負荷は問題ないか
さらに、FindObjectOfType はUnity 2023.1以降では非推奨となっており、現在は FindFirstObjectByType や FindAnyObjectByType が推奨されています。加えて、毎回シーン内を探索する設計自体が問題になることも多く、
- Inspectorから参照を渡す
- 依存性注入（DI）を使う
- 初期化時にキャッシュする
といった方法が望ましい場合もあります。重要なのは、「動くか」ではなく「なぜそう書くか」を疑えるかです。
「動いた」は完成ではない
学習中に陥りやすいのは、「動いたからOK」という考えです。しかし実務では、
- 再現性
- 保守性
- 可読性
- 変更耐性
- 障害時の追跡性
まで求められます。つまり、動くコード ≠ 良いコードです。AIは「動きそうなコード」は出せますが、なぜその設計か・なぜその実装か・何を選び何を捨てたか、までは保証しません。判断するのは人間です。
疑う対象はAIだけではない
強いエンジニアはAIだけでなく、
- 自分の思い込みや解釈の誤り
- 他人の説明
- ブログ記事や動画解説
- 公式ドキュメントの読み違い
も検証します。これは「何も信じるな」ではなく、鵜呑みにせず、自分で検証するということです。エンジニアの仕事は、観測 → 仮説 → 検証の繰り返しです。
AIを使うな、ではない
AIを使うなという話ではありません。むしろ積極的に使うべきです。例えば、
- ボイラープレート生成
- リファクタ案出し
- エラー解析
- ドキュメント要約
- テストコード作成
などは大幅に効率化できます。問題は、思考までAIに任せることです。ここを手放すと成長は止まります。
最後に
AI時代に必要なのは「最速タイピング」ではなく、違和感を持つ力・本質を見抜く力・仮説を立てる力・検証する力です。つまり真の上級者とは、最も速く書く人ではなく、最も上手く疑う人です。
AIが強くなるほど、この差は広がります。コードを書ける人は増えますが、コードを疑える人は簡単には増えません。
AIが書いたコードを読めないなら、それは「開発」ではなく「転記」です。エンジニアを目指すなら、コードを書く前に疑う習慣を持ってください。