A Skeptic's Guide to Vibe Coding

I used to have a pretty negative view on the term "vibe coding." To me, it always sounded like some sloppy engineer just churning out buggy or inefficient code without much thought or proper testing. But after listening to Keith Ballinger, VP and GM at Google Cloud, on episode 6 of the Agent Factor podcast, my perspective started to shift. Keith showed that vibe coding isn’t just chaotic or careless; it’s actually a pretty structured approach that channels that vague sense of "vibe" into a clear, actionable plan. One of the coolest parts of the episode was when Keith decided to vibe-code a command line markdown viewer using the Gemini CLI right on the show. That demo really stuck with me because it wasn’t just hacking together code—it was a step-by-step, methodical process that I’m definitely gonna steal for my own workflow. The first step he took was to focus on the user experience before writing any code. He asked the Gemini CLI to draft a UserGuide.md file that detailed what the program should do—paginate long markdown files, include syntax highlighting, and avoid any editing functions. This forced clarity on the project goals from the user’s perspective, making sure everyone was on the same page before diving into technical stuff. Next up, Keith got advice on which programming language to use. Instead of defaulting to something familiar, he asked the AI for three options and a final recommendation. This part is super smart because it keeps you from getting stuck in your comfort zone and might push you to learn a new tool better suited for the job. It’s a good reminder to stay open and flexible, especially when working with AI assistance. After locking down the user guide and picking a language, Keith had the AI draft a technical design saved in Arch.md. This document served as a blueprint outlining the tech stack and architecture in detail, with a checkpoint for review before writing any code. Separating design from implementation like this makes it easier to catch issues early and adjust the direction if needed. The core of Keith’s approach came next: creating a comprehensive plan.md file with a numbered list of discrete tasks. This turned the vague idea into a clear roadmap, preventing the AI from jumping ahead or trying to build everything all at once. It set the project on a clear path, step-by-step. He also gave meta-instructions directing the AI to update the plan.md and arch.md files as tasks got completed or designs changed. This self-documenting process keeps the whole workflow transparent and easy to pick up later without losing context. And just for fun, Keith added a bit of personality to the AI’s responses, asking it to call him "K-bro" and use puns. This lighthearted touch made the interaction way more enjoyable, reminding me how much nicer it is to work with AI that feels a bit more human, less like a cold machine. The biggest lesson for me was realizing vibe coding sits on a spectrum—from exploration to acceleration. When you’re working in an unfamiliar domain, it lets you experiment and iterate rapidly, making daunting projects way more approachable. When you’re an expert, it helps you speed through routine tasks and focus on the important stuff. Keith’s workflow made me want to jump back into building and prototyping more often. It’s about embracing process, using AI not just to get code done, but to do it thoughtfully and creatively.