What product looks like when coding is solved | Geoff Charles (Ramp CPO)

Geoff Charles uses a racing metaphor to shift attention away from individual coding speed. In product work, his clock starts when a customer experiences pain and stops when a product solves it. A faster build step helps only as part of that complete journey.

The title’s premise that coding is solved is deliberately simplified. Charles later qualifies it: when one bottleneck improves, the next appears. Definition, review, testing, coordination and improvement can now limit the flow. His proposal is to redesign the product factory around the current constraint, rather than celebrate code volume alone.

Customer pain arrives through calls, support systems, recordings, surveys and direct messages. Charles says an initial channel that broadcast complaints became overwhelming. The problem was not merely insufficient summarization, but finding useful context in many disconnected sources.

He describes rebuilding around ordinary data pipelines, vector search and clustering, with product and team context. Different interfaces then made the insights accessible: chat, dashboards and even a podcast. Crucially, he says the point is to identify which customers to talk to, with traceable evidence, rather than replace customer conversations with an agent’s summary.

A blank prompt asking what to build is a weak starting point if the system lacks company context. Charles describes Glass as an agent connected to research, quantitative data, strategy, specifications and the codebase, so it can help make a problem specific and explore implementation questions.

The output he wants is a combination: qualitative and quantitative evidence that the problem matters, requirements a coding agent can use and a prototype consistent with the product. A long specification or an isolated mockup alone is not that contract. Calling AI a thought partner does not remove responsibility for deciding whether the evidence and design are sound.

07:20View full image

Charles describes Inspect as a coding agent with a provisioned environment and preview output, and stresses that strong architecture and a strong codebase make such tools more useful. The talk reports large adoption and many pull requests initiated outside engineering.

That volume moves pressure to review. Review Buddy is described as using codebase, security and prompt context to review work and involve the appropriate human reviewer. The reported percentages are Ramp’s claims at recording time, not an independent measure of defect rates or proof that every change can bypass human review. The relevant design idea is visible context and escalation, not automation by percentage alone.

The next described system, Testo, operates a browser like a user across different configurations. Charles says it can report blocking bugs and also identify confusing flows or inconsistencies with design principles.

He reports hundreds of bugs caught during a recent period, but the talk does not establish complete coverage or a controlled comparison with every prior testing method. The meaningful loop is that a discovered issue returns to the team for a fix. Faster generation has not made validation unnecessary; it has increased the need to make validation scale.

Charles calls human attention the next bottleneck. Too much process slows builders; too little leaves everyone confused. His Gadget example connects questions to formal records such as roadmaps, specifications, tickets and customer calls.

The agent can answer a project-status question with evidence, identify owners and help update records or prepare launch material. When it cannot answer, it routes the question to a person and feeds the answer back. The reported response rate is an internal account, not a guarantee. The reusable principle is that agents need an organization they can read, with records that remain meaningful and accountable.

Charles wants product managers to escape a constant stream of small reactive tasks so they can work on larger opportunities. He describes loops that route issues, deduplicate and rank them, make a plan, obtain a human checkpoint in Slack, write code, pass testing and CI, and update the knowledge base after launch.

The talk’s reported fast UX-fix rate should not be read as all work becoming unsupervised. Its own description includes approval and validation. Nor does choosing a high-leverage bottleneck guarantee a tenfold business result: Charles treats constraints as a reason to concentrate resources, rather than copy every internal tool in the presentation.

Charles sketches three directions: the technical factory builder who improves how products are made, the tastemaker who holds the quality bar and direction, and the general manager who owns broader business outcomes across functions.

These are proposed paths, not a settled forecast for every product role. His closing emphasis is continuous redesign: tools shown on stage will age, competitors will learn and the next bottleneck will appear. The enduring task is to shorten the path from a real problem to a checked solution while preserving the judgment that makes the solution worth shipping.