Share this post
Gartner predicts that by 2028, 90% of enterprise software engineers will use AI code assistants, up from less than 14% in early 2024. AI-assisted development is quickly becoming a standard workflow inside software teams. At the same time, simpler prompt-based tools are putting software creation into the hands of finance, operations, marketing, and other business teams.
This shift can help employees solve problems faster, but it also creates a new governance challenge. When AI-built apps are deployed without oversight, they can introduce security, data-access, and compliance risks.
This guide explains what enterprise vibe coding is, why it is growing, the risks it creates, and how to give business builders a safe, governed path to deploy AI-built apps without relying on a full development team.
What Is Enterprise Vibe Coding?
Enterprise vibe coding is the use of AI tools by non-developers inside a business to build working software from natural-language prompts.
The person describes the outcome they want, and the tool generates real, running code, a web app, an internal dashboard, a script, or an automation that they can deploy without touching the underlying implementation. The tools driving this are general-purpose and easy to reach, including Lovable, Bolt, v0, Replit, Claude, and ChatGPT.
Most of the building happens outside the engineering function. For example, a finance analyst might generate an internal web app that reconciles data across two spreadsheets, an ops manager might automate a weekly report pulling from Salesforce, Slack, and a shared drive, or a marketing lead might build a campaign dashboard that reads from three systems and surfaces performance in one view.
In each case, someone with no formal development background produces working software that touches real customer, financial, or operational data. The build might take an afternoon, but the deployment decides whether the business can safely use it.
Why Enterprise Vibe Coding Is Taking Off
In its June 2026 Build Economy report, Lovable found that 80% of people building on its platform identified as non-technical. These users were creating internal tools, CRMs, inventory systems, HR platforms, e-commerce applications, and other working software. Lovable CEO also said that more than half of Fortune 500 companies now use the platform, with customers including Klarna and HubSpot.
There are primarily four reasons for the shift:
- The tools are free or nearly free to start. A business team can try one on a lazy afternoon without a procurement conversation, a license, or a manager’s sign-off. The barrier to first use is close to zero.
- They’re easy to use. Most run on large language models, so the user writes plain-English prompts and the tool generates a working application in response. If you can describe what you want, you can build it.
- They solve actual business problems. Internal software requests that used to sit in an engineering backlog for months can now be answered in an hour by the person who needed the tool in the first place.
- Everyone else is doing it. Non-technical builders see finished projects on LinkedIn, Reddit, X, and YouTube every day, and the message they take away is that if a marketer or a founder built one over a weekend, they can too.
The trade-off, however, is that these apps are still built without the oversight that normally sits between the request and production, exposing the business to serious risks.
Key Risks and Considerations of Enterprise Vibe Coding
You can use vibe coding to create some amazing stuff, but doing so safely is a completely different ball game. Here are potential risks and considerations of enterprise vibe coding:
1. The App Runs Somewhere IT Doesn’t Control
The first question with any vibe-coded app is where it actually runs. In many cases, the answer is outside the infrastructure IT manages.
Many vibe-coding platforms make external hosting the easiest next step, allowing users to publish an app without first bringing it into the company’s approved infrastructure or deployment pipeline. A user can publish the finished app to:
- The platform’s own hosting environment
- A public cloud service such as Vercel, Netlify, or Fly.io
- A personal or departmental cloud account that IT doesn’t monitor
Since the app sits outside sanctioned infrastructure, IT can’t assume that its normal controls apply. The app may lack the organization’s required network policies, resource quotas, identity provider, centralized logging, vulnerability scanning, or central shutdown controls.
If the app is misconfigured, compromised, or abandoned, the security team may only discover it after an incident.
2. The Code Has Vulnerabilities and Too Much Access
The second problem is what the code itself does once it’s running. AI coding tools can generate functional software without consistently applying secure development practices. Unless the output goes through established review, testing, and Kubernetes security scanning, insecure patterns can move straight into production.
Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities, most commonly cross-site scripting and log injection.
Access is the other half of the risk. Without an approved deployment process, a vibe-coded app may:
- Store database credentials, API keys, or service tokens insecurely
- Use over-scoped tokens that grant more access than the app needs
- Connect to internal systems without a documented least-privilege review
This combination is what makes the risk serious. A flaw in a simple marketing dashboard could expose the customer, financial, or operational data that the app was designed to access.
3. Nobody Knows the App Exists, and Nobody Can Audit It
The third failure mode is a lack of visibility. Vibe-coded apps often sit outside the corporate application inventory, centralized logging, change-management process, and ownership model, even when they process real customer, financial, or operational data.
IBM’s 2025 Cost of a Data Breach Report found that one in five organizations had experienced a breach involving shadow AI. Organizations with high levels of shadow AI also faced breach costs averaging $670,000 more than those with little or no shadow AI.
Ungoverned enterprise vibe coding can extend this same problem from AI tool usage to application development and deployment. IT may not know who built the app, where it runs, what systems it connects to, what data it processes, or whether anyone is still responsible for maintaining it.
This creates a serious audit and compliance gap. Depending on the industry and the data involved, frameworks such as GDPR, HIPAA, and SOX can require organizations to demonstrate where regulated data is stored, who can access it, how it is processed, and which controls protect it. An application that sits outside the inventory makes this evidence much harder to produce.
Why Your Existing Security Stack Might Need Revisiting
Enterprise teams already run tools for code scanning, data protection, and cloud oversight. These controls are still valuable, but they only work when the application enters the repositories, accounts, networks, and deployment processes they monitor.
Vibe-coded apps can bypass this coverage by running in vendor-hosted environments, personal cloud accounts, or workflows that never touch the company’s approved software-delivery pipeline.
These tools only provide coverage once an application enters the repositories, accounts, networks, and deployment processes they monitor. Vibe-coded apps that bypass those systems can remain outside normal security and governance controls.
Moving the app to a managed cloud host or vendor runtime doesn’t necessarily close this gap. For organizations with data-residency requirements, on-premises or air-gapped obligations, or auditors who expect infrastructure-level control, the deployment may still sit in a third-party environment the organization doesn’t fully govern.
Business builders need a governed deployment path onto the infrastructure that the organization already operates.
How to Govern Enterprise Vibe Coding Safely
Governing enterprise vibe coding means putting a deployment layer between the builder and production, one IT configures once, and every AI-built app has to pass through.
Here’s what this looks like in practice.
1. The App Deploys Onto Infrastructure the Organization Already Controls
Vibe coding platforms default to their own hosting or a personal cloud account, and once the application is running there, none of the organization’s controls reach it. A governed path routes every deployment onto the Kubernetes clusters the organization already runs, whether those clusters sit in the corporate cloud tenancy, an on-prem data center, an edge site, or an air-gapped environment.
This is the design behind Portainer-Run and Portainer Business.
Portainer-Run is the self-service portal the builder uses, whereas Portainer Business is the operator control plane over the organization’s sanctioned clusters. The builder describes what they want to deploy in Portainer-Run. It generates the Kubernetes manifest, commits the source and manifest to a sanctioned Git repository, and triggers the deployment. Portainer Business reconciles the workload into the cluster and namespace that IT has designated.
The builder doesn’t see the cluster, doesn’t touch infrastructure, and doesn’t pick where the app runs. IT has already made the decision on their behalf.
{{article-cta}}
2. Access Is Bound by Policy
In an ungoverned deployment, the builder or the AI tool picks the credentials, the API tokens, and the database access, usually by hardcoding whatever works first. This decision shouldn’t belong to the builder in the first place.
Portainer’s model handles access through four controls that IT configures once:
- Scoped personal access tokens. The builder’s identity is bound to a token that authorizes deployment through Portainer-Run and nothing else. It replaces the need for a kubeconfig or direct cluster credentials.
- Centrally managed RBAC. Access inside the resulting namespace is governed by Portainer’s RBAC, configured in Portainer Business by IT.
- Resource quotas and namespace isolation. Both are set at the cluster level and enforced automatically at deploy time.
- IT-scoped secrets for every credential. If the app needs a database connection or an external API key, it draws from a secret IT scoped in advance. Nothing gets hardcoded by the AI tool or pasted in by the builder.
3. Every App Is Visible, Auditable, and Reversible
Compliance and security teams can’t defend what they can’t see, and they can’t audit what doesn’t leave a record. A governed deployment path has to guarantee three things:
- A central inventory. Every vibe-coded app in the organization appears in one place, queryable by IT and security.
- A complete audit record. Every deployment writes to a log tied to the builder's identity and the commit that produced it.
- One-click rollback. IT can undo a bad deployment without depending on the builder to know what to revert.
Under Portainer-Run, the commit-before-deploy flow enforces all three. Nothing reaches a cluster without first appearing as a commit in the sanctioned Git repository, which becomes the system of record. This follows a standard GitOps pattern. Portainer Business exposes the audit trail and the rollback action to the security team.
Ownership also becomes durable. When an employee changes roles or leaves the business, the vibe-coded app they built stays as standard source code in Git and a standard Kubernetes workload. IT can reassign it, update it, or retire it without needing the original builder to recreate anything.
Your Enterprise Vibe Coding Security Checklist
If you’re an IT or security leader trying to bring enterprise vibe coding under control, use this checklist to move from scattered AI-built apps to a governed environment.
Establish Visibility
Reduce Exposure
Sustain Governance
Work through the list top to bottom, and enterprise vibe coding moves from an ungoverned risk into a managed part of how your business builds software.
{{article-cta}}
Bring Enterprise Vibe Coding Under Control with Portainer
Enterprise vibe coding isn’t going away. Business teams will keep building, and the number of AI-generated apps running in production will only grow. What changes the security posture, however, is a deployment path in which IT retains control of the infrastructure while builders maintain their speed.
This is what Portainer-Run and Portainer Business do together. Portainer-Run gives non-technical builders a self-service portal to deploy AI-built apps, whereas Portainer Business keeps IT in control of the sanctioned clusters, RBAC, and audit trail underneath. You get enterprise-grade governance without standing up a bespoke deployment platform or expanding the team to run it.
And since Portainer Business is vendor-agnostic, that governed path runs on any Kubernetes distribution across cloud, on-premises, and edge, so bringing business-built apps under IT control doesn't lock the organization into a single provider’s platform.
Want to see how a governed enterprise vibe coding path works on your own Kubernetes? Schedule a demo with our technical sales team today.
FAQs
1. Can you deploy vibe-coded apps on-premises or in an air-gapped network?
Yes. A governed deployment path can route AI-built apps onto whichever Kubernetes clusters the organization runs, including on-prem data centers and air-gapped networks. Portainer Business connects to those sanctioned clusters, and Portainer-Run gives builders a self-service portal to deploy into them.
2. Do business users need to know Kubernetes to deploy an AI-built app safely?
No. A well-designed governance layer handles the technical work behind the scenes, so business users can deploy an app without touching kubectl, YAML, or the cluster itself. Portainer-Run generates the manifest and the Git commit, and Portainer Business reconciles the workload into the sanctioned cluster.
3. Is enterprise vibe coding the same as low-code or no-code development?
No. Low-code and no-code tools assemble apps from visual blocks, whereas vibe coding uses AI to generate real, running source code from natural-language prompts, which changes both what’s produced and how it needs to be governed.
4. Does a governed deployment path replace the platform engineering team?
No. Platform teams still design the clusters, RBAC model, and policies underneath, in the same pattern used by an internal developer portal. What changes is that they configure the guardrails once and let business builders deploy inside them, rather than reviewing every request individually.
5. How do you build a self-service Kubernetes deployment experience without creating security problems?
Put a deployment layer between the builder and the cluster that IT configures once. Bind access to identity through SSO rather than shared credentials, scope every deployment to a namespace with quotas and network policies set in advance, and commit every deploy to a sanctioned Git repo so the audit trail and rollback path are handled automatically. Portainer-Run provides a self-service portal for non-technical builders, while Portainer Business enforces RBAC, admission policies, and the sanctioned Git flow underneath, so IT sets the guardrails once, and business builders deploy within them.
