开源函数式程序设计语言 OCaml 的主维护者拒绝了一个由人工智能生成的包含超过 13,000 行代码的拉取请求 (PR),理由是版权问题、缺乏审查资源,以及该请求与项目的维护实践不符。
这引发了关于人工智能和开源软件未来互动的关键问题。
OCaml 有着多个编译器,包括生成字节码的 ocamlc 和构建独立本地可执行文件的 ocamlopt。通常情况,OCaml 开发者使用字节码编译器进行代码开发和测试,但在生产环境中可能会使用本地编译器。OCaml 内置了一些用于调试字节码的工具,但使用本地编译器进行调试的功能则较为有限。
开发者 Joel Reymont 在使用原生编译器时,对缺少 DWARF 调试信息感到不满,于是转而使用 Claude Code 来添加此功能。
这里,DWARF是许多调试器(包括lldb(LLVM 调试器)和 gdb(GNU 调试器))使用的标准格式。
Reymont在他的博客中描述了如何使用 Anthropic 的 Claude Code 为 OCaml 原生编译器添加此功能。他表示道:“我没有编写任何一行代码,而是在几天的时间里精心引导 AI……我的工作只是指导、调整、引导和审查。” Reymont 将代码以pull request 的形式提交到了 OCaml 的 GitHub 代码库。
https://github.com/ocaml/ocaml/pull/14369
https://blog.janestreet.com/introducing-oxcaml/
其他发现的问题还包括:缺乏关于该功能的设计讨论、难以审查(Review)如此“庞大的代码量”,包括未来的维护负担,还有其他人正在开发类似功能但尚未准备好向上游合并,即 OxCaml 中的 DWARF 支持。
三年前,Scherer发帖称,OCaml 的“维护者们一直在抱怨,提交修改/PR 的人数远超过愿意审查这些修改/PR 的人数,导致审查环节出现瓶颈。” 这种情况至今仍未改善。Scherer 在 Reymont 的 PR 下评论道,人们提交“体积庞大但工作量相对较低的 PR,确实有可能导致 Pull Request 系统瘫痪”。他还补充说,根据他的经验,审查 AI 生成的代码比审查人工编写的代码更加费力。
经过一番讨论,Scherer关闭了该拉取请求,并表示“似乎没有一个可能对审查和支持 DWARF 支持的拉取请求感兴趣的人愿意承担这项工作……所以我认为它没有合并的可能。” 他说这并非是对代码本身的价值判断,而是开发方法与项目的理念不符。“目前 github/ocaml 的组织结构无法以这种方式运作。”
而 Reymont 声称人工智能对代码有着“深刻的理解”,但另一位开发者对此提出质疑,认为这表明他缺乏对 LLM(大型语言模型)工作原理的了解。
尽管这次活动存在一些问题,但Claude Code能够在人工监督下开发出如此复杂的功能,这本身很令人印象深刻,尽管代码的可靠性和质量尚不清楚。
Scherer在另一条评论中指出,“如果OCaml编译器能提供良好的原生调试支持就太好了”,并补充说,难点在于找到一种维护负担合理的实现方式。他再次表示,OCaml项目缺乏“关于人工智能辅助代码贡献的明确政策”。
如今,包括微软、谷歌和AWS在内的行业巨头大力推动人工智能编码,提交给开源项目的、全部或部分使用人工智能编写的代码提交请求(PR)的数量肯定会增加。人工智能的乐观主义者可能认为人工智能本身可以令人满意地审查这些PR,但考虑到大模型的输出并非确定性,而且诸如幻觉和提示注入等问题仍未得到解决,这种做法仍然存在着风险。
作者:行动的大雄
本篇文章为 @ 行动的大雄 创作并授权 21CTO 发布,未经许可,请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人,21CTO 平台仅提供信息存储空间服务。
请扫描二维码,使用微信支付哦。