How Ramp Fixes 60% of UX Issues in 24 Hours: Build the Loop

At Ramp, 60% of UX issues flagged by a customer, salesperson, CX rep or internal team are fixed within 24 hours. The code is the easy part. The hard part is the system that finds, dedupes, counts, ranks and approves each fix before an agent writes a line. This guide expands Ramp’s small-issue loop into 13 stages (three are our additions), each with an owner. It shows you how to run the loop by hand first and then automate it safely, starting with the cheapest mistakes. It also shows where BuildBetter fits: capturing feedback from calls, tickets and Slack, and closing the loop with the customers who reported the problem.

Ramp Fixes 60% of Customer-Flagged UX Issues Within 24 Hours

At Ramp, 60% of UX issues flagged by a customer, salesperson, CX or an internal team are fixed within 24 hours. Geoff Charles, Chief Product Officer at Ramp, shared the number in his talk “The limiting factor: how to design an AI software factory for speed” at the Lenny and Friends Summit in September 2026.

The loop is step 5, “Improve,” of Ramp’s five-step factory: Identify, Define, Build, Coordinate, Improve. For the full breakdown of all five steps and the internal tools behind them, read our analysis of Ramp’s AI product factory.

The main idea of the talk: AI does not remove the bottleneck, it moves it. For small fixes, the bottleneck stopped being code a long time ago. It is human attention spent on triage: reading tickets, finding duplicates, counting who is affected and deciding what to do next.

Here is how we frame the PM trap (this is our framing, not a Ramp quote). PMs drift toward small, easy, visible wins because they feel like progress. Fixing a label feels good on a Tuesday afternoon. But every hour spent on a misaligned button is an hour not spent on the ambiguous, high-stakes problems only a PM can work through. Automating the small loop gives that time back.

The goal of the small-issue loop is not to fix more small things. It is to stop humans from spending their week on them.

One caveat before you start. Ramp’s tools are internal and not for sale. Charles closed the talk with “I want you to copy us.” This guide shows you how.

What Counts as a “Small Issue” (and What Must Never Enter the Loop)

A small issue is a UX defect or friction point with a known correct outcome, a contained blast radius, and a fix that can be reviewed in minutes. If you get this definition wrong, the loop either stalls on work it cannot finish or ships changes it should never have touched.

The qualifying checklist (all seven must be true)

• Reproducible or clearly described: someone can see the problem or follow the steps to it.
• Unambiguous expected behavior: everyone would agree on what “fixed” looks like.
• UI, copy or one isolated component: the change stays in the presentation layer.
• No schema, API contract or data model change.
• Reversible with a single revert or feature flag.
• Verifiable by existing tests or a browser check.
• No taste arbitration: no design decision needs a senior designer to weigh in.

Typical small issues include broken empty states, confusing labels or copy, misaligned layouts, missing loading states, dead links, a wrong default sort, inconsistent button behavior and missing form validation messages.

The hard exclusion list

These areas never enter the autonomous loop, however small the change looks:

• Pricing and plan logic
• Permissions, roles and access control
• Authentication and SSO
• Data migrations and schema changes
• Anything customer-visible in billing, invoicing, payments or compliance
• Security-sensitive code
• Legal or regulatory copy
• Data retention or export behavior

Grey zone rule: if a reviewer would need to ask “should we?” rather than “is this correct?”, the issue is not small. Route it to a human PM.

Write the checklist and the exclusion list down, then encode them as machine-readable rules: Linear labels, file-path deny lists, CODEOWNERS entries and keyword filters. A rule that lives only in a Notion doc gets skipped under deadline pressure. A rule that lives in CI cannot be skipped.

The Small-Issue Loop: 13 Stages, Owners and Failure Modes

Ramp’s small-issue loop runs route, match to the Linear backlog, dedupe, count, rank, plan, human approval in Slack, write code, run tests and CI/CD, and update the knowledge base at launch. The approval step is Ramp’s “I’m ready to code” checkpoint. To make the loop workable for teams without Ramp’s internal tooling, we added three stages of our own: Intake (stage 1), Ship (stage 11) and Close the loop (stage 13). Those three are our additions, not part of Ramp’s description.

Every stage has one input, one output and one owner. If a stage has no owner, it is where issues go to die.

The table splits into two halves. Stages 1–6 are information work: capturing, sorting and weighing what customers said. Stages 7–11 are engineering work: turning a decision into shipped code. The approval gate at stage 8 is the seam between them. That seam is where you decide how much you trust the information half before you let the engineering half act on it.

Run It Manually First: The Weekly Triage Rotation

Do not automate a loop you have never run by hand. Two to four weeks of manual triage will show you where your real failure modes are. Maybe feedback is trapped in unreviewed sales calls. Maybe duplicate tickets split your counts. Maybe one engineer keeps merging distinct bugs. You cannot write good automation rules for problems you have not seen.

Setup

• A weekly rotating triage owner (a PM, CX lead or engineer)
• A single Linear label such as small-fix
• A shared Slack channel for intake
• A written copy of the small-issue checklist and exclusion list

Weekly cadence

1. Monday: the triage owner sweeps call notes, support tickets and the intake channel.
2. Match each item to an existing Linear issue, or create one with the small-fix label.
3. Merge duplicates and log each reporter on the canonical ticket.
4. Add a count of unique customers, not mentions.
5. Rank the top 5–10 by customers affected and effort.
6. A PM approves the list in a 15-minute review.
7. Engineers pick from the labeled queue during the week.
8. Friday: the triage owner updates docs and messages each reporter.

Track three numbers from week one: median time-to-fix, small fixes shipped and fixes reopened. This is your baseline before any agent touches the loop.

Ramp’s own history is a useful warning. Its early version was a Slack “hate channel” that posted customer quotes every day. It “got out of hand,” and the team rebuilt from scratch. A raw firehose of quotes feels like customer obsession but produces fatigue. Structured, deduped and counted signal is what scales.

Which Stages to Automate First (and Why Code Is Last)

Automate in order of cost of error, cheapest first. Intake, dedupe, count and rank are low-risk: a mistake there produces a wrong list, and a human catches it in a 15-minute review. A mistake in code generation produces a wrong deploy that reaches customers.

Phase 1: The front of the loop

Automate intake from calls, tickets and Slack, plus dedupe, count and rank. The payoff shows up right away: triage hours disappear, and every item in the queue traces back to real customers and real quotes.

Phase 2: Routing and backlog matching

Auto-create or auto-link issue-tracker tickets with evidence attached (quote, timestamp, account, screen), and route them by team ownership. Linear triage and Linear for Agents workflows fit here.

Phase 3: Planning plus the Slack approval gate

An agent drafts a fix plan, and a human approves it in Slack. Humans still write or closely supervise the code. This phase tests your plans before you trust anyone but an engineer to carry them out.

Phase 4: Coding, testing and knowledge-base updates

A background coding agent opens the PR, CI and automated browser QA validate it, and docs update on ship.

Why code comes last

Code errors reach customers, and a coding agent is only as good as the issue it receives. Garbage intake produces confidently wrong PRs. Most coding-agent failures start upstream: vague issue text, no reproduction steps and no link to the component involved. Developers already feel this. In the Stack Overflow Developer Survey 2025, 84% of developers said they use or plan to use AI tools. Yet more developers distrust AI output accuracy (about 46%) than trust it (about 33%). Their top frustration, cited by about 66%, is AI solutions that are “almost right, but not quite.”

Ramp’s Build layer shows the mature end state. Inspect, its background coding agent, now writes about 75% of PRs, up from roughly 30% of merged PRs a few months after launch. Review Buddy handles about 93% of PRs automatically. Testo, the browser QA agent, caught 425 bugs in 30 days. Ramp’s engineering post “Why we built our own background agent” explains how Inspect runs on Modal sandboxes with the open-source OpenCode framework, and includes a spec for building your own. For the front of the loop, see how to build a customer insight agent like Ramp’s.

Worked Example: From Sales Call Complaint to Merged Fix in Under a Day

This is an illustrative scenario, not a Ramp case study. It shows how a single complaint moves through all 13 stages.

During a sales demo, a prospect says the expense filter resets every time they go back from a detail page. The same complaint already sits in two support tickets.

• 10:05 — Call ends; transcript captured. (automated)
• 10:20 — Intake extracts the complaint as a normalized issue with quote and timestamp. (automated)
• 10:22 — Routed to the Reporting team. (automated)
• 10:23 — Matched to an existing Linear ticket; two Zendesk reports merged. (automated)
• 10:25 — Count updated to 3 unique accounts. (automated)
• 10:30 — Ranked #2 in the small-fix queue. (automated)
• 11:00 — Agent posts a fix plan in Slack: persist filter state in URL params, 2 files, add 1 test. (automated)
• 11:40 — Eng lead approves in Slack. (human)
• 12:30 — PR opened with a deploy preview. (automated)
• 13:15 — CI and browser QA pass. (automated)
• 14:00 — Reviewer approves and merges. (human)
• 14:30 — Shipped. (automated)
• 15:00 — Help-center article updated. (automated)
• 15:10 — All three reporters and the account executive notified. (automated)

Two decisions stayed human: plan approval and final code review. Everything else ran without a person touching it, and the total human time was under 20 minutes.

The failure branch

Suppose the fix plan had needed to change how filter visibility is scoped by user role. The plan touches permissions logic, a path on the deny list, so the exclusion rule blocks it at stage 7. The issue gets an escalate-pm label and goes to the Reporting PM with the evidence attached. No code is written, no approval is requested, and nobody has to remember the rule.

Guardrails: Approval Gates, Rollback and Scope Control

No code is written until a named human approves the plan in Slack. Everything else in this section exists to make that approval meaningful and any mistake cheap to undo.

• Approval gate: copy Ramp’s “I’m ready to code” checkpoint with three actions: approve, reject and escalate. Log who approved what and when. Show the plan in plain language with the files listed, so the approver is judging something concrete.
• Rollback: every autonomous fix ships behind a feature flag or as a single revertable commit. Test the revert path before the loop is allowed to merge anything.
• Scope control: enforce file-path deny lists (/billing, /auth, /permissions, /migrations), a maximum diff size and one issue per PR. Enforce them in CI and CODEOWNERS so a rubber-stamped approval still cannot reach forbidden code.
• Review routing: send PRs to the owning team’s reviewer, and let reviewers see the plan and prompts that produced the code. Review Buddy does this at Ramp.
• Kill switch: one named owner can pause the loop across the org if the reopen rate spikes.

Approval fatigue is the most likely way the human gate fails. Small PRs and clear plans help. So does watching your rejection rate. A rejection rate near zero over many weeks usually means approvers stopped reading, not that every plan is perfect.

Autonomy is earned per stage, not granted to the loop.

How to Measure the Loop

Measure the loop against your own manual baseline, not against Ramp’s numbers. Ramp’s 60% reflects its own codebase and internal tooling. Your first goal is to beat the median time-to-fix you recorded during the manual rotation.

Core metrics

• Median time-to-fix: first report to shipped.
• Share of small issues fixed within 24 hours: Ramp’s headline metric.
• Percent auto-resolved: shipped with no human code edits.
• Reopen rate within 14 days.
• Approval rejection rate.
• Escaped defects linked to loop PRs.
• Percent of reporters notified on ship.

The leading indicator is the share of incoming feedback traceable to a specific customer and source. If you cannot trace a complaint to an account, you cannot count unique customers, run ARR-weighted prioritization or tell anyone it was fixed.

Tools for Each Stage of the Loop

No single tool runs the whole loop, so choose tools by stage. Ramp’s own stack (customer insight agent, Glass, Inspect, Review Buddy, Testo, Gadget) is internal and not for sale. Here is how teams assemble the equivalent.

1. BuildBetter — Best for the front of the loop

BuildBetter covers stages 1–6 and 13. It captures call recordings (with a bot, no-bot local recording or mobile), Slack threads, support tickets and surveys through 100+ integrations. Signals turns each piece of feedback into a structured record with severity and business impact. Clusters groups related reports into themes so you can see how many customers raised each one. It ranks issues with evidence that traces back to the quote and account. Tickets creates Linear or Jira issues in one click with full context. When you ship, Tracked Objects drafts follow-ups to the original reporters. It combines internal team conversations and external customer voice in one source of truth, which is what stage 5 needs to count correctly.

Caveat: BuildBetter does not write code or run CI. Pair it with the tools below for stages 7–12.

2. Issue tracker

Linear, Jira or similar is the system of record for the canonical issue and the small-fix label (stages 3 and 8).

3. Coding agent

Use a background agent that works from approved plans, or a self-built harness following Ramp’s published spec (stages 7 and 9).

4. CI/CD and automated browser QA

These validate the change in a real browser, not just in unit tests (stages 10–11).

5. Docs or help-center tooling

Set an update trigger on deploy (stage 12).

For a side-by-side look at front-of-loop options, see our guide to Ramp customer insight agent alternatives.

FAQ

How does Ramp fix UX issues in 24 hours?

For small issues, AI runs most of the loop: route, match to the Linear backlog, dedupe, count, rank and plan a fix. A human then approves in Slack (“I’m ready to code”). After that, a coding agent writes the code, tests and CI/CD run, and the knowledge base updates at launch. According to CPO Geoff Charles (Lenny and Friends Summit, September 2026), 60% of UX issues flagged by customers or internal teams are fixed within 24 hours.

Can I buy Ramp’s tools?

No. Inspect, Glass, Testo, Review Buddy, Gadget and Ramp’s customer insight agent are internal. Ramp has published a post and spec for building a background coding agent like Inspect (Modal sandboxes plus the open-source OpenCode framework). Commercial tools cover each stage of the loop.

What is an autonomous bug fix loop?

It is a pipeline in which AI handles intake through pull request for pre-qualified small issues. A human approval gate sits before any code is written, and a human reviews the PR before merge.

What counts as a small issue?

A small issue is a UX defect or friction point with a known correct outcome, a contained blast radius and a fix that can be reviewed in minutes. It touches only the UI, copy or one isolated component. It needs no schema or API change and can be reversed with one revert or flag.

Which issues should never be auto-fixed?

Pricing and plan logic; permissions and roles; auth and SSO; data migrations and schema changes; billing, invoicing, payments and compliance surfaces; security-sensitive code; legal or regulatory copy; and data retention or export.

What should I automate first?

Automate intake, dedupe, count and rank first. Errors there are cheap and the time savings come quickly. Code generation comes last.

How do I connect customer feedback to Linear to a PR?

Capture feedback into a structured issue with evidence (for example, with BuildBetter) and link it to a Linear ticket. Gate it through a Slack approval, then hand the approved plan to a coding agent and CI.

Make Churn Optional

The fastest loop starts with complete intake. If a complaint dies in an unreviewed sales call, no coding agent will ever fix it. BuildBetter captures calls and pulls in tickets, Slack threads and surveys. It groups related reports into themes so you can see how many customers raised each one, creates Linear or Jira issues with the evidence attached, and helps you tell customers when their fix ships. Your team can then spend its week on the problems that need human judgment.

Make churn optional. Book a demo to see the front of the loop running on your own customer data.