Intent Driven Development

For sixty years software engineering has been organized around one act: a human translating what people want into instructions a machine can execute, by hand, one line at a time. That act was always lossy, expensive, and the bottleneck. Now machines can perform the translation continuously, and that changes not just how fast we work but what the work is.

The central claim: human intent is the primary artifact and the source of truth. Everything else, specifications, architecture, code, infrastructure, tests, and the running system itself, is derived from intent and continuously reconciled against it across the entire lifecycle. IDD is not a coding technique with ambitions; it is an engineering philosophy, comparable in scope to Agile, DevOps, or Platform Engineering, made practical for the first time by AI.

IDD does not begin at a keyboard. It begins in a meeting room with bad coffee, where the head of retail lending says "I want them to feel like we are on their side." That sentence is an intent: not a requirement, not a ticket, not a schema, but a human wish about how other humans should feel. Requirements do not fall from the sky; they are the fossilized remains of a messy conversation about what an organization is trying to achieve and why.

IDD is a loop, never a one-shot pipeline. It carries intent down into a running system and carries reality back up to refine the intent, a mechanism the book calls intent reconciliation. That return journey is the part almost nothing else has, and it is where IDD stops resembling anything you have seen.

A new center of gravity for the craft: from writing implementations to authoring and governing intent. Engineers, managers, architects, and product roles each find a path for their expertise to grow rather than erode, so that humans stay central while the boring bits of software engineering are entrusted to artificial co-workers.