コーディングエージェントがエンジニアリング、製品、デザインを再構築する方法
LangChain Blogの記事は、コーディングエージェントの登場により、ソフトウェア開発における従来のPRD中心のプロセスが崩壊し、エンジニアリング・プロダクト・デザインの役割が実装からレビューと品質保証へと移行するという業界の根本的な変化を分析している。
キーポイント
PRD中心プロセスの終焉
コーディングエージェントによりアイデアから直接コード生成が可能になったため、従来のプロダクト要件定義書（PRD）を起点としたウォーターフォール型開発プロセスは時代遅れとなった。
ボトルネックの移行：実装からレビューへ
誰でもコードを生成できるようになった結果、開発のボトルネックは実装から、生成されたコードのアーキテクチャ、ユーザー課題解決、使いやすさを評価・改善するレビュー作業へと移行した。
EPD役割の再定義
エンジニアリング、プロダクト、デザインの専門家の役割は、実行者からレビュアーと品質保証者へと変化し、ジェネラリストの価値が高まり、専門性の基準も引き上げられる。
プロダクトセンスの普遍化
誰でもビルダーになれる環境では、すべての関係者がユーザー課題を理解し、適切な解決策を判断する「プロダクトセンス」を持つことが必須要件となった。
プロトタイプの増加とレビューのボトルネック
コーディングエージェントによりプロトタイプ作成コストが低下し、プロトタイプ数が増加。製品、エンジニアリング、デザインのレビューがボトルネックとなっている。
PRDの進化と文書の重要性
従来のPRDプロセスは終わったが、製品要件を記述した文書は依然として重要。プロトタイプのレビュー時には意図を伝える文書が必須であり、構造化されたプロンプトが未来のPRDとなる可能性がある。
ジェネラリストの価値向上とコーディングエージェントの必須化
製品、エンジニアリング、デザインの知識を持つジェネラリストは、コミュニケーションコストが低いためエージェント時代により価値が高まる。コーディングエージェントの採用は必須となり、各職種の生産性を向上させる。
影響分析・編集コメントを表示
影響分析
この記事は、AIによるコード生成が単なる生産性向上ツールではなく、ソフトウェア開発の組織構造、プロセス、専門職の役割定義そのものを根本から再構築する破壊的変化をもたらしていることを示している。業界全体が「誰でもビルダー」の時代における品質保証と戦略的価値創造の新しいモデルを模索する必要がある。
編集コメント
技術的な詳細よりも組織とプロセスの変革に焦点を当てた分析で、AIツールの導入がもたらす人的・組織的影響を鋭く考察している。業界関係者必読の視点を提供。
imageソフトウェア企業におけるEPD（エンジニアリング、プロダクト、デザイン）の役割は、優れたソフトウェアを作り出すことです。各役割は分かれていますが、最終的な目標は、ユーザーが使える、ビジネス課題を解決する機能的なソフトウェアです。結局のところ、その成果物はコードにほかなりません。EPDという組織機能が生み出すアウトプットが「単なるコード」であると認識することが重要です。なぜなら…コーディングエージェントの登場により、コードを書くことが非常に容易になったからです。では、これはEPDの役割をどう変えるのでしょうか？
変化するプロセス:
PRDは死んだ
ボトルネックは実装からレビューへ移る
PRD万歳
役割への影響:
ジェネラリストはこれまで以上に価値が高まる
コーディングエージェントは必須ツールとなる
優れたPMはさらに輝き、悪いPMはより問題になる
全員がプロダクトセンスを求められる
専門特化へのハードルは上がる
あなたはビルダーか、レビュアーか
誰もが自分の役割がコーディングエージェントで最も強化されると考える―そしてそれは正しい
PRDは死んだ
PRD（プロダクト要件定義書）は、AI（Claude）以前の時代におけるソフトウェア構築の要でした。EPDプロセスはおおむね以下の通りでした:
誰か（通常はプロダクト担当者）がアイデアを思いつく
プロダクト担当者がPRDを作成する
デザイナーがPRDを受け取り、モックアップを作る
エンジニアがモックアップをコードに変換する
imageこれは絶対的なルールではありませんでした（スタートアップではこれらのステップが融合し、優秀なビルダーは複数の役割を同時にこなせました）が、ものづくりの教科書的な方法ではありました。
このプロセスが必要だったのは、ソフトウェア（およびモックアップ）の構築には膨大な時間と労力がかかったためです。そこで、それらの作業に特化した専門職が生まれました。人々が専門化するにつれ、各専門分野間で意思疎通を図る必要性が生じます。PRDはそのための基盤となり、すべての始点でした。その後、PRDはデザインへと引き継がれ（ウォーターフォール）、美しい言葉は洗練されたUI/UXへと形を変えます。そしてエンジニアリングがそれを現実のものにするのです。
コーディングエージェントはこのすべてを変えます。コーディングエージェントはアイデアを受け取り、機能するソフトウェアを作り出せます。私や他の人々が「PRDは死んだ」と言うとき、本当に意味しているのは、PRDの作成から始まるこの伝統的なソフトウェア構築方法が終わったということです。
ボトルネックは実装からレビューへ移る
今や誰でもコードを書けるようになったということは、誰でも何かを作れるようになったということです。しかし、作られたものが適切に設計されているか、正しい問題を解決しているか、使いやすいかどうかは別問題です。エンジニアリング、プロダクト、デザインの各専門家は、これらの領域のレビュアーおよび仲裁者となるべきです。問題は、生成されるコードが常に「優れた」ものとは限らないことです。EPDの役割は、それをレビューし、「優れた」ものに仕上げることに移行します。ここで「優れた」とは、以下のようなことを意味します:
エンジニアリングシステムの観点で適切に設計されている: スケーラブルで、高性能で、堅牢な方法で書かれているか？
プロダクトの観点でよく考え抜かれている: ユーザーの課題を解決しているか？
優れたデザインである: インターフェースは使いやすく直感的か？
コードの初期バージョンを作成するコストが非常に低くなったため、はるかに多くのプロトタイプが生み出されるようになりました。これらのプロトタイプが議論の焦点となり、プロダクト、エンジニアリング、デザインの各担当者がそれをレビューします。
image問題は、コード生成があまりにも簡単だということです。以前は、コードを作成するには時間がかかりました。そのため、レビュアーの元に一度に届くレビュー対象のプロジェクト数には限りがありました。しかし今では、誰でもコードを書けます。つまり、進行中のプロジェクトの数が爆発的に増加しているのです。私たちは、（三つの機能すべてにおいて）ボトルネックが「レビュー」、すなわちプロトタイプを受け取り、それを「良い」ものに仕上げる作業に移っているのを目の当たりにしています。
PRD万歳
ソフトウェア構築のAI（Claude）以前の時代（PRDから始まる方法）は終わりました。しかし、プロダクト要件を記述する文書そのものは依然として不可欠です。
誰かがアイデアを思いつき、素早くプロトタイプを作成したとしましょう。それはどのようにして本番環境にリリースされるのでしょうか？それはEPDの他のメンバーによるレビューを経る必要があります。このプロセスにおいて、文書化された記録は常に有益であり、多くの場合必須です。他者がレビューする際、コードの一部が偶然存在するのか、意図的に組み込まれたのかを、どうやって判断すればよいのでしょうか？それは意図によります。この意図を伝える何らかの手段が必要なのです。
私は、伝統的なPRDプロセス（PRD → モックアップ → コード）は終わったと考えます。しかし、プロダクト要件を記述する「テキスト」は非常に重要であり続けます。この関連文書は、レビューに回される前に、プロトタイプに必須の添付物とすべきです。
最も標準的な形式は文書ですが、機能作成に使用したプロンプト自体を共有するという興味深いアイデアもあります。将来のPRDは、単に構造化され、バージョン管理されたプロンプトになるのではないでしょうか？
ジェネラリストはこれまで以上に価値が高まる
ここで言うジェネラリストとは、プロダクト、エンジニアリング、デザインの三つすべてに対する優れた感覚を持つ人々を指します。こうした人々は以前から価値があり、影響力を持っていましたが、コーディングエージェントの登場により、その価値はさらに高まります。なぜでしょうか？
コミュニケーションはあらゆるものごとの中で最も難しい部分です。それは作業を遅らせます。プロダクト、デザイン、エンジニアリングのすべてを一人でこなせる人物は、コミュニケーションのオーバーヘッドがない分、三人のチームよりも速く動けます。
以前は、実装自体が障害となっていたため、このようなジェネラリストであっても作業を完了するには他者とのコミュニケーションが必要でした。今では、彼らはエージェントとだけコミュニケーションを取ればよいのです。これは、彼らが単独でこれまで以上に大きな影響力を発揮できることを意味します。
コーディングエージェントは必須ツールとなる
コーディングエージェントによって実装コストが下がった今、それらを使いこなすことは必須条件です。コーディングエージェントを活用できる人々は、自分一人でより多くのことを成し遂げられるようになります:
コーディングエージェントを活用するPMは、仕様書を書いて待つことなく、直接プロトタイプを構築してアイデアを検証できる
コーディングエージェントを活用するデザイナーは、Figma内だけでなく、コード上でも反復改善を行える
コーディングエージェントを活用するエンジニアは、実装作業からシステム思考へと時間をシフトできる
コーディングエージェントの採用は必須です。なぜなら、それは難しくなく、もしあなたが採用しなければ、採用する誰かに置き換えられるからです。
優れたPMはさらに輝き、悪いPMはより問題になる
優れたプロダクト思考はこれまで以上に価値があります。あなたは価値あるものを作り出せます。一方、拙いプロダクト思考はこれまで以上に無駄を生みます。もし誰かが悪いプロダクトアイデアを持っている場合、彼らはプロトタイプを持って現れることができます。しかし、そのプロトタイプは役に立たない、あるいは浅慮な機能のものになるでしょう。こうしたプロトタイプは今、エンジニアリング、プロダクト、デザインからのより多くのレビューを必要とします。これは時間とリソースを消耗します。また、「もう既に存在しているんだから、マージしよう！」という考えから、これらのプロトタイプを本番環境にリリースしようとする慣性も強まります。これは、より質の低い、あるいは肥大化したプロダクトを生むリスクがあります。
システム思考は磨くべきスキル
実装が低コストな世界では、システム思考が差別化要因となります。あなたはシステム思考を真に得意とし、特定の領域について明確なメンタルモデルを持つことに集中すべきです:
エンジニアリング: サービス、API、データベースをどのように設計すべきかについての確固たるメンタルモデル
プロダクト: ユーザーが実際に何を必要としているか（彼らが何を欲しているかではなく）についての確固たるメンタルモデル
デザイン: 何かが使いやすいと感じられる理由についての確固たるメンタルモデル
システム思考は常に重要でした。では、何が変わったのでしょうか？実装のコストが劇的に下がったのです。これは、何かを実装することがこれまで以上に簡単になったことを意味します。しかし、それが「優れている」ことにはつながりません。優れたシステム思考者であることは、最初から正しいものを構築していることを保証し、また、事後に他者の仕事をレビューすることも可能にします。どちらの場合も、優れたシステム思考者であることの重要性は高まっています。
全員がプロダクトセンスを求められる
コーディングエージェントも、誰かがプロンプトして指示を与える必要があります。何をすべきかを伝える人が必要なのです。もしあなたが間違ったものを構築するように指示すれば、他者がレビューしなければならない無駄な成果物を増やしていることになります。エージェントに何を構築させるべきかを知ること（「プロダクトセンス」）は必須条件です。そうでなければ、組織の足手まといになるでしょう。これはエンジニアリング、デザイン、そして（言うまでもなく）プロダクトの全員に当てはまります。
EPDの大きな役割の一つは、今やプロトタイプのレビューです。プロダクトセンスがあれば、レビューは容易になります。デザインやエンジニアリングのレビューであっても同様です。プロダクトセンスがなければ、プロトタイプに付随する非常に詳細なプロダクト文書が必要になります。プロダクトセンスがあれば、最小限の仕様で機能の意図を理解し、コミュニケーション、レビュー、納品を加速させることができます。
専門特化へのハードルは上がる
あなたはコーディングエージェントの使い方を知る必要があります。プロダクトセンスが必要です。すべての役割が融合しつつあります。
役割間には常に重複がありました。デザインとプロダクトは長い間密接に関わってきました。AppleやAirbnbのような特定の企業では、デザイナーがプロダクトマネージャーの役割を果たしています。「デザインエンジニア」という役割は、Vercelのような企業で存在感を増しています。
これは専門特化の余地がなくなったという意味ではありません。システムアーキテクチャだけを考える非常にシニアなエンジニアは依然として価値があります。同様に、コーディングを学んでいないが、顧客の問題と構築すべきものについて超明確なメンタルモデルを持つPMも価値があります。Figmaを使い続けていても、ユーザージャーニーとインタラクションを理解し、モックアップを作れるデザイナーも同様です。
しかし、専門特化へのハードルははるかに高くなりました。あなたは自分の領域で卓越しているだけでなく、信じられないほど速くレビューを行い、驚異的なコミュニケーターである必要があります。そして、特定の企業にはおそらく、そのような人材はそれほど多くはいないでしょう。
あなたはビルダーか、レビュアーか
私たちはEPDにおいて、二つの異なるタイプの役割が出現しつつあるのを見ています。
第一に：ビルダー。この原型は優れたプロダクト思考を持ち、コーディングエージェントを使いこなし、基本的なデザイン直感を備えています。ガードレール（テストスイート、コンポーネントライブラリ）が整っていれば、彼らは小さな機能をアイデアから本番環境まで進め、大きな機能の実動プロトタイプを作成できます。
第二に：レビュアー。大規模で複雑な機能については、詳細なEPD（エンジニアリング、プロダクト、デザイン）レビューが必要です。この基準は高く、自身の領域において卓越したシステム思考を持つ必要があります。また、高速なペースで作業しなければなりません。レビューすべきものは山ほどあるからです。
もしあなたが今エンジニアなら、システム設計に卓越し、アーキテクチャレビューに熟達してレビュアーを目指すか、あるいはプロダクト/デザインスキルを伸ばしてビルダーになることを試みるかの選択に直面します。
もしあなたがプロダクトやデザインに携わっているなら、プロダクト/デザインに関する卓越したメンタルモデルを持ち、主にレビューを行うか、あるいはコーディングエージェントに飛び込み、コーディングスキルを磨くかの選択に直面します。
image興味深いのは、上のチャートが示すように、EPD（エンジニアリング、プロダクト、デザイン）全体のどこかに位置するという意味で、役割がある種融合しつつあることです。役割は混ざり合い始める可能性があります。エンジニアはより多くの時間を持ち、プロダクトとデザインについてより深く考えることができます。プロダクトとデザイン担当者はコードを作成できます。
誰もが、自分の役割がコーディングエージェントによって最も恩恵を受けると考えています。そして、彼らは正しいのです。
コーディングエージェントによって最も恩恵を受ける人々のタイプについて、Twitterで素晴らしい投稿がありました：
既存のプロダクトを直感的に理解し、どこが弱く、どこが優れているのか、そしてそれをどう鋭く反復改善していくかを知っている人。
この人物の最も稀なタイプは、文化と深い技術の交差点に位置しています。真にバイリンガルな人です。彼らは技術的に何が可能かを知っており、どの文化的潮流が本物で、どの潮流が一時的なものかを知っています。その組み合わせが、「必然的に感じられるプロダクト」と「組み立てられたように感じられるプロダクト」を分けるのです。
この投稿はこの新しい世界を見事に要約しており、ある程度バズりました。それがバズった理由の一つは、それを読んだ誰もが、それが自分自身や自分の役割について書かれていると思ったからです。プロダクト担当者、デザイナー、デザインエンジニア、創業者…皆が自分に当てはまると考えました。
そして、おそらく彼らは皆、正しかったのでしょう！この新しい世界について素晴らしく、エキサイティングなことは、背景がそれほど重要ではなくなることだと思います。私は心から、この人物像はプロダクト、デザイン、エンジニアリングのいずれの背景からも生まれうると信じています。もちろん、誰もがこのような人物になれるという意味ではありません。言うは易く行うは難しです。真のユニコーンは非常に稀なのです。
今は、ものづくりにワクワクする時代です :)
原文を表示
imageEPD (Engineering, Product, and Design) at software company is about creating good software. Separate roles exist, but the end goal is functional software that solves a business problem that users can use. At the end of the day, this is just code. It is important to recognize that the output of what EPD as a function builds is just code because… coding agents have suddenly made code very easy to write. So how does this change the role of EPD?
The changing process:
PRDs are dead
The bottleneck shifts from implementation to review
Long live PRDs
Impact on roles:
Generalists are more valuable than ever
Coding agents are a requirement
Good PMs are great, bad PMs are terrible
Everyone needs product sense
The bar for specialization is higher
You're either a builder or a reviewer
Everyone thinks their role is most advantaged by coding agents - and they are right
PRDs are dead
PRDs (Product Requirement Documents) were the focal point of building software in the pre-Claude era. The EPD process was largely:
Someone (usually product) has an idea
Product writes a PRD
Design takes PRD and creates a mock
Engineering turns mock into code
imageThis wasn’t a hard and fast rule (at startups these steps blended together, the best builders were able to do multiple of these together) but it was the textbook way to build things.
This was required because building the software (and building the mock) required a significant amount of time and effort. So disciplines were created to specialize in those efforts. As people became more specialized, there then became a need to communicate across those disciplines. The PRD was the basis of that, which kickstarted everything. It would then waterfall to design, who would turn pretty words into a pretty UI and smooth UX. Engineering would then make that real.
Coding agents change all of that. Coding agents can take an idea and create functional software. When I (and others) say “PRDs are dead” what we really mean is this traditional way of building software, starting with the writing of a PRD, is dead.
The bottleneck shifts from implementation to review
Anyone can write code now, which means anyone can build things. That does not mean the things that are built are well architected, or solve the right problems, or easy to use. Engineering, Product, and Design should be the reviewers and arbitrators of these areas. The issue is the code generated isn’t always “great”. The role of EPD becomes reviewing and making sure it is “great”. “great” can mean several things:
Well architected from an engineering systems perspective: is it written in a scalable, performant, robust way?
Well thought out from a product perspective: does this solve the user pain point?
Well designed: are the interfaces easy and intuitive to use?
Since the cost of creating some initial version of the code is so cheap, we see that a lot more prototypes are created. Those prototypes then serve as a focal point, with Product, Engineering, and Design reviewing them.
imageThe issue is - it’s so easy to generate code. Previously, it took a while to create the code - so as a reviewer there were only so many projects coming across your desk for review at any given point. Now though - anyone can write code. That means the number of projects going on is increasing. We’ve seen the bottleneck (in all three functions) be review - taking the prototypes and making sure they are “good”.
Long live PRDs
The pre-Claude era of building software (starting with a PRD) is gone. But documents describing product requirements are still essential.
Let’s assume someone has an idea and quickly builds a prototype. How does this get into production? It needs to be reviewed by other members of EPD. As part of this process, a written document always helps and is often essential. When others are reviewing, how are they to know if part of the code is there by accident or on purpose? Depends on the intent. Some communication of this intent is needed.
I think the traditional PRD process (PRD → mock → code) is dead. But text that describes product requirements is very much alive. This associated document should be a required companion to the prototype before being handed off for review.
The most standard format would be a document, but there are some interesting ideas around sharing the prompts used to create this feature as a way to communicate that. What if PRDs of the future are just structured, versioned prompts?
Generalists are more valuable than ever
By generalists I mean people with a good sense of all three of product, engineering and design. These people were always valuable and impactful - but with coding agents they are even more so. Why?
Communication is the hardest part of everything. It slows things down. One person who can do all of product, design, and engineering will move faster than a team of three because of the communication overhead.
Previously, when implementation was the blocker, this generalist still had to communicate with others to get work done. Now they can just communicate with agents. This means they can be far more impactful by just themselves than ever before.
Coding agents are a requirement
With coding agents making implementation cheap, using them is a requirement. People who can adopt coding agents will be able to do more by themselves:
PMs who adopt coding agents can validate ideas by building prototypes directly, without writing a spec and waiting
Designers who adopt coding agents can iterate in code, not just in Figma
Engineers who adopt coding agents can shift their time from implementation to system thinking
Adopting coding agents is a requirement because it is not hard to do so, and if you don’t do you so you will be replaced by someone who does.
Good PMs are great, bad PMs are terrible
Good product thinking is more valuable than ever - you can build things that are useful. Bad product thinking is more wasteful than ever. If someone has a bad product idea, they can show up with a prototype - but that prototype will be of a feature that is useless, or poorly conceived. These prototypes now require more reviews - from engineering, product and design. This sucks up time and resources. There is also more inertia to get these prototypes into production (”It already exists! Let’s just merge it!”). This risks creating a worse or bloated product.
System thinking is the skill to hone
In a world where execution is cheap, system thinking becomes the differentiator. You should focus on being really good at systems thinking and have a clear mental model of your particular domain:
Engineering: really good mental model of how to architect services and APIs and databases
Product: really good mental model of what users actually need, not what they say they want
Design: really good mental model of why something looks and feels right to use
System thinking has always been important - so what has changed? The cost of implementation went way down. This means that it is easier than ever to implement something - but that doesn’t mean it’s great. Being a good system thinker allows you make sure you are building the right things upfront. It also lets you review others work after the fact. Both mean that the importance of being a good system thinker has grown.
Everyone needs product sense
Coding agents still need someone to prompt them. Someone to tell them what to do. If you tell them to build the wrong thing - you are creating more slop for others to review. Knowing what to tell the agent to build (”product sense”) is a requirement, or you will be a drag on the org. This is true across engineering, design, and (obviously) product.
A big part of EPD is now reviewing prototypes. Reviewing is easier if you have product sense, even for reviewing design/engineering. If you don’t have product sense, you need a super detailed product document along side the prototype. If you do have product sense you understand the intent of the feature with a minimal spec, speeding up communication, review, and delivery.
The bar for specialization is higher
You need to know how to use coding agents. You need product sense. All the roles are blending together.
There’s always been overlap in roles. Design and product have long been linked -a t certain companies like Apple and AirBnb, designers serve as product managers. “Design engineer” as a role has been picking up steam at companies like Vercel.
This doesn’t mean there is no room for specialization. A very senior engineer who just thinks about the system architecture is still valuable. As is a PM who hasn’t picked up vibe coding but does have a super clear mental model of the customers problems and what to build. Same with a designer who can understand and mock user journeys and interactions, even if still in Figma.
But the bar for specialization is much higher. You have to be not only fantastic at your domain, but also incredibly fast at review and an incredible communicator. And there probably aren’t that many of these roles at any given company.
You’re either a builder or a reviewer
We see two different types of roles emerging in EPD.
First: the builder. This archetype has good product thinking, they are capable of using coding agents, and have baseline design intuition. With guardrails around them (test suite, component library) they can take small features from idea to production, and prototype functional versions of larger ones.
Second: the reviewer. For large and complicated features, detailed EPD review is required. The bar for this is high - you have to be a fantastic systems thinker in your domain. You also have to work at a fast pace - there is a lot to review.
If you are an engineer right now - you should either aim to get fantastic at system design and comfortable reviewing architectures and aim to be a reviewer… or try to grow your product/design skills and become a builder.
If you are in product or design - you either have to have a fantastic mental model for product/design and largely review, or jump into coding agents and improving your coding chops.
imageWhat's interesting is that roles are kind of collapsing, as shown by all of EPD being somewhere on the above chart. Roles can start to blend together - engineers have more time, can think more on product and design. Product and design can create code.
Everyone thinks their role is most advantaged by coding agents - and they are right
There was a great post on Twitter about the type of people most advantaged by coding agents:
someone with an intuitive grasp of the product as it exists, where it's soft, where it sings, & how to iterate it toward something even sharper.
the rarest version of this person sits at the intersection of culture & deep technology. someone genuinely bilingual. they know what's technically possible & they know which cultural currents are real vs. ephemeral. that combo is what separates products that feel inevitable from products that feel assembled.
The post was a great encapsulation of this new world, and it went semi-viral. Part of the reason it went viral was everyone reading it thought it was about them or their role. I saw product people quoting it, designers, design engineers, founders… everyone thought it applied to them and their role.
And they were all probably right! I think the great and exciting thing about this new world is that backgrounds matter less. I genuinely believe this archetype of person could come from product, design, or engineering. That doesn’t mean everyone will be this person - it’s much easier said than done. There are very few true unicorns out there.
It’s an exciting time to be building :)
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み