GLM-5.2 - Fine-tune and deploy your own instance (Sponsored)
GLM-5.2 is Z.ai’s flagship long-horizon coding model, featuring a usable 1M-token context window that reliably maintains API contracts and engineering intent where others fail. Stop managing GPU clusters. With Crusoe Serverless Fine-Tuning, you customize GLM-5.2 on your proprietary data in a tenant-isolated environment—no data sharing, no infrastructure overhead. When your job finishes, deploy to Self-Serve Deployments in one click or download raw .safetensors weights for full portability. Every run is reproducible, auditable, and fully yours. No lock-in. No guesswork. Experience production-grade, customized performance without the DevOps burden.
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?
Here’s what we will cover:
Why does cheap code generation move the hard engineering problem to another place, and how does that impact the platform’s overall value?
GitHub’s orchestration bet, built on ephemeral cloud environments and a control layer that routes work across competing agents.
Vercel’s production bet, built on isolated microVM sandboxes and a billing model matched to how agents actually run
Replit’s verification angle, built on a self-testing loop that drives a real browser to catch code that only looks like it works
How the MCP standard lets any agent reach any tool, and why all three companies now support it
How Stripe turned payments into something an agent can set up from inside a coding tool, and the credential design that keeps it safe
Disclaimer: This post is based on publicly shared details from various sources. References at the end. Please comment if you notice any inaccuracies.
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
GitHub gives us the clearest place to start, because it deals with the pull request workflow most developers already use.
[Webinar] Can you prove AI is working? (Sponsored)
AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.
Join live on Aug 19 (FREE) to learn:
The 4 metrics to measure where AI gains leak out before production.
The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is
Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.
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 [1][2]. 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 [1]. Each cloud run happens in a fully isolated, single-use Linux environment hosted by GitHub. Every new task starts from a clean workspace [4]. The review step stays human, which keeps the existing quality gate intact.
See the diagram below:
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 [3]. The agents available inside a paid Copilot subscription include ones from Anthropic, OpenAI, Google, Cognition, and xAI [3].
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 [3].
See the diagram below:
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.
Let us now look at how Vercel developed its architecture around what happens after the code exists. This is somewhere between a working demo and production-ready software.
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 [5].
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 [5].
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 [5]. Therefore, wrapping code generation in real deployment controls is the right response.
See the diagram below:
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 [6][7]. 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.
Nevertheless, strong isolation carries a cost per unit of compute. There is an open question about whether the heaviest workloads eventually move to cheaper execution options elsewhere. Vercel’s wager is that a single, convenient platform keeps them in place.
To summarize, GitHub owns the workflow, and Vercel owns the route to production. Both of them still depend on one assumption that Replit chose to attack directly. Let us look at that now.
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 [8]. 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 [9].
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 [9]. 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 [8][9].
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 [9]. 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 [9].
See the diagram below:
Anyone who has shipped a feature that looked finished and later broke understands the problem here. Replit is trying to automate the check that catches exactly that, so that the automation can be trusted.
A verification loop reduces the risk substantially. Some failures still surface only under conditions a single test session might miss, which keeps this a pretty hard problem even with a capable tester in place.
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. In this approach, the number of integrations grew quickly as both sides multiplied. 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 [10].
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 [11]. 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 [11].
Replit was among the earliest developer tools to integrate MCP [10], GitHub added an MCP registry to VS Code where a server can be enabled with a single click [3], and Stripe runs an official MCP server for its payment operations [12].
Going deeper, MCP also standardizes how agents reach existing APIs rather than replacing those APIs. A single shared entry point also concentrates security in one place. That makes careful control over which servers an agent may use an important part of any real deployment.
Tradeoffs
Each of these architectures and approaches has trade-offs:
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 (code that looks complete yet fails when used) stays difficult even with a capable tester, because some failures appear only in situations a test session might miss.
MCP gains a clean, reusable way to connect agents and tools, and a shared standard also concentrates risk into a common entry point. When many agents reach many tools through one protocol, controlling which servers an agent may use, and their permission levels, becomes a central problem rather than a detail.
Understanding these costs is what separates picking one of these tools from understanding why it was built the way it was.
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.
References:
It looks like AI generated content. I don't know why include stripe to this article
As usual insightful write-up.