Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

From Software Engineering to Intent Engineering

Software engineering is the discipline of turning requirements into working systems. It has matured over decades — from ad hoc coding to structured programming, from waterfall to agile, from monoliths to microservices. Each transition reflected a deeper understanding of what makes software succeed.

We are at another transition. The systems we are building no longer just execute code. They interpret intent, make decisions, and act autonomously. The discipline that builds these systems is not software engineering as we know it. It is something new.

Call it intent engineering.

The Shift in What We Build

In traditional software engineering, the human does the thinking and the computer does the executing. The programmer’s job is to translate a solution into a language the machine can follow. Every conditional, every loop, every data structure is an explicit instruction.

In agentic systems, the human expresses a goal and the system figures out how to achieve it. The engineer’s job shifts from writing instructions to designing the conditions under which good decisions emerge.

This is a fundamental change in the unit of work:

Software EngineeringIntent Engineering
InputRequirements specificationIntent and constraints
OutputDeterministic programAdaptive system
Design focusAlgorithms and data structuresDecision architectures
Quality measureCorrectness (does it do what the spec says?)Alignment (does it do what was meant?)
Failure modeBugs (incorrect execution)Misalignment (correct execution of wrong intent)
TestingDeterministic assertionsBehavioral evaluation
MaintenanceFix codeEvolve policies, skills, and memory

What Intent Engineers Do

An intent engineer does not primarily write code — though code is part of the work. An intent engineer designs, builds, and maintains the systems that make agentic behavior reliable.

Design the Cognitive Architecture

How should the kernel interpret requests? What decomposition strategies apply to this domain? How deep should planning go? These are architectural decisions, but they are not about databases and message queues. They are about reasoning structures.

The intent engineer decides:

  • When the system should plan vs. act directly.
  • How much autonomy each task type warrants.
  • What context is needed for reliable decision-making.
  • Where the boundaries between agents should fall.

Craft Skills and Instructions

Skills are the domain knowledge that makes an agentic system competent. Writing a good skill — one that produces consistently high-quality results — is a design discipline.

It requires:

  • Deep domain understanding (what does “good” look like in this domain?).
  • Clarity of expression (can the model follow these instructions reliably?).
  • Empirical validation (do these instructions produce better results than alternatives?).
  • Iterative refinement (where do the instructions fail, and how can they be improved?).

This is not prompt engineering in the sense of clever tricks to get a model to do something. It is systematic design of the knowledge and strategy layer that guides model behavior.

Design Governance Policies

What should the system be allowed to do? What should it never do? What should require human approval? These questions are not afterthoughts — they are primary design decisions.

The intent engineer designs:

  • Risk classification schemes for actions.
  • Autonomy levels for different contexts.
  • Escalation flows for uncertain situations.
  • Audit requirements for accountability.

Build Evaluation Frameworks

How do you know the system is working well? In traditional software, you write unit tests. In agentic systems, evaluation is harder because correct behavior is often a matter of judgment, not a boolean.

The intent engineer builds:

  • Benchmark suites that test system behavior across representative scenarios.
  • Quality rubrics that score outputs on multiple dimensions (correctness, completeness, style, safety).
  • Regression detection that catches degradation in system performance over time.
  • A/B testing frameworks that compare system variants.

Manage the Memory Lifecycle

What should the system remember? For how long? How should memories be organized, validated, and retired? The intent engineer designs the memory architecture and the processes that keep it healthy.

Skills of the Intent Engineer

Intent engineering draws from multiple existing disciplines but combines them in new ways:

From Software Engineering

  • Systems thinking: understanding component interactions and emergent behavior.
  • Interface design: defining clean boundaries between subsystems.
  • Testing discipline: systematic verification of behavior.
  • Operational awareness: building systems that can be monitored and debugged.

From Product Design

  • User empathy: understanding what operators actually need vs. what they say.
  • Interaction design: crafting how humans and systems collaborate.
  • Iterative design: building, testing, learning, refining.

From Cognitive Science

  • Mental models: understanding how the system’s reasoning works and fails.
  • Decision theory: designing environments where good decisions are likely.
  • Bias awareness: recognizing systematic reasoning failures and designing around them.

From Policy and Governance

  • Risk assessment: classifying and managing operational risk.
  • Compliance design: building systems that meet regulatory requirements by construction.
  • Accountability structures: ensuring actions can be traced and explained.

New Skills

  • Behavioral debugging: When the system produces a wrong result, diagnosing why — not in the code, but in the reasoning. Was the context wrong? Was the instruction ambiguous? Was the plan flawed? Was the governance too loose?
  • Instruction design: Writing instructions that produce reliable behavior across diverse inputs. This is harder than it sounds — natural language is ambiguous, and models are sensitive to phrasing.
  • Alignment verification: Confirming that the system’s actions match the operator’s intent, not just their words. This requires understanding what the operator meant, not just what they said.

The Intent Engineering Process

Intent engineering has its own development lifecycle:

flowchart LR
  IM[1. Intent\nModeling] --> AD[2. Architecture\nDesign]
  AD --> SD[3. Skill\nDevelopment]
  SD --> BT[4. Behavioral\nTesting]
  BT --> DM[5. Deployment &\nMonitoring]
  DM --> CR[6. Continuous\nRefinement]
  CR -.->|iterate| IM

1. Intent Modeling

Before building anything, model the intents the system must handle. What do operators ask for? What do they mean? What do they expect? What constraints are implicit?

This is the requirements phase, but the requirements are not features — they are goals, with all their ambiguity.

2. Architecture Design

Design the cognitive architecture: kernel behavior, decomposition strategies, worker types, memory structure, governance policies. This is the blueprint for decision-making, not for computation.

3. Skill Development

Build, test, and refine the skills that make the system competent in its domain. Each skill goes through cycles of design, testing, evaluation, and refinement.

4. Behavioral Testing

Test the system’s behavior across a wide range of scenarios. Not just “does it produce the right output” but “does it behave appropriately” — handling ambiguity, managing uncertainty, escalating when necessary, and staying within governance boundaries.

5. Deployment and Monitoring

Deploy the system with monitoring for behavioral quality. Track not just uptime and latency, but decision quality, alignment accuracy, and governance compliance.

6. Continuous Refinement

Use operational data to improve the system. Update skills based on failure analysis. Refine governance policies based on incident patterns. Expand memory based on recurring needs.

The Profession

Intent engineering is not a role that can be filled by a single person. It is a discipline practiced by teams that combine technical skill, domain knowledge, and design sensibility.

Today, this discipline is practiced informally — by prompt engineers, AI engineers, and product designers who are inventing the practice as they go. Tomorrow, it will be as structured as software engineering, with its own principles, patterns, certifications, and body of knowledge.

This book is one attempt to lay the foundation for that discipline.

The transition from software engineering to intent engineering is not a replacement — software engineering remains essential. It is an expansion. We are adding a new layer to the stack of how humans build useful systems. Software engineering builds the machine. Intent engineering teaches it to reason.