In early 2025, Andrej Karpathy put a name on a workflow a lot of us had already fallen into: vibe coding. Describe what you want to an LLM, accept what it writes, keep iterating until it does the thing. The code itself becomes the LLM's problem, not yours. You stay focused on the outcome.
For a certain kind of work, it's genuinely magic. Lovable, Cursor, Bolt, Claude Code - they'll produce a working app with a database, an auth flow, and a deployed URL in under an hour. If you're building a throwaway tool, validating a product idea, or scripting around a personal workflow, vibe coding is often the right answer.
This post isn't about why vibe coding is bad. It isn't.
It's about what happens when the thing you're vibe coding is meant to run your business for the next ten years.
Enterprise apps are 20% code and 80% everything else
The honest problem isn't "can an LLM write this code?". The answer is usually yes.
The problem is that when a business application moves from "it works on my machine" to "it's used by 500 people across six teams, and our auditors inspect it quarterly", the code itself is the easy bit.
The hard bits are the ones a clean "build me a claims app" prompt will never cover without very specific coaching:
- Who can see what. Not just "logged-in users only", but "the broker can see
policy_numberbut notpremium_amount, and only for claims assigned to their portfolio." - Who did what, when, and what it used to be. Every action logged with before-and-after values, request context, session ID, and the original user if someone was impersonating.
- Multi-tenancy. Strata managers don't see each other's buildings. Ever. Not in a search, not in a report, not through a URL bump.
- Parallel versions. Production users stay on v1 while your team tests v2 in preview, with a one-click promote. Your app doesn't mutate under someone mid-workflow.
- Integration. Your app lives inside an ecosystem - CRMs, identity providers, document generation, data warehouses. None of that's just a prompt.
- Handover. In two years, someone who wasn't in the original chat session needs to change this app. They'll read the structure, not the prompt history.
- Governance. Security reviews, procurement panels, DPAs, SLAs, Essential Eight alignment. You can't prompt your way into SOC 2.
You can have an LLM produce code for all of these. But you'll produce it inconsistently, specific to this one app, scattered across a hundred files, with no systemic guarantee that any of it fits together. That's the difference between code and an enterprise application.
What goes wrong when teams try to vibe-code enterprise anyway
Four failure modes we've seen enough times to name.
The permission rot
The first three roles are in the opening prompt. Six months later, someone needs "read-only but can export". The assistant happily adds it - in a different place from the others. A year in, nobody knows for certain what each role can actually do. Three years in, you discover during an audit that the analyst role can update the audit log itself.
The audit-shaped hole
"We'll add audit logging later" is the most-commonly-broken promise in enterprise software. Retrofitting an audit trail across a codebase that wasn't designed for one is, generously, a quarter of engineering work. It never happens. Then compliance asks.
The opaque codebase
Vibe-coded systems have a curious property: they're legible line-by-line but incoherent as a whole. You can't tell what the rules are, because the rules live nowhere in particular. The only person who can change the app safely is the LLM that wrote it - which means your app's maintainability is bounded by the context window of a six-month-old chat session.
The schema drift
You vibe-coded staging. You vibe-coded production. Somewhere along the way they stopped matching, and a field that's a proper enum in one is a nullable string in the other. This will cost you a weekend to discover and a quarter to recover from.
What xMS does differently
xMS has an AI assistant. When you describe the app you want, it builds it. The "vibe" part of vibe coding is still there.
What's different is what it's writing into.
Instead of scattering app code across a dozen files, the assistant is writing into a structured platform - resources, fields, roles, pages, permissions, workflows, triggers. The platform enforces consistency automatically.
- Permissions are a matrix, not a pile of if-statements. Define who can see and do what in one place; the UI, the API, and the database all honour it. Field-level. Row-level. No drift.
- Audit trails are free. Every write is logged with who/when/where, before-and-after values, request context. You didn't have to prompt for it.
- Multi-tenancy is a setting. Enable it and data isolation is enforced at the database layer, not in your application logic.
- Versioning is built in. Every change is tracked. v1 stays live for production while v2 runs in preview; promote when ready.
- Handover is possible. The app is defined in structured metadata, not prompts. Someone new to the project can read the permissions matrix, the resource list, and the page definitions - and understand the app.
The assistant isn't just writing code faster. It's writing into a platform that's already solved the things a vibe-coded build would otherwise spend years solving badly.
Where to use each
A simple decision rule:
- Vibe-code it if the app is temporary, throwaway, internal-only, has a handful of users, won't be audited, and doesn't hold data your business actually cares about. Most prototypes. Most personal tools. Plenty of weekend projects.
- Build it on xMS if more than a handful of people depend on it, it touches data that has consequences if it leaks or corrupts, it needs to survive a change of team, or it will ever be asked to comply with anything.
The two aren't opposed. Inside xMS, you're still working with an AI assistant. You still describe what you want in natural language. The difference is that what you're building isn't a pile of code with your requirements hoped-for - it's a system where the requirements are part of the platform from the first line.
Vibe coding, for when it fits. Everything else, on something that can carry the weight.