Vibe Coding Is Trying to Solve the Same Problem as BDD

Joe, my co-founder here at BiTE, is not a developer. He’s a product owner — came up through project management, has excellent design taste, has run more projects than I can count over the years. But he doesn’t write code.

Recently, Joe built a tool that helps him GM his Torg tabletop games. It generates art for his stories, calculates and records game mechanics, tracks campaign state. The kind of thing where every GM has a slightly different system held together with notebooks and spreadsheets, and Joe just went and built exactly the one he wanted. He’s also building an email triage tool because, while there are countless AI-applied-to-email tools in the market, nothing handles email the quite way he thinks about it.

Joe is vibe coding. And I love it.

This Isn’t New

Here’s the thing that keeps nagging at me as I watch the discourse around vibe coding: the impulse behind it is exactly the impulse behind Behavior Driven Development. Both are trying to solve the same fundamental problem — how do we get the people who aren’t writing code but who have critical knowledge into the process of creating software?

BDD’s answer was executable specifications. You write requirements in structured natural language that connects directly to test automation. The product owner, the domain expert, the clinician — they can read the specifications, they can challenge them, they can say “no, that’s not how that workflow actually works.” Their expertise shapes the code without them needing to write it.

Years ago, I dragged Joe — somewhat reluctantly — to a BDD training that Aslak Hellesøy, the creator of Cucumber, was running. Joe was skeptical going in. But something clicked during that session. He saw that executable specifications meant he wasn’t just writing tickets and throwing them over a wall. His input was directly influencing the code being created. And since a lot of our work at the time was in Ruby, he was genuinely surprised to find he could read much of the code itself.

Joe went on to lead BDD efforts at one of our clients and played a major role in how we used BDD to build Alethium. He went from reluctant attendee to one of the strongest advocates for the practice I’ve worked with.

Now he’s building his own software with AI. The same person. The same impulse. A different tool.

The Joy Is Real

Last Thursday night, I was at a local AI Leaders meetup. I talked with a bunch of people — involved in tech, but not developers — who had built entire systems through vibe coding. And what struck me wasn’t the software they’d built. It was the experience they described.

I’ve seen it with Joe. I’ve seen it with Carissa, our VP of UX/Design, who’s been experimenting with building her own project — partly to scratch an itch, partly to understand what the engineers on our team are actively using. And I saw it again at that meetup.

These people are going through all the same things programmers go through. The absolute joy when you make it all run and see what you’ve built. The agony of hitting a wall you can’t get past and feeling like it’s taking longer than it should to find the way forward. The vacillation between beaming pride when something works and crushing impostor syndrome when it doesn’t.

That emotional arc — the one every developer knows — is now shared by people who never expected to experience it. That’s not a problem. That’s wonderful.

Custom Beats Approximate

There’s a practical dimension here that I think is underappreciated. We live in a world of SaaS products that are, by nature, built for the widest possible market. Maybe they fit your use case, but they have dozens of features you don’t need. Or maybe they’re close to perfect, but this one critical part doesn’t quite map to how you actually work.

I think we’re about to see an explosion of custom software being built — vibe coded or otherwise — because the cost of building something specific has dropped dramatically. A tool that would have been too much work as a hobby project is now totally worth knocking out in an evening, because once it’s built and it fits your exact need, it’s a huge win.

Joe’s Torg GM tool is a perfect example. No product on the market does what he needs, because the market for “tools that help Joe run his specific tabletop campaign” is exactly one person. But now he can build it. And it’s better than anything he could have bought, because it was made for him.

People should be encouraged to make software that works for them. Software that fits a specific need and solves a real problem. That’s a good thing.

What I Don’t Want Us to Lose

There’s plenty of commentary right now about how vibe coding is dangerous without real engineers doing real architecture. I’m not going to pile on. I think that point is being made well enough by others. I obviously believe senior engineers still have enormous value to provide. But it’s not the thing I want to emphasize.

What I want to talk about is collaboration.

BDD was never just about getting better requirements. It was about the idea that collaboration makes us all better.That other people have strengths and perspectives that aren’t perfectly aligned with ours, and that means collectively we can build things none of us would build alone. The best software I’ve ever worked on was built by groups of people who saw problems differently, challenged each other’s assumptions, and stumbled into solutions that no single person would have designed.

If the future of software is all of us in isolation, building things by ourselves with an AI assistant, I think we’re going to make worse software. Not just because AI produces bugs, but because you don’t have a skilled QA engineer asking “have we thought about X?” You don’t have a designer pushing back on a flow that makes sense to an expert but confuses a novice. You don’t get the features that serendipitously appear when you’re talking through a hard problem and someone suggests a totally different way of looking at it.

The magic of BDD was never the tooling. It was getting people with different expertise into the same room, working on the same problem, with a shared language for describing what the software should do. Vibe coding gives more people access to software creation — and that’s genuinely exciting. I just don’t want us to trade collaboration for independence and call it progress.

The Best Version of This Future

The thing that always excited me about BDD was getting non-engineers interested in the craft of software. I loved that we could bring in people outside of our discipline and they could help us build exactly the right thing.

Vibe coding carries that same energy. More people creating software, more people experiencing the satisfaction, and the struggle, of making something real. More people who understand, from the inside, why building good software is hard and why it’s worth doing well.

The best version of this future isn’t one where everyone builds alone. It’s one where more people can participate, and we’re all still building together.