Plasis

Insights

Vibe coding is real. So is the solution architect.

· 9 min read

AI that writes code from a description makes software faster and cheaper to produce, and that is a real change. But code was never the expensive part. Deciding what to build, how it holds together and whether it is safe still is, and three roles own exactly that.

Describe what you want in plain words, and an AI writes the code. Run it, look at what comes out, ask for changes, and repeat. Within an afternoon there is something on the screen that works.

The name for it came from the AI researcher Andrej Karpathy, in a post in February 2025: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He described accepting every change the AI proposed without reading it, and added a qualification that is often left out: “It’s not too bad for throwaway weekend projects.” By November, Collins had made vibe coding its Word of the Year 2025.

It is tempting to treat it either as the end of software engineering or as a toy. It is neither. Our philosophy is not to ride whatever trend is passing, but to study the real current state and the real benefit, and then design and build. Studied that way, vibe coding is a genuine change in how quickly software can be produced. It does not change what makes software succeed or fail. That is still decided by three roles that some people now think are optional: the product owner, the solution architect and the senior developer.

What vibe coding really is

Vibe coding means describing the result you want and accepting the code an AI produces, often without reading it closely. The person steering judges the outcome by whether it appears to work, not by how it is built.

For some work, that is exactly right. A prototype to test an idea with real users before committing to it. A small internal tool that saves a team an hour a week. A first version of a screen, to argue about something concrete rather than a description. An experiment that will be thrown away whatever happens. In all of these, speed matters more than durability, and the cost of being wrong is small. Something that used to take a week can now take a day, and that is a real gain.

The software author Martin Fowler draws the line in the same place in his entry on the subject: “On the whole vibe coding software is best used for disposable software that’s only used by its author or a close group of collaborators who understand and accept the risks involved.”

The tools themselves are now everywhere. In the Stack Overflow Developer Survey 2025, 84% of respondents said they were using or planning to use AI tools in their development process. Most of them, the same survey found, are not vibe coding: 72% said they were not.

We use AI in our own work for the same reason we use any tool: where it does real work. The question is not whether to use it, but where it stops being enough.

Where it breaks

It breaks at the moment a prototype becomes a product, and that moment often passes without anyone noticing.

Security is the first casualty. Code that appears to work can still accept input it should refuse, expose data it should protect or trust users it should check. None of that shows on the screen. Researchers from Carnegie Mellon University and others measured it directly in a study presented at ICML 2026, titled “Is Vibe Coding Safe?”. They gave AI coding agents 186 real feature requests from open-source projects. With one leading agent and model, “57% of the solutions … are functionally correct, only 11.8% are secure.” An earlier benchmark of AI-generated backends, BaxBench, found that the researchers “could successfully execute security exploits on around half of the correct programs generated by each LLM.” Working and safe are two different tests, and only the first is visible.

Developers know it. In the same Stack Overflow survey, more developers said they distrust the accuracy of AI tools (46%) than trust it (33%), and the most common frustration, named by 66%, was “AI solutions that are almost right, but not quite.” Almost right is the most expensive kind of wrong, because it passes a glance.

Data comes next. A prototype can lose or corrupt a record and nobody minds. A product that handles orders, payments or personal information cannot. Keeping data correct when many people use a system at once, when a step fails halfway or when two changes collide is design work, not something that emerges from a description.

Then come scale and time. Code that runs well for ten users can fail at a thousand. Code that nobody on the team understands cannot be safely changed, and every product has to change. Google’s DORA research program, in its 2025 report on AI-assisted software development, drawn from nearly 5,000 technology professionals, found that AI adoption now goes with higher delivery throughput, but that it “does continue to have a negative relationship with software delivery stability.” Its summary is worth keeping: “AI doesn’t fix a team; it amplifies what’s already there.”

Finally, integration and obligation. Real systems connect to other systems, follow regulations and keep promises to customers. None of that is visible from inside the prompt.

The product owner: what to build, and what not

The product owner decides what the product is for, which problems it solves first, and when something is good enough to release. They speak for the people who will use it and for the organization paying for it.

Forty years ago, Fred Brooks wrote in “No Silver Bullet”, a classic of software engineering: “The hardest single part of building a software system is deciding precisely what to build.” He argued that tools could remove the accidental difficulties of programming but not the essential one, which is knowing what the system must do. AI is a powerful new tool against the accidental difficulties. It leaves the essential one exactly where it was.

When producing software becomes faster, this role becomes more important, not less. A team that can build ten features a week instead of two can also build ten wrong features a week. The scarce resource is no longer the ability to produce; it is the judgment about what is worth producing. Every unnecessary feature still has to be tested, secured, maintained and explained, whoever wrote it.

The solution architect: how it holds together

The solution architect decides how the system is put together: where its boundaries are, how its data is organized, how it connects to the systems around it, how it is secured and what it will cost to run. These are the decisions that are expensive to change later, which is exactly why they need to be made deliberately at the start. Brooks again, in the same essay: “No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

An AI can write a component quickly. It does not know, unless someone tells it, how that component should fit with the forty others, what the organization already owns, what the regulator requires or what will happen when usage grows. The architect holds that picture. Without it, a system is a collection of parts that each work and do not work together. DORA’s finding cuts both ways: on a sound design, AI amplifies the soundness.

The senior developer: judging what the machine wrote

The senior developer is the person who can read generated code and tell when it is subtly wrong: when it handles the common case and fails on the rare one, when it solves the problem in a way that will hurt later, when it looks correct and is not. They decide which parts must be written and checked with particular care, and they make sure there are tests that would catch the mistakes nobody saw.

Judgment matters because our sense of our own speed is unreliable. In a randomized trial by METR, a research nonprofit, experienced open-source developers working on projects they knew well with early-2025 AI tools took 19% longer than without them, while believing afterward that AI had sped them up by 20%. METR’s 2026 follow-up with newer tools estimated a speed-up instead, and called its own data “only very weak evidence” for the size of it. The tools are improving quickly. The gap between how fast work feels and how fast it is remains the reason someone has to measure.

They also teach. Less experienced developers working with AI produce more code than ever, and they need someone who can show them why one version is sound and another is not. A randomized study published in January 2026 by Anthropic, the company that makes the Claude models, found that junior engineers who learned a new library with AI assistance scored 50% on a follow-up quiz, against 67% for those who coded by hand. The authors noted that how people used the AI mattered: those who asked it conceptual questions learned more. Without someone guiding that use, a team’s speed grows while its understanding shrinks.

How we work

We use AI throughout the build where it does real work: drafting code, exploring options, writing tests, speeding up the routine parts. The product owner keeps it aimed at the right problem, the architect keeps it inside a design that will hold, and the senior developer checks what it produces before it reaches anyone who depends on it. The result is faster than building without AI, and as sound as building with care. It is handed over with documentation that matches what was built, so its owners can run it.

Questions to ask whoever builds your software

Who decides what goes into the product, and who decides what stays out?

Who is responsible for how the system fits together, and can they explain it to you on one page?

Who reads the code before it goes live, and what are they looking for?

How is your data protected, and how would you know if it were not?

If the people who built it left tomorrow, could someone else take it over?

The tools change who types the code. They do not change who is accountable for what it does.

Sources

The service behind this piece

SaaS and systems development

SaaS products, and the systems an organization runs on where an off-the-shelf tool does not fit: specified with the people who will use them, built in short cycles, and handed over with documentation that matches what was built.

Building something?

Tell us what you have in mind. A short description is enough; we will ask the rest.

Start a project