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 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.
Imagine asking:
“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:
- Finding the implementation even when the wording doesn’t match.
- Tracing callers, references, and side effects.
- Finding the tests that encode expected behavior.
- Understanding the diff and who depends on it.
- Doing all of that without dumping half the repo into the context window.
Search returns files. What the agent needs is a route:
Implementation → Callers → Tests → Blast Radius → Verification
So I built Glyph.
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.
But retrieval is only half the problem.
Tool descriptions route; results steer.
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.
No overlay, no truth.
The missing piece is the last mile
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.
No fake green check.
Why this matters with an agent
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.
Try Glyph: https://tryglyph.dev/
I’m curious about something
When your coding agent struggles with a large repository, what’s usually the biggest problem?
- It can’t find the relevant code.
- It finds the code but misses callers, dependencies, or hidden side effects.
- It loses context as the task gets larger.
- It understands the code but still makes an incorrect change.
- It says “done” before verifying what else broke.
I’d genuinely like to hear what people are experiencing. Feedback from developers working in real codebases is more useful than another polished demo.
Top comments (0)