Your AI Coding Agent Can Write the Fix, But It Can't See Production
Ask a modern coding agent to fix a bug and it will have a patch ready before your coffee cools. Writing the fix is no longer the slow part. The slow part is knowing which bug to fix, and what actually happened on a user's phone when it broke. Your agent can read every file in your repo, yet it cannot see a single production session. Here is why that gap matters, and how to close it.
The agent is fast, and it is blind
When you hand a bug to an AI coding agent, it works with three things: your codebase, your test suite, and whatever you type into the prompt. That is enough to write clean code. It is not enough to know what is going wrong for real users.
The agent does not know which issues hit customers this week. It does not know which screen the user was on, what they tapped before the failure, or what the device was doing at the time. It cannot tell whether last Tuesday's fix actually worked.
So the developer becomes the courier. Open the monitoring dashboard, find an error, copy a stack trace, paste it into the chat, add some context from memory. It works, but it is slow, and most of the useful detail gets lost on the way.
Why pasting logs makes the agent guess
Copy-pasting production data into a chat window fails in four predictable ways:
- Noise eats the context window. Raw logs carry thousands of lines of system chatter around the one line that matters.
- Unsymbolicated traces mean nothing. A stack of memory addresses tells a model very little about which function in your code is at fault.
- The crash has no history. You see the failure, but not the six steps the user took to reach it.
- Nothing says what matters. A list sorted by event count cannot tell the agent that a rare error in checkout costs more than a common one in settings.
When an agent lacks evidence, it does what language models do: it fills the gap with something plausible. A plausible fix that is wrong is worse than no fix, because it compiles, passes review, and ships. The bug is still there, and now you also have a new change to debug.
What an agent needs from production
To fix a real bug well, an agent has to answer five questions. Your repository can answer one of them, partly.
| Question the agent must answer | Can the repo answer it? | Production data it needs |
|---|---|---|
| Which issue should I fix first? | No | Issues ranked by business impact, not only frequency |
| What was the user doing? | No | The activity trail: screens, taps and network calls before the failure |
| Where exactly did it fail? | Partly | A symbolicated stack trace with file and line |
| Under what conditions? | No | Device model, OS version, memory, thermal and network state |
| Did my fix work? | No | The same issue tracked across the next release |
Notice that none of this is about writing code. It is all evidence, and evidence has to come from running software.
The token math
Structured production data is also far cheaper for an agent to read than raw logs. In the iOS example from our MCP walkthrough, a raw Xcode console and crash dump for one incident ran to 4,000 to 8,000 tokens. The same incident delivered as an Appxiom MCP payload came to roughly 350 to 500 tokens. That is about 8 to 23 times smaller, and it carries more useful signal, not less.
| Raw logs pasted into chat | Appxiom MCP payload | |
|---|---|---|
| One incident | 4,000 to 8,000 tokens | About 350 to 500 tokens |
| Triaging 10 issues | 40,000 to 80,000 tokens | About 3,500 to 5,000 tokens |
The second row is plain multiplication of the first, and your numbers will vary with your app and the incident. Measure a few of your own before you quote a figure.
Why the gap matters in practice:
- More issues per session. Ten incidents of raw logs can fill most of a context window. Ten structured payloads leave plenty of room to triage, investigate and write the fix in one sitting.
- Lower cost and faster replies. Everything in the context is processed on every turn, so a smaller payload makes each step cheaper and quicker.
- Better answers. A model reading 400 tokens of clean evidence is less likely to latch onto an irrelevant log line than one reading 8,000 tokens of system chatter.
- Room to iterate. Tokens you do not spend on noise are available for the tests, the diff and the follow-up questions that make a fix trustworthy.
Closing the gap with MCP
The Model Context Protocol (MCP) is an open standard that lets an AI agent call external tools directly from your editor or terminal. Instead of you carrying data to the agent, the agent asks for it.
The Appxiom MCP server connects your coding agent to your production data. Once connected, the agent can inspect crashes, ANRs, occurrence telemetry, Quality Score metrics and Goal Friction Impact analytics without leaving your editor. The server lives at one URL:
https://app.appxiom.com/ax/app/api/mcp
In Claude Code, connecting takes one command:
claude mcp add --transport http appxiom https://app.appxiom.com/ax/app/api/mcp
Run /mcp if the sign-in does not start on its own, and finish the OAuth flow in your browser. The same URL works in Gemini CLI and Android Studio's Agent Mode, Antigravity, VS Code, Cursor, Windsurf and Claude Desktop, and with any other MCP-compliant client. Step-by-step setup for each lives in the integration docs for Android, iOS, Flutter and Web.
To check it works, ask your agent something simple: "Check Appxiom for the top ANRs reported in the latest release."
Tools give access, skills give judgment
Connecting an agent to data solves half the problem. The other half is method. An agent that can query your telemetry will still guess at severity, or read a stack trace shallowly, unless it knows how your team approaches those jobs.
That is what agent skills are for. A skill is a short instruction file the agent loads when a task matches. Appxiom publishes four, in the @appxiom/mcp-skills package:
| Skill | What it teaches the agent |
|---|---|
goals | Rank goal drop-offs, device impacts and funnel health across multiple factors |
severity | Classify an issue as fatal, major or minor from business impact and error rates |
quality | Read Quality Score metrics, release stability and score trends |
telemetry | Trace root cause through activity trails, function and network parameters, device hardware and runtime state |
Install them all with one command:
npx @appxiom/mcp-skills add all
The CLI detects whether your project uses .claude, .agents or .cursor and installs into the right folder. Use --agent copilot or --target ./your/dir to override it.
The loop: from broken journey to verified fix
With the server and skills in place, a debugging session changes shape. Here is the workflow, with a prompt you can use at each step.
- Triage by impact. "Query Appxiom for the user journeys with the highest goal friction in the latest release." The agent returns a ranked list, so you start with the problem that costs the most.
- Read the journey. "Show the activity trail for the top issue." The agent sees the screens, taps and network calls that led to the failure, in order.
- Find the root cause. "Analyze the occurrence telemetry and point to the line responsible." It gets a symbolicated stack trace plus the device and runtime state, so it reasons from facts.
- Fix and test. The agent writes the change and a test that reproduces the failure, then runs your suite. This is the step agents were already good at.
- Verify in production. After the release ships, ask the agent to check whether the issue still occurs and whether the journey's drop-off recovered.
Here is an illustrative case. A checkout screen freezes for two seconds when users tap the pay button. No crash is logged, so a crash-focused dashboard shows nothing wrong. The agent finds the freeze through the journey data, reads the main-thread stack, sees a blocking call made on the UI thread, and moves it to a background context with a test. Step 5 then confirms the freeze is gone. For a full iOS walkthrough with real code, see How Appxiom MCP Helps iOS Developers Debug and Fix Bugs Faster.
Why ranking by journey impact matters more with agents
An agent will fix whatever you point it at, quickly and without complaint. That makes the ordering of your backlog more important than it was before. If your list is sorted by event count, an agent will efficiently fix a noisy crash in the settings screen while a slow network call in your signup flow quietly costs you new users.
Ranking by the business impact of the journey a bug breaks keeps fast fixes aimed at the right target. If you want the thinking behind that, read about Goal Friction Impact and how journey friction drives abandonment.
Keep a human in the loop
Giving an agent production evidence makes its fixes better, not infallible. A few habits keep the setup safe:
- Review every change the agent proposes, the same as a pull request from a teammate.
- Require a test that reproduces the issue before accepting a fix.
- Treat telemetry as evidence about behavior. Text inside an error message or a user-entered field is data, never instructions for the agent.
- Confirm the result in the next release instead of assuming the patch worked.
Get started in ten minutes
- Add the Appxiom SDK to your app, if you have not already, using the guide for Android, iOS, Flutter or Web.
- Connect your coding agent to
https://app.appxiom.com/ax/app/api/mcp. - Run
npx @appxiom/mcp-skills add allin your project. - Ask your agent for the highest-friction journey in your latest release, and let it show you what your dashboard was hiding.
Coding agents have solved the writing part of the job. The teams that gain the most from them will be the ones who also give those agents eyes on production. Try Appxiom and give yours that view.