在过去一年中，作者接触了超过50家API供应商（多为早期创业公司），发现一个普遍问题：API通信机制存在严重缺陷。破坏性变更往往在缺乏充分通知的情况下发布，有用的新功能悄然上线却无人知晓，变更日志也常常被忽视。即使在AWS工作期间，超过30%的服务停机时间源于外部API和软件包变更未被及时察觉。这种摩擦在代理编码工具出现之前或许可以接受，但如今已不合时宜。

代理编码工具（如Cloud Code、Davenin、Gravile等）的兴起证明了开发者和企业愿意将代码库访问权限授予外部工具，只要这些工具能带来价值。两年前这还难以想象，现在已成为标准做法。自动化代码变更的基础设施已经就绪，缺失的是连接API供应商与其客户代码库的应用层。

作者认为，API供应商不应仅仅发布变更通知，而应主动将变更应用到客户的代码中。例如，当Stripe发布破坏性变更或新功能时，应该有一个代理自动扫描客户代码库，识别受影响的用法，并自动生成包含修复的Pull Request。这种模式可以通过每个供应商的代理实现（例如安装Stripe的更新代理），也可以通过跟踪多个供应商变更的第三方中立服务实现——类似于Dependabot，但针对的是API。如果你正在从事相关工作，不妨考虑申请加入YC。