Vibe Coding in the Enterprise: Why Citizen Developers Are the Real Opportunity

Last Friday, somebody on the frontline of a large industrial business sat down with Claude and, in about an afternoon, built a working web app that gave their commercial team a centralised view of the market landscape, with renewal tracking and opportunity owners. No code skills. No IT involvement. No data leaving the public domain. By Monday it was being passed around the business as a “look what’s possible” demo, and by Tuesday it had landed in the CIO’s inbox as both an exciting success story and a small governance crisis.

That conversation is now happening, in some form, at every large organisation I speak to. The cast is consistent. Business sponsor wants the result and is asking why IT cannot move this fast. CIO wants to lean in and enable, with the right guardrails. Security lead worries about malware injection and supply chain risk in AI-generated code. Development lead worries about the volume of code review this is about to create. Architect is trying to coordinate a coherent response across all of them. Frontline person just wants to use the thing they built and does not understand why this is suddenly complicated.

There are actually two conversations happening about vibe coding right now, and most organisations are only having one of them.

The first conversation is about developers. Can professional engineers move faster with Claude Code, Cursor, GitHub Copilot, and Codex? Yes, obviously. That conversation is largely settled and the value is being captured.

The second conversation is the one that matters more for most enterprises, and it is the one this article is about. It is about everyone else. The thousands of people in your business who are not developers, who do not work in IT, and who spend a meaningful chunk of every week working around the gaps in your application portfolio with spreadsheets, macros, and personal productivity hacks that nobody in IT can see. That is where the real value sits, and that is where the platforms have finally caught up.

The short version: vibe coding by non-developers should be treated as the next step in your citizen development program, not as a separate AI initiative. It should be enabled on a platform you control, with the right tiering, the right guardrails, and an explicit graduation path into engineering for anything that needs to scale. Blanket bans do not work and never have. The risks are real, mostly familiar, and tractable. The business value is too large to leave on the table.

Two Audiences, Two Risk Profiles

Vibe coding, the term Andrej Karpathy coined in early 2025 for AI-assisted development where you describe what you want and let the model generate the code, is now Collins Dictionary’s 2025 Word of the Year. Gartner expects more than 80% of enterprises to have used generative AI APIs or deployed GenAI applications by the end of 2026. Adoption is not the question.

The question is who should be doing it, and on what.

For professional developers, open vibe coding tools like Claude Code, Cursor, ChatGPT, and Copilot make sense. These people understand version control, security trade-offs, code review, and what production-ready actually means. They can read the output, push back when the model produces something dangerous, and own the code afterwards. Vibe coding in this context is a productivity multiplier on top of existing engineering discipline.

For everyone else, dropping the same tools in their lap is asking for trouble. The data tells us what happens. A scan of 5,600 publicly deployed apps built on Lovable, Bolt.new, and Base44 found 2,000 critical vulnerabilities, 400 exposed secrets including API keys, and 175 instances of PII including medical records and payment data. A separate Tenzai study tested five major AI coding agents and found that every single one introduced Server-Side Request Forgery vulnerabilities in URL-handling features. Five out of five. Zero of them set basic security headers by default.

A marketing analyst with a Claude API key and a Vercel account can build something useful. They can also expose the customer database to the internet by accident. The model does not know which one you wanted.

The framing that works is this: citizen vibe coding is a governed prototyping and personal productivity capability, with a clear graduation path into engineering for anything that needs to scale, integrate, or run as critical infrastructure. It is not a parallel software development function operating outside engineering pathways. It is a different lane on the same road, with different speed limits and the option to merge.

This distinction matters because it answers most of the objections before they start. Engineering teams stop worrying that they are being replaced. Security teams know which tier of control applies. Citizen developers know what they are allowed to build and what triggers a handover. The frontline gets the productivity benefit. IT keeps the visibility.

Vibe Coding as the Next Step in Low-Code/No-Code

Citizen development is not new. Gartner has been tracking it for years, and the numbers have been pointing in one direction: by 2026, 80% of technology products and services will be built by people outside formal IT roles, and citizen developers at large enterprises are projected to outnumber professional developers 4:1.

That trend predates vibe coding. Power Apps, Power Automate, Mendix, OutSystems, and Appsheet have spent the last decade building the muscle. Vibe coding collapses the learning curve. A Power App that took a citizen developer two weeks to build with drag-and-drop and Power Fx now takes an afternoon, and the person building it does not need to learn the formula language at all.

Most of the risks people now panic about with vibe coding are risks the citizen development community has already solved, scaled-up versions of problems that platforms like Power Platform, Mendix, and ServiceNow App Engine have spent the better part of a decade designing controls for.

Why Blanket Bans Always Fail

Some IT leaders still default to a ban. Don’t.

This never works. People want to do their jobs well. When the official path is too slow or does not exist, they find another path. Excel is the most successful citizen development platform in history not because it is well-governed, but because it is there, on every desk, and the alternatives require a six-week intake process. When IT blocks ChatGPT, people use it on their phones. When IT blocks a vibe coding platform, people sign up with personal email addresses and a credit card.

The result of a blanket ban is not safety. It is loss of visibility. The work still happens, but now you cannot see it, cannot govern it, cannot back it up, and cannot recover it when the person who built it leaves the company. Retool’s 2026 research found that 60% of respondents had built software outside IT oversight in the past year, which is exactly what you would expect when the formal channels cannot keep up with demand.

The job is not to stop the work. The job is to give people a sanctioned, secure place to do it. That is what platforms do.

This is the same lesson SaaS taught us a decade ago and DevOps taught us five years ago. Security teams that adapted by moving from gatekeeper to enabler kept their influence. Security teams that did not, lost it. Vibe coding is the same shift, just faster.

The Platform Approach: Visibility, Governance, Control, Security

A platform approach is not a single product. It is a set of capabilities the organisation must be able to provide:

Visibility. Every app built must show up in a single inventory. Who built it, what data it touches, what it does, who is using it, when it was last changed. You cannot govern what you cannot see.

Governance. Roles, approvals, lifecycle. Apps for personal use have one set of rules. Apps used by a team have another. Apps that touch customer data, financial data, or operate at scale have a third. The platform enforces those tiers automatically, not through policy documents nobody reads.

Control. Access to data is mediated by the platform, not by credentials embedded in the app. When a citizen developer connects their app to the CRM, they get only the data their existing role entitles them to. When they leave the company, the app loses access automatically. Single sign-on, role-based access control, and audit logs are non-negotiable.

Security. The platform applies sensible defaults. Authentication is built in. Common vulnerability classes are eliminated at the framework level, not left to a non-technical user to remember. The Replit team described this as defense in depth across every layer of the vibe coding stack, which is exactly the right framing.

This is the same model that made cloud adoption work. AWS, Azure, and GCP did not succeed by giving everyone root access to the data centre. They succeeded by giving teams a paved road with guardrails built in.

The Risks Are Familiar, the Scale Is New

Most risks people raise here map to something the citizen development community has already solved:

• Shadow IT: solved by giving people a sanctioned platform and making it easier than the alternatives.
• Data leakage: solved by mediating data access through the platform identity, not embedded credentials.
• Apps with no owner: solved by lifecycle management, expiry dates, and ownership transfer workflows.
• Untested code in production: solved by tiered approval, automated security scanning, and clear lines about which apps need formal review.
• Sprawl: solved by visibility, app rationalisation, and a clear deprecation pathway.
• Compliance and audit: solved by audit logs, data classification at the platform level, and regulatory tagging.

The newer issues are mostly about the AI generation itself, and these deserve to be taken seriously rather than waved away. They are a different class of risk to anything the citizen development community has dealt with before, and they are the concern most likely to be raised by your security and development leads when this conversation starts.

The AI Code Supply Chain Risk Is Real

The legitimate pushback goes something like this: AI generates code that looks finished. Citizen developers cannot review it. There are not enough software engineers to manually review millions of lines of vibe-coded output. One person ships malware-laced code and the whole organisation is exposed.

Three components are genuinely new. AI models invent package names that do not exist, and attackers register them with malicious payloads so the next install ships the malware. AI agents read README files, comments, and configs when generating code, and attackers embed instructions there for the model to follow (AquilaX research traces how this propagates). Generated code looks production-ready, suppressing scrutiny. Combined with citizen developers who cannot read the code, the review layer traditional development relies on does not exist.

Not theoretical. Georgia Tech’s SSLab attributed at least 35 new CVEs in March 2026 to AI-generated code. OX Security found critical vulnerabilities in the AI coding tools themselves (Cursor, Windsurf, VS Code AI extensions) the month before. BeyondTrust’s Phantom Labs found a command injection in OpenAI’s Codex cloud environment that exposed GitHub credentials. Tools, outputs, and supply chain are all attack surfaces now.

This is exactly why the platform approach matters

And why the platform alone is not enough

What a well-chosen platform handles automatically:

• Dependency allowlists, so only approved packages can be installed
• Automated SAST and secret scanning on every generated artifact before it runs
• Sandboxed execution environments that contain blast radius if something does go wrong
• Authentication and data access mediated by platform identity, not embedded credentials
• Continuous evaluation of generated code for security issues, the Shift Left model Replit describes

What needs to sit alongside the platform:

• An extended development pathway for citizen-built apps that scales differently to traditional code review. Specialised scanners now exist for AI-generated code that catch patterns traditional SAST rules miss.
• Tooling that can detect typosquatted and hallucinated dependencies before they reach production
• An approval pathway with mandatory human review at the point an app moves from personal use to shared use to enterprise use
• Clear rules about what a citizen-built app can connect to, and what triggers an automatic referral to engineering

A well-chosen platform does not eliminate the AI code supply chain risk. It moves the risk to a place where automated tooling can address most of it, and a small development team can address the rest, without manually reviewing every line of every citizen-built app. That is the only model that scales.

If your security or development leads are pushing back, the answer is not to override them. It is to bring them into the platform selection and process design from day one. They are right that the risk is real. Their input is what makes the program work rather than blow up.

What the Platforms Actually Look Like in 2026

The market has moved fast in the last six months. A short scan of where the major options sit:

Microsoft Power Platform Vibe launched in public preview in April 2026 at vibe.powerapps.com. Describe an app in plain English, the platform generates a plan, the data model, the Dataverse tables, and a working React app. It runs Anthropic models alongside OpenAI and inherits the full Power Platform governance stack: managed environments, DLP policies, Center of Excellence kit, audit logs, and role-based access. NASA is the headline reference customer, running 47,000 monthly active Power Platform users on the same stack. For organisations already invested in Microsoft 365, this is the path of least resistance.

Google AI Studio added a full-stack vibe coding experience in March 2026 backed by the Antigravity coding agent and built-in Firebase for auth, database, and hosting. It is genuinely impressive for prototyping. For enterprises, the production path runs through Vertex AI and Google Cloud, not AI Studio itself, which is the right separation. AI Studio for the prompt-to-prototype loop, Vertex AI for governed production workloads.

Replit has gone hardest at the enterprise vibe coding positioning. The platform is in use at 85% of the Fortune 500, closed a $400M round at a $9B valuation in March 2026, and ships SSO, SOC2, private deployments, and role-based access control on its enterprise plan. The Databricks connector is the more interesting story for large enterprises: governed data stays in Databricks, the app generation happens in Replit, and Unity Catalog enforces who can see what.

Lovable and Vercel v0 are the other names that come up. Both are excellent at what they do, both have a smaller enterprise governance story, and both had significant security incidents in April 2026. Lovable had an access control failure that left project data readable to unauthorised users, and Vercel was hit through a compromised third-party AI tool that exposed customer environment variables. These platforms are great for individual developers and small teams. For large enterprise citizen development at scale, the governance model is not yet there.

Specialist enterprise platforms like Superblocks, Retool, ToolJet, and UI Bakery have spent the last year explicitly building for the governed citizen development use case: private VPC deployment, fine-grained data access controls, audit logs, and AI app generation that respects organisational permissions from the first prompt.

The right answer for most organisations is one or two of these, not all of them. The picking criteria matter more than the brand:

• Does it connect to your identity provider?
• Does it respect data access from your governed sources or does it copy data into its own stores?
• Can you see every app built on the platform from a central console?
• Does it support tiered governance for personal, team, and enterprise apps?
• Where does the AI generation happen, and what model is it using?
• What does the platform do to mitigate AI-specific risks like hallucinated dependencies and prompt injection in generated code?

The landscape moves faster than traditional IT evaluation cycles. New tools emerge every few months, often picked up by individuals or small teams before the formal evaluation has caught up. An approved tool list that takes nine months to refresh is permanently out of date. Build the evaluation pathway with that in mind: a lightweight first-pass risk assessment that can absorb new entrants quickly, a deeper evaluation for anything that looks like it might become standard, and a quick “no, here is why, and here is the approved alternative” for anything that fails. The goal is not to keep up with every release. The goal is to never be more than one good option behind.

For deeper thinking on how to wire AI tools into enterprise data without losing control, the MCP server architecture piece covers the integration layer that makes most of this work.

The Business Case

The productivity case for citizen development was already strong before vibe coding showed up. Low-code and no-code platforms cut custom app development time by 50% to 90%. Forrester found that low-code and no-code software development helps teams build cloud-native applications more than 10 times faster with 70% fewer resources.

Vibe coding compresses the timeline further. What used to be a two-week Power Apps build for a moderately complex departmental tool now ships in an afternoon. Internal tooling that previously sat on the IT backlog for six months because it was not big enough to prioritise gets built by the team that actually needs it. The productivity ceiling has moved.

The strategic case is more interesting than the productivity case. IT is genuinely good at top-down, large-scale, integrated programs. SAP rollouts. ERP transformations. Identity programs. Major SaaS deployments. These are hard, they need professional engineering, and they will always be IT’s job.

What IT has never been good at is the long tail. The 400 small applications, the 4,000 small workflow improvements, the 40,000 small process gaps that exist on every frontline in every business. Each one is too small to fund. Together they represent a vast amount of waste, and the people who could fix them sit right there, on the frontline, with the context.

Citizen vibe coding closes that gap. The frontline gets to build what the frontline needs, IT keeps the visibility and governance, and the platform absorbs most of the risk. The CIO gets to spend their engineering capacity on the strategic work that actually requires it.

If you want a worked example of how this looks when the platform layer is in place and the build velocity is real, the Claude Code methodology piece walks through what an AI-first build cycle looks like in practice.

Where to Start When the First App Is Already Built

The sequence that works:

1. Treat the first frontline build as a signal, not a problem. If someone in the business has already vibe coded something useful, they have just done the discovery work for you. The person is now an obvious candidate to become one of the first sanctioned power users. Punishing them, or making them feel like they did something wrong, is the fastest way to push the rest of the iceberg further underground.

2. Pick a platform that already fits your stack. If you are a Microsoft shop, Power Platform Vibe is the obvious starting point. If you are a Google Cloud shop, AI Studio for prototyping with a Vertex AI production path. If you have a strong data platform investment, the Replit-Databricks pattern is worth a serious look. Resist the temptation to introduce a brand-new vendor unless your existing stack genuinely cannot do the job. Plan on 60 to 90 days from platform selection to first sanctioned cohort and an annualised cost in the order of one to two engineering FTEs once you include licensing, identity integration, and CoE staffing. The fastest way to seed the cohort, surface real use cases, and prove value back to the business is a hackathon: pick a business unit with a genuine backlog of paper-cuts, give them the platform and a day, and let the demos drive the next round of adoption.

3. Wire it into identity, data governance, and your existing development tooling day one. SSO, role-based access, audit logs, DLP, dependency scanning, and SAST extended to cover AI-generated code. The platform is only as safe as the data boundaries you set and the development controls you wrap around it. Bring the security and development leads in at platform selection, not after.

4. Establish tiered governance with an explicit graduation path. Personal apps need almost no oversight. Team apps need an owner, a basic data classification, and platform-level scanning. Apps that move toward broader business use trigger a structured handover to engineering for hardening, integration, and production support. Make the graduation path obvious and welcomed, not punitive. Most apps will live in the first two tiers and that is fine. The handful that graduate are the ones worth productionising properly.

5. Run a Center of Excellence. A small central team supporting the makers. Templates, training, office hours, governance enforcement, rationalisation, and the bridge into engineering when an app graduates. Not optional.

6. Communicate the rules clearly. What can be built, with what data, on what platform, with what expectations. What triggers a security review or graduation to engineering. What is disallowed and why. Most citizen developers want to do the right thing; they need to know what it is.

7. Measure and rationalise. Track adoption, app inventory, retirement rates, graduations, and value delivered. Kill what nobody uses. Promote what proves valuable. Refine the framework from the data.

The organisations that get this right will see citizen development at a scale that was not possible eighteen months ago. The organisations that try to block it will discover, the way every previous wave has been discovered, that the work happens anyway, just somewhere they cannot see it.

AI-powered citizen development is going to truly revolutionise how we work. The IT leaders who block this will not stop the work. They will only stop seeing it. Six months from now, the frontline person is either building 20 more useful things on a sanctioned platform, mentoring five colleagues into the same pattern, and moving the productivity needle for the organisation. Or they have left for a competitor who let them.

The frontline is ready. The question is whether IT is.

Written by Bradley Hunt. For more on AI-first enterprise architecture, see the writing index.