All posts

Engineering Planning Works Like Stable Diffusion

We just didn't have a name for it.

Start with noise. Then slowly, carefully, remove it.

Stable Diffusion doesn't generate an image in one shot. It starts with pure random static and runs dozens of denoising passes - each one guided by the prompt - until something coherent emerges. The trick is that it never skips a level of detail. You can't get sharp eyes before you have a face.

Engineering planning works exactly the same way. We just haven't been doing it deliberately.

Progressive denoising: four panels showing a plan evolving from scattered noise at 1000ft, to emerging structure at 500ft, to labeled interfaces at 100ft, to fully detailed implementation at 10ft
· · ·

Why this matters now

Most agent planning frameworks today treat planning as a single pass: decompose once, then execute. That's the equivalent of asking Stable Diffusion to skip straight to a finished image. Hand a complex feature to an AI agent and it dives straight into implementation details before anyone has agreed on the architecture. The root cause is always the same - skipping abstraction levels.

In the AI agents era, the first time a human sees the agent's work is often a massive PR - hundreds of files changed across multiple services. Reviewing that is nearly impossible. A bad architectural decision is baked into every file, and by the time you spot it, days of work need to be thrown out.

The fix isn't better prompts. It's a structure that forces progressive resolution - where an agent must earn the right to go deeper by getting human sign-off at each level of zoom. It fixes this in three ways:

  • Catch mistakes when they're cheap. A wrong service boundary at 1000ft takes minutes to fix. The same mistake discovered in a 500-file PR takes days. Each checkpoint is a moment where the human brain can actually process what's being proposed - because it's at the right level of abstraction.
  • Each level is easy to review. Validating a flow diagram is simple. Checking a sequence diagram against requirements is straightforward. Reviewing an API contract is manageable. Reviewing 47 changed files across 6 services is not. Progressive resolution matches review complexity to human cognitive capacity, level by level.
  • Research before you build - DRY by default. At each level, the agent researches the existing codebase before proposing anything new. At 500ft it finds existing services and patterns. At 100ft it finds existing APIs and schemas. At 10ft it finds existing utilities and helpers. Duplication gets caught before code is written, not after.
· · ·

Four zoom levels, each a prerequisite for the next

1000ft
Interactions and services Which users, which systems, how they talk. No schemas, no APIs - just the shape of the thing.
500ft
Data and boundaries Who owns what data. REST or queue. Auth boundaries. The architecture locks in here.
100ft
APIs and interfaces Concrete endpoints, request/response schemas, GraphQL mutations. The specifics emerge.
10ft
Implementation touchpoints Exact files, classes, migrations. Pixel-level. Tasks get written here.
Human checkpoint between every level

The agent presents its work. You review, push back, approve. Only then does it zoom in further.

This isn't process theater. It mirrors how good senior engineers actually think. You don't design a database schema before you've agreed on what service owns the data. You don't write API contracts before you've agreed on the system boundaries. Garbage noise at the 1000ft level produces garbage detail at the 10ft level. Every refinement step amplifies whatever signal - or noise - was present in the step before it.

· · ·

Go wide before you go deep

There's a subtler rule that the diffusion analogy reveals. Stable Diffusion doesn't resolve one corner of the image to full detail while the rest stays blurry. It denoises the entire frame together, level by level.

Engineering planning should work the same way. Map all your flows at 1000ft before zooming in on any single one. If you go deep on one flow first, you'll make architectural assumptions that break the others - and you won't find out until you're already committed.

Two grids comparing depth-first vs breadth-first planning: depth-first resolves one flow completely while others stay unmapped, breadth-first resolves all flows to the same level before going deeper
· · ·

Progressive trust

We're in the early days of figuring out how humans and AI agents should collaborate on technical work. The instinct so far has been to either micromanage every line (slow, defeats the purpose) or hand off entirely and review at the end (fast, but brittle).

The diffusion model suggests a third way: progressive trust. You don't need to watch every denoising step. But you do need to approve the image before it sharpens further. Each checkpoint is cheap. Catching a bad architectural decision at 1000ft takes minutes. Catching it at 10ft - after contracts, tasks, and implementation have been built on top of it - takes days.

Exponential cost bars: catching a bad decision at 1000ft costs minutes, at 500ft costs hours, at 100ft costs days, at 10ft costs weeks

The best engineering planning in the AI era won't look like waterfall. It won't look like agile. It'll look like diffusion.

· · ·

We built this into ProdE. The agent walks through exactly these four altitude levels - researching your actual codebase at each step, producing concrete artifacts (flows, contracts, tasks), and waiting for your sign-off before going deeper. No skipped levels. No implementation details before the architecture is locked.

See diffusion-based planning in action

Get a demo