AIがコードを書くようになったとき、エンジニアは成長し続けられるのか？

私はその問いと向き合うことになった。

※本記事は英語で執筆し、日本語訳にChatGPTを使用しています。

ツールより、コンテキストが重要

IDEでAIアシスタントを使い始めたとき、正直かなり驚いた。周囲のコードを読み取り、コンテキストに沿った提案をしてくれる。その体験は、まるで魔法のようだった——もちろん、常に正しいわけではなかったが。

前職では、AI支援開発を本格的に試した。GitLab DuoやClaude Codeを使ってみたが、結果は正直に言って厳しかった。

問題はAIではなかった。コードベースにあった。

対象のプロダクトは約12年前に作られたもので、PHP 5と古いフレームワークの上に成り立っていた。問題は明確だった：

さらに悪いことに、レガシーコードは直接テストできなかった。

加えて、PHP 5 + レガシーフレームワークからPHP 8.3 + ヘキサゴナルアーキテクチャへの移行が進行中であり、新機能開発・バグ修正・移行作業が同時に走っていた。

コードベースは常に 「移行途中」 の状態だった。この状態がAIを混乱させ、提案の精度を下げていた。

Claude Codeはこれらすべてをコンテキストとして取り込もうとしたが、アーキテクチャ自体が一貫していないため、しばしば迷い込んでしまった。

設計の相談やアイデア出しには役立ったが、実際のコード生成においては信頼できるものではなかった。

現職では状況が大きく異なる。

アプリケーションはゼロから構築され、コードベースはクリーンで整理されており、多くは開発から1年以内のものだ。この違いは、Claude Codeの活用度に大きく影響している。

現在では、開発プロセス全体を通してClaude Codeを活用している。チームで定義したルールやスキルを与えながら、問題分析、アプローチ設計、設計判断、ドキュメント作成、実装までを一緒に進めている。

たとえば、API設計の案を複数出させ、それぞれを比較した上で最終判断は自分で行う。

さらに、生成されたコードに対しては、単に全体を見るだけではない。
実際のコードの細かい部分——1行ごとの小さな判断や実装の意図——にまで踏み込んで向き合う。

そこから学ぶこともあれば、自分の考えで再定義（リフレーム）することもある。

もはやすべてのコードを書くことはしていない。その代わりに、ロジック、構造、トレードオフを徹底的にレビューし、プロセスのオーナーシップは自分が持ち続けている。

この働き方によって開発スピードは大きく向上した。それ以上に重要なのは、学びが止まっていないことだ。

特に不慣れな言語では、質の高い生成コードを読み、批評することで、独学では出会えなかったような考え方やパターンに触れることができている。

ひとつの問いが頭から離れない。

今、私はほとんどコードを書いていない。これは以前とは根本的に異なる働き方だ。では、自分はエンジニアとして成長し続けているのだろうか？それとも、これまで積み上げてきたスキルを少しずつ失っているのだろうか？

正直な答えはこうだ。
私は成長している——ただし、その形が変わった。

以前は、仕事の約70%がコードを書くことだった。今ではその大部分をAIに任せている。しかし残りの30%は大きく広がった。

設計の意思決定、アーキテクチャの思考、コードの批判的レビュー、そしてユーザーが本当に必要としているものを理解することに、より多くの時間を使っている。

私は以前よりも考えている。しかも、より深く。

トレードオフについて、より深く考えるようになった。システムの見え方も変わった。そして 「なぜそれが良くないのか」を言語化する力が確実に伸びている。

AIのコードをレビューするには、直感ではなく、思考を言葉にする必要があるからだ。

エンジニアリングは変わりつつある。これは無視できない変化だ。

前職について、もうひとつ重要な点がある。それは技術的負債だけではなく、チームの抵抗感だった。

AI生成コードに対する懐疑的な見方があり、それが無視できない摩擦になっていた。

この摩擦は重要だ。たとえコードベースが良くても、チームが実験する意欲を持っていなければ、AIから価値を引き出すことはできない。

現職ではその逆だ。チーム全体がAIの可能性を積極的に探っている。この違いは非常に大きい。

両方の環境を経験して、次の結論に至った。

Claude Codeから本当の価値を得るには、次の2つが必要だ：

現時点では、思考するエンジニアをAIが置き換えることはできないと思っている。
なぜなら、最終的な意思決定と結果に対する責任、オーナーシップを持つ必要があるからだ。
しかし、その力を劇的に増幅することはできる。

もはや問われているのは「コードを書けるか」ではない。

「それを判断できるか」だ。