# AI-Native Software Engineering — the O'Reilly Media book > What the book covers, chapter by chapter: who it is for, what you will learn, and where to read it. - **Source:** https://ainativesoftware.engineering/book - **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book ## The short version AI-Native Software Engineering is a book about building production software with AI agents. It is published by O'Reilly Media, written by Alfonso Graziano, and it is out now in Early Release, with the print edition in February 2027. - **Author:** Alfonso Graziano, AI Lead at Nearform - **Publisher:** O'Reilly Media · Early Release - **Print edition:** February 2027 - **Size:** 11 chapters, 359 sections, about 134,876 words, 37 figures, roughly 10 hours of reading - **Read it:** [On the O'Reilly learning platform](https://www.oreilly.com/library/view/ai-native-software-engineering/0642572352530/) - **Free access:** [30 days of the platform, free](https://learning.oreilly.com/get-learning/?code=ANSE2026) with the code `ANSE2026` - **Contents:** [Every chapter and section](https://ainativesoftware.engineering/book/toc.md) ## What the book argues Vibe coding — describing what you want and accepting whatever comes back — works for prototypes and fails in production. The alternative is not writing every line yourself again. It is treating AI as part of the system you engineer: explicit context, specs written before prompts, tools the agent can reach, gates that check its output, and team practices that make any of it repeatable. ## The pillars it is built on ### Context engineering (Chapter 3) Assemble the right code, docs, rules and examples at the right time, so the agent produces consistent output instead of occasional lucky output. ### Spec-driven development (Chapter 5) Write intent down before you prompt. The spec is the durable artifact that survives every tool change and model upgrade. ### Harness engineering (Chapter 10) Build the environment around the agent: rules, skills, tests, feedback loops. Agent equals model plus harness, and the harness is yours. ### Verification and gates (Chapter 8) Once code is cheap, trust is the bottleneck. Four layers of checks let AI-written code meet the same bar as anything else you ship. ### Agent orchestration (Chapter 9) Know when one agent is enough and when to run a fleet, and stop hallucinations from propagating through a pipeline. ### Scaling in teams (Chapter 10) Licences change nothing. Shared context, standard stacks and honest metrics are what move a team, not a purchase order. ## What you will learn - Adopt the AI-native mindset, from implementer to orchestrator - Master context engineering for consistent, production-ready output - Navigate the AI tool landscape with criteria instead of hype - Apply spec-driven development as a practice that survives tool changes - Orchestrate single and multi-agent systems without the usual anti-patterns - Integrate verification and quality gates so AI code ships with confidence - Collaborate across functions using specs, acceptance criteria and constraints - Scale AI practices from IC to team to organisation ## Who it is for - You are a mid-level to staff engineer shipping and maintaining production systems. - AI has made it into your editor but not into your workflow. - You use a coding assistant daily and suspect you are using it badly. - You lead a team and licences alone have not moved a single metric. - You want practices that outlive the tool you happen to use this quarter. ### Who it is not for - You want to build AI applications, models or RAG pipelines. That is a different book. - You are looking for prompt templates to copy and paste. - You have never shipped production code. The book assumes solid fundamentals. - You want a tool tutorial tied to one vendor. ### What it assumes - A few years of experience building and shipping production code - Comfort with any mainstream language and a real codebase - Familiarity with Agile-style delivery and working in a team - No ML or AI research background at all ## The chapters ### Chapter 1: The AI-Native Engineer The shift from implementer to orchestrator, the vibe-coding trap, and what makes an engineer irreplaceable. This chapter sets the mindset the rest of the book builds on. It names the three ways vibe coding fails in production, then replaces it with a structured practice built on intent, constraints, and verification. Getting this part right decides whether AI multiplies your effectiveness or just accelerates your mistakes. **Key takeaways** - Vibe coding works for prototypes and fails for production. - The engineer's role is shifting from primary implementer to orchestrator. - AI-native engineering is a structured approach, not a set of tool recommendations. - The traditional workflow no longer scales when implementation isn't the bottleneck. - Intent, constraints, and verification form the new center of gravity. - Human-in-the-loop is a design principle, not a constraint. - The new skill stack describes judgment that compounds with experience. - AI replaces tasks, not purpose. - **Words:** 10,615 - **Figures:** Fig1-1, Fig1-2 ### Chapter 2: From LLMs to Agents How LLMs work from an engineer's-eye view, why they are good at code, and how tools, context, and a loop turn a model into an agent. A working mental model of the machine you are about to direct. Tokens, attention, the context window as a working-memory budget, why training against tests makes models good at code, and then the small step from model to agent: an LLM, tools, context, and a loop. You build one in 50 lines. **Key takeaways** - An LLM predicts the next token. Every behaviour you see is downstream of that. - The context window is a finite, unevenly attended working-memory budget. - In-weights knowledge is frozen and can be wrong; in-context knowledge is authoritative because you control it. - LLMs are good at code because code is structured, well represented, and verifiable. - Nondeterminism is a property, not a bug. Answer it with acceptance criteria and tests. - An agent is an LLM plus tools, context, and a loop. Under the frameworks, it is a while loop. - Tool quality and stopping conditions are the two most underrated design concerns. - The durable artifacts are your specs, rules, and integrations. The assistant on top is interchangeable. - **Words:** 14,673 - **Figures:** Fig2-1, Fig2-2, Fig2-3 ### Chapter 3: Context Engineering Fundamentals Moving from prompt engineering to assembling the right context at the right time, so AI tools produce consistent outputs, not lucky ones. Context engineering is the discipline underneath everything else in the book. This chapter gives you a taxonomy of what goes into a context window, how agents discover context on their own, and how to keep a long session from rotting. **Key takeaways** - Context is everything the model receives, not just your prompt. - The context window is finite and models don't process it uniformly. - Context rot accumulates across long sessions. - The only mandatory context component is the user's query. Everything else is a choice. - Context engineering has two failure modes: too little focus, and too much distraction. - **Words:** 10,010 - **Figures:** Fig3-1, Fig3-2 ### Chapter 4: Model Context Protocol What MCP is and why it matters, its client/server/transport architecture, and how to operate MCP servers safely. One protocol connects any compliant AI tool to any compliant service. This chapter covers the architecture, the real cost of every connected server, the security model with actual incidents, how to debug it when it breaks, and when a plain CLI script or a skill is the better answer. **Key takeaways** - MCP defines a single integration interface between any compliant AI tool and any compliant service. - The highest-value servers connect to the tools you already use heavily. - Every connected server costs you tokens and quality. - Security is not optional when agents can take real-world actions. - Too many tools degrade performance. Match active servers to the task at hand. - Not every integration needs MCP. Skills and CLI tools handle most needs. - As tool counts scale, three patterns help: tool search, programmatic tool calling, and tool-use examples. - **Words:** 11,307 - **Figures:** Fig4-1, Fig4-2 ### Chapter 5: Spec-Driven Development Why specs are the durable artifact that keeps AI-generated code aligned with intent, and how you already write them without realising it. Agents do not ask for clarification. They resolve ambiguity from training data instead of from your system's constraints, and they do it fast enough that misalignment compounds. This chapter makes the case for writing intent down first, and shows the three levels of SDD maturity. **Key takeaways** - Agents don't ask for clarification. They resolve ambiguity using training data patterns. - You already write specs: PRDs, ADRs, RFCs, user stories. - Writing a spec is a discovery process, not a documentation exercise. - Specs are durable artifacts that survive tool changes. - SDD makes human oversight practical at scale. - Not every task needs a spec. - Plan Mode is the accessible first step toward SDD. - **Words:** 9,483 - **Figures:** Fig5-1, Fig5-2, Fig5-3, Fig5-4 ### Chapter 6: The SDD Workflow The canonical loop — Specify, Plan, Execute, Verify, Integrate, Learn — and exactly where humans must stay in it. The longest chapter in the book, and the most operational. Every phase of the loop, the artifacts each one produces, the prompts that drive them, and what to do when the codebase you are speccing was never specified in the first place. **Key takeaways** - The SDD loop is a six-phase cycle with durable artifacts at every stage. - Human oversight sits at the seams between phases, not deep inside any single phase. - Verification is hard rails, not advisory. - The spec lifecycle is a deliberate choice, not a default. - In brownfield projects, SDD begins with Spec Islands, not retroactive documentation of everything. - The quality of the acceptance criteria decides the quality of every downstream phase. - **Words:** 14,746 - **Figures:** Fig6-1, Fig6-2, Fig6-3, Fig6-4 ### Chapter 7: SDD Frameworks Compared Why frameworks exist and how to choose between them — or when no framework is the right answer. Spec Kit, OpenSpec, BMAD, Kiro, and Agent Skills, placed on a ceremony spectrum and compared on the things that actually decide the choice. Plus the operational questions every team asks once SDD hits production. **Key takeaways** - Spec Kit is the middle-ground option. - OpenSpec is the light option. - BMAD is the heavy option. - The rest of the landscape fills in around these three. - The choice comes down to a small number of questions about your team. - The operational questions are framework-agnostic. - **Words:** 9,467 - **Figures:** Fig7-1, Fig7-2 ### Chapter 8: Verification and Quality Gates Where the bottleneck moves once coding is cheap, and the four layers that let AI-generated code meet the same bar as human-written code. The biggest chapter in the book. Twenty-one deterministic gates, then LLM review for the judgment calls, then deployment strategies as a safety layer, then runtime and AI-powered ops. It ends with the trust ladder: how authority gets earned one reversible step at a time. **Key takeaways** - The bottleneck has moved from writing code to trusting it. - Verification is a stack of four automated layers, with a human directing the whole thing. - Deterministic gates are the floor, and they should run on everything first. - LLM review covers the judgment calls deterministic checks can't make. - After merge, the deployment itself becomes a safety layer. - Observability is the price of admission for AIOps, and the loop closes back to the start. - Two simple mechanisms decide when a human is pulled in: a path gate, then a risk scorer. - **Words:** 20,557 - **Figures:** Fig8-1, Fig8-2, Fig8-3, Fig8-4, Fig8-5, Fig8-6, Fig8-7 ### Chapter 9: Agent Orchestration Patterns Scaling one agent with compaction and scratchpads, then coordinating many agents while avoiding cascading failures. Generator-critic loops, the goal pattern, the Ralph loop, git worktrees, subagent arrangements, orchestration as code, and the dark factory at the end of it. The chapter closes with the honest limit: your attention, not your tooling. **Key takeaways** - One agent goes further with a scratchpad you control than with compaction you cannot see. - SDD is itself an orchestration pattern: the spec is the shared coordination artifact. - A generator and a separate critic catch more than one agent reviewing itself. - Isolation comes in three levels: context windows, worktrees, and separate machines. - The same subagent building block arranges four ways: orchestrator-worker, pipeline, fan-out/fan-in, router. - Tools change faster than the thinking behind them, so the patterns are what to learn. - Your brain is the real limit. Find your number of parallel streams and treat it as the cap. - **Words:** 12,138 - **Figures:** Fig9-1, Fig9-2, Fig9-3, Fig9-4, Fig9-5, Fig9-6 ### Chapter 10: Scaling AI-Native Engineering in Teams Why buying licences changes nothing, what actually shifts when a team goes AI-native, and how to scale without burning out your best people. A CTO whose bill went up and whose velocity did not. This chapter is about the part no tool fixes: shared context, standardised stacks, rational resistance, the new shape of the team, and metrics that measure capability instead of activity. The canvas comes from here. **Key takeaways** - Scaling AI-native engineering is a people-and-standards problem, not a tooling problem. - Individual gains do not add up to team gains on their own. - Use the AI-Native Team Canvas to design how your team adopts AI. - Treat resistance as rational and answer it with a better definition of the job. - Standardise the stack and sanction experimentation. - The harness is the real deliverable, and it compounds. - The team's shape changes: smaller, tighter, with product and design closer to the code. - Measure real capabilities, not vanity metrics. - **Words:** 10,638 - **Figures:** Fig10-1, Fig10-2, Fig10-3, Fig10-4 ### Chapter 11: AI-Native in Practice at Cogwheel Nine weeks at Cogwheel: one team applies every practice in the book to ship the bet the company was too slow to ship. The whole book, applied. The team from the foreword takes a greenfield service inside a brownfield world from a PRD to production in nine weeks: canvas, harness, specs, stories, quality gates, a fleet of agents, and honest measurement. **Key takeaways** - Week 1 is everything except the feature: a PRD, the canvas, and the harness. - Prototype in code, not in pictures. - One pull request, watched end to end, is the clearest picture of the loop in motion. - A fleet beats a hero, and making it the team's way is the actual work. - Measure honestly, including the things that got worse. - **Words:** 11,242 - **Figures:** Fig11-1 ## Questions people ask ### What will I learn from this book? How to build production software with AI systems using the core pillars of AI-native engineering: avoiding the vibe-coding trap, context engineering, spec-driven development, MCP tooling, agent orchestration, and verification gates. Every chapter has concrete patterns, real code, and team playbooks. ### Who is this book for? Software engineers, tech leads, and engineering managers who already use AI coding assistants but want to move past ad-hoc usage into repeatable, production-grade practice. ### Do I need prior AI or ML experience? No. The book assumes solid software engineering fundamentals and treats AI-native engineering as a discipline of software delivery, not as an ML research topic. ### Which AI tools does the book cover? The focus is on patterns that outlive any single tool. Claude Code, Cursor, Copilot, Codex, Windsurf, Aider and whatever ships next all fit the practice. Specific tools appear as examples, never as requirements. ### How is AI-native engineering different from vibe coding? Vibe coding is ad-hoc AI usage that produces plausible code which fails in production. AI-native engineering is the disciplined alternative: explicit context, clear specs, verification gates, and team practices that ship reliable software. ### Is this just prompt engineering with a new name? No. Prompt engineering optimises one input for one output. AI-native engineering designs the whole system around the agent: the spec you write before the prompt, the rules that load every session, the tools that give the agent live context, the gates that check its output, and the team practices that make any of it repeatable. ### Can I read it now? Yes. The Early Release is on the O'Reilly learning platform, and chapters land as they are written. The code ANSE2026 gives you 30 days of free access to the platform. ### Is there anything free? Plenty. The 7-day roadmap, the 8-area team canvas as a printable PDF, and the 25-question maturity assessment are all free and need no email address. ### When is the full book out? The print edition is out in February 2027. You do not have to wait for it: the Early Release is already on the O'Reilly platform, and chapters are published there as they are finished. Subscribing to the newsletter is the fastest way to know when a new one lands. ## Free companion material - [The 7-day roadmap](https://ainativesoftware.engineering/roadmap.md) — a free path from AI user to AI-native engineer. - [The AI-Native Engineering Canvas](https://ainativesoftware.engineering/canvas.md) — an 8-area team workshop template, also a [printable PDF](https://ainativesoftware.engineering/aine-canvas.pdf). - [The maturity assessment](https://ainativesoftware.engineering/assessment.md) — 29 questions and a score out of 100. - [The pillars of AI-native engineering](https://ainativesoftware.engineering/pillars.md) — long-form essays on the foundations. --- _AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._