My Architect, part 11: eight hundred commits I didn't write

On the morning of August 2 I counted the commits in my video generator. It came to 795. While I was writing this post, the counter reached 802. In that time I didn't write a single line of code — I answered questions and watched what came out.

For ten parts of this series I've been explaining how my_architect is built: memory, storage, the planning model, the working loop, Event Storming, the code graph. All that time one objection was fair: nice, but show it on a real project. Here it is.

Every number below was taken off a live project on August 2, 2026. Where a number measures something other than what it looks like at first glance, I say so.

The project that doesn't fit in my head

The video generator — a.k.a. Vini Studio — started on May 16, 2026 with a commit that said init. As of August 2 that's 802 commits over 78 days, 920 files under git, 85 thousand lines of code and another 70 thousand lines of documentation and configs.

The heterogeneity in there is indecent for a single person. Front end: React 18 on top of litegraph, a node canvas with 25 node types. Back end: Node with no framework, 2771 lines in one router, SQLite with 16 tables. Rendering goes through Remotion, which in turn spins up Chrome Headless Shell. Next door live two Python sidecars on Flask: the first wraps ffmpeg and holds 17 endpoints, the second splits audio tracks with Demucs on torch. Five model vendors — fal.ai, Anthropic, OpenAI, Groq, ElevenLabs — plus two registries with six models each, one for video and one for images. There's a research layer too: nineteen research documents, three-layer behavior evals, a blind cross-vendor evaluation of scriptwriters, and five A/B measurements where the decision was made by the numbers.

And on July 24 the project changed its architecture wholesale. The first assembly path, a Telegram bot on n8n, went into the archive by decision RFC-055, and the node canvas became canonical. Nineteen n8n workflows stayed in git as history only.

About the title, right away, so there's nothing to speculate about. Git considers me the author of all 802 commits, and I'm the one pressing commit too. The formal trace of agent co-authorship is the Co-Authored-By trailer: it sits on 256 commits, that's 31.9%, and there are five different model versions in there. That's a lower bound, because the trailer doesn't always get added.

What is clearly visible, though, is the working mode across the repository. Seven worktrees, three of them agentic and created on July 19 within seven minutes of each other. And on July 4 there's a run of 43 commits in 33 minutes: a mechanical migration of tests onto a shared harness, one commit per file. I can't do that by hand.

I don't remember this project. I remember the direction. Everything else lives in the architect.

What's actually in there

The project dump from my_architect as of August 2 is 650 nodes. Thirty-one top-level epics, 237 features, 33 stories, 324 tasks and 25 bugs filed under their own type. Of those, 527 are closed — 81%. Four levels of hierarchy, six release buckets; the oldest one, MVP, is closed in full, 38 out of 38.

Requirements: 296. Not only functional ones — 241 FRs, 26 NFRs, 20 constraints, five architecturally significant, three system-level and one open question, the very one I tossed into a discussion and filed precisely so it wouldn't get lost. Documents on nodes: 29. Diagrams: four, including the Event Storming board.

The easiest way to feel the scale is this. When I asked for the project context in a single call, the answer came to 258 thousand characters — and that's the trimmed view, without node descriptions. The full list of requirements didn't fit at all: the tool returned the error "385 thousand characters, limit exceeded" and put the answer on disk.

That right there is the answer to why you need external memory. Not because the agent is dumb. Because the project is physically bigger than any context window — mine included.

Requirement, commit and test holding hands

At the root of the project sits a CLAUDE.md of 488 lines with eleven hard rules. One of them works like this:

Any architectural decision, status-change or scope-shift MUST be reflected in TWO places: an RFC in docs/rfc/RFC-NNN-*.md and my_architect MCP. If a change isn't in both, it gets lost on /compact or in a new session. Don't do work without recording it. Don't record work without doing it.

That last line isn't my paraphrase, it's the literal string from the repository. And it works: 456 commits out of 802, that is 56.9%, carry a reference to a specific FR or RFC in the subject or the body. There are 63 RFC files in the project, from the first to the sixty-fourth, with one gap at forty-six.

But link discipline on its own is worth nothing without the other end. The other end is tests. The rule reads: every regression fix arrives with a permanent test tagged // covers: FR-NNN against a requirement in the architect, and if the requirement doesn't exist yet, it gets filed first.

Then the machinery starts. A script pulls the requirements out of the architect and matches them against the tags in the tests. A second script fails the build if any requirement turns up with zero covering tests. I ran it just now: ALL 203 requirements covered. There are 290 // covers: tags in the test folder, across 221 unique identifiers. Requirement identifiers live in the product code as well: 145 different FRs show up in the canvas sources.

Here's what it looks like in one concrete chain. There's RFC-052 about deleting a project. Its header points at the node feature-211-adwcry in the architect. The node has five requirements. From them come two commits dated July 23; from the commits come the deleteProject and renameProject functions in the store; from the functions come three tagged tests. And the body of the first commit ends with the line Architect: feature-211-adwcry → done; NFR-122/FR-143/FR-144/FR-145 → approved. The chain is closed in both directions, and you can walk it from either end.

Before the code, a picture rather than text

There's a technique I underrated until I started using it all the time: before building something, draw it and make yourself choose.

Between June 28 and July 3 the agent drew me fourteen interactive HTML wireframes across six brainstorm sessions — about 94 kilobytes of hand-written markup. Not pictures: a local server served them up in the browser one at a time, and I clicked the option I wanted. The shell layout — a rail with a dock versus everything in a top bar. Three status-bar variants. Where to hang the icons above a node and how many of them. What the states of the save indicator look like. The history panel.

Checking the "picture first, code second" order is easy. The canvas concept wireframe is dated June 28, the first commit of the canvas itself the 29th. The spec from July 1 says, word for word: "the options below reflect the user's real choice in the browser, not assumptions". The spec from July 3 records that mockup C was taken and mockup B rejected.

The most valuable case is when a mockup led to the decision to build nothing: we compared the options and saw that the wire reads fine as it is, the intermediate node isn't needed.

In my notes that rule is written down harder than I usually allow myself: until the brainstorm has been run and worked through, don't do anything, it will only get worse.

The wireframes, by the way, are in gitignore. From git alone you'd never see this practice — which is itself a decent illustration of why work has to be recorded somewhere other than commits.

About the night

I hand a task over at ten in the evening and come back in the morning to a finished result. Lately a big one: not "fix that padding", but an assembled piece of the system.

My first move was to check that against the commits, and I nearly drew the wrong conclusion. Out of the 802 commits, 75 fall into the window from ten at night to eight in the morning, and between one and six in the morning there are exactly zero. It looks like a refutation.

Except a commit doesn't record the moment the work was happening. It records the moment the work was accepted. At three in the morning there's nobody there to accept it. Timestamps can't measure the length of an autonomous run at all — they can neither prove it nor disprove it.

The shape of the day, on the other hand, is measurable, and it says exactly what I describe. The day has two humps with the night lying between them. Nine in the evening is the second-busiest hour of the whole project, 75 commits. Nine in the morning is the third, 70. The evening handoff, nine to midnight, accounts for 122 commits; the morning review, seven to ten, for 115.

And morning commits are the biggest of the day: 361 inserted lines on average against 179 during the day, twice the size. Daytime is small iteration. In the morning a big piece arrives in the repository, done whole.

So the line isn't about the hours. It's about where the confidence comes from to hand over a big piece and not sit over it — and that part is measurable directly.

Confidence doesn't come from the model. It comes from the agent having nowhere to lie: the requirement has a number, the number has a test, the test has a gate that fails the build.

What a stress test of that mechanism looks like can be seen in the story of August 1. The canvas had 63 green browser tests that created links between nodes by calling an internal API. Living right alongside them were two bugs that reproduced by hand a hundred percent of the time. One test outright faked an event that never happens in production, and it was green precisely because it patched over the exact condition that was broken.

The conclusion turned into another hard rule: input bugs are verified with real browser input — through real mouse events, with real pointer capture. A // covers: tag on an interaction requirement without real input is false confidence, because the gate matches a string in a comment, not the layer the test actually touches.

And since I promised honesty, here's the other half of the picture. I have no machine enforcement of the sync: no hooks, CI runs the deploy only, I run the tests and the coverage gate by hand. The discipline rests on the text of the rules and on the agent reading them every session. It works — but that isn't the same thing as "impossible to break".

What I get out of it

My role is a different one because of this. I don't retell the agent the context and I don't remember what state the twenty-eighth epic is in. I do product: I watch the clips, catch what irritates me, decide which model we throw out of the registry and what it costs in seconds of video.

Over the last week of July and the first days of August the studio gained a packaging editor where the preview physically cannot diverge from the render, because it is literally the same composition. An editing studio appeared: as of the August 2 revision it assembles a clip right in a browser tab. And in two days the whole voice pipeline landed: voice cloning, voiceover, isolation, dubbing, lip sync. Three RFCs in a row closed in three days.

Along the way there was an incident of the kind that usually doesn't make it into the victory report: on July 20 an unbounded render took down the entire shared server on memory, load hit eleven on four cores. The cure is boring — a memory and CPU ceiling on the container, so only your own render falls over, not the host. I left a comment describing the incident right in the config, so nobody would later lift the limits "because we don't need them".

Next up: the team

Let me say this plainly, so it doesn't get read backwards. This is not a story about one person replacing a team. Putting one person on a big team project and hoping it flies is not something you can do today, and I'm not proposing it.

It's a story about where the bottleneck moved. My constraint used to be my hands. Now the constraint is how clearly it's stated what has to come out, and how far a machine can check that what came out is exactly that.

And this is where it gets interesting for a team. All the discipline that makes it possible to hand an agent a big piece is exactly the set of artifacts a team needs with no agents involved at all. A single source of truth about the state of the work instead of a thread in a messenger. A requirement with a number you can reach from the code, and a gate that fails the build if that requirement is left without a test. On your own you can still live without that; on a team you can't.

Artifacts like these used to have to be sold to a team as overhead: we write requirements because that's the right way to do it. Now they have a second consumer, one that reads them every session and follows them literally. The same document serves the human and the agent both. I hadn't seen that before, and the multiplier is exactly there.

What I haven't measured on a team and honestly call open: how the tracker drifts when five people and ten agents write into it; who approves a requirement when its author is an agent; how much review you need when the volume of code per week grows several times over. That's the next problem, not a solved one.

I'm opening a door here, not closing one.

Facts and links

The measurement was taken on August 2, 2026. The video generator repository: 802 commits, the first on May 16, 2026, the last at the moment of measurement a2cc612 at 12:50. Architect data — the live ai-video-generator project on my-architect.app: 650 nodes, 296 requirements, 29 documents, 4 diagrams. The coverage gate is node test/check-coverage.mjs, output "ALL 203 requirements covered". The distribution of commits by hour — git log --format='%ad' --date=format:'%H'; the average commit size per window of the day — from git log --shortstat. The wireframes live in .superpowers/ and never reach git; their dates come from the file system and were cross-checked against the dates of the specs.

The tool itself is my-architect.app, installed into Claude Code with two commands. How the studio I'm talking about here is built, I went through in the post "From canvas to studio".

If you're running a similar project with agents and it turned out differently for you — write to me. I'm especially interested in cases where this kind of discipline didn't take off: they're more useful than success stories.