GitHub vs Vercel vs Replit: What Dev Platforms Do When AI Code Is Cheap

AI models have solved the writing code part of software development to a great extent. Today, a capable model can produce a working function, a full component, or a small application from a plain-language description. It can do so in seconds for a fraction of the cost.

This change has shifted the economics of every developer platform. As the generation of new code becomes cheaper and widely available, it stops being the differentiating factor for a platform. This is the reason GitHub, Vercel, and Replit are trying to rebuild themselves around solving other hard problems in the software development process.

To understand what the three companies are doing, we trace one unit of work through every platform while asking the same questions:

• Where does the AI actually run the code it writes?
• How does each platform verify that the code works?
• How does the finished product reach production, and who is permitted to ship it?

Commoditization

A language model can now turn a description into working code. This means a developer can write a sentence and receive a function, a page, or a small application that actually runs right out of the gate.

This capability used to be the scarce and valuable part of a developer tool. Today it is widely available and close to free, which leaves a platform that offers only generation with little to charge for.

So what matters now is not raw code generation, but aspects of software development that come up after the code is available. Three questions carry most of the weight now:

• Where does the agent run the code it produces, and how is that environment kept safe?
• How does the platform confirm that the generated code actually works?
• How does the result reach production, and who is allowed to ship it?

GitHub, Vercel, and Replit answer these questions in different ways.

• GitHub puts its effort into coordination
• Vercel into the path to production
• Replit into verification

Orchestration

GitHub made a specific choice about where the value sits.

Rather than building its own model and competing on raw generation, it built a control layer that coordinates many agents and keeps their work governed, all inside the pull request workflow that developers use every day.

The mechanics start with where the code runs.

GitHub’s coding agent operates in its own ephemeral development environment, which is a temporary workspace that exists only for that task. It is powered by GitHub Actions, the same automation system that runs tests and builds on the platform. In practice, you assign a task to the agent the way you would open a ticket. The agent reads through the repository, edits files, runs the tests and linters (tools that check code for problems), and opens a draft pull request for a person to review. Each cloud run happens in a fully isolated, single-use Linux environment hosted by GitHub. Every new task starts from a clean workspace. The review step stays human, which keeps the existing quality gate intact.

A single agent sits above the coordination layer. GitHub calls it Agent HQ. It introduces a mission control view that lets a developer assign, steer, and approve work across a fleet of agents from GitHub and VS Code. The agents available inside a paid Copilot subscription include ones from Anthropic, OpenAI, Google, Cognition, and xAI.

Governance is treated as version-controlled configuration. Teams define custom agents through AGENTS.md files that carry rules such as a preferred logger or a required testing style, and a control plane gives administrators security policies, audit logging, and model-access controls in one place.

For developers who are already accustomed to handling issues and pull requests, this design adds agents to a pretty familiar workflow. Reviewing a colleague’s branch is not so different from reviewing an agent’s branch.

Routing to other companies’ models is a deliberate decision. GitHub is positioning the workflow, the execution environment, and the governance layer as the durable product, and treating the underlying model as a swappable component.

Production

Vercel starts from a different premise where code generation is assumed, and the design deals with carrying the generated code into production. This is the stage where most enterprise software work actually happens, because it involves existing applications rather than fresh prototypes.

The rebuilt version of v0, Vercel’s generation product, runs on a sandbox. It is an isolated space for executing code that imports a real GitHub repository and automatically pulls in the project’s environment variables and configuration. Every prompt produces code that fits the actual application and lives in the repository itself.

A Git panel handles the workflow around it. You create a branch for each chat, open a pull request against the main branch, and deploy when it merges. This means a product manager or a designer can ship through the same review process an engineer uses.

Vercel’s rationale about this approach is that AI-assisted building is already happening inside companies, and it has produced real failures. Incidents have been reported, such as credentials pasted into prompts, private data reaching the public internet, and deleted databases, often with the audit trail left empty. Therefore, wrapping code generation in real deployment controls is the right response.

Underneath the workflow is the execution layer. Every sandbox runs inside a Firecracker microVM, a lightweight virtual machine that isolates untrusted code. The reason for this isolation is that the code an AI wrote is code you have yet to review. Therefore, running it needs a boundary strong enough to contain mistakes. A microVM provides that strong boundary.

The billing model depends on how agents actually run. Vercel’s Fluid compute lets several requests share one running instance, with one using the processor while another waits on input or output. It charges for active processor time while treating wait time as free. Agentic workloads spend much of their time waiting on a model to respond, so this pricing matches the real work being done.

This approach deals with a frustration many developers face in their careers. The thing that worked in a demo behaves differently in production. However, Vercel’s design tries to close that gap by making the preview a real deployment from the start.

Verification

Replit concentrated its work on whether autonomously generated code genuinely works using a verification loop built into the agent itself.

Replit’s Agent 3 runs what the company calls a reflection loop. The agent generates code, runs it, tests the result, and repairs failures, repeating that cycle until the tests pass. This loop is reliable because of how the testing is done. Replit built a REPL-based verification system that runs code immediately and pairs that execution with a real browser it drives automatically, so it can click buttons, submit forms, and check data the way a user would.

The specific problem this approach targets has a memorable name inside Replit: the Potemkin interface. It is basically a feature that looks complete on screen yet fails the moment it is used. Catching that class of error is what allows the agent to run on its own for more than 200 minutes at a stretch, a large increase over the roughly 20 minutes of its predecessor.

The verification runs as its own process. A testing subagent follows a simple cycle of taking an action, observing the result, and repeating. When it finishes, it returns a summary to the main agent describing what works and what broke. This multi-hundred-step testing costs a median of roughly twenty cents per session and runs several times faster and more cheaply than relying on general-purpose computer-use models.

Interoperability

Every architecture we have looked at assumes its agent can reach tools and data that live outside the model, and doing that cleanly requires a common method. That method is the Model Context Protocol, usually shortened to MCP.

Before a standard like this existed, connecting several AI applications to several external tools meant writing a separate custom integration for each pairing. Anthropic introduced MCP to replace those fragmented, one-off connections with a single protocol, so each application and each tool implements the standard once and then works with everything else without additional changes.

A host, which is the AI application such as an IDE or a chat client, creates one or more clients, and each client connects to a server that exposes some capability. A server offers three kinds of capability:

• Tools, which the model can call to take an action, such as creating a record or running a query.
• Resources, which supply context data the model can read, such as a file or a database schema.
• Prompts, which provide reusable instruction templates.

The whole exchange runs over a defined message format across either a local or a remote connection. The effect is that a tool provider builds one MCP server and every compliant agent can use it.

Replit was among the earliest developer tools to integrate MCP, GitHub added an MCP registry to VS Code where a server can be enabled with a single click, and Stripe runs an official MCP server for its payment operations.

Tradeoffs

• GitHub gains breadth and governance by routing to many vendors’ models. But the cost is that it owns the surface rather than the intelligence underneath. Whether a coordination and governance layer stays valuable as models and agents keep changing is an open question.
• Vercel gains strong isolation by running generated code inside microVMs, and that isolation carries a cost per unit of compute. There is a question about whether the heaviest workloads eventually move to cheaper execution elsewhere
• Replit gains long stretches of autonomy through its verification loop, and the more work an agent does on its own, the more weight rests on that verification being right. The Potemkin problem stays difficult even with a capable tester, because some failures appear only in situations a test session might miss.

Conclusion

The pattern across all three companies is the same. Code generation became cheap, so the value moved into the engineering that surrounds it. Each company placed its bet on a different piece of that surrounding work.

GitHub bet on orchestration, building a control layer that runs and governs many agents inside the pull request workflow developers already use.

Vercel bet on production, wrapping generated code in real deployments and running it inside isolated microVMs built for untrusted code.

Lastly, Replit bet on verification, driving a real browser in a self-testing loop so an agent can work on its own for hours and still be checked.

Underneath all three, MCP provides the common protocol that lets any agent reach any tool, which is why every one of these platforms now supports it.