For decades, the measure of a software engineer was their command of syntax. We spent our careers acting as human compilers, translating business requirements into machine code, line by painstaking line. But as we transition into the AI-native era, that metric is shifting. We are moving away from a world where we focus on how to implement a feature, and into a world where we focus entirely on what that feature is intended to accomplish.
In our Human-centric AI-Native Distributed Systems Manifesto (if you haven't read it yet, please do), we outlined a future where we prioritize "Verifiable Intent over Syntactic Correctness." To ground this philosophy in reality, we need a new operating model. We need to move beyond the traditional boundaries of Domain Driven Design and Test Driven Development.
We need Intent Driven Development (IDD).
The Inescapable Reality of Distributed Systems
To understand why IDD is necessary, we must first accept the current state of the global economy. It is no longer possible to conduct significant business today without applications that are, in some manner, distributed. The era of the "isolated application" is dead.
Whether you are a logistics giant or a local fintech startup, your digital footprint is inherently fragmented. You are consuming APIs from payment providers, syncing data to mobile devices, replicating databases across regions for latency, and relying on third-party authentication services. "No application is an island," as our manifesto states. Every piece of logic exists within a complex, fragile web of dependencies, network latency, and eventual consistency.
This complexity creates a dangerous trap. As systems become more distributed, the cognitive load required to maintain them explodes. If we rely solely on manual coding, we move too slowly to compete. But if we recklessly hand the keys to an AI, we invite chaos. An AI can write a function that works perfectly in isolation on a developer’s laptop but fails catastrophically when introduced to the latency of a real-world network.
This is where IDD becomes the critical bridge.
The Engine of Intent
Intent Driven Development is the natural evolution of software engineering, accelerated by the "engine" of Artificial Intelligence. In an IDD workflow, the engineer’s primary responsibility shifts from being the manual laborer laying every brick to becoming the Architect defining the destination.
In the past, methodologies like Domain Driven Design (DDD) gave us the vocabulary—the maps of our system—but still required us to manually write the glue code to make those words interact. Test Driven Development (TDD) gave us verification, but required us to write "intent" buried inside unit tests that were often as complex as the code they were testing.
IDD elevates these concepts. DDD becomes the strict Schema that prevents the AI from hallucinating business concepts. TDD becomes Policy Verification, where we define high-level behavioral contracts, and the AI navigates the route to satisfy them.
So, What is IDD?
We have established the philosophy, but how does Intent Driven Development manifest in a daily engineering workflow?
IDD is an "Implementation-Last" methodology.
In traditional software development, we spend 80% of our time writing the implementation and 20% verifying it. IDD flips this ratio. We spend 80% of our time defining the Constraints and the Verification, and we let the AI handle the implementation in the seconds remaining. Specifically, IDD is a three-stage lifecycle:
1. The Definition Phase (The Human Context)
This is where the "Intent" is crystallized. Before a single line of executable code is written, the human engineer constructs the "Immutable Skeleton." This is not a vague prompt like "Make a user system." It is a rigorous set of artifacts:
The Contract (Schema): You define the exact input and output.
The Environmental Constraints: You explicitly select the technology (e.g., Vue, NestJS and MongoDB, or Angular, Spring Boot, and MySQL, etc. etc.). We call these "Foundries" in m8a.
The Behavioral Policy: Instead of writing code, you write the criteria for success (e.g., "Must retry 3 times with exponential backoff").
2. The Generation Phase (The AI Engine)
Once the Skeleton and Policy are locked, the AI is engaged. It is tasked with filling the void between the Input Contract and the Output Contract. Because the AI is constrained by your pre-selected stack and pre-defined business rules, it generates the boilerplate and logic required to satisfy your intent without "guessing."
3. The Verification Phase (The Automated Judge)
This is where "Verifiable Intent" supersedes "Syntactic Correctness." As soon as the AI generates the code, the system runs the Policy Tests. If the output fails the Schema or the Behavior check, it is rejected and regenerated. The human only reviews the solution that has already proven it meets the intent.
The "Intent File"
To make this concrete, IDD relies on a tangible "Intent File."
We are already seeing primitive shadows of this in the developer community today. Many developers are now adding files like CLAUDE.md or GEMINI.md to their repositories to "prep" the AI with context. While this is a step in the right direction, these local files are severely limited. They are static snapshots that only understand the code sitting next to them in the folder; they lack the global awareness of the living system. They are passive suggestions, not active architectural drivers.
In true IDD, the "Intent File" is not limited to a rigid format like YAML, JSON, or a static markdown file. The "Intent" can be anything made of text. It can be a structured design document, a technical spec, or—in advanced platforms like m8a—it can be context injected dynamically via Retrieval-Augmented Generation (RAG). By pulling context from your existing documentation, knowledge bases, or previous system states, the "Intent File" becomes a living entity.
Regardless of the source, the concept remains the same: The Intent is the Source Code; the actual Python or TypeScript files that get generated are merely the compiled artifacts of that intent.
The Non-Negotiable Human Layer
However, a critical distinction must be made to separate IDD from the chaotic "AI-generated" workflows often hyped today. In a true IDD architecture, AI drives the car, but the Human builds the road.
We do not ask the AI to "imagine" an architecture. We do not ask it to pick a database, choose a framework, or decide on a logging strategy. These are the "Rigid Structures" of our system, and they must remain under strict human ownership.
This is not a matter of preference; it is a matter of accountability.
1. The "3 AM" Rule
The primary reason humans must define the stack is simple: Accountability cannot be automated. When a production database locks up at 3:00 AM, the AI is not the one answering the pager. The engineer is. Therefore, the engineer must possess total agency over the tools they are required to debug. If we allow an AI to whimsically choose an obscure library because it "fit the prompt," we burden the human team with technical debt they did not consent to.
2. Guardrails Against Entropy
AI is inherently probabilistic; it craves novelty. If you ask an AI to "build a service" ten times without constraints, it might give you ten slightly different architectural variations. In a distributed system, this inconsistency is fatal. By locking the architecture into "Immutable Skeletons"—human-defined templates—we force the AI to adhere to organizational standards.
3. Strategic Homogeneity
Finally, architecture is rarely just technical; it is strategic. An AI cannot know that we use a specific cloud provider because of a corporate discount, or that we avoid a certain language because it conflicts with our hiring strategy. AI lacks the global context of the business.
The Architects of "Done"
This brings us to the ultimate role of the human in IDD: we are the Architects of "Done."
The AI can iterate indefinitely, generating code that is syntactically perfect but semantically void. It is the human engineer who must review the outcome, not for style, but for meaning. We provide the "Why" and the "Where." We set the hard guardrails, the frameworks, and the templates. The AI simply provides the "How."
By embracing Intent Driven Development, we stop being the manual laborers of syntax and finally become what we were always meant to be: the Architects of Intent.
Top comments (0)