Ramp's $60B AI Bet: The Agents That Code and the One That Decides What to Build

On October 15, 2026, Ramp was reported valued at $60B after a $1.85B round led by Dragoneer, up from $44B in June 2026, with roughly $2B in annualized revenue (tech-insider.org). Coverage has focused on Ramp's coding agents. The more useful lesson is the other agent Ramp built, the one that decides what those coding agents should work on. This guide from the BuildBetter team explains both halves and gives you a five-step method to copy the pattern without a platform team.

Ramp's $60B Round, and What an "AI Software Factory" Actually Is

An AI software factory is a system where coding agents take a task, write the code in an isolated environment, and open a pull request that a human reviews and merges. The factory automates how code gets written. A ticket goes in and a reviewable PR comes out, and an engineer decides whether it ships.

Ramp's valuation has climbed in steps. Publicly reported marks were about $13B in March 2025, $16B in June 2025, $22.5B in July 2025 and $32B in November 2025. The $44B and $60B rounds in 2026 continue that curve. The $60B mark is a 36% step-up in about four months, and much of the reporting ties it to how fast Ramp ships.

Ramp's setup has a second half that gets less attention. Ramp also runs a deciding agent, its Voice of the Customer agent, which turns customer evidence (calls, tickets, Slack threads, feedback) into the prioritized list of what the factory should build. Ramp built both the factory and the decider.

Every well-known software factory automates how code gets written, and almost none of them decides what to build.

That gap is the subject of this guide. For the full picture of Ramp's internal stack, see how Ramp's AI product factory and internal tools fit together.

How Inspect Works: Ramp's Background Coding Agent

Inspect is Ramp's internal background coding agent, and it writes about 30% of Ramp's merged frontend and backend pull requests. A background agent runs asynchronously, without a developer watching. Someone triggers it from Slack, a ticket, a web UI or an API, and it returns a PR. An IDE copilot works differently: it suggests code interactively while a developer types.

Sandboxed VMs and fresh repo images

Each Inspect task runs in its own sandboxed VM on Modal, a serverless compute platform that offers sandboxes. Repo images refresh about every 30 minutes, so each agent starts from near-current code instead of a stale snapshot.

The two design choices do different jobs:

• Isolation enables parallelism. Every agent gets its own environment, so dozens of tasks can run at once without touching production, secrets or each other's working state.
• Fresh images reduce waste. Agents branch from recent main, which cuts merge conflicts, failed CI runs and compute spent on tasks that someone already fixed.

Two numbers that measure different things

Ramp CPO Geoff Charles said on a podcast that about 50% of Ramp's codebase is AI-generated and that the target is 80%. Treat that as a stated claim and an ambition, not an audited figure.

Keep the two figures separate:

• ~30% is the share of merged PRs authored by Inspect, one specific agent.
• ~50% is a broader claim about the codebase, which likely includes code written with IDE assistants and other tools.

Combining them ("Ramp's agent writes half its code") misstates both.

Ramp Isn't Alone: How Other Software Factories Compare

Several large engineering organizations now run software factories, and their published descriptions focus almost entirely on code production. Per hashnode.com:

• Uber runs an agent platform called Minion, wired into its monorepo. 92% of developers use agents monthly, and 11% of PRs are opened by agents. Broad adoption and authoring share are different measures.
• OpenAI's harness-engineering team shipped an internal product of about a million lines with no hand-written code. It came from roughly 1,500 PRs by three to seven engineers driving Codex.
• Vercel built a factory for the AI SDK. Four weeks in, it authored a quarter to a third of merged PRs. Every agent runs in its own sandbox, and a person merges every change.
• Build vs. buy is shifting. Nearly a third of organizations report deciding against buying software because they could build it with agentic coding tools.

There are four routes to a factory: buy a platform, assemble one from parts, self-host, or have one built inside your environment. Whichever you pick, the cost that matters is cost per finished task: compute, tokens, CI time, reviewer minutes, rework and rejected PRs. Cost per run is the wrong measure, because a cheap run that gets rejected still uses reviewer time and ships nothing.

The Part Most Companies Skip: Ramp's Voice of the Customer Agent

Ramp runs a Voice of the Customer agent that analyzes customer feedback and helps triage bugs. Public sources describe what it does, not how it is built, so that is as far as this guide goes. The point is that it exists, and it sits upstream of the factory.

The deciding layer matters more as code gets cheaper. When agents write a third of your PRs, engineering capacity stops being the main constraint. Choosing the right tasks becomes the constraint. DORA's 2025 research describes AI as an amplifier: teams with clear priorities get faster at useful work, and teams without them get faster at the wrong work. A deciding agent supplies the clear priorities.

A factory works the same way. If you double the speed of the assembly line and give it the wrong order, you ship the wrong product twice as fast.

The input to a deciding layer is customer evidence:

• Call transcripts from sales, CS and research conversations
• Support tickets
• Slack threads from customer-facing teams
• Survey responses
• Product feedback submitted in-app or by email

Each item has to trace back to a real customer and account. Without that link you have opinions, and you cannot weigh them by frequency or revenue. For an example of how fast the feedback-to-fix cycle can run when evidence is wired in, see how Ramp fixes UX issues in 24 hours. The broader concept is described in the voice of the customer literature.

Why Pointing Coding Agents at the Right Work Is Hard

Most teams can get a coding agent to open PRs in a week; very few can reliably point it at problems customers have confirmed. Six failure points come up repeatedly:

1. Evidence is scattered. Sales calls live in one system, tickets in another, CS escalations in Slack. No single person sees all of it.
2. Loudness bias takes over. The biggest account or the angriest Slack thread sets the roadmap, and frequency and revenue impact get ignored.
3. Feedback isn't agent-ready. Customers send complaints ("export is broken"). They don't send scoped tasks with acceptance criteria an agent can execute.
4. Context gets stripped. By the time a request becomes a Jira ticket, the customer quote, account and workaround are gone. Agents and reviewers end up guessing.
5. Throughput hides waste. A factory merging dozens of PRs a week looks productive even when few of those PRs map to problems customers reported.
6. The loop never closes. Customers who reported an issue never hear that it shipped, so they report it again, and the duplicates inflate the backlog.

OpenAI's harness-engineering work points to the same conclusion. When agents write the code, engineering effort shifts to the environment: specs, tests, linters, in-repo docs and feedback loops. A well-written task brief is part of that environment. A one-line ticket title is not.

The 5-Step Method: Copy Ramp's Pattern Without a Platform Team

Build the evidence layer first, then add agents. You can run every step manually today with a spreadsheet and the exports you already have.

Step 1: Centralize evidence weekly

Export the last 30 days of support tickets, call notes or transcripts, and customer-facing Slack threads into one sheet. Use one row per piece of feedback, with columns for source, customer, account size, date and verbatim quote.

Step 2: Tag and cluster

Give every row a problem tag in the customer's words, not a solution: "can't find past invoices," not "add search." Merge duplicates into clusters and keep links back to every source row.

Step 3: Score each cluster

Score on frequency (distinct customers), impact (revenue at risk or blocked workflows) and an effort guess (S/M/L). Then flag which clusters are agent-sized: well-scoped, testable, reversible, low in architectural risk and with clear acceptance criteria. Ambiguous or architectural work goes to senior engineers.

Step 4: Write evidence-backed task briefs

For each top cluster, write a one-page brief with the problem statement, 2–3 verbatim quotes, affected accounts, acceptance criteria and out-of-scope notes. The coding agent or engineer receives this brief as the prompt.

Step 5: Run the factory and close the loop

Hand agent-sized briefs to whatever coding agent you use, running in a sandbox. Have a human review and merge every change, as Vercel does. When it ships, message every customer in the cluster, then check whether that feedback stops arriving.

Steps 1–4 don't require any vendor. The method works without new tools.

Worked Example: One Month, One Small Team

This is an illustrative scenario, not a customer case study. It shows how the method plays out at a B2B SaaS company with six engineers, one PM and one CS lead, already using a coding agent.

Inputs for the month: 220 support tickets, 35 customer call notes and about 60 relevant Slack messages from #customer-escalations.

Step 2 produces 18 problem clusters. The top three:

• "CSV export times out on large accounts": 14 customers, including 3 of the 10 largest
• "Approval emails land in spam": 9 customers
• "Can't bulk-edit user roles": 6 customers, mostly onboarding complaints

Step 3 routes each one differently. CSV export scores highest on impact, but the fix is architectural (query design, likely async jobs), so a senior engineer takes it. The spam issue is a config and DNS fix, so ops handles it and no code is written. Bulk-edit is agent-sized and testable, so it gets a brief.

Step 4, the bulk-edit brief, contains:

• 3 verbatim quotes from onboarding calls and tickets
• 6 affected accounts
• Acceptance criteria: select up to 100 users, change role, write an audit log entry, allow undo within the session
• Out of scope: custom roles

Outcome: The agent's PR goes through human review, the team merges it, and the CS lead emails the six accounts. Next month's export shows whether bulk-edit complaints drop. That result is the only metric that proves the factory built the right thing. PR count and AI-generated share don't tell you that.

Without steps 1–4, the same agent would probably have spent the month on whichever tickets were newest or loudest.

Common Mistakes Teams Make When Copying Ramp

The most common mistake is copying Inspect and skipping the Voice of the Customer agent. That gets you more PRs with no better direction. Other frequent errors:

• Measuring cost per run instead of cost per finished task. Cheap runs that get rejected in review are expensive.
• Feeding agents ticket titles instead of evidence-backed briefs. Vague input produces code that looks plausible and solves the wrong problem.
• Chasing a percentage target. Ramp's 80% figure is an ambition stated on a podcast, not a benchmark. AI-generated share describes output and says nothing about whether the work was right.
• Removing the human merge step too early. Every factory cited here keeps people in the review or merge loop.
• Letting the evidence sheet go stale. Ramp refreshes repo images every 30 minutes for a reason: agents acting on old context waste work. Refresh evidence at least weekly for the same reason.

When You Need Tooling

The manual method holds up to roughly 200 pieces of feedback a month across two or three sources. Past that, or once several coding agents need evidence on demand, manual tagging becomes the bottleneck. Other signs you've outgrown the spreadsheet:

• Calls aren't being transcribed, so call evidence never reaches the sheet.
• Slack evidence is never exported.
• Briefs take longer to write than the agent takes to code.

1. BuildBetter — Best Evidence Layer for Coding Agents

BuildBetter automates steps 1–4 and the loop-closure half of step 5. It unifies calls, Slack, tickets, surveys and feedback through 100+ integrations, including Zoom, Slack, Jira, Salesforce, Zendesk, HubSpot and Intercom. It analyzes each item individually for severity and business impact using Signals, then produces PRDs, Jira and Linear tickets with the source quotes attached, and follow-up messages to the customers who asked. Its MCP server lets coding agents query customer evidence directly, so a brief can carry the actual quotes and accounts. It combines internal team activity with external customer feedback in one place.

Honest caveat: BuildBetter isn't built for distributing enterprise surveys at scale, and it isn't a dedicated research-repository workflow tool.

2. ZeroShot — Customer Evidence for Agent-Driven Development

ZeroShot is BuildBetter's product for coding teams running agents. It connects customer evidence to agent-driven development so that each brief an agent receives includes real customer context.

3. Supporting Infrastructure Categories

• Sandboxed agent runtimes: the infrastructure layer Ramp uses on Modal.
• Model Context Protocol servers: expose internal data to agents in a standard way.
• Help-desk and call-recording exports: the raw inputs for step 1.

For a broader comparison, see alternatives to building a Ramp-style customer insight agent.

FAQ

What is Ramp valued at?

Ramp was reported valued at $60B as of October 15, 2026, after a $1.85B round led by Dragoneer. That is up from $44B in June 2026, with about $2B in annualized revenue (per tech-insider.org).

What is Ramp's Inspect agent?

Inspect is Ramp's internal background coding agent. It runs each task in a sandboxed VM on Modal using repo images refreshed every 30 minutes, and it writes about 30% of Ramp's merged frontend and backend PRs.

How much of Ramp's code is AI-generated?

CPO Geoff Charles said on a podcast that about 50% of Ramp's codebase is AI-generated, with a target of 80%. This is a stated claim, not an audited figure. It also measures something different from Inspect's 30% merged-PR share.

What does Ramp's Voice of the Customer agent do?

It analyzes customer feedback and helps triage bugs. It is the deciding layer that tells the factory what is worth building, and most published software factories don't describe one.

What is an AI software factory?

An AI software factory is a system where coding agents take tasks, write code in isolated environments, and open pull requests that humans review and merge.

Can a small team copy Ramp's approach without a platform team?

Yes. Build the evidence layer first with the manual five-step method. Then point any coding agent at evidence-backed briefs, with a human merging every change.

Should we build software instead of buying it in 2027?

Nearly a third of organizations report deciding against a purchase because agentic coding let them build it instead. Judge each case by cost per finished task, and include review time and ongoing maintenance in that cost.

Sources and Further Reading

• Ramp $60B valuation and AI coding details: tech-insider.org
• AI software factory tools and peer company data: hashnode.com
• Voice of the customer (concept background): Wikipedia
• Model Context Protocol official docs: modelcontextprotocol.io
• Modal documentation (sandboxed compute): modal.com/docs

Give Your Coding Agents the Right Orders

Your coding agents can already write the code. What they need is a reliable signal about which code to write. BuildBetter turns every call, ticket, Slack thread and survey into evidence-backed briefs your agents and engineers can act on, then notifies customers when the fix ships.

Make churn optional. Book a demo.