What enterprise actually demands — and why most AI-assisted builders are about to hit it hard

Tags: Vibe Coding, AI Development, Enterprise Software, Production Engineering, Software Architecture, GenAI, AI Tools, Software Quality, IAM, Security, Observability, Audit Trail, Technical Debt, Product Delivery

There are a lot of posts making the rounds about vibe coding.

The popular among engineers opinion: vibe coding can publish software faster than its builders can determine whether anyone should depend on it. The demos are real. The production assurance is not.

• Reddit, blogs, and dev discussions repeatedly highlight the exact gap: “Vibe coding feels amazing until an experienced developer reviews your code.” It excels at prototypes/MVPs but produces opaque architecture, performance issues, bad patterns, and hidden bugs that only surface under real load or scrutiny [reddit.com].
• Professionals view it as great for spikes, throwaway projects, or acceleration in areas you already understand, but risky as a full replacement for disciplined engineering. It multiplies existing knowledge more than it substitutes for it [flatlogic.com].
• Common warnings: technical debt piles up, debugging becomes hard (“the code is the only source of truth”), security holes slip through, and non-experts can’t easily evaluate what they’ve built [developers.redhat.com]
• Recent debates (even trending on X) note that while some big players use AI heavily for parts of code, pure vibe-coded apps often flop in production or require heavy cleanup. No flood of major, valuable projects has emerged solely from unskilled vibe coding [x.com].

I want to add one thing to it, because the diagnosis matters for what comes next.

I am one of the people who knows how to build production systems with or without AI coding tools. It is not because I am especially clever with prompts. It is because I spent some years building software before the modern AI coding tools existed, and that history sits in my hands in a way that is invisible until you need it.

The semantic trick inside “prompt to product”

This is not a straw man invented by sceptical engineers. AI app builders explicitly market the collapse of software development into a prompt:

The promises vary, but the semantic move is the same. A runnable artifact becomes a working app; a working app becomes a product; one-click deployment becomes production. The visible distance from prompt to software has genuinely collapsed. The invisible distance from software to accountable system has not.

Lovable’s own documentation restores that boundary. Its security tools do not replace a thorough security review; the builder remains responsible for deciding what security the use case requires; the deeper scan does not run automatically; and publishing with unresolved critical findings remains possible. Marketing removes the engineer from the build. Documentation quietly brings the engineer back for accountability.

That is the problem with “prompt to product.” It works only when product means a runnable artifact. It stops at the boundary where organizational accountability begins.

What the demo does not show

A good demo needs one thing: it needs to work once, in the right conditions, in front of the right person.

A production system needs to do something harder. It needs to work ten thousand times. It needs to fail gracefully the other times. It needs to tell you what happened. It needs to let you undo the wrong ones. It needs to keep the data of the people who trusted you with it. It needs to survive a CISO walking through the architecture, a procurement team asking about SLAs, a regulator asking for an audit trail, and an engineer three years from now who has never seen your code before.

None of that shows up in a demo. All of it shows up eventually.

Research is beginning to quantify the distinction. A June 2026 preprint assembled 10,517 predominantly AI-authored applications and found 1,226 reachable deployments (11.6%). In a manually validated sample of 200 deployed web apps, 90% contained at least one vulnerability, with a median of seven among the vulnerable applications. The corpus was discovered mainly through Claude Code and Lovable fingerprints, so this is not a universal failure rate. It is still strong evidence of the mechanism: software can be public, functional, and visibly complete while failing requirements its builder did not know to specify.

A second repository-level benchmark makes the gap between working and safe measurable. On 200 feature tasks spanning 77 classes of weakness, the strongest tested configuration passed functional tests on 61% of tasks, but only 10.5% of all tasks were completed both correctly and securely. In the authors’ estimate, accepting generated work because its functional tests pass would leave a vulnerability roughly 80% of the time.

The demo checks whether the requested behavior appeared. Production asks what else appeared with it.

The distance between “make it run” and “make it survive” is what I am calling the invisible wall. A non-technical builder can reach it without knowing which requirements were omitted until real users, reviewers, or incidents reveal them.

Where the wall comes from

My first vibe-coded app was already full stack in VS Code. Auth, database, API layer, frontend, deployment pipeline. Most of the stack in the diagram. A few extra enterprise scars bolted on for dramatic effect.

But I had been a software engineer before. A long time ago, but it still counts as “hands do remember.” And before GenAI arrived, I spent years in what I can only describe as the enterprise ocean.

XaaS contracts. Identity and access management. Role-based access control. Audit trails that held up in a compliance review. Rollback strategies. Integration nightmares across six vendors. “Why is prod down at 2 a.m.” calls. Post-mortems that went around the table. Architecture decisions that came back to haunt the team eighteen months later.

When AI coding tools arrived, I was not learning to build. I was learning to build faster. That is a completely different cognitive starting point.

The muscle memory was already there. I already knew what a production system needs to survive contact with the real world. The AI tools gave me leverage on top of that existing foundation.

The no-code prompt-to-product pitch invites builders to skip the foundation entirely. That works until the wall appears. Then it does not.

What enterprise muscle memory actually consists of

This is the part that is hard to write as a list, because it does not live as a list. It lives as instinct — a set of automatic checks that fire before problems surface, not after.

But I am going to try to make it explicit, because I think that is where the real opportunity is.

IAM intuition. Experienced engineers know that “just use the admin token for now” is a promise to a future incident. Identity and access management gets designed before data gets designed, not after. The question “who can see this, who can change this, and can you prove it in a log?” gets asked at the start of a feature, not the end. Vibe coders typically add auth as a layer on top of a system that was built without it. The seams show.

Audit trail reflex. Who did what, when, and can you prove it? This question is essentially invisible in a demo. It becomes central the moment an enterprise customer asks about compliance, or when something goes wrong and you need to reconstruct what happened. Building in an audit log after the fact is painful. Designing auditability early is materially cheaper and more reliable than retrofitting it — but only if you know to ask the question.

Integration scepticism. Every dependency expands the system’s incident and maintenance surface. Experienced engineers treat the integration contract — the shape of the data, the failure modes, the rate limits, the SLA — as something to be designed carefully, not assumed to be stable. Vibe coders tend to integrate fast and trust. The trust usually holds until it does not.

Rollback discipline. Never shipping without knowing how to undo it. What happens when this migration fails halfway through? What happens when this feature is switched on and causes an unexpected downstream effect? What is the fast path back to a known-good state? These questions get asked before the ship button is pressed, not after the incident starts.

Observability first. If you cannot see it, you cannot fix it when it breaks at 2 a.m. Logs, metrics, traces, alerts — these are not add-ons for mature systems. They are the mechanism by which a system tells you when it needs attention. Building a system without them is building a car without a dashboard and trusting that nothing will ever go wrong.

Dependency hygiene. How many packages does this thing depend on? Are any of them unmaintained? Does this library have a known CVE that the auto-generated code quietly imported? The AI is good at pulling in the package that solves the immediate problem. It is less reliable about asking whether that package should be there at all.

Blast radius thinking. What is the worst-case outcome if this goes wrong? Which customers are affected? Is the failure isolated or cascading? Can you contain it? This kind of thinking becomes automatic after you have been in an incident where the blast radius was larger than anyone expected.

Why telling people to “learn more engineering” is the wrong answer

The standard prescription here is a skills gap framing: vibe coders need to learn enterprise engineering. More tutorials. Better courses. “Introduction to IAM for non-engineers.”

That framing is wrong in an important way.

The things listed above are not knowledge. They are system — a set of defaults that fire automatically, without having to think about them. You do not remember to check the audit trail because you read an article about audit trails. You remember because you have been in the post-mortem where the audit trail was missing, and that memory is load-bearing.

Courses can transfer concepts, but they rarely reproduce the fast, contextual judgment formed through operating real systems. It takes years of failure and recovery to build, and most vibe coders do not have years to spare.

But something has changed: you do not need to acquire that instinct through experience anymore. You can encode it.

LLMs have lowered the floor of building faster than any tool I have worked with. What they have not changed is what enterprise demands from software that ships into it. The bar is where the bar is.

For the first time, it is genuinely possible to encode the accumulated discipline of experienced engineers — the checklists, the review loops, the guardrails, the reference architectures, the deployment contracts — into the workflow itself, in a form that does not require the person following it to have twenty years of scar tissue.

The interesting work is not teaching vibe coders to be engineers. It is turning the knowledge of engineers into a system that does not require you to be one.

What that system looks like in practice

Encoding engineering discipline into a workflow means making the invisible visible. It means turning the automatic checks that live in an experienced engineer’s head into explicit steps that any builder can follow.

In practice, this includes things like:

Pre-ship checklists with teeth. Not a list of nice-to-haves but a set of gates that a feature must pass before it ships. Does it have auth? Does it have an audit log? Does it have a rollback path? Does it expose anything that should not be exposed? These can be defined once and applied to every feature, by anyone on the team.

Reference architectures for common patterns. Most enterprise software solves the same ten problems in slightly different shapes. Auth flows. Multi-tenant data models. Audit schemas. Integration contracts. Deployment pipelines with rollback. These do not need to be reinvented every time. They can be specified once, in a form that AI coding tools can follow, and applied consistently.

Security defaults that are on by default. The secure path should be the easy path. Headers, CORS settings, input validation, secret handling, dependency scanning — these should be configured in the template, not added as an afterthought.

Observability baked in, not bolted on. Logging, error tracking, and alerting should be present from the first line of code, not added when the first production incident reveals their absence.

Review loops that catch what the AI misses. AI coding tools are very good at making things work. They are less reliable about asking whether they should work the way they do. A human review loop — focused specifically on the questions the AI is likely to skip — is not a sign of distrust. It is an acknowledgement that “it runs” and “it is ready for enterprise” are different sentences.

This is not an exotic new definition of software engineering. The NIST Secure Software Development Framework organizes the same lifecycle responsibilities around preparing the organization, protecting the software, producing well-secured releases, and responding to remaining vulnerabilities. A generated interface cannot demonstrate those properties. The workflow around it has to produce the evidence.

The opportunity

The vibe coding conversation is mostly focused on what AI tools can do now. That is reasonable. The demos are impressive.

The question that matters more is: what happens at scale, under enterprise conditions, over time?

The builders who will win in that environment are not the ones who can prompt the best. They are the ones who have embedded engineering discipline into their workflow in a way that scales — so that each new thing they build inherits the rigour of everything that came before it, without requiring the team to reinvent it.

The wall is real. Vibe coding can ship the artifact. What it cannot supply by itself is production assurance. But there is now a plausible path to closing the gap — not by making every vibe coder into a senior engineer, but by making senior engineering into a system that anyone can run.

That is the interesting work.

This is part of an ongoing series on building AI-native products for enterprise.