AIがコードを書いても、プログラマーはコードを読み問い続ける必要がある

いまや新しいコードの多くをAIのコーディングツールが書いています。このガイドは、韓国企業や国際チームで働く開発者と開発管理職向けです。筆者の主張はこうです。今もプログラマーをプログラマーたらしめるのは、コードに問いを投げ、その答えをコードそのものの中に探す習慣です。

AIが変えた開発の仕事

Claude CodeやCursorのようなツールを使えば、コーディング経験の少ない人でも短時間で動くアプリケーションを作れます。Anthropicは、Claude Codeをコードベースを読み、ファイルを編集し、コマンドを実行するエージェント型のコーディングツールと説明しています。ターミナル、コードエディター、デスクトップアプリ、ブラウザで使えます。

変化の大きさを示すデータが2つあります。

• 2025年3月、Y Combinatorのマネージングパートナーであるジャレッド・フリードマン氏は、2025年冬期のスタートアップの4分の1でコードベースの95%がAIで生成されたと述べました。ライブラリを読み込むコードは計算から除かれています。同氏は、これらの創業者が皆高い技術力を持つと強調しました（TechCrunch報道）。
• 2022年のGitHubの実験では、プロの開発者95人がJavaScriptでHTTPサーバーを作りました。GitHub Copilotを使ったグループは約55%速く終えました。平均1時間11分対2時間41分です。課題を完了した割合はCopilotグループが78%、もう一方が70%でした。狭い課題1つの結果なので、すべての開発業務に当てはまるわけではありません。

タイピングの速さや文法の暗記で差がつくことは、以前より少なくなりました。

昔の物差しとより良い物差し

「本物の開発者」をめぐる議論は、主に技術的な深さを軸にしてきました。アルゴリズムとデータ構造、言語の習熟度、システム設計の力です。これらは今も大切です。しかし、その力で書いていたコードの多くを今はAIが書きます。

筆者の考えでは、この仕事の核心は最初からコードを打つことではありませんでした。事業の問題を動くソフトウェアに変えることです。プログラマーを分ける物差しは単純です。あるコードに問いを投げ、そのコードから答えを出せるかどうかです。

AIツールの利用とプログラミングの違い

AIツールで行う「バイブコーディング」を例に取ります。望むものを自然言語で説明し、結果が期待どおりに動くかを確かめ、だめならAIに直してもらいます。コードは読みません。役に立つ仕事ですが、プログラミングというより、AIツールで製品を作る作業に近いものです。

プログラミングとは、AIが書いたコードであっても動く仕組みを理解し、自分で直して改善できることです。ソフトウェアが予想外の動きをしたとき、プログラマーは文書や外部の資料より先に、実際に動いているコードを見ます。

Y Combinatorに関するTechCrunchの報道も同じ点を指摘しています。Y Combinatorのギャリー・タンCEOは、初期の推論モデルはデバッグが苦手なので、創業者は自分の製品を深く理解する必要があると警告しました。

職場でのコード回避

筆者は、コードを読むのを避ける開発者をよく見かけます。新しいプロジェクトに入ると、文書や同僚の説明だけに頼ります。文書が足りないので開発を始められないと言いながら、自分ではあまり文書を書きません。筆者の経験では、経験10年以上のシニア開発者に意外とよく見られます。一方、1~3年目のジュニア開発者は新しい言語やフレームワークにすばやく慣れることが多いです。筆者はこれを学習能力ではなく、仕事への向き合い方の違いと見ています。

この習慣はチーム全体を傷つけます。動くソフトウェアがすでに事業を支えているなら、そのコードこそ事業の動き方を最も正確に、最新の状態で記録したものです。コードを読まない開発者は、チームが事業を理解する手助けができません。

よくある言い訳は「レガシーコードが汚い」というものです。ところが同じ人が、最初から参加したプロジェクトにも同じことを言います。それなら問題はコードではなく、理解しようとする意志や力です。自分が理解できるかどうかでコードの良し悪しを決める開発者もいますが、それは客観的な基準になりません。さまざまなコードを多く読んだ開発者は、自分のコードと他人のコードを公平に比べ、どこに説明や文書が必要かを判断できるようになります。

AIでコードを読む

ClaudeやChatGPTのようなAIツールは、関数やモジュールの役割をわかりやすい言葉で説明してくれます。そのためコードを読むハードルは下がりました。しかし説明は出発点にすぎません。説明を実際のコードと比べ、意図した動きと実際の動きの差を見つけ、直し方を決めるのは今も開発者の仕事です。プロジェクト全体の構造を要約するエージェント型ツールも、コードを理解しようとする姿勢があってこそ最も役立ちます。

開発者とチームのためのチェックリスト

1. ソフトウェアに問題が起きたら、まずコードを開きます。
2. コードレビューを行い、チーム全員が動いているコードを理解するよう求めます。
3. 汚いレガシーコードは避ける対象ではなく、学ぶ対象と考えます。
4. AIを学ぶための道具として使います。コードがどうあるべきかだけでなく、なぜそう動くのかを尋ねます。
5. 採用では、AIツールを上手に使い、そのツールが生成したコードを確認・検証できる人を評価するよう筆者は提案します。問題を定義し、事業の文脈を理解するのは今も人の仕事です。
6. プロンプト設計や新しいツールの習得も役立つ技術ですが、コードを本当に理解していてこそ最もよく生きます。

筆者の結論はこうです。AIはプログラマーの役割をなくすのではなく、求められる水準を上げます。コードに問い、コードから答えを見つけられる開発者が、これからも価値を生み出します。