Quality, written down

Picture the worst ten minutes of your quarter. Your database has gone down. Customers can’t sign in, and the first thing they do is open your status page.

It says: All systems operational.

Nobody lied. The page tried to read the state of your systems, couldn’t, and fell back on the friendliest thing it knew how to say. Nobody writes that bug on purpose, and nobody notices it until the one moment it matters.

We think about that page a lot, because it holds the question now at the centre of building software. An agent will build you a status page in an afternoon, and it will look finished. Writing the code has become the cheap part. The expensive part is what comes after. Is it still right? Is it right after the next change, and the one after that, after you’ve bent it to fit your business and we’ve shipped an update underneath you?

For most of software’s history, that answer lived in people. Someone reviewed the change. Someone remembered why the fallback works the way it does. That never scaled well, and it doesn’t scale at all to products built mostly by agents and forked by anyone who wants one.

So we wrote the answer down.

A sentence an agent can check

Every product we publish has a file called CONTRACT.md at the root of its repository. It’s a list of promises in plain English, each one specific enough to argue about. Across our fourteen products there are more than a thousand of them.

Lamp is our status page, and one of its promises is about exactly that outage. When the database or storage can’t be reached, the public page still loads from its last saved copy, labelled as the last known state, and “no failed read ever produces the all-clear.”

A sentence like that used to be a good intention in a wiki. What changed is who reads it. Our agents write the code and the tests in these repositories, and they work from the sentences. So the promise became a test, and the test does the unkind thing on purpose. It starts Lamp, pulls a table out from under the running database, loads the public page, and checks that the words “All systems operational” appear nowhere on it. Then it takes away the pointer to the saved copy as well, and checks again.

496contract("PAGE-006", "public reads survive a D1 failure and never invent an all-clear", async () => {497  execFileSync("pnpm", ["exec", "wrangler", "d1", "execute", …, "DROP TABLE page_settings"], …);498  const response = await fetch(`${pageUrl}/`);499  assert.equal(response.status, 200);500  const html = await response.text();501  assert.match(html, /Partially unavailable/);502  assert.doesNotMatch(html, /All systems operational/);

Lamp takes it one step further. Its build reads the contract, lists every promise, and stops if any of them has no test. You can’t add a promise to Lamp and leave it unchecked.

This is the part we find quietly remarkable. The contract is a bridge between what we want, in words, and what the code actually does, and for the first time something walks across that bridge on every change. A reviewer, human or agent, no longer needs the whole product in their head. They need to know which promises a change touches, and whether those still hold.

Promises change on purpose

Code can change all day. A promise changes only when someone decides it should, and writes down why.

Lamp used to promise that a scheduled update goes out within 60 seconds of its time. Then we stress-tested it, with forty scheduled updates and maintenance windows falling due in the same minute on a busy page. The last one went out 238.5 seconds late.

We could have called that an edge case and moved on. Instead, Lamp 1.4.0 promises 240 seconds. Its release record keeps the old promise, the new one and the measurement behind it, including the plain admission that this was one run on one machine. And Lamp’s release check refuses any changed promise that arrives without a record like that.

We would rather promise four minutes we’ve watched than sixty we haven’t.

Forks used to fall behind

All of this would be tidy bookkeeping if we were the only ones changing these products. The reason it matters is forks.

Every product here is MIT licensed and public. Take one and change anything: the screens, the schema, the framework. The old objection to forking was never the first change. It was the hundredth update from upstream that you’d have to merge by hand, forever. A fork was a promise to fall behind.

We stopped believing that because we’ve lived the other side of it. For more than a year we’ve run Every Code, our fork of OpenAI’s Codex CLI, with thousands of commits of our own on top. Between April and September 2026, our agents merged 5,306 of OpenAI’s commits into it, in 85 merges. It’s also where we built Auto Drive, which takes a task you’ve planned and keeps going until it’s done.

Play · 2:36

Those merges began as a workflow that woke every half hour and asked Every Code to merge its own parent. The agent worked from a written list of what made the fork ours: which parts to keep, and which features must never regress. Read it today and it’s plainly a contract, just an early and rougher one. It’s where this whole way of working started.

If the fork is yours

So here is how it works when you take one of ours. Change anything. If you change what the product promises, write down the new promise and why.

Lamp does this itself. Our shared baseline says to rate-limit public endpoints, and Lamp overrides that in writing for its public page, because a status page is read hardest during the very outage it exists to report. Your agent treats your written promise exactly the way ours treat theirs.

When an update arrives, Lamp’s release lists every promise it changed, old wording beside new. Your agent reads that list next to yours and asks one question from our agent guide: what did upstream intend, what does this installation intend, and what satisfies both? Sometimes the answer is a clean merge. Sometimes it’s our change, rewritten in the shape of yours. Either way the check at the end is the same: both contracts, both sets of tests.

The code is the cheap part now, and it will keep getting cheaper. What’s worth keeping is a short list of sentences that says what a product is for, and a machine that won’t let anyone, us included, break one without saying so.

That’s the difference, in the worst ten minutes of your quarter, between a page that says everything is fine and a page that tells the truth.