AI Software Factories at Ramp, Uber, OpenAI & Vercel (2027)

Ramp, Uber, OpenAI and Vercel now ship a large share of their code through background coding agents. Tickets go in, agents write code in sandboxes, and humans review and merge the pull requests. This guide explains how each company runs its AI software factory, using only figures they have reported publicly. It covers what all four setups share and where factories break. It also gives a step-by-step method for feeding customer evidence into the factory so agents build what customers asked for. That last gap is the one BuildBetter was built to close: connecting the calls, tickets and Slack threads that explain why to the agents that decide how.

What Is an AI Software Factory?

An AI software factory is a repeatable system where coding agents take scoped work (usually tickets), write code in isolated sandboxes, open pull requests, and hand them to a human who reviews and merges. The human role shifts from writing code to specifying it and reviewing it.

A factory is different from autocomplete or a chat-based coding assistant. Those tools help one developer at one keyboard, one suggestion at a time. A factory runs in the background and in parallel. It pulls work from a queue and produces mergeable PRs without a developer typing for each one. One engineer might have five agents working on five tickets while they review the output of the previous batch.

Every AI software factory has three moving parts:

• Intake: tickets or tasks that define the work. The ticket is the specification.
• Execution: agents running in sandboxes with repository context, writing and testing code.
• Gate: human review and merge. Nothing reaches production without a person approving it.

The thesis of this article in one sentence: every factory described here automates HOW code gets written, and none of them decides WHAT to build. That decision still depends on customer evidence, and most factories never receive it.

For a deeper look at one company's full setup, read our breakdown of Ramp's AI product factory and internal tools.

How Ramp, Uber, OpenAI and Vercel Build With Agents

All four companies run agentic coding at production scale, and all four keep a human at the merge gate. The table below summarizes what each has reported. The first row shows where a customer evidence layer fits, because none of the four coding systems handles that input on its own.

Two Ramp numbers often get blended, and they measure different things. The 30% figure is a share of merged PRs written by Inspect. The 50% figure is a share of the codebase, and it came from an executive speaking on a podcast, not an audited metric. Uber's numbers show a similar gap between usage and output. Almost every developer uses agents, but agents open about one PR in nine.

Ramp's business context explains why its approach gets so much attention. On October 15, 2026, Ramp was valued at $60B after a $1.85B round led by Dragoneer, up from $44B in June 2026, with about $2B in annualized revenue (Tech Insider).

Ramp is also the only one of the four that built an agent for the input side of the factory. Its Voice of the Customer agent analyzes customer feedback and helps triage bugs (Hashnode). The other three describe in detail how code gets written. Ramp is the only one that also describes how the work gets chosen.

Four Routes to Getting Your Own Factory

Teams can get an AI software factory in four ways, and each one trades speed for control differently.

1. Buy a platform. This is the fastest way to start. You get the least control over sandboxing and over the context agents can see.
2. Assemble from parts. You combine a coding agent, a sandbox provider and your existing CI yourself. It is flexible, but you own every integration and every breakage between them.
3. Self-host. You get maximum control and data residency. You also carry the highest operational load: images, secrets, scaling and upgrades are all yours.
4. Have one built inside your environment. Someone else does the setup, and the factory runs on your infrastructure against your repos.

Whichever route you pick, measure cost per finished task, meaning a merged change that was accepted. Cost per agent run is the wrong metric. A cheap run that produces an unmergeable PR costs reviewer time, rework and a second run. A more expensive run that merges on the first review is cheaper where it counts.

The route matters less than it seems, because building has become cheap everywhere. Nearly a third of organizations report deciding against buying software because they could build it with agentic coding tools. When building costs less, choosing the wrong thing to build becomes the expensive mistake. That pushes the hard decision upstream to intake and to the customer evidence behind each ticket.

What Every Factory Shares

Ramp, Uber, OpenAI and Vercel use different agents and tooling, but their factories share four structural traits.

Sandboxes

Every agent works in an isolated environment. Ramp runs Inspect in sandboxed VMs on Modal. Vercel gives each agent its own sandbox. Isolation is what makes parallelism safe, because many agents can run at once without interfering with each other or touching production.

Fresh context

Ramp refreshes its repo images every 30 minutes so agents start from current code. That detail shows a broader principle: stale context produces stale code. An agent working from a two-day-old snapshot will confidently write code against functions that no longer exist.

A human merging every change

Vercel says it directly: a person merges every change. Review is the quality gate in all four examples. None of them describes a fully autonomous merge path, including OpenAI's million-line project, which still had three to seven engineers driving Codex.

Intake from tickets

Agents work from scoped tasks, so the ticket serves as the specification. The agent has no other source for what the change is supposed to accomplish.

If the ticket is the spec, the factory's output can only be as good as its tickets.

What Breaks: Factories Don't Decide What to Build

The most common factory failures happen at intake, before any code is written. Better models don't fix them, because the problem is the input.

Failure mode 1: faithful execution of vague tickets

An agent builds exactly what a thin ticket says. If the ticket says “Add bulk export,” the agent adds bulk export. Nobody checks whether that export solves the problem the customer actually described.

Failure mode 2: speed amplifies priority errors

A team that ships several times faster also ships a wrong roadmap several times faster. A slow team with bad priorities wastes a quarter. A fast factory with bad priorities fills production with features nobody uses.

Failure mode 3: review checks code, not intent

Reviewers confirm the code is correct, tested and readable. They can't confirm it matches what customers asked for, because the customer context isn't in the PR. Code review verifies correctness, not intent.

Failure mode 4: evidence lives in silos

Call recordings, support tickets, Slack threads from customer channels and survey responses sit in tools the agent can't read. The “why” never reaches the factory, so agents fill the gap with plausible guesses.

Failure mode 5: no loop closure

Features merge, but the customers who asked for them are never told. Nobody checks the original request against the result, so the team can't tell whether the shipped work solved anything.

Ramp's Voice of the Customer agent is the counterexample. It treats customer evidence as a factory input rather than something product managers carry around in their heads. If you want to build something similar, see how to build a customer insight agent like Ramp.

The Evidence-to-Merge Method: Feeding a Factory Customer Evidence

The Evidence-to-Merge method is a seven-step process that connects customer evidence to agent-written code. Any team can run it this week with a spreadsheet, a ticket tracker and a coding agent. It needs no special tooling.

Step 1: Collect raw evidence weekly

Pull call notes, support tickets, Slack threads from customer channels and survey verbatims into one doc or sheet. For each item, record the source, date, customer or account, and the exact quote. Use the customer's actual words, not a paraphrase.

Step 2: Cluster into problems, not features

Group quotes by the underlying problem, not by the feature someone requested. Three customers asking for “CSV export,” “an API endpoint” and “a Sheets sync” may all have the same problem: getting data into their finance system. Count distinct accounts per problem, and note revenue or segment where you know it.

Step 3: Write tickets that cite evidence

Every agent-bound ticket gets an Evidence block with 2–5 linked quotes (call timestamp, ticket ID, Slack link) and the account count. The agent reads this block, and so does the reviewer.

Step 4: Quote customers in acceptance criteria

Write acceptance criteria in the customer's own words. For example: “User can export filtered transactions without re-applying filters (per Account X, ticket #123).” This gives both the agent and the reviewer a test that traces back to a real person.

Step 5: Give agents a standing context file

Keep a short repo-level doc that the agent reads on every run. It should include a glossary of customer terms, the current top problems and known non-goals. Refresh it as often as your evidence changes. Customer context goes stale the same way repo images do.

Step 6: Review against evidence, not just code

The reviewer asks two questions. Does this pass tests? Would the quoted customer say this solves their problem?

Step 7: Close the loop after merge

Notify the accounts cited in the ticket and link the PR to the original evidence. Then track whether mentions of that problem drop in the following weeks.

Worked Example: One Ticket Through the Evidence-to-Merge Loop

The following is a hypothetical, illustrative scenario, not a real customer case study. It shows how evidence changes both what gets built and what review catches.

Setup

A B2B team running background coding agents reviews one week of evidence: about 40 support tickets, six sales and CS call notes, and one customer Slack channel.

The clustering decision

Two candidate problems come out of clustering:

• Problem A: one large account wants a custom export format for its ERP. Their champion raised it on two calls and escalated in Slack. It is loud.
• Problem B: twelve smaller accounts mention, in support tickets and one call, that exporting data ignores the filters they've already applied. It is quiet and spread across sources.

The team prioritizes by distinct accounts plus revenue at risk, not by volume of complaints. In this scenario, the twelve accounts together carry more revenue than the single large account, and three of them have renewals within the quarter. Problem B goes first. Problem A is logged with its evidence so it can compete fairly next week.

Before and after: the ticket

Thin version:

Add bulk export to the transactions page.

Evidence-backed version:

Problem: Exports ignore applied filters, forcing users to re-filter in spreadsheets.

Evidence (12 accounts): “I filter to last month's card spend, hit export, and get every row since we signed up” (ticket #4412). “We rebuild the filter in Excel every Monday” (call with Account Y, 14:32). Plus three more linked quotes.

Acceptance criteria: User can export filtered transactions without re-applying filters (per Account X, ticket #4412). Exported row count matches on-screen row count.

Non-goals: Custom ERP formats. Scheduled exports.

The agent run

The agent picks up the ticket, works in its sandbox and opens a PR. Tests pass. The code is clean. But the reviewer checks the acceptance criteria and finds that the export button calls the unfiltered query. The PR exports all rows. The reviewer catches this only because the criteria quote the customer and require the row counts to match. Under the thin ticket, “bulk export” would have been correctly implemented and merged.

Post-merge

The fix merges after one revision. The twelve cited accounts get a short note saying filtered exports are live. The team tracks export-related tickets over the next few weeks to confirm they decline.

The evidence changed what got built, and it caught an error that code review alone would have passed.

Common Mistakes Teams Make With AI Software Factories

Most factory mistakes come from measuring the wrong thing or removing safeguards too early.

• Measuring cost per run instead of cost per finished task. Runs are cheap. Merged, accepted changes are what you pay for.
• Treating “% of PRs written by agents” as the goal. Ramp, Uber and Vercel report that share as an output. None presents it as a measure of customer value.
• Letting stale context in. Outdated repo images and an outdated customer context file both produce confident, wrong output.
• Removing the human merge gate too early. All four examples keep a person in the loop, including the one that shipped a million lines.
• Writing tickets from internal opinion. A ticket with no linked customer evidence turns a guess into production code faster.
• Skipping loop closure. Without it, nobody learns whether shipped work solved the problem.
• Building by default because building got cheap. Agents lower the cost of building. They don't tell you whether customers need what you built.

When You Need Tooling: BuildBetter and the Rest of the Factory Stack

The manual Evidence-to-Merge method works until volume outruns the person maintaining the spreadsheet. Three signs that you've reached that point:

• You get more than about 200 pieces of customer feedback a month across more than two or three sources.
• Agents open more PRs per week than a PM can trace to evidence by hand.
• The real context lives in call recordings, not in anyone's notes.

1. BuildBetter — Best for feeding customer evidence to coding agents

BuildBetter is the customer evidence layer for the factory. It unifies calls, Slack, support tickets, surveys and feedback through 100+ integrations, including Zoom, Slack, Jira, Salesforce, Zendesk, HubSpot and Intercom. It produces tickets and PRDs with linked evidence, so the Evidence block from Step 3 fills itself in. Through the BuildBetter MCP server, coding agents can read customer evidence directly using the Model Context Protocol. After you ship, it drafts loop-closure emails to the accounts that asked.

2. ZeroShot

ZeroShot is BuildBetter's product for coding teams running agents. It connects customer evidence to agent-driven development work.

3. Sandbox and execution infrastructure

This category covers isolated VMs or containers per agent with fast repo image refresh, the role Modal plays in Ramp's setup. Evaluate options on isolation, startup time and image freshness.

4. Background coding agents

These agents take tickets and open PRs. Evaluate them on cost per finished task, monorepo handling and how well they consume external context such as MCP.

When BuildBetter is not the right fit: if you mainly need enterprise survey distribution at scale, or a dedicated research-repository workflow with tagging and highlight reels, purpose-built tools in those categories go deeper. If you're evaluating Ramp-style internal tools, see our Ramp Glass alternatives comparison.

FAQ

What is an AI software factory?

An AI software factory is a system where coding agents take scoped tickets, write code in isolated sandboxes and open pull requests that a human reviews and merges. Unlike autocomplete or chat assistants, it runs in the background and in parallel.

How much of Ramp's code is written by AI?

Ramp's Inspect agent writes about 30% of merged frontend and backend PRs. CPO Geoff Charles said on a podcast that about 50% of the codebase is AI-generated, with a target of 80%.

What is Ramp Inspect?

Inspect is Ramp's internal background coding agent. It runs in sandboxed VMs on Modal, and its repository images refresh every 30 minutes. It writes roughly 30% of merged frontend and backend PRs.

What is Uber's Minion?

Minion is Uber's agent platform, wired into its monorepo. 92% of Uber developers use agents monthly, and 11% of PRs are opened by agents.

What is harness engineering at OpenAI?

Harness engineering means engineers build the environment, tooling and specifications that let Codex write code, instead of writing the code themselves. One OpenAI team shipped an internal product of about a million lines through roughly 1,500 PRs, with three to seven engineers driving Codex.

Do AI software factories replace engineers?

Not in these examples. OpenAI's million-line product still had three to seven engineers driving Codex, and Vercel has a person merge every change. The engineer's role shifts to specifying and reviewing.

What should I measure?

Measure cost per finished task, meaning merged and accepted changes. Also track whether shipped work resolves the customer problems that justified it.

How do coding agents get customer context?

Agents get customer context through evidence linked in tickets, acceptance criteria that quote customers, a standing context file in the repo, or an MCP server that exposes customer evidence to the agent.

Should we build instead of buy now that agents make building cheap?

Only when customer evidence shows the need. Nearly a third of organizations report choosing to build software they would once have bought. That makes deciding what to build the scarce skill.

Sources and Further Reading

• Ramp valuation and Inspect details: Tech Insider
• AI software factory tools roundup: Hashnode
• Model Context Protocol, official docs: modelcontextprotocol.io
• Modal documentation (sandbox infrastructure used by Ramp): modal.com/docs
• Continuous integration: Wikipedia
• Related reading: Ramp's AI product factory and internal tools and How to build a customer insight agent like Ramp

Give Your Factory the Why, Not Only the How

Your coding agents can already write the code. What they can't do on their own is hear the customer. BuildBetter connects every call, ticket, Slack thread and survey to the tickets your agents work from. It exposes that evidence through MCP and notifies customers when their request ships. Agents build the right thing, reviewers check it against real quotes, and the loop closes on its own.

Make churn optional. Book a demo