AI编码代理是否遇到了瓶颈,还是我们衡量它们的方式出了问题?
摘要
本文探讨了AI编码代理的炒作与现实之间的差距,认为它们对于加速工作流程的某些部分有效,但在架构、调试和审查方面仍需人工监督,并质疑当前基准测试是否衡量了正确的东西。
我不断看到三种关于AI代理的讨论碰撞在一起:大公司表示代理的进展比预期的要慢;新的基准测试试图像高级工程师一样评判代理;开发者表示代理编码有效,但需要强约束、日志记录、审查和清理。我目前的看法是:炒作让人以为代理会取代工程工作。实际上,它们似乎更擅长加速工作流程的某些部分,但前提是人类仍然掌控架构、上下文、调试和审查。令人不安的是,代理失败通常意味着代理周围的工作流程是模糊的。因此,我很好奇:在生产或严肃的副项目中,什么对你真正有效?代理在哪里仍然失败?像SWE-Bench这样的基准测试是否衡量了正确的东西?真正的技能现在是编码,还是很好地指导/审查代理?我对超出简单演示的例子特别感兴趣:多文件更改、调试、测试、重构、依赖选择以及长期运行的任务。代理是表现不佳,还是我们在建立护栏之前就期望了自主性?
相似文章
AI编程工具是在让开发者变得更好,还是仅仅加速了糟糕的判断?
一篇观点文章探讨了像Claude Code和Copilot这样的AI编程工具是否真正提升了开发者的技能,还是仅仅加速了有缺陷的决策,并强调了需要新的指标来评估工程中的人机协作。
AI代理真的变得高效了吗,还是仅仅是能力更强?
对AI代理当前状态的反思,指出尽管它们在写作、编码和规划方面变得更有能力,但在产生有用输出和在实际组织中可靠地推动成果之间仍然存在差距。
编码代理是否暴露了我们规格的糟糕程度?
文章认为,AI编码代理的许多失败源于模糊的规格,而不仅仅是模型弱点。它建议,编写更清晰、更详细的工作包可能是使用编码代理的开发人员的下一个基本技能。
有没有人也觉得AI代理在事情变得复杂之前都表现得很惊艳?
对AI代理令人印象深刻的演示和可靠的实际执行之间差距的反思,认为当前代理擅长结构化任务但在不可预测条件下会失败,并指出近期AI角色将主要集中于带人类监督的窄范围自动化。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。