counterentry/ESSAY.md at main · pollockchris083-arch/counterentry · GitHub
//blob/show" data-turbo-transient="true" />
Skip to content
Search/
Sign in<br>Sign upAppearance settings
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
pollockchris083-arch
counterentry
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
FilesExpand file tree
main
/ESSAY.md
Copy path
Blame<br>More file actions
Blame<br>More file actions
Latest commit
History<br>History<br>History
121 lines (61 loc) · 13.4 KB
main
/ESSAY.md
Copy path
Top
File metadata and controls<br>Preview
Code
Blame
121 lines (61 loc) · 13.4 KB
Raw<br>Copy raw file<br>Download raw file
OutlineEdit and raw actions
A knowledge base that notices when it stops being true
I keep records for a handful of internal apps at a small company where I work. Ordinary stuff: what each app does, who it's for, what we decided and why.
One of those records said a dashboard required admin access.
The code said something else. The permission check returned true. Every visitor, every time, since the day the line was written. There was no gate. There had never been a gate. We fixed it that afternoon.
Here's the part that got me: nothing we run could ever have caught it. It didn't crash. It didn't throw an error. It did exactly what it was written to do. Error monitoring watches for failure, and this wasn't a failure. It was a function working perfectly while also being wrong.
It only surfaced when I put two records of the same app side by side and asked one question: do you agree?
I've spent my time since building a system that asks that question every night, so nobody has to remember to. Here's what I built, what it's caught, what's wrong with it, and what I'm measuring next.
How I got here
I was building an app on my own: nights, weekends, any hour I could steal. The thing that kept stopping me wasn't the code. It was that every session with my AI coding agent started from zero. I'd re-explain the same constraints. I'd re-argue decisions I'd already settled and forgotten the reasons for.
So I started keeping notes the agent could read. Basically the pattern Andrej Karpathy published in April as the "LLM Wiki": keep your knowledge in plain files, let the model write and organize them, ask your questions against that record. If you haven't read his gist, go read it. It's one page and it's the best statement of the idea anyone has written. The foundations of what I'm describing are his.
Then two of my systems failed in the same season, and the failures had the same shape.
The first was the app. I asked my own notes what state something was in, got a confident answer, and built on it. And the notes described what I had intended to build, not what had actually shipped. The record agreed with itself completely and was wrong. Nothing failed, so nothing flagged it.
The second was dumber and more expensive. A vehicle service I kept meaning to get to, with nothing ever set to bring it back, turned into a $4,000 repair. That's the kind of number that quietly rearranges your next few months. My notes didn't fail there. I never wrote it down at all, because meaning to get to it felt like a plan. It wasn't a plan. It was a wish, and then not even that.
Same failure, twice: something I believed quietly stopped matching reality, and nothing was checking. Code has tests. Servers have monitoring. Money has had reconciliation since 1494. What we believe has no feedback loop at all.
That repair bought one of my rules outright: a thing you put off without a trigger to bring it back is a thing you deleted. Everything I park now comes back on a condition. "Next time I touch the brakes." "If a second customer asks." Never on my memory. That rule cost me four thousand dollars, which is more than I've paid for any book.
The gap
Karpathy's pattern includes a health check he calls lint. It looks for contradictions between pages, stale claims, orphans, and gaps a web search could fill. For a research vault, which is what the pattern was built for, that's the right check.
But it checks the notes against the notes. When your notes describe a running system that changes, a claim can be wrong the day it's written with nothing inside the vault to contradict it. My admin-gate record was never contradicted by any note I had. It was contradicted by one line of code the notes had never read.
So the change I made is small to say: compare against something outside, and let reality moving be the trigger.
What I changed
Notes about code point at the code. A claim about software records exactly which file and lines it's describing, and what that code looked like at the time. The design: each night, the system checks what changed in the codebase and flags...