Personal · Design Tooling · 202504 / 04

What the files already knew

Documentation was the tax on design that kept a capable team writing about the past instead of defining the future. The solution was inside the files themselves.

The team was small and capable. What it couldn’t hold was the documentation. Every product ecosystem we worked on carried the same weight: time spent writing things down, maintaining what had been written, catching the places where specs had drifted from what was actually in the files. A capable team was spending a significant part of its energy writing about work instead of doing it.

I started building because I wanted that time back. My assumption going in was that the hard part would be output quality, getting an agent to produce documentation that was accurate and readable enough to actually use. One week in, I knew that wasn’t where the difficulty lived.

The files already knew more than I expected.

The annotations, the naming conventions, the structure: everything designers had been writing for human readers turned out to be exactly what an agent needed to understand the work. We hadn’t been documenting for machines. But the way we’d written for humans was rich enough that agents could pick it up, extend it, and make it useful for development and for downstream agents as well. The knowledge was already in the files. It just needed to be activated.

Years of careful annotation had already built a foundation nobody had thought to build on. The work wasn’t acceleration. It was recognition.

Before the seventeen agents, there was one. A single agent reading a file end-to-end and producing the documentation. It broke constantly, and the breaks weren’t the problem. The problem was the runs that didn’t break. The agent would go dark for long stretches, working through a file with no way to tell whether it was making progress or quietly failing, until it surfaced at the end with output I had to read carefully to trust. The cycles were too long, the feedback too late. A single agent doing everything was an agent I couldn’t see inside of.

The answer wasn’t a better single agent. It was seventeen.

Fig.01 — Audit Bureau architecture

The result is a process that’s declarative rather than bespoke. The same pipeline runs on a single component library and on an enterprise product ecosystem. It scales because the roles are explicit and the coordination is fixed.

If the work can document itself when it’s structured clearly enough, the documentation standard and the production standard are the same standard. Clarity isn’t something you add at the end. It’s either in the file or it isn’t.

The Design Audit Bureau is being piloted on the Delta account, and that pilot is running alongside something larger. We’ve rearchitected the way the design team works from the ground up: token architecture, component construction, how designers use both before anything reaches a developer. The documentation isn’t a separate layer that happens after the design work. It’s built into how the work is made.

The more significant shift is from static to live. When the design changes, the documentation changes. No designer has to notice the drift, schedule the update, find the time. The pipeline runs and the specs are current. The maintenance burden that was eating the team is gone. Not reduced, gone. What came back in its place was the capacity to go earlier and deeper, closer to the human truth a project is actually trying to solve for, before the moment to act on it has passed.

The Delta system case study ends with a bet: infrastructure that works without a human in the loop. This is where that bet is being collected. The files had been preparing for it longer than anyone knew.

← All work