Vibecoding Has a Thinking Problem

How clarity before code changed how I build with AI

In February 2025 Andrej Karpathy posted a tweet that would go on to become Collins Dictionary’s Word of the Year. He described a new approach to programming he called “vibe coding,” where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” You describe what you want in plain English. The AI writes the code. You accept it without reading the diffs. If something breaks, you paste the error back in and keep going.

(Karpathy’s original post on X, February 2, 2025)

The tweet went viral. And within months, the world ran with it.

By March 2025 Y Combinator reported that 25% of startups in its Winter batch had codebases that were 95% AI-generated (more on TechCrunch). Tools like Cursor, Replit, and Lovable made it possible for non-technical founders to ship working prototypes in a weekend. By mid-2025, surveys showed 84% of developers were using AI coding tools, with over half using them daily.

Searches for “vibe coding” jumped 6,700% in spring 2025 alone (more on Exploding Topics). The promise was intoxicating: anyone could build software, and the only language you needed to know was English.

But here’s what almost no one talks about: most of what gets vibecoded doesn’t survive contact with reality.

By September 2025 Fast Company published a piece declaring the honeymoon was over. Senior engineers at companies like PayPal reported that AI-generated codebases were becoming impossible to maintain: fast to ship, brutal to debug (more on Fast Company). Even Karpathy himself went back to hand-coding his next project, Nanochat, building it from scratch without AI assistance (more on Futurism).

The problem isn’t bad tools. The tools are genuinely extraordinary and are actually getting better every day. The problem is skipping the thinking.

From Vibecoding to Context Engineering to Agentic Automation

By late 2025 the conversation shifted from “vibe coding” to what Thoughtworks and others began calling “context engineering,” a systematic approach to manage how AI systems process information rather than relying on intuition alone (more on Thoughtworks / MIT Technology Review). The insight was simple but important: the models weren’t failing because they lacked capability. They were failing because people weren’t giving them enough structured context to work with.

But the most interesting development came in early 2026, and it went beyond just how people write prompts.

Anthropic’s Claude Code, originally released as a terminal-based coding tool for developers, quickly became something much broader. Users started deploying it for vacation research, building slide decks, cleaning up email, even controlling their oven (more on X).

By September 2025, Claude Code was generating over $500 million in annual run-rate revenue, and by early 2026 had crossed $1 billion (more on BuiltIn).

Then in January 2026, yes, January was a long month, Anthropic launched Cowork, essentially “Claude Code for the rest of your work” (more on Anthropic). Instead of requiring a terminal, Cowork lets anyone point Claude at a folder on their computer and describe what they need done. Organize a messy downloads folder. Turn a pile of receipt screenshots into an expense spreadsheet. Draft a report from scattered notes. Claude figures out the steps and handles it. By January 30, Anthropic added a plugin system with 11 open-source plugins covering sales, marketing, finance, legal, and more, letting users tailor Claude to specific job functions without writing a single line of code (more on SiliconAngle). The market reaction was immediate: a $285 billion selloff across software, financial services, and legal tech stocks as investors recalculated which knowledge-work tasks were now automatable (more on Bloomberg).

This is a meaningful shift. The vibecoding era was about individuals building apps. The agentic era is about individuals automating workflows. And that changes who the power users are. As Anthropic’s own 2026 trends report put it, engineers are shifting from writing code to coordinating agents, focusing their expertise on architecture, system design, and strategic decisions (more on Anthropic).

The pattern is the same one we discovered at Nido: the value isn’t in building shiny tools. It’s in automating the tedium around decisions. And now the tools to do that are available to everyone, not just developers.

The Real Problem: Judgment Can’t Be Automated

At Nido Ventures we’ve been experimenting with AI-powered tools since the early days. We’ve built small internal tools, automations, and workflows to streamline how we operate the fund. And through that process, we’ve learned something counterintuitive.

The most valuable things we’ve built aren’t tools. They’re automations. And the difference between the two comes down to what you’re trying to replace.

Here’s a concrete example. Early on, we built a Deck Analyzer, a tool that ingests a startup pitch deck and gives you structured insights: market size assessment, team background, competitive landscape, red flags. On paper, it sounds incredibly useful. And the insights were genuinely good. But at the end of the day, there’s nuance that goes into the decision to talk to a founder or not. The pattern recognition, the gut feeling about timing, the read on a team’s hunger. That’s judgment. And judgment is exactly what AI is worst at automating.

Compare that to our Deal Intake automation. This is a Zapier workflow that ingests founder calls, centralizes meeting notes, populates our CRM, and keeps everything in one place. It doesn’t try to make any decisions for us. It just eliminates the tedium around the decision. And it has saved us countless hours.

The pattern is clear: vibecoding works best when you’re automating the boring stuff around a decision, not the decision itself. This is the distinction that most vibecoding advice misses entirely. The conversation is dominated by what tools to use, which models are fastest, and how to write better prompts. But the real unlock has nothing to do with the code. It’s about understanding the problem deeply enough to know what’s worth building in the first place.

Think Like a PM, Then Vibecode

Here’s the workflow I’ve developed, that has helped me build things that people want to use.

Before you touch any tool, do the product work. Use AI as your pair product manager, not as your developer. I use Claude to co-create what is essentially a Product Requirements Document (PRD) before a single line of code gets generated. This isn’t complicated, and you don’t need a product management background to do it. But it forces you through a thinking process that changes everything downstream.

For a simple automation, like our Deal Intake flow, a one-pager is enough. It answers three questions:

1. What’s the problem? (We’re losing information between founder calls and our CRM.)

2. What’s the current workflow? (Someone takes notes on a call, then manually logs it in three different places, and things get missed.)

3. What does “done” look like? (Call ends → notes are auto-captured → CRM is updated → team is notified. No manual steps.)

Those three questions force you to map the actual workflow before you automate it, and that mapping is where most of the value lives. Nine times out of ten, the act of writing the one-pager reveals that the problem you thought you had isn’t quite the problem you actually have.

For a bigger project, you need a real PRD or your own version of a requirement document. I’m building something right now called CasitaOS, a home management system, and the PRD process has been essential. Not because Claude couldn’t build the whole thing in one shot (it probably could). But because I needed to think through what actually adds value versus what just sounds cool. The PRD forces specificity: Who is this for? What’s the core use case? What does an MVP look like?

The conversation with Claude as a pair PM is the most underrated part of this workflow. I don’t just ask Claude to write the PRD. I ask it to push back on my assumptions, poke holes in the logic, and help me sequence what matters. By the time we’re done, I have a document that could be handed to any builder, human or AI, and produce something coherent.

Version Your Thinking, Not Just Your Code

This brings me to what I think has revolutionized my ability to build with AI: versioning my thinking.

The temptation with AI tools is to build everything at once. The model is capable of it. The token window is big enough. Why not just describe the whole vision and go for it?

Because you don’t yet know what matters.

Versioning isn’t a technical constraint. It’s a thinking discipline. When you define what v1 looks like versus v2 versus v3, you’re forcing yourself to make value judgments: What’s the minimum thing that would be useful? What can I learn from using v1 that changes what v2 should be? What did I think was essential that turned out to be noise?

This is especially important for operators and founders who aren’t developers. Version control from a technical perspective (Git, branches, rollbacks) is still a real challenge for many people who vibecode. When you build everything in one shot and something breaks, you often can’t go back. You either fix it or start over. That’s not a workflow; that’s a gamble.

But if you build in deliberate stages, each version becomes a checkpoint. V1 is the automation that handles the core workflow. V2 adds the edge cases you discovered by actually using v1. V3 is the polish. Each stage teaches you something, and each stage is recoverable.

The irony of vibecoding is that the people who get the most out of it are the ones who slow down before they speed up.

The Framework: From Problem to Product

Here’s a simple framework for anyone who wants to build with AI more deliberately.

Step 1: Identify the pain. What workflow is eating your time? What process do you dread? Start there, not with what’s technically possible.

Step 2: Map the workflow. Before you automate anything, write down how it currently works. Every step. Every handoff. Every place where things get lost. This is where the real insights hide.

Step 3: Write the spec. For small automations, use a one-pager (Problem / Current Workflow / Done State). For bigger tools, co-create a PRD with Claude or your AI of choice. The goal is clarity, not length.

Step 4: Build v1. V1 should do one thing well. Use AI to build it fast; that’s what these tools are for. But build only what the spec says.

Step 5: Use it. Actually use what you built. Pay attention to what works and what doesn’t.

Step 6: Iterate. Now build v2, informed by what you learned. This is where vibecoding gets genuinely powerful, not as a one-shot miracle, but as a rapid iteration loop guided by real experience.

The Opportunity Nobody’s Talking About

The vibecoding conversation is stuck in a binary: either it’s going to replace developers, or it’s a dangerous toy for amateurs. Both miss the point. The real opportunity is for operators, people who understand workflows, feel the pain of inefficiency, and know their business inside out, to become builders. Not by learning to code, but by learning to think like product managers. The AI handles the syntax. You handle the strategy. And with tools like CoWork, you don’t even need a terminal anymore. You need a folder on your desktop and a clear description of the outcome you want.

So before you open Cursor, before you describe your next app to Claude, before you give in to the vibes, take 15 minutes and write down the problem. Map the workflow. Define what “done” looks like. You’ll be amazed at how much better everything works when you start with clarity instead of code.

If you want to see more short-form AI related posts follow @codebloodedbitch on Instagram or Tiktok.