产品开发正在被重写

编码代理正在以指数速度变得更好，这一点可以明显看出，随着基准变得饱和，模型能够异步完成越来越长的任务。随着验证和仿真成为瓶颈，产品开发的方式将被彻底改写。到目前为止，产品开发的方式基本上是一个连续的过程，整个堆栈涉及多个利益相关者。对于一般的软件项目来说，它看起来像下面这样。想法 -> 产品 -> 设计 -> 工程 -> QA -> 生产 在这种模式下，绝大多数时间都花在循环的实施阶段。循环 Idea <> QA 的尾端花费的时间最少一个数量级。因此，由于实现是此过程中的主要成本，因此循环的制作方式是为了与此相协调。我们现在正达到大型语言模型的拐点，其中成本/性能的帕累托边界已经达到这样一个点：对于任务的重要部分来说，确实感觉更长的异步任务和云代理开始在生产案例中有意义。由于代码生成的丰富性和便捷性，人们强烈渴望了解代码的故事以及代码库中正在实施的真正变化。对于很多用例来说，代码库存储库的实用性确实在减少。以下的一个有趣的结果是多个工作角色的紧密结合，特别是设计、工程和产品。与我们合作的许多公司都已经看到这种组织成为一个整体，尽管专业化不同，但日常工作角色几乎相同。我们看到许多团队采用了新的工作单元，因为我们看到旧的顺序产品开发循环的压缩是一个循环，其中工作单元可以被描述为产品行为的已验证更改，循环如下。意图 -> 实施 -> 观察到的结果 这里观察到的结果是运行时证据、产品流程的变化以及对相关用户旅程的影响的组合。它本质上是非常经验性的，实际的基质是实际发生变化的。对于这个新循环，要保存的最重要的并不是代码，而是实际运行应用程序的运行时信号。想一想，您的软件如何在设备上运行，它是什么样子，这些新变化的支付流程的性能，以及后端分布式服务是什么样子。代码库当然仍然很重要，但它不再以完整的方式捕获代码的故事和实用性。如果代理更改了签出流程，存储库可以告诉我们哪些文件发生了更改。它无法告诉我们键盘是否覆盖了支付按钮，回访用户是否被引导到了错误的路径，延迟是否增加，或者最终的体验是否仍然符合最初的意图。所有这些都被保存并聚合在您所有工作的平台中，并且创建历史数据具有超越代码的巨大价值。我们正致力于在 Revyl 中为这个从移动开始的新开发循环构建缺失的部分。我们相信我们可以在您现有的工具（如Figma、Codex、claude code、cursor 等）之间工作，并为使这些工具更好地协同工作提供巨大的价值。缺少的部分是每个产品变更附带的行为记录。我想，在接下来的一年里，我们将看到软件开发中采用许多标准，其中一些包括：拉取请求包括行为证据，作为标准运行时信号成为一流的开发环境。产品、设计、工程将越来越多地围绕以结果为中心的开发。产品开发显然并没有消亡，它比以往任何时候都更加活跃，只是从根本上被重写了。