Day 4 — The Constitution

Back in 1988 — or '89, I genuinely can't remember — when the local youth council gathered to discuss matters of no great seriousness. Smoking cigarettes and drinking coffee by the gallon at the age of fourteen or fifteen was, in the Norway of that era, considered perfectly normal behaviour for youngsters. We had no shortage of bad ideas. But we really did think we were very clever.

There was a gap of a day in there — the third was quiet, the calm before any of the real machinery started turning.

Day four is when it turned.

And here is the thing that I suspect makes no sense at all from the outside: the project was properly underway now, the path was clear, and the sensible thing to do would have been to start building the actual software.

I did not build any software on day four. I spent the entire day writing the rules that the software — and more importantly, the way I work on it — would have to obey.

Why the rules come first

I want to explain why, because it is the single most important habit behind everything you'll read in these posts.

I build alone, with a small fleet of AI assistants doing the heavy lifting under my direction — one to advise and review, others to write code to a tightly written spec.

That arrangement can move astonishingly fast. But left ungoverned it descends into chaos within days.

Decisions get quietly forgotten. The same mistake gets made twice. Nobody remembers why a thing was done a certain way.

The only defence I have ever found against that — the thing that lets a one-man operation hold itself to the discipline of a real team — is to write the laws down and then refuse to break them.

The Covenant

So on day four I wrote the Covenant.

It is exactly what it sounds like: a constitution for the project, a formal set of laws governing how the work is done.

How documentation is kept. The hard line between the part of the system that thinks and plans and the part that actually writes code — they are never allowed to be the same hand at the same moment, because a mind that reviews its own work is a mind that approves its own mistakes.

How every working session must be closed out, so that the next one can pick up cleanly.

Fourteen laws to begin with. It has grown since, but the spine of it was set that day.

Alongside the Covenant I wrote the full specification for the Living Documentation System — the private, searchable tool that has since become the beating heart of how I keep track of this entire project.

Eighteen sections of spec, and by the end of the day a working interactive prototype of it sitting in front of me.

And I wrote one more document that has quietly governed every day since: the single source of truth, the one file that, whenever it disagrees with any other document in the project, simply wins. When you are juggling this much, you cannot afford ambiguity about which version of reality is correct. So I named one, in writing, and gave it the final word.

The discipline earned its keep before the day was even out.

I sent the new governance to one of my coding agents that I use for spec writing, audits and Quality Assurance (QA), and it came back having found two genuine faults — not in any code, but in the rules themselves.

A gate that had been written in the wrong order, and a stale checklist that no longer matched how things actually worked. Both fixed on the spot.

There is something deeply reassuring about a process catching its own mistakes on day four, while the cost of catching them is still nothing more than a few edits.

No product code, then.

What I built on day four was the system that would let me build the product — fast, and without losing my mind doing it.

A constitution, a source of truth, and the bones of the tool that keeps the whole thing legible to me.

It is not the kind of work that makes for a thrilling screenshot. But every fast day that followed was only possible because of the slow, unglamorous one that laid down the law.

---

Written by Torgrim Nyerrød — May 4, 2026