AIがほぼ全てのコードを書く時代、ソフトウェア工学はどう変わるのか？

当 AI 写了几乎所有代码，软件工程会怎样？

作者：Gergely Orosz

不再是假设性问题，这是一场即将冲击科技行业的大趋势

今年冬假是开发者们从日常工作中抽身、捣鼓个人项目的好时机，其中也包括用 AI 智能体（AI Agent）把那些做了一半的点子补完。至少我是这么干的：有几个功能我想做好几个月了，但 2025 年一直没腾出手——一个是给大公司用的自助团体订阅功能，另一个是我给 The Pragmatic Engineer 定制的后台管理面板。

没想到，像 Opus 4.5 和 GPT 5.2 这样的大语言模型（Large Language Model）在我布置的中等规模任务上表现惊人：我最终往生产环境推了几百行代码，整个流程就是提示 LLM、审查输出、确认测试通过（包括我让它写的新测试也通过了！），再提示它做点最后的微调。

更魔幻的是，我居然在手机上写出了生产级的软件：我把 Claude Code for Web（Anthropic 的 Web 版编码工具，可在手机上指挥 AI 编程）连上了我的 GitHub，这样我就能用 Claude 手机应用来指挥它修改代码、添加和运行测试。Claude 乖乖地创建了 PR（Pull Request），触发了 GitHub Actions（跑那些 Claude 跑不了的测试），我发现自己在旅途中纯靠手机就能审查和合并带有新功能的 PR。说实话，这些都是低风险的工作，所有业务逻辑都有自动化测试覆盖，但我以前从未体验过用手机“创造”代码并推送到生产环境的快感。

这段经历不只是我一个人有，很多人都深有同感。在我看来，软件工程工具正在经历一场质的飞跃（step change）。在这篇文章中——也是 The Pragmatic Engineer 2026 年的第一篇——我们来探讨一下当前的现状，以及当 AI 开始写绝大部分代码时，对我们开发者意味着什么。

最新模型带来了“顿悟时刻”（a-ha moment）。不只是 AI 公司的开发者注意到模型能力大幅提升，独立开发者同样感受到了。

为什么是现在？十一月和十二月发布的几个模型似乎就是拐点（tipping point）：Opus 4.5、GPT-5.2 和 Gemini 3。

坏消息：专业知识的价值在下降。往前看，原型开发、精通多种编程语言、或者在某个技术栈上的专精，可能都会大幅贬值。

好消息：软件“工程师”比以前更值钱。技术负责人（Tech Lead）的特质更受追捧，初创公司会要求工程师具备产品思维（product-minded），做一个扎实的软件工程师而不仅仅是“写代码的”会更吃香。

残酷的现实：令人不安的后果。生成更多代码会带来更多问题，薄弱的工程实践会更快暴露，开发者的工作生活平衡可能更难维持。

产品管理 vs 软件工程：融合还是分离？产品经理现在可以更容易地生成软件——实现目标所需的工程师更少了——但软件工程师同样不那么需要产品经理了。两个职业的重叠将比以往更多。

1. 最新模型带来了“顿悟时刻”

过去几周，一些资深软件工程师分享了他们的亲身体验，讲述 AI 工具已经强大到可以生成他们日常大部分代码的程度。

Google 首席工程师 Jaana Dogan 对 Claude Code 的进步印象深刻：

"我不是在开玩笑，这一点都不好笑。我们从去年开始就在 Google 尝试构建分布式智能体编排系统（Distributed Agent Orchestration System）。各种方案并存，大家也没达成共识等等。我给 Claude Code 描述了一下这个问题，它一小时内就生成了我们去年才做出来的东西。

まだ完璧ではありませんが、私は現在も改善を続けています。これが私たちが今いる段階です。プログラミング・インテリジェント・エージェントに対して懐疑的な立場なら、ご自身の得意分野で試してみてください。ゼロから複雑なものを構築し、自分で審判になってみてください。

Amp のソフトウェアエンジニアである Thorsten Ball がブログで振り返っています（太字は原文の強調）：

「15 年間、私はコードを書くことが好きだと信じてきました。一文字ずつタイピングする喜び、Gary Bernhardt が言う『タイピングのリズム』への愛、エディターの前で指がキーボードを叩くあの感覚です。

2025 年は、私とプログラミングとの関係について深く振り返った年でした。以前はたまに『私は Lisp の信者になるべきか？』といった考えも浮かびましたが、『私が実際に手書きのコードを書くことをまだ好きなのか？』と考えたことはありませんでした。

この一年で気づいたのは、手書きでコードを記述すること自体が、今では私にとってストレスを感じる行為だということです。」

Vercel の CTO である Malte Ubl は次のように語っています：

「この休暇はあまりにも過激でした。私は二つの大規模なオープンソース・プロジェクトに取り組んでいます（一つはまだ未公開で、もう一つは TypeScript を用いて AI エージェント向けの完全な bash 環境を実装したものです）。

Opus 4.5 が登場してから、世界は全く変わりました。これがなければ、これらの作業を完了することは絶対に不可能でした。現在、Opus に Claude Code を組み合わせることで、まるで高度なソフトウェアエンジニアのようになり、指示を出せば実行してくれます。難しいタスクには依然として監督が必要ですが、フィードバックへの反応が非常に敏感で、基本的に一瞬で修正が完了します。

言い過ぎかもしれませんが、過去の認識を捨て去ってください。ソフトウェア生産のコストはほぼゼロに近づいています。」

古くからの読者なら Malte のことをお忘れではないでしょう。彼は以前、Google で 11 年間を過ごした软件工程（Software Engineering）20 年間のキャリアについて振り返った記事を公開しています。

「これらの人が所属する企業は AI 開発ツールを販売しているのだから、そう言うのは当然だ」と反論されるかもしれません。しかし、どのベンダーとも利害関係のないエンジニアたちも同様の観察結果を示しています：

Ruby on Rails の創設者である David Heinemeier Hansson（DHH）は、AI に対する自身の態度が 180 度転換したことを説明しました：

「粗末で恥ずかしい AI の出力があるからといって、AI 自体の素晴らしさを否定してはいけません。コンピュータをネットワークに接続して以来、これほど興奮する出来事はありませんでした。もしあなたが 2025 年に AI に対して悲観的または懐疑的な立場を取っていたなら、2026 年には楽観主義と好奇心を持って再出発してみませんか？

去年の夏、私はまだ Lex Fridman（著名なテクノロジー・ポッドキャストのホスト）の番組で、AI に直接コードを書かせるべきではないと述べていました。しかし後から振り返れば、その抵抗感は当時のモデルが十分ではなかったことに起因していたのです！私が AI が生成したコードを修正するために費やした時間は、最初から自分で書く時間よりも多かったです。今は完全に逆転しています。」

Tailwind CSS の創設者である Adam Wathan は次のように述べています：

「今、AI を使わずに手動で正確な構文を入力しなければならないときは、まるで苦役を強いられるような気分になります。驚きと安堵を感じたのは、プログラミングが依然として面白いこと、むしろ以前よりもさらに面白くなったことです。

私が現在抱えている最大の課題は、この生産性向上を最大限に活用できるほど多くのアイデアを思いつけないということです。」

「AI による粗末な作業」から業界全体を震撼させるまで

広く知られる「気づきの瞬間」の一つは、OpenAI の共同創設者である Andrej Karpathy によるものです。Karpathy は長年 OpenAI の運営に関与しておらず、率直な評価と AI ツールへの批判で知られています。昨年 10 月、彼は著名なテクノロジー・ポッドキャスト『Dwarkesh』番組において、AI コーディングツールに対する見解をまとめました（太字は原文の強調）：

「全体的に見て、モデルはまだ完成していません。業界があまりにも大きな一歩を踏み出しすぎたと感じます。すべてが素晴らしいかのように振る舞おうとしていますが、実際にはそうではありません。

彼らはこの事実を直視したがりません。おそらく資金調達などに忙殺されているのでしょう。何が起きているのかはわかりませんが、私たちはまさにこのような居心地の悪い中間段階にいます。モデル自体は確かに強力ですが、まだ多くの研磨が必要です。

現時点では、自動補完が私にとって最も効果的です。ただし、一部のコードについては LLM エージェント（大規模言語モデル・エージェント）を使って記述することもあります。」

2 ヶ月後、この見解は完全に修正されました。Karpathy は 12 月 26 日に次のように書き（太字は原文の強調部分です）：

「これまで以上に、自分がプログラマーとして時代遅れになっていると感じたことはありません。

この職業は大規模に『リファクタリング』（refactored、はい、彼は職業自体の変革をプログラミング用語で表現しました）されており、プログラマーが直接貢献するコードの割合はますます減少しています。

もし私が過去 1 年間に登場したツールすべてを繋ぎ合わせることができれば、私の能力は 10 倍になると感じています。この波に乗れなかったのは、純粋に自分の実力が不足していたからです。

既存の抽象層の上に、さらに新しいプログラミング可能な抽象層が追加され、習得する必要があります：エージェント、サブエージェント、それらのプロンプト、コンテキスト、メモリ、パターン、権限、ツール、プラグイン、スキル、フック、MCP、LSP、スラッシュコマンド、ワークフロー、IDE 統合……これら本質的にランダムで、エラーを犯し、不透明であり、絶えず変化する実体の強みと罠を把握するために、完全なメンタルモデル（心構えの枠組み）を構築する必要があります。それらが突然、かつては順調だった伝統的なエンジニアリングと混ざり合ってしまったのです。

明らかに、強力な異星のツールが人々に配布されましたが、使用説明書は付いておらず、誰もが 9 級地震の中で、どうやってそれをしっかり握り、どう操作するかを自分自身で模索している状態です。

Claude Code の創造者である Boris Cherny はこう応えています。彼によると先月提出したすべてのコードは AI が書いたものです：

「先月はエンジニアとして初めて IDE（統合開発環境）を開くことすらありませんでした。Opus 4.5 が約 200 の PR を作成し、その行ごとのコードすべてを彼が書きました。ソフトウェア工学には根本的な変化が起きており、私たちような早期採用者や実践者にとっても、最も難しい部分は期待値を絶えず再調整することです。しかし、これはまだ始まりに過ぎません。」

The Pragmatic Engineer は以前、Boris やチームの他の創設メンバーと対談し、Claude Code がどのように作られたかについて深掘りした記事を発表しました。

11 月と 12 月のモデル発表は、AI のプログラミング能力が本当に強くなる転換点のようです：

Gemini 3（Google、11 月 17 日発表）：Google がこれまで発表した中で最も強力なプログラミングモデル

Opus 4.5（Anthropic、11 月 24 日発表）：同社が持つ最強のプログラミングモデルであり、Claude Code のデフォルトモデルとなっています

GPT-5.2（OpenAI、12 月 11 日発表）：Codex を駆動しており、Opus を搭載した Claude Code と互角のパフォーマンスを発揮

Opus 4.5 と GPT-5.2 の両方を実際に使用しましたが、どちらもプログラミングにおいて非常に強力です。これは決してマイナーな意見ではありません。Peter Steinberger は約 20 年の経験を持つソフトウェアエンジニアであり、有名 PDF 処理フレームワークである PSPDFKit の創設者ですが、彼のブログでは GPT-5.2 に対する印象を共有しています：

「GPT 5/5.1 から 5.2 への移行は劇的なものです。GPT 5.2 が登場した後、私が作成した CLI ツール『oracle』（エージェントが立ち往生した際に脱出を手伝うためのツール）を使用する機会が大幅に減りました。私は時々 GPT 5 Pro を研究のために使用しますが、モデルに『oracle に問いかける』回数は、1 日に数回から週に数回へと激減しました。

惜しいとは思いません。『oracle』を作るプロセス自体が非常に面白く、ブラウザの自動化や Windows に関する多くのことを学びました。また、以前は軽視していた『skills（スキル）』という機能についてもようやく時間を割いて研究することができました。この事実は、5.2 が実際のプログラミングタスクにおいてどれほど進歩したかを示しています：私が投げかけた課題に対して、ほぼすべてをワンショットで解決してくれます。」

Simon Willison は大規模言語モデル分野で私が常に注目している独立系のソフトウェアエンジニアリングの専門家ですが、彼も同様の観察点を指摘しました：

私の実感では、11 月に発表された GPT-5.2 と Opus 4.5 は確かに転換点を示しています。つまり、モデルの漸進的な進化が突如として見えない能力のラインを越えたのです。一瞬で、これまで非常に難しかったとされるプログラミング問題の数々が解決可能になりました。

Gemini 3 Pro もこの仲間に入るべきかもしれませんが、私はまだ、博識なベテランエンジニアたちから、他の 2 つのモデルと同じレベルの驚きというものを聞いていません。

『The Pragmatic Engineer』ポッドキャストの第 1 回のゲストは Simon で、タイトルもまさにその通りです。『ソフトウェアエンジニアのための AI ツール——ハッタリなしで』——Simon はこの姿勢を常に実践しています。

当時、私を含む多くの人々が懐疑的だった予測の一つが、Anthropic の CEO Dario Amodei によるものです。昨年 3 月、彼はこう述べていました。

「私は、AI が今後 3 か月から 6 ヶ月のうちにコードの 90% を書くようになると思います。さらに 12 ヶ月後には、私たちはほぼすべてのコードを AI が書く世界で暮らしていることになるでしょう」

その結果は 12 月に実現しました。Cherny が Claude Code に貢献したコードは 100% AI によって生成されました。批判的な立場から言えば、Claude Code はオープンソースプロジェクトではないため、この主張を検証するのは難しいと指摘できます。また、Claude Code の創造者自身がその能力を誇示したいと思うのは当然のことです。しかし、私は Boris と話し、彼を信頼しています。同時に、私が Claude Code を使用した体験も彼の言葉と一致していました。私が提出したすべてのコードは、Claude Code によって生成されたものです。

コードが私の期待に沿わない場合、私は引き続きプロンプト（指示）を送って LLM（大規模言語モデル）に修正を求めます。Boris と同じく、私はもう手書きでコードを書くことはありません——できないからではなく、必要がないからです。モデルは十分にその役割を果たせます。私が手書きすることも可能ですが、モデルに任せた方が明らかに速いです。

私の非常に熟悉しており、IDE（統合開発環境）内で自在に操作できるコードであっても、エージェントを使って編集する方が、少なくとも手動で操作するのと同じくらい速く、むしろ速いと感じています。ただし、私は時々 IDE を開きます。なぜなら、自分がこれらの作業を手で行う能力を維持したいからです。

私の個人的なユースケース——技術スタックは TypeScript、Node/Express、React、Postgres です——においては、「AI がコードの 90% を生成できる」という主張はほぼ事実です。私が知る限り、Go、Rust、そして他の多くのトレーニングデータを持つ主要言語やフレームワークにおいても、状況はますます同様になりつつあります。興味深いことに、LLM が C コードを書くのも非常に優れているようです。Redis の作者 Salvatore Sanfilippo もこの点に気づいています。

本稿の続きは以下の仮定に基づいています：AI プログラミングツールは今年、多くの開発者やチームに対してコードの 90% 以上を生成できるレベルに達するでしょう。最も早くこれを実現するのは、製品と市場の適合（product-market fit）を探しているスタートアップ企業です——彼らにとって試行錯誤的な作業は本質的に問題になりません——そして、既存のコードベースを理解する必要なくゼロから構築する新規プロジェクト開発（greenfield development）です。

もちろん、多くのシナリオでは AI プログラミングツールへの完全な依存はまだ現実的ではありません。特定のコードベースや文脈においてまだ十分に機能しないためかもしれませんし、あるいは開発者があえてそれに依存しないことを選んでいるのかもしれません。

しかし、考えるべきは、ほぼすべてのコードがプロンプトによって AI によって生成され、開発者による手打ちではない環境において、ソフトウェアエンジニアリングという職業がどこへ向かうのかということです。これは劇的な変化をもたらすでしょうが、具体的にどうなるのでしょうか？良い可能性、悪い可能性、そして残酷な可能性を一つずつ検討していきましょう。まずは潜在的な悪影響から始めます。

1. 悪いニュース：専門知識の価値が低下する

過去に高価値と見なされていたいくつかの能力は、ますます AI に委ねられることになります：

プロトタイプ開発。Lovable や Replit のようなプラットフォームは、明確に非技術者がソフトウェアを構築するためのツールとして位置づけられています。最近の広告では、Replit が NBA 伝説の選手であるシャキール・オニール（Shaquille O'Neal）を起用し、彼が「感覚プログラミング（Vibe Coding）」と呼ばれる手法で、「史上最高の 5000 件のナンパフレーズ」アプリを作成しました。

開発経験ゼロのオニールが感覚プログラミングで作り上げたアプリは、せいぜいプロトタイプに過ぎません。出典：Replit

さて、AI ツールの登場により、製品マネージャー、デザイナー、ビジネス担当者が自らプロトタイプを構築できるようになり、もはやアイデアを現実にするために開発者を雇う必要がなくなりました。その一方で、各開発者には概念実証（PoC）アプリケーションを迅速に生成できることが期待されるようになり、これが基本的なスキルとなるでしょう。

プログラミング言語の多面手（language polyglot）としての価値は低下するかもしれません。過去には、複数のプログラミング言語を精通したエンジニアが重宝されていました。なぜなら、チームは通常、自社の技術スタックに経験のある人材を採用したがるからです。Go を使うチームは Go のエキスパートを好み、Rust や TypeScript を使うチームも同様です。ただし、いくつかの先駆的なチームでは、候補者が使用する特定の言語に精通しているかどうかよりも、優秀なエンジニアであればいつでも新しい言語に習得できると信じている傾向があります。

しかし、AI がコードの大部分を書く時代になると、複数の言語を知っていることの優位性はそれほど大きくなくなります。なぜなら、どのエンジニアでも任意のコードベースに入り込み、AI に機能を実装させることができるからです——そして AI は概してそれなりの実装結果を提示します。さらに素晴らしいことに、AI を使ってコードベースの各部分を説明してもらうことで、新しい言語への習得が、AI がない場合よりもはるかに迅速になります。

言語特化型やフロントエンド/バックエンド特化型の役割に終止符が打たれるのでしょうか？2000 年代初頭を思い起こせば、採用広告の多くは特定の言語の開発者を求めていました：ASP.NET 開発者、Java 開発者、PHP 開発者などです。2010 年代半ばからは、技術スタックの方向性で採用する企業が増加しました：バックエンド開発、フロントエンド開発、iOS/Android ネイティブ開発、クロスプラットフォームモバイル開発などです。バックエンド分野では、Go に精通した開発者が TypeScript、Scala、または Rust へ転向することは一般的に受け入れられています。特定の言語を重視する求人が残っているのは主にネイティブモバイル開発の領域で、これは iOS と Android のフレームワークの違いが甚だしく、どちらかを深く理解している必要があるためです。

しかし今日では AI が存在するため、バックエンドエンジニアはプロンプト（指示）を通じて、それなりのフロントエンドコードやクロスプラットフォームコード、さらにはネイティブモバイルコードさえも生成できます。このツールがあれば、スタートアップ企業がフロントエンドとバックエンドの開発者を別々に採用し続ける理由が想像できません。彼らは信頼できる専門家 1 人を雇い、その人が AI を活用して技術スタック全体で問題を解決できると信じるだけで十分でしょう。

明確に定義されたチケット（工数票）の執行は、ますます AI に委ねられるようになります。例えば、JIRA や Linear で詳細が記述されたチケット——バグ報告でも小機能の要望でも——を AI に実装させます。現在、Cursor チームには自動化プロセスが整備されており、Linear のすべてのチケットが自動的に Cursor へ転送され、そこで完結してしまいます。開発者は単にマージするか、さらに反復するかの判断を下すだけで済みます。渡されるコンテキスト（文脈）が多く、モデルの能力が高ければ高いほど、出力をそのままマージできる確率は高まります。

これは、特に階層が明確な職場において大きな転換点となるでしょう——プロジェクトマネージャーや製品マネージャーは長年、詳細なチケットを作成して開発者に指示を出す役割を担ってきました。

リファクタリング（コードの再構築）も、ますます AI に任せるようになるでしょう。AI はすでにリファクタリングに非常に優れており、ツールは今後さらに進化します。手動でリファクタリングを行うよりも、AI に対してどのようなリファクタリングを望んでいるかを伝える方がはるかに時間がかかります。もちろん、AI の登場以前から、現代の IDE（統合開発環境）も強力なリファクタリング機能を提供していました——例えば、コードベース全体での関数やクラスの名称変更、関数の抽出などです。

もちろん、AI が失敗するリスクは常に存在します、特に大規模なリファクタリングにおいては。したがって、今年こそコード検証（コードバリデーション）の重要性がさらに高まることになるでしょう。

生成されたコードを注意深くレビューする必要があるでしょうか？状況によります。AI が生成したコードは冗長であったり、既存の抽象化を再利用するのではなく、再び車輪を発明したりする可能性があります。しかし、概念実証を行う場合や、プログラムのパフォーマンスが重要ではないシナリオでは、これらは完全に許容されます。

ソフトウェアエンジニアのピーター・シュタインバーガー氏は新しいプロジェクトに取り組んでおり、AI が生成したコードをほとんど見なくなったと話しています：

「現在、私はあまりコードを読みません。コードの流れを目で追うだけで、時々重要な部分に注目する程度です。正直なところ、大部分のコードは読みません。各コンポーネントがどこにあるか、全体構造がどうなっているか、システムがどのように設計されているかは理解しています——通常これだけで十分です。

現在、真に重要な意思決定は言語/エコシステムと依存関係の選定です。私がよく使う言語は、Web 開発には TypeScript（TypeScript）、コマンドラインツールには Go（Go）、macOS の機能が必要だったり UI が必要な場合は Swift（Swift）です。数ヶ月前までは Go には全く興味がありませんでしたが、試してみたらエージェントが非常に優れた Go コードを書き、シンプルな型システムのおかげでコードチェックも高速に実行できることが分かりました。」

それでも、既存の成熟したソフトウェアを拡張する場合や、セキュリティ上の問題を回避する必要がある場合は、コードを読むことが依然として重要です。大まかに言って、リリースされたコードに問題が発生してビジネスに影響を与える場合、テストとコードレビューの両方を行いたいと思うはずです。

1. 朗報：ソフトウェアエンジニアは以前よりも価値がある

開発者がすべての時間をコード作成に費やすわけではありません——少なくとも職場の大多数ではそうではありません。Atlassian の 2025 年開発者体験レポート（調査参加者 3,500 名）によると、開発者が実際にコードを書くのに費やす時間は週平均わずか 16% で、残りの時間はすべて事務作業に費やされています。私が Microsoft、Skyscanner、Uber で働いていた頃を振り返ると、この割合は非常に現実的です：同僚のサポート、コードレビュー、設計とバグに関する議論、計画会議、チーム会議、全社会議への参加、採用活動、関係者との連絡などです。

つまり、2026 年に AI がすべてのコードを書いたとしても、それは週の作業時間のほんの一部を解放するに過ぎません。また当然のことながら、AI に正しいコードを書かせるには、まず適切なプロンプトを与える必要があります。

技術リーダーの資質は、以前にも増して求められます。AI が定義された明確なタスクであれば何でも実現できる時代において、AI が正確にコードを生成するためのタスク（チケット）を作成するのは誰でしょうか？「完璧」なタスクを作成するには、以下の 2 つの側面を明確に記述する必要があります：

機能的な作業におけるユーザーニーズ：機能がどのように動作すべきか、さまざまな境界条件で何が起きるべきか

非機能要件（nonfunctional requirements）に関する技術的詳細：パフォーマンス、アクセシビリティ、信頼性に関連する事項

非技術者がユーザー向けの詳細なタスクを作成することは可能ですが、非機能要件を明確に記述するのはほぼ不可能です。ここがソフトウェアエンジニアリングの知識がますます重要になる場所です。ユーザー視点で考え、作業を定義された明確なタスクに分解できる実践的なエンジニアは、より重宝されるようになります。これは優れた技術リーダーがすでに備えている能力そのものです。唯一の変化は、コーディング分野で急速に成長したい入門レベルのエンジニアであっても、この能力を習得する必要があるということです。

テストとテストインフラストラクチャの能力は、これまで以上に重要になります。エージェントをより効率的にし、ハルシネーション（Hallucination：AI が存在しないコードや API を捏造すること）を減らすには、自分の作業を検証するためのフィードバックループが必要です。迅速に実行可能な検証手段としては以下が挙げられます：

静的解析の実行（定義されたルールに従っているか？）

自動化テストの実行（すべてのテストはパスしたか？）」

私個人としては、ユニットテストやインテグレーションテスト、さらにはエンドツーエンドテストがない状態で、AI が生成したコードを信頼できるとは想像できません。率直に言って、現時点では特定の指示を与えない限り、AI エージェントがテストを書く能力はまだ十分ではないと感じています。機能を構築するようプロンプトを与える際にも、期待するテストの種類を指定し、テストが意図通りに記述されているかを確認しています。

テストも CI/CD フローに統合して実行する必要があります。もちろん、コードベースが大きくなるにつれてテストの実行速度が遅くなることがありますが、その際はエンジニアが袖をまくり上げてテスト速度の最適化を行うか、あるいはどのテストが不要かを判断する必要があります。この能力は過去には上級ソフトウェアエンジニアにのみ要求されていましたが、今後は AI によって生成されたコードを大量に使用するすべてのエンジニアにとって、基礎的なスキルとなる可能性があります。

より多くのスタートアップ企業において、「製品思考（product thinking）」を持つことが基本的な要件となるでしょう。AI がますます多くのコードを生成するようになれば、「何をすべきか」を明確にする重要性がさらに高まります。すでにいくつかの機敏なスタートアップ企業が「プロダクトエンジニア（product engineer）」を採用しています——彼らは自ら行うべき課題を発見し、ミニマムな製品責任者とソフトウェアエンジニアの両方の役割を兼ね備えています。

プロダクトエンジニアモデルを採用しているスタートアップ企業には WorkOS があり、そこでは約 80 人のエンジニアに対して製品マネージャーはたった 1 人しかおらず、全員がプロダクトエンジニアです。また Linear も設立当初数年間は製品マネージャーを全く擁していませんでしたが、現在も同様にプロダクトエンジニアを採用しています。

優れたアーキテクチャ上の意思決定を行うことがより重要になります。コード生成が速く多くなるほど、ソフトウェアの構造を明確にすることが必要となります。ソフトウェアはモノリシックなアプリケーションとして構築すべきか、それとも独立してテスト可能なサービスとして構築すべきか？インターフェースと境界はどこにあるのか、各部分をどのようにテスト可能にするのか、エンドツーエンドのテストやモック（Mock）、フェイク（Fake）はあるのか——このリストは非常に長くなります。

これらはすべて AI に明確に指示し、従わせるべき意思決定事項であり、AI に自由に任せてはいけません。そうしなければ、メンテナンスが困難なソフトウェアに陥り、たとえ AI があっても救済することはできません。

技術的負債（tech debt）の追跡と処理がより重視されるようになります。コード量が増えるほど技術的負債も増え、追跡・処理すべき事項も多くなります。経験不足のエンジニアはすべての問題に気づくことができず、信頼性の課題や性能の低下、さらなるバグが静かに蓄積し、他の部分に影響を与えずにコードを修正することも次第に困難になります。私たちが以前作成した技術的負債返済ガイドは、AI による大量コード生成の時代において、これまで以上に適用可能となります！

信頼性が高く、高性能で、スケーラブルかつ安全なシステムを構築できることは、極めて貴重なスキルとなるでしょう。誰でも「まあ使えるがいつ崩れてもおかしくない」ソフトウェアを生成できるようになる中で、常に安定して高品質なコードを生み出すエンジニアはより重宝されるようになります。

単一のプロンプト（指示）だけで AI に安全で高性能なコードを書かせることはできません：自分が何を求めているかを理解し、非機能的要件をどのように検証するか、アーキテクチャをどう設計するかを知り、それに基づいて AI に指示を出す必要があります。時には AI を脇に置いて、自らコードを書き直したり設定を変更したりして細部を正しく仕上げる必要があるかもしれません。归根结底（結局のところ）、いつ自分の専門知識を使うべきかを知ることも、それ自体が一つの能力です。

単なる「コードを書く人」ではなく、堅実なソフトウェアエンジニアであることが、以前よりもより求められます。上記の要点をまとめると、ソフトウェア構築における「エンジニアリング」の部分がこれまで以上に重要になるということです。私たちはより多くのコードを生成しますが、そのコードを確実に動作させるためには、エンジニアリング手法が確かなものであり、フィードバックループが密接に機能している必要があります。

昨年、「フィーリングプログラミング（vibe coding）」は非技術者の間で急速に流行しましたが、多くの人々がすぐに気づきました：スーパー AI を使ってコードを生成したとしても、実際に使えるソフトウェアを構築するのは実は難しいのです。半年前、私は LinkedIn でこのテーマに関するミームを作成しました：

素早くコードを書くことが高品質なソフトウェアのボトルネックではない

1. 残酷な現実：不安を招く結果

より多くのコードとより多くのリソース消費 = より多くの問題？ AI を活用するエンジニアは、より多くの PR（プルリクエスト）を提出し、より多くのコードを生み出しています。これはすでに証拠として示されています。以下は、Michael Novati 氏の GitHub での活動状況の比較です：2024 年（ほとんど AI を使用しない場合）と 2025 年（AI を大量に使用した場合）。

AI 利用後、PR 数が倍増。出典：Michael Novati

Michael は Meta に在籍していた際、同社で最も生産性の高い開発者であり、Meta の「コーディング・マシン（Coding Machine）」というラベルは彼のために設けられたものです。私たちは Michael をゲストに招いたポッドキャスト番組を制作したことがあります。

その後、彼のペースが緩むことはなく、昨年、フルタイムで開発に取り組むスタートアッププラットフォームにおいて、月間 400〜600 回（1 日あたり 15〜25 回！）というペースで、1,500 以上の新機能と 800 以上のバグ修正に貢献しました。彼はより詳細なサマリーを公開しています。

明白なことは、コード量が増えれば増えるほど、バグやセキュリティ脆弱性、その他の問題が滋生する余地も大きくなるということです。また、これによりリソース消費も増加する可能性があります——開発者やチームはより複雑なサービスを構築し続け、より多くのデータを保存し、より多くの計算資源を消費することになるからです。

コードの質が粗雑化する恐れがあります。予測される通り、AI によって生成されたコード量を増やすチームの多くにおいて、品質基準がそれに伴って向上するとは限りません——少なくとも初期段階ではそうではないでしょう。エンジニアたちは以前は少量の小規模なプルリクエスト（PR）をレビューしていましたが、現在は同じ基準で、より頻繁に、より大規模になる PR をレビューする必要があり、それは非現実的です。

初期データによると、本番環境へデプロイされるコードの品質は低下しつつあります。Cortex 2026 ベンチマークレポートでは 50 名以上のエンジニアリングリーダーを対象とした調査が行われ、変更失敗率（change failure rate：障害やロールバックを引き起こすデプロイの割合）が 30% 上昇していることが判明しました。

脆弱なソフトウェア工学の実践は、問題をより迅速に露呈させます。自動化テスト文化が欠如していたり、コーディング規約に従っていなかったり、あるいは観測性（observability）インフラが脆弱であったりするチームでは、回帰バグが本番環境へ押し出されるケースが増え、さらにはオンライン障害に直面する可能性も高まります。理由は単純です——納品スピードが加速したことで、「悪いもの」が本番環境に衝突する頻度と速度が高まっているからです。

「コードを書くこと」しかできず、ソフトウェア工学の能力を備えていない開発者に対する需要は低下する可能性があります。もし開発者が、複雑なプロジェクトを分解する能力や、テスト容易性や観測性を意識したアーキテクチャ設計能力、そしてスケーラブルで高信頼性のシステムを構築する能力といった、ソフトウェア工学に関するスキルを示せない場合、就職がより困難になるでしょう。非技術者であっても AI を使ってコードを生成できる時代において、開発者に求められるスキルは「コードを書くこと」そのものを超えたものでなければなりません。なぜなら、AI はすでにその役割を果たし始めているからです。

仕事と生活の境界線を維持することがさらに難しくなるでしょうか？ 私には、2026 年が AI エージェントによるリモート仮想サンドボックスでの実行が主流となる年になるという予感がします。これは、開発者としてブラウザやスマートフォンを通じて指示を出し、結果を検証し、コードをデプロイできることを意味します——作業用 PC が全く不要になります。この変化は、かつて Slack などのコミュニケーションツールがモバイル端末に対応した際と同じです——開発者はいつでもどこでも連絡が取れるようになり、ネットワークがあればどこでもバグ修正が可能になります。

これが問題となる可能性があります。元 Datadog エンジニアの Donovan Dicks は次のように指摘しています：

「懸念しているのは、モバイル体験の向上が、従業員の私生活と職業責任との境界線をさらに侵食する恐れがあることです。すでに多くの人が、スマートフォンに Slack や Teams などのアプリをインストールし、いつでも雇用主から連絡を受けられることによるストレスを抱えています。また、通常の勤務時間外に行う作業には追加の報酬がありません。エンジニアがキーボードから離れている（AFK）状態でもより多くの作業を行えるようにすることは、彼らが雇用主に搾取されるリスクをさらに高めるだけです。

米国の給与所得者として、深夜の障害対応や通勤中の返信、あるいは勤務時間外に完了したタスクに対して、私は一度も追加報酬を受け取ったことはありません。『PC の前ではない』状態は、私の個人時間をより多くの職業責任が侵食しないように守るための最後の防衛線のひとつです——特に休暇中において。もしモバイルでのコーディングワークフローが可能になり、それが常態化すれば、この防衛線はもはや存在しなくなるでしょう。

ツールの進化には確かに興奮を覚えますし、個人的なプロジェクトでこれらのツールを遊ぶのも好きですが、職業的なワークフローに導入する際にはより慎重になります。これが業界全体にどのような影響を与えるのか、非常に興味深く思っています。」

初级工程师被逼着快速成长为高级工程师？在 AI 生成大部分代码的新时代，对软件工程师的预期似乎变成了：

能够跨栈工作：从后端到前端，甚至到移动端

具备产品思维（product-minded）：主动与客户交流，不用别人催就去修 Bug，主动提出产品改进建议

尽早思考架构决策，在软件结构设计上做出务实的选择

能亲自动手搞自动化测试和可观测性

持续管理技术债（tech debt）

这些要求在以前是头部公司对高级或 Staff 级别工程师的基本标准，而现在正在变成对入门级工程师的基本期望。然而在 AI 时代之前，入门级工程师要花好几年时间写大量代码，在与资深同事的合作中逐渐习得这些技能。

这种变化会推动应届毕业生更快地“成熟”吗——跳过 AI 已经擅长的“写代码”阶段，直接进入软件中的工程部分？如果是的话，这一定是坏事吗？以我的经验来看，应届毕业生能力很强、学得很快，我相信很多人会在承担那些以前只有资深开发者才能胜任的角色时，表现得相当出色。

计算机科学教育会成为新人入行的刚需？如果我是一个招聘经理，要招一个应届生，我需要的是一个理解“高级”概念的人。他们需要在零年行业经验的情况下，就懂软件架构模式、自动化测试、以及技术债的概念和重要性。哦，他们大概还得有在团队里用 AI 工具做过项目的经验。这要求看起来确实很高。

但事实上，一些大学的课程体系已经能提供这些了。在 3-5 年的学制中，它们兼顾理论和实践，并组织团队项目。与此同时，像哈佛这样的顶尖学府已经在开设大语言模型相关的课程。其他大学肯定也会迅速跟上。

在一个写代码不再那么值钱、但软件工程的其他部分更加值钱的世界里，以软件工程和计算机科学为核心的学术教育可能会成为进入这个行业不可逾越的门槛。大学还充当着“垃圾过滤器”的角色：当 AI 生成的申请塞满了招聘通道时，与本地高校直接合作能让雇主更有把握确认候选人是真人。

代码和软件的大爆发，总得有人为此负责。如前所述，我们几乎可以肯定会看到更多代码被生成、更多软件被交付、更多的维护工作需要完成！这对基础设施提供商来说无疑是利好——云服务商、基础设施工具商、以及软件正确性验证工具都将从中受益。

而对于任何上线运行的生产软件，当出了问题时，总得有人为此负责。我不认为这个人会是非技术人员，而是那些理解 AI 工具生成的代码、能够维护这些代码的专业软件工程师——他们有能力、有知识，对基于自己的提示词部署到生产环境的代码承担责任。

1. 产品管理 vs 软件工程：融合还是分离？

我见过好几位产品经理对这场变革兴奋不已，因为 AI 能按规格生成代码，这或许意味着产品经理可以不需要软件工程师就能构建软件。但我认为事情不会这样发展：相反，软件工程和产品管理之间的边界可能会比以前更加模糊：

软件工程师变得更有产品思维，与客户走得更近。比如，他们可以迅速修复客户反馈的 Bug，而不需要产品经理的分诊或介入

产品经理变得更加亲力亲为，自己构建原型给客户演示——有时甚至不需要工程师参与，偶尔还能自己提交 Bug 修复让工程师合并

我还预期工程团队会变得更小更高效，告别过去那种更为正式的交接模式——比如产品经理写一份产品需求文档（PRD）扔给工程团队去实现新功能。

Linear 联合创始人 Karri Saarinen 这样描述这种转变——“中间层软件工作”正在消失，也就是那个曾经占据大量时间的“写代码”环节：

純粋なコーディング・エージェントのワークフローは、現在、目標、文脈、タスクに基づいて直接使用可能なコードを直接生成できるようになりました。これらはより独立して動作し、あなたが実際にコードに触れる機会はますます減り、IDE への依存も小さくなっています。IDE は単なる記述ツールから、コードを閲覧するためのブラウザへと変貌しつつあります。

これらのシステムがさらに進化するにつれて、この中間層はますます薄くなっていきます。手動で意図を実装に翻訳することに費やす時間は減少していきます。

実際に何を構築すべきかという問いこそが、依然として最も重要な問題です。（……）

[ソフトウェア] の設計とは、この意味において、成果物やツールに関するものではありません。それは、創造性、探求、調査、そして議論を通じて意図の明確さを形成し、磨き上げるプロセスです。何が重要で、どのような制約が適用され、どのようなトレードオフが許容されるかを決定することです。優れた製品とは、この実行を真に意味あるものにする何か——すなわち明確さ——を追求するものです。

この時代において、エージェントを指導し管理すること自体が一つの職人芸となっています。

コードを書くことはもはや解決策を構築するようなものではなく、良い解決策が創発するための条件を整えるようなものに似ています。"

ある一点は確実です：より強力な AI コーディングツールがソフトウェアエンジニアリングの進化を推し進めるにつれ、製品管理もまた進化していくでしょう。

もし誰かが本文冒頭の論断——「AI は多くのチームでコードの 90% 以上を書くようになる」——に反論しようとするなら、それは全く妥当なことです。私は実際に大手テクノロジー企業で働いた経験がありますが、そこでは開発者たちが本来ほとんどコードを書かず、複雑さはコード以外のあらゆる側面に存在していました！そのような環境では、AI が大きな助けや衝撃をもたらす可能性は低いです。

私の「気づきの瞬間（a-ha moment）」さえも、比較的シンプルなコードベースにおいて起こりました——そのプロジェクトには優れたエンジニアリングプラクティス（すべてのものにテストが存在する）があり、製品自体のリスクも低く、さまざまな試行錯誤が容易でした。

しかし一方で、最新の AI ツールは確かに私が求める品質基準——「書かれたコードは私自身が書いたものと同じくらい良い」——に達しています。これは非常に大きな意味を持ちます！

予見される未来では、初期段階のスタートアップは、製品と市場の適合（product-market fit）を見つけるまで、AI に主導権を委ねてプロンプトで全てのコードを書かせ続けるでしょう。本文が探求するのは、このパターンが普及し、IDE 内で手動でコードを入力することが時間と労力を要するものとなった際に何が起こるか——まるで今日では自動補完機能のないテキストエディタでコードを書く人が誰もいないのと同じようにです。

朗報は：チームが AI によるコード生成に依存すればするほど、ソフトウェアエンジニアリングの基本スキルがより重要になるということです。コードが増えれば問題も増え、それらをより早期に発見し、体系的に解決する必要があります。これが優れたソフトウェアエンジニアリングがこれまで行ってきたことであり、過去同様、現在もまたそうなのです。

私はこれを良いことだと考えています：AI は検証（なぜなら AI を完全に信頼することはできないから）、観測可能性（本番環境で実際に動作していることを確認する）、アーキテクチャ（より多くのコードを生成し、より速く生成するため、これらのコードは適切に組織化される必要がある）、そして制約（納期が速くなるほど、リソース使用量、パフォーマンス、信頼性などの天井に早くぶつかることになる）について真剣に考えさせるでしょう。

残念なことに：変化は非常に急速に進む可能性があります。Claude Code が Boris Cherny の頭の中で生まれたアイデアから誕生してまだ 1 年余りですが、OpenCode、Codex、Factory、Amp、Cursor、そしてさらに強力なエージェントなど、同様のツールがすでにソフトウェアの書き方を変え始めています。変化はテクノロジー業界の常態ですが、これほど急速に、かつ業界全体を同時に席巻したことを私は記憶していません！

还有一种失落感（注：原文の中国語部分は日本語訳として「ある種の喪失感」として扱います）。 徐々に受け入れつつある現実があります：今後は、私が本番環境にデプロイするコードの大部分が AI によって書かれるようになるでしょう。それはすでに私よりも速く書き、結果も私が手入力したものと同じくらい良いものです。私があまり詳しくない言語やフレームワークにおいては、むしろ私よりも優れた成果を出しています。

何か貴重なものが奪われていくような感覚があり、その変化は突然訪れました。コードを上手に書くには多大な努力が必要です——動くコードを書く方法を学び、複雑なコードを読み解き理解し、問題が発生した際にはデバッグして修復する技術を習得しなければなりません。今でも鮮明に覚えているのは、大学での最初の「本格的」なプログラミングの授業（C 言語）がどれほど畏怖を感じさせたか、そして第一回の仕事で複雑なコードベースに直面した時の途方に暮れた感覚です。その技術が上達するまでには、数年間にわたる実践、他の開発者からの学び、読書、ブログの閲覧が必要でした。ある程度高いレベルに達すると、あなたは価値があり、かつ容易に検証可能な能力を手にします——動くコードを書けることがそれ自体が証明となるのです！

ソフトウェア構築に関する私の最も素晴らしい記憶の一つは、コーディングそのものに関わるものです。フロー状態（心流状態）に入り込み、頭の中で複数の考え事を同時にバランスさせながら、指先が素早くそれを打ち込みます。そしてコードをコンパイルし実行して、結果を見て「やった！」と叫びたくなる——すべてが予想通り機能している！

正直に言って、この関係は愛憎半ばです——複雑なコードを書くために必要なその高度な集中力自体が、人を惹きつけると同時に苦痛も伴います。さらに、時間見積もりから生じる様々な対立もあります。あなたが難問に没頭してフロー状態に入った時、時間の流れ方は通常とは異なるものです。

今や、これらすべてが過去のものとなろうとしています。

ふと考えるのですが、複雑なコードを書く困難さから得られるあの達成感というものは、未来にも残るのでしょうか？はい、AI は確かに便利ですが、同時に何かを失う感覚もあります。

あるいは、AI エージェント（自律型エージェント）が介入することで、「フロー状態」はより高次な問題への思考へと転換し、その上で AI に複雑なコードの記述を指揮するようになるのでしょうか？

いずれにせよ、地震のような劇的な変化は、同時に興奮を伴う新たな機会も意味しています。私はこれまで、大きな変革が進行中であることをその最中に明確に認識したことはありませんでした。しかし今回は、2026 年までに私のコーディングのあり方が根本から変わることを確信しており、そこから生じる連鎖反応は無数にあるでしょう。

変化はより良いキャリア機会を生み出し、新たな成功への道を開くと同時に、多大な興奮と不安ももたらします。私は推測しますが、5 年後には AI が創出したソフトウェアの爆発的増加という理由の一部により、市場におけるソフトウェア専門人材への需要は今日よりもさらに高まっているはずです。これらのより強力な新ツールを用いて、私たちは模索しています——この未来において、世界レベルのソフトウェアエンジニアリングとは一体何を意味するのかを。

より強力な AI ツールが私たちの職業にもたらす可能性のある変化について、あなたはどうお考えですか？下のコメント欄で歓迎します。