Director-Driven Development

You direct. Agents build. A check proves every task.¶

Director-Driven Development is a way of working with AI coding agents. The human is the director: design, priorities, acceptance and the final say. Agents build one small task at a time in a fresh context, and one automatic check decides when a task is done. Creativity, inside a frame.

Elevator pitch¶

Who it is for. Director-Driven Development is for anyone who wants to use AI coding agents to build software and stay in control of what gets built.
The problem. The first prompt is easy. The second is where it breaks: context fills up, the agent quietly decides things nobody agreed to, and every new session reinterprets the project from scratch. Before you know it, the product that was built is no longer the product you ordered.
The solution. DDD puts you in the director's seat. Every task is small and handed to a fresh agent that reads only what it needs. Design decisions come to you as options, and only your choice is recorded. One automatic check decides when a task is done. The agent never guesses intent.
Why it is different. Most AI workflows guide the agent with prompts, and prompts can be ignored. DDD enforces the architecture through a check that fails the build: a rule in the wrong layer, a tenant ID read from a request, logic where it does not belong. Directing scales by turning repeated judgment into checks.
Try it. Pick the framework that fits your stack, install it in your own repo, and run /next-task. All three frameworks are free, MIT licensed, and work with any AI coding assistant that reads AGENTS.md.

The roles¶

You · the director

Director¶

Design, priorities, acceptance. Final say.

Main session

Orchestrator¶

Picks tasks, records decisions, hands off builds. Never reads the code being changed.

Subagent

Builder¶

Builds one task in a fresh context and returns a short report.

Subagent, read-only

Reviewer¶

Reviews large and risky changes in a fresh context, before the commit.

Subagent, read-only

Researcher¶

Researches one question and returns options. It informs, the director decides.

The loop¶

01

Decide¶

The agent proposes options. The director decides.

02

Build¶

One sized task, one fresh builder.

03

Prove¶

The check passes, or the task isn't done.

04

Commit¶

One task, one commit.

Three frameworks, one model¶

The same loop runs all three. Only the rules the check enforces change.

App-Director ¶

Small web, mobile and desktop apps, on TypeScript, Flutter or Python.

Godot-Director ¶

Games in Godot 4. The check fails when a screen script holds game rules.

SaaSAllTheThings ¶

Multi-tenant B2B SaaS on Azure, with an architecture the check enforces.

All three are MIT licensed, run locally, and work with any AI coding assistant that reads AGENTS.md. They are built and tested on Claude Code.

Built with the frameworks¶

Each framework has an example. PKSEI, a rage game you can play in the browser, was built with Godot-Director. This site is built with App-Director: every change is a task in its TASKS.md, design decisions are recorded in product/, and one check passes before every commit. Build a B2B SaaS on Azure is the worked example for SaaSAllTheThings. The repository that holds this site also develops the three frameworks: see how framework work runs on GitHub.