One person, four workspaces, too many projects

Tuesday's plan can describe a dead end by Friday. That is the quiet failure of agentic development. Priorities shift, new information lands, and the plans and analyses that made the speed possible go stale without anyone noticing. Code at today's rates produces documentation at today's rates - and documents rot at exactly the velocity they are written.

I hit this harder than most. I'm Sander, a developer in Estonia, fifteen-plus years through network and security administration, platform engineering and full-stack development. My work lives in four workspaces with nothing shared between them: the day job, freelance clients, my own products, personal projects. No shared code, no shared context, not even vocabulary. Four universes, dozens of projects, one head.

I have used AI coding tools since autocomplete was the best on offer, so I watched the rate change from the inside. An app that once meant years of work - fifty thousand lines or so - stopped being years of work. This July alone, git counted roughly 190,000 added lines across my repos. Read that number the way I do: added lines measure activity, not output - they count every rewrite, every scaffold, every pass an agent takes on the way to the version that survives. Call it vibe coding if you like - the vibes are supervised. Fifteen years decide what gets accepted - and nothing I shipped in those years was tested or reviewed as thoroughly as what ships today. But the documents are commissioned per pass, not per survivor: an analysis before each decision, a plan before each build. They are not exhaust - I asked for every one of them. Which means the docs pile up at the churn rate, and the rot compounds exactly as fast as the activity.

Discipline did not fix it. I consolidated a whole domain into a structured knowledge base - linking rules, tooling set up specifically against drift. It helped. The drift came anyway. So the breaking point was ordinary. I opened a project after three weeks away and could not say what was decided, what was blocked, or which plan still held. The state existed. It was written down. It was scattered across hundreds of markdown files, and I was the extraction layer. sitrep is that extraction layer as software: an AI project status dashboard - a state layer on top of the markdown your AI agents already generate.

sitrep runs against my real working corpus every day: roughly 54,900 markdown files across those four workspaces - most of it the machine-shaped bulk a working disk accumulates, exports and archives and vendored trees - of which about 730 are actual project documents. Every extraction heuristic is measured against that corpus before it ships - when the intuitive threshold for a staleness signal would have flagged half of everything, the measurement won and the threshold moved.

The dogfooding goes one level deeper than most: sitrep's own strategy and decision documents live in the corpus it parses, so the product reads its own decision log. A regression in the extractor shows up as a moved number in its own docs before any user could see it.

No growth team, no roadmap by committee. Theproduct contract- eight promises and a binding list of things sitrep refuses to become - holds precisely because there is nobody to please except the people using it. When you write support, you reach the person who wrote the code.

My work is private - client projects and my own - so there is no public repository trail to point at, and I won't pretend otherwise. That is exactly why this site is built the way it is: the claims are designed to beverified, not believed- cut the network and everything still works, read the sync protocol when it ships, bring your own storage. "Trust me" is not an argument, and sitrep never asks you to accept it as one.

- Sander