海外の技術コミュニティで「AIを使ってコードを書くことは絶対にしない」という宣言が話題を呼んでいる。Hacker Newsで65ポイントを獲得し80件のコメントが集まったこの主張は、AI活用が当たり前になりつつある今だからこそ、私たちに本質的な問いを投げかけている。
主張の核心：なぜAIコーディングを拒否するのか
著者の立場は単純な「技術嫌い」ではない。コードを書くという行為そのものに宿る価値を守りたいという、強い職人意識から来ている。
主な論点はこうだ。
- 理解のないコードは負債になる: AIが生成したコードでも、理解していなければバグに直面したとき自力で解決できない
- 書くことで思考が整理される: コーディングは問題解決のプロセスそのものであり、AIに委託することは思考の一部を手放すことになる
- スキルの維持と職人の矜持: 長年磨いてきたコーディング能力をショートカットによって錆びさせたくない
これはプロとして真剣に考え抜いた上での立場表明であり、単なる変化拒否ではない。
なぜ今、この主張が注目されるのか
AIコーディングツールの普及が急速に進む中、このような反論が注目されるのは必然とも言える。背景にはいくつかの構造的な懸念がある。
スキルの二極化が実際に始まっている: AIを使いこなしてアウトプットを大幅に増やすエンジニアと、AIへの依存が進んで基礎力が落ちていくエンジニアの分岐が、現場レベルで起き始めている。この懸念は根拠のないものではない。
「動くコード」と「理解しているコード」の乖離: AIが生成するコードは文法的に正しく、一見動作する。しかし本番環境の複雑な条件下でどう振る舞うか、セキュリティ上の考慮が十分かどうかは、理解していなければ判断できない。
コードレビューの形骸化リスク: チーム全員がAIでコードを書くようになると、誰もそのコードを深く理解していない状態が生まれうる。これはリスク管理の観点から深刻な問題だ。
実務での活用ポイント
日本のエンジニアはどう向き合えばいいか。
1. 「生成させて、理解して、使う」のサイクルを守る
AIに生成させたコードを無批判に貼り付けるのは確かに危険だ。しかし「生成 → 読解 → 改変 → 理解」というサイクルを守れば、良いコードのサンプルを素早く参照できる学習ツールにもなる。重要なのは「理解してから使う」という姿勢だ。
2. 中核の設計はエンジニア自身が考える
アーキテクチャの決定、データモデルの設計、セキュリティの考慮――これらは自分の頭で考える必要がある領域だ。AIはここでも補助ツールとして使えるが、最終的な判断と理解は人間が持つ必要がある。
3. 未経験領域への足がかりとして使う
全く触れたことのない言語やフレームワークを探索する際、AIは非常に強力だ。生成されたコードを読み解くことで、新しい技術を素早く理解するための「スタートアップコスト」を大幅に下げられる。
4. テストとドキュメントから始める
理解が薄い状態でAIにコードを書かせるリスクが心配なら、まずテストやドキュメントの補助から試すのが現実的だ。リスクが低く、効果が高い領域だ。
筆者の見解
率直に言う。「AIでコードを絶対に書かない」という立場は、誠実な職人意識から来るものとして尊重できる。しかし同じ立場を2年後も維持できる人は少ないだろう。
より本質的に言えば、AIによる支援を「副操縦士」として使うか、「自律して動くエージェント」として使うかで話は全く変わってくる。前者の使い方――AIに一行ずつコード補完させて自分が書いた気になって進む――これは著者が批判する対象に近い。確かに「理解の薄いコード」が溜まっていく危険がある。
しかし後者の使い方――「このシステムを設計してテストまで通せ」という目的を与え、エンジニアはアーキテクチャ判断と成果物のレビューに集中する――これは全く別の話だ。エンジニアの役割は「コードを書く人」から「システムを設計・判断・検証する人」に移行する。これはスキルの喪失ではなく、スキルの高度化だ。
日本のIT現場では、この移行に気づいていない現場がまだ多い。「AIにコードを書かせていいの？」という議論の段階で止まっている間に、世界では「AIエージェントが自律的にシステムを改善し続ける仕組み」の設計競争が始まっている。
「AIでコードを書かない」という宣言の背後にある問い――「エンジニアの本質的価値とは何か」――は、真剣に向き合うべき問いだ。その答えは、コードを一行一行自分の手で書くことではなく、より高い抽象度で技術を設計・判断できる能力にある。その能力を磨くための手段として、AIをどう使うかが、これからのエンジニアに問われている。
出典: この記事は I Will Never Use AI to Code の内容をもとに、筆者の見解を加えて独自に執筆したものです。