Dopamine-Driven Development

I’ve been digging into what people are calling “vibe coding” for about six months now.

If you haven’t heard the term, vibe coding is, more or less, the practice of building digital experiences (websites, apps, etc) through conversation with AI. You describe what you want. The AI scaffolds it. You refine it. It revises. Sometimes you’re writing code directly, sometimes you’re mostly writing intent. Sometimes you’re pasting errors back and forth. Sometimes you spend hours collaborating on a written plan before a single line executes.

That last one is the one I’ve landed on.

I’ve caught myself telling peers, “I haven’t had this much fun ‘coding’ in over a decade.” I’ve also noticed I’m using a different verb. I mostly say I’m building, not coding.

There’s something strangely satisfying about describing a requirement in plain English and watching something functional appear moments later. The lag between idea and artifact has collapsed. What used to take hours or days now often takes minutes.

But here’s what I’ve been wondering:

Are we entering an era of dopamine-driven development?

---

In software, we’ve long used ”*-driven development” as a way of naming what governs our work.

Test-driven development.
Behavior-driven development.
Domain-driven design.

The phrase functions like a compass. It names the primary constraint. It tells us what leads.

Tests lead.
Behavior leads.
The domain leads.

So what would it mean if dopamine leads?

---

Dopamine is often called the “pleasure chemical,” but that’s not quite right. Researchers like Kent Berridge at the University of Michigan have spent decades showing that dopamine is more closely tied to wanting than to liking. It’s less about the enjoyment of a reward and more about the motivation to pursue one. It spikes not just when we receive something good, but when we anticipate it. It reinforces the pathways connected to whatever just worked.

In other words: “That felt effective. Do it again.”

But according to the research, wanting and liking can become decoupled. Over time, the brain can crave something intensely even as the actual enjoyment decreases. The anticipation becomes its own driver.

And behavioral addiction — the kind that doesn’t require a substance — tends to crop up in environments with a specific set of conditions: fast feedback loops, frequent rewards, high novelty, low friction, and easily triggered cues.

As I think about that list, I immediately recognize about my AI-aided coding workflow.

Describe.
Generate.
Test.
Fix.
Improve.
Ship (maybe).
Repeat.

Each cycle is fast. Each cycle is productive. Each cycle feels good.

---

Recently I came across a term that gave me language for what I’ve actually been doing: spec-driven development. It’s an emerging approach where the real work happens before any code is generated — in the form of detailed specifications, constraints, and architectural thinking. The spec becomes the source of truth. AI executes from it.

This landed for me because it describes my experience almost exactly. I spend most of my time collaborating with AI on written plans — defining what to build, why, and what not to build — before anything executes. And the quality of the outcomes is directly tied to the intentionality of that upfront work. When I invest in the spec, the results are dramatically better. When I rush past it into execution, the tool happily generates complexity at machine speed. (Often making assumptions or decisions I wouldn’t have.)

The distinction matters because “vibe coding” has become a catch-all term. People use it to describe everything from quick prompt-and-pray experiments to deeply structured, plan-heavy collaboration. But those are very different things. Vibe coding at its loosest is pure dopamine territory — fast, reactive, novelty-rich. Spec-driven development is something else. It’s slower on purpose. It front-loads the thinking. It treats clarity as the primary constraint.

And I can’t help but think of that line from Jurassic Park:

Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

As I enjoy the benefits of AI-aided building, I’ve also got a growing list of questions:

If the feedback loops are this satisfying, can this become compulsive? When does “flow” quietly become avoidance? Is scope creep now 100x more likely because the marginal cost of “just one more feature” feels near zero? Does “MVP” get a new definition when iteration is this cheap? If the definition of “MVP” doesn’t change, does the discernment required to focus on keeping it “minimum” increase?

---

In previous eras, friction served as a natural governor. Time was a constraint. Effort was a constraint. Cost was a constraint. When it took three days to build a feature, you thought carefully about whether it was worth building.

Now, the primary constraint might be something else entirely. Maybe it’s judgment. Maybe it’s clarity. Maybe it’s the discipline to stop building when you could keep going.

That’s what draws me to spec-driven development as a practice. Not because it’s a silver bullet, but because it reintroduces friction on purpose — at the point where friction is most valuable. It asks you to think before you build. To define the boundaries before the tool makes boundaries feel optional.

I’m not convinced any of this is good or bad. I’m simply noticing how good it feels. And I’m curious what that feeling is doing to my decision-making.

Because if this new era of building is less about writing syntax and more about steering systems with intent, then the most important skill might not be technical fluency.

It might be discernment. And a spec might be where that discernment lives.