The T+1000 Standard.

In launch terms, T+0 is liftoff. T+1000 is a thousand days later.

By then, the launch team has scattered. The architect who defended every diagram has a new job. The engineer who knew why the retry logic works that way is two companies gone. The system is still running, under people who never met the team that built it, answering questions nobody wrote down.

Most software is built for T+0. The demo. The launch announcement. The quarter it ships in. Almost nobody builds for the day the building team is gone, even though that day is most of the system's life.

That is the day we engineer for.

The case against elegance

Software outlives the people who write it. Over enough generations of engineers, architectural sophistication stops mattering. What matters is whether the next person can tell when something's wrong. Where to look. How to add the next thing without breaking the last one.

Nobody sees this more clearly than retail. The systems that run your stores were not built last year. Some were not built last decade. POS, loyalty, pricing, payment reconciliation: they work well enough to be irreplaceable and badly enough to be a ceiling, and the people who know how they fit together are down to a handful. Every one of those systems was once somebody's elegant architecture. The elegance did not survive. What survived was whatever the next engineer could understand.

So the roadmap gets written around the system instead of through it. Not because the system is broken. Because it is opaque.

What obviousness looks like

The test is simple: would this code make sense on day 1,000, to an engineer who wasn't there on day one?

Holding that standard changes decisions all the way down.

It means boring names over clever ones, because the next engineer searches for what a thing does, not what it amused someone to call it. It means the documentation exists before the implementation, not after the exit interview. It means patterns repeated on purpose, so the codebase teaches its own conventions, and a developer who has read one module has effectively read them all.

It also means the design inputs are bigger than the code. The support desk that will field the calls. The accounting report that closes the month. The on-call runbook, the downstream jobs, the person whose Tuesday changes when the system ships. If those are afterthoughts, the system fails at T+30, long before T+1000 gets a chance to judge it.

And it means staying to operate what we build. Running your own code in production is the fastest honest feedback in software. An engineer who carries the pager for their own architecture learns obviousness in a way no style guide can teach.

Then the agents arrived

Agents made this more urgent, not less. Without firm rules of the road, an agent will replicate a pattern across your codebase faster than any human team could. Speed without discipline doesn't produce a maintainable system. It produces a large one.

An agent is the ultimate day-1,000 engineer. It was not in the design meeting. It holds no tribal knowledge. It reads what is actually there and extends it, at scale, immediately.

That is why the rules of the road come first on every build: the naming, the patterns, the review gates, encoded before any agent touches the code. And it is why what the work teaches does not walk out the door when an engagement ends. The way the thing was built stays behind, captured as agentic skills, so the next hundred developers inherit the discipline whether they are ours or yours.

We give the agents the rules of the road. That's the job now.

The promise

T+1000 is not a methodology. It is a promise about a day neither of us will be in the room.

On that day, an engineer we never met will open the system we built. They will be able to tell what it does, why it does it, and where to add the next thing without breaking the last one. They will not need to call us.

That is the standard. Everything we ship is built to it.