The Folder That Became a Discipline

It began as a small, practical question: how many AI agents were actually running across a set of related codebases? Not a hypothetical — a real audit request. The problem was that "the codebase" wasn't one codebase. It was several independent services, each in its own repository, each with its own history, its own conventions, and no shared place to even ask the question from.

So I did the simplest thing that could possibly work: I created a folder. Not a repository — just a folder on disk. Into it, I cloned every repository I needed to reason about as subfolders, side by side. Then I opened that container folder as a single workspace in my editor.

I didn't reach for that move because a methodology told me to. I reached for it because it was the obvious next thing given what I had to work with — several repos, no shared surface, a question that couldn't be answered from inside any one of them.

The tool I already had, and the tool I didn't reach for

I use DevSpark — a methodology I built for spec-driven, AI-assisted software development — on most of my repos. It would have been easy to describe what happened next as "I used DevSpark to plan better." That's not what happened, and the distinction matters more than it sounds like it should.

DevSpark's commands are built for a specific job — specifications, plans, tasks, code, run inside one repo at a time. Planning across five repositories with no shared history wasn't that job. Using DevSpark there wouldn't have been adaptation; it would have been forcing a tool to solve a problem it wasn't built for.

What carried over from DevSpark wasn't the tool. It was the instinct behind it — read what the environment is actually asking for, then build only what that requires, using what is already at hand. The workspace, and everything that grew out of it, is a different tool, built the same way, for a different problem.

What grew out of the folder

The workspace didn't stay a scratch folder for long. Within a day it had become its own version-controlled repository — deliberately separate from any of the product code it describes. It holds no application logic. Its entire job is to be the connective tissue between repositories that otherwise share no context at all.

The rest of that first day kept adding structure, but only as fast as a real gap showed up. Two documents both tried to describe "current status" almost immediately, and I watched them start drifting apart within hours — so I picked one and made everything else defer to it. Not a policy decided in advance. A fix applied the moment the problem showed up. A decision-traceability matrix, a rendered architecture diagram, a small deployed site to browse all of it. Each one showed up because the last addition had just exposed the next actual gap — not because a plan called for it in sequence.

None of this was designed as a system on day one. It accreted one real need at a time. Every piece exists because something upstream of it broke first, not because a roadmap said, "week two: add a diagram."

The first version was wrong

I built a script to check whether the tracker still matched reality — whether things that had actually shipped were reflected as shipped. The first version flagged several items as "shipped but untracked" that turned out to be false positives: work that had landed in a repository the tracker didn't know to watch yet, not work that had actually skipped the process.

The fix wasn't clever. I made the tracker explicitly enumerate which repositories it was accountable for. This is what building a tool for a problem you're still inside of actually looks like — you don't get the shape right on the first pass, because you don't fully know the shape yet. You get something running, watch where it's wrong, and fix that. That's not an exception to the process. That is the process.

What actually changed

None of this was ever really about the folder, or the tracker, or the script that caught its own blind spot. A cross-repository question that used to take three conversations and a pile of old commit messages now has a place to be asked, and something durable recording the answer. Decisions that used to live only in memory of a meeting are written down as decisions, dated, traceable. That's the actual payoff. The tooling isn't where the story ends anymore; it's what makes the larger picture visible.

The lesson here isn't "build a workspace like mine." The folder solved a problem that showed up during an audit, one that had nothing to do with writing code. I built a tool for it anyway, the same way I'd build a tool for anything else in front of me that needed one. Somewhere in the middle of doing that, it started to dawn on me that catching a planning gap while it's still just a folder full of repositories isn't all that different from catching a bug before it ships instead of after. Same instinct. Aimed one stage further upstream than I'd ever pointed it before.

That's a bigger idea than one folder can carry. It's worth its own telling.

Explore More

• Shift Left Into Planning — the bigger idea this anecdote sets up: agentic planning as its own discipline
• Dogfooding DevSpark: Building the Plane While Flying It — another case of a tool getting built by using it on itself
• DevSpark Monorepo Support: Governing Multiple Apps in One Repository — the more general version of the cross-repository governance problem this folder solved by hand
• The Beaver Builds a Pond — the same instinct of reading what the environment actually needs before reaching for a fixed process