My code map was wrong about my own repo. So I taught it to learn.

You ask your agent to find the code behind a bug. It keeps pulling the same irrelevant file into context, every time, because its map of your repo says that file matters.

That happened to me. A formatter buried in a side app was ranked the single most important symbol in my entire codebase.

Not top ten. Number one. Above the agent loop, above the session store, above everything that actually matters. Whenever the agent looked for context, that formatter was near the top.

The ranking wasn't wrong, exactly. A lot of code referenced the formatter, so by reference count it looked like a hub. But nobody who had worked in that repo for a week would have called it important.

The map was reading the code. It wasn't reading how I work.

Everything below shipped in 3.5.0-beta. The numbers come from running it on Empryo's own repo.

A static map misses how you workLink to this section

Empryo keeps a live map of your code called the Genome: every file, its exported symbols, and who depends on what, ranked so the important parts come first. Most coding agents that index a repo do something similar. They parse the files, build a graph of symbols, rank it, and put the top slice into the model's context. Aider made this approach popular years ago and deserves credit for it.

But a map built only from the code knows what the code says. It has no idea what you do.

It misses three things:

Files that always change together but never import each other. The migration and the config. The route and the test fixture. The type and its mock. Nothing in the code connects them, yet changing one without the other breaks your build.

The file you always open before editing another one. That's a real dependency. It just lives in your head.

Reads that led nowhere. Static analysis has no way to know that the agent opened a file and it turned out to be useless.

Teaching the map to learnLink to this section

I added three sources of learning. All of them are cheap, and none of them call a model.

Git history, scored properly. Simply counting how often two files change together doesn't work, because some files change with everything. Your lockfile isn't tied to your whole repo. It's just noisy. So the Genome uses a statistic called pointwise mutual information. It asks whether two files change together *more often than chance would predict*. Real pairs stand out. A file that changes with everything scores close to zero, which is correct.

The scoring follows renames, so moving a file with git mv doesn't erase what the map learned about it. It skips housekeeping commits, because a release that bumps 40 version numbers says nothing about how those 40 files relate. And I raised the history window from 300 commits to 2,500. That change mattered more than anything else here. On any active repo, 300 commits missed most of the history.

What the agent actually did. Every session leaves a trail: which files the agent read, in what order, and before which edit. The Genome turns those into patterns. Files read together. The file opened before another. The reads that went nowhere.

The risk is learning from noise. So at the end of each session, a check marks which patterns actually helped. Patterns that keep helping become permanent. The rest fade over time. One lucky session doesn't teach the map anything lasting, and it shouldn't.

How your model responds to hints. I didn't expect to build this part. Different models react to hints differently. If a model keeps ignoring a type of hint, Empryo shows fewer of them. When the model starts acting on them again, they come back. And when you click a search result to open a file, that click counts toward future ranking too.

What it did to my repoLink to this section

empryo's own repo · static graph vs learned genome
──────────────────────────────────────────────────
co-change coverage      86  →  3,239  file pairs
edit-advisory pool      14  →    444  entries
side-app formatter      #1  →   #103  rank

The formatter went from first to 103rd. The code didn't change. The map just stopped confusing "referenced a lot" with "important".

Most of the jump from 86 to 3,239 co-change pairs came from the larger history window. The map had been looking through a keyhole.

Why this saves moneyLink to this section

Fixing a bug is two jobs: find where it lives, then change it. Changing it is cheap. Finding it is expensive, because every file the agent opens while searching stays in its context and gets billed again on every later step.

That's why a better map matters. In a head-to-head test on real bugs from hono, zod and ky, released after the models' training cutoff, an agent with a map used 5.7× fewer input tokens than one without, and fixed more bugs. On the cheaper model tier, the mapped agent fixed 3 of 5 where the unmapped one fixed 2 of 5.

Give a small model a map and it stops acting like a small model. I've come to think a lot of what we call model capability is really search budget.

What I'm not sure aboutLink to this section

This was measured on one repo: mine. It's the repo I know best and the one where I notice ranking mistakes, which makes me the wrong person to grade it objectively.

A learning system can also learn the wrong thing with confidence. That's why patterns have to prove themselves before they stick, and why they fade otherwise. I'd rather it learn slowly than be sure about nonsense. Whether the balance is right on a repo with fifteen contributors instead of one, I don't know yet. If you try it on a big team repo, I'd like to hear what it gets wrong.

Testing catches bugs. It doesn't tell you whether the idea itself is right.

The map is built on your machine, with your keys, and building it costs no model tokens. Empryo is at empryo.com.