Vibe Coding is Prototyping For The Masses

Goodbye Domain-Driven Development, Hello Domain-Embodied Development

Vibe coding—prompting AI to generate code snippets—is getting increasing attention, not just among developers but also among people with little or no prior coding experience. Previously, building a solution required an engineer or possibly even a team. Now, it might only take someone with a problem and the willingness to prompt AI, with threats or prizes, into producing something useful.

As vibe coding spreads, it has taken over the developer memesphere. There are fundamentally two sides: one that claims it’s the worst thing ever and will lead to poorly written code and insecure services, and another that sees it as a valuable addition to the developer’s toolkit. These sides are almost completely opposite, so it’s no wonder people are struggling to make up their minds about it.

Understandably, people calling it the worst thing ever are basing it on the fact that most of the code that LLMs write is “intelligent” only in the sense that most of the code you can crawl through and use to train your models is not intelligent. There are patterns that are generally efficient, clean, and well-written, such as bubble sort. Asking for those from an LLM will produce good results as there’s enough material. Going beyond that will most definitely produce unwanted results. Anything beyond the general stuff doesn’t model well into statistical inference.

The other side of the conversation sees vibe coding as a tool where you prompt your way through menial tasks to produce results. Without demonizing any junior developers, commanding an LLM is akin to delegating tasks to a junior developer so you can focus on the big picture. The major difference is that junior developers usually don’t start hallucinating cross-framework solutions when they run out of skill; in some cases, they might even ask for help.

I personally fall into the latter camp, as I’ve found LLMs particularly good for things that require manual work. Recently, for example, I migrated an older React Native project that used styled-components for styling back to using StyleSheet (after a year of being a proponent of styled-components, I’ve changed my mind and consider them a misstep in styling evolution). Without vibe coding, I most likely would not have even revisited that project, seeing as that kind of change is essentially just reducing technical debt and therefore not something I would like to spend my spare time doing.

However, that is about using LLMs to improve existing projects, and people calling vibe coding a blasphemy are mostly referring to the cases where completely new projects are created using LLMs. I’ve done a few experiments in this space. LLMs certainly do tend to start pulling some very bad code when their context space no longer contains the original prompt you started working on. It’s not really that difficult to get Cursor to start writing React code in a React Native project, with divs and all, once it forgets you’re building a mobile app. Then again, that is something you, as a developer, can easily fix by making sure you’re adding the missing context when needed. You can also most likely fix most security problems by keeping that in mind.

Where I see the most potential for vibe coding is when it starts to get adopted by the masses; used by people who don’t work in technology and who have potentially never coded. Using vibe coding not to build the next SaaS startup but to solve their own problems in domains they’re experts in.

Domain being the keyword here. In traditional software development, the push for the last few decades has been for something called domain-driven development, a paradigm where domain experts are included in the development process in order to build products that actually solve a real problem. When I used to compete in hackathons, semi-professionally, it took about 10 hackathons, both won and lost, to figure out that including experts from another domain beyond coding was the key to consistently winning. Deviating from this model was always statistically less successful. Of the 70 hackathons I competed in, 40 were won using this approach.

Limits of User-Centered and Domain-Driven Design

Similarly, when I was studying design, involving domain experts in the design process was the paradigm we were hammered to follow. In design, a similar concept is called user-centered design, or even co-creation if users are actively doing some parts of the design. However, most user-centered design tends to be more user-inspired and centered around them. Similarly, domain-driven development is mostly inspired by domain experts; they are not the driving force behind it at all times. Arguing against this statement would require explaining how so many developers hate talking to users.

Perhaps we’ve reached the optimum state for domain-driven development and user-centered design. Already during my studies, quite a lot of discussion focused on how products created through user-centered design were often examples of incremental innovation, whereas radical innovation—meaning scale-changing innovation like the internet—was consistently produced by not involving users in the process at all. I’ve written about this before if you’re interested.

Domain-Embodied Development

If we reframe innovation as the serendipitous result of introducing a new pair of eyes into how we build the world, then it becomes clear that in the age of the internet, it is not the ones who built it this far, coders and designers, who will build the new businesses. It is the ones who’ve spent years studying and working in skill- and knowledge-based domains, such as teaching, healthcare, and manufacturing, that we should look to for building new businesses and innovations. The domain experts themselves will start building the software. Development would no longer be driven by the domain; it would be embodied by it.

I’ve had the luck to witness a win by this new domain-embodied development even before LLMs took over. In 2021, a friend of mine asked me to work on building the design system for a startup of theirs that had just been bought by Kahoot. This was just six months after they had founded the company. The product they worked on was very simple: an online whiteboard for teachers, something that COVID-19 suddenly made very crucial. Technology-wise, it was relatively simple to build, but apparently no one had cracked it in the same way before. The difference was that the founder who built this product was a teacher themselves; they knew from the start what features were crucial and could focus on building those. Without their vast domain knowledge of users and the market, this product most likely would not have made it, even though the market change caused by the pandemic helped.

When it comes to what tools will drive domain-embodied development, it’s hard to say, as they are still mostly developer-oriented. While tools such as Cursor enable developers to be increasingly efficient in building software in ways that feel close to magic, their fundamental context is still the IDE, something only developers really find inviting. Bolt.new and Lovable move away from the traditional development context, but they still end up spitting out code. Code that someone has to analyze, fix, improve, and maintain; all things which AIs handle rather shakily. Tools not being all there yet is, therefore, more a limitation of the performance of our current LLM models.

It is at that limitation where I personally think the current state of vibe coding is: in apps and websites that simulate the functionality and design of a final product, more commonly known as prototypes. Prototypes don’t need to be maintained; they don’t even need to be complete, or fully real, in order to validate ideas. Vibe coding, when done by developers, has, of course, the chance to cross the chasm from prototype to a real product, but for non-developers, that part is missing.

Despite being an AI skeptic, I predict that as models and the tools using them improve, we will start to see domain-embodied development become a crucial paradigm for building software, preferably by non-developers. Similarly, it will become easier to cross the prototype-to-product chasm without ever having to touch code.