by Guillermo Quiros
Here is something I keep coming back to: we are often treating LLMs like a genie in a lamp. Type a wish, get a result, and hope it is the one you wanted.
For the first three or four wishes, it often works. The output looks polished. The prototype behaves. You start to believe.
Then you ask for the fifth feature, and the LLM uses a different ORM than the one it set up two prompts ago. The sixth feature reinvents authentication. By the tenth, your codebase looks like five different developers wrote it, none of whom spoke to each other.
Each prompt may have been answered correctly. The system, as an emergent thing, has quietly fallen apart.
The instinct is to blame the model. Better model, better output. Wait for the next release and the problem goes away.
I do not think that is true.
The Problem Is Not the Model. It Is the Missing Architecture
If you have worked in software long enough, you know that good software does not appear just because someone started coding. It usually starts in front of a whiteboard, with a set of boxes and lines that define the architecture.
That is where we decide:
- what the system is
- what the UI needs to do
- whether mobile matters
- what the backend stack should be
- how the system scales
- how secure it needs to be
- what it costs to run
These are not implementation details. They are the shape of the product.
Once that shape exists, we are on our way to building good software. Without it, we are mostly just typing.
Now compare that with how many people prompt an LLM:
Build me a checkout flow with Stripe.
That is not a brief. That is a wish.
We would never hand that sentence to a developer and expect a coherent result. Yet we hand it to Claude or Codex and then act surprised when the output does not match the rest of our codebase.
What makes software engineering a discipline is not code alone. It is architecture plus code.
Code by itself gives you a pile of functions that happen to compile. Architecture is what turns those functions into a system. And the same brief that empowers a senior engineer, with boundaries, contracts, dependencies, and intent, is the brief that empowers an LLM too.
What This Looks Like in Practice
Suppose you want to add a refund endpoint to your order service.
The genie-in-the-lamp version looks like this:
Add a refund endpoint to the order service.
The LLM will produce something. It may even work. But it will probably call Stripe directly, write to the database from the controller, and emit no events, because nothing in the prompt told it not to.
Three weeks later, when you ask it to add partial refunds, it may solve that problem in a completely different way again.
The architecture-grounded version looks like this:
Add a refund endpoint to the OrderController component of the Order API container.
It calls RefundUseCase, which orchestrates PaymentPort.refund and
OrderRepository.markRefunded inside a transaction, then emits an OrderRefunded
event via EventPublisher. The use case must not import Stripe directly.
Refunds are idempotent on the payment ID.
The first prompt is a wish. The second is a specification.
In the second version, the model is no longer guessing at:
- the topology of the system
- the boundaries of the change
- the contracts it must respect
- the policies that govern the implementation
The output becomes more consistent not because the model got smarter, but because the input became less ambiguous.
The 80/20 of Real Software
Something that does not get said enough is that most software is boilerplate. Maybe 80 percent of it. Maybe more.
Only a small portion of the system usually carries the product's real advantage.
Take Uxxu as an example. Login, signup, project pages, sidebars, and settings are all important, but they are not where the product becomes distinctive. A good developer or a good LLM can build that kind of surface area quickly.
The part that matters most is the viewport:
- how we draw on canvas
- how we render in SVG and HTML
- how it scales
- how it feels to use
That is the 20 percent that defines the product, and that is exactly the part that needs the clearest documentation, the strongest intent, and the best architecture.
Otherwise, you end up with a polished login screen wrapped around the one thing that makes the product valuable, held together mostly by accident.
This is where vibe coding tends to break down. Boilerplate is easy. The differentiated part is hard. And the hard part is where the LLM needs the most context, the strongest constraints, and the clearest contracts.
Is Architecture-First Slower?
There is an obvious counterargument here: architecture-first sounds slower, and the whole point of vibe coding is to skip ceremony and ship faster.
For a weekend prototype, that is fair. Vibe code away.
The argument I am making starts when the prototype begins to matter:
- other people are using it
- the code will live for months
- the team has to extend it safely
At that point, architecture stops being ceremony and starts being leverage.
Spend ten minutes drawing boundaries and you can save ten hours cleaning up inconsistent code later.
The architecture does not need to be exhaustive either. You do not need to model the world. You need to model the boundaries:
- what talks to what
- who owns the data
- where the contracts are
Sometimes five boxes and the lines between them are enough.
The point is not the diagram itself. The point is that the model now has somewhere to ground its work.
Treat Agents Like Developers
If we treat agents like developers, and keep the discipline we have built up over decades, architecture, patterns, best practices, code standards, maintainability, and security, then we start to get the best out of them.
The model does not get smarter. The brief does.
This is also one of the clearest ways to differentiate a product. If everyone is vibe coding with the same vague prompts against the same models, they tend to produce the same sort of vanilla software with the same strengths and the same flaws.
Architecture is where your input lives. Architecture is where your product becomes specifically yours.
Done well, vibe coding looks less like tossing prompts into a void and more like managing a team. Your job is not to write every line yourself. Your job is to define the system clearly enough that the people working for you, human or otherwise, can write code that fits.
That is the shift.
Not better prompts. Better architecture.
A Note on What We Are Building
This is the problem we are working on at Uxxu. The idea is simple: before you vibe code, think. Create the architecture first.
You can invite your agents to collaborate with you on the diagram through our MCP. The agent reads the architecture, understands it, and reasons at the right level of abstraction. You can also work in the diagram directly and let the changes flow back into the LLM's context.
This is not just diagram-to-code. It is bidirectional. The code reflects the diagram, and the diagram reflects the code.
The architecture stays alive as the system grows, and you can manage your agents at a deeper level, not by reviewing every diff, but by reviewing whether they respected the boundaries you set.
If this resonates, start with the codeToC4 beta page, then read how to teach your LLM to write C4 diagrams for the practical workflow.
Vibe with architecture.