Vibe coding has enabled us to build software incredibly quickly, but it’s also raised the question of software quality to new heights. What does it mean for software to be high quality? Does it mean writing unit/integration/e2e tests for all possible code execution branches? Measuring code coverage? Having a comprehensive suite of test cases? And how do we even measure test comprehensiveness? Should we focus on happy paths or negative checks? Performance and stress testing? Accessibility? Running every possible test on each pull request? Security testing? Usability? The list goes on.
That’s a lot of testing types. But even if we write all of them, does that guarantee quality software? Practice shows the answer is no. There’s a meme that illustrates this perfectly:
A QA engineer walks into a bar and orders a beer. She orders 2 beers, 0 beers, -1 beers. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is. The bar explodes.
The beer ordering module was spotless—it could handle every possible way to order a beer. And yet the bar exploded.
Why did the bar explode?
The problem was that the engineers who built the bar hadn’t put themselves in their users’ shoes. They didn’t realize that people who order and drink beers in a bar typically need to use the bathroom after a couple of pints. They could have known this if they’d studied their target users more deeply. We can’t know every aspect of our users’ lives. But now we have LLMs—trained on essentially the entire internet. LLMs likely have a much better understanding of what our users need and want. So why not vibe code the users themselves?
Vibe coding users
The idea is simple: choose your target users and understand them inside and out. You could create a folder structure like this:
/users /group1 user.md /happy-paths requirement.flow.md
In this example, group1 represents a group of users who interact with our software. user.md contains the user profile—a description of who they are and what they do throughout their day, with our software being just one step in their life. happy-paths is a folder containing files that describe user flows through our software. These happy paths can be built the same way as agent skills—using natural language, pseudocode, or actual code, depending on how precise the flow needs to be.
... continue reading