The SAE Test
Status: Complete · Ten yes/no questions that tell you, in ninety seconds, whether you have a practice or just a habit.
In 2000, Joel Spolsky published a twelve-question test for software teams that survived because it was brutally simple: yes or no, no maybes, no partial credit. It became the most-shared artifact his company ever produced because you could run it in a hallway. This is the SAE equivalent for the era of free code generation — a single page you can paste into a Slack channel, a job posting, or your own conscience without needing the rest of this wiki.
Score 1 point per yes. Be honest — aspirations score zero. "We're planning to" is a no. "We do it for the important stuff" is a no. The test only respects what you did on your last change, not what you intend to do on your next one.
1. Does every change re-enter at the spec — do you fix the spec first, then regenerate? Why it matters: if you patch the code and leave the spec stale, the spec is fiction and the code is the source of truth again. → P2
2. Does a fresh, independent context try to break every non-trivial change before you ship it? Why it matters: the context that wrote the code is the worst judge of it; verification has to come from somewhere that hasn't seen the reasoning. → P3, The Verification Doctrine
3. Do you track spec-drift time and reconcile it the same day? Why it matters: drift compounds silently — a spec that's a week behind the code is a map of a city that's been rebuilt. → P1, KPIs and Metrics
4. Is every irreversible action — auth, payments, deletion, schema migration — human-gated? Why it matters: speed is free, but a dropped table is not; you gate by blast radius, not by trust in the generator. → P5, Risks, Security and Governance
5. Are your files small and isolated to a single bounded context? Why it matters: a generator and a reviewer both reason better over a tight context; sprawling files are how unrelated logic leaks into one blast radius. → P4
6. Can you personally evaluate every domain in your slice — or do you pair where you can't? Why it matters: you cannot verify what you cannot read; an unverifiable domain is a liability you've named, not avoided. → P6, Operator Competency Model
7. Do you size work by Context Entropy — preparation difficulty — rather than story points? Why it matters: with N=1 and free syntax, the cost is getting ready to generate well, not typing; story points measure a coordination problem you no longer have. → Module 5
8. Does your spec include explicit edge cases and acceptance criteria before you generate? Why it matters: a spec without edge cases is a wish; the generator fills ambiguity with plausible guesses, and plausible is exactly what slips through review. → SDD Spec Template
9. Do you measure your regression escape rate — not just velocity? Why it matters: velocity with a rising escape rate is just shipping bugs faster; escape rate is the one number that can't be gamed by going quicker. → KPIs and Metrics
10. Does every bold claim or decision ship paired with its honest limit? Why it matters: a claim without a Reality Check is marketing; honesty by construction is what lets anyone else trust the rest of your work. → P7
Add your yeses. Then locate yourself on the Maturity Model — and remember its rule: your true level is the highest rung where the proof metric is real, not the highest behaviour you can describe.
| Score | Band | Maturity level | What it means |
|---|---|---|---|
| 0–3 | Ad-hoc | L1 | Prompt, paste, ship. The only durable artifact is the code. You have a habit, not a practice. |
| 4–6 | Emerging | L2–L3 | A spec exists and review is starting, but discipline is selective — applied to the scary changes, skipped on the routine ones. |
| 7–8 | Disciplined | L3–L4 | Adversarial verification and measurement are the default, not the exception. The loop holds under pressure. |
| 9–10 | Sovereign | L4–L5 | Spec-first, independently refuted, instrumented, blast-radius-gated, honest by construction. Incidents close the loop back into the spec. |
Reality check. A 10 is not a trophy. It is table stakes for shipping production software solo. Every yes on this list is something a healthy team of several people used to get from process, headcount, and a second pair of eyes — meetings, code owners, a QA function, a release manager. As the sovereign operator, you absorbed all of it. Scoring 10 means you've rebuilt those guarantees as discipline; it does not mean you're done. The work is keeping the score at 10 on the next change, when you're tired and the deadline is real. That's the whole game.
See also: The Maturity Model (the bands in full) · First Principles (P1–P7) · KPIs and Metrics · The Verification Doctrine · Operator Competency Model · Getting Started.