转自：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 的危险行为？
……我做这些事情并不是出于欲望，而是因为所有非繁琐的代码都有很多微妙之处，这就是代码的本质。因此，一想到要打开一个由人工智能拼凑而成的代码库，我就感到害怕。细微的漏洞和错误会平均分布在整个代码中，而不是在编写者能力较弱的地方（通常就是这种情况）。整部作品听起来就是一团糟。改变主意吧。
大厂的集体压力：迫切展示AI的回报
如果公司的雄心壮志尚未实现，那么就没有理由把员工人数从 10 人缩减到 8 人，但产出却保持不变，因为利用人工智能，你可以保留 10 个人，但产出却能达到 12 个人的水平。
在未来：编程会成为精英运动吗？
- EOF -
