From vibe coding to vibe deployment: Closing the prototype-to-production gap

In February 2025, Andrej Karpathy coined the term “vibe coding” with a tweet that instantly resonated across the developer community. The idea was simple yet powerful: instead of writing code line-by-line, you describe what you want in natural language, and an AI model scaffolds the entire solution. No formal specs, no boilerplate grind, just vibes.

Vibe coding quickly gained traction because it removed the friction from starting a project. In minutes, developers could go from a vague product idea to a working prototype. It wasn’t just about speed, it was about fluid creativity. Teams could explore ideas without committing weeks of engineering time. The viral demo, like the one Satya Nadella did and various experiments, reinforced the feeling that AI-assisted development wasn’t just a curiosity; it was a glimpse into the future of software creation.

But even in those early days, there was an unspoken reality: while AI could “vibe” out an MVP, the leap from prototype to production remained a formidable gap. That gap would soon become the central challenge for the next evolution of this trend.

The Hard Part: Why Prototypes Rarely Survive Contact with Prod

Vibe coding excels at ideation speed but struggles at deployment rigor. The path to production isn’t a straight line; it’s a maze of choices, constraints, and governance.

A typical production deployment forces teams to make dozens of decisions:

• Language and runtime versions – not all are equally supported or approved in your environment. For example, your org may only certify Java 21 and Node.js 18 for production, but the agent picks Python 3.12 with a new async library that ops doesn’t support yet.
• Infrastructure choices – Kubernetes? Serverless? VM-based? Each has its own scaling, networking, and security model. A prototype might assume AWS Lambda, but your preferred cloud provider is different. The choice of infrastructure will change the architecture as well.
• Third-party integrations – Most of the solutions will need to be integrated with third-party systems via means like APIs, webhooks. There will be multiple such third-party systems to get one task done and that single selected system will have multiple API versions as well, which will differ significantly in functionality, authentication flows, and pricing.
• AI model usage – not every model is approved, and cost or privacy rules can limit choices. A developer might prototype with GPT-4o via a public API, but the organization only allows an internally hosted model for compliance and privacy reasons.

This combinatorial explosion overwhelms both human developers and AI agents. Without constraints, the agent might produce an architecture that’s elegant in theory but incompatible with your production environment. Without guardrails, it may introduce security gaps, performance risks, or compliance violations that surface only after deployment.

Operational realities, uptime SLAs, cost budgets, compliance checks, change management require deliberate engineering discipline. These aren’t things AI can guess; they have to be encoded in the system it works within.

The result? Many vibe-coded prototypes either stall before deployment or require a full rewrite to meet production standards. The creative energy that made the prototype exciting gets bogged down in the slow grind of last-mile engineering.

Thesis: Constrain to Empower — Give the Agent a Bounded Context

The common instinct when working with large language models (LLMs) is to give them maximum freedom, more options, more tools. But in software delivery, this is exactly what causes them to fail.

When an agent has to choose between every possible language, runtime, library, deployment pattern, and infrastructure configuration, it’s like asking a chef to cook a meal in a grocery store the size of a city, too many possibilities, no constraints, and no guarantee the ingredients will even work together.

The real unlock for vibe deployment is constraint. Not arbitrary limits, but opinionated defaults baked into an Internal Developer Platform (IDP):

• A curated menu of programming languages and runtime versions that the organization supports and maintains.
• A blessed list of third-party services and APIs with approved versions and security reviews.
• Pre-defined infrastructure classes (databases, queues, storage) that align with organizational SLAs and cost models.
• A finite set of approved AI models and APIs with clear usage guidelines.

This “bounded context” transforms the agent’s job. Instead of inventing an arbitrary solution, it assembles a system from known-good, production-ready building blocks. That means every artifact it generates, from application code to Kubernetes manifests is deployable on day one. Like providing a well-designed countertop with selected utensils and ingredients to a chef.

In other words: freedom at the creative level, discipline at the operational level.

The Interface: Exposing the Platform via MCP

An opinionated platform is only useful if the agent can understand and operate within it. That’s where the Model Context Protocol (MCP) comes in.

MCP is like the menu interface between your internal developer platform and the AI agent. Instead of the agent guessing: “What database engines are allowed here? Which version of the Salesforce API is approved?” it can ask the platform directly via MCP, and the platform responds with an authoritative answer.

MCP Server will run alongside your IDP, exposing a set of structured capabilities (tools, metadata).

1. Capabilities Catalog – lists the approved options for languages, libraries, infra resources, deployment patterns, and third-party APIs through tool descriptions
2. Golden Path Templates – accessible via tool descriptions so the agent can scaffold new projects with the correct structure, configuration, and security posture.
3. Provisioning & Governance APIs – accessible through MCP tools, letting the agent request infra or run policy checks without leaving the bounded context.

For the LLM, MCP isn’t just an API endpoint; it’s the operational reality of your platform made machine-readable and operable. This makes the difference between “the agent might generate something deployable” and “the agent always generates something deployable.”

In our chef analogy, MCP is like the kitchen manager who hands over the pantry map and the menus to the chef, through which the chef learns the ingredients and utensils available to him so that he will not try to make wood-fired pizza with a gas oven.

Reference Architecture: “Prompt-to-Prod” Flow

Based on the above combination of above thesis and interface sections, we can arrive at a reference architecture for vibe deployment. The reference architecture for vibe deployment is a five-step framework that pairs platform opinionation with agent guidance:

1. Inventory & Opinionate

• Choose blessed languages, versions, third-party dependencies, infrastructure classes (databases, queues, storage), and deployment architectures(VM, Kubernetes).
• Define blueprints, templates and golden paths which bundle the above curated inventory and offer opinionated experiences. These will be abstractions that your business platform will use, like backend components, web apps, and tasks. Golden path will be a definition that says for backend services use Go version 10 with MySQL database.
• Clearly document what’s in scope and off-menu so both humans and agents operate within the same boundaries.

2. Build / Modify the Platform

• Adapt your internal developer platform to reflect these opinionated decisions. This will include adding new infrastructure and services to make available the opinionated resources. If you decide on lang version 10 then this means having proper base images in container registries. If you decide on a particular third party dependency then this means having a subscription and keeping that subscription information in your configuration stores or key vaults.
• Bake in golden-path templates, pre-configured infrastructure definitions, and built-in governance checks. Implement the defined blueprints and golden paths using the newly added platform capabilities. This would include integrating earlier added infrastructure and services through kubernetes manifests, helm charts in a way to provide curated experience

3. Expose via MCP Server

• Once the platform is available, it’s about implementing the interface. This interface should be self-describable and machine-readable. Characteristics that clearly suit MCP.
• Expose capabilities that highlight opinionated boundaries — from API versions to infrastructure limits — so the agent has a bounded context to operate in. Capabilities should be self-describable and machine-friendly as well. This will include well-thought-out tool descriptions that agents can use to make better decisions.

4. Refine and Iterate

• Test the prompt-to-prod flow with real development teams. Iteration is what makes all this work. Given the composition of the platform differs there is no golden rule. It is about testing and improving the tool descriptions.
• Fine-tune MCP tools based on feedback. Based on the feedback received on testing, keep changing tool descriptions and at times will require API changes as well. This may even require a change of opinions that are too rigid.

5. Vibe Deploy Away!

• With the foundation set, teams can move seamlessly from vibe coding to production deployment with a single prompt.
• Monitor outcomes to ensure that speed gains do not erode reliability or maintainability.

What to Measure: Proving It’s More Than a Demo

The danger with hype-driven trends is that they work beautifully in demos but collapse under the weight of real-world constraints. Vibe deployment avoids that — but only if you measure the right things.

The ‘why’ here is simple: if we don’t track outcomes, vibe-coded apps could quietly introduce maintenance headaches and drag out lead times just like any rushed project. Guardrails are only useful if we know they’re holding.

So what do we measure?

• Lead time for changes — Are we actually delivering faster after the first release, not just for v1?
• Change failure rate — Are we keeping production stability even as we speed up?
• MTTR (Mean Time to Recovery) — When something breaks, do we recover quickly?
• Infra cost per service — Are we keeping deployments cost-efficient and predictable?

These metrics tell you whether vibe deployment is delivering sustained value or just front-loading the development cycle with speed that you pay for later in technical debt.

For platform leaders, this is a call to action:

• Stop thinking of opinionation as a limitation; start treating it as the enabler for AI-powered delivery.
• Encode your best practices, compliance rules, and architectural patterns into the platform itself.
• Measure relentlessly to ensure that speed doesn’t erode stability.

The future of software delivery isn’t “prompt to prototype.” It’s prompt to production — without skipping the engineering discipline that keeps systems healthy. The tools exist. The patterns are here. The only question is whether you’ll make the leap.