Sep 26, 2026 · 3 min read

Intent-Driven Design: Compiling Outcomes Down to Running Bits

Stop designing visual button states in a vacuum. When AI can generate infinite boilerplate, the declarative specification is your actual executable.

Traditional software design has always had an awkward handoff problem.

A designer draws 40 screens in Figma with static lorem-ipsum copy. A product manager writes a 15-page PRD describing edge cases that the mocks completely ignored. An engineer looks at both, sighs deeply, and builds something that roughly resembles the middle ground.

In an era where autonomous agents can scaffold an entire full-stack application in ninety seconds, this pipeline is completely broken. If you give an AI code generator a vague aesthetic prompt like “make a sleek project management dashboard,” it will gladly generate 4,000 lines of brittle React components that look pretty and do absolutely nothing.

To build durable software at contemporary velocity, you need Intent-Driven Design.

[ Human Intent / Target Outcome ]
               │
               ▼
   ┌───────────────────────┐
   │    System Invariants  │  (What must NEVER break)
   └───────────┬───────────┘
               │
               ▼
   ┌───────────────────────┐
   │ Declarative Contracts │  (Schemas, State Machines, APIs)
   └───────────┬───────────┘
               │
               ▼
   ┌───────────────────────┐
   │   Agentic Synthesis   │  (Scaffolding, Code, Assets)
   └───────────┬───────────┘
               │
               ▼
   ┌───────────────────────┐
   │   Verification Gate   │  (CI Tests, Evals, Typecheck)
   └───────────────────────┘

What is Intent-Driven Design?

Intent-Driven Design means specifying the system’s target invariants and acceptable state transitions before writing a single line of UI or database code.

Instead of starting with:

“What should the navigation bar look like on mobile?”

You start with:

“What is the state machine of this domain, what are the forbidden transitions, and how does the user verify success?”

Here is the exact framework I use when designing internal tools:

1. Define the System Invariants First

Invariants are facts about your system that must remain true no matter what happens: no matter what the model hallucinates, what weird data the user submits, or how overloaded the network is.

Example for a billing portal:

• An account cannot have two active subscriptions simultaneously.
• A card charge cannot execute without an idempotency key tied to a specific checkout intent.
• Cancellation always takes effect at the end of the billing cycle, never mid-stream.

When you write down your invariants explicitly, they become automated unit tests before any application code is generated.

2. The Spec is the Machine

In Intent-Driven Design, the specification is not passive documentation. It is an executable contract.

// Define intent in pure types before generating endpoints
export interface SubscriptionIntent {
  readonly customerId: CustomerId;
  readonly planTier: "pro" | "team" | "enterprise";
  readonly billingPeriod: "monthly" | "annual";
  readonly promoCode?: string;
  
  // Explicit constraints that agents must enforce
  readonly constraints: {
    maxSeats: number;
    requirePaymentMethodOnFile: true;
  };
}

When an AI coding partner has access to typed schemas and clear invariant boundaries, it doesn’t wander off hallucinating fantasy database relationships. The prompt isn’t “build billing.” The prompt is:

“Implement the handler for SubscriptionIntent. Validate against constraints. Write unit tests proving the three invariants cannot be violated.”

3. Verification Gates Replace Code Reviews for Boilerplate

When you design with intent, you don’t waste 45 minutes of human attention reviewing whether someone properly imported a utility library or capitalized a CSS class.

Your intent is verified automatically:

1. Does the TypeScript compiler pass?
2. Do the invariant test suites go green?
3. Do the latency budgets hold under simulated load?
4. Does the synthesized UI match the state machine transitions?

If all gates pass, the code is correct by construction.

Why This Matters

When the cost of writing code collapses to zero, the value of precision in thinking skyrockets.

Teams that struggle today aren’t failing because their developers can’t type fast enough. They are failing because nobody on the team took the time to define what the software was actually intended to do before they asked an agent to generate it.

Intent is the compiler. Code is just the binary.