This is the judgment an experienced software leader would bring to that — 281 rules, each with the reason and the real incident behind it — packaged so the AI applies them for you.
The method has overhead: work orders, tests, close-outs. If you are building for yourself alone, it will feel like friction.
Founder — you. Decides what it does, costs, keeps, ships.
Architect — an AI holding the rules. Writes the work orders.
Builder — an AI in the code. One work order at a time.
You.
Owns what the product does, what it costs, what data it keeps, what ships next, and the release to real users. Nothing else.
An AI, holding the rules.
Turns what you want into written work orders. Refuses to write one that breaks a rule, and tells you why in one line.
An AI, in the code.
Executes one work order at a time, touches only the files it names, and stops to ask when the answer is not obvious.
Every change starts as a written order: what to build, which files it may touch, how to prove it worked. The Builder never widens its own scope.
Who decides is set by the consequence of the decision, not by job title. Only the unrecoverable acts stop the work — and they are named.
Three of them, told as they happened on the two products this method was built on.
Production was frozen for twelve days and nobody knew.
A platform rollback was never undone. Two releases built cleanly, merged, and answered “OK” the whole time — while reaching no users. It was found because the Founder looked at the release card himself.
The rule: a release is not finished until the live address is confirmed to be serving the exact version you released.
The Builder waited twenty hours for an approval that added nothing.
A task to rebuild an empty production database finished its first step and verified it, then stopped for a sign-off that reviewed nothing the Builder had not already established.
The rule: escalate on decisions that are hard to reverse — not on the fact that production is involved.
Reversing one decision took four edits in four documents.
The rule had been written in four places. Miss one and the old behaviour lives on, because the next session reads whichever copy it opens first.
The rule: a rule is stated in exactly one document. Every other document cites it.
And who will direct an AI to build it. Engineers may buy it; it is not written for them.
The engineer joined later, for speed — not for expertise. The rules on this page are the ones that made it work.
The other twelve categories are in the kit.
| ID | Rule | Why |
|---|---|---|
| R-001 | Write down who decides what, before the first disagreement. | When nobody has named the decider, every small question stops the work while it looks for an owner. |
| R-002 | Set decision rights by what the decision changes, not by who happens to be asking. | A rule about job titles breaks the moment someone new joins; a rule about consequences survives. |
| R-003 | Keep five things permanently yours: what the product does for users, what it costs, what data it keeps, what ships next, and the release to real users. | These are the decisions that reach customers and money. Everything else is craft. |
| R-004 | Give the AI no decision rights at all: every action traces to a written work order, a ruling, or a direct human instruction. | Widening a human's authority is a management choice. Widening an AI's is an unbounded one. |
| R-005 | The AI that writes specifications never writes production code. | Whoever writes the plan cannot also be the only one checking it was followed. |
| R-006 | The AI Builder must stop and ask a human before touching a file outside the work order's stated list. | An AI that quietly widens its own scope is the single easiest way to lose track of what changed. |
| R-007 | Escalate to the human owner whenever the answer is not obvious — not just when a rule names it. | Rules cannot enumerate every case; “when in doubt, ask” is what covers the rest. |
| R-008 | When the AI Builder is told something that contradicts the architecture, it flags it and stops — it does not resolve the conflict itself. | An AI reconciling two conflicting instructions will pick one silently and you will never know which. |
| R-009 | A written instruction sitting untouched in the repo counts as approved; hold back only the ones that touch live user data or still need a final pass. | Otherwise every piece of work needs a second, ceremonial approval that adds nothing. |
| R-010 | Escalate on decisions that are hard to reverse or that leave something behind — not on the fact that production is involved, and the same test applies to the AI. | A rule that escalates by environment stops the work most often exactly where the work is cheapest to redo. |
| R-011 | Name the unrecoverable acts explicitly, and let those — and only those — stop the work. | “Be careful with production” cannot be applied; “deleting an environment, dropping a column holding live data, rotating a credential with no captured rollback” can. |
| R-012 | When you relax a control because the risk is not real yet, write the expiry condition into the decision and name who declares it. | A temporary relaxation with no stated end quietly becomes permanent, and nobody notices the day it stopped being safe. |
| R-013 | A requirement only one person can satisfy is not a control — remove it or find someone who can supply it. | It blocks work without reviewing anything, and it fails exactly when that person is away. |
| R-014 | Before any planned absence, read the queue's specifications for anything that names you, and read branch protection for anything requiring a second person. | The blockers that strand a builder are invisible from the board — they sit inside a specification's fine print and inside a settings page. |
Early access is a handful of people who build their first product with the system before it goes on sale. You work with the Architect from the first conversation to a repository whose checks are green. Doug reads every reply himself.
Thresh Lab receives no commission from any platform the kit prescribes. If that changes, this line will say so before it takes effect. Every prescribed tool is one Thresh Lab's own products run on.
Thresh Lab · Lowering the threshold to what matters.