Intent-Driven Engineering: When AI Can Build Almost Anything, Intent Becomes the Engineering Discipline

Intent-Driven Engineering: When AI Can Build Almost Anything, Intent Becomes the Engineering Discipline

For most of my career, software development had an obvious constraint:

Building software was expensive.

We spent enormous amounts of time turning requirements into designs, designs into code, code into tests, and tests into production systems.

AI is changing that constraint.

An AI coding agent can now generate a surprising amount of working software in minutes.

That sounds like the solution.

It also exposes a much bigger problem.

What happens when building becomes easier than deciding what should be built?

That is where Intent-Driven Engineering begins.

The ticket is not the intent

Consider a normal requirement:

Add an approval workflow.

That tells an engineer what somebody thinks the solution should be.

It doesn’t necessarily tell us why.

Maybe the actual objective is:

• reduce compliance risk,

• prevent expensive mistakes,

• establish an audit trail,

• reduce approval time,

• or eliminate approvals happening through email and chat.

Those are different problems.

They may require completely different solutions.

Yet once the ticket says “build an approval workflow,” much of the reasoning has already been taken away from the engineer — or, increasingly, from the AI agent.

We’ve accidentally turned an outcome into an instruction.

AI makes this problem bigger, not smaller

When humans wrote nearly every line of code, detailed specifications often made sense.

Implementation was expensive.

Coordination was expensive.

Changing direction was expensive.

But an AI agent operates differently.

Give a capable agent a desired outcome, the authoritative information it can use, the required outputs, meaningful constraints, and a definition of success — and it can reason about how to accomplish the objective.

That changes the engineering relationship.

The human no longer needs to specify every implementation decision.

In fact, doing so can make the agent less useful.

We can constrain the very reasoning capability we are paying for.

Three responsibilities

I increasingly think about modern AI-assisted engineering as three distinct responsibilities.

The human owns intent and boundaries.

The human should define:

Outcome

What are we trying to accomplish?

Inputs

What information or systems are authoritative?

Outputs

What must exist when the work is complete?

Success criteria and evidence

How will we know it worked?

True constraints

What boundaries cannot be violated?

Security requirements.

Regulatory requirements.

Compatibility requirements.

Cost limits.

Business rules.

Those belong to the human.

The agent owns reasoning.

Once the intent is clear, the agent should have room to determine:

• architecture,

• implementation strategy,

• decomposition,

• sequencing,

• algorithms,

• frameworks,

• refactoring,

• testing approaches,

• and other technical decisions.

Unless one of those things is itself a legitimate business or engineering constraint, it does not automatically belong in the intent.

This is one of the most important changes AI brings to software engineering.

Structure the boundary, not the reasoning.

The system owns the evidence.

We also should not simply trust an agent because it tells us the work is complete.

Software still needs deterministic verification.

Tests.

Hooks.

Static analysis.

Security controls.

Observability.

Metrics.

CI/CD validation.

Business measurements.

The agent may reason probabilistically.

The evidence should not.

That gives us a simple model:

Human → Intent

Agent → Reasoning

System → Evidence

Minimum sufficient constraint

This leads to another principle I use constantly:

Minimum sufficient constraint.

The objective is not to create the world’s most detailed specification.

The objective is to provide the smallest amount of constraint necessary for the agent to produce a result we can evaluate safely.

Then run it.

Look at the result.

Refine the intent.

Run it again.

That is Progressive Intent.

Instead of trying to predict every implementation detail before development starts, we progressively improve the intent based on observable results.

Sometimes the most valuable human feedback is simply:

That’s not what I meant.

That is legitimate engineering information.

The human does not have to prescribe the technical correction.

The agent can reason about the correction.

From requirements to executable intent

This is where I believe Intent-Driven Engineering becomes more than requirements management.

The intent becomes an engineering artifact.

It can live with the repository.

It can be evaluated by an agent.

It can reference enterprise systems and authoritative sources.

It can drive implementation.

It can trigger validation.

It can produce evidence.

And it can evolve as the human learns more.

The repository stops being merely a container for code.

It becomes a container for:

Intent → Reasoning → Implementation → Evidence → Refined Intent

That loop is what makes AI-assisted engineering fundamentally different from simply adding an AI coding assistant to the old SDLC.

The engineer is not disappearing

This doesn’t make engineers less important.

It changes where the highest-value engineering work happens.

When implementation becomes cheaper, understanding becomes more valuable.

Architecture becomes more valuable.

Boundaries become more valuable.

Evaluation becomes more valuable.

Knowing which constraints matter — and which ones should be left to the agent — becomes more valuable.

The engineer of the future isn’t necessarily the person who writes every line.

It is increasingly the person who can state the right intent, establish the right boundaries, evaluate the result, and improve the system.

And this may be why others are reaching the same conclusion

I recently came across another article using the term Intent-Driven Engineering.

What surprised me was how closely some of its conclusions aligned with ideas I had reached independently.

Then I realized that shouldn’t be surprising.

When technology changes the economics of implementation, people working on the same underlying problem often converge toward similar ideas.

AI has made building faster.

So the bottleneck moves upstream.

From:

How do we build this?

toward:

What are we actually trying to accomplish?

And then downstream again:

How do we prove that we accomplished it?

That’s the territory I believe Intent-Driven Engineering needs to own.

Not another requirements template.

Not another giant specification.

Not another way to tell an AI exactly how to think.

A disciplined separation of responsibilities:

Humans own intent and boundaries.

Agents own reasoning.

Systems own evidence.

And then we repeat the loop until the result matches the intent.

That, to me, is what engineering looks like when implementation is no longer the hardest part.