Technology · · 3 min read
Meta利用代码变更数据评估AI对工程工作的影响
Meta研究员莫里茨·贝勒在一次对话中,探讨了公司衡量开发者生产力的方式、AI带来的影响,以及自动化测试的局限。
据 newsletter.getdx.com 的一篇报道,Meta正利用从单次代码变更中获取的测量数据,了解工程工具和人工智能如何影响开发者的工作。研究员莫里茨·贝勒表示,尽管工程师提交的变更多了、规模也更大了,但公司发现,编写一次变更所花的时间同比下降了40%以上。
这项指标被称为差异编写时间(diff authoring time),记录的是创建、测试和审查一次代码变更所涉及的实际投入。逐一考察变更,可以让Meta比通过计算开发者一天中的全部工作来衡量生产力,获得更聚焦的视角。
Meta不会利用这一指标对单个工程师进行排名或评估。相反,公司会考察团队、部门以及整个公司的整体模式。目的是发现退化问题,找出有用的改进,并决定在哪些方面进一步投资工程工具是合理的。
更细致地看待生产力
公司将差异编写时间视为多个信号之一。变更吞吐量、变更规模及其质量都会与之结合考量,因为没有任何单一指标能够可靠地描述工程生产力。例如,完成一次变更所需的时间缩短,并不一定有益,前提是生成的代码质量低下,或需要大量修正。
这种方法还让Meta能够检验框架和开发者工具的变化是否带来了实际收益。报道以React编译器中的自动记忆化为例。与手动添加缓存相比,编译器的自动化方法将编写一次变更所需的时间缩短了约30%。贝勒认为,这种规模的结果表明,对开发环境进行根本性改进,可能比对界面进行小幅优化更重要。
编写时间的下降并不能完全用打字或代码生成速度更快来解释。贝勒认为,开发者可能会把节省下来的时间用于收集背景信息,以及处理实现周边的任务。提示词编写似乎只占这类额外活动的一小部分。
随着代码生成成本降低,更困难的问题可能变成确定代码应该做什么。当自动化系统能够快速生成实现方案,却可能误解不完整的请求时,开发者意图的价值就会提高。
生产力指标遗漏了什么
传统遥测更擅长记录代码变更,却不太能捕捉变更之前的工作。白板讨论、头脑风暴和架构讨论可能对最终结果至关重要,却未必与之后的差异产生清晰的联系。AI生成的会议记录和其他记录,最终可能让其中一部分准备工作更容易被研究。
这并不意味着架构的重要性降低了。跳过设计文档,可能只是把负担转移给审查者,让他们不得不从完成的实现中推断原本想要的结构。因此,更快的产出可能掩盖工程流程其他环节增加的工作。
贝勒此前进行的 Mind the Gap 研究,将自动记录的活动与开发者对自身生产力的评估进行了比较。编码时间是一个重要的预测因素,但休息、干扰和随时待命的职责也会影响人们对自身生产力的感受。新的版本还需要考察开发者如何与智能代理协作、他们对代理的信任程度,以及同时协调多个自动化任务是否会造成过大的认知负担。
产出更多也不意味着工作体验更好。讨论指出,生产力可能上升,而专注程度、脑力投入和总体满意度却保持不变或下降。人际关系、共同理解和非正式知识交流对工程工作十分重要,但在大多数指标中仍然难以体现。
减少不必要的会议可能提高吞吐量,但过度减少协作会让团队失去想法和背景信息。小规模的社交交流同样重要:节目中讨论的一项研究发现,会议前后的非正式交谈,比互联网质量更能预测人们自我报告的生产力。
AI智能代理带来的测试挑战
AI智能代理让创建单元测试和端到端测试的成本变得很低,有可能弥补长期以来开发者自动化覆盖不足的缺口——过去,许多开发者很少编写自动化测试。但当实现和测试共同采用了对模糊请求的错误解读时,一组全部通过的测试可能带来误导性的安心感。
智能代理可能生成彼此内部一致的代码和测试,却仍然无法实现开发者真正的目标。这种风险使得在实现开始之前定义正确性变得更加重要。这场对话提出,随着智能代理承担更多编码工作,以规格说明为驱动的开发,可能会成为测试驱动开发的对应方法。
自动化实现的速度也增加了团队在不知情的情况下并行构建同一事物的风险。更好的测量不仅需要考虑已经完成的代码,还需要考虑协同、沟通和重复劳动。Meta在差异层级收集的数据提供了一种观察新工具部分影响的方式,但更广泛的讨论清楚表明,工程生产力不仅是技术问题,也是人的问题和组织问题。