top of page
Search

# Why Intent-Driven Engineering Works Across Every AI Coding Tool

  • Writer: Mark Kendall
    Mark Kendall
  • 11 minutes ago
  • 5 min read

# Why Intent-Driven Engineering Works Across Every AI Coding Tool


*Claude Code, Cursor, Gemini, ChatGPT — the tools change. The underlying architecture doesn’t.*


-----


Every few months, a new AI coding tool claims the throne. Claude Code today, Cursor tomorrow, Gemini CLI or the next ChatGPT-powered agent after that. Teams building their engineering practice around a single vendor’s feature set are building on sand.


Intent-Driven Engineering (IDE) takes a different bet: the tools are interchangeable, but the *architecture* underneath good agentic systems is not. Strip away the vendor-specific command names and flags, and what’s left is a small set of principles that hold regardless of which model or CLI is running the loop. That’s the bet worth making — and it’s why an intent file written today should still be useful when the tooling underneath it has completely changed.


Below are the principles. Every one of them was pressure-tested against a specific tool’s documentation — and every one of them survived the translation.


## 1. The Agentic Loop Is Universal


Whatever the vendor, the mechanics are the same: the model produces a response that may include one or more tool requests, the host application executes those tools, and results are matched back to the request that triggered them. This is true whether the host is Claude Code, Cursor’s agent, or a ChatGPT function-calling loop. The model requests; the application executes. Design for that boundary, and the design survives a tool swap.


## 2. Goal-Oriented vs. Procedural Instructions


An instruction can define the outcome and let the agent choose the path, or it can specify the exact steps. Neither is universally correct — the right choice depends on how much autonomy the task should have. This is a prompting decision, not a tool feature. It applies whether you’re writing a Claude Code intent file or a Cursor rules file.


## 3. Delegate for a Reason, Not Because You Can


Specialization, context isolation, and parallelism are real reasons to hand work to a sub-agent or separate invocation. “Because the tool supports it” is not. Every serious multi-agent tool now offers some form of delegation — the judgment about *when* it’s worth the handoff cost is entirely portable.


## 4. Treat a Delegated Prompt as a Contract


A worker needs the goal, relevant context, scope, constraints, allowed actions, and expected output — enough to complete the task independently, not the entire history of the conversation that led up to it. This is contract design. It has nothing to do with which vendor is executing the contract.


## 5. Least Privilege for Agents


Give each agent the smallest set of capabilities that safely accomplishes its assigned goal. Every mature agentic tool now exposes some form of permission or tool restriction. The security posture — minimum sufficient access — is the same discipline whether you’re scoping Claude Code’s allowed tools or a Cursor agent’s file permissions.


## 6. Minimum Sufficient Context


Passing everything is wasteful and can introduce stale or conflicting information. Passing too little starves the worker of the evidence it needs. The right target is the smallest package that preserves the facts, constraints, and provenance the next step actually requires — a context-window discipline that applies identically no matter which model is reading that context.


## 7. The Coordinator Owns the Workflow


Decomposition, dependency ordering, tool restriction, result validation, and synthesis are coordinator responsibilities — distinct from simply assigning work. This coordinator/worker separation is standard in agentic system design generally, independent of any single product’s implementation.


## 8. Parallelism Requires Independence


Tasks with no data dependency between them can run concurrently. Tasks where one needs another’s output cannot. This is a dependency-graph question, and dependency graphs don’t care which vendor is executing the nodes.


## 9. Multiple Tool Calls, One Turn


A single model response can request several independent tool operations at once, reducing unnecessary round trips. The deciding factor is always dependency, not vendor capability — if a later call needs an earlier result, it waits for another turn.


## 10. Headless Invocation as a Pipeline Stage


Interactive use lets the agent orchestrate freely. Headless, scripted invocation — Claude Code’s `-p` flag, or the equivalent in any other CLI-capable tool — hands orchestration to an external system instead: deterministic stages, validation gates, auditability. The pattern of “agent as one controlled stage in a larger pipeline” is now common across essentially every serious coding agent with a non-interactive mode.


## 11. New Invocation Means New Context


Separate agent invocations do not automatically share prior state. If a later stage needs an earlier finding, that finding must be explicitly passed — through a file, a structured artifact, or a supported handoff mechanism. This is simply how stateless invocation works, and it’s true everywhere.


## 12. Structured Input Earns Its Keep When Machines Are Asking


Free-form prompts are fine for humans. When software or another agent constructs the request, explicit fields — goal, scope, known findings, constraints — make the boundary predictable and validate-able. This is API design applied to prompts, and API design doesn’t expire when you change vendors.


## 13. Structured Output Is an Interface, Not a Formatting Choice


When another agent, script, or pipeline stage consumes a result, a defined schema — status, findings, evidence, confidence — is what makes the handoff safe. Prose is fine for a human reader. It’s a liability for a machine consumer. This distinction is architectural, not tool-specific.


## 14. Define What “No Value” Means


Required versus optional, null versus missing versus empty — these are contract semantics. A missing required field is a failure, not a synonym for null. Get this wrong and it breaks the same way whether the producer is Claude, Gemini, or GPT.


## 15. Encode Constraints in the Schema


If a field can only take a few known values, constrain it — don’t leave the constraint as a prompt suggestion the model might ignore. Explicit types and bounded domains protect downstream code regardless of which model produced the data.


## 16. Validate Before You Trust


Malformed output — bad JSON, missing fields, invalid values — should never silently flow downstream. Recovery should be bounded: retry with feedback, mark the stage failed, or escalate, but never loop indefinitely. Generate, validate, then continue only if valid. This discipline is orthogonal to the model generating the output.


## 17. Token Economics Serve Correctness, Not the Reverse


Caching stable context and retrieving selectively from large sources both reduce cost — but never at the expense of the evidence a task actually needs. A smaller prompt that drops required context is a worse prompt, no matter how much cheaper it is. Every vendor’s pricing model rewards this discipline differently, but the discipline itself is the same.


## 18. Match the Control Plane to the Situation


Interactive development benefits from an agent that can orchestrate its own work against a durable intent artifact. Unattended automation benefits from external, deterministic control — explicit stages, approvals, gates. The intent describes the desired outcome either way; only the execution layer changes shape.


-----


## The Point


None of these eighteen principles reference a proprietary API, a specific CLI flag, or a vendor’s roadmap. They’re the architecture of agentic systems generally — the same reasoning a well-designed multi-agent pipeline needs whether it’s built on Claude Code, Cursor, Gemini, or ChatGPT’s function-calling loop.


That’s precisely why Intent-Driven Engineering is built around the *intent file*, not around any single tool’s syntax. The intent file captures outcome, scope, constraints, and success criteria — the durable part. The tool underneath compiles that intent into execution, whatever shape that execution takes this year.


Tools will keep changing. The engineering discipline underneath them doesn’t have to.

 
 
 

Recent Posts

See All

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
Post: Blog2_Post

Subscribe Form

Thanks for submitting!

©2020 by LearnTeachMaster DevOps. Proudly created with Wix.com

bottom of page