The Intent-Driven Enterprise Is Here book released! AI Can Write the Code. The Bigger Question Is: Who Defines the Intent?
- Mark Kendall
- 43 minutes ago
- 4 min read
The Intent-Driven Enterprise Is Here
AI Can Write the Code. The Bigger Question Is: Who Defines the Intent?
For the last year, I’ve been working on a simple idea that has turned into something much bigger:
What happens when we stop treating AI like a faster programmer and start designing engineering around intent?
That idea became Intent-Driven Engineering.
And now I’ve pulled the concepts, architecture, lessons, patterns, successes, failures, and practical techniques together into a book:
The Intent-Driven Enterprise
Available now as a digital PDF for $10.98.
We Don’t Have a Coding Problem Anymore
AI can generate code.
It can write tests. It can analyze repositories. It can refactor applications. It can call tools, use APIs, interact with external systems, coordinate agents, and increasingly execute entire engineering tasks.
The bottleneck is moving.
The difficult question is no longer:
“How do we get AI to write more code?”
It’s:
“How do we tell AI exactly what we want, give it the right context, establish the boundaries, and prove that it accomplished the goal?”
That is the problem Intent-Driven Engineering is designed to solve.
Intent Becomes the Center of the Architecture
Instead of beginning with prompts, agents, workflows, or tools, Intent-Driven Engineering begins with a clear definition of the desired outcome.
At its simplest, an intent defines four things:
Intent / Goal — What are we trying to accomplish?
Inputs / Context — What does the system need to know?
Outputs — What must be produced?
Success Criteria — How do we know the job is actually finished?
From that foundation, everything else becomes an architectural decision.
Use a Skill when the system needs reusable knowledge about how your organization does something.
Use a Hook when a rule cannot be optional.
Use a Tool when AI needs to take an external action.
Use MCP when AI needs governed access to systems, data, and services.
Use a Subagent when specialization, isolation, or parallel reasoning provides a real benefit.
Use an Orchestrator when sequencing, dependencies, recovery, or failure consequences require control.
And when none of those things are necessary?
Don’t add them.
Let the system remain goal-oriented.
That’s one of the central ideas behind the entire approach:
Govern what must be governed.
Structure what must be structured.
Orchestrate what must be orchestrated.
Leave everything else goal-oriented.
Context Is Becoming Part of the Architecture
There’s another enormous shift happening.
For decades, architects thought about APIs, databases, services, networks, security, events, and infrastructure.
AI introduces another architectural resource:
Context.
Every AI worker has a context window.
Every agent boundary creates a context-passing decision.
Every orchestration step raises a question:
What does this worker actually need to know to accomplish its intent?
Passing everything creates noise, cost, latency, and confusion.
Passing too little creates failure.
Intent-Driven Engineering treats those boundaries as information contracts.
Pass the minimum sufficient context.
Pass intent.
Pass constraints.
Pass relevant state.
Pass evidence when downstream verification matters.
And don’t dump an entire conversation into another agent simply because you can.
This is context engineering meeting software architecture.
This Isn’t Another Prompt-Engineering Book
Prompt engineering is useful.
But prompts are only one piece of a much larger engineering system.
The Intent-Driven Enterprise is about building an architecture where AI can actually participate in engineering work safely and effectively.
That includes:
Intent → Context → Reasoning → Tools → Execution → Validation → Evidence
The goal isn’t autonomous AI running around doing whatever it wants.
The goal is bounded autonomy.
Humans establish the intent.
Architecture establishes the boundaries.
AI gets freedom inside those boundaries.
Deterministic controls protect the places where failure matters.
And evidence tells us whether the intent was actually satisfied.
You Can See the Work, Not Just Read About It
A lot of this work has been developed publicly.
I’ve published code, experiments, prototypes, architecture patterns, agentic workflows, intent files, skills, hooks, MCP experiments, and other examples on GitHub.
There are now dozens of public repositories there covering different pieces of this evolution. (GitHub)
You can also explore the broader methodology, articles, concepts, and ongoing work at:
The website starts with the same fundamental principle:
Define what you’re building before you build it. (Intent-Driven Engineering)
Why I Wrote The Intent-Driven Enterprise
The AI development conversation is moving incredibly fast.
New models.
New agents.
New coding tools.
New protocols.
New frameworks.
New diagrams every week.
But underneath all of that technology is a much more durable question:
What do we want the system to accomplish?
If we can express that clearly, provide the right context, establish the right constraints, give AI appropriate capabilities, and objectively validate the result, something fundamental changes.
We stop micromanaging AI.
We start architecting outcomes.
That is the transition this book explores.
The Next Generation of Software Engineering Won’t Start With Code
It will start with intent.
Developers aren’t disappearing.
Architects aren’t disappearing.
Engineering isn’t disappearing.
But our jobs are changing.
The value is moving upward—from manually producing every implementation detail toward defining goals, designing boundaries, managing context, governing capabilities, validating outcomes, and building systems capable of executing increasingly sophisticated intent.
That’s the Intent-Driven Enterprise.
And we’re only getting started.
Get the Book
The Intent-Driven Enterprise is available now as a downloadable PDF.
$10.98 — Immediate Digital Access
If you’re a developer, architect, engineering leader, AI practitioner, or simply trying to understand where software engineering goes after AI learns to code, this book was written for you.
Don’t just learn another AI tool.
Learn the architecture behind what comes next.
Define the intent. Govern the boundaries. Let AI do the work.
Comments