Enterprise Vibe Coding Is Coming. The Trick Is Deciding What the Vibes Are Allowed to Touch.

“Vibe coding” entered the vocabulary as a half-joke: prompt-in, code-out, run it, describe what’s wrong, repeat. Don’t waste your time in code review. It works or it doesn’t.

The enterprise reaction was immediate — a mixture of horror and dismissal. And the horror isn’t wrong. Vibe-coded software, as practiced in the wild: hand-rolled authentication that doesn’t protect the API, secrets in source, 1990s level SQL injection opportunities, no audit trail, no access model, most scarily, everyone’s local environment has terraform scripts with full-access given to the model. Every CISO who banned it had good reasons.

But dismissal is the wrong conclusion, because the productivity signal underneath the joke is real. People with no development background are producing working software in an afternoon. Product managers are themselves shipping features. The gap between “I can describe it” and “it exists” has collapsed from months to minutes — for exactly the class of small, specific software that fills every enterprise’s unbuildable backlog.

So the interesting question was never “should enterprises allow vibe coding?” It’s an engineering question: where, precisely, does the risk live in vibe-coded software — and can it be fenced?

The risk is not evenly distributed

Look at what goes wrong when generated code fails in production, and a pattern jumps out: the failures cluster. Nobody has ever been breached through a poorly considered button color. No audit finding has ever cited an unfashionable layout. The UI layer — the part vibe coders most enjoy iterating on — is close to risk-free.

The damage concentrates in a specific and enumerable set of concerns:

• Authentication and authorization — who is this user, what may they see, what may they do
• Persistence — where data lives, how it’s modeled, whether writes are safe and recoverable
• Type and contract discipline — whether the data crossing boundaries means what both sides think it means
• Rate limiting and quota — whether one runaway loop can take down a shared service
• Scaling and sharding — whether the thing survives contact with real load and real data volume
• Audit and telemetry — whether anyone can reconstruct what happened

Call these the enterprise concerns. They share three properties: they’re where all the danger is, they’re nearly identical across every application in the organization, and — critically — they’re the part language models are worst at generating correctly, because correctness here isn’t local. You can’t verify an auth model by looking at one file. It has to agree with the organization’s identity provider, its access policies, its data classification rules. A model confabulating a plausible-looking JWT validation function is the security equivalent of a hallucinated citation: fluent, confident, wrong in ways that don’t show until it matters.

Meanwhile the concerns outside that list — screens, forms, workflow states, report layouts — are local, visually verifiable, and low-consequence. If the generated form is wrong, you can see it’s wrong. The feedback loop that makes vibe coding work — look at it, describe the problem, regenerate — actually functions there.

The risk profile of vibe coding isn’t a cloud. It’s a map. And anything with a map can be fenced.

The fence is an SDK

The architecture that follows from this observation is the one we built into LACE’s App Builder, and it has two components: a sandbox and an SDK.

The sandbox is where the agent works. Generated code executes in an isolated environment with no direct access to databases, networks, credentials, or the host. This is table stakes — containment for code you didn’t review.

The SDK is the interesting part. It’s the only surface through which sandboxed code can reach anything real, and it’s designed on a simple principle: every enterprise concern exists exclusively as a governed capability, never as something the generated code implements.

The generated app doesn’t authenticate users — it asks the SDK who the current user is, and the platform’s identity layer answers. It doesn’t write SQL — it declares the data it needs against typed contracts, and the platform’s persistence layer handles storage, sharding, migration, and backup. It doesn’t implement permissions — every data access flows through the platform’s policy engine, which enforces the same document-level and field-level controls as everything else in the environment. Rate limits, quotas, retry semantics, telemetry: all ambient, all inherited, all invisible to the app code.

The load-bearing property is what the SDK omits. There is no API for opening a raw database connection, because that API doesn’t exist in the sandbox. The agent cannot hand-roll auth — not because a linter catches it, not because a code review rejects it, but because the capability isn’t there to misuse. This is the same structural-enforcement insight that applies everywhere agents operate: you don’t get reliability by instructing an agent to behave. You get it by constructing a world where the wrong behavior is unrepresentable.

Prompt-level guardrails are suggestions. SDK Capability boundaries are physics.

What’s left is the good part

Subtract the enterprise concerns, and what remains for the vibe coder — human, agent, or the usual pair of them — is precisely the layer where vibing works: the interface, the workflow, the experience.

This is not a consolation prize. It’s most of what makes an internal tool fit a team. Two inspection-intake apps can share identical auth, storage, and audit machinery and still succeed or fail entirely on whether the workflow matches how the team actually operates — which fields, which states, which view the supervisor sees Monday morning. That knowledge lives with the team, not with IT, and conversational iteration is genuinely the best interface anyone has built for extracting it.

So the team members splash around. Describes the tool, looks at it, changes it, ships it — in an afternoon, with the blast radius limited to wonky UI. Underneath, the app is indistinguishable from custom-built enterprise software, because the enterprise parts weren’t generated. They were inherited.

And because agents in LACE are governed components too, “the vibe coder” is increasingly an agent in Agent Studio working the same loop — building, checking its work against the rendered UI, iterating — inside the same fences, under the same audit.

The inversion

Here’s the framing shift worth taking away. The instinct is to treat generated code as a quality problem: review it harder, test it more, trust it less. That instinct doesn’t scale, and it gives up the entire productivity gain.

The alternative is to treat it as a jurisdiction problem: decide which concerns generated code is allowed to have, make everything else a platform capability, and enforce the boundary structurally. Then the question “can we trust vibe-coded software?” dissolves, because the parts that required trust were never vibe-coded.

Enterprise software was always majorly a plumbing problem. The revolution isn’t that AI writes the plumbing. It’s that nobody writes the plumbing anymore — and the 20% that’s left is finally cheap enough to get right.

Let them vibe.