Everyone Has “THE Way” to Build AI Now — Maybe That’s the Wrong Way to Think About It

Mark Kendall
2 days ago
5 min read

Everyone Has “THE Way” to Build AI Now — Maybe That’s the Wrong Way to Think About It

Spend five minutes on LinkedIn today and you can find the new way to build software with AI:

Agent Engineering.

Context Engineering.

Harness Engineering.

Flow Engineering.

Spec-Driven Development.

Agentic Engineering.

And, yes, Intent-Driven Engineering.

At first, this looks like another technology-industry naming contest. But beneath the terminology, serious practitioners are converging on a common architecture: define the mission, provide relevant context, constrain execution, validate the result and keep humans focused on judgment rather than repetitive review.

A recent roadmap from Dr. Maryam Miradi is an excellent example.

First: Credit Where Credit Is Due

Maryam Miradi has written extensively about production AI agents, context engineering, orchestration, MCP, evaluation, observability and Harness Engineering.

Her seven-step roadmap is:

Turn a task into a mission.
Define what good code means.
Provide context just in time.
Turn recurring mistakes into tests.
Add reviewer agents.
Move humans from reviewing every detail to steering the system.
Merge only after the harness proves the work is ready.

She describes this as a shift from coding tasks toward system steering, where repeatability creates production leverage. (LinkedIn)

Her broader work makes the same point: teams should not obsess over fashionable agent frameworks because most eventually implement variations of the same concepts—roles, structured inputs and outputs, reasoning, tools, memory and evaluation. (LinkedIn)

You can explore her work at Maryam Miradi’s website, review the Harness Engineering roadmap, and see her production-agent training covering orchestration, evaluations, permissions, observability, human gates and MCP. (Maryam Miradi)

This is not criticism of her roadmap. I think she is identifying the same fundamental shift many of us are seeing.

Maryam, I Think You’re Right — With One Addition

The engineering bottleneck is moving.

The question is becoming less:

“Can the AI write this code?”

Increasingly, the answer is yes.

The more important questions are:

Did we define the actual outcome?
Did the system receive the right context?
Did we constrain dangerous actions?
Did we preserve engineering judgment?
Can the result be independently verified?
Can the system prove that it satisfied the original business intent?

That’s where I would place one additional abstraction above the harness:

Intent

Before constructing the harness, we need to know what the harness exists to accomplish.

An Intent should define:

Goal

What outcome are we trying to achieve?

Inputs and Context

What does the system need to know?

Outputs

What must be produced?

Success Criteria

What evidence tells us we’re finished?

Once those are clear, architecture can choose the appropriate mechanism: a skill, hook, subagent, MCP server, deterministic workflow, ordinary code or a test.

Sometimes the right answer is:

Don’t build another agent at all.

Use the Smallest Correct Mechanism

Not every useful capability needs to become an agent.

A Skill teaches a reusable way of working.

A Hook or deterministic guardrail enforces a rule that cannot be bypassed.

A Subagent provides specialization, context isolation or parallel execution.

A Tool performs an external capability.

An MCP server exposes governed context and capabilities.

A workflow or orchestrator manages sequencing, state, recovery or coordination.

A test provides evidence.

These are architectural mechanisms, not competing philosophies.

Use the smallest correct mechanism for the job.

Context May Matter More Than the Model

Maryam’s emphasis on providing context just in time is especially important. Dumping everything into an agent’s context window is not context engineering. Her production-agent architecture advocates keeping context lean and relevant. (LinkedIn)

The goal should be:

Minimum sufficient context.

A security reviewer may not need the entire project history. A testing agent may not need every architectural discussion. An implementation agent may not need every document the company has written.

Context should function as an information contract: enough information to perform a bounded responsibility well, and no more.

“Fail Once, Encode Forever”

One of Maryam’s strongest ideas is:

Fail once, encode forever.

Repeated review comments reveal organizational knowledge.

If humans repeatedly tell AI:

“Don’t expose credentials.”
“Always validate this.”
“Use our shared library.”
“Every network request needs timeout and retry handling.”

Then those lessons should stop living only in code reviews.

Encode them as:

Tests
Rules
Hooks
Skills
Policies
Reusable capabilities

That is how individual engineering knowledge becomes institutional engineering intelligence.

Humans Should Steer, Not Babysit

Maryam’s principle that humans steer and agents execute captures the changing role of the engineer.

Steering does not mean disappearing. It means moving human expertise upward.

Instead of asking:

Is line 347 correct?

We increasingly ask:

Why was the system capable of generating that failure in the first place?

The engineer becomes less of a code typist and more of a designer of the system that produces software.

The architect establishes intent.

The organization establishes boundaries.

Agents execute.

Automated mechanisms validate.

Humans intervene where judgment genuinely matters.

Beware of “THE Way”

The danger is turning every useful pattern into a branded methodology and declaring:

THIS IS THE WAY

It probably isn’t.

Harness Engineering, Context Engineering, Agent Engineering and Intent-Driven Engineering describe different layers of a larger architecture.

Harness Engineering can provide the implementation discipline.

Context Engineering can govern information flow.

Agent Engineering can define autonomous capabilities.

MCP can expose tools and context.

Skills can preserve reusable expertise.

Hooks can enforce boundaries.

Tests and evaluations can provide evidence.

None needs to defeat the others.

The Architecture That Survives the Naming Wars

Strip away the frameworks and product names. What remains is:

Human Intent → Governed Execution → Evidence

Human Intent

Define the outcome, constraints and meaning of success.

Governed Execution

Give AI the context, capabilities, standards and boundaries required to accomplish the mission safely.

Evidence

Do not accept “the agent says it’s finished.”

Require tests, evaluations, security checks, observability, acceptance criteria, artifacts and traceability.

Proof first. Then ship.

From AI Coding to AI Software Engineering

That is why I value Maryam Miradi’s roadmap—not because the industry needs another branded methodology, but because it illustrates a broader transition.

Prompt engineering was never the destination. Neither was simply generating code faster.

We are learning how to build engineering systems around increasingly capable reasoning models.

Maryam calls an important part of that Harness Engineering. I approach the layer above it through Intent-Driven Engineering. The names may continue to change, but the underlying architecture is becoming clearer.

Tell AI what outcome matters.

Give it only the context it needs.

Provide the right capabilities.

Constrain what must be constrained.

Automate what does not require reasoning.

Capture recurring failures as reusable knowledge.

Require evidence before accepting the result.

And keep humans focused on what they do best:

steering the system rather than babysitting its output.

The goal is not to find THE framework.

The goal is to build a system that can understand intent, execute safely and prove that it worked.

References & Further Reading