What Is Vibe Coding—and Where Does Structure Still Matter?

Vibe coding is a way of building software by telling an AI system what you want, looking at what it produces, and steering from there through conversation. The term, popularised by Andrej Karpathy in early 2025, captured something real: the distance between an intent and a working screen has collapsed. For exploration, that is a genuine breakthrough.

But the question we keep returning to as we build Blazorly is not whether vibe coding works. It is what happens after the demo. An operational product still has records, permissions, state transitions, external effects, users, errors, releases, and responsibilities. Conversation is a powerful starting interface. It is not, by itself, an operating model.

What is vibe coding, exactly?

Vibe coding is an iterative loop in which natural language is the primary interface: you describe an outcome, the AI proposes an implementation, you run it, react to what you see, and describe the next adjustment. The craft moves from writing syntax to directing and evaluating results.

• Describe what you want in plain language.
• The AI proposes code or an application.
• You run it, look at the result, and react.
• You refine with follow-up instructions and repeat until it feels right.

That last step is doing more work than it looks. "It feels right" is the acceptance criterion — that is the vibe. The reason the technique spreads is that the cost of a first version drops so far that people who could never justify writing software can see their idea running, and people who could write it can explore more options in an afternoon than they used to in a week.

Where does vibe coding work well?

Honestly: in a lot of places. The technique is strongest wherever the cost of being wrong is low.

• Throwaway prototypes and spikes that test whether an idea is worth pursuing.
• Personal, single-user utilities where you are the developer, reviewer, and maintainer at once.
• Interface exploration, where comparing three layouts beats committing to one.
• Learning, because a conversation can walk you through unfamiliar frameworks.
• Small internal helpers whose failure would be annoying but not damaging.

Notice the common thread. Each of these situations has one user or a forgiving audience, reversible changes, and no external effects. The moment those conditions change, the technique on its own stops being enough.

Where does vibe coding start to break?

Consider a small services business that vibes its way into a job-tracking app. On Monday, the founder asks for a list of jobs with customer names and statuses. Over two weeks of follow-up prompts the app grows: quotes, a status called Awaiting Parts, a dashboard of overdue jobs, and a workaround where somebody re-labels records because adding a field felt like too much to ask.

None of the individual steps were unreasonable. Together they produce the failure modes we keep seeing in software that grows purely by conversation:

These are not AI failures. The model did what it was asked, prompt by prompt. They are system failures: the work of pinning down the model, the rules, and the permissions never happened because the interface made it easy to skip. If you have lived through a rewrite caused by this, you will recognise the pattern.

Why does structure make intent repeatable?

Structure is not the opposite of conversation. It is what conversation should produce when the result has to survive daily operations. For an operational application, structure means schemas, relationships, validation, views, actions, navigation, and versioned publication. Users can start in conversation, but the resulting model must be inspectable and usable through a predictable interface.

That is the role of Blazorly Builder and its Project Studio. The AI translates requests into an explicit application configuration — schemas, forms, lists, detail views, rules, actions, navigation, themes, and dashboards — which is published to a shared runtime. Builder is deliberately not a source-code generator: the durable artefact is the inspectable configuration with a version history. Focused changes flow through conversation; larger changes first become a plan you can review, and every candidate version can be previewed against the runtime before it goes live.

Once an application is published, it is worked in two ways. The SaaS Client provides the screen-based workspace — dashboards, lists, forms, detail views, related records — for structured daily work. The Conversational Client provides a conversational route into the same published app, with structured record cards and approval before supported data-changing actions. Conversation is the front door. Structure is the house. The record-first thinking in our guide to designing a CRM workflow without code shows what that design work looks like in practice.

What does a controlled vibe-coding workflow look like?

Take a client-onboarding application. The conversation starts with intent: "We need to track new clients from first inquiry through onboarding." A structured builder does not just emit a form. It proposes a plan — Client and Onboarding records, ownership, statuses with entry rules, a follow-up list, and a dashboard of at-risk onboardings — and the plan is reviewed before any configuration is applied.

Two weeks later, the operations lead asks, conversationally, for an approval step before a client is marked live. Because that change touches statuses and permissions, it arrives as a plan with a visible diff against the current version. The team previews it, publishes a new version, and keeps the previous one for rollback. The conversation stayed natural; the change stayed governed. If you are weighing this model against owning a codebase, our breakdown of AI app builders versus traditional development covers the trade-offs.

The questions we use to decide how much structure a change needs:

• Does it touch the schema, or rename anything that already exists?
• Does it change who can see or edit data?
• Does it have effects outside the application — emails, payments, agent actions?
• Would rolling it back be painful?
• Do more than one person or team rely on the behaviour?

If every answer is no, plain conversation is probably fine — enjoy the vibe. If any answer is yes, the change deserves a plan, a reviewable configuration, and a version you can return to.

Do agents make the problem harder?

Yes, because an agent's mistakes are executed rather than merely typed. A tool-using agent can search the web, work with files in a workspace, call APIs, use connected applications, schedule tasks, and delegate sub-tasks. Each capability changes the risk profile, and "it felt right in the chat" is not an adequate control for any of them.

A useful agent platform therefore separates outcome, instructions, tools, knowledge, connections, tests, release, and activity. Blazorly Agent is organised around those lifecycle surfaces: outcome-driven creation, tools with isolated workspaces, knowledge and memory, connected applications with explicit grants, testing and evaluation before release, and versioned deployment with observation afterwards.

Before an agent is released, we think an operator should be able to answer:

• Can you state the agent's outcome in one sentence?
• Does every tool have a reason to exist, and every connection a narrow grant?
• Has it been tested against realistic inputs, including ones that should fail?
• Do you know exactly what it may change without asking?
• Can you see what it did afterwards, in one place?

Does a group of agents need a crew, or just more prompts?

Several agents do not automatically become a team. More prompts produce more activity, not coordination. A crew needs product context, distinct responsibilities, shared reviewed knowledge, ownership of work, handoff rules, founder decisions, and a way to report outcomes.

Blazorly Crew is that control plane around Agent-powered Mates: a crew per product, shared reviewed knowledge, a team room alongside direct chats, work items with handoffs and founder approvals, and connected applications with narrow grants where the Agent retains the credentials. The division of labour is deliberate: Crew coordinates, Agent executes.

When is vibe coding enough?

The honest answer depends on what the software has to survive. The same judgment applies when you compare AI app builders: the right choice follows the operating model, not the speed of the first demo.

The durable lesson

Conversation is the easiest way to express what should happen. Structure is what makes the result inspectable, repeatable, and governable. The teams that get durable value from AI will not be the ones that chose vibes or structure — they will be the ones that used conversation to move fast and structure to keep what they built.

That is the product we are building at Blazorly: Builder for the conversation that produces a governed application, two clients for working it daily, Agent for execution, and Crew for coordination. Blazorly is in private invitation beta. If this matches how you think about AI-built software, you can request access and tell us what you would build first.