读 How Coding Agents Are Reshaping Engineering, Product and Design
无意间看到的一篇文章，有种冬日喝了一碗鸡汤，一股暖流灌遍全身，分享给你一起品鉴。
EPD
作者发明的一个单词：EPD (Engineering, Product, and Design)
PRDs 已死
过去公司的开发流程：Idea -> PRD (Product Requirement Documents) -> Mock -> Code
为什么软件开发的金科玉律已崩塌？因为以往开发软件需要大量精力和时间，所以被迫分工。而现在 coding agent 的出现，可以将一个想法，快速转化为功能完善的软件。
瓶颈从实现转移到 review 环节
现在任何人都可以写代码，也就是每个人都可以构建产品。但生成的代码大概率不是完美的，EPD 还是需要承担 review 的职责：
- 工程师视角：是否可扩展、高可靠、可维护
- 产品视角：是不是真正解决了用户的问题
- 设计视角：用户交互是否足够友好
转化为以下模型，但带来了新的问题：代码太容易生成，原型层出不穷，review 的节点反而成为了瓶颈。
PRD 浴火重生
作者认为虽然传统 PRD 的流水线已不复存在，但假如只有生成的代码，reviewer 怎么能发现代码是否正确，代码是否多余。所以还是需要文档沉淀产品的要求。
关于这份 PRD 文档，应该以什么形式维护呢？未来甚至有没有可能就是用户的提示词？
通才的黄金时代
同时擅长技术、产品与设计的“通才”，一直非常的吃香，而 agent 将这一杠杆加倍持续放大。
背后的原因在于沟通成本：过去在大公司中，职责越多越清晰，沟通的效率反而指数降低。而现在所谓的“一人公司”，只需要与 AI coding agent 对话，反而会比多人的团队跑的更快更远。
Coding agents 成为必需品
产品、设计、开发，都要拥抱 agent（否则将被取代🤔）：
- 产品可以直接构建 POC，而不是停在 spec 阶段，苦苦等待他人的实现
- 设计可以直接通过代码迭代看到效果，而不是仅停留在 Figma 中
- 开发可以利用 agent 将时间更多花在系统设计中
优秀的 PM 变得伟大，不合格的 PM 将变得更加糟糕
好的「产品思维」比任何时候都变得更有价值。
反证法：想象不合格的 PM，在 agent 的帮助下，将会前所未有“高效”地产出更多“垃圾”，而严重浪费 reviewer 的时间。并更有可能制造出糟糕和臃肿的产品。
任何人都需要具备“产品思维”
虽然 agent 强大无比，但它还是需要人，通过自定义的提示词来驱动他。而这里的产品思维（product sense），简而言之，就是指人需要有足够的判断力，让 agent 做什么 以及不做什么。
在上文提到的 review 的阶段，好的产品思维，帮助加速沟通、review 和交付。相反，没有产品思维的人则需要超详细的文档才能搞清楚，拖慢整个流程。
p.s. 个人理解简而言之，就是学会减法。
“专才”的空间被挤压
你既要会使用 coding agent，又要有产品思维，所有职责之间的边界越来越模糊。
但并不意味着经验丰富的系统架构师就没有空间了，只是这样的“专才”的要求会越来越高，同时公司里这样的人会越来越少。因为“专才”除了要在自己的领域精通，还需要非常高效的 review 和强悍的沟通能力。
二选一：builder vs reviewer
在 EPD 模型中新出现的两种角色：
- builder：有良好的产品思维，能够使用 coding agent 产出代码，还有基础的设计审美。可以将小的特性或想法转化为产品。
- reviewer：面对大型或特别复杂的特性，需要各个领域的专家进行把关。
例如作为工程师，你可以选择成为“专才”，深耕系统设计，成为架构层面的 reviewer；或称为“通才”，补产品和设计能力，成为 builder。
p.s. 如果没有理解错误，原文的意思：builder 的边界在不断模糊，而 reviewer 依然术业有专攻，但 bar 会越来越高。
AI coding agent 最大的受益者？
作者认为，在新时代中，每个人都是 AI coding agent 最大的受益者，尤其是是将不同领域能力组合的人（例如开发+产品+设计）。
然而，说起来容易做起来难… 在兴奋之前，不如先行动起来～