Progressive Intent: The Practical Specification for Intent-Driven Engineering

Progressive Intent: The Practical Specification for Intent-Driven Engineering

For the last couple of years, I have been working toward a better way for humans and AI to build software together.

It started where many people start: with prompts.

The prompts became larger. More detailed. More structured. We tried to describe everything the AI should do, how it should think, what sequence it should follow, what architecture it should use, what rules it should obey, and how it should validate the result.

And it worked.

At least, it appeared to work.

The code got better. The prompts got more sophisticated. We turned prompts into intent files and began creating reusable structures around them.

But eventually a problem became obvious.

The more detailed the specification became, the less the human was actually participating in the specification.

The AI was interviewing the human, interpreting a few statements, and then generating an enormous document describing the solution.

Technically, the human had supplied the intent.

Practically, the AI had authored it.

That is where Progressive Intent emerged.

Intent-Driven Engineering

Intent-Driven Engineering starts with a simple idea:

The human should define what must be true, not prescribe every step required to make it true.

That distinction matters.

Humans and AI have different responsibilities.

The human understands the problem, the desired outcome, the business context, the boundaries, and ultimately whether the result feels right.

The AI is exceptionally good at exploring alternatives, reasoning through implementation choices, designing solutions, writing code, and adapting when the result does not meet expectations.

The system can then provide deterministic validation through tests, hooks, evidence, observability, policies, and other controls.

Those responsibilities form three distinct zones:

HUMAN → Intent, Boundaries, Judgment

AI → Reasoning, Creation, Adaptation

SYSTEM → Evidence, Validation, Enforcement

Intent-Driven Engineering works when we respect those boundaries.

The human should not unnecessarily dictate how the intelligence reasons.

The AI should not redefine the human’s desired outcome.

And neither should be trusted to simply declare that the work succeeded.

The system provides the evidence.

Why Progressive Intent?

Traditional specifications often attempt to anticipate everything before the first line of code is written.

Progressive Intent assumes something different:

We learn more by interacting with the working result.

Instead of attempting to create the perfect specification at the beginning, we begin with the minimum amount of intent necessary to produce something meaningful.

Then we build it.

We look at it.

We use it.

We decide what is wrong.

And we refine the intent.

That cycle repeats.

Intent → Build → Observe → Refine → Validate.

The specification becomes clearer as the product becomes real.

This is not an excuse for vague requirements. It is the opposite.

Progressive Intent forces the human to concentrate on the requirements that actually matter.

Minimum Sufficient Constraint

The central discipline of Progressive Intent is minimum sufficient constraint.

An intent should contain enough information to establish the desired outcome and protect important boundaries—but no more.

A useful initial intent usually focuses on a small number of things:

• What outcome are we trying to achieve?

• What authoritative inputs matter?

• What outputs must exist?

• What boundaries or constraints are genuinely required?

• How will we recognize success?

• What evidence must the running system provide?

• 
  

Notice what is normally missing.

Framework choices.

Component structures.

Algorithm choices.

Build sequences.

Testing frameworks.

Agent reasoning procedures.

Hosting decisions.

Architecture patterns.

Those decisions may eventually matter. But unless they are actual requirements, they belong to the implementation, not the intent.

The AI should have room to reason.

The Human Does Not Need to Know the Fix

This may be the most important part of Progressive Intent.

The human is allowed to say:

“I don’t like it.”

That can be legitimate engineering feedback.

The human might say:

“The application works, but it doesn’t feel premium.”

“The workflow is technically correct, but it feels confusing.”

“The page doesn’t feel like a beauty experience.”

“The response is accurate, but I wouldn’t trust it yet.”

None of those statements tells the AI how to solve the problem.

They shouldn’t.

The human owns judgment.

The intelligence owns adaptation.

The next iteration should incorporate that judgment without forcing the human to invent the technical solution.

This creates a very different development relationship.

Instead of humans attempting to simulate the reasoning of the machine, they provide direction and judgment while the machine explores the solution space.

Progressive Intent in Practice

The working method is intentionally small.

1. State the intent.

Describe the outcome and the few things that must be true.

2. Establish real boundaries.

Include only constraints that genuinely matter to the business, user, system, security posture, regulation, or environment.

3. Give the intelligence room to work.

Do not prescribe the reasoning path simply because you can.

4. Build something real.

The artifact matters more than another round of theoretical specification.

5. Inspect the result.

Humans judge usability, credibility, beauty, clarity, usefulness, and whether the result actually solves the intended problem.

6. Add the smallest necessary refinement.

Do not rewrite the entire specification every time something changes.

Add what was learned.

7. Validate with evidence.

Where success can be measured deterministically, the system should prove it.

Then repeat.

A Simple Test for Every Intent

Before an intent file is handed to an AI, ask one question:

Does every constraint belong to the human’s responsibility, or are we accidentally telling the intelligence how to think?

If a statement unnecessarily controls the implementation, reasoning process, architecture, tooling, or sequence of work, remove it.

If it describes something that genuinely must be true, keep it.

That one test prevents an intent file from slowly turning back into a giant prompt.

The Specification Is Not the Product

Perhaps the biggest lesson from this journey is that a larger specification does not necessarily represent more human intent.

Sometimes it represents less.

A 3,000-word AI-generated specification assembled from a short conversation may look impressive, but very little of it may have actually been authored, understood, or consciously chosen by the human.

A five-line intent that the human understands, runs, evaluates, changes, and progressively improves may contain far more genuine human ownership.

That is the difference.

Progressive Intent is not about writing less because less is fashionable.

It is about writing only what the human has the authority and knowledge to decide.

Then allowing intelligence to do what intelligence does best.

And allowing the running system to prove whether the combination succeeded.

The Progressive Intent Model

The model can be expressed simply:

Humans declare intent and boundaries.

AI reasons, creates, and adapts.

Systems verify with evidence.

Then the human observes the result and supplies the next piece of intent.

That loop continues until the desired outcome is achieved.

That is Progressive Intent.

And for us, it has become the practical operating specification for Intent-Driven Engineering.