丰色 发自 凹非寺量子位 | 公众号 QbitAI
AI帮忙写代码程序员用了都说好,但代码质量真的靠谱吗?
结果或许令你大跌眼镜。
一家名为GitClear的公司分析了近四年超过1.5亿行代码后发现,随着GitHub Copilot工具的加入,代码流失率(即代码写入后不久又被返工修改、删除的情况)出现了显著上升:
2023年为7.1%,而2020年时仅为3.3%,翻了一番。
与之相应的,代码复用率也出现了明显下降。
言外之意,AI写的很多内容其实不亚于“屎山”,根本不好随着业务的变化作相应更改。
看起来,AI编程工具还远没有宣传中的那么好用?
Copilot更爱直接添加代码而不鼓励复用
GitClear收集的1.5亿行代码中,有3/2来自匿名私企,剩下的1/3则源自于谷歌、Meta和微软的开源项目。
它们全部被排除了“噪声”数据,比如在多个分支中提交的一模一样的代码、空行以及其他没有意义的代码行。
调查的主要对象是微软的GitHub Copilot。
它于2021年6月推出测试版,按照CEO说法,截至2023年第三季度,该工具已有超100万开发者付费订阅,能够帮助开发者编写46%的代码,并将编码速度提高55%。
不过在此,GitClear不关心编码速度,只关心质量。
“AI编程工具更类似于高级开发人员,仔细又精细?还是更像短期承包商一样,只在乎面前的任务完成与否?”
为此,他们统计了这1亿行+代码的新增、删除、更新、移动、复制/粘贴等情况,得出了这样一个趋势表格:
从中我们可以发现:
Copilot添加代码、复制/粘贴代码的百分比比更新、删除和移动增加得更明显。
其中我们还可以清晰地看到,移动代码的百分比从2020年的25%下降到了13.4%,这是所有数据中唯一一个反向特例。
更少的移动意味着更少的重构和复用,加上大幅增长的添加、复制/粘贴代码,这表明:
AI编程工具并不鼓励代码复用、在已有代码上进行修改,而是更倾向于“无脑重写”。
在此,GitClear也指出,过度新增代码、复制/粘贴对代码的长期可维护性也相当不利。
这其实在人类程序员中也是老问题,可能是程序员觉得解决当下问题比思考如何复用、整合现有代码更快更容易,也可能是因为同个项目组中的开发人员沟通不畅等。
遭殃的就变成后面的维护人员。
Copilot的代码质量下降也体现在代码流失率(Churn)这个数据上。
在此,它的标准定义是代码编写后不到两周的时间内修改更新的百分比。
表格显示,2020年的流失率为3.3%(那会还没有用上Copilot),2023年增长到5.5%。
GitClear预计,2024年将直接相比2020年翻一番之多,达到7.1%。
这说明AI的加速,并没有带来足够高质量的代码。
除了以上结论,GitClear还发现,Copilot的代码建议算法还被设计为总是提出最有可能被用户接受的建议——
这选择乍一听没啥毛病,但其实会忽略代码简洁易读的重要性。
总的来说,这项结果足以让那些担心AI编程工具会取代人类程序员的人暂时把心放肚子里。
最近也有不少其他研究佐证了GitClear的发现。
比如来自CodeScene的一篇报告就表示:
在编码任务中,AI远无法取代人类;今天的AI太容易出错,且远未达到能够安全修改已有代码的程度。
网友体验大差不差
实实在在使用过Copilot的人怎么说?
一位网友表示:
我用了俩个月后取消了会员,因为花了太多精力去检查AI给出的代码以及修复bug。
在TA看来,现阶段还是自己编写内容要省力得多,因为自己知道自己想要写什么,修复自己的bug总是比修复机器人的更容易。
有人使用的是ChatGPT而非Copilot,也对TA的话表示了赞同:
我对AI的能力感到惊讶,但还是不会称其为“好代码”。
当然,Copilot在大家眼里也并非一无是处。
一位从事web开发20多年的程序员就表示:
用它编写重要的SQL或TypeScript代码时,总是失败;但对于编写测试、请求处理、React样式等等来说,它还是可以帮我节省大量时间的。
你的Copilot(或者其他AI编码工具)体验如何?你同意GitClear的发现吗?
参考链接:[1]https://devclass.com/2024/01/24/ai-assistance-is-leading-to-lower-code-quality-claim-researchers/[2]https://visualstudiomagazine.com/articles/2024/01/25/copilot-research.aspx[3]https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
— 完 —
点这里👇关注我,记得标星哦~
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~
AI帮忙写代码程序员用了都说好,但代码质量真的靠谱吗?
结果或许令你大跌眼镜。
一家名为GitClear的公司分析了近四年超过1.5亿行代码后发现,随着GitHub Copilot工具的加入,代码流失率(即代码写入后不久又被返工修改、删除的情况)出现了显著上升:
2023年为7.1%,而2020年时仅为3.3%,翻了一番。
与之相应的,代码复用率也出现了明显下降。
言外之意,AI写的很多内容其实不亚于“屎山”,根本不好随着业务的变化作相应更改。
看起来,AI编程工具还远没有宣传中的那么好用?
Copilot更爱直接添加代码而不鼓励复用
GitClear收集的1.5亿行代码中,有3/2来自匿名私企,剩下的1/3则源自于谷歌、Meta和微软的开源项目。
它们全部被排除了“噪声”数据,比如在多个分支中提交的一模一样的代码、空行以及其他没有意义的代码行。
调查的主要对象是微软的GitHub Copilot。
它于2021年6月推出测试版,按照CEO说法,截至2023年第三季度,该工具已有超100万开发者付费订阅,能够帮助开发者编写46%的代码,并将编码速度提高55%。
不过在此,GitClear不关心编码速度,只关心质量。
“AI编程工具更类似于高级开发人员,仔细又精细?还是更像短期承包商一样,只在乎面前的任务完成与否?”
为此,他们统计了这1亿行+代码的新增、删除、更新、移动、复制/粘贴等情况,得出了这样一个趋势表格:
从中我们可以发现:
Copilot添加代码、复制/粘贴代码的百分比比更新、删除和移动增加得更明显。
其中我们还可以清晰地看到,移动代码的百分比从2020年的25%下降到了13.4%,这是所有数据中唯一一个反向特例。
更少的移动意味着更少的重构和复用,加上大幅增长的添加、复制/粘贴代码,这表明:
AI编程工具并不鼓励代码复用、在已有代码上进行修改,而是更倾向于“无脑重写”。
在此,GitClear也指出,过度新增代码、复制/粘贴对代码的长期可维护性也相当不利。
这其实在人类程序员中也是老问题,可能是程序员觉得解决当下问题比思考如何复用、整合现有代码更快更容易,也可能是因为同个项目组中的开发人员沟通不畅等。
遭殃的就变成后面的维护人员。
Copilot的代码质量下降也体现在代码流失率(Churn)这个数据上。
在此,它的标准定义是代码编写后不到两周的时间内修改更新的百分比。
表格显示,2020年的流失率为3.3%(那会还没有用上Copilot),2023年增长到5.5%。
GitClear预计,2024年将直接相比2020年翻一番之多,达到7.1%。
这说明AI的加速,并没有带来足够高质量的代码。
除了以上结论,GitClear还发现,Copilot的代码建议算法还被设计为总是提出最有可能被用户接受的建议——
这选择乍一听没啥毛病,但其实会忽略代码简洁易读的重要性。
总的来说,这项结果足以让那些担心AI编程工具会取代人类程序员的人暂时把心放肚子里。
最近也有不少其他研究佐证了GitClear的发现。
比如来自CodeScene的一篇报告就表示:
在编码任务中,AI远无法取代人类;今天的AI太容易出错,且远未达到能够安全修改已有代码的程度。
网友体验大差不差
实实在在使用过Copilot的人怎么说?
一位网友表示:
我用了俩个月后取消了会员,因为花了太多精力去检查AI给出的代码以及修复bug。
在TA看来,现阶段还是自己编写内容要省力得多,因为自己知道自己想要写什么,修复自己的bug总是比修复机器人的更容易。
有人使用的是ChatGPT而非Copilot,也对TA的话表示了赞同:
我对AI的能力感到惊讶,但还是不会称其为“好代码”。
当然,Copilot在大家眼里也并非一无是处。
一位从事web开发20多年的程序员就表示:
用它编写重要的SQL或TypeScript代码时,总是失败;但对于编写测试、请求处理、React样式等等来说,它还是可以帮我节省大量时间的。
你的Copilot(或者其他AI编码工具)体验如何?你同意GitClear的发现吗?
参考链接:[1]https://devclass.com/2024/01/24/ai-assistance-is-leading-to-lower-code-quality-claim-researchers/[2]https://visualstudiomagazine.com/articles/2024/01/25/copilot-research.aspx[3]https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
— 完 —
点这里👇关注我,记得标星哦~
一键三连「分享」、「点赞」和「在看」
科技前沿进展日日相见 ~