Field notes · 8 min read
What Ramp built when coding stopped being the bottleneck
Ramp’s CPO walked through the five agents his team built around the product development loop. The pattern underneath them matters more than any one of them.
At the Lenny and Friends Summit in September 2026, Ramp’s chief product officer Geoff Charles gave a talk with a deliberately provocative title: what product looks like when coding is solved. His answer is that coding being solved does not make you fast. It just moves the slow part somewhere else.
His framing: “AI simply removes the bottleneck, but moves it.” Every time a team automates one stage of building software, the next stage becomes the constraint. The job of a product leader is to keep finding the new one.
Why he opens with a pit stop
Charles races cars, badly by his own account, and the talk leans on Formula 1 throughout. The useful part is the pit stop. In the 1950s, changing tires took 67 seconds. Today it takes 1.8 seconds. That did not happen, he points out, “by asking the mechanic to work 37 times harder.” It happened because teams found each bottleneck and removed it: “Specialized functions, better technology, more practice.”
The same logic applies to a product org. As he puts it, “The best drivers in the world can only perform up to the level of the system.” Winning “is about removing the bottlenecks around the driving.”
So where did the bottleneck go once engineers got coding agents? To product. More things to ship, more to test, more to release, and the same number of PMs to shepherd it. His advice to product managers is blunt: “Be as lazy as engineers.” Automate your own job the way they automated theirs.
What follows is the five stages of Ramp’s loop and the agent they built for each.
1. Identify: the customer insight agent
Charles starts where every product team starts, with pain that is real but scattered. It arrives through Gong, Zendesk, LogRocket, surveys and angry emails. “Context lives all over the place,” and the first bottleneck is separating signal from noise.
Ramp’s first attempt was a Slack channel that posted customer complaints every day. It was funny and it did not scale. So they rebuilt it as a customer insight agent that pulls from every data source in the company, using ordinary ETL and pipelines, clusters related context together, and is accessible to the rest of the organization rather than locked in one team’s tooling.
Two details matter more than the agent itself. The first is distribution: once it worked, they asked how to get it into as many hands as possible, and shipped it as a dashboard and even a daily audio digest of customer complaints. The second is trust: “the data is traceable.” Every insight can be followed back to the conversation it came from.
2. Define: give the AI context, not a blank page
This is the sharpest section of the talk. Charles notes that every AI tool opens the same way, by asking what you want to build. “Is that really the best question to ask? Is that really the best starting point?” You are handed a blank prompt by a system that knows nothing about your company.
Ramp’s answer is an agent called Glass, which they loaded with the context a good PM would have: customer evidence, the quantitative data in Snowflake, the product strategy, how the company defines product quality, and the codebase. The result is that the reviewing conversation flips. Instead of a PM chasing an engineer to ask “does this break something? What am I missing?”, they ask the agent. In his words, “AI can be your best thought partner. So now AI is your tech lead.”
He is also direct about what engineers actually want from product, and it is not the artifacts PMs are trained to produce. “They don’t want your prototype… They don’t want your long spec. That’s useless.” What they want is enough qualitative and quantitative evidence to believe the problem is real, context their coding agents can work from, and a prototype to get inspired by. He calls that “the next contract” between product and engineering.
3. Build: coding agents, and who is actually shipping
Ramp built their own coding agent, Inspect, because they wanted control of the harness and wanted it to genuinely understand their codebase. It runs inside Slack and returns something a person can interact with rather than a diff to read.
The number worth sitting with: Inspect has run a million sessions, and 75% of Ramp’s pull requests last month were submitted by someone who is not an engineer.
Predictably, that moved the bottleneck again, this time to code review. So they built Review Buddy, which knows the codebase and the company’s security concerns, finds the right human reviewer to loop in, and can audit how AI was used to produce the change. Most reviews are handled automatically so that the strongest engineers spend their time on the small share of changes that carry real architectural risk.
4. Test: a QA agent that uses the product like a customer
Testing was next. Instead of PMs spinning up QA environments and clicking through screens, Ramp built Testo, a browser-based QA agent that exercises the product the way a customer would, across many combinations, against realistic production scenarios. You give it instructions in plain language, of the form “pay an invoice, but amortize it.”
It reports two kinds of feedback: blocking bugs, and softer issues like confusing flows or breaks in the design language. In the 30 days before the talk, Testo caught 425 bugs.
5. Coordinate: every question is an API
Once a team ships this much, the constraint becomes human attention. PMs drown in notifications and status pings, and coordination quietly becomes the job.
Charles’s reframe here is the one worth stealing: “Every question is an API.” If people keep asking the same question, that is an interface waiting to be built, not an interruption to absorb.
Ramp built Gadget, which reads the intent behind a question and connects it to the formal record: the roadmap in Notion, the tickets, the rest of the system. It answers “what’s the status of this launch, are we on track?” with evidence, updates the roadmap, posts status, and nudges people who are late on deliverables. It handles sales questions like whether a feature is available in a given market and how it is priced. At launch time it drafts the help center article, the blog post and the customer email.
The number: 85% of the questions asked of Ramp PMs are now answered by AI, and the ones that are not get answered by a human and fed back into the system so the next one is covered.
The principle underneath it is the one every team should copy: “For you to empower an agent, the agent needs to be able to understand and read the organization.”
The part most teams skip: closing the small loops
After a product ships, PMs naturally gravitate to small, visible, reactive work, the tasks that are easy and give you, in his words, “the dopamine hit, oh we’ve solved something.” Charles calls that a mistake. “You need to automate your way out of these small loops.”
At Ramp, small issues run through an autonomous loop: it routes the issue to the right team, matches it against the backlog in Linear, dedupes, counts, ranks, plans, checks in with a human through Slack, writes the code and runs it through testing and CI/CD. Humans stay in the loop barely, and only where it counts.
The result is the statistic that best captures what a closed loop actually buys you: 60% of UX issues raised by customers, salespeople or the team itself are fixed within 24 hours.
How do you know if you’re moving fast enough?
Charles takes three obvious objections head on.
On measurement. Product velocity has no lap time. He tells the story of Niki Lauda taking a Ferrari around the track in 1974 and telling Enzo Ferrari, in considerably stronger language, that the car drove, handled and braked badly. His conclusion: you will know whether you are fast enough if you hire people who know what speed looks like, put them in charge, and let them challenge you. “That might be hard for some leaders.”
On budget. In 2006 Audi had a slow car, so they competed on fuel efficiency instead: fewer stops, more time on track, and three consecutive wins. “Constraints force you to choose a dimension in which you can be world-class.” His line: “Embrace your constraints, but not your bottlenecks.” Find the one bottleneck you think could 10x your company and start there.
On the future of the PM role. He does not think product managers are automating themselves away, and he thinks being out of the loop on what engineers can drive alone is good. He sees three tracks: the technical PM who builds the factory, “shipping the product that helps you build the product for the customer”; the tastemaker who holds the steering wheel and the quality bar; and the PM who becomes a GM, owning the business outcome across marketing, sales, growth and operations.
His closing takeaway: obsess a little less about the product you are delivering, and a little more about the factory that builds it.
What this means if you are not Ramp
Ramp has the engineering capacity to build five internal agents. Most teams do not. But the pattern is portable, and the expensive part is not the agents.
Look at what actually made each of them work. Glass is useful because it has the customer evidence, the metrics, the strategy and the codebase in one place. Gadget is useful because it can read the organization’s formal record. The insight agent is trusted because its data is traceable. In all three, the agent is the cheap part. The context layer underneath is the hard part, and it is the same layer in each case.
That is the real lesson: Ramp did not buy five point solutions. They made their company legible to software once, then pointed different agents at it.
Where Fijord fits
Fijord is that context layer for product teams that are not going to build one from scratch.
It connects meeting notes and recordings, Slack, Linear, Jira, Notion, GitHub and Mixpanel into one product memory, so customer pain, decisions, tickets and outcomes live in the same place instead of six. Every insight links back to the conversation, document or metric it came from, because an answer you cannot trace is an answer you cannot act on. It drafts briefs, epics and tickets from that evidence, so what reaches engineering is closer to the contract Charles describes. And it compares what you predicted before a release against what actually happened afterwards, which is the loop most teams still leave open.
It is not a coding agent and not a QA agent. It is the part underneath: the layer that has to exist before any of the rest is worth building.
Frequently asked questions
What was Geoff Charles’s main argument?
That AI does not remove bottlenecks in product development, it relocates them. Once coding is fast, the constraint moves to identifying problems, defining work, reviewing, testing and coordinating. Product leaders should focus on the system that builds the product, not only on the product.
What agents does Ramp use internally?
Five, by stage of the product loop: a customer insight agent for identifying problems, Glass for defining and scoping work, Inspect for coding, Review Buddy for code review, Testo for browser-based QA, and Gadget for coordination and launch communication.
What results did Ramp report?
A million Inspect sessions, 75% of last month’s pull requests submitted by non-engineers, 425 bugs caught by Testo in 30 days, 85% of questions to PMs answered by AI, and 60% of UX issues fixed within 24 hours.
What does “every question is an API” mean?
That a repeated question is an interface waiting to be built. Rather than answering the same status or product question by hand, connect it to the system of record so an agent can answer it with evidence and keep the record updated.
What should a smaller team do first?
Make the company readable before building agents. Get customer evidence, decisions, tickets and outcomes into one traceable place, then automate the single bottleneck you think would most change your throughput.