Human Declares. Agent Reasons. System Verifies.
Human Declares. Agent Reasons. System Verifies.
The more I work with AI-assisted software engineering, the more I believe the architecture can be reduced to three responsibilities:
Human declares.
Agent reasons.
System verifies.
That may be the simplest description I have found for Intent-Driven Engineering.
And it helps separate three concepts that are often mixed together: declarative intent, goal-oriented reasoning, and deterministic control.
1. Human Declares
The human starts by defining what matters.
Not every implementation step.
Not every line of code.
Not every tool call.
The human defines the outcome.
That means declaring things like:
Intent
Boundaries
Inputs
Outputs
Success criteria
Architectural constraints
What must not fail
This is the declarative part of the system.
We are saying:
Here is the state we want to achieve.
That is very different from telling the system exactly how to achieve it.
For most of my career, this has really been the job of good engineering leadership anyway.
Understand the problem.
Define the requirements.
Establish constraints.
Determine what acceptable looks like.
AI does not eliminate that responsibility.
It makes it more important.
Because the more capable the execution system becomes, the more important the quality of the intent becomes.
2. Agent Reasons
Once the intent and boundaries are clear, we should allow the intelligent system to do what it is good at.
Reason.
Plan.
Explore alternatives.
Use tools.
Investigate the repository.
Read documentation.
Call APIs.
Create code.
Run tests.
Adapt when something unexpected happens.
This is the goal-oriented portion of the architecture.
Whether the runner is Claude Code, Copilot, Codex, Cursor, an autonomous workflow, or some future platform is almost secondary.
The principle remains the same.
Give the agent a goal and enough freedom to solve the problem inside the boundary.
This is also why I have become increasingly uncomfortable with giant procedural prompts.
If I already know every exact step the agent must perform, there may not be much reasoning left for the agent to do.
We are using intelligence but treating it like a shell script.
That is often the wrong abstraction.
The agent should be able to choose the path.
The architect defines the destination and the road boundaries.
3. System Enforces and Verifies
This is where things become especially important.
There are some requirements that should not depend on the agent’s judgment.
Security rules.
Compliance requirements.
Regression tests.
Build requirements.
API contracts.
Policy checks.
Deployment gates.
Critical architectural constraints.
Those should be deterministic whenever possible.
If a secret must never enter the repository, don’t simply tell the agent:
“Please don’t commit secrets.”
Add a deterministic control that blocks them.
If every service must pass a test suite before merging, don’t ask the agent whether it believes the code is ready.
Run the tests.
If a dependency is prohibited, enforce that rule.
If an API contract must remain backward compatible, validate it.
This is where hooks, CI pipelines, policy engines, linters, scanners, schema validators, and other deterministic mechanisms become essential.
The agent can reason.
The system decides whether certain boundaries were actually respected.
Declarative Is Not the Same as Deterministic
This distinction is important.
Declarative describes how we express the requirement.
Deterministic describes how we enforce or verify the requirement.
For example:
A human may declare:
Response latency must remain below 200 milliseconds.
That is declarative.
The agent may then decide how to improve the application.
That is goal-oriented reasoning.
A performance test measures whether the result actually stays below 200 milliseconds.
That is deterministic verification.
Three different responsibilities.
One engineering loop.
This Is Where Hooks Become Powerful
Hooks are especially valuable because they allow us to turn important boundaries into executable controls.
A standard may say:
Do not modify the production database schema without migration validation.
A hook can make sure the validation actually happens.
A rule may say:
Every implementation must include evidence against the success criteria.
A hook can stop completion if that evidence is missing.
The difference is simple.
A prompt asks.
A deterministic control enforces.
And we should know which one we need.
Don’t Over-Structure the Reasoning
This leads to one of the principles I keep coming back to:
Structure the boundary, not the reasoning.
The goal is not to tell the AI exactly how to think.
The goal is to clearly define the environment in which it is allowed to think.
That means:
Humans define intent.
Humans establish constraints.
Agents explore the solution.
Systems enforce critical rules.
Evidence determines acceptance.
This keeps the architecture simple while preserving control.
Intent-Driven Engineering in One Line
If I had to explain Intent-Driven Engineering in one sentence today, I would say:
Humans declare the important boundaries. Agents reason inside them. Deterministic systems verify and enforce what cannot be left to judgment.
That is the model.
It applies whether we are using one coding agent, a complex agentic workflow, MCP-connected enterprise systems, or a simple repository-level automation.
The technology will keep changing.
The models will get better.
The runners will change.
The orchestration frameworks will come and go.
But these responsibilities remain surprisingly stable.
Human declares.
Agent reasons.
System verifies.
That may be the essence of AI-native software engineering.
Comments