Lately, I’ve been reflecting on a concept that’s been gaining traction in the developer community: “vibe coding.” The term gained prominence after computer scientist Andrej Karpathy discussed it in October 2024, referring to a programming approach leveraging large language models to generate code from natural language descriptions. Karpathy described this method as a conversational interaction with AI, where he would “just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works.” (Original tweet)
Over the past six months, I’ve immersed myself in tools like Gemini 2.5 Pro, Cursor, GitHub Copilot, and various chat interfaces to different models. These tools have significantly enhanced my productivity—not by producing flawless code outright, but by fundamentally reshaping my development process.
My workflow has undergone a notable transformation. While these AI tools excel in exploration and ideation, I seldom deploy code exactly as generated. Instead, I engage in a dynamic, iterative process—rapidly prototyping multiple approaches, assessing their viability, and identifying potential pitfalls. This method resembles sketching preliminary drafts before committing to a final piece, fostering intuition and insight into the problem space.
This approach is liberating. Since initial iterations are AI-generated, discarding them carries no remorse. This contrasts sharply with my previous experiences, where manually written code often led to a sunk-cost mentality, making it harder to abandon flawed directions. Now, if a prototype doesn’t meet expectations, I simply move on, unencumbered.
The time savings are substantial. Achieving a functional prototype now takes mere hours, whereas previously, it might have required days. This efficiency opens avenues for broader exploration, allowing me to entertain ideas that once seemed too risky or time-intensive. I can experiment with numerous approaches before lunch and dedicate the afternoon to refining the most promising one.
However, this methodology leans heavily on experience. Decades of coding, familiarity with design patterns, system architecture, and honed intuition guide me in effectively interacting with the AI—knowing what to request, interpreting outputs, and steering the development process. Without this foundation, the experience might feel less like a collaborative dance and more like navigating without a map. This experience isn’t just about knowing syntax; it’s about the architectural intuition to guide the AI, the pattern recognition to spot plausible-but-wrong suggestions, and the judgment to know when a generated snippet is truly production-ready versus merely a starting point.
The landscape of AI-assisted development continues to evolve with the emergence of tools like Bolt.new and Gemini Canvas. These platforms take vibe coding a step further by enabling the creation of full web applications through natural language prompts. With Bolt.new, users describe their envisioned application, and the AI generates the corresponding code, providing a workspace for further customization. Gemini Canvas offers an interactive environment where users can draft, edit, and preview web applications in real-time, toggling seamlessly between running applications and underlying code.
While these advancements are impressive, they also evoke a sense of caution. Relying heavily on AI for code generation raises questions about the quality, security, and maintainability of resulting applications. It’s crucial to balance the convenience of AI assistance with thorough review and understanding of produced code, ensuring adherence to best practices and alignment with project requirements.
In essence, tools like Bolt.new and Gemini Canvas are transforming the development landscape, making it more accessible and efficient. However, they also underscore the importance of maintaining a critical eye and an active role in the development process to deliver robust and reliable applications. Even so, I believe this is just the beginning. As these tools improve, the line between prototyping and production will blur further. For now, I’m embracing this rhythm—coding by feel, following the vibes, and letting curiosity lead the way.
Yet, I don’t think we’ve seen the end of this trend. If anything, we’re just getting started. Frontier labs are intensely focused on enhancing coding and, crucially, machine learning engineering capabilities within their models. OpenAI explicitly discussed this when introducing MLE-Bench last October, building and evaluating AI tools specifically to assist with complex, domain-specific tasks performed by their own machine learning engineers. Improving AI’s ability to contribute to ML workflows accelerates internal research and development cycles, creating a powerful feedback loop.
But for all the progress in the models themselves, the interface still lags behind. Tools like Cursor, Copilot, or AI-assisted editors in VS Code remain designed around source code as the primary focus. Yet when deeply immersed, the code increasingly feels secondary. The conversation is paramount. Until interfaces evolve to truly center conversation, we might only scratch the surface of this collaborative paradigm.
The tools need to catch up with this shift. The interface should support conversation as the primary modality. Karpathy’s original idea resonates here—I don’t want a passive assistant or a fancy text editor. What I want is closer to sitting beside a truly skilled engineer, working through problems together.
It reminds me of pair programming practices common in Google’s early days. We’d sit side by side at one computer, each with our own keyboard and mouse, either person able to take over at any moment. There’s a great description of this dynamic in The New Yorker’s piece on the friendship that made Google huge. That spirit of collaborative problem-solving—real-time, fluid, and deeply interactive—is exactly what I desire from my AI partner.
That’s my goal—not an editor, not a command-line interface masquerading as a co-pilot, but a true thought partner. Someone—or rather, something—up to date on the latest trends, fluent in new languages, well-versed in modern idioms and design patterns. A partner who sees what I see, tracks what I’m pointing at, and understands half-formed questions I ask aloud. We’re not there yet. But I can feel it getting closer, and I’m genuinely excited about where this path leads.
But that’s just my perspective after diving into this world. What about yours? I’d love to hear your thoughts in the comments. What aspects of ‘vibe coding’ resonate with you, and what challenges have you faced? What’s working well in your AI-assisted workflow, and what improvements or future directions are you most excited about?
[…] in April 2025, before this series even started, I wrote about waiting for a true AI coding partner. I was describing something I could feel but couldn’t quite build yet: an AI that […]
[…] lately, especially as I’ve moved more of my workflow into the Gemini CLI. If we want AI to be a true partner in our development process, it can’t just live in a silo. It needs access to the context of our […]
[…] we’re seeing the same story play out with the rise of AI-assisted development, or “vibe coding.” The idea of talking to an AI to build software feels like the next logical, almost […]
[…] the architectural decisions we made ten minutes ago. It can answer a question, but it can’t be a true partner if it starts every conversation from […]
[…] in April, I wrote about waiting for the true AI coding partner. I articulated a vision for an AI that transcends mere code generation, one that truly understands […]
[…] While I appreciate the creative input from AI models, I don’t yet see this approach as the true AI coding partner I envision. Instead, these models currently serve as tools that help me explore possibilities, challenge […]