来自公众号:51CTO技术栈编辑 | 伊风
谷歌员工:25%掺水了,工程还是我们做
人在谷歌,刚刚下班。我就是写所谓 'AI 生成代码”的人。比如我写 'function getAc...',“鹅”就会很聪明地补全为 'function getActionHandler()',也许还会建议正确的参数和一个像样的 jsdoc 注释。所以基本上,它是一个有用的生产力工具,但它根本不做任何工程设计。 它可能和 Copilot 一样好,甚至比 Copilot 稍差。 (不过我最近还没用过)
我也在谷歌工作(直到上周五)。同意你所说的。我的想法是:1. 这句话显然是在夸大现实,他们很可能把已经存在了十年的全自动 CL/PR 等也算作 '人工智能生成'。我之前说过,如果一个 10 人团队和一个 8 人团队在使用 copilot 等设备时效率相同,那么在我看来,说 '人工智能取代了 2 名工程师 '是公平的。更重要的是,如果这种说法是真的,技术领导者也会这么说。Copilot 及其克隆产品已经存在了足够长的时间,证据确凿,而且没有人说 '我们已经用人工智能取代了 X% 的劳动力'--因此,我的说法是(通过 '否认结果'),使用 Copilot 并没有实质性地加速发展。
我觉得写代码几乎是一种放松,而且这只占开发工作的一小部分。纯粹靠编写代码片段来提高工作效率,我并不太感兴趣。我觉得提高可维护性、稳健性和其他质量指标(不是关注人工智能输出的质量,而是代码库的实际质量)更有意思。
作为一个工作了 20 多年的程序员,这实在是太可怕了。我愿意接受我只是得了 '滚出我的地盘 '综合症之类的说法,但让一个LLM来编写/移动大量代码的想法看起来实在是太不负责任了。每当我坐下来写代码时,无论是大型实现还是小函数,我都会考虑其他人(或未来的我)在与代码交互时会遇到什么困难。它是否简洁明了?是否过于巧妙?在进行修改时,是否太容易写入一个微妙的 bug?我是否通过添加注释或故意以其他方式让人看到 X 依赖于 Y 的危险行为?
……我做这些事情并不是出于欲望,而是因为所有非繁琐的代码都有很多微妙之处,这就是代码的本质。因此,一想到要打开一个由人工智能拼凑而成的代码库,我就感到害怕。细微的漏洞和错误会平均分布在整个代码中,而不是在编写者能力较弱的地方(通常就是这种情况)。整部作品听起来就是一团糟。改变主意吧。
如果公司的雄心壮志尚未实现,那么就没有理由把员工人数从 10 人缩减到 8 人,但产出却保持不变,因为利用人工智能,你可以保留 10 个人,但产出却能达到 12 个人的水平。
在未来:编程会成为精英运动吗?