The Standard We Build To (And Why Most Teams Are Still One Argument Behind)

A pressure-washing company in Oregon sent six commercial quotes on a Monday afternoon. The property manager replied that evening, because nobody else had sent one yet.

The same week, eight job photos became a month of posts in fifteen minutes, a two-star review got answered in a way that won a booking three weeks later, and two ZIP codes went live in twenty minutes instead of eleven days.

That week is written up here, and the full case study is here. One owner, a couple of trucks. Nothing about it is a technology company.

That is what these systems do for a business. This post is about the standard required to build one that behaves like that on a Tuesday in February, eighteen months after anyone was excited about it.

Most teams are still one argument behind

Can agents write real code. Is it cheating. Will it take my job.

We settled that a while ago, by evidence rather than enthusiasm, and it turned out to be the easy part. Agents write most of our code. The hard and genuinely unsolved part is what happens after you accept it: when most of the writing is automated and a human is still accountable for every expensive-to-undo thing that gets done.

The engineering moves. It stops being about how you write a function and becomes about how you build something that can be trusted to move fast without a person reading every line. That is the work, and this is the standard it is held to.

Spec-first

The specification is written before the code, and the specification is the artefact under review. Not a ticket. Not a paragraph in a chat thread.

The test of whether a team really works this way is uncomfortable: if a behaviour is not in a spec, is it a requirement? In most teams the honest answer is "yes, if the right person remembers." That means the real specification lives in somebody's head and every disagreement resolves by seniority instead of by reading.

This gets sharply more valuable once agents are writing. An agent cannot infer the requirement you forgot to write down. It will confidently satisfy the spec you gave it. Vague spec, confident wrong output, delivered fast - that is the signature failure of agentic delivery, and it is a specification failure wearing a costume.

Verify before you assert

Nothing is reported done because it was intended.

Every claim carries the check that could have falsified it. Not "I updated the config" - the config read back. Not "the migration applied" - the object it creates, found in the database.

The corollary is the part teams find hardest: "I could not ask" is a distinct answer from "no." A check that could not run has not passed. A probe pointed at the wrong place has not proved absence. Most false confidence in software does not come from checks that fail; it comes from checks that never asked the question and reported green anyway.

So every control has to be able to fail, and has to be demonstrated failing. A guard nobody has watched refuse something is not a guard. It is a decoration that reads as protection.

Governed gates

Decisions are recorded, not remembered. When a decision is made about how the system works, it becomes a record with a status and a date, in the words of the person who decided it.

Irreversible actions sit behind gates. A gate has a named human on the other side and cannot be argued past - not by urgency, not by seniority, and specifically not by an agent deciding mid-run that the rule surely was not meant to apply here. Discovering that you need a new decision is a stop condition, not an obstacle to route around.

That sounds like bureaucracy and is the opposite. Because the decisions are written and the gates are explicit, everything not gated moves at full speed without anyone asking permission. Ceremony concentrated where the stakes are is what buys velocity everywhere else.

Tenant sovereignty

A customer's data and decisions belong to the customer - as architecture, not as a value statement.

The systems are built structurally unable to cross tenant boundaries rather than instructed not to. There is a large difference between a system that will not do something and one that cannot, and it shows up on exactly one day: the day somebody makes a mistake.

This is the discipline that costs the most to hold, because the shortcut is always available and always cheaper this week. Ask any team that has a service key with broad access "just for the migration."

Agent-orchestrated delivery

Agents do the work, inside rails a human set. The interesting engineering is entirely in the rails: what an agent may decide alone, what it must escalate, what it must never touch, and - the one most teams forget - how you can tell afterwards which of those happened.

An autonomous run that produces no evidence of its own reasoning is not automation. It is a rumour with a commit hash. Unattended work needs *more* evidence than attended work, not less, because its natural failure mode is to quietly emit less: nobody is watching, so nothing forces the record.

Why this is worth your time

If you have been quietly frustrated that "AI-assisted development" at your company means a chat window bolted onto the same process, this is the other version. The open problems here are real and current:

• How do you make a check that cannot silently pass?
• What is the smallest gate that stops a bad irreversible action without slowing the ninety percent that are fine?
• How does an automated run prove what it did, to someone who was not watching?
• What must a specification contain before an agent can be trusted to satisfy it alone?

These are going to define the next decade of how software gets built. Working on them now is a head start, not a bet.

Take the free version first

Everything above is published. The methodology material and the tutorials are open to anyone and are not a trailer - same standard, written down, nothing held back to make you pay. Read it, work through it, judge the level for yourself before you speak to anybody.

That is deliberate. We would rather you arrive already knowing whether this is the level you want to work at.

The part that is not published

There is a part that is not on this site and will not be: how we actually run a delivery - the flow itself, and how a customer's system gets built end to end.

It is the method that makes everything above hold under a real deadline with real money on it, and it belongs to the people doing the work. There is one door to it, and it is a plain one: come in as a contracted implementor, NDA and Employment Agreement signed, and you are taught the method properly by the people who use it daily. No trial version, no overview deck, no summary that gets you most of the way.

Want to build these?

Somebody is going to build the next thousand of these systems for the businesses that need them. If the standard above reads like the level you already hold yourself to, come and talk to us.

*Written by Patrick Roden.*