As software engineers, I get the feeling we’re moving almost entirely away from code. And I don’t just mean having conversations with agents where they write all the code.

But even further, maintaining just a system of prompts that describes the software. Treating the agents as some kind of modern compiler that compiles English into code. The natural language becomes the “code base”.

When we hold these imperative conversations with agents, tell them what we want, watch them write code, we review it, and then close out the session, starting all over from scratch next time. We lose so much each time.

Consider an almost declarative switch to how we treat software development with agents.

The Idea

What if we stopped maintaining code and started maintaining intent?

There has been recent talk of the 4 levels of communication with agents.

  1. Prompt Engineering
  2. Content Engineering
  3. Intent Engineering
  4. Specification Engineering

Intent-Driven Development (IDD) is a framework for building software where we describe what we want in natural language, and an Agent handles the how - not through live conversation, but through a structured, layered process with clear checkpoints for human review.

The result is three layers, each one derived from the layer above it:

  1. Intent Source - owned by people, written in natural language
  2. Decision Layer - owned by the agent, structured and human-reviewable
  3. Code - generated by the agent, derived from the Decision Layer

People maintain the Intent Source. The agent maintains everything below it.

The Three Layers

Intent Source

The Intent Source is the human-maintained specification of the application. It is the single source of truth for what the software should do. It contains:

  • Descriptions of features and desired behavior
  • User scenarios and journeys
  • Test cases described in plain English
  • Any architectural constraints or preferences the owners want to enforce
  • Descriptions or examples of look and feel, or an explicit choice to leave those decisions to the agent

The Intent Source is declarative, not conversational. Developers don’t chat with the agent to refine their intent. They write it down, review what the agent produces, and update the Intent Source if something needs to change. This is a critical distinction from how most people use coding agents today - there is no back-and-forth. The Intent Source is the interface.

Decision Layer

The Decision Layer is the agent’s structured interpretation of the Intent Source plus all the implementation decisions the agent made on its own. It serves two purposes: it shows the owners what the agent understood and decided, and it gives the agent a persistent record of its own reasoning so it doesn’t need to re-derive everything from the Intent Source on every pass.

The Decision Layer contains:

  • The agent’s distilled understanding of features and behaviors from the Intent Source (more precise and structured than the original natural language)
  • Technology and framework selections
  • Data models and schemas
  • Component and service boundaries
  • Workflow and state diagrams
  • API contracts
  • Key tradeoffs and constraints

Content in the Decision Layer is lightly marked to distinguish interpreted intent (what the agent understood from the Intent Source) from agent decisions (what the agent resolved on its own). This distinction matters during review - if a developer disagrees with an interpretation, they fix the Intent Source; if they disagree with a decision, they add a constraint to the Intent Source that steers the agent differently.

The format is not prose. It’s a collection of structured artifacts - schemas, diagrams, decision records, interface definitions - whatever is most precise and efficient while remaining human-reviewable.

Code

The generated implementation. Derived from the Decision Layer, testable against the scenarios and test cases defined in the Intent Source. The agent also generates automated tests that verify the English-language test cases from the Intent Source.

In an ideal state, people never need to read the code. In practice, code review may still be useful, but the goal is to make the Intent Source expressive enough that the code is predictably correct.

The Workflow

Building a New Application

Step 1: Write the Intent Source. Developers describe the application - features, behavior, scenarios, constraints, preferences. They describe it to the level of detail they care about and leave the rest to the agent.

Step 2: The agent proposes test cases and asks clarifying questions. The agent reviews the Intent Source and produces additional user scenarios and test case descriptions in English. It also flags anything ambiguous or underspecified. Developers review these, refine them, and add them back into the Intent Source. This is not a conversation - the agent’s output is reviewed offline and the Intent Source is updated.

Step 3: The agent builds the Decision Layer. Once the Intent Source is stable enough, the agent reads the full Intent Source and produces the Decision Layer - its interpretation of intent, plus all the architectural and implementation decisions needed to build the application.

Step 4: Developers review the Decision Layer. If something is wrong, humans don’t edit the Decision Layer directly. They update the Intent Source to be clearer or more specific, then let the agent regenerate.

Step 5: The agent generates code. With an approved Decision Layer, the agent writes the implementation and generates tests that map back to the Intent Source scenarios.

Ongoing Development

Once the application is in production, work continues through the same layers. Whether it’s a bug fix, a new feature, a behavior change, or a performance improvement, the process is uniform:

  1. The developer updates the Intent Source to reflect the desired change - refining a description, adding a test case, describing new behavior.
  2. The agent reads the diff, consults the relevant parts of the Decision Layer, and updates its decisions accordingly.
  3. The changes propagate down to code.

The agent doesn’t reprocess the entire Intent Source for incremental work. It looks at what changed and traces that through the Decision Layer to the code. From the agent’s perspective, the type of change doesn’t matter - bug fix, feature, refactor - it’s all just a delta to the Intent Source.

Coherence Pass

Over time, incremental changes can introduce drift. The Decision Layer may accumulate decisions that made sense in isolation but don’t hold up when viewed holistically. The code may have grown in ways that no longer align cleanly with the Decision Layer OR the Intent Source.

A Coherence Pass is a periodic full review where the agent:

  1. Reads the full Intent Source and compares it against the full Decision Layer to check for misinterpretations or outdated decisions.
  2. Reads the full Decision Layer and compares it against the code to check for implementation drift.

This is lighter than building from scratch because the agent isn’t making new decisions - it’s looking for mismatches. It can work in sections, checking cross-cutting concerns and flagging anything that needs attention.

This level of ecosystem/code-base code review is already being performed by foundation models today.

Example: A Task Management App

To make this concrete, here’s an over-simplified example of how IDD would work for a basic task management application.

Intent Source (written by the developers)

Feature: Task Creation
Users can create tasks with a title and optional description.
Each task has a status: pending, in progress, or complete.
Tasks are associated with the user who created them.

Feature: Task List
Users see their own tasks, sorted by most recently created.
Users can filter by status.

Scenario: New User Experience
A new user who has no tasks should see an empty state
with a clear prompt to create their first task.

Scenario: Completing a Task
When a user marks a task as complete, it should move to the
bottom of the list and appear visually distinct (muted).

Test Case: Status Filter
A user with 3 pending tasks and 2 complete tasks filters by
"pending" and sees exactly 3 tasks.

Constraint: Stack
Use PostgreSQL for persistence. No preference on framework.

Decision Layer (generated by agent)

## Interpreted Intent

- Tasks are simple: title (required), description (optional),
  status (enum: pending | in_progress | complete), owner reference,
  timestamps for created/updated.
- Task list is per-user, default sort: created_at DESC.
- Completed tasks sort last within the list, rendered with
  reduced visual emphasis.
- Empty state is a distinct UI state, not just an empty list.
- Status filter is exact match, single-select.

## Agent Decisions

- Framework: Next.js (App Router) - fits the scope, provides
  SSR for initial load, API routes for backend.
- ORM: Drizzle - lightweight, type-safe, good PostgreSQL support.
- Schema:
    tasks(id UUID PK, title TEXT NOT NULL, description TEXT,
          status task_status NOT NULL DEFAULT 'pending',
          user_id UUID FK, created_at TIMESTAMPTZ, updated_at TIMESTAMPTZ)
- Sort logic: ORDER BY (status = 'complete') ASC, created_at DESC
  - this pushes completed tasks to the bottom while preserving
  recency within each group.
- Filter: query parameter `?status=pending` applied as WHERE clause.
- Empty state component renders when task count for user is 0
  (before filtering).

Generated Code

Derived from the above. Includes the schema migration, API routes, UI components, and test suite that verifies the scenarios and test cases from the Intent Source.