Agentic Software Engineering (Hassan)

Ahmed E. Hassan's 2026 book: a comprehensive engineering discipline for building trustworthy software with stochastic AI teammates at unprecedented scale. Not a prompt guide — a full-stack rethinking of the SE system across four pillars (actors, process, artifacts, tools) for the agentic era. The best single-volume treatment of what software engineering becomes when code generation is no longer the bottleneck.

The Core Argument

The book's thesis, stated plainly in the Preface: "Agentic Software Engineering is the discipline of producing high-quality, reliable, trustworthy software from stochastic contributors, both AI and human, by making the full SE system ready: people, process, tools, and artifacts. It is not about finding perfect agents. It is about engineering trusted reliability on top of components that can fail with some probability, using the right constraints and evidence."

The central metaphor is Cypher eating steak in The Matrix — the industry chooses the comforting illusion of deterministic control rather than confronting the probabilistic reality of AI teammates. The book's refrain: "Stop eating the steak."

"A fool with a tool is still a fool."

This line appears throughout the book and captures Hassan's thesis that agentic coding harnesses aren't magic wands — they accelerate whatever your engineering system was already bad at. The book is the manual that didn't come with Claude Code.

SE 1.0 → SE 2.0 → SE 3.0

Hassan's evolutionary model reframes the common discourse:

• SE 1.0: Humans drive every loop. Throughput bounded by hands and attention.
• SE 2.0: AI copilots help typing and searching, but humans remain in the micro-loop as the primary safety mechanism. Cognitive load stays on the developer.
• SE 3.0: AI teammates plan, execute, branch, and produce finished work at machine speed. Output explodes, human attention becomes the scarce resource, and the entire engineering system must change.

The critical insight: agentic coding harnesses appear in your system as tools, but operate as actors. A tool rollout without actor onboarding (autonomy boundaries, evidence standards, escalation paths) produces faster disasters.

"If you treat an actor like a tool, you build the wrong controls."

The Four Paradoxes

Chapter 3 identifies four universal paradoxes that make AI teammates simultaneously valuable and challenging:

1. The Eagerness Paradox: AI always has an answer, even when it shouldn't. This turns a speed advantage into dangerous confidence.
2. The Context Paradox: AI needs rich context to perform well, but too much context degrades performance — the context window is not RAM, it's working memory with nonlinear degradation.
3. The Tunnel Vision Paradox: AI focuses narrowly on the immediate task and loses awareness of cross-cutting concerns, dependencies, and architectural invariants.
4. The Learning Paradox: AI learns quickly within a session but starts each session fresh — "the junior developer who never learns" despite vast encoded knowledge.

These paradoxes aren't bugs to fix but properties to engineer around. The book's entire assurance and platform engineering frameworks exist to manage them.

The Six Coordination Artifacts

Chapter 1 introduces structured artifacts as "a new engineering layer, not personal macros." These replace chat and hope with durable interfaces:

"Artifacts are the interface" — the coordination layer between humans and AI teammates, not personal macros that rot in someone's dotfiles.

Trustworthiness as Code

Hassan's key implementation principle: "Deterministic enforcement, not probabilistic instruction." This echoes throughout the wiki — it's the same thesis as claude-ctrl, Feedback Loop is All You Need, and Pre-Commit Lint Checks.

"Trust requires enforcement. An instruction in context is not a constraint — it's a suggestion that a stochastic actor may or may not follow."

The book goes further than most by structuring enforcement into four disciplines:

The Four Trust Disciplines

Chapter 9 (Trust Engineering) names four distinct engineering problems that are often conflated:

1. Delegation Engineering (upstream): What autonomy envelope, under what conditions, for what tasks? Risk tiering, least privilege, tool access boundaries.
2. Safety Engineering (runtime): What happens when something goes wrong? Prevention, detection, circuit breakers, automatic rollback.
3. Accountability Engineering (retrospective): Can we reconstruct what occurred? Three BOMs (SBOM, BBOM, DBOM), frozen audit trails, provenance bundles.
4. Compliance Engineering (verification): Did what was supposed to happen actually happen? Independent verification, spot-checks, closing the gap between self-reporting and reality.

"Trust that is built solely on self-reporting is not trust engineering; it is hope."

The McDonald's Insight

The most vivid metaphor in the book: McDonald's food safety as layered verification for stochastic actors. Some controls are deterministic and cannot be bypassed (grill thermostat). Some are assistive (cooking timers). Some rely entirely on behavioral compliance (hand washing). But critically, McDonald's adds a verification layer — health inspectors, spot checks — that catches what the other layers miss.

For agentic SE: CI pipelines are grill thermostats. System prompts are hand-washing expectations. Compliance verification is the health inspector.

The Three BOMs

• SBOM (Software BOM): What shipped — dependencies, versions, vulnerability surface.
• BBOM (Build BOM): How it was built — toolchains, environment, reproducibility.
• DBOM (Decision BOM): How it was decided — which Teammate Definition ran, which policies were in force, what autonomy envelope applied, which escalations happened. The DBOM is the agentic record. Without it, postmortems collapse into "we think the AI teammate did X."

The Ferrari and the Donkey

"Your AI teammates will make mistakes; but so does 100% of your development team today. The difference is like choosing between a Ferrari and a donkey. The Ferrari is powerful and fast, but yes, a tiny steering mistake at that speed can cause huge damage. The donkey is slow and steady, predictable and safe. Most organizations will choose the donkey because they're comparing the Ferrari to some perfect vehicle that never existed."

This is the book's closing argument: the winning organizations won't be those waiting for deterministic agents — they'll be those who build deterministic evidence from probabilistic work.

Two Modalities, Two Workbenches

Chapter 7 introduces a design principle that should influence every agent tool:

• SE4Humans: Optimized for review, debugging, auditing, and long-term comprehension. A command center where humans see patterns and make decisions.
• SE4Agents: Optimized for execution throughput, tool orchestration, and evidence generation. An execution environment with clear boundaries and fast feedback.

"Mix these two workbenches and you get chat-driven chaos instead of engineering-grade reliability."

This is why "chat as IDE" is an anti-pattern.

The Reversible World

One of the book's sharpest insights: software development is a remarkably reversible world (Git history, container rebuilds, IaC redeployment), and this fundamentally changes the delegation calculus. When mistakes are bounded and recovery paths are well-defined, the optimal delegation posture shifts toward greater autonomy.

"The question changes from 'Can I trust this teammate not to make mistakes?' to 'Can I trust my review and rollback infrastructure to catch and recover from mistakes?'"

Code Becomes the New Binary

Chapter 10's thesis: when AI writes most code, reading becomes the bottleneck, not writing. The economics invert — cheap production, expensive comprehension. Hassan argues programming language choice becomes a governance decision, not a developer preference, because safety-by-construction and static analysis become the primary trust mechanisms.

"Until semantic review matures, syntax still matters because it is what humans actually see."

The endpoint: code becomes the new binary, and meaning moves up a layer to specifications, constraints, and policies — echoing Specifications as the Product.

Critical Analysis

What this book gets right:

The four-part structure (foundations → assurance → platform → roadmap) is genuinely engineering in its rigor. Hassan doesn't just name problems — he provides practices, patterns, anti-patterns, and metrics for each one. This is a playbook, not a polemic, and it's the most comprehensive treatment of agentic SE as an engineering discipline I've encountered.

The actor-not-tool reframe is the book's most important contribution. It explains why naive Claude Code adoption fails: organizations do tool rollouts when they need actor onboarding. This connects directly to the wiki's Agent Coding Workflow maturity spectrum and the How Intercom Uses Claude Code case study — Intercom succeeded because they built the system around the actors, not just the tool.

The McDonald's layered verification metaphor is worth the price of admission alone. It gives concrete engineering intuition for what most people call "trust but verify" without understanding the layers involved.

The four trust disciplines (Delegation, Safety, Accountability, Compliance) resolve a confusion that pervades agent safety discourse. Most teams collapse these into one bucket called "security" and call it done.

What the book misses or underplays:

Hassan explicitly frames this as a book for leaders, not practitioners, and it shows. There are no code examples, no configuration snippets, no walkthroughs of actual harness configuration. The artifacts are described in structural detail (tables, sections, fields) but there's no worked example showing a real Mission Brief. This is a spec for a system, not an implementation guide.

The book mentions model capabilities evolving rapidly but doesn't engage deeply with the trajectory question: how much of this engineering discipline is permanent vs. a bridge to better models? If models improve enough to handle context, paradoxes, and intent alignment natively, how much of the platform engineering layer collapses? Hassan's answer is implicit — the discipline is permanent, only the implementations change — but the argument deserves more engagement.

The personas in Part IV feel thin compared to the engineering chapters. The "for business leaders" section in particular reads like a consulting engagement pitch.

The book's "SE 1.0 → 2.0 → 3.0" model is clean but undersells the continuity. Most organizations will operate in all three modes simultaneously for years — a legacy monolith (SE 1.0), a Next.js app with Copilot (SE 2.0), and an agent-built microservice (SE 3.0). The book acknowledges this but doesn't help leaders manage the mixed-mode reality.

Hassan is also a co-author on Don't Trust the Label — License Laundering in AI Supply Chains, which operationalizes the book's thesis about evidence and trust in stochastic supply chains: tracing 232,270 dataset→model→application chains reveals that 62.3% pass through unlicensed artifacts and every obligation-bearing license category collapses below 7% end-to-end survival. The paper is the empirical measurement the book's framework was built to interpret.

Where this sits in the wiki:

This is the closest thing to a canonical text on agentic software engineering as a discipline. It synthesizes and formalizes themes that appear across dozens of wiki pages: Specifications as the Product, Compound Engineering, Guardrails and Feedback Loops, Harness Engineering, Agent Coding Workflow, Cognitive Debt, Write Only Code, Slowing the Fuck Down, Agent Orchestration, Security and Sandboxing.

If the wiki has a spine, this book names it: the discipline that stands between humanity and confidently-produced nonsense.

Sources: Agentic Software Engineering: Building Trustworthy Software with Stochastic Teammates at Unprecedented Scale Last updated: 2026-05-14