Module 2 Core Pillars of SAE Architecture

Module 2: Core Pillars of SAE Architecture

Status: Complete · The three structural pillars that make solo, AI‑native delivery actually work.

If Module 1 is the why, this is the how you structure the work. Three pillars: the vertical slice, AI‑readable code hygiene, and spec‑driven development.

---

2.1 The "Single‑Shot" Vertical Slice

Legacy delivery builds horizontally: DB engineers design tables, backend exposes endpoints weeks later, frontend eventually maps UI to those endpoints. Every layer boundary is an integration risk and an alignment checkpoint.

The SAE builds vertically. Using full‑stack context awareness, the operator builds an entire functional feature end‑to‑end in one unified cycle:

Database schema  →  API endpoint  →  State / data hooks  →  UI view layer
└────────────────── ONE execution cycle, ONE bounded context ──────────────────┘

Because the model holds the whole stack context concurrently, the backend data models and the frontend components stay aligned by construction.

Reality check. Single‑shot generation gives you structural alignment (the types line up, the API shape matches the UI). It does not give you behavioural correctness for free. Race conditions, auth edge cases, data‑integrity rules, and integration with external systems still need explicit tests. Do not read "bypass integration testing" as "skip verification" — read it as "the boundary that integration testing used to police now lives inside one slice, so you test the slice's behaviour instead of the seams between teams." The Guardian exists precisely because single‑shot is not the same as correct.

---

2.2 High‑Context Modular Design (AI Hygiene)

LLMs degrade fast on codebases with structural bloat, loose coupling, and sprawling files. To prevent context drift and hallucination, the codebase must be engineered for AI readability.

Self‑documenting directory layout

📂 sae-enterprise-project/
├── 📄 .cursorrules              # Immutable, system-wide LLM behavioural constraints
├── 📁 specs/                    # Bounded-context Markdown specifications
│   └── 📄 customer-billing.md   # The source of truth for the billing slice
└── 📁 src/
    └── 📁 features/             # Zero-dependency, encapsulated vertical slices
        └── 📁 billing/          # Bounded context: Billing domain
            ├── 📄 schema.sql    # Localized database definition
            ├── 📄 routes.ts     # Localized backend endpoints
            └── 📄 view.tsx      # Localized UI components

Rule of strict bounded contexts

Every feature is fully self‑contained. An agent modifying the billing slice should never need to parse the authentication system or user‑profile tables to understand its boundaries. Isolation prevents model confusion and accidental cross‑coupling.

Aggressive file‑splitting policy

Files target a single responsibility with a soft ceiling of roughly ~100 lines. Models operate near‑perfectly on small, cohesive files; accuracy decays sharply when navigating 1,000‑line monoliths.

Reality check. Treat ~100 lines as a pressure toward cohesion, not a hard law to game. Splitting a tightly‑coupled function across five files to hit a line count makes things worse for both humans and models. The real metric is: can a fresh context window understand this file without opening six others? Optimize for that.

---

2.3 Spec‑Driven Development (SDD)

In the SAE framework, writing code by hand is treated as an architectural failure. The operator's primary artifact is the Markdown specification. The spec — not the code — is the supreme source of truth.

The SDD protocol

Text version

[Human writes spec (.md)] ──▶ [AI parses context] ──▶ [AI generates / alters codebase]
          ▲                                                          │
          │                                                          ▼
 [Human edits spec first] ◀── [Change / bug encountered] ◀──────── [Reality]

1. The abstract manifest. The operator writes a pristine spec in machine‑readable Markdown: DB schemas, API payload shapes, UI actions, and explicit edge cases.
2. Context injection. The AI workspace parses the spec as an explicit system mandate.
3. Automated generation. The agent reads the spec, analyzes the current repo, and writes code across all target files.
4. The maintenance loop. When a bug or change appears, you never patch the code directly. You update the spec first, then re‑run generation so the code realigns to the spec.

Use the SDD Spec Template to write your first bounded‑context spec.

Reality check. "Never edit code directly" is the ideal that keeps the spec authoritative. In practice you will sometimes hand‑fix a one‑line bug under time pressure — the discipline is to fold that fix back into the spec immediately, or the spec rots and stops being the source of truth. A stale spec is worse than no spec, because everyone (including the agents) trusts it.

---

▶ Putting it into practice: Operator Techniques (vertical slicing, spec‑first debugging) · Best Practices (spec & context discipline) · SDD Spec Template · Agent Setup & Configuration.

Next: Module 3: The Digital Org Chart →