Intent-Driven Engineering, Revisited: The Industry Is Starting to Converge

Intent-Driven Engineering, Revisited: The Industry Is Starting to Converge

For a long time, I have been writing about Intent-Driven Engineering.

Intent files. Context. Skills. Hooks. Agents. Tools. MCP. Contracts. Structured inputs and outputs. Validation. Governance. Orchestration.

At times, it probably sounded like a growing collection of AI terminology.

It isn’t.

After going around this problem again and again—building systems, watching the platforms evolve, seeing what works and what fails—I think the larger picture is becoming much clearer.

And interestingly, the AI industry is beginning to converge on many of the same principles.

Anthropic calls an important part of this context engineering.

Others talk about spec-driven development, agentic engineering, AI-native development, or agentic workflows.

Different terminology.

Different platforms.

But increasingly, the same underlying engineering problem.

How do we reliably translate human intent into working, governed, verifiable software using increasingly autonomous AI systems?

That is the problem Intent-Driven Engineering was always trying to solve.

Maybe We Were Looking at the Pieces Instead of the System

Prompt engineering was an important first step.

We learned how to communicate with models.

Then the models became more capable.

They gained tools.

They gained memory.

They gained repository access.

They gained MCP.

They gained Skills.

They gained subagents.

They gained the ability to execute code, inspect results, correct themselves, and continue working.

Suddenly, writing a better prompt wasn’t enough.

The engineering problem became much larger:

What does the AI need to know?

That is context engineering.

What are we actually trying to accomplish?

That is intent.

What capabilities should the AI be able to use?

Those are tools, Skills, APIs, MCP servers, services, and agents.

What absolutely must happen?

Those are deterministic boundaries, policies, contracts, hooks, tests, and governance.

How do we know the result is correct?

That is validation, evidence, acceptance criteria, and evaluation.

These aren’t competing methodologies.

They are layers of the same emerging engineering discipline.

Anthropic Helped Clarify Something Important

Anthropic’s work around context engineering provides an especially useful way of thinking about this.

Their basic argument is straightforward:

The challenge is no longer simply writing the perfect prompt.

The challenge is determining what information belongs in the model’s limited attention at the moment it needs it.

That means context has to be engineered.

Repository instructions.

Relevant files.

Tools.

Examples.

Conversation history.

MCP resources.

External information.

Previous findings.

State.

And importantly, not everything belongs in context all the time.

Good context engineering means providing the smallest useful collection of high-signal information that gives the model the best chance of accomplishing the goal.

That aligns remarkably well with where Intent-Driven Engineering has evolved.

Because IDE shouldn’t tell an intelligent system every tiny step it must perform.

It should establish the destination, the relevant context, the boundaries, and the evidence required to prove success.

Then allow intelligence to operate inside those boundaries.

Structure the Boundary, Not the Reasoning

This may be the simplest way I know to explain where I believe AI engineering is heading:

Structure the boundary, not the reasoning.

We absolutely need structure.

But we need it in the right places.

Define the intent.

Define the inputs.

Define the expected outputs.

Define success.

Define the contracts between components.

Define security boundaries.

Define what cannot be violated.

Define validation.

Define evidence.

Then give the AI room to determine how to get from here to there.

That is fundamentally different from attempting to encode every possible decision into a gigantic procedural workflow.

And it is fundamentally different from simply typing:

Build me this application.

There is a middle ground.

That middle ground is becoming AI-native engineering.

Intent Gives Context a Purpose

This is where I think Intent-Driven Engineering and context engineering fit together particularly well.

Context without intent is just information.

Intent gives context a reason to exist.

The relationship becomes:

Intent → Context → Capabilities → Execution → Validation

Intent answers:

What are we trying to accomplish?

Context engineering answers:

What does the intelligence need to know to accomplish it?

Capabilities answer:

What can the intelligence use to accomplish it?

Execution answers:

What combination of reasoning, workflows, agents, tools, and deterministic software should perform the work?

Validation answers:

How do we prove the original intent was actually satisfied?

Now we have an engineering system.

And This Is Bigger Than Claude

This part matters enormously.

I like Claude Code.

I like what Anthropic is doing.

Their thinking around context engineering, composable agents, Skills, tools, MCP, evaluation, and increasingly autonomous development is helping move the entire industry forward.

But Intent-Driven Engineering cannot become Claude-Driven Engineering.

And it cannot become ChatGPT engineering.

Or Copilot engineering.

Or Gemini engineering.

Or Cursor engineering.

The platforms will change.

Models will change.

Today’s best model will eventually not be the best model.

Tools will appear and disappear.

Agent frameworks will consolidate.

Standards will evolve.

The engineering principles underneath them need to survive all of that.

The AI Should Be Replaceable

Imagine an enterprise engineering model that looks like this:

BUSINESS INTENT

↓

INTENT CONTRACT

Goal

Inputs

Outputs

Success Criteria

Constraints

Evidence

↓

CONTEXT ENGINEERING

Repository context

Architecture

Standards

Current state

Relevant knowledge

Just-in-time retrieval

↓

GOVERNED CAPABILITIES

Skills

Tools

Agents

MCP

APIs

Shared services

↓

AI EXECUTION ENVIRONMENT

Claude Code

GitHub Copilot

ChatGPT

Gemini

Cursor

Tomorrow’s platform

↓

VALIDATION

Tests

Policies

Security

Architecture rules

Acceptance criteria

Evidence

↓

WORKING SOFTWARE

Notice something important.

The AI platform is only one layer.

That is intentional.

The methodology belongs to the organization.

The intelligence can change.

We Should Stop Betting the Engineering Organization on One AI

Enterprises don’t build their entire technology strategy around one programming language.

They don’t build every workload on one architectural pattern.

They don’t use one database for every problem.

Why would AI engineering be different?

Claude may be excellent for one workload.

Another model may be better for another.

One team may operate primarily through Copilot.

Another may use Claude Code.

Another may use ChatGPT.

Another may use Gemini.

The goal should not be forcing every engineering team onto the same AI.

The goal should be establishing an engineering system that allows different AI systems to operate within the same organizational principles.

That is where intent becomes powerful.

The Portable Asset Is Not the Prompt

This is another shift I think enterprises need to understand.

The valuable artifact isn’t necessarily the prompt.

It is the engineering knowledge around the prompt.

The intent.

The standards.

The contracts.

The architecture.

The Skills.

The validation.

The policies.

The examples.

The acceptance criteria.

The organizational knowledge.

Those things should become reusable engineering assets.

Anthropic’s move toward portable Agent Skills is particularly interesting because it reflects the same broader direction: organizational knowledge should increasingly become modular, reusable, and discoverable by intelligent systems.

That is much bigger than any individual coding assistant.

The Architecture Is Starting to Come Together

After spending a long time exploring Intent-Driven Engineering, I would describe the emerging model this way:

Intent defines the destination.

Context engineering supplies the right knowledge.

Skills encode reusable organizational expertise.

Tools and MCP provide access to the outside world.

Agents provide reasoning and autonomy where autonomy creates value.

Workflows provide deterministic sequencing where predictability matters.

Hooks and policies enforce boundaries that cannot be optional.

Contracts structure communication between components.

Evals and tests determine whether the system is actually working.

And underneath all of it:

Software engineering still matters.

Perhaps more than ever.

We Don’t Need Another Giant Framework

There is another principle worth protecting as this industry matures.

Don’t make this unnecessarily complicated.

Anthropic has repeatedly emphasized simple, composable patterns and increasing complexity only when the problem requires it.

I agree completely.

Don’t bring an agent to a function job.

Don’t bring a multi-agent architecture to a Skill job.

Don’t build an orchestration engine when a three-step workflow solves the problem.

Don’t dump an entire enterprise knowledge base into context when three files will do.

And don’t create a 47-page specification when four clearly defined intent pillars are enough.

Use the smallest correct mechanism.

Then evolve when evidence tells you that you need more.

Intent-Driven Engineering 2.0

So perhaps this is the right moment to reintroduce Intent-Driven Engineering.

Not as another AI framework.

Not as an alternative to context engineering.

Not as an alternative to Anthropic’s approach.

Not as a replacement for spec-driven development.

And certainly not as a methodology tied to a single AI vendor.

Instead:

Intent-Driven Engineering is an engineering operating model for translating human and business intent into governed, executable, and verifiable outcomes using intelligent systems.

Context engineering fits inside it.

Agentic engineering fits inside it.

Specs can fit inside it.

Skills fit inside it.

MCP fits inside it.

Traditional software engineering fits inside it.

Claude fits inside it.

Copilot fits inside it.

ChatGPT fits inside it.

Gemini fits inside it.

Whatever comes next should fit inside it too.

Because the durable idea isn’t the tool.

The durable idea is the engineering.

The Next Phase Isn’t About Inventing More Terminology

We have enough terminology.

What the industry needs now is convergence.

We need to take the strongest ideas emerging from Anthropic, OpenAI, Microsoft, Google, the open-source community, enterprise engineering teams, and practitioners building these systems every day and start turning them into repeatable engineering practices.

Keep what works.

Discard what doesn’t.

Measure the results.

Standardize the patterns that survive.

And keep the architecture open enough to incorporate the next breakthrough.

That is how software engineering has always matured.

AI engineering shouldn’t be any different.

Learn. Teach. Master.

That has always been the philosophy.

Learn what works.

Teach what we learn.

Master the patterns through repetition.

Then be willing to change them when something better comes along.

Intent-Driven Engineering isn’t finished.

It shouldn’t be.

Neither is context engineering.

Neither are agents.

Neither are Skills.

Neither is MCP.

Neither is AI-native software development.

We are still building the discipline.

And maybe that’s the most exciting part.

For the first time, we aren’t simply designing software systems.

We are designing engineering systems in which human intent, organizational knowledge, deterministic software, and machine intelligence can work together.

The vendors will compete.

The models will change.

The terminology will evolve.

But the mission should remain remarkably simple:

Understand the intent.

Provide the right context.

Structure the boundaries.

Give intelligence room to work.

Prove the outcome.

And never confuse the AI platform with the engineering methodology.

Intent is the constant. Intelligence is the variable.

p

I particularly like “Intent is the constant. Intelligence is the variable.” as the closing line. It gives us a killer concept for the custom Wix image too: IDE as the stable architectural layer across Claude, ChatGPT, Copilot, Gemini, Cursor and whatever comes next. Anthropic’s own published direction supports the underlying themes here: context as a finite engineering resource, simple composable agent patterns, portable Skills, deliberate tool contracts, and evaluation-driven reliability.