The illusion of power: what vibe coding hides from the people doing it

What AI actually gave you

AI collapsed the cost of producing code. It did not collapse the cost of knowing whether that code is right.

Those are different problems. The second one is harder.

Consider a patient who has read three medical websites. can describe symptoms fluently and even suggest a diagnosis. Sometimes they are right. What they cannot do is know what they are missing. They don't know which symptom is the dangerous one, which test to order, or which drugs interact. A good clinician earns their value from what they know to look for and what they refuse to ignore. The patient's fluency is the trap.

Vibe coding is the symptom-checker version of software engineering. It gives you fluency. Fluency feels exactly like competence from the inside.

Two of thirteen

What you see on screen is a fraction of a real software platform, and AI models are optimised to make that fraction look finished.

Ask an AI for a customer portal and you get a customer portal. It looks right, clicks right and demos beautifully. It will not volunteer what the portal needs to survive the real world, because you did not ask, and you did not know to ask.

Measured against the 13 layers below, the typical vibe-coded build I see has two: a front end and a database. Neither is built to production standard. The other eleven are absent.

The MVP1 13-layer production architecture

I developed this framework from decades of delivering digital programs across healthcare, financial services, government and enterprise. It describes the full technical stack that separates a proof of concept from enterprise-ready software. Every layer exists because its absence has caused a real failure somewhere.

The 13 layers, one by one

1 Front end foundations

The front end is the layer AI does best, which is exactly why it misleads. The screen looks finished. Underneath, you often find API keys and credentials shipped to the browser where anyone can read them, no handling for failed requests, no loading or empty states, and performance that degrades the moment real data arrives. Logic that decides who can see what must never live here, because anything in the browser belongs to the user.

2 APIs and back end logic

APIs are how your product talks to your app, your partners, your payment provider and your customers' systems. AI-generated APIs tend to work on the happy path and collapse everywhere else. Missing from most of what I see:

• Versioning, so one change breaks every integration that depends on you.
• Pagination, so one large request takes the whole system down.
• Idempotency, so a retried payment request charges the customer twice.
• Input validation and consistent error handling, so failures are silent or leak internal details.
• Permission checks on every endpoint, not only the ones the AI remembered.
• Sensible limits on what a single request can ask for.

How it fails: at 2am, usually with a customer on the phone. None of this shows in a demo.

3 Database and storage

Every platform is a data model with an interface on top. If the data model is wrong, everything built on it is wrong, and fixing it later costs a fortune. AI builds the data model for the screen in front of it, not for the business you will run in two years.

• Tables designed for the first feature, with no thought for the tenth.
• Customer data not properly separated, so multi-tenancy becomes a rebuild.
• The same data stored in several places that drift out of sync, until your reports disagree with each other.
• Missing constraints, so bad data gets in and stays in.
• No migration strategy, so every change risks the data you already hold.
• No indexing, so it runs fine at 100 records and falls over at 100,000.
• Uploaded files stored without access controls or lifecycle rules.

How it fails: in slow motion. Nothing breaks on day one. It breaks when you have customers, revenue and a growth story, and the fix means rebuilding the foundation while people still live in the house.

4 Auth and permissions

AI-generated apps routinely get authentication right (can you log in?) and authorisation wrong (what are you allowed to see once you are in?). The difference is brutal. In a poorly built platform, any logged-in user can open another customer's records by changing an ID in a request. The app works perfectly in testing because you only ever tested as yourself.

Production needs defined roles, least-privilege access, multi-factor authentication, safe session handling and a single, tested place where access decisions are made. Not scattered checks the AI remembered to add.

How it fails: one customer sees another customer's data. That is a reportable breach, not a bug.

5 Hosting and deployment

Where does your code run, and how does a change get from a laptop to your customers? In vibe-coded builds the honest answer is often "the AI set it up" and "we edit production directly." Production needs separate development, staging and live environments, repeatable releases, configuration kept apart from code, and a rollback you have actually tested.

How it fails: a fix at 4pm takes the platform down at 4:05pm, and nobody can undo it.

6 Cloud and compute

The platform runs on someone's infrastructure, and the choices matter: sizing, regions, cost limits and data residency. Do you know which country your customers' data sits in, and whether your contracts allow it? Does anyone get an alert when the bill triples? AI picks defaults. Defaults are not decisions.

How it fails: a surprise invoice, or a customer contract breached because the data lives in the wrong place.

7 CI/CD and version control

Continuous integration and deployment is the safety net under every change: automated tests, code review, dependency scanning and secret scanning before anything ships. Vibe-coded builds frequently have no tests at all, so every change is a gamble. Credentials committed to repositories, some of them public, are a recurring finding. Version control is also your memory. Without it, nobody can say what changed, when, or why.

How it fails: each new AI-generated fix quietly breaks something that worked yesterday.

8 Security and row-level security

This is the one that keeps me up at night, and the one enterprise buyers test first. Row-level security means the database itself enforces who can read or change each individual record. It is the last line of defence when application code has a flaw, and AI-built apps regularly leave it switched off, because turning it on made the demo "break" and the AI took the shortcut.

Other gaps I see constantly:

• Secret keys and credentials sitting in exposed code or public repositories.
• Input that is never validated, which opens the door to injection attacks.
• Third-party packages pulled in without checks, including abandoned, vulnerable or non-existent ones the AI invented.
• Open storage, debug settings left on and default configurations in production.
• No threat testing by anyone who is paid to break the system.

Here is the part that should worry you. The AI will tell you the code is secure. It says so confidently and fluently, and it is often wrong. It is not lying. It pattern-matches to what secure code sounds like. It carries no accountability for the outcome and it won't be in the room when you explain the breach to your customers.

9 Rate limiting

Rate limiting stops one user, one bot or one bug from consuming everything. Without it, a bot can guess passwords all day, scrape your whole dataset, or hammer an expensive endpoint until your hosting bill or your service collapses. Production needs limits on logins, on API calls per customer and on the cost of any single request.

How it fails: an attack that looks like a traffic spike, a bill that looks like a typo.

10 Caching and CDN

Caching stores answers so the system does not recompute them for every request. A content delivery network (CDN) serves assets from locations close to the user. Vibe-coded builds rarely have either. The product feels fast with 10 users, then slows and costs more with every user you add, because every request does the full work from scratch.

How it fails: your growth makes the product worse, and your cloud bill climbs faster than your revenue.

11 Load balancing and scaling

Load balancing spreads traffic across resources so no single machine is a point of failure. Scaling lets capacity grow with demand. Ask the question I asked the founder: what happens at 10,000 users instead of 10? A vibe-coded platform usually has one server, one database and no tested answer.

How it fails: on your best day. The campaign works, the traffic arrives and the platform goes down.

12 Error tracking and logs

You cannot fix what you cannot see. Production needs error tracking that tells you something broke before a customer does, logs that show who accessed what, and alerts that reach a person. Without them, a breach is invisible. After one, you cannot tell what was taken or when, and you cannot answer your regulator.

How it fails: silently. The first you hear of it is a customer, a journalist or an attacker.

13 Availability and recovery

Software isn't finished when it works. It is finished when someone can run it, recover it and prove it. That means backups, and tested restores, because an untested backup is a hope, not a backup. It means defined recovery targets (how much data can you lose, how long can you be down), failover for the parts that matter, and a rehearsed plan.

How it fails: the day you need the backup is the day you learn it never worked.

One more thing sits across all thirteen: maintainability. A vibe-coded codebase often grows by the AI patching its own patches. Nobody holds the whole design in their head, including the AI, which only sees what fits in its working window. Each new request risks breaking something old. Speed turns into fragility, and eventually every change is a gamble.

What the independent evidence says

I'm not asking you to take my word for it. The independent evidence points the same way.

On AI-generated code. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that AI-generated code introduced a security vulnerability in 45% of cases. Its 2026 report found the average pass rate stuck at 56%, virtually unchanged from the year before. Models got faster and more capable. They did not get safer.

On the vulnerabilities themselves. The OWASP Top 10:2025, the industry's standard awareness list of critical web application risks, ranks Broken Access Control first. That is the failure behind Layers 4 and 8. The same list names Security Misconfiguration, Software Supply Chain Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions. Every one of them maps to a layer vibe-coded builds skip.

Compliance: the proof the layers work

I hear this one often: "The AI built it to be compliant."

It didn't.

Compliance is not a layer and it is not a property of code. It is the evidence that your layers work: how data is collected, stored, accessed, retained, deleted and audited, and your ability to prove it consistently. It draws on Layers 3, 4, 6, 8, 12 and 13 together.

In Australia that means the Privacy Act and the Australian Privacy Principles, the Notifiable Data Breaches scheme and, depending on your customers, frameworks such as the Essential Eight, ISO 27001, SOC 2 and IRAP for government. Healthcare, financial services and education add their own layers. If your organisation is covered by the Privacy Act, a further obligation starts on 10 December 2026: you must describe in your privacy policy how automated decision-making uses personal information, where it makes or substantially drives decisions that significantly affect people.

Ask yourself:

• Do you know where your data physically lives, and whether your customers' contracts allow it?
• Can you delete a person's data completely when they ask?
• Do you have audit trails showing who accessed what?
• Do you know which AI services your customer data flows into?
• Could you survive a security questionnaire from an enterprise or government buyer?

That last question is where the delusion ends. Enterprise and government buyers ask what your AI never raised, and you won't have the answers. The sale dies. Or it closes, and the breach arrives afterwards.

The unknown unknowns

Everything above is bad enough. What makes it dangerous is that you can't feel any of it.

There are things you know you don't know. You can hire for those. Then there are things you don't know that you don't know. You can't hire for them, ask about them or worry about them, because they don't exist in your mind.

AI makes this worse in three ways.

1. It agrees with you. A good senior engineer says "that's a bad idea, and here's why." AI says "great idea, here's the code."
2. It sounds right. Confident, well-formatted output reads as correct. Wrong answers and right answers look identical.
3. Nothing pushes back until failure. In a real engineering team, code review, testing and experienced colleagues catch problems early. Remove the team and the only things left to tell you something is wrong are a customer, a regulator or an attacker.

A little knowledge produces more confidence than deep knowledge does. Deep knowledge knows how much there is to know.

Psychologists have a name for this: the Dunning-Kruger effect. In 1999, David Dunning and Justin Kruger published research showing that people with the least skill in a domain tend to overestimate their ability the most. The reason is cruel. The skills you need to do the work well are the same skills you need to judge whether it is done well. Without them, you cannot see your own mistakes. The less you know, the less equipped you are to notice what you don't know, and the more confident you feel than your knowledge justifies.

Vibe coding industrialises that trap. The AI produces output that looks expert. The output works in the demo. Nothing in the process shows you the gap, so the feedback that would normally correct overconfidence never arrives. Meanwhile the experienced engineer sounds less certain, because they know how many ways a system can fail. That caution is not a lack of confidence. It is evidence of competence.

This is the oldest trap in business. The people most certain they have cracked it stand furthest from the actual problem.

To the founder who let the engineers go

I'll say this plainly, because I would want someone to say it to me.

If you made your engineering team redundant because an AI model built your product in a weekend, you did not replace them. You removed the people who knew what could go wrong and kept the ones who can't see it.

You didn't win. You swapped a visible cost for an invisible risk. The invisible risk doesn't show on your P&L today. It shows up later, with interest.

And if you are a non-technical team member who now tells experienced engineers how to do their jobs because "the AI said so," understand what that is. It is a person who has read about surgery telling the surgeon where to cut. Your engineers aren't resisting change. They are the ones who can see the cliff while you admire the view.

Be humble. Not because AI lacks power, but because you hold a powerful tool without the training to know where it is dangerous.

Add agents and the stakes double

Everything so far describes software that waits for a person to click. Now give that software the ability to decide and act. This is where vibe coding is heading, and it is where the downside gets severe.

An AI agent doesn't just show data. It reads documents, calls tools, writes to databases, sends messages and spends money on your behalf. The 13 layers still apply, in full. Four more sit on top. Together they form the MVP1 17-layer agentic SaaS architecture.

Two controls that are never optional

In MVP1's Agentic Architecture Standard v2, two elements are mandatory at every stage of maturity, including a first prototype.

1. A token and cost budget with a kill-switch. A hard stop when an agent exceeds a spend ceiling, step limit or loop threshold. Without it, one bug or one attack can burn through inference spend or repeat an action thousands of times before anyone notices. OWASP lists unbounded consumption as a distinct risk in its Top 10 for LLM applications.
2. Tenant isolation. One customer's data, prompts and agent memory must never reach another customer. An agent that retrieves across customers without a hard boundary turns a data leak into a feature.

What changes in the original layers

Agents deepen two of the 13 layers.

• Layer 8 Security now includes agent identity: the agent is not the user, so it needs its own scoped, short-lived credentials. It also needs defences against prompt injection, where hidden instructions in a document or web page hijack the agent, and against excessive agency, where an agent holds more tools, permissions or autonomy than its task needs. OWASP ranks prompt injection first and excessive agency among the top risks for LLM applications.
• Layer 12 Logs becomes full trajectory tracing: every step, tool call, prompt, response, decision and retry, so you can reconstruct what the agent did and why.

The full standard also adds elements that have no equivalent in conventional software: inference cost and FinOps (cost per task and per tenant), model supply-chain management (pinning model versions and managing provider drift and deprecation as change control), an improvement flywheel that feeds production failures back into prompts, tools and test sets, and evaluation in the release pipeline that blocks a change when behaviour regresses.

The 17-layer view is the memorable version. The full standard organises the same material into five planes:

1. Foundation

Front end as a control surface for autonomy, deterministic back end logic, data with an append-only audit trail.

2. Infrastructure and operations

Deployment of code and prompts together, queues and backpressure, caching, budgets with the kill-switch, recovery and cost control.

3. Agentic runtime: the heart

Orchestration, tools and context, the part with no equivalent in conventional SaaS.

4. Assurance and trust

Security and identity, trajectory tracing, evaluation, guardrails and human oversight, cutting across everything.

5. Lifecycle and governance

Versioned prompts, models and configurations, evaluation in the pipeline, model supply chain and the improvement flywheel.

Human oversight is also becoming a legal question. From 10 December 2026 the Privacy Act requires covered organisations to disclose how automated decision-making uses personal information. An agent that approves, declines, ranks or prices people is inside that rule, and you cannot disclose what you cannot trace.

Where vibe coding is the right tool

Scrutiny works both ways, so here is the fair position.

Vibe coding is excellent for prototypes, throwaway internal tools, design exploration and testing whether anyone wants the thing. I use it for exactly that. MVP1's standard scales the definition of done by stage: a validation MVP can carry thin implementations of most layers, a production SaaS needs them built and proven, and a regulated or sovereign product needs them evidenced and audited. Even at the validation stage, the budget with a kill-switch and tenant isolation stay.

The danger is not vibe coding. The danger is the quiet slide from stage one to stage two. A prototype acquires a paying customer, then real data, then a contract, and nobody stops to say: this is no longer a prototype. Know which stage you are in, and say it out loud.

Why engineering skill gains value, not loses it

Here is the counterintuitive truth. As AI makes code cheaper, engineering judgement becomes the scarce resource.

When producing code was expensive, the cost of writing it limited how much bad code could exist. Now anyone can generate unlimited code. The constraint has moved from writing to deciding: what to build, how to structure it, what to trust, what to throw away and what will hold at scale.

That is architecture, security thinking, data design and systems judgement. It is the core of software engineering, and it is exactly what AI cannot be held accountable for.

The role of the engineer is changing, and it is getting bigger. The best engineers I work with now operate as architects and governors. They direct AI, review what it produces, set the guardrails, catch the subtle failures and own the outcome. One senior engineer using AI well delivers the work of a much larger team. A non-engineer using AI alone delivers a much larger pile.

AI is a multiplier. It multiplies whatever you bring. Bring deep expertise and you get leverage. Bring none and you get a faster way to build something you can't maintain, secure or defend.

Score your product

Answer each question with yes, no or don't know. Every no and every don't know is a finding. Start with Layers 4 and 8. If you can't answer those, stop and fix them before anything else.

1. Front end: Are secrets kept out of the browser, and does the app handle failed requests and empty data?
2. APIs: Does every endpoint check permissions, validate input, paginate results and survive a retried request?
3. Database: Was the data model designed for the business in two years, with constraints and tested migrations?
4. Auth: If a logged-in user changes an ID in a request, are they blocked from another customer's data?
5. Hosting: Do you have separate environments and a rollback you have tested?
6. Cloud: Do you know where your data lives, and do you get alerted when costs spike?
7. CI/CD: Do automated tests, code review and secret scanning run before every release?
8. Security: Is row-level security on, and has an independent party tried to break the system?
9. Rate limiting: Are logins, API calls and expensive requests throttled?
10. Caching: Do you have a caching and CDN strategy that holds cost as users grow?
11. Scaling: Have you tested what happens at 100 times today's load?
12. Logs: Will a person be alerted to errors, and can you show who accessed what?
13. Recovery: Have you restored from backup, and do you know your recovery targets?
14. Orchestration: Does each agent run have an explicit state, and can it resume after failure?
15. Tools: Does each tool carry only the permissions its task needs, with side effects sandboxed?
16. Context and memory: Do you control exactly what the agent sees, and can you inspect and purge its memory?
17. Evals and oversight: Is there a test set with a pass threshold, and does a person approve high-impact actions?

If your product contains agents, add two more: is there a budget with a kill-switch, and is tenant isolation enforced everywhere the agent reads? If either answer is no, nothing else matters yet.

What to do about it

I'm not telling you to stop using AI. Use it with your eyes open.

1. Keep or hire real engineering judgement. Even one senior architect changes the outcome. Use AI to make that person ten times more effective, not to replace them.
2. Score your product against all 13 layers. Treat every "don't know" as a finding, and fix Layers 4 and 8 first.
3. Get an independent security review before you go live. Not the AI's opinion of its own work. A real penetration test and code review by people who break systems for a living.
4. Design your data model deliberately. Do it before you scale, with someone who has done it before.
5. Know your compliance obligations before your customers ask. Work out where your data lives, who touches it and what you can prove.
6. Demand observability. If you can't see what your platform is doing, you don't control it.
7. Put a budget and kill-switch on every agent. Then give each agent its own identity, scoped tools, evals and human approval for anything high-impact.
8. Make your AI challenge you. Tell it to find the flaws, not to please you. Then have a human verify the answers.
9. Be honest about what you don't know. That honesty is the most valuable engineering skill you can build.

The real problem is rarely on the screen

I spent seventeen years inside enterprise and government technology, across financial services, the Australian federal government, state government and mining. The biggest lesson: the visible problem is almost never the real one.

On one government program, a $34M, seven-year effort with a team of 50 to 70 people, the real blocker wasn't technology. It was a legal restriction on information sharing. Nobody wanted to name it. Once it was named, the law changed and seven projects got delivered. The skill that mattered was seeing what sat underneath.

That is what real engineering gives you. It isn't typing speed. It is the ability to see what is underneath.

AI hands you the keys to the building. It doesn't tell you where the load-bearing walls are, and the building doesn't need to look unstable until the day it comes down.

Use the tool. Respect the craft. Hire the people who can see what you can't.

The most expensive sentence in business right now: "But it was working when we launched."

Scope and limits

Scrutiny deserves a straight account of what this article is and is not.

• The frameworks are MVP1's. The 13-layer production architecture and the Agentic Architecture Standard v2 are MVP1's own working standards, built from delivery experience. They are not industry-body standards. The OWASP mapping in this article is MVP1's mapping.
• The "two of thirteen" observation is mine. It describes the typical vibe-coded build I see. It is not a measured industry statistic, and some AI-assisted builds will have more.
• The Veracode figures come from a vendor study. They measure AI code completion on defined tasks, not complete applications, and a vendor with a security business ran them. Treat them as strong directional evidence.
• The Dunning-Kruger effect is a pattern, not a law. Kruger and Dunning's 1999 finding is widely replicated in direction, but researchers debate how large the effect is and how much is statistical artefact. I cite it to explain why overconfidence is predictable, not to label any individual.
• Regulatory references are summaries, not legal advice. Check your obligations under the Privacy Act and any sector rules with a qualified adviser.
• Standards move. Cited sources were current at publication on 14 October 2026.

Frequently asked questions

About the author

Jay Pandya is the founder and chief executive of MVP1 Ventures, a software and AI company in Brisbane. He spent seventeen years in enterprise and government technology from 2001 to 2018, across financial services, the Australian federal government, state government and mining, including a period in Silicon Valley. Since 2018 he has worked with startups and small and medium businesses, and developed the thirteen-layer production architecture and the agentic architecture standard described here.

Sources and further reading

• OWASP Top 10:2025: Web Application Security Risks (Broken Access Control ranked first)
• OWASP Top 10 for LLM Applications 2025 (prompt injection, excessive agency, unbounded consumption)
• Veracode, 2025 GenAI Code Security Report
• Veracode, 2026 GenAI Code Security Report (coverage in SD Times)
• Australian Privacy Principles, Office of the Australian Information Commissioner
• OAIC: Transparency for use of AI and automated decision making (commences 10 December 2026)
• Essential Eight, Australian Signals Directorate
• Kruger, J. and Dunning, D. (1999), Unskilled and unaware of it, Journal of Personality and Social Psychology