Ramp has around 1,600 employees. Three of them built an internal coding agent called Inspect in two weeks. It now writes 75% of the company's merged pull requests.
The interesting part is not the build. Two weeks for three good engineers is fast but not remarkable in 2026. The interesting part is what had to already be true for it to work, and what broke immediately afterwards.
The precondition nobody puts in the case study
Inspect works because six years of specs, customer requests and roadmaps were already sitting in Linear, reachable through Linear's agent API. That let the agent, in Ramp's own description, "trace the thread from a customer request through a product spec to the relevant code."
Read that again as a dependency rather than a feature. The agent is not clever because the model is clever. It is useful because six years of decisions were written down in a system with types and an API, so a machine could walk from a complaint to the commit that caused it.
A company that ran the same six years through email threads, meeting notes and three migrations of a project tool cannot build this agent in two weeks. It cannot build it at all until it does the boring part first. That is the whole substrate-before-agents argument, with dates attached. See Your AI Doesn't Know How Your Company Actually Works.
Then the bottleneck moved
Ramp's own conclusion is the sentence to carry into any conversation about agent throughput:
"The speed has moved Ramp's bottleneck from writing code to reviewing it."
That is not a complaint and it is not a footnote. It is the predictable second-order effect of making one station in a pipeline dramatically faster, and almost every agent pilot discovers it about six weeks in.
Linear's response is the tell that this generalises: they shipped code review inside Linear. The platform followed the bottleneck. When the industry's tooling starts moving toward review, it is because everybody's constraint moved at once.
Why they built it instead of buying it
Zach Bruggeman's reason is unfashionable and specific: "It's a really tight integration with our development lifecycle and our tooling." Internally they "know the one API key it needs and precisely what the schema of their logs looks like."
That is the honest build-versus-buy line for internal agents, and it is not about capability. A general coding agent cannot have parity with tooling it has never seen. It does not know which of your four logging systems is the real one, or that the deploy script has a manual step nobody documented. The advantage of building is not a better model. It is knowing the answers to questions a vendor would have to ask you.
The counterweight, and it is real: two weeks of three engineers is cheap to start and permanent to maintain. Inspect is now a piece of internal infrastructure with an owner, an on-call story and a migration path every time a dependency moves.
The governance line worth stealing
Cristina Cordova's description of how this is kept safe is the most copyable sentence in the whole account:
"A central team defines what agents can access and do, so functional teams can build their own automations safely on the same rails."
Not a review board. Not a request queue. Rails. The central team owns what agents may touch, and the functions build on top without asking permission each time. That is the same structure Lovable arrived at from the opposite direction, where the People team became the heaviest builder of internal software once the rails existed. See Lovable Went From 11 Internal Apps to 80.
What to take from this
Ask the precondition question first. Before anyone scopes an internal agent, ask where the last six years of decisions live and whether a machine can walk them. If the answer involves email and a migration, that is the project, and it is unglamorous and it comes first.
Budget for the new bottleneck. If an agent writes most of your pull requests, review is now the constraint, and review is the activity you were least planning to staff. Plan the reviewer capacity into the pilot rather than discovering it in month two.
Copy the rails, not the agent. Inspect is specific to Ramp's stack and always will be. The transferable artifact is the sentence about what a central team owns, because it is what lets everyone else build without a queue.
One caveat on the headline number: 75% of merged pull requests is a volume measure, not a value measure. It counts PRs, not the difficulty of the work in them, and an agent that handles the routine three quarters while humans keep the hard quarter is exactly what you would expect and exactly what you should want. It is a real number and it is not the same as saying three quarters of the engineering got automated.
