-
Notifications
You must be signed in to change notification settings - Fork 0
Where SAE Sits
Status: Complete · SAE positioned honestly inside the 2025–26 conversation on AI-native delivery — informed synthesis, not first discovery.
SAE did not invent the idea that specs should drive AI, that AI-assisted work needs discipline, or that you should separate the what from the how. Those ideas are in the water in 2025–26, and several serious people got there first. This page names them, represents them accurately, and then states plainly the narrow lane SAE actually owns.
The intellectually honest move is to concede the borrowed ideas loudly so the original ones stand out clearly. SAE's debts are real. So is its delta.
The discourse on building software with AI agents sorted itself into a spectrum over 2025–26, running from "stop caring about the code" to "care harder than ever, just faster."
Karpathy coined vibe coding in a now-famous post on 2 February 2025: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." You describe what you want, accept what the model emits, and feed errors back without reading the diff. It was named Collins Dictionary Word of the Year 2025. It is genuinely useful for throwaways, demos, and learning — and genuinely dangerous for anything you have to maintain or be accountable for. SAE sits at the opposite pole: vibe coding optimizes for not caring about the code; SAE makes accountability for the code a first-class, measured concern.
Willison proposed vibe engineering in October 2025 as the deliberate inverse of vibe coding: seasoned professionals accelerating with LLMs while staying "proudly and confidently accountable for the software they produce" — resting on automated testing, planning, documentation, and rigorous process (version control, CI, code review). By early 2026 the field had largely migrated to calling this agentic engineering. SAE shares Willison's value system almost entirely. The difference is scope and instrumentation: vibe engineering is a stance for experienced engineers; SAE is an opinionated operating model with named roles, blast-radius gating, and a numeric unit of work.
Osmani (Google) frames agentic engineering as "disciplined, agent-assisted development with human oversight" — write specs before prompting, review every diff, run the suite, treat the AI as a fast but unreliable junior. His Agent-Skills project encodes senior-engineer workflows and quality gates as reusable skills so agents execute them consistently. This is close kin to SAE's Operator Techniques and the Digital Org Chart. SAE's added bet is adversarial independence — not just "review every diff" but the writer never judges its own work; a fresh-context Guardian tries to refute it.
Beck defines augmented coding as keeping traditional engineering values — caring about code, complexity, tests, coverage — while using AI as a power tool that amplifies judgment rather than replacing it. Explicitly contra vibe coding. SAE is squarely in the augmented-coding tradition; the Reality Check habit is, in spirit, Beck's "tidy code that works" applied to claims as well as code.
Spec Kit operationalizes Spec-Driven Development: invert the power structure so "intent is the source of truth," the spec generates implementation, and code serves the spec. Works across 30+ coding agents. This is the prior art for SAE's SDD-Spec-Template and spec-as-source-of-truth pillar. SAE adopts the philosophy wholesale.
Kiro (built on Code OSS, routing Claude Sonnet for reasoning and Amazon Nova for throughput) makes the spec the unit of work: prompts become structured specs → design → tasks → code + tests + docs, with agent hooks that fire on file events. Kiro independently arrived at "the spec, not the prompt, is the unit of work" — and said it well. SAE agrees on the spec's primacy but defines its unit of work differently (see below).
BMAD is an open-source multi-agent framework: 12+ domain-expert agents (PM, Architect, Developer, UX, QA) running a four-phase cycle (Analysis → Planning → Solutioning → Implementation), mirroring an agile team in agents. It is the closest sibling to SAE's Digital Org Chart — and a useful contrast. BMAD simulates the team; SAE's thesis is "collapse the handoff, not the headcount" — keep the concerns (PM, architecture, QA) as modes one operator moves through, not a standing roster of personas to coordinate.
Grey-box testing combines black-box (no internal knowledge) and white-box (full internal knowledge): the tester has partial knowledge — architecture, models, contracts — and uses it to design adversarial cases. SAE's Guardian is grey-box by design: it sees the spec and the interfaces (partial knowledge) but judges from a fresh context, refuting behaviour rather than rubber-stamping the author's mental model.
| SAE | GitHub Spec Kit | AWS Kiro | BMAD-METHOD | Vibe coding | |
|---|---|---|---|---|---|
| Team size | Solo / small team (the team-of-one) | Any (tool, agent-agnostic) | Individual dev in an IDE | Small team or solo simulating a team | Individual, any |
| Source of truth | Spec, with measured drift vs. code | Spec ("intent is source of truth") | Spec (requirements → design → tasks) | Phased agile artifacts (PRD, architecture) | The running behaviour; code is disposable |
| Verification model | Adversarial independence — fresh-context Guardian refutes (grey-box) | Whatever your agent + CI provide | Agent generates tests alongside code | QA agent persona in the cycle | "Feed the error back to the model" |
| Governance / gating | Blast-radius gating — auth, payments, deletion, schema drops never auto | Not prescribed | Agent hooks; human in IDE loop | Human approval between phases | None |
| Unit of work | Context Entropy (prep difficulty, scored 1–13) | The specification | The specification | The agile story / phase | The prompt |
| Ideal user | Accountable operator shipping production solo/small | Teams adopting SDD on existing agents | Devs wanting spec rigor inside one IDE | Teams wanting an agile shape over agents | Hobbyist, prototyper, learner |
Strip away the borrowed parts and three contributions remain that are genuinely SAE's own:
-
Context Entropy as the unit of work. Spec Kit and Kiro make the spec the unit; everyone else makes the prompt or the story the unit. SAE makes the unit a measured quantity — preparation difficulty scored 1–13. You estimate how hard a thing is to make legible to an agent, not how hard it is to type. This is the moat: see Module 5 and KPIs and Metrics.
-
Adversarial independence as a co-equal moat. "The writer never judges its own work." Osmani says review every diff; Kiro generates tests beside the code. SAE structurally forbids the author from grading itself and stands up a fresh-context Guardian whose job is to refute — grey-box verification as an operating discipline, not a phase. See Module 3 and Risks, Security and Governance.
-
Measured spec-drift. SDD's "spec is the source of truth" is only true if you measure when code and spec diverge. The prior art asserts the spec's primacy; SAE instruments it. That instrumentation is the delta — see First Principles and SDD-Spec-Template.
Net: SAE is the disciplined, measured operating model for solo and small-team AI-native delivery. It competes on discipline and measurement, not speed — and it is honest by construction: every bold claim ships paired with a named Reality Check.
Reality check. Spec-driven development and separation of concerns are not SAE inventions. SDD predates SAE and is best-articulated by GitHub Spec Kit and AWS Kiro; separation of concerns is decades old; the "be accountable while using AI" stance belongs to Willison, Osmani, and Beck; the org-chart-of-agents idea is BMAD's. SAE's honest claim is synthesis plus three original instruments — Context Entropy, adversarial independence, and measured spec-drift — not first discovery. If you already run Spec Kit with rigorous review, you have most of SAE's value without the SAE label; what SAE adds is the numeric unit of work and the structural refusal to let a writer grade itself.
See also: The SAE Manifesto · First Principles · Evolution and Positioning · Objections · When Not to Use SAE · Module 2 — Core Pillars · Module 3 — The Digital Org Chart · Glossary
The Sovereign Architect‑Engineer (SAE) Framework · Maintained by Sanjeev Azad · Repository · MIT License · Contribute
- Module 1: The Sovereign Paradigm Shifts
- Module 2: Core Pillars of SAE Architecture
- Module 3: The Digital Org Chart
- Module 4: The Lean SAE Tech Stack
- Module 5: Project Navigation & Metrics
- The End‑to‑End Lifecycle
- Operator Competency Model
- The Verification Doctrine
- Scenario Playbooks
- Operator Techniques
- Best Practices
- KPIs & Metrics
- The Maturity Model
- The Anti-Pattern Catalog
- Risks, Security & Governance
- Governance, Versioning & Stewardship