Do Google engineers actually vibe code?

### TL;DR 前Google工程师揭露：公司内部所谓的“AI生成代码”在2024年多半只是自动补全，真正的“氛围编程”因技术孤岛和强审查文化而受限，直到2026年仍存在效率与责任的冲突。 --- ## 嘉宾与背景 本期节目邀请了一位前Google高级软件工程师，他在YouTube平台工作了六年半，主要参与功能开发。离职后，他愿意坦白分享Google工程师如何（以及如何不）使用AI工具进行“氛围编程”。他坦言，两年前就想做这个视频，但怕被开除，现在终于可以畅所欲言。 ## 什么是“氛围编程”？ “氛围编程”（vibe-coding）这个词由Andrej Karpathy推广，原意是：你完全沉浸在氛围中，甚至忘了代码存在，连一段程序用什么语言写的都说不出来。典型场景是用Bolt、Lovable或Claude Code等工具搭建东西，但对底层机制毫无概念。 在日常使用中，人们往往把任何使用AI工具（如Cloud Code、Codex、Gemini CLI）的行为都称为“氛围编程”，即使你熟悉语言、文件结构，甚至对实现方式有直觉。为了区分，嘉宾从BBC电台采访中听到了“代理工程”（agentic engineering）这个术语——指通过编排代理并审查其输出来编写代码，仍保留真正的工程判断。虽然这个词不够顺口，但有助于在讨论中区分不同层次的AI使用。 ## Google内部的AI编码：2024年的真相 2024年底，Google CEO Sundar Pichai公开表示公司超过25%的代码是AI生成的。嘉宾当时目瞪口呆，因为他自己和他认识的所有人根本没有进行任何“氛围编程”——这个词当时甚至还没被发明。他推测，所谓的“25%”其实是指IDE自带的自动补全功能变得更聪明了，能补全整个方法。大家只是不停地按Tab键接受建议。他感叹：“这不算数。” 公众听到“25%代码由AI生成”时，会想象一群代理在写代码，但现实只是工程师一遍遍按Tab。 嘉宾还提到，当时内部使用的自动补全工具有硬限制，容易丢失上下文，经常只生成半个函数，然后逻辑就断了。所以2024年虽然有AI生成的代码，但绝没有人真正在Google里进行“氛围编程”。此时外界已经开始流行Cursor等工具，但Google内部只能用自研产品。 ## 技术孤岛：自己造一切的文化 Google有一个根深蒂固的习惯：一切软件都自己造，不用开源、不用第三方工具，连餐厅菜单都有定制软件。这种模式过去很有效，但在AI飞速变化的时期成了障碍。每次外部新工具发布，Google内部至少要等几个月才能有类似产品——如果它被开发的话。 最典型的例子是内部使用的框架“Fleebal Floorp”（化名），模型完全没有在它上面训练过，生成的代码往往是三种不同的意大利面条，根本编译不过。直到2026年中，嘉宾离职时，让AI生成Fleebal Floop代码仍然可能产生无法编译的结果。这种技术孤岛让Googlers非常沮丧，他们私下用着外部的AI工具，却被禁止在工作中使用。甚至有员工公开威胁：“如果不让我们用XX工具，我就辞职。” ## 强工程文化：审查与责任 Google的工程文化要求开发者必须知道自己在写什么代码，并对每一行负责，确保代码经过严格审查。这种文化杜绝了人们提交一大段“氛围编程”垃圾PR。嘉宾回忆，有同事明显用AI工具修补bug，PR描述是完美英文语法写成的完整句子，审查者直接驳回并标注“这是AI垃圾，我不审”。 在影响youtube.com这种规模的产品时，这种谨慎态度是合理的——不能允许随机AI生成的代码有潜在可能性拖垮整个网站。但另一方面，这种文化也拖慢了速度。 ## 2026年的紧张关系：推广与抗拒 到2026年，“氛围编程”工具已变得非常好。Google内部推广Gemini CLI和antigravity（两者本质都是“氛围编程”工具），领导层公开鼓励多用这些工具。但与此同时，工程文化仍然要求工程师对代码负责，不能把理解代码是否安全的负担全推给审查者。 理想情况下，可以用AI生成所有代码，然后逐行审查、真正理解每一行。但现实中，当AI生成的代码通过了所有测试时，开发者往往没有动力去逐行检查，尤其是在不熟悉的代码库或语言中。如果强行要求逐行审查并完全负责，那就违背了用AI加速的初衷——花的时间可能和手写差不了多少。 ## 结论 嘉宾认为，在大公司整体趋势中，主张逐行手动审查代码的人很可能会输给那些只想让工程师加速的人。效率的压力最终会压倒谨慎的文化，但如何平衡安全与速度，仍然是悬而未决的问题。 --- Source: [Do Google engineers actually vibe code?](https://www.youtube.com/watch?v=PbsocBPkoUc)