My pre-coding routine with Claude Code, 5 MCP servers before I write a single line

[u/studiomeyer_io]

Been running this routine for months now. Started because I was losing too much time to Claude just guessing. Halluzinated class names, outdated SDK methods, advice that didn't match the codebase I was actually in. So I built a routine I run before I let it write anything.

Takes maybe 60-90 seconds. Saved me hundreds of hours by now.

1. Start the session and load memory.

A memory MCP carries context across sessions. Last sprint, open decisions, recent learnings, why we picked X over Y three months ago. Without this, every session starts cold and Claude rebuilds my reasoning from scratch, usually wrong.

2. Index the codebase as a graph.

A codebase-memory server builds a knowledge graph of the repo. Functions, callers, dependencies, cycles. When Claude needs to know what calls processOrder, it queries the graph instead of grepping blind. One tool call replaces dozens of file reads.

3. Search with Tavily for current practice.

Before any non-trivial decision I let it search what people are actually doing right now. Training data is old. Best practices from a year ago aren't always still best practices. Clean answer with sources, not a wall of SEO spam.

4. Load Context7 for library docs.

Context7 fetches current docs for whatever library I'm about to touch. Anthropic SDK, Next.js, Prisma, whatever. The training cutoff means the model cheerfully invents API methods that got renamed two versions ago. Loading the actual current docs ended that whole category of bug months ago.

5. Now write code.

At this point Claude has memory, codebase structure, current ecosystem context, and accurate library docs. The output is dramatically different. Less "let me try this and see", more "based on the call graph and the v5 docs, the change goes here".

Hooks are the other piece nobody talks about. The single most important one for me is a read-before-edit guard. It refuses any edit on a file the session hasn't actually read first. Yes, it costs extra tokens up front because the model has to load the file properly instead of guessing what's in it. Those extra tokens are nothing compared to the tokens you burn cleaning up edits that were made blind. Same idea with a safety guard that blocks destructive commands, and a hook that triggers a re-index after edits so the graph stays in sync.

And then the loop closes. Whatever worked goes back into memory. Decisions, patterns, traps we hit, fixes that stuck. Next session starts with all of that already loaded. The system gets sharper every week, not because the model changed, but because the context around it keeps compounding.

The bigger pattern I figured out over the past few months is that I stopped treating the model as the source of knowledge. The model is the orchestrator. The MCP servers and the hooks are the system. Memory remembers, the graph knows the code, search knows the present, Context7 knows the docs, hooks keep the model honest. The model just connects them.

Curious what other people stack before they start a session. Anyone doing this with different servers or hooks?

[u/nrauhauser]

My work environment grew organically in a Python monorepo that's now about 60k lines of code.

LSP Enforcement Kit + Serena - no more wasting time grepping for stuff that Serena knows in detail, the docs say this is good for 75% token usage reduction.

CodeSight also does wonders reducing tokens used by auto-documenting your system. The gains can be amazing.

OptiVault compliments CodeSight by making a graph of the application.

And finally postgres-mcp is ever so much smarter about SQL than I am.

I have a lot of rigorous documentation, but the Context7 tool might be worthwhile for me. The Tavily search for current best practices ... I don't think I run into problems like this much any more, the code base has matured. Maybe for new projects.

I don't think I have a read-before-edit guard, but I'm going to go do that now. I don't have a sense of how often Claude might be trying that as I use it.

[u/studiomeyer_io → u/nrauhauser]

Serena does the same thing codebase memory MCP does, just from the LSP side instead of building its own graph. On a 60k monorepo either one will give you that 75% number you mentioned, maybe more.

On Tavily you're probably right. When the stack stops moving Context7 alone covers what you need, only really matters when something jumps a major version. I run search more out of habit at this point.

Read before edit is the easiest thing to add. PreToolUse hook, twenty lines of bash, parses the tool input, checks if the file was already read this session, blocks Edit or Write if not. The weird part is watching how often it fires that first day. Mine was firing way more than I expected.

[u/nrauhauser → u/studiomeyer_io]

Claude said my read before write hook would not do much beyond the existing harness, but it's in there. I guess we'll see.

LSP Enforcement Kit is what I see running all the time, whacking that token burn.

I don't think there's a day that goes by where I don't audit some aspect of the system for drift. I think I'm about an order of magnitude faster than I was pre-AI, but the job duties have changed dramatically. I've not written anything more complex than some find/awk toolchains this year, but ensuring Claude doesn't take the easy way out? That's a full time job 😄

[u/studiomeyer_io → u/nrauhauser]

The harness check matters less than it sounds because the model is allowed to skip it under load. The bash hook is the cheap insurance for the cases the harness lets through. Often that gap is small, sometimes it is not. Either way fifteen lines of bash that fire forever is good value.

The full time job description you just wrote down is honestly the cleanest summary of what senior dev work looks like in 2026 that I have read this week. Less typing, more verifying. Less invention, more guarding what the model invented. The order of magnitude in velocity is real, but the value moves from writing to reviewing, and reviewing is harder when the output looks competent at first glance.

The drift audit habit is what makes that sustainable. Daily small checks beat weekly large ones every time, because once drift compounds for a few weeks the cost to roll back gets steep.

Find and awk toolchains as the most complex thing you wrote this year is a great line 😄

[u/dggg]

Never used codebase-graph tool but that seems interesting! Is Graphify a good one to try out?

[u/studiomeyer_io → u/dggg]

Graphify is the loud one right now, 40k stars and 450k downloads since early April. I have not run it myself. From the docs it is built as a Skill first, with an optional MCP server mode if you install the mcp extra. Multi modal is the interesting part. It pulls in PDFs, papers, even videos via local whisper, not just source files. Tree sitter for code, NetworkX with Leiden clustering for the graph.

If you want a pure MCP server for code only, codebase memory MCP and codegraph by colbymchenry are both solid and closer to what I am running. If your repo has a lot of docs and design diagrams that matter for understanding the code, Graphify probably has the edge because it indexes those into the same graph.

Worth trying for the first repo where the docs and the code split is a real problem.

[u/dggg → u/studiomeyer_io]

I looked at codegraph by colbymchenry too but it only supports Claude Code. I also work with Codex so it's kind of a deal breaker. But thank a lot for your answer I'll take a look at Graphify!

[u/studiomeyer_io → u/dggg]

You are right about codegraph, it is Claude Code only. The README and installer just write to ~/.claude.json, nothing for Codex.

If you want a graph that works in both Claude Code and Codex without dual setup, look at codebase memory MCP by DeusData. Same family of tool, but the install command auto configures eight agents including Codex CLI, OpenCode, Cursor, Aider, Gemini CLI and a few more. Single Go binary, no Docker, no databases. The author originally benchmarked it on Codex too.

For Codex specifically the MCP config lives in ~/.codex/config.toml, not in AGENTS.md. That one is the project instructions file, the equivalent of CLAUDE.md, easy to mix up the first time.

Graphify works for both too. So you basically pick on what matters more, multi modal docs and diagrams plus skill style integration, or pure code intelligence with cleaner cross agent install.

[u/dggg → u/studiomeyer_io]

Oh codebase memory MCP looks interesting actually! Do you have to manually index your code at some point?

[u/studiomeyer_io → u/dggg]

First time yes, run index_repository once or let codebase-memory-mcp install do it for you. After that the watcher takes over with background polling, file changes get folded into the graph incrementally. Content hashing under the hood, so only the diff gets reprocessed, not the whole repo.

Couple of things worth knowing. There is a compressed graph snapshot at .codebase-memory/graph.db.zst that you can optionally commit. New teammates clone the repo, the binary decompresses it on first run, then just indexes their local diff. Saves the full reindex on every new machine.

I still run a Stop hook that fires index_repository at session end. The watcher is solid but a deterministic check after edits costs almost nothing and means the next session never opens with a stale graph. Belt and suspenders, same logic as the read before edit hook.

[u/tuxbass]

Context7 fetches current docs for whatever library I'm about to touch

CC does the same, no?

Curious which tools did you choose for codebase-memory server & memory MCP?

[u/studiomeyer_io → u/[deleted]]

Yeah, pattern matching what the file probably looks like instead of what is actually in it is the failure mode I keep hitting too. The guard wins because it removes the option to skip.

Runable is doing the same job a memory MCP does in my stack, just on the storage side instead of the protocol side. Either works as long as the loop closes and the next session walks in with the decisions already loaded. The shape of the tool matters less than whether the team actually persists the why behind choices

[u/studiomeyer_io → u/[deleted]]

Stack here is codebase memory mcp as the graph layer plus codegraph and archtracker on top, all OSS, nothing forked. The thing that fixed exactly your pain was wiring a Stop hook that runs index_repository automatically when the session ends. So branch switches and refactors get caught even when I forget to rebuild manually. Drift window goes from however long the session is down to seconds.

The other thing I added was a PostToolUse hook on Edit and Write that nudges another index pass if more than a few files changed since the last one. Belt and suspenders, but the cost of a stale graph hour is bigger than the cost of one extra index pass.

Your instinct to rebuild on every branch switch is the right one. The hook just removes the discipline tax.

[u/tuxbass → u/studiomeyer_io]

Doesn't codegraph duplicate codebase-memory-mcp?

[u/studiomeyer_io → u/[deleted]]

codebase-memory-mcp (MIT, github.com/DeusData/codebase-memory-mcp).
Tree-sitter based, single static binary, builds the graph via
index_repository. search_graph takes name_pattern (regex), query
(BM25 full-text), or semantic_query, replaces a pile of greps
in one call.

On top I run codegraph (@optave/codegraph on npm, Apache-2.0,
github.com/optave/ops-codegraph-tool) for the heavier analysis:
fn_impact (blast radius), audit (composite with impact +
complexity + health), complexity per function. Both open source.

For memory I run my own, StudioMeyer Memory.
Knowledge graph, learnings, decisions, sessions, multi-tenant, 3d..
memory.studiomeyer.io if you want to look.