I've spent a lot of hours lately watching AI coding agents work, and one thing keeps bugging me: they read code like it's a novel.

Ask most agents to fix a bug three files deep, and they'll grep around, open a file, skim it, open another, lose track of what they already read, and open the first one again ten minutes later. Not because the model is dumb but because the way we're feeding it code doesn't match what code actually is.

Code isn't prose. It's a graph. Functions call other functions. Classes inherit from other classes. Modules import each other in patterns that took your team months to build and that no README fully captures. When you flatten all of that into a wall of raw text and hope the model "gets it" from context, you're throwing away almost everything that makes code legible in the first place which is the structure.

That's the part I keep coming back to: agents need structure, not more raw code. Consider this me thinking out loud, not an announcement of something finished. Most of what follows is still a hypothesis I'm chasing, not something I've proven.

The easy objection is "just give it a bigger context window." I used to believe that too, honestly. But the evidence doesn't really support it.

Anthropic's own research and, separately, Chroma's "Context Rot" study both point at the same uncomfortable finding: model recall degrades as the token count climbs, even well inside the hard limit of the context window. It's not that the model runs out of room instead it's that attention gets diluted the more you cram in. The older "Lost in the Middle" paper found something similar years earlier: facts near the start or end of a long context get recalled reliably, facts buried in the middle quietly get dropped.

So a bigger window doesn't fix flat context. It just moves the cliff edge further out. The actual fix, I think, is giving the agent structure to navigate, not more text to wade through.

Here's the bet: instead of dumping files, give the agent a structural map of the codebase something like a graph where every function, class, and file is a node, and the edges are the real relationships: "calls," "imports," "defines," "is referenced by." When the agent needs to touch a function, it doesn't skim four files hoping to spot every caller. It walks the graph, pulls the exact neighborhood it needs, and stops there.

This isn't an idea I invented in a vacuum , there's real academic groundwork here. RepoGraph, a paper that made it into ICLR 2025, plugged a repository-level code graph into existing AI software engineering pipelines and measured a 32.8% average relative improvement across the LLM frameworks tested, on top of catching localization mistakes that flat retrieval kept missing. That's a meaningful result. It's also, and I want to be honest about this, a result on specific benchmarks with specific repos , not a guarantee it holds up on the messy, half-abandoned, six-different-code-styles codebase most of us actually work in day-to-day.

On the tooling side, I've been experimenting with graphify, an open-source, MIT-licensed project that turns a folder of code into a queryable knowledge graph locally, without shipping anything off to a server. I didn't build the underlying graph-construction work, and I'm not claiming credit for it , what I'm actually interested in is what an agent can do once it has a graph like that to query, instead of a filesystem to grep blindly.

The obvious pitch is "it saves tokens," and sure, scoping context tighter does that. But the part I actually care about is precision. A flat-text agent is guessing which files matter based on filenames and vibes. A graph-aware agent can ask a real question , "what calls this function, and what does it call in turn" and get a real answer instead of a probabilistic one.

My hunch is that this cuts down on a specific, annoying failure mode: the agent that confidently edits a function without noticing three other call sites now expects the old signature. If the agent can walk "who references this" before it touches anything, that class of mistake should get rarer. Should. I haven't proven it yet, and I want to be upfront that "should" is doing a lot of work in that sentence.

There's also a scaling angle I think about: right now, every agent session re-discovers the codebase from scratch meaning grep it, read it, forget it, repeat next session. A persistent structural map means that work only has to happen once, and could in principle be shared across multiple agents working the same repo instead of each one independently reinventing an understanding of code that hasn't even changed.

I want to be honest about the open questions, because the theoretical version of an idea always sounds cleaner than the real version:

• Codebases change constantly. Keeping a graph in sync with active edits, without it going stale mid-session, is a real engineering problem, not a footnote.
• Small projects might not need this at all i mean building and maintaining a graph has overhead, and for a 200-line script it's probably pure cost with no payoff.
• Messy, legacy, heavily-generated, or wildly inconsistent codebases are where this idea is least tested. The academic results are encouraging, but they're not from the kind of half-documented monorepo most of us actually inherit.

None of that makes me want to drop the idea. It makes me want to actually test it instead of just believing it because it's a satisfying story.

So that's where I'm at , a strong hunch, some real prior art backing the direction, and a genuinely open question about whether it holds up outside of a benchmark. I'm building a harness right now specifically to test this: running the same set of realistic coding tasks with flat file access versus graph-scoped access, and actually measuring what changes , not just tokens, but correctness, and how often the agent breaks something it didn't know it was touching.

I'll write about what the harness turns up, good or bad. If the idea doesn't hold, I'd rather know that from data than keep believing it because it sounds right.