Do Google engineers actually vibe code?

### TL;DR A former Google engineer reveals: the company’s so-called "AI-generated code" in 2024 was mostly just autocomplete. True "vibe coding" was limited by tech silos and a strong review culture, and the efficiency vs. responsibility conflict persists into 2026. --- ## Guest & Background This episode features a former senior software engineer at Google who worked on the YouTube platform for six and a half years, mainly on feature development. After leaving the company, he was willing to speak openly about how Google engineers do (and don't) use AI tools for "vibe coding." He admits he wanted to make this video two years ago but was afraid of being fired—now he can finally speak his mind. ## What Is "Vibe Coding"? The term "vibe coding" was popularized by Andrej Karpathy. It originally meant: you’re so immersed in the vibe that you forget code even exists—you can’t even say what language a piece of code is written in. A typical scenario involves using tools like Bolt, Lovable, or Claude Code to build something while having no clue about the underlying mechanics. In everyday usage, people often call any use of AI tools (like Cloud Code, Codex, Gemini CLI) "vibe coding," even if you’re familiar with the language, file structure, or have intuition about the implementation. To make a distinction, the guest heard the term "agentic engineering" from a BBC radio interview—it refers to coding by orchestrating agents and reviewing their outputs, while still retaining real engineering judgment. The term isn’t catchy, but it helps separate different levels of AI use in discussions. ## AI Coding Inside Google: The 2024 Reality At the end of 2024, Google CEO Sundar Pichai publicly stated that over 25% of the company’s code was AI-generated. The guest was stunned at the time, because he and everyone he knew were not doing any "vibe coding"—the term hadn’t even been invented yet. His guess: the "25%" actually referred to the IDE’s built-in autocomplete getting smarter, able to complete entire methods. People were just hitting Tab to accept suggestions over and over. He sighed: "That doesn’t count." When the public hears "25% of code generated by AI," they imagine swarms of agents writing code, but the reality was just engineers pressing Tab repeatedly. The guest also noted that the internal autocomplete tool at the time had hard limits, easily lost context, and often generated only half a function before the logic broke. So while there was AI-generated code in 2024, nobody inside Google was actually doing "vibe coding." Meanwhile, tools like Cursor were becoming popular outside, but Google could only use its own in-house products. ## Tech Silos: The Culture of Building Everything In-House Google has a deeply ingrained habit: build all software in-house, no open source, no third-party tools—even the cafeteria menu has custom software. This model worked well in the past, but it became a barrier during the rapid changes in AI. Every time an external new tool was released, Google had to wait at least a few months for a similar product—if it was developed at all. The most typical example is the internal framework called "Fleebal Floorp" (a pseudonym). The model had never been trained on it, so generated code often looked like three different kinds of spaghetti and wouldn’t even compile. By mid-2026 when the guest left, asking AI to generate Fleebal Floorp code could still produce uncompilable results. This tech silo frustrated Googlers, who privately used external AI tools but were forbidden from using them at work. Some employees even publicly threatened: "If you don’t let us use XX tool, I’ll quit." ## Strong Engineering Culture: Review & Responsibility Google’s engineering culture demands that developers must know what they’re writing and be responsible for every line of code, ensuring it undergoes rigorous review. This culture prevents people from submitting huge PRs of "vibe coding" garbage. The guest recalled a colleague who clearly used AI to patch a bug—the PR description was in perfect English, complete sentences. The reviewer rejected it outright, labeling it "AI trash, I’m not reviewing this." When affecting a product of youtube.com’s scale, this caution is reasonable—you can’t allow random AI-generated code to potentially bring down the entire site. But on the other hand, this culture slows things down. ## The Tension in 2026: Promotion vs. Resistance By 2026, "vibe coding" tools had become very good. Inside Google, they promoted Gemini CLI and antigravity (both essentially "vibe coding" tools), and leadership publicly encouraged using them more. But at the same time, engineering culture still required engineers to be responsible for their code and not shift the burden of understanding whether code is safe entirely onto reviewers. Ideally, you could generate all code with AI, then review every line and truly understand it. But in reality, when AI-generated code passes all tests, developers often lack the motivation to inspect every line—especially in unfamiliar codebases or languages. If you force line-by-line review and full responsibility, it defeats the purpose of using AI to speed up—the time spent might be nearly the same as handwriting it. ## Conclusion The guest believes that in the overall trend at big companies, those advocating for manual line-by-line code review will likely lose to those who just want to accelerate engineers. The pressure of efficiency will eventually overwhelm cautious culture, but how to balance safety and speed remains an open question. --- Source: Do Google engineers actually vibe code? (https://www.youtube.com/watch?v=PbsocBPkoUc)