Vibe Engineering vs. Enterprise Engineering: Where Natural-Language Development Fits in Regulated Delivery

By 2028, 40 percent of new enterprise production software will be created with vibe coding techniques and tools, according to Gartner. That’s a striking number for a term that didn’t exist before Andrej Karpathy coined it in February 2025 to describe a fully prompt-driven, exploratory way of building software with almost no attention paid to how the resulting code actually works. Gartner’s own research defines vibe coding as a methodology where developers focus on intent and outcomes rather than implementation details, staying in a state of flow while AI agents generate, modify, and repair code on their own. And in the same research, Gartner is explicit: today’s vibe-coded software is not yet production-ready, and needs to be piloted thoughtfully, governed carefully, and constrained by guardrails.

Those two facts sitting next to each other, rapid enterprise adoption and an explicit not-ready-for-production warning, are the actual subject of this piece. The question for a regulated enterprise was never whether natural-language, AI-driven development is useful. It’s where the line sits between the fast, exploratory version of it and the accountable, production-grade version, and what has to be true for AI-assisted development to belong on the production side of that line.

The terminology here is genuinely still being worked out, which is worth naming directly rather than glossing over. In October 2025, independent software engineer Simon Willison proposed the term “vibe engineering” to describe the other end of the spectrum from vibe coding: seasoned professionals who accelerate their work with LLMs while staying accountable for the software they produce, as opposed to the fast, loose, entirely prompt-driven approach with no attention paid to how the code works. By February 2026, Willison had updated his own post to note that the term “agentic engineering” appeared to be winning out as the industry’s preferred label for the same idea. The label is still moving. The distinction it’s pointing at is not.

That distinction is the one that actually matters for regulated delivery: not whether development is driven by natural language, but whether accountability, verification, and governance are built into the process or skipped entirely in favor of speed. A prompt that generates working code is not the same thing as a specification a qualified engineer has reviewed and taken responsibility for, even when the two produce identical output.

Gartner’s own caution here is direct, not hedged: vibe-coded software isn’t production-ready without governance and guardrails around it. That’s consistent with a pattern that’s shown up throughout this series in a different context. Legacy modernization efforts that succeed reverse-engineer a system’s actual logic before rebuilding it, rather than translating code blindly. Agentic organizations that scale successfully embed governance into the workflow itself, critic agents, guardrail agents, compliance agents, rather than bolting a review step on afterward. The same principle applies here: the risk in regulated delivery was never that AI-generated code looks wrong. It’s that nobody can explain, after the fact, why a specific decision got made, which is exactly the accountability a regulator or auditor will ask for.

That’s a harder requirement than “the code runs without errors.” A financial services system or a healthcare workflow needs a defensible record of intent, review, and validation behind every change that touches production data or a regulated process, the same audit trail requirement that shows up whenever this series has discussed legacy systems in regulated industries. Vibe coding, in Gartner’s own definition, is built to skip exactly that layer in favor of staying in flow.

None of this makes natural-language, AI-driven development something enterprises should avoid. It means the decision isn’t binary. Karpathy’s original framing of vibe coding was explicitly for throwaway, low-stakes projects, not systems of record, and that distinction still holds as a reasonable starting point for where it fits inside an enterprise SDLC.

Fast, exploratory, natural-language-driven development is well suited to internal prototyping, early-stage exploration, throwaway scripts, and non-production tooling, work with a small blast radius where a mistake is cheap to catch and reverse. Production systems, anything touching customer data, regulated processes, or systems of record, need the fuller discipline this series has described elsewhere: authenticated access instead of mocked integrations, real error handling instead of a clean-data assumption, and validated output instead of code that merely compiles. The line isn’t about which tool generated the first draft. It’s about what happens to that draft before it reaches a system the business actually depends on.

Three things separate accountable, production-grade AI-assisted development from the fast version Gartner is warning enterprises about.

Verification discipline has to be explicit and trained, not assumed, treating AI-generated code the way a careful engineer treats any other contributor’s pull request rather than accepting it because it ran successfully once. Specification quality matters more, not less, in natural-language-driven development, since the prompt or intent statement effectively becomes the specification; a loose one compounds risk at production scale in a way a loose comment in traditionally written code never did. And governance has to be built into the workflow itself, the same critic-agent, guardrail-agent, compliance-agent model described elsewhere in this series, so the accountability an auditor needs is a structural feature of how the software got built, not a step someone has to remember to do.

A short set of questions does most of the work of deciding where a given piece of AI-assisted development actually belongs. Does it touch production data or a system of record, or is it a throwaway or internal tool with a small blast radius? Is there a regulatory or compliance exposure that will eventually require an audit trail? Is a qualified human verifying the output with real review rigor, or is “it ran without errors” the actual bar being applied? And is governance built into the workflow as agents and checkpoints, or does accountability depend on someone remembering to review it later?

Work that scores low-stakes, easily reversible, and genuinely reviewed can move fast using natural-language-driven development without much friction. Work that touches regulated data, production systems, or compliance-sensitive logic needs the fuller model this series has described throughout: AI-augmented, but governed, verified, and accountable by design.