Last week I found myself vibe coding a personal OKR app. I’d start with a rough idea, look at what Claude Code produced, tweak it, add functionality, rearrange the layout—and then do it all again. The app emerged through conversation, not specification.
I didn’t know what I wanted until I saw it.
This felt familiar. Not from coding, which I don’t do professionally. It felt like drawing.
Pantsers and Plotters
In the writing world, novelists sort themselves into two camps: plotters and pantsers. Plotters fill out character worksheets, map the three-act structure, diagram subplots and turning points. Only then do they write a single sentence of prose. Discovery writers—pantsers, from “flying by the seat of your pants”—work the opposite way. They write to discover what they’re thinking. The characters reveal themselves as the story unfolds. Plot twists emerge from the writing itself.
Neither approach is wrong. Brandon Sanderson plots obsessively. Stephen King is a famous pantser. The finished books can be equally brilliant.
But until now, software development has been firmly in the plotter camp.
The Plotter’s Art
Traditional software development is specification work. You figure out what you want, document it exhaustively, then implement the spec. The tools reward this: you can’t easily undo architectural decisions, rewriting is expensive, and production code needs stability. This isn’t a bug in the process—it’s the reasonable response to materials that resist change.
Nate’s newsletter this morning drew the distinction sharply: Codex excels when you can define technical correctness upfront, when you know what “right” looks like before you start. Claude Code wins when intent needs to evolve through the work, when you’re discovering what you want as you build.
But I think there’s something bigger happening here.
Drawing as Conversation
Bryan Lawson, in How Designers Think, describes sketching as “drawing as a conversation with yourself”—the designer is in dialogue with their own emerging ideas. You put a mark on paper. You look at it. The mark suggests something. You respond. The drawing isn’t a plan you execute; it’s a thinking process made visible.
This is what I experienced with my OKR app. I’d describe what I wanted in rough terms. Claude would build something. I’d look at it—really look at it, not compare it against a specification—and discover that I wanted something different. Or that I wanted exactly this, plus something I couldn’t have articulated until I saw it missing.
The conversation was the design.
Tools Shape Thought
For decades, we’ve had conversational tools for some kinds of creation. Google Docs lets me write by feel, discovering my argument as I draft. Procreate lets me paint, building an image through responsive dialogue with the canvas. Figma lets designers sketch ideas quickly enough to think with them.
But software? Software required the plotter’s discipline. You couldn’t discover what you wanted while building it—the cost of change was too high. Even prototyping tools fell short: they gave you mockups, not working interactive systems. The gap between sketch and software stayed wide.
Claude Code closes that gap. For the first time, I can pants my way through software.
What Discovery Coding Reveals
Let me be clear about what this is and isn’t. Vibe coding a personal app is not building production software. My OKR tracker doesn’t need test coverage, security audits, or scalability planning. If I were building software for others—for real users, real stakes—I’d still need the plotter’s discipline.
But that’s the wrong comparison. This isn’t about replacing serious engineering. It’s about enabling a new kind of creation.
When I discovered what I wanted through building it, I learned things no amount of upfront specification could have taught me. I learned which features I actually cared about by seeing which ones I kept tweaking. I learned how I think about OKRs by watching myself rearrange the interface. The app became a mirror for my own cognition.
And here’s where it gets interesting: once I know what I actually want—once the conversation has revealed it—I can write that specification. If I needed production code, I’d now know what to specify. Discovery and planning aren’t enemies. They’re phases.
Loss Aversion and the Freedom to Explore
There’s a psychological dimension here too. Loss aversion makes us cling to what we’ve built. The more code we’ve written, the more we resist changing it. This creates a gravitational pull toward our first solutions, even when better ones become visible.
But when rewriting is nearly free—when you can describe a different approach and get working code in minutes—that gravitational force weakens. You explore more widely. You’re willing to throw away what isn’t working. The sunk cost fallacy loses its power when the costs aren’t sunk.
I found myself more experimental than I’d ever been with software. I’d try approaches I wasn’t sure about, because trying was cheap. Some failed. Some taught me something. A few became exactly what I’d been looking for without knowing it.
Where This Goes
I suspect we’re going to see new kinds of interactive products emerge from this. Things that couldn’t be conceived through specification alone. Things their creators discovered by making them.
The prototypes won’t ship directly to production. The vibecoded experiments will need rewriting for deployment, proper engineering, all the serious work of software. But that rewriting step becomes less daunting when you know exactly what you’re trying to build—because you’ve already built it once, messily, in conversation with the machine.
This is the pantser’s gift: by writing to discover, you eventually know your story well enough to plot it. By coding to discover, you eventually know your software well enough to specify it.
Maybe for the first time, we can make interactive products the way we’ve always made art. In conversation. By discovery. Flying by the seat of our pants until we finally see what we were trying to build.
I can’t wait to see what people make.