Two weeks ago I was debugging a module I had written myself.
Sat staring at it for twenty minutes. everything was unfamiliar. The structure made no sense to me. I had to reverse-engineer my own code like a stranger had written it.
The uncomfortable truth — an AI had written significant chunks of it, I had reviewed, merged, and completely moved on. Two weeks later it was an alien to me !
I kept thinking about this. We talk constantly about LLMs having a context window like it is some fundamental technical limitation. We never apply the same framing to ourselves.
Developers have a context window too. AI-assisted development is just filling it faster than any human brain can track.
The problem with existing solutions
The obvious answer is "write better documentation." Every team says this. No team actually does it consistently — not because developers are lazy but because documentation written as a separate task from coding immediately starts drifting from reality.
Asking your IDE to document as it goes is worse. Cursor adds a new README for every three lines it touches. Imagine 3-4 Readme files just for an Auth module ! nobody on earth would feel enthusiastic to open ai generated docs !
What I actually needed was something that treated documentation as a continuous output of development — written automatically at the one moment developers never skip.
The commit. ( ~ Version Controlled Documentation )
What I built
DevMem is an open source Go CLI that hooks into your git workflow and maintains a living knowledge base inside your repository.
First run — crawls your entire repo and documents everything
devmem init
After every commit — patches only what changed
devmem capture
Ask your codebase anything
devmem query "how does the auth module work?"
The thing I did not expect
The .devmem/ folder ends up being genuinely useful context for AI coding tools.
When Cursor or Copilot has access to accurate, current, structured documentation of every module — what it does, what its API surface is, what it depends on, what changed recently — it becomes meaningfully better at helping you. It stops making assumptions about your architecture because it is reading your actual architecture.
One knowledge base. Useful for your teammates and your AI tools simultaneously. That was not the original goal but it might be the most valuable outcome.
_
Honest rough edges_
Module detection uses directory heuristics. It works well on standard Go, Node, and Python project layouts. Unconventional structures need a small manual config to define module boundaries explicitly — the heuristics will miss or misgroup things.
Large messy refactor commits that touch many modules simultaneously stress-test the capture prompt in ways I have not fully solved. The classification is harder and the patches are less surgical than I want them to be.
The query command is only as good as your documentation is — which is only as good as your captures are. If you skip captures for two weeks the query answers drift.
_Stack
_
Go + Cobra
Anthropic API (Claude)
Single binary — no runtime dependencies
go install, direct download
MIT licensed
GitHub: https://github.com/surya-sourav/devmem
https://fun-tomato-aiuks1hrge.edgeone.app/
Demo :
Built this because I was tired of being a stranger in my own codebase. Curious whether anyone else has felt the same way and what approaches you have tried.
Brutal feedback welcome — especially on the module detection and the query command. Those are the two places where real-world codebases will stress-test the assumptions hardest.
Top comments (26)
codebase memory is one of those things where the value compounds over time - slow to appreciate at first, then you really notice it when you switch contexts or come back to something after a few weeks. curious what the storage backend looks like and whether it handles monorepos with multiple services cleanly or if you have to segment it manually
It actually uses your codebase root as the storage backend , Local first approach - where the documentations gets updated each time you make a change and remains locally ( without being shared to a 3rd party Org ) , the docs would get contained in a "./devmem" dir ( dir in the project root )
as of now , i have tested with monorepos with MVC pattern codebases and its able to draw boundaries between different modules , crawling the codebase , identifying the files , writing docs.
Personal Note : "Its a weekend project. I dont get much time aside my full-time swe job , its still in its baby stage , would make it more robust and promising in the future "
local-first is the right call here - the moment your codebase memory lives in a third-party silo you've got a privacy problem and a vendor dependency. auto-updating on each change is interesting though, does it diff or full-rebuild? would imagine large codebases could get noisy fast
Interesting, I wonder if this could be integrated?
your agent can think. it can't remember.
Hi. I have similar workflow tool called REAP. Click my profile and see my recent posts. The key thing is, generate document at once is easy. But managing the knowledge in ai session context always fresh and maintain synchronized with codebase is the real problem to solve. You might need iterative workflow to kept the document to synchornize with code base. I recommend you to search “reap.cc”
Nice concept , reap is something i will call more matured than the current state of devmem and also serves a bit of different purpose other than auto-documenting & changelog capture that becomes a unified memory both for humans as well as Agents.
Thanks, I’m working on it!
That "stranger in your own codebase" problem hit home. I've definitely had moments where I'm reading my own code from 3 months ago like "who wrote this garbage" and then checking git blame... oh. me.
The commit-time approach makes a lot of sense. Documentation as a post-commit hook is the only way it actually gets written consistently. I've tried convention-based doc tools before and they all become shelfware within weeks.
One question — how does this handle the incremental capture when you have commits that span multiple modules but are logically one change? Like refactoring a shared type that ripples through 5 different directories. Does each module get its own isolated doc patch, or is there some way to link them conceptually?
Also, have you thought about adding a git hook that just auto-runs
devmem captureafter every commit? Removes one more manual step. Most devs would probably forget to run it otherwise (myself included).Spot on , each module gets their dedicated Document ( markdown file ) that gets auto-updated even on a minute change ( that is based on the git diff ) .
great idea of adding the devmem capture git hook , have raised the issue - once i get time , i would start working on it.
its also conceptually linked by the changelog hashid ~ git hash id for easy traceability and figuring out what & when the changes were made.
Personal Note : "Its a weekend project. I dont get much time aside my full-time swe job , its still in its baby stage , would make it more robust and promising in the future "
This is actually a pretty cool idea… giving a codebase some kind of “memory” feels like a small step toward something much bigger.
Tools like this make you think about how development might evolve in ways we’re just starting to see.
Curious to see where this goes.
Really cool concept — giving a codebase persistent memory solves one of the biggest friction points in developer onboarding and context-switching. The idea of AI understanding not just what code does but why decisions were made is powerful.
We're exploring a similar philosophy with AnveVoice — instead of AI that just reads/understands websites, we built voice AI that takes real DOM actions (clicks buttons, fills forms, navigates pages). The "memory" angle resonates because our agent needs to understand the full page context to act correctly. Built in Go too? Nice choice for CLI tooling. What's your approach to handling stale context when code changes significantly?
Hey , great initiative in the domain you are building, of context engineering ! its a really booming domain fs in 26 , currently by default the stale context is being discared and is only remembered in the changelog history in form of short summaries , if we compress the stale context and still store it , and retrieve only when necessary with the help of page index ( vectordb less RAG ) then it can be a solution , talking vaguely here but will soon think of a solution for this.
Thanks 🙌🏻
This is such a clever idea! Context switching and forgetting why certain decisions were made is one of the biggest productivity killers for developers. Having a dedicated CLI to act as a 'memory bank' right inside the terminal is brilliant. Thanks for building and sharing this!
"Developers have a context window too" -- this is such a perfect way to frame it. I've had the exact same experience: reviewing AI-generated code I merged a week ago and feeling like I'm reading someone else's project. Definitely checking out DevMem.
This is promising.
Glad you liked :D
Its open for contributions and your love in form of Stars :D
This looks extremely useful, but the Anthropic API Key only requirement is a blocker, will you be adding the ability to bring your own API Key?
yeah , multiple AI clients are in the future roadmap , added to issue - will implement them gradually , btw its open for contributions , anyone can contribute to it meanigfully :D
Some comments may only be visible to logged-in visitors. Sign in to view all comments.