I connected friction data to a coding agent. Here’s what happened.

Most analytics workflows stop right before the part teams actually care about. You wanted the bug fixed. What you got was proof the bug existed.

Everything between those two points was a relay run by humans: someone spots the friction, writes it up, files a ticket, and tries to explain to an engineer what a customer they never met experienced on a page nobody screenshotted. The engineer tries to reproduce it, digs through the code, and ships a fix a week or two later. Information leaks at every handoff. And the small stuff, the papercuts that each cost you a rounding error but add up to real money, mostly dies in the backlog, because it is not worth the effort to route.

I got tired of assuming that relay had to exist. So I tried to remove it.

Using the friction data Quantum Metric captures out of the box and our MCP server, I wired the whole thing together: friction detected on a site, handed to a coding agent with the codebase in front of it, turned into a drafted, reviewable fix. I ran it end to end as a proof of concept, and it worked. Here is how it fits together, and why I think it is a preview of where this is going.

One caveat up front, because I would want it if I were reading this. This is something I built to prove the pattern, not a button you turn on in the product today.

The ingredients are real: Quantum Metric’s out-of-the-box capture and our MCP server, currently in beta. The specific loop I describe here is something I wired together by hand.

The friction is already captured. That is step one.

If you run Quantum Metric, the raw material is already there, and you do not have to tag anything to get it. Quantum Metric autocaptures the signals of a struggling user out of the box (https://www.quantummetric.com/blog/digital-product-managers-its-time-for-less-tracking-code-and-more-insights): rage clicks, disabled input clicks, JavaScript and API errors, slow pages, failed form submissions, abandoned flows. Nobody had to predict in advance that the promo code field would break, or that a Thursday release would take out checkout on one browser. The whole session is captured, so the evidence is sitting in your data the moment it happens.

Capturing friction was never the hard part for teams on Quantum Metric. The hard part came next: turning that signal into an actual change in the product. That is where the chain broke.

The missing link was context, and MCP supplies it.

A coding agent like Claude Code is genuinely good at fixing code, as long as it understands two things: what is broken, and how your codebase is built. The second half is easy. Point it at your repo in GitHub and it reads your components, your conventions, your history. The first half was the problem. The agent had no idea what real customers were hitting, because that lived in a separate system it could not see.

That is the gap our MCP server closes. MCP (the Model Context Protocol) is an open standard that lets an AI agent plug into an outside system and actually use it. Our server exposes Quantum Metric's experience data to the agent, so it can ask your analytics what is breaking right now and get a specific, grounded answer instead of a guess.

And Quantum Metric does not have to be the only thing feeding it. The same agent can pull in the rest of your evidence trail through their own connections: backend telemetry and logs to confirm an error server-side, your APM to see the failing call, your release history to line the problem up with a deploy. Quantum Metric tells it what the customer experienced. The telemetry tells it what the system did. Together that is most of what a senior engineer would gather before touching a fix, assembled in seconds instead of across an afternoon of Slack threads.

What the loop actually looks like.

Let me make it concrete with a scenario. Numbers here are invented, but the shape is exactly what I ran.

Thursday, 9:14 PM. A release ships. Within the hour, Quantum Metric starts logging a cluster of rage clicks and PROMO_VALIDATION errors on the payment step. It is narrow: only logged-in users, only on mobile Safari, only when a promo code is applied. Overall conversion barely twitches, so no threshold alert fires and no dashboard has a cut for that exact slice. In the old world this hides until Monday.

Instead, the analysis runs on its own overnight. It confirms the drop is real against baseline (checkout completion for that segment fell from 71% to 46%), isolates where it concentrates, cross-checks the backend logs to confirm the promo service is throwing 500s for that path, and lines the start time up against the 9:14 PM deploy. It sizes it too: roughly 1,200 affected sessions so far, about $18K in stalled revenue a day if it keeps going. None of that needed a human awake.

From there the agent, holding both the Quantum Metric findings and the repo, locates the component handling promo validation, spots the likely cause in the diff that shipped, and drafts a fix. Then it does the part that used to eat a week. It opens a pull request in GitHub, and it files a ticket in Jira as the record: what customers hit, the affected sessions and revenue, the suspected commit, and a link to the PR. Your developer opens that ticket to a full picture instead of "checkout seems broken for some people?"

The relay that used to run analyst to ticket to engineer to reproduction to fix now runs detection to diagnosis to pull request, and the human shows up exactly where human judgment belongs.

Why a human still owns the merge button.

I built it this way on purpose. The loop stops well short of shipping code to production untouched. Everything up to the merge is handled. The merge stays a person's call.

The output is a pull request, never a deploy. A developer reads the change, checks the reasoning, tests it, and decides whether to merge, revise, or throw it out, the same gate every other change goes through. That is the honest design, and it is the only version that survives contact with a real enterprise. The machine is not pushing code to your customers on its own. It is doing the tedious middle, the reproduction, the root-cause hunt, the first draft, so your engineers spend their time judging a solution instead of assembling one from a screenshot.

The reason you can trust the PR is that you can see how it got there. Every step is grounded in captured evidence and laid out in the ticket: here is the friction, here are the sessions, here is the failing call, here is the commit, here is the fix. It is not a black box asking for faith. It is a diagnosis you can check.

What changes when the gap closes.

Two things jumped out once it was running.

The obvious one is speed. What is normally a multi-day relay collapsed to minutes, because the handoffs that eat most of the time were gone.

The subtler one is which problems get fixed at all. When routing a small issue costs more than the fix is worth, it gets ignored, and small issues are where quiet revenue leakage lives. Drop the cost of turning friction into a reviewable PR close to zero and the math flips. The papercuts nobody would file a ticket for suddenly clear, and in aggregate they often outweigh the one big bug everybody was watching.

In hindsight, this is the thing I kept circling. An AI analyst has to reason over raw experience data instead of fetching what someone pre-built, which I got into in Is your AI analyst actually a fetcher. The capture underneath has to be complete enough to diagnose problems nobody anticipated, the case our team made in Why most agentic analytics will fail without experience-level data. Detection, diagnosis, and now a first draft of the fix, all in one loop.

Analytics has been telling us what is broken for years. What I find genuinely exciting is how close it is now to handing your engineers the fix. The pieces are already here. I just connected them to see what would happen.

Want to see the parts that made it work? The capture and the MCP server are real and available today: explore Felix AI Agentic.