We All Look the Same: The Side Effects of Vibe Coding
Vibe coding promises that anyone can turn an idea into software. In practice, it is also producing an endless stream of nearly identical products.
The same interfaces. The same architecture. The same terminology. The same shallow abstractions wrapped around the same APIs.
This is not surprising. LLMs are statistical systems trained to generate probable solutions. Give them similar ideas and similar prompts, and they will naturally converge on similar implementations. Vibe coding accelerates production, but it also accelerates sameness.
The distance from the domain
The deeper problem is not the generated code. It is the distance it creates between developers and their domains.
Building software in a complex domain is like building a car: thousands of decisions are hidden under the hood. In Mozaik, agent loops move through multiple states and transitions. Visitors observe them. Events connect participants. Situations determine how agents react. Interceptions alter execution. Shared state coordinates concurrency. Models, context structures, specifications, and memory add further dimensions.
These details are the product
These details are not implementation noise. They are the product.
Use vibe coding without reading the code, and you do not get a solution. You get a simulation of one.
Try to vibe-code a complex game with a ton of detail. You will not get the game. You will get a mimic of it — something that looks like the idea from a distance, but has none of the systems that would make those details real.
When developers stop engaging with them, they stop discovering. They accept the abstractions, terminology, and boundaries suggested by the model. The application may function, but it rarely contains a genuinely original way of understanding the problem.
The best ideas do not appear at the level of prompts and feature lists. They emerge while studying edge cases, questioning existing abstractions, resolving contradictions, and developing a precise language for the domain.
That requires reading the code
That requires reading the code.
AI is extremely valuable for research, learning, navigating unfamiliar systems, sketching implementations, and developing supporting domains. But outsourcing the core domain from beginning to end is not acceleration. It is surrendering the main source of differentiation.
Vibe coding is appropriate for simple domains and valuable as an entry point into engineering. But in complex domains, it creates a dangerous illusion: the feeling of rapid progress without the understanding required to build anything defensible.
Anyone can now ship an application.
Very few are developing a new model of the domain, creating original concepts, or building technology that competitors cannot reproduce with the same prompts.
Vibe coding makes software easier to create. It does not make the result different.
To build something original, developers still need to go under the hood.
With tools and technology we already have, we can build much more valuable systems than most projects today. We can write software that is a pleasure to use and a pleasure to work on; software that doesn't box us in as it grows, but creates new opportunities and continues to add value for its owners.
