Vibe coding in the enterprise: how to govern AI-assisted development
The term jumped into the conversation in early 2025 and has not stopped since. Andrej Karpathy popularised “vibe coding” as a way of programming by going with the flow of the AI, accepting its suggestions almost without reading them, flowing with the model. In a personal notebook, it sounds fine. In a company, it opens a serious debate. Hence this practical guide on vibe coding in the enterprise.
In this guide
My position is direct. Vibe coding, well channelled, is the biggest productivity gain IT has seen in a decade. Badly channelled, it is hidden technical debt, secret leaks and loss of control over what runs in production. The difference between one scenario and the other lies in governance, not in the model.
What vibe coding in the enterprise is and why it has become inevitable
Vibe coding in the enterprise is the development practice where the programmer interacts with an AI assistant (Claude Code, Cursor, GitHub Copilot, Windsurf) to generate large blocks of code from natural-language prompts, reviewing them at a high level and letting the AI iterate on the detail. Delivery speed multiplies, but responsibility for the result remains human.
The reason it is inevitable is competitive. Companies that adopted AI assistants in 2024 report reductions of 30-50% in delivery time for comparable features. If your organisation does not join that curve, its competitors will build a two-year lead in a matter of quarters. The sensible thing is to enter, but to enter with a safety net.
Real risks that appear in production
In vibe coding in the enterprise, the first risk is invisible technical debt. AI produces code that works, but not always consistent with the project’s architecture. When it accumulates without architectural review, you end up with five different ways of doing the same thing within your codebase. The second is security: badly written prompts can leak secrets to the model or generate dependencies with known vulnerabilities.
The third risk is regulatory. The EU AI Act requires documenting the use of AI in significant processes and, in regulated sectors, that includes the development of critical software. This connects directly with preventing Shadow AI in the company: if developers use AI assistants outside the corporate policy, there is no way to audit or to assume responsibility.
Practical governance: how to make the most of it with a safety net
To govern vibe coding in the enterprise, the first step is to centralise access. A single AI assistant platform per organisation, with SSO, per-project access control and usage telemetry. The second is to define an internal code of ethics: what information can be pasted into a prompt, what is considered sensitive data, what type of code is always reviewed by a human before merging.
The third step is the repository rules. Automated tests on the generated code, specific linters to detect AI antipatterns, mandatory architect review on critical modules. That connects with risk management in IT projects with GenAI, where fast delivery coexists with serious controls.
Changes in the role of the developer and the project manager
With vibe coding in the enterprise, the developer moves from writing every line to acting as a senior editor. Their value lies in knowing what to ask for, how to verify it and when to be sceptical. That raises the technical bar: a pure junior falls behind if they only accept what the AI suggests; a junior with judgement grows faster than ever. Companies that understand this will adjust their technical career paths accordingly.
For the project manager, the change is also important. Traditional story-point estimates stop making sense when AI speeds up mechanical tasks and leaves the team focused on design decisions. The planning conversation shifts towards risks, dependencies and quality, not capacity. It is exactly the direction I advocate in my approach as an AI Project Manager.
Frequently asked questions about vibe coding in the enterprise
Vibe coding in the enterprise is software development where the programmer works with generative AI assistants to produce large blocks of code from natural-language prompts. The review is done at design level and the final responsibility remains human.
The most widespread are Claude Code, Cursor, GitHub Copilot, Windsurf and Aider. What is critical is not the tool, but the governance model: corporate SSO, usage telemetry, per-project access control and clear policies on what data can be sent to the model.
Only if the tool is under corporate control and the contract with the provider guarantees that the prompts are not used to train models. It is wise to separate environments: public assistants for non-sensitive code and a dedicated corporate assistant for modules with confidential or regulated data.
Mature organisations report reductions of 30-50% in delivery time for comparable features. The gain is real, but it only holds if it coexists with architectural review and automated testing, because AI produces code that works, not necessarily code consistent with the architecture.
The EU AI Act requires documenting the use of AI in significant processes. In critical software development (banking, healthcare, infrastructure), that means recording which tool was used, which prompts were sent and how the result was validated. The internal policy must align with those requirements before generalising use.
A programme to run with little margin for error? See how I have done it.
See the nine case studies