I've been pretty vocal about my skepticism around "live coding" and the whole vibe coding movement. But working with AI tools over the past few months has clarified something important: my resistance wasn't really about the concept itself—it was about humans doing vibe coding for the wrong purposes.
Here's what changed my perspective: Andrej Karpathy coined the term "vibe coding" in February 2025, and within months, 25% of Y Combinator startups reported that 95% of their codebases were AI-generated. That's not hyperbole—that's actual adoption data showing we're in the middle of a fundamental shift.
The problem isn't vibe coding itself. It's that we've been treating all coding as if it requires the same approach, when there are actually two completely different categories happening.
Structured vs. Unstructured: Two Different Games
Structured coding is what we typically think of as "real" development. You're building a codebase meant to last. You've got architecture decisions, coding standards, unit tests, security considerations. The code gets deployed, maintained, extended. Multiple people work on it. You invest time upfront because you're planning for the long haul.
Unstructured coding is completely different. You're writing code to solve a specific, immediate problem. It's personal workflow automation. Maybe you need to process a CSV file, or batch rename some files, or pull data from an API for a one-time analysis. The code serves its purpose and gets thrown away. No one else needs to understand it. No deployment pipeline. No documentation beyond maybe a comment or two.
The problem with humans doing vibe coding isn't vibe coding itself—it's using vibe coding for structured problems. Research shows this creates serious issues: 9 out of 10 AI-generated projects contain basic security flaws, and teams experience a 7.2% decrease in delivery stability with increased AI usage.
But for unstructured problems? Vibe coding makes perfect sense. And that's where AI shines.
AI as Your Personal Vibe Coder
Here's what changed my perspective: AI can do the vibe coding for you.
I built an open source project (MCP Desktop Gateway) that gives Claude AI access to bash scripting, AppleScript, and JavaScript on my desktop. This builds on Anthropic's Model Context Protocol (MCP), which launched in November 2024 and has already become an industry standard for AI-desktop integration. Essentially, I handed Claude a toolkit for solving desktop automation problems.
Last week I needed to set a reminder for later in the day. Instead of opening an app or writing a quick script myself, I just asked Claude to handle it.
The interesting part: I have Google Tasks integration available, but Claude chose to use Apple Reminders instead. I'm not sure why it made that choice, but it worked perfectly. The reminder got created exactly when and how I needed it.
That's vibe coding in its purest form. But it's not me doing the vibe coding—it's AI doing the vibe coding based on my instructions. Maybe it's meta-vibe coding.
When Vibe Coding Actually Works
This experience clarified when vibe coding is appropriate:
One-off automation tasks where building proper tooling isn't worth the investment
Personal workflow problems that don't need to be shared or maintained
Quick data processing where the script gets used once and discarded
Desktop automation for repetitive tasks you want to eliminate
The key insight: vibe coding works when the return on investment for proper engineering doesn't justify the time investment. And AI dramatically changes that equation.
Research backs this up. Studies show that junior developers experience 27-39% productivity increases with AI coding assistants, while senior developers see more modest 7-16% gains. The pattern is clear: AI excels at the routine tasks that consume disproportionate time for less experienced developers—exactly the kind of unstructured problems where vibe coding makes sense.
The Tools Already Exist
LLMs and AI desktop tools are already moving toward coding solutions for input/output problems—they're just not being framed this way yet.
Tools like Zapier have integrated GPT-4o mini and introduced AI Agents that handle complex, multi-step workflows previously requiring custom development. GitHub Copilot now has Agent Mode that works asynchronously in the background. Microsoft reports teams gaining 30-40 minutes of productivity daily as developers focus on more intellectually stimulating tasks.
When Claude can access your desktop environment and write scripts to solve immediate problems through protocols like MCP, it's handling the entire category of tasks where vibe coding makes sense. You get the benefits—quick problem solving, minimal time investment—without the downsides of unmaintainable code cluttering your actual projects.
Where I Draw the Line
I still wouldn't use vibe coding (human or AI) for anything that needs legs. Building features for production systems, creating tools that other people will use, writing code that becomes part of a larger system—that requires structured approaches.
But for quick problems where I don't want to invest the time and there's no return on code reuse? Having AI handle the vibe coding is exactly the right approach.
The Broader Implication
This distinction between structured and unstructured coding might be more important than we realize. As AI gets better at handling unstructured problems, it frees us up to focus on the structured work that actually requires human insight.
The research paints a clear picture: AI excels at generating boilerplate code, detecting bugs, and automating tests, while humans retain responsibility for system architecture, strategic planning, and complex problem-solving. That's exactly the division of labor we want.
The goal isn't to eliminate all quick-and-dirty coding. It's to let AI handle the quick-and-dirty work so humans can focus on the architecture, design, and long-term thinking that actually moves projects forward.
Maybe the future of coding isn't about AI replacing developers. It's about AI becoming our personal automation layer for all the small problems that don't warrant proper engineering—while we focus on the problems that do.
Thanks for finally putting into words what's been on my mind - the difference between structured and unstructured projects, though not the words I would have used.
I would have used other terms like:
Industrial-grade vs. Hobbyist
Mission-critical vs. Quick-and-dirty