A methodology for building complex software systems with AI — where human vision, persistent architectural intelligence, and context-bounded execution work as complementary layers.
Companion to: Snowmelting Method
Context-window AI assistants are powerful in bursts. But they restart cold every session. Architectural memory vanishes. The same decisions get rediscovered. Systems drift between sessions.
Meanwhile, you're building something that spans months and hundreds of components.
No single session can hold the full picture. No human can act as the full-time translator between vision and code.
┌─────────────────────────────────────────────────────┐
│ LEVEL 1 — Human │
│ Vision · Trade-offs · What "done" means │
│ (you, the builder) │
└────────────────────┬────────────────────────────────┘
│ intent
▼
┌─────────────────────────────────────────────────────┐
│ LEVEL 2 — Persistent AI Architect │
│ Cross-session memory · Architecture decisions │
│ Handoff preparation · Drift prevention │
│ (Codex, GPT Projects, Gemini long-context...) │
└────────────────────┬────────────────────────────────┘
│ structured handoff
▼
┌─────────────────────────────────────────────────────┐
│ LEVEL 3 — Execution AI │
│ Wave-based implementation · Parallel teams │
│ Context-window bounded · Cold-start compensated │
│ (Claude Code, Cursor, Aider...) │
└─────────────────────────────────────────────────────┘
You hold what no AI can: the long-term product vision, the non-obvious trade-offs, the judgment about what actually matters.
Your job is not to micromanage implementation. Your job is to:
- Define the destination clearly
- Make the decisions that have no right answer
- Approve or redirect when something drifts from the intent
You spend time at the boundaries, not inside the execution.
This is the missing layer most teams skip.
A persistent AI (one with project memory, long context, or cross-session continuity) acts as the standing architect between your vision and execution. It:
- Holds architectural decisions across sessions
- Catches drift when implementation diverges from intent
- Translates high-level vision into executor-optimized handoffs
- Produces structured packages that execution AI can consume cold
Without Level 2, every execution session starts from scratch. With it, each session starts from a briefing.
The key artifact Level 2 produces: the Handoff Package.
Context-window AI (Claude Code, Cursor, etc.) is excellent at focused bursts of implementation. Its limits are real:
- It forgets between sessions
- It can't hold architectural consistency across 50+ components
- Given ambiguous specs, it improvises — sometimes well, sometimes not
Three-Level Development compensates for all three limits:
- Level 2 provides the spec so there's nothing to forget
- Level 2 maintains consistency across sessions so Level 3 doesn't have to
- Level 2 resolves ambiguity before execution begins
Level 3 then runs in waves — parallel teams, each with a clear handoff package. See Snowmelting Method for how wave execution works.
The core artifact of this methodology. A good Level 2 → Level 3 handoff contains:
id: package-identifier
priority: P0 | P1 | P2
goal: |
One paragraph. What this package builds and why it matters now.
input_docs:
- path/to/spec.md
- path/to/schema.md
likely_touchpoints:
- src/module/file.py
- src/api/router.py
done_when: |
Concrete, verifiable exit criterion.
Not "looks good" — something you can test or observe.
not_now:
- What to explicitly NOT do in this package
- Scope boundaries that prevent over-engineeringThe not_now field is as important as the rest. It prevents Level 3 from scope-creeping into adjacent work.
Session 1: Build auth module. Decide schema on the fly.
Session 2: Build user module. Re-discover auth schema. Slightly different interpretation.
Session 3: Build API layer. Tries to reconcile both. Drift is now structural.
Level 2 (persistent): Defines auth schema once. Writes handoff packages for auth, user, API.
Session 1 (Level 3): Receives auth handoff. Implements cleanly.
Session 2 (Level 3): Receives user handoff. Auth schema already resolved — no rediscovery.
Session 3 (Level 3): Receives API handoff. Same schema, same contracts. No drift.
These two methodologies are designed to work together:
| Snowmelting | Three-Level Dev | |
|---|---|---|
| Answers | How does execution happen? | Who prepares the work? |
| Focus | Wave structure, team delegation, synthesis | Level handoffs, drift prevention, handoff contracts |
| Level | Level 3 internal mechanics | Cross-level coordination |
Snowmelting describes how Level 3 execution AI runs parallel teams and synthesizes results.
Three-Level Development describes how Level 2 prepares work for Level 3, and how Level 1 stays in control without micromanaging.
They compose: Level 2 writes handoff packages → Level 3 runs Snowmelting waves against them.
Use Three-Level Development when:
- Your project spans multiple AI sessions and architectural consistency matters
- You've experienced drift where later sessions contradict earlier decisions
- Your system has 50+ components where no single session holds full context
- You want parallel execution without coordination overhead between teams
- You're building something where cold-start overhead is costing real velocity
You don't need a specific tool for Level 2. Any AI with project memory, long context, or cross-session continuity works. The methodology is model-agnostic.
Skipping Level 2 — Going directly from human vision to execution AI. Works for small projects. Breaks at scale. Architectural memory lives in the human, creating a bottleneck.
Level 2 over-specifying — Handoff packages that try to decide every implementation detail. Level 3 needs direction, not a script. Leave judgment calls inside the context window.
Level 1 micro-managing Level 3 — If you're reviewing every function signature, Level 2 isn't doing its job. Push that responsibility down.
Skipping not_now — Without explicit scope boundaries, execution AI expands work naturally. Every handoff needs a "don't touch this" section.
This methodology is actively used in the FYOS project — a personal AI operating system built with this three-level structure.
Level 2 in FYOS: OpenAI Codex with project memory
Level 3 in FYOS: Claude Code with Snowmelting wave execution
Level 1: Max (the builder)
MIT