Daniel's been living in Claude Code all day, every day, and there's this little ritual he's gotten tired of. He switches into a repository, fires off a prompt, and Claude says, let me just get acquainted with the repository first. Perfectly polite. But Daniel's question is, why does this keep happening? Why does an agent that's worked in this repo before, maybe hours ago, have to introduce itself to the codebase from scratch every single time? We've had vectorization for years. Graph databases. The capacity to build an agent-readable map of a repository and persist it. So his ideal version is, send Claude a task in a repo it knows, and it instantly loads up a persistent map and gets to work. He's surprised this doesn't exist, or if it does, that nobody's wired it into the harness. And he's asking directly, does the technology exist, maybe in third-party tooling outside the harness? And if it does, can it be system-prompted in? Something like, before responding to the first prompt in a session, check for the map.
The answer is more interesting than just, no, it doesn't exist. Because the technology absolutely does exist. The question is what kind of memory Claude Code actually has, and the answer turns out to be, instruction memory, not structure memory. The harness remembers how you like to work. It does not remember what your repository looks like.
That's the distinction that anchors the whole thing. Daniel's asking for structure memory. A map of the codebase. What Claude Code ships with is instruction memory. CLAUDE.md files, auto memory, rules, skills. Those are all notes to self about preferences and conventions. They say, run tests this way, use this naming pattern, don't touch that directory. They don't say, here's the dependency graph, here's where the entry points live, here are the files that matter.
And the reason the get acquainted step exists at all is that context windows are finite. A repository's full contents vastly exceed what fits. Even with the big context windows we have now, a serious codebase is millions of tokens. You cannot load it all. So the agent has to triage. It scans the tree, looks at the task, and pulls in the files that seem relevant. The acquaintance pass is a triage mechanism, not a failure of memory.
It's the agent doing a quick sort of the room before it starts the actual work. And the thing is, that pass is fast. For most repos, it's a few seconds. The annoyance Daniel's feeling is the repetition, not the cost of any single pass.
Right. And this is where the design choice gets interesting. The harness treats sessions as independent. Each one starts fresh. Now, conversation compaction exists, and it preserves the conversation. There's a three-tier architecture, a separate model call for summarization, all of that. But compaction preserves what was said. It does not preserve a structural map of the repository. Those are different memory systems entirely.
So even if you had a long conversation about the repo yesterday, and the compaction summary captured all of that, the summary is about the conversation, not the codebase. It's like having notes from a meeting about a building, but not the blueprints.
And then there's the hidden context tax. Bigger context windows do not mean unlimited working memory. If you load a full repo map into context at the start of every session, you're spending budget that should go to the actual task. The acquaintance pass keeps the working context lean. It's a tradeoff, and the tradeoff favors not pre-loading everything.
So the design is defensible. But Daniel's frustration is still real, because the tradeoff is being made on his behalf, every session, even when he knows the repo hasn't changed since the last time he was in it.
And that's the staleness problem. A persistent map would have to know when the repo changed. Branches, commits, new files, deleted files. If you cache a map and the repo moves under you, the map lies. The acquaintance pass guarantees freshness. It's choosing correctness of current state over speed of recall. Which is, honestly, the right call for a coding agent. You do not want Claude confidently working from a stale map.
No, you don't. Because the failure mode is subtle. It's not that the map is obviously wrong. It's that it's slightly wrong, and the agent makes decisions based on files that no longer exist or functions that have moved. That's worse than spending five seconds re-scanning. It's like using a GPS that still thinks a bridge exists. You don't find out until you're already committed to the route.
And a coding agent that's confidently wrong is more dangerous than one that's slowly right. The slow part is the feature.
So the current design is, the harness has not built structure-shaped memory. It's built instruction-shaped memory, and the rationale is, instructions don't go stale the way structure does. Your preference for how to run tests doesn't change when someone merges a branch. Your map of the codebase does.
Right. If I tell Claude, always run the test suite with coverage flags, that's true whether the repo has forty files or four hundred. But if I tell Claude, the entry point is in src/main.py, and someone refactors that into src/app/entry.py, my instruction is now actively harmful.
Now, Daniel's other question. Does the technology exist in third-party tooling? And this is where it gets genuinely interesting, because the answer is yes, and it's been around for a while.
The landscape is rich. Let me walk through it. Aider, which is a well-known coding agent, builds something called a repo map. It uses tree-sitter to parse the code, ranks files by relevance to the task at hand, and injects a condensed map into the prompt. That's exactly the map before task pattern Daniel's describing. It's not persistent across sessions by default, but the map-building machinery is all there.
So aider's already doing the thing, just inside its own harness. And the map is task-aware, which is interesting. It's not a flat map of the entire repo. It's a map that says, for this task, these are the files that matter.
Right. And that's a meaningful difference. A flat map of a large repo is just noise. A relevance-ranked map is actually useful. Aider's approach is closer to what Daniel actually wants, which is not just structure, but structure filtered by relevance.
So the technology exists, and it's already been refined past the naive version. That's worth noting.
Then there's repomix and code2prompt. These flatten an entire repository into a single file that you can drop into a prompt. It's crude, but it works. You get a text representation of the whole codebase, and you hand it to the model. That is a persistent map, in the sense that you can generate it once and reuse it until the repo changes.
And gitingest does something similar, right? It's aimed at turning a GitHub repo into something digestible for an LLM.
Yes. And then there's context7, which is solving a related but different problem. Context7 fetches up-to-date library documentation on demand. So when your code depends on a library, and the library's docs have changed, context7 pulls the current version. It's a freshness problem, same shape as the repo map problem. The map goes stale, you need a way to refresh it.
So the pieces are all there. Tree-sitter for parsing, vectorization for semantic search, graph databases for dependency structure, and tools that flatten or summarize or rank. The ecosystem has solved this in a dozen different ways, just outside the harness.
Then there's the MCP angle. MCP servers like codebase-context-mcp and mcp-server-github can serve repository structure on demand. That's the closest existing implementation of Daniel's ideal. A map that persists outside the session, gets queried when needed, and injects the relevant parts into context. It's not built into Claude Code, but it plugs into it.
The answer to does the technology exist is unambiguously yes. It exists in multiple forms, with different tradeoffs, and some of it is already designed to plug into Claude Code through MCP.
Which brings us to the system prompt question. Can you just tell Claude, before responding to the first prompt in a session, check for the map? And technically, yes. You can absolutely do that. A system prompt could instruct Claude to look for a pre-built map file, a repomix output or a context7 cache, and load it before doing anything else.
But the practical friction is real. The map has to be kept fresh. The prompt has to know where to look. And the harness doesn't ship this by default, so you're building your own convention. You have to decide where the map lives, how it gets regenerated, what happens when it's stale. It's like setting up your own backup system. You can do it, but you're now responsible for it.
This is why I think Anthropic hasn't built it in. The design philosophy leans toward correctness and freshness over speed. A built-in persistent map would need invalidation logic, branch awareness, a staleness policy. That's a significant engineering investment for what is, at the end of the day, a convenience feature.
Here's the deeper question Daniel's prompt opens up. Is the acquaintance pass actually a cost worth optimizing? For large repos, the pass is cheap relative to the task. If you're going to spend twenty minutes debugging something, five seconds of scanning is nothing. For small repos, it's negligible. The real inefficiency isn't the initial scan. It's the repeated re-reading of files that happens during the task.
That's the thing. The get acquainted step is not where the time goes. The time goes in Claude reading the same file three times because it forgot what was in it, or re-exploring a directory it already explored. The map solves the wrong problem. It solves the hello step, which was never expensive.
Daniel's ideal behavior is achievable, and the technology exists, and it can be system-prompted in. But the reason it's not built into the harness is that the harness is optimizing for something else. Freshness. Correctness. Not having to maintain a cache that can lie to you.
If you want it, the third-party ecosystem is right there. Aider's repo map, repomix, context7, MCP servers. You can assemble Daniel's ideal behavior today with off-the-shelf parts. It just won't be maintained by Anthropic.
Let me poke at one thing. You said the map solves the wrong problem. But there is a version of this where the map does solve a real problem. If the map encodes not just structure but relevance. Which files matter for which kinds of tasks. That's judgment, not just parsing.
That's the interesting frontier. Tree-sitter can give you structure. Vectorization can give you semantic similarity. But neither of those gives you judgment. Which files are dead weight. Which modules are actively misleading. Which comments are outdated. That's institutional knowledge, and it's the thing a persistent map would actually need to capture to be worth the staleness risk.
We're back to the distinction you drew at the top. Instruction memory versus structure memory. Daniel wants structure memory. But the really valuable thing is judgment memory. And that's the thing nobody's built, because it's hard.
It's the difference between a map of a city and a friend who lives there. The map tells you where the streets are. The friend tells you which streets to avoid after dark.
The get acquainted step is Claude looking at the map every time, because it doesn't have the friend.
Right. And that's not a failure of engineering. It's a choice about what kind of memory is safe to persist. Structure goes stale. Judgment goes stale too, but in a different way. And the harness has decided that the staleness risk isn't worth it for either one.
Daniel's question, does the technology exist, has a clear answer. Yes, and here's the landscape. Can it be system-prompted in? Yes, with caveats. But the reason it's not built in is more interesting than a simple oversight. It's a design philosophy.
I think the thing to leave listeners with is, the acquaintance pass is a feature, not a bug. It forces freshness. The cost is repetition. The alternative is a cache that might be stale, and a stale map in a coding agent is a subtle disaster.
The technology exists, it can be wired in, but the real question is whether a map is what's missing. Or whether what's missing is judgment about what the map should contain.
Which is a much harder problem, and one that no vector database is going to solve on its own.
We've got the mechanism, the tradeoffs, the third-party landscape, and the system prompt answer. What we haven't got is the thing that would actually make the map worth having.
That's where I want to hear from someone who's actually tried to build this kind of thing. Not a vector database, but a map that encodes judgment.
Hilbert: I built one of those. Nineteen ninety-eight. Technical writer at a mid-sized software company in Cleveland. Four thousand pages of internal documentation, and nobody read any of it. New hires would spend their first week just trying to find the right page. So I built a system of doc maps. Index cards, hand-drawn, color-coded by module, pinned to a corkboard. You wanted to know where the authentication logic lived, you looked at the card, it told you which binder, which section, which page. I was very proud of it. The company replaced it with a search engine in two thousand one and the corkboard went in the bin.
The thing about that corkboard is it encoded judgment. Which files mattered. Which ones were dead weight. A search engine can find any page. It can't tell you which page is worth finding.
Hilbert: The corkboard had a section for files that lie. Modules whose comments were so outdated they actively misled you. You'd read the comment, trust it, and spend three days debugging something that wasn't there anymore. The card for that module had a red dot. Red dot meant, don't trust the comment. Search engine never had a red dot.
The map wasn't just structure. It was a record of where the structure was wrong.
Hilbert: That's what a real map is. It's not just what's there. It's what's there but shouldn't be trusted. No vector database is going to tell you that. It'll happily index the misleading comment and serve it up as relevant.
That's the thing. Vectorization captures similarity. It doesn't capture reliability. A file that's similar to your query but full of lies ranks just as high as one that's accurate.
Hilbert: That's why the get acquainted step isn't the problem. The problem is that every session, the agent has to re-learn which files lie. And it can't, because that's not in the structure. It's in the history. Somebody tried to use that function and it didn't work. Somebody read that comment and got burned. That's not in the code. It's in the scars.
A persistent map that just captured structure would be marginally useful. A persistent map that captured scars would be valuable. But nobody's building that, because scars are hard to encode.
They go stale in a different way. A file that lied yesterday might be fixed today. The red dot has to be re-earned every time you trust the file and it burns you again.
Hilbert: I kept the corkboard in my garage for eleven years. The cards went yellow. The red dots faded. I threw it out when we moved. But I still remember which modules had the red dots. That's the thing about judgment. It doesn't go stale the way structure does. It just lives in your head.
The answer to Daniel's question is, yes, the technology exists, and yes, it can be system-prompted in, and no, it probably won't solve the problem he's actually feeling. The problem is the repeated re-learning, not the initial scan.
The repeated re-learning is a judgment problem. It's not that Claude doesn't know the repo. It's that Claude doesn't know what the repo has taught the people who work in it. The scars. The red dots.
Which brings us back to the open question. Will Anthropic eventually build a persistent repo map into the harness? Or will the third-party ecosystem, the MCP servers and repomix-style tools, remain the answer? And does it matter, if a map without judgment is only solving the cheap part of the problem?
The deeper implication is that the acquaintance pass is a feature. It forces freshness. But the files that lie problem suggests that even a perfect map is only as good as the judgment behind it. A map of structure is a solved problem. A map of scars is not.
The technology exists, it can be system-prompted, but the real question is whether a map is what's missing. Or whether what's missing is judgment about what the map should contain.
That's a question for the people building the harness, not the people using it. But it's the right question to be asking.
Thanks to our producer, Hilbert Flumingtop, for keeping this show running and for the corkboard story. This has been My Weird Prompts. If you want to send us a prompt like Daniel does, email the show at show at my weird prompts dot com.
We'll be back soon.
See you tomorrow.
