北京
软件工程师正处在一个高强度时刻。一方面，编码代理已经变得真正出色，团队正在以越来越高的吞吐量持续使用它们。另一方面，这些代理构建代码的方式草率且不断累积缺陷，工程师承受着持续压力去约束它们。
代理变强了，但裂缝随时间显现
先看积极的一面，因为这确实值得注意。AI 编码工具的采用曲线已经接近垂直上升。一年前，采用还是零散和实验性的；如今在许多组织中，绝大多数代码由 AI 撰写。但与此同时，缺陷数量和生产事故也在随之增加，因为更多拉取请求在没有人工代码审查的情况下通过。
基准测试从另一个角度讲述了同样的故事。基于任务的基准测试已经基本饱和——如果能清晰定义一项任务并衡量它是否完成，代理就能完成它。但如果要求代理重构大型代码库，或者在其已有工作上持续构建，就会看到质量下降，成功率也低得多。
更好的代理会带来帮助，但也伴随成本
自然的期望是更好的模型会直接消解所有这些问题。但这里存在沉重的权衡——很大一部分问题在于对整体设计决策的推理，以及对现有代码的审查，以遵循既有模式并保持一致——所有这些都需要时间和推理努力。即使代理能够做到，期望它们在每个会话中都从第一性原理出发做好这些，也会极其昂贵。
如果把运行代理的成本与其智能程度绘制成图，智能轴大致呈线性移动，而价格轴则呈对数尺度移动。在整个范围内，差距大约有 100 倍，而顶级模型与一个完全够用的较便宜模型之间，在相同任务上的成本差距可能约为 10 倍。即使最好的模型能够胜任工作，这也可能是一种异常昂贵的解决问题方式。当开始以真实吞吐量运行代理时，这一点就不再是学术问题。最近一周内，一家小公司就合并了大约 600 个拉取请求。
工程没有变得不重要，而是变得更关键
随着代理写出越来越多的代码，工程并非变得不那么重要，而是更加重要。只是它看起来不同于许多工程师成长过程中所熟悉的工程形态。有人开始把从事这种新工作的人称为“约束工程师”，并认为这是许多人即将进入的角色——有些人会把它作为全职专业，更多人则会在产品工程之外，把它作为工作中不断增长的一部分。
这种变化的核心在于，当代理承担越来越多的代码编写工作时，人类需要把精力转向定义边界、审查模式、维持一致性，以及在代理产出速度与代码质量之间建立可控的约束机制。那些能够理解整体设计、识别累积缺陷并保持系统长期健康的人，正在成为新的关键节点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
