Your AI coding agent can read 1,000 files and still miss the one that matters.
The failure usually isn’t “the agent can’t find the code.” It’s this: The agent finds createSession , changes it, runs the nearest test, and says “done.” It misses the worker that calls refreshSession , the test that asserts cookie flags, and the retry path that assumes the old TTL. The diff looks
Posted on Oct 21 • Originally published at tryglyph.dev
The failure usually isn’t “the agent can’t find the code.”
The diff looks clean. The bug shows up under load.
That’s not a coding failure. It’s an evidence failure.
The agent wasn’t bad at writing code. It was missing the connections between pieces of code.
“Where is this session state established, and what would break if I changed it?”
A normal search finds the function name. Answering the real question requires more:
Search returns files. What the agent needs is a route:
Implementation → Callers → Tests → Blast Radius → Verification
Glyph is a code context engine that connects to AI coding agents through MCP.
It combines semantic search, keyword search, symbol relationships, and dependency data so the agent starts with better evidence instead of burning its context on file-by-file exploration.
The description gets the agent to make the right call. The result determines the next call. If either one is vague, the agent falls back to grep, reads too much, and still misses the connection that mattered.
That’s why Glyph is MCP-first, not another chat window. The agent already has a loop. Glyph puts better tools inside that loop.
It also starts with sync_working_tree. If the agent’s uncommitted edits aren’t in the overlay, every answer is about a repository that no longer exists.
Most agent failures I see are last-mile failures.
The agent has enough context to make a change. What it doesn’t have is a cheap, honest check before it says “done.”
verify_change is that terminal call. It returns a compact receipt — what was checked, what is still open, which tests to run, and what was not checked. The same receipt also lands in the console.
That receipt matters twice: it gives the agent a stopping condition, and it gives the developer something to inspect without reading the transcript.
It doesn’t run tests or pretend to. It tells the agent what to run and what it couldn’t verify.
Agents are already good at knowing where things are. The hard part is knowing what else depends on the line they’re about to change — and knowing when the change is actually safe to call done.
Glyph isn’t trying to replace the agent or write code for you. It’s trying to give the agent better evidence and a real stopping condition.
I test it against real repositories and publish the cases where it loses, alongside the wins. I’d rather show a receipt than a highlight reel.
When your coding agent struggles with a large repository, what’s usually the biggest problem?
I’d genuinely like to hear what people are experiencing. Feedback from developers working in real codebases is more useful than another polished demo.