When Not to Use SAE

When NOT to Use SAE (and FAQ)

A framework that can't name its own limits isn't a method — it's a sales pitch. This page is the honest counterweight to the manifesto. Read it before betting a real project on the SAE approach.

---

When the SAE framework fits

• Greenfield projects where you control the architecture from line zero.
• Solo founders / small teams shipping product fast.
• Internal tools, prototypes, MVPs, and well‑bounded SaaS features.
• Domains where you, the operator, have genuine breadth to evaluate AI output across the stack.

When to be cautious — or not use it

Situation	Why SAE strains	What to do instead
Regulated industries (health, finance, aviation, gov)	Layers like architect review and change sign‑off are legally mandated, not optional friction	Keep the mandated gates; apply SAE within them to remove the latency, not the controls
Safety‑critical / life‑critical systems	"Bypass integration testing" is unacceptable; failure cost is catastrophic	Formal verification, independent review, full test pyramid — SAE speed is the wrong optimization
Large existing teams	Collapsing to N=1 throws away parallelism you already have	Adopt SAE practices (SDD, vertical slices, AI hygiene) without collapsing roles
Massive legacy monoliths	Codebase violates AI hygiene; context windows can't hold it	Refactor toward bounded contexts before expecting clean generation
Deep domain expertise you lack	You can't review what you can't evaluate; agents will produce confident, wrong output	Pair with a human expert, or don't ship without one
The bus‑factor problem	One operator owning the whole lifecycle is a single point of failure	Document ruthlessly via specs; ensure a second person can pick up the specs/ folder

---

FAQ

Q: Does "collapse the 12 layers" mean skip QA, security, and review? No. It means absorb their function into the operator + Guardian loop and remove the handoff latency. The concern stays; the queue disappears. The Guardian and your own review are non‑negotiable.

Q: Is "bypass integration testing entirely" literal? No — it's shorthand. Single‑shot vertical slicing removes the cross‑team integration seam that integration testing used to police. You still test the slice's behaviour, especially edge cases, concurrency, auth, and external failures. See the Reality Check in Module 2.

Q: Doesn't N=1 just create a hero/bus‑factor risk? Yes, and that's the framework's main structural cost. The mitigation is Spec‑Driven Development: if the specs/ folder is authoritative and current, the project is legible to anyone who reads it — the spec is the succession plan.

Q: Is vendor lock‑in a problem with the Zero‑Ops stack? It's a real trade‑off. Favour tools with standard exit formats (plain Postgres, portable components) so Zero‑Ops doesn't become zero‑leverage. See Module 4.

Q: Can a team adopt SAE without firing everyone? Absolutely — and most should start there. Adopt the practices (SDD, vertical slices, AI hygiene, Zero‑Ops, adversarial QA) without literally collapsing to one person. The practices deliver most of the value; the N=1 collapse is the radical end of the spectrum.

Q: What's the single biggest failure mode? A stale spec. The moment code and spec disagree and the code wins silently, you've lost the source of truth and the framework degrades into ad‑hoc AI coding. Keep the spec authoritative.

---

Bottom line. The SAE framework is a high‑leverage method for the right operator on the right project. It is not a universal law. Its boldest lines are aspirational targets, not literal instructions — and every one of them is paired with a Reality Check for that reason. Use the parts that fit; keep the gates that exist for good reason.