AI時代、フロントエンドエンジニアとして生き残る方法：検証・仕様化・判断力という新たな能力

今回の記事では、AI時代にエンジニアがどのように成長し、生き残れるのかについて、個人的な視点から考えてみたい。

筆者がジュニアだった頃、特に印象深く読んだ記事の一つに、ペ・フィドンさんの「フロントエンドエンジニアのキャリアロードマップ、ジュニアのための3つの専門性トラック」がある。フロントエンドエンジニアのキャリアを、**Web特化（Software Engineer）／プロダクト特化（Product Engineer）／運用特化（Full-Stack Engineer）**という3つのトラックに分けて整理し、「優れたエンジニアに必要な5つの基礎能力」と「シニアになるための3つのポイント」まで押さえた記事だ。当時は、トラックごとにどんな力を伸ばすべきかを考えることが最大のテーマだった。ところが、この記事を読んでから2年も経たないうちに、テーマそのものがすっかり変わってしまった。

最近、同僚のエンジニアたちと話していると、ここ数年耳にしてきた悩みとは少し性質が違うと感じる。

「会社でAIを導入したんですが、デザイン案を渡せばほとんど全部作ってくれます。便利ではあるんですが……」
「採用市場がものすごく冷え込んでいますね」
「AIが書いたコードをそのままマージするのは怖いし、かといって一つひとつレビューすると効率が落ちるので悩んでいます」

筆者も同じような時期を経験したし、今も経験している。1〜2年前までは「AIは便利な補助ツール」くらいに考えていたが、今やAIなしで開発する姿そのものが想像できない環境になった（筆者もこの記事を書きながら、Claudeにリサーチを頼んでいる）。今回はペ・フィドンさんの記事の続編という位置づけで、この間に景色がどう変わったのか、そして変化した景色の中で、フロントエンドエンジニアとしてどんな力をさらに伸ばすべきなのかを、筆者なりの視点で整理してみたい。

今回もできる限り多くの資料を探して検証するよう努めたが、非常に変化の速い分野だけに、この記事が公開された時点ですでに一部の内容が古くなっている可能性があることを、あらかじめご了承いただきたい。反論や議論したい点があれば、いつでもコメントで知らせてほしい。

「もうAIが全部やってくれるんじゃないですか？」

まず確認しておかなければならないことがある。「AIが全部やってくれる」という文は事実なのか。どこまでが事実で、どこからが幻想なのか。

2025年2月、OpenAIの共同創業者で、テスラのAIディレクターも務めたAndrej Karpathyは、自身のTwitterに次のように投稿した。

私が「vibe coding」と呼ぶ新しい種類のコーディングがある。雰囲気に完全に身を委ね、指数関数的な成長を受け入れ、コードそのものが存在することさえ忘れるやり方だ。
There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

**バイブコーディング（Vibe Coding）**とは、一言でいえば「AIにキーボードを渡し、欲しいものを自然言語で説明するだけのコーディング手法」だ。アーキテクチャ文書も、ボイラープレートも、セミコロン探しもない。ただバイブだけでコードが動いていく。この言葉は1年も経たないうちに、英語圏の開発者コミュニティで標準的な語彙として定着した。

ところが、ちょうど1年後の2026年2月、同じKarpathyが一歩後退した。彼はvibe codingという言葉を**「agentic engineering」**に置き換えようと提案する。両者の違いは明確だ。

Vibe coding：欲しいものを説明し、出来上がったものを受け入れること
Agentic engineering：システムを設計し、制約を仕様として定め、頭の中ですでに推論を終えた実装をAIで加速すること

1年前は「頼めば全部作ってくれます」が基本的な前提だったとすれば、今では「AIに何をどう指示するかを設計する力」そのものがエンジニアリング能力として定着している。この流れは、一人のツイートだけにとどまるものではない。同じ頃、GoogleのエンジニアであるAddy Osmaniは、Beyond Vibe Coding: From Coder to AI-Era Developerという本を出版し、「AIはアシスタントにすぎず、自律的に信頼できるコーダーではない。シニア開発者はあなたであり、LLMはあなたの判断を加速するために存在する」と明言した。

ツールは暴走する勢いで進化している

ツール側も、この流れに合わせて急速に進化している。2026年5月時点で最もよく言及されるコーディングツールは、Cursor、Claude Code、GitHub Copilot、Windsurf、v0 by Vercel、Bolt.new、Devinあたりだ。

とりわけ、v0の変化は象徴的だ。Vercelは「90% problem」という表現を使っている。現実の開発の90%は、既存のコードベースと既存のインフラの中で行われる、という意味だ。当初はグリーンフィールドのプロトタイプさえうまく作れればよかったv0が、今ではGitHubリポジトリを直接取り込んで作業し、デザインシステムを適用し、デプロイ環境変数を自動で取得して使う。「AIはおもちゃのようなデモしか上手に作れないのでは」というシニアたちの反論に、ツール側が直接答えているわけだ。

ビッグテックのコードベースが、この変化を最もよく表している。

GoogleのSundar Pichaiは、2024年10月の第3四半期決算説明会で「新しいコードの25%以上がAIで生成され、その後エンジニアがレビュー・承認したもの」だと発表し、2025年4月には30%以上に増えたと述べた。MicrosoftのSatya Nadellaは、2025年4月のLlamaConで「私たちのコードの最大30%はAIが書いたコード」だと明かした。Metaの社内目標は、「2026年前半までに、エンジニアの65%がコミットの75%以上をAIで生成する」という水準にまで引き上げられた。

韓国でも流れは変わらない。Tossは、開発者がもはや文書を探さずに済み、DXを高められるようAIベースのドキュメントシステムを構築し、さらに一歩踏み込んで「AI時代、デザイナーをなくしたら起きたこと」といったテーマも扱った。Daangnは毎週火曜日のAI Show & Tellでチームごとの実験を共有し、「エンジニアを超えてビルダーへ」という採用スローガンを掲げ始めた。Woowa Brothersは「AIがコードを書く時代、それでも開発者になりますか？」といった記事を通じて、「開発者の本質はコードではなく、問題を定義し解決する力にある」というメッセージを発信している。

しかし、数字は少し違う物語を語る

ここまでを見れば、「もう頼むだけで全部できるんだな」という結論に向かいやすい。ところが、実際のデータを詳しく見ると、話は少し違う。

ソフトウェア開発の現状を総合的に分析した2025 Stack Overflow Developer Surveyの数字から見てみよう。

開発者の84%が、AIツールを使用している、または使用する予定だと回答した（2024年の76%から上昇）。
プロの開発者のうち51%が、AIツールを毎日使っている。
しかし、AIツールに対する好意度（positive sentiment）はむしろ下がった。2023年と2024年には70%以上だった好意度が、2025年には60%まで落ち込んだ。
10年以上の経験を持つシニア開発者は、AIの出力に対する信頼度が最も低い。

要するに、**「みんな使ってはいるが、時間が経つほど信用できなくなっている」**ということだ。

METRという非営利研究所が2025年に行った実験は、この認識と現実の隔たりをさらに劇的に示している。平均5年の経験と平均1,500コミットの実績を持つ熟練したオープンソース開発者16人に246件の作業を依頼し、AIを使うかどうかを無作為に割り当てた対照実験だった。結果は次のとおりだ。

開始前、開発者たちは「AIを使えば24%速くなる」と予測した。
作業を終えた直後にも、「20%ほど速くなった気がする」と自己評価した。
ところが、実測値では19%遅くなっていた。

研究チームが指摘した原因は興味深い。AIが生成したコードの採用率は44%以下で、却下したコードにもレビューとテストの時間がかかり、採用したコードでさえレビューと修正にかなりの時間を要したという。遅くなったのに速くなったように感じる錯覚。この隔たりが、シニア開発者たちがAIに対してますます懐疑的になる理由の一つだ。

さらに、「AIが書くコードの品質」そのものも盤石ではない。Veracodeが100以上のAIモデルにコードを書かせた実験を見てみよう。

AI生成コードの45%にOWASP Top 10のセキュリティ脆弱性が含まれていた。
XSS（クロスサイトスクリプティング）の防御に失敗した割合は86%。
ログインジェクション（Log Injection）の防御失敗率は88%。
別の研究では、AIコードの脆弱性密度は人間のコードと比べて2.7倍高いと報告された。

フロントエンドに直結するXSSの失敗率86%は、とりわけ重く受け止めるべき数字だ。AIが書いたform inputをそのままマージすることが何を意味するのか、この数字がよく示している。（フロントエンドのセキュリティ監査を経験した開発者なら、dangerouslySetInnerHTMLを自分で直接書くときでさえ違和感を覚えて不安になるのに、AIがこっそり差し込んだものはさらに怖いと感じるだろう。）

品質面でも、同じような兆候が表れている。GitClearが2020〜2024年の間に行われた2億1,100万行のコード変更を分析した結果は次のとおりだ。

作成後2週間以内に元に戻された（reverted）コードの割合（Code Churn）：2020年5.5% → 2024年7.9%
リファクタリングが占める割合：2021年25% → 2024年10%未満
コピー＆ペースト（クローン）の割合：2021年8.3% → 2024年12.3%（2025年には実に4倍に増加）

解釈はそれほど難しくない。コードを素早く量産する力は高まった一方で、再び手を入れる価値のあるコードを書く力は低下したということだ。Fortune 50企業を分析したApiiroのデータでは、さらに強い傾向が見られる。AI支援を利用する開発者は、同僚の3〜4倍のコミットを生み出す一方、セキュリティ上の指摘事項は10倍多く生み出す。権限昇格経路（privilege escalation）は322%増、アーキテクチャ設計上の欠陥は153%増と急増した。

AIは何を代替し、何を代替できなかったのか

ツールは暴走する勢いで進化しているが、数字が示す実態は一筋縄ではいかない。ではAIは、具体的に何を代替し、何をまだ代替できていないのか。この区別を明確にしてこそ、どこに時間を投資すべきかが見えてくる。

代替されたのは、開発者が自らタイピングする比重だ。ボイラープレートや反復的なコードを書く場面は減り、デザイン案さえあれば、規約に沿った水準の画面が数分で出来上がる。構文やAPIを調べる時間も、学習曲線を上る時間も急激に短くなった。要するにAIは、「生産速度」を平準化した。

しかし、「判断」の領域はまだ代替できていない。（正確には「まだ期待を満たせていない」に近い。人によってAI活用能力には差があるだろうが、ここでは平均的な利用体験を基準に話を進める。）

最初に立ちはだかるのは、要件を仕様へ翻訳する作業だ。曖昧なビジネス要件を、正確なエッジケースとステートマシンに落とし込む作業には、今なお人の手がより深く必要になる。システム全体への影響を把握することも同様だ。このコンポーネントがバンドルにどのような影響を与えるのか、依存関係はツリーシェイキング可能なのか、データフェッチのパターンがCore Web VitalsのINP（Interaction to Next Paint）スコアにどう影響するのか。こうした問いにAIがもっともらしい答えを出しても、結局は人がもう一度確認しなければ安心できない。

先ほど見た45%のOWASP脆弱性の問題と同様に、セキュリティとリスク評価も欠かせない。新しいコンポーネントが既存システムのトークン、アクセシビリティルール、インタラクションパターンと整合しているかを見るデザインシステムと一貫性の維持、なぜこの機能が必要なのか、どのユーザーフローに組み込むべきなのかを考える顧客・市場の文脈理解といった領域も同じだ。

最後に、yceffortさんの記事にある表現を借りれば、「システムの複雑さと、チームがそのシステムを理解している度合いとの隔たり」、すなわち認知負債（Cognitive Debt）の管理は、むしろAI導入後により速く広がる領域だ。この隔たりを縮めること自体が、人の役割として残っている。

なくなるのは開発者ではなく、開発者がしていた仕事の形だ。ボトルネックが「作る速さ」から「決める速さ」へ移った。

同じ文脈で、Tossの「開発者はAIに代替されるのか」は、もう少し重い診断を下している。記事の要旨はこうだ。AIはすべての人員を代替するのではなく、徒弟制度の階段（apprenticeship ladder）を取り払いつつある。今のシニアたちが引退する10〜20年後には、複雑なシステムを設計する次世代の人材が不足するだろう。これは「うちの会社は来年どう採用しようか」という次元ではなく、業界全体に仕掛けられた時差式爆弾のような問題だ。（悩みの多い時期に、本当によく書かれた記事だと思う。）

AIが作ってくれる「動く最初のバージョン」は70%だ。「実際のユーザーに提供してもよいバージョン」に至るまでの30%が、人の領域だ。そして、その30%を埋める力は一朝一夕には身につかない。これが徒弟制度の階段をめぐる問題の本質だ。ボイラープレートや単純なコンポーネントを書きながら「手を汚す時間」がなくなれば、その30%を埋められる人も同時にいなくなる。

ペ・フィドンさんの元記事では、「優れたエンジニアに必要な5つの基礎能力」として、良いコードを書くこと、現在価値の最大化（迅速なリリースと長期的な保守性のバランス）、データに基づく意思決定、同僚の効果的な意思決定の支援、継続的な学習を挙げていた。5つすべてがAI時代にも有効だが、その中でも最後の項目が最も危うい位置にある。学習そのものがなくなったのではなく、学ぶ対象が変わった。以前は「このツールをどう使うか」を学んでいたとすれば、これからは「このシステム全体がどう動くのか」を学ぶことに時間を使わなければならない。さらに恐ろしいのは、Evan Moonさんが指摘した「AIがコード作成を代行した瞬間、脳の認知負荷が急激に減る問題」だ。認知負荷が減るのは一見よいことに聞こえるが、その負荷こそが学びの材料だったという点で危険だ。楽になるほど成長しない。

ここで自然に浮かぶ疑問がある。では、ペ・フィドンさんの記事にある3つのトラック（Web特化／プロダクト特化／運用特化）は、もう意味がないのだろうか。

筆者の考えは違う。トラックそのものは今も有効だ。ただし、それぞれのトラックがAI時代に合わせて一段階ずつ進化したと見るのが妥当だろう。トラックごとに景色がどう変わったのか、整理してみよう。

生産者から「検証者」へ

ペ・フィドンさんの元記事では、Web特化トラックはSoftware Engineerという名前でまとめられていた。「インターネット、Webブラウザ、HTML/CSS/JSに対する深い理解と活用」、Webエコシステムのツールの長所と短所を見極める力とトラブルシューティング経験、新しい技術に敏感な姿勢が核心であり、シニアへの道としては、Webエコシステムのツール開発会社のエンジニア／フロントエンドの教育者／複雑なプロダクト組織のテックリードが提示されていた。一言でいえば「ブラウザとHTML/CSS/JSの動作原理を深く掘り下げる人たち」であり、1〜2年前まで彼らの最大の武器は「誰よりも正確にコードを書けること」だった。

AI時代に彼らの価値はどう変わったのだろう。コードを書く速さだけを見れば、AIが追いついた。しかし、**「AIが書いたコードを正確に評価する力」**は、むしろ彼らがほぼ独占していると言ってよい。

AIを使う一般の人：自分が望んだ要件どおりに実装されて、問題なく動いている。
AIを使う開発者：動いてはいるが、この依存関係はこういう問題を引き起こす可能性があり、このパターンはこう改善したほうが規約に合っている。関連部分をもう一度確認しよう。

先ほど取り上げたVeracodeの研究には、XSSで86%、ログインジェクションで88%が防御に失敗したという数字があった。これを見つけて食い止められる人こそ、私たちのような専門家だ。彼らは、AIの成果物を品質管理（QA）するシニアの役割へと自然に進化していく。

もう一つ、専門家の領域にまったく新しいトピックが加わった。生成UI（Generative UI）とAIインターフェースデザインだ。LLMの応答をストリーミング表示するチャットUI、途中で停止できるabortコントロール、Markdownやコードブロックの段階的レンダリング、ツール呼び出しの結果をインラインで表示するUX、Vercel AI SDKやMCP（Model Context Protocol）を利用したアシスタント統合などがその例だ。この領域では、「Webの動作原理を正確に理解しながら、同時にLLMの動作特性も理解して応用・活用できる人」への需要が爆発的に高まっている。

Product Engineerへの自然な進化

プロダクト特化トラックは、最も大きな恩恵を受けたトラックだ。市場と顧客への理解が深く、外部のステークホルダーと頻繁にコミュニケーションを取る人は、AIが加わった瞬間、はるかに強力な武器を手にした。シニアへの道として、グロースエンジニア・コンサルタント／PM・PO・CPOへの転向など、他職種への広がりもあわせて提示されていたのが、このトラックの特徴だ。

興味深い変化は、このトラックの名称がグローバルスタンダードとして定着し始めたことだ。元記事でもすでにこのトラックを「Product Engineer」と呼んでいたが、記事を読んだ当時、筆者にとってはやや耳慣れない表現だった。それから1年が経った今では、Vercelが職務記述書の「Fullstack Engineer」を一斉に「Product Engineer」へ変更するほど定着している。

Lee Robinsonは、Product Engineerの核となる資質として3つを挙げている。

反復（Iteration）重視：デプロイ → フィードバック → 調整のサイクルを素早く回す。
顧客中心性：顧客と直接対話しながらプロダクトを改善する。
実用性：「技術選択はすべて手段にすぎない」。プロダクトの目標に貢献しないツールは思い切って捨てる。

ここで一つ注意したいのは、プロダクト特化エンジニアを「速く作る人」とだけ捉えるのは危険だということだ。AIが登場した今、その危険はさらに大きくなった。「機能を素早く実装すること」は、今やどの職種でもAIツールを使えばできるからだ。Product Engineerの違いは、「顧客の問題を正確に定義し、最小のソリューションで素早く検証する力」にあって、「手が速いこと」にあるのではない。

この流れの中で、Design Engineerという職種が正式なポジションへ格上げされ始めた。Vercelはデザインエンジニアを年俸20万ドル超の正式なトラックとして採用しており、LinearやStripeも同じ方向に動いている。フロントエンドとデザインの間のハンドオフそのものをなくす職種だ。AIが素早く絵を描いてくれるようになったからこそ、「何を描くか」と「描かれた結果が一貫したデザインシステムに沿っているか」を同時に扱う能力が、さらに希少になった結果だ。

AIオーケストレーター

運用特化トラックは、最も劇的に変わりつつあるトラックだ。ペ・フィドンさんの元記事では、このトラックをFull-Stack Engineerに分類し、「プロジェクトの構造・統合・テスト・デプロイに強い関心を持ち、簡単なAPIとインフラを自ら扱いながら、組織の隙間を埋め、プロセスを改善する人」と定義していた。その上に、この1〜2年でAIエージェントそのものを運用する役割が新たに加わり、トラックの裾野が急速に広がっている。

2026年のトレンドを整理する中で、**「コーディングエージェントのオーケストレーション（Orchestrating Coding Agents）」**という概念が中心的なものとして挙げられた。これは、一つのAIに指示することを超えて、複数のAIエージェントを同時に協働させるシステムを設計・運用することを意味する。同じ文脈で、彼は「agent-skills」というフレームワークを提案している。プロフェッショナルなワークフローや品質ゲート、業界のベストプラクティスを、エージェントの動作ロジックに直接組み込もうという意見も出ている。

関連資料をまとめてみたところ、筆者が考える、運用トラックのエンジニアが新たに扱うべきキーワードは次のとおりだ。

MCP（Model Context Protocol）：Anthropicが提案した、LLMと外部ツールを接続するための標準
AIガバナンス：誰がどのコンテキストでAIを使えるのか、シークレットが漏れていないかを管理
エージェント評価（Evaluation）：エージェントが生み出した成果物を自動採点するパイプライン
AIゲート：PRのマージ前に行う自動的なセキュリティ・品質検証、AIコードのラベリング

元記事では、運用トラックのシニアへの道として、大規模組織のプラットフォームチームのエンジニア／テックリード／アジャイルコーチ／テクニカルプログラムマネージャー（TPM）／CTOといった役割を挙げていた。この道は今も有効だが、そこに**「AI開発インフラリード」、「開発者生産性（DevProd）エンジニア」**といった新しい役割が加わったと考えればよい。

3つのトラックがそれぞれ進化する一方で、すべてのトラックに共通して、より重要になった能力がある。本来は5年後を基準に考えたかったが、最近の進歩の速さを見ると、1年という単位さえ長すぎるように感じる。そこで、ひとまず「来年」程度まで視野を狭め、筆者が今後さらに重要になると考える能力を見ていきたい。

5つの能力

一つ目は、仕様（Specification）を書く力だ。 AI時代における「コーディングの出発点」は、キーボードではなく仕様だ。AIに何をさせるかを正確に書き表す力が、コードそのものより重要になった。ここでいう仕様とは、大がかりなRFC文書ではない。ビジネスロジックに期待する動作をコードで記述したテスト、UIコンポーネントのシナリオと視覚的な契約を整理したStorybookのストーリー、データフローの契約を明示する型定義などだ。結局のところ、AIが作った成果物を自動で検証する基準をあらかじめ用意する作業であり、これがない状態でAIコーディングを進めれば、問題が積み重なっていく。

二つ目は、検証力と判断力だ。 AIは、もっともらしいが間違ったコードを自信満々に作り出す。そのため、「AIのコードを素早く正確にレビューする力」そのものが中核になると考えている。セキュリティヘッダー、入力値のサニタイズ、CSRFトークンを見落としていないか、アクセシビリティ（ARIA、キーボードナビゲーション、フォーカストラップ）が保たれているか、レンダリングコスト、メモリ、バンドルサイズなど、パフォーマンスへの影響に問題がないかを見極めることだ。レビューせずにAIスロップをPRへ投げ込むのは、エンジニアとしての職務放棄だ。マージボタンを押すのは今も人であり、その責任をAIに押しつけることはできない。Stack Overflowの調査でシニアのAIへの信頼度が最も低いのも、結局はこうした細部を見抜く目を持っているからである可能性が高い。

三つ目は、システム理解とアーキテクチャ思考だ。 AIは一度に一つのファイルをうまく扱い、フローや関連性を認識する力にも優れている。AIは症状を素早く直すが、能力の高い開発者は根本原因を探す。この力を伸ばす方法の一つは、Architecture Retrospectiveのような意識的な活動を行うことだ。コードの変化が速くなったぶん、チームのシステム理解も意識して引き上げなければ、認知負債が急速に蓄積する。

四つ目は、AIオーケストレーション能力だ。 AIそのものを扱う力も、独立したスキルセットとして分化しつつある。単にプロンプトを上手に書くという次元ではなく、作業を小さなチケットに細分化する力、同じ作業にどのモデルを使うか選ぶ力、エージェントの評価・検証パイプラインを設計する力、エージェントが失敗した際の復旧（rollback）戦略までを、一つのまとまりとして扱う領域になった。Steve Yeggeは、この流れを**6つのwave（traditional → completions → chat → coding agents → agent clusters → agent fleets）**に整理している。

五つ目は、Context Engineeringだ。 2025年半ばからKarpathyとShopifyのCEOであるTobi Lütkeがともに推し始めた概念で、一言でいえば「AIにどのコンテキストを、どのような形で、どの程度見せるかを設計する力」だ。具体的には、プロジェクトの規約、アーキテクチャ原則、禁止事項をAIが参照できる場所にまとめておくCLAUDE.md／rulesファイルの整備、すべてのファイルをコンテキストに入れず、関連するモジュールだけを選んで見せる意図的なコンテキストの縮小、計画 → 実装 → 検証を別々のセッションに分け、コンテキストの汚染を防ぐ明示的な段階分離、デザインシステム、APIスキーマ、モニタリングデータなどの外部コンテキストを標準インターフェースで接続するMCPを通じた外部コンテキストといった形で現れる。Anthropicの公式文書はこれを「the new prompt engineering」と呼び、単一のプロンプトだけでは、システムのアーキテクチャ知識、パターン、組織内の暗黙知を決して収められないと明言した。言い換えれば、「一度でよいプロンプトを書くこと」よりも、「AIが常によいコンテキストを受け取れるよう環境を設計すること」のほうが、はるかに重要になった。

ここまで読めば、自然な疑問が浮かぶ。では、具体的にどう学べばよいのか。筆者が実践している方法は、大きく4つある。

学び方

元記事で挙げられた「継続的な学習」という項目は今も有効だが、学習時間の配分を変えなければならない。

以前は多くの時間を使っていたものの、今では減らしてもよい領域がある。その一方で、以前は難しくて手をつけなかった領域や、時間のかかる複雑な領域もある。後者には、テスト仕様の作成、パフォーマンス測定ツールの活用（Lighthouse、WebPageTest、Chrome DevTools Performance）、アクセシビリティ（WCAG）、セキュリティ（特にOWASP Top 10）などがある。そして、Vercel AI SDK、LangChain.js、MCP、ストリーミングUIパターン、エージェント評価パイプラインのように、まったく新しく身につけるべき領域も存在する。自分に必要な能力が何かを認識し、時間を配分することが重要だ。

AIが生み出すコードは、大きくなりがちだ。1分間に数百行を出力する。そのため、PRのサイズとマージの周期を意識的に管理しなければ、コードレビューそのものが崩壊する。社内では、AI導入後に平均PRサイズが18%増、PR当たりのインシデントが24%増、変更失敗率が30%増となった。先ほどまでのデータとあわせて考えれば、大きく作って一度にマージすると、流れを把握して意図を反映するのが難しくなるため、作業単位を細分化することが重要だ。

Evan Moonさんの記事が指摘した、認知負荷の減少という問題に直結する話がある。1日に1〜2時間は、AIなしでコードを書く時間を別に確保するとよい。アーキテクチャを手で描いてみたり、慣れていない領域のコードを自分で一行ずつ読んだりすることが、その例だ。（筆者も毎日、昼食後の眠くなる時間帯にはAIなしでコードを書いている。昔からの感覚を手放さないよう、つなぎ止めておく時間だ。）

これは単に「昔のやり方を忘れないため」ではない。AIが代わりにやってくれる時間の分だけ、自分自身の深さも育たないからだ。検証力や判断力、システム理解といった能力は、自ら向き合った時間の関数である。

だから、私たちは

ここまで長く書いてきたが、実のところ、AI時代を生き残るフロントエンドエンジニアの姿は、元記事が示した結論とそれほど変わらない。元記事で挙げられていた、優れたシニアエンジニアになるための3つのポイントは次のとおりだった。

基本に忠実であろうと努める（5つの基礎能力を継続的に維持・強化する）。
明示的なリーダーでなくても、模範となる行動によって自然な影響力を発揮する。
与えられた仕事をうまく終わらせるだけで満足せず、前後の文脈に目を配り、大きな影響を生み出す。

これをAI時代の観点から捉え直すと、次のようになる。

AIが作るコードの先にある基礎力（Web、システム、ドメイン）を大切にする。
AIではなく、自分が方向を決める。明示的な責任者でないときでさえ、「どこへ向かうべきか」を判断する。
AIを個人の生産性ツールとして使うだけでなく、チームとシステムのボトルネックを解消するために使う。

OpenAIの権威であるAndrej Karpathyの文章を見ると、彼が今強調している**「agentic engineering」**の核心も、結局は同じだ。システムを設計し、制約を仕様として定め、頭の中ですでに推論を終えた実装をAIで加速する。ツールが変わっても、方向を決めるハンドルは今も人の手にある、という話だ。

元記事が最後に伝えたメッセージも、結局は「与えられた仕事をうまく終わらせることに満足せず、前後の文脈に目を配り、大きな影響を生み出す人」がシニアになる、というものだった。AI時代には、その「インパクト」の定義が変わっただけだ。AIが1時間で作った画面を「動くからこれでいい」とマージする人と、その画面がアクセシビリティ、セキュリティ、パフォーマンス、システム整合性の面でどこまで妥当かを、さらに30分かけて確認する人がいる。1年後にシニアとして認められるのは後者だ。70%（動作）と30%（応用と活用）の境界で、30%側に立つ人が生き残る。

この記事を読むフロントエンドエンジニアの皆さんにも、「これから何をもっと勉強すべきか」という問いに、自分なりの答えを持ち帰ってもらえたらと思う。正解は誰にも分からない。それでも、AIがコードを書く時代であるほど、「コードの先にあるもの」を見る人が生き残るという点については、筆者はかなり確信している。1年後、この景色がさらにどう変わっているのか、そのとき改めて文章にまとめられることを願って、この記事を終える。

（もしこの記事が1年後にはあまりにも当たり前、あるいは古い話に見えるなら、それだけ私たちがうまく対応できたということではないだろうか。）

参考資料

참고 자료

AIフロントエンドエンジニア