You reduce developer interruptions from support by sorting questions on two criteria — where the answer lives, and who can reach it unaided — then handling each case exactly once. Writing more documentation closes only one of those cases. The most frequent one covers answers that exist nowhere in prose: they live in a diff.
The sorting matters more than the tooling. A team that answers "we should document better" to every escalation rewrites, every quarter, a knowledge base that each deployment makes stale — and interrupts its developers for the same reasons as before.
The four cases of an escalated question
A question that reaches support and bounces to a developer sits on two axes. First: where the answer lives, in a written artefact (help center, changelog, release notes) or only in the code and its history. Second: who can reach it, the person asking or only someone with repository access.
Four cases, then, and they do not call for the same move.
| The answer is written somewhere | The answer exists only in the code and its diffs | |
|---|---|---|
| The asker can reach it alone | Case 1 — a findability problem | Case 3 — the empty cell |
| Only a developer can reach it | Case 2 — a trust problem | Case 4 — the guaranteed escalation |
Case 1: the answer is written, and the asker eventually finds it. When it escalates anyway, nothing is missing from the knowledge base; search or structure is at fault. This is the only case that "let's document better" genuinely closes.
Case 2: the article exists, but nobody believes it. After three stale answers served to customers, a support agent stops trusting the page and asks a developer to confirm, even when the page is right. The artefact is there; what it lost is its authority. A help center derived from the code rather than hand-rewritten attacks that case, as our piece on why knowledge bases drift sets out.
Case 4: the question has no written answer anywhere. "Since Tuesday the export takes two minutes instead of ten seconds — is that intended?" No page carries that answer. It sits in a diff, and in the intent of the commit that shipped it. This is the classic post-release mystery ticket, and it produces most of the direct messages developers get.
Case 3: the cell is empty, and it is empty by design. Getting an answer that exists only in the code has always meant getting access to the code. A support agent has no cloned repository, a customer success manager has none either, and a customer certainly does not.
The empty cell is the only place left to win
Cases 1 and 2 have been tooled for years: search, structure, artefact freshness. Case 4 does not shrink by writing — nobody drafts an article in advance for every modified behaviour.
That leaves case 3: making an answer derived from the code reachable by someone who does not have the code. That is the job of a queryable product expert — one MCP server per project, connected read-only to the repository, answering in sourced sentences instead of handing out credentials.
Illustrative example — invented figures, used to carry the reasoning, not a customer measurement: out of twelve escalations in a week, three are case 1, two are case 2, seven are case 4. Documenting better removes three. Filling case 3 moves seven to the support agent, who no longer needs a developer to close them — and those are precisely the ones that land the day after a deployment.
"Did this ticket come from a release?"
That is the question support actually asks, and it is almost never written down anywhere. Put to an expert connected to the repository, it resolves by comparing the diffs between the last two deployments: the change is named, dated, tied to its commit, and the intent behind that commit comes with it.
Two properties make the difference. The source is re-synced on every push, so the answer does not age between two writing sessions. And it comes back as prose rather than a file excerpt: support relays it to a customer without opening the code.
What stays an interruption, and should
A share of escalations has nothing to do with access to knowledge. The answer does not exist yet.
"Will we support this format?", "when does it ship?", "can this customer get an exception?" — these are decisions, and no source derived from code contains them. A product expert decides nothing. It reports what the code does and what the commits said they meant to do.
Live incidents and prioritisation calls fall outside the frame for the same reason. A team hoping to remove every interruption is mostly preparing to manufacture new ones: invented answers come back as tickets.
"A developer with the right tools does this with git log"
True, and they do it better than any tool. With the repository cloned and a solid feel for the history, git log -S then git blame answer a case 4 question in minutes.
Two limits, and both are in the premise. The first: that answer is only available to the person holding the repository — the very person you were trying not to interrupt. Routing every question through them is the original problem plus one step. The second: git log reads what was written in commit messages. When those messages say "fix" or "wip", the answer to "is this intended?" is not in them; it is in the diff. The official GitHub MCP server inherits the same boundary: excellent for an equipped developer, silent for an asker without credentials.
"And that expert reads your repository too"
The objection turns back on us, and it is fair: to answer in a developer's place, something has to read the code.
It does, inside a frame that holds in four points. The GitHub connection is read-only. There is one server per project, not a blanket grant. What leaves is answers sourced on commits and diffs, never files handed back as-is. And access is revocable at any time.
So what changes is not the number of readers your repository has. It is that askers get answers without getting access.
Mini-FAQ
Should we stop writing documentation? Absolutely not: cases 1 and 2 are closed by well-organised prose. Documentation holds slow-moving material very well — installation, concepts, known limits. What it holds badly is whatever changes at every deployment.
Can support answer without understanding the code? That is the condition for the whole thing to be worth anything. The answer arrives as prose, with its date and the commit it came from; the agent relays and cites. If they have to interpret a code excerpt, the interruption moved rather than disappeared.
What if our first line of support is an AI agent? Same path: agent platforms accept custom MCP connectors, as our guide to connecting Intercom Fin to your codebase shows. The agent queries the expert before answering, and stops inventing what it does not know.
How long before the difference shows? The right unit is not the week, it is the deployment: case 4 questions arrive in bursts the day after a release. If that particular morning goes by without a direct message to a developer, the sorting worked.
What to remember
Interruptions do not shrink by asking support to be more self-sufficient. They shrink by looking, question by question, at where the answer lives and who can reach it.
Three of the four cases already have their tool. The fourth, and most frequent, is waiting for a path between a question asked in plain language and a git history the asker is not allowed to read.
DeployIt is free during early access; paid plans arrive in January 2027. The MCP server stays in early access: the design partner program is open to teams who want to test this sorting on their own ticket queue.
Frequently asked questions
How do you reduce developer interruptions from support?
Sort the questions on two criteria — where the answer lives, and who can reach it unaided — then handle each case once. Better documentation closes the questions whose answer is already written down; questions whose answer exists only in a diff need a different path, one that hands the asker an answer without handing them repository access.
Does that mean writing less documentation?
No, and cutting documentation is the fastest way to raise the number of escalations. Written docs remain the right answer for what changes slowly: installation, concepts, known limits. What they hold badly is whatever moves with every deployment.
Can a support agent answer without understanding the code?
Yes, when the answer arrives as sourced prose rather than a code excerpt: the sentence, the date of the change, and the commit it came from. The agent relays and cites; reading the repository is never required.
Which questions will keep reaching developers?
The ones whose answer does not exist yet: a product decision, a prioritisation call, a trade-off, a live incident. No source derived from code covers those, and it is healthy that they escalate.