Ramp’s CPO reported that 75% of its pull requests are now opened by an agent — and the structural reason that number exists at all has nothing to do with programming being easy.
On Lenny’s Podcast, Ramp chief product officer Geoff Charles described Inspect, Ramp’s internal coding agent. It runs inside Slack, returns a deploy preview in under five seconds, and — according to Charles — is now responsible for 75% of Ramp’s pull requests, with more than a thousand of those opened last month by people Ramp does not classify as engineers. Every one of those numbers is self-reported on a podcast, not audited and not independently verified. PR size, review time, defect rates, merge rates, and the precise definition of “non-engineer” are all unknown.
The caveat Charles attached to these figures deserves to be read before the figures themselves, not after: “Coding agents are really good when you have a strong architecture and a strong code base.” That sentence does a great deal of analytical work, and the rest of this piece is largely an attempt to make explicit what it implies.
The 75% figure also requires one specific clarification — and it is a clarification about measurement, not about Charles’s honesty, which is not in question. He reported a specific, falsifiable metric with a named tool and a time window attached, which is more than most companies disclose on this subject. The limit sits in the unit: pull requests are counted one-for-one. A one-line configuration tweak and a full schema migration each register as a single PR. The share of PRs opened by an agent and the share of engineering work completed by an agent are simply different quantities, and only the first was measured.
The key insight: Coding landed first not because programming is easy, but because software is unusually rich in cheap, fast, machine-readable verification signals — it compiles or it does not, tests pass or they do not, a deploy preview renders or it does not. An agent can only be trusted to finish work whose completion can be checked without a human redoing it. That is a fact about the availability of done-states, not a claim about any single company’s headcount or hiring plans.
A real number, in a unit that does not measure what most readers will assume.
The Structural Read
The pattern underneath Ramp’s disclosure is not specific to Ramp. In the same week, independent accounts surfaced the same underlying property: a lab acquired a physical bench so it could own the verification of its own output; a Googleproject turned out to have been shaped around problems that arrive pre-packaged with a scoring function; a researcher described optimisers satisfying a measure in ways its author never intended. Each story is different. The structural property is identical: automation scales exactly as far as verification does.
Software is unusually well-stocked with verification. The type system is a statement about what correct looks like. The test suite is a library of done-states accumulated over years. The deploy preview is an independent oracle that has no stake in flattering the agent. These are not incidental features — they are the preconditions. Which is why Charles’s architectural caveat is not a platitude. A strong codebase is a dense supply of machine-checkable correctness signals. An organisation that never accumulated those signals cannot simply purchase the capability by choosing a better model.
Geoff Charles — Lenny’s Podcast (self-reported, unaudited)
“AI simply removes the bottleneck but moves it. And the best team, the winning team is the team that can find the bottleneck faster, remove it, and move on to the next one.”
A separate practitioner — Theo on t3.gg, a different show, a different conversation — described the same constraint from the opposite end: current top-tier models “work really, really well if you tell them what done is because they’ll keep going until they get there.” A strong codebase is exactly a pre-existing library of done-states. Charles and Theo were not in conversation; they converged on the same limit independently.
The second half of Charles’s bottleneck observation deserves equal weight. Removing a constraint does not produce throughput — it produces a new constraint somewhere upstream or downstream. If code-writing was never the binding bottleneck at a given organisation — if the queue actually forms at code review, at product prioritisation, or at getting a decision from someone who is in meetings all day — then making code appear faster changes nothing except where the work piles up. The return on any automation step is entirely conditional on whether that step was the binding one.
Three Implications
IMPLICATION 1 — VERIFICATION IS THE PRIOR INVESTMENT
The organisations that benefit most from coding agents are those that already built the architecture Charles describes — typed codebases, strong test coverage, clear module boundaries. That work was done years before agents existed. It is now functioning as the infrastructure on which agent capability runs. The capability cannot be imported without the prior investment, and the prior investment took years.
IMPLICATION 2 — THE PR COUNT METRIC IS REAL BUT NARROW
Pull-request count is a legitimate, falsifiable metric. It is also a unit that does not distinguish a one-line config change from a multi-day refactor. Any organisation benchmarking its own agent usage against Ramp’s 75% figure should first ask whether its PR-size distribution is comparable. The useful denominator is engineering work completed — a harder quantity to measure, which is precisely why it tends not to be the one that gets reported.
Charles’s own framing is the most generalisable thing in this story: the winning team finds the bottleneck faster, removes it, and moves on. That is a constraint-management discipline, not an AI adoption checklist. Deploying an agent on a step that was not your bottleneck produces a faster queue at the next step and no net throughput gain. The diagnostic question — where does work actually wait? — has to precede the tooling decision.
The reason Ramp’s story fits the Map of AI framework is that Inspect is not a model — it is a harness that turns model output into a checkable artifact (a deploy preview) before any human sees it. That harness layer is where most of the real capability unlock lives, and it is the layer most organisations underinvest in when they think about AI adoption. Understanding where verification sits across all nine layers of the AI stack is the prerequisite for knowing where to build.
Ramp’s self-reported numbers are real enough to be instructive and incomplete enough to require care — 75% of pull requests is not 75% of engineering work, and neither figure says anything about headcount, hiring, or what happens at any other company. That is not an accusation. Charles reported a specific, falsifiable metric with a named tool and a time window attached, which is considerably more than most companies disclose about this, and volunteered the architecture caveat unprompted. The limitation sits in the unit, nowhere near his honesty. What the story does establish, with unusual clarity, is the structural condition that makes agent-assisted development possible at all: not a sufficiently capable model, but a sufficiently verifiable codebase. The capability is a function of the prior investment in correctness infrastructure, and that infrastructure took years to build. The organisations wondering why the same tools produce different results at different companies now have a precise answer.
Every figure above is self-reported by Geoff Charles on a podcast. None is audited or independently verified.His own caveat travels with the numbers: coding agents work well when the architecture and codebase are already strong.“75% of pull requests” is not 75% of engineering work — pull requests differ enormously in size, difficulty and risk, so the share of PRs and the share of work are different quantities and only the first was measured. That is a limitation of the unit and not a criticism of the reporting, which is more specific and more falsifiable than most companies offer. Nothing above claims anyone is being replaced, that headcount will fall, or that any of this generalises to another company. Theo and Geoff Charles are separate people speaking on separate shows; nothing above implies a conversation between them. Ramp’s headcount, revenue, hiring plans, what Inspect is built on, pull-request size, review time, defect and revert rates, the definition of “non-engineer”, whether those pull requests were merged and the size of the codebase are not established and do not appear above. Nothing above predicts anything or constitutes investment advice.
Gennaro is the creator of FourWeekMBA, which reached about four million business people, comprising C-level executives, investors, analysts, product managers, and aspiring digital entrepreneurs in 2022 alone | He is also Director of Sales for a high-tech scaleup in the AI Industry | In 2012, Gennaro earned an International MBA with emphasis on Corporate Finance and Business Strategy.
Scroll to Top
Discover more from FourWeekMBA
Subscribe now to keep reading and get access to the full archive.
