We had 40 decisions in our codebase. 4 of them were written down.
I ran a mapper over our own repository this week and counted something uncomfortable: how many of our decisions were ever written down anywhere a person could actually find them.
22 modules. 40 identifiable decisions. Of those 40:
4 were in a real document in the repo
3 were explained in a PR body
33 existed only as a commit message
Look at the conditions before you decide that says something about me. This is a repo written almost entirely in the last three months, by someone who cares about this problem enough to be building a product about it, with a tool running the whole time that captures decisions automatically. That is close to the best case anyone gets, and it is still 4 out of 40 written down properly.
A commit subject is not memory. It tells you what changed and, if you write good ones, it hints at why. It cannot tell you what you considered and rejected, or which weird-looking line is load-bearing and must not be tidied up by the next person who walks past it. And nobody reads git log before answering a question, including your coding agent, which will rewrite that load-bearing line with total confidence because nothing ever told it not to.
Here is the part that changed my mind about my own product. I had assumed the safe design for AI-written memory was to ask permission: the agent proposes, a human reviews, nothing gets recorded without consent. It sounds obviously correct. Then I looked at 33 out of 40 and realized the human already does not do it. Not out of laziness. The moment you decide something you are mid-problem, and writing it down is a separate act of work that pays off weeks later for somebody else. A review queue you never open is not consent. It is a slower way of remembering nothing.
So the real question is not whether the AI asks first. It is who is responsible for noticing when a recorded thing stops being true. If nothing catches that, then an AI writing its own memory is dangerous, and so is a human writing it, which is exactly what a stale CLAUDE.md already is. If something does catch it, the cost of a wrong note collapses, and the thing you should actually be afraid of is the missing note.
That is why we build the net instead of the gate. A note is pinned to the code it describes, it goes stale on its own when that code changes, contradictions supersede each other, and any note can be pulled in one click. Letting it record on its own is still opt in and still off by default, and I think that is right. I just no longer think leaving it off is the cautious choice. It is the choice where you end up with 4 out of 40.
Two more numbers, since I would rather hand over all of them than only the flattering ones.
56% structural coverage. 306 of our 549 files are in the full graph. The rest are configs, markdown, and generated files. That is the honest reason and not a great excuse.
0 blind spots, meaning no part of the product has been sitting untouched for months. Real, but mostly an artifact of a young repo that gets worked on daily. Run this on something three years old that a team has rotated through and I would be surprised if you get 0. That is the number I actually want to see.
You can get yours without signing up or installing anything. Go to secondos.app/scan/try, copy the prompt, paste it into whatever AI coding tool you already have open, then paste the JSON it hands back into the page. Your agent reads your source locally and emits structure only, so no code leaves your machine. It is a model reading your repo rather than a deterministic build, so treat it as a decent first draft and not gospel. It is enough to see the shape of the thing.
Then tell me your ratio. How many of your decisions live anywhere other than a commit message? I am genuinely collecting these, partly because I suspect 4 out of 40 is not the embarrassing outlier it felt like when I first saw it.
Our actual launch here is on the 27th. This is not that. I wanted the number out before then, since it is the argument for the whole product and it happens to be at our own expense.
— Oğuz (management@monafy.com · x.com/grbuzoguz)

Replies