Intent-Driven Engineering, Simplified

Intent-Driven Engineering, Simplified

After working with AI-assisted software development for the last couple of years, I’ve simplified how I think about Intent-Driven Engineering.

I no longer care very much where the initial intent comes from.

It can start as a prompt.

It can come from Jira.

It can come from a specification.

It can come from a conversation with a product owner.

It can be generated by Claude, Copilot, Cursor, Codex, or another AI tool.

What matters is whether the resulting engineering artifact is good enough to guide the work.

For me, a strong intent still comes down to four things:

Intent — What are we trying to accomplish?

Inputs — What context, constraints, references, and existing systems matter?

Outputs — What should be created or changed?

Success Criteria — How will we know the work is actually complete?

Once those things are clear, the intent belongs in the repository.

Maybe it is called feature.md. Maybe an organization uses another format. The filename is not the important part.

The important part is that the intent becomes a durable engineering artifact that humans, agents, automation, and verification systems can work from.

This Is Where IDE Really Starts

The repository is where the idea becomes engineering.

The feature is committed.

An AI coding agent can reason about it.

The implementation begins.

Tests, hooks, policies, and other deterministic systems verify the result.

Then the team learns something.

The intent gets refined.

A delta is added.

The process continues.

That is Progressive Intent.

We do not have to assume that the original requirement was perfect. We improve our understanding while we improve the software.

Humans, Agents, and Systems

The simplest version of Intent-Driven Engineering may be this:

Humans declare intent and boundaries.

They determine the outcome, constraints, context, priorities, and acceptable tradeoffs.

Agents reason and explore.

They plan, research, generate, implement, compare alternatives, and propose solutions.

Systems verify deterministically.

Tests run. Hooks execute. Evidence is collected. Policies are checked. Governance is enforced.

Each has a different responsibility.

IDE Is a Practice, Not a Tool

I used to spend more time thinking about how Intent-Driven Engineering compared with prompt engineering, spec-driven development, or particular AI platforms.

I think that distinction matters less now.

A good specification can express intent.

A good prompt can express intent.

A good conversation can become intent.

And almost any capable AI engineering tool can become the runner.

Intent-Driven Engineering is therefore not really about choosing the right AI product.

It is an engineering practice for organizing the relationship between human intent, agent reasoning, repository context, and deterministic verification.

The simplest principle I know is this:

The source of the intent matters less than the quality of the artifact in the repository.

Create the best intent you can.

Put it where the engineering happens.

Let agents reason.

Make systems prove the result.

Then improve the intent and repeat.