What vibe coding is, and what it is not

The term was coined in February 2025 by Andrej Karpathy, a founding engineer at OpenAI, to describe building software by describing what you want to an AI model and accepting what it produces, to the point where one can "forget that the code even exists". Collins Dictionary named it its word of the year for 2025.

In practice, the label now covers a spectrum. At one end, a business analyst describes an app in plain language and an AI tool generates and runs it, with nobody reading the code. At the other end, an experienced engineer uses AI agents to write most of the code but still reviews, tests and owns every change. For enterprises, the useful distinction is not whether AI writes the code, but whether anyone accountable understands, checks and maintains what goes into production.

Where it genuinely helps

Prompt-driven development is well suited to work where speed of learning matters more than durability:

  • Prototypes and proofs of concept. Teams can test an idea with users in days, then decide whether it deserves a proper build.
  • Internal tools with limited scope. Reporting screens, data clean-up scripts and workflow helpers that touch non-sensitive data and few systems.
  • Exploration of unfamiliar technology. Engineers can get a working starting point in a new framework or API, then refine it.
  • Clearer requirements. A clickable prototype often communicates intent better than a long specification, which can reduce misunderstandings between business and IT.

The common thread is a short life, a small blast radius and a human who decides what happens next.

Where the risks sit

The same speed that makes vibe coding attractive also moves risk downstream.

Security. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that 45% of the generated code samples introduced a known security weakness from the OWASP Top 10, the standard list of critical web application risks. Veracode also reported that newer and larger models were not meaningfully better at security, even as they improved at writing code that runs.

Software supply chain. A study presented at USENIX Security 2025 analysed 576,000 code samples from 16 models and found that 19.7% of the software packages they recommended did not exist. Attackers can register such invented names with malicious code, so an unreviewed dependency list becomes an entry point.

Maintainability and technical debt. Code nobody has read is code nobody can safely change. Generated applications often duplicate logic, ignore existing platform services and skip tests, which raises the cost of every later change.

Intellectual property and licensing. AI suggestions can resemble existing public code. Some tools offer controls for this; GitHub Copilot, for example, can block suggestions that match public code or show the matching repositories and their licences. Whether and how to use such controls is a decision for your legal and procurement teams.

Governance and shadow IT. When anyone can build an application in an afternoon, applications appear outside the portfolio, without owners, access reviews or backup. Data can flow to AI services that have not been assessed.

Speed is not the same as productivity

Leaders should be careful with productivity claims. In a randomised trial published in July 2025, the research group METR found that 16 experienced open-source developers took 19% longer on real tasks when allowed to use early-2025 AI tools, while believing they had been about 20% faster. METR has since said those results are out of date and that developers are likely faster with newer tools, but that its follow-up data is too affected by selection effects to measure by how much.

Google's 2025 DORA report, based on nearly 5,000 technology professionals, offers a more useful framing: AI amplifies what is already there. It found that 90% of respondents use AI at work and more than 80% believe it has increased their productivity, while 30% report little or no trust in AI-generated code. AI adoption was associated with higher delivery throughput but also with lower delivery stability, and teams with strong testing, version control and fast feedback benefited most.

The lesson for executives is that the return depends less on the tool than on the engineering system around it.

Guardrails: an architecture view

Treat AI-generated code as untrusted input until it passes the same controls as any other change. In architectural terms, that means:

  • Tiers by risk. Define where prompt-driven building is allowed without review (personal experiments, sandboxes), where it needs light review (internal tools on non-sensitive data) and where full engineering standards apply (customer-facing, regulated or integrated systems).
  • Sandboxed environments. Give citizen developers and prototypes isolated environments with synthetic or masked data, no production credentials and limited network access.
  • Paved roads. Offer approved templates, authentication, logging and data access services so generated applications reuse platform capabilities instead of reinventing them.
  • Automated checks in the pipeline. Static analysis, dependency and licence scanning, secret detection and test coverage gates should run on every change, whoever or whatever wrote it.
  • Clear ownership. Every application that leaves the sandbox needs a named owner, an entry in the application portfolio and a decision on support and retirement.
  • Approved tools and data rules. Decide which AI coding tools may be used, under which contracts, and what code or data may be sent to them.

Existing frameworks help. The US National Institute of Standards and Technology (NIST) Secure Software Development Framework and the OWASP Top 10 for large language model applications give a shared vocabulary for these controls.

A practical adoption path

  1. Start with an inventory. Find out which AI coding tools are already in use and where generated applications already run.
  2. Publish a short policy. State the risk tiers, approved tools, data rules and the definition of "production".
  3. Pilot in two lanes. Use one lane for business-led prototypes in a sandbox and one for engineering teams using AI agents under normal review.
  4. Measure outcomes, not output. Track lead time, change failure rate, defects and security findings, not lines of code or the number of apps created.
  5. Define the graduation path. Agree what a prototype must pass (security review, tests, ownership, architecture fit) before it becomes a supported system, and when it should be rebuilt instead.

Practical takeaways

  • Vibe coding is a useful accelerator for learning and prototyping, not a replacement for engineering discipline.
  • Independent research shows real security and supply-chain risks in unreviewed AI-generated code.
  • Productivity gains depend on testing, version control, platforms and clear ownership already being in place.
  • Risk tiers, sandboxes, paved roads and automated pipeline checks let enterprises gain speed without accumulating hidden debt.
  • Decide on tools, data and IP controls before adoption spreads, not after.

Further reading

Facing a similar architecture decision?

An introductory conversation can help clarify options and risks. No obligation and no requirement to share assessment results.

Request an introductory discussion ↗

← All articles