book

AI-Native Software Engineering

Name: AI-Native Software Engineering
Author: Alfonso Graziano
ISBN: 9798341674738

by Alfonso Graziano

February 2027

Intermediate

300 pages

9h 40m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Brief Table of Contents (Not Yet Final)
1. The AI-Native Engineer
The Vibe-Coding TrapTwo Engineers, One TaskWhat AI-Native Engineering Is NotThe Role Transformation: From Implementer to OrchestratorWhy the Traditional Workflow No Longer ScalesThe New Center of Gravity: Intent, Constraints, and VerificationIntentConstraintsVerificationHuman-in-the-Loop: The Nonnegotiable CheckpointWhat AI-Native Engineers Actually DoBefore the workDuring the workThroughoutThe New Skill Stack: Eight Skills That Make You IrreplaceableThe Cost of Not AdaptingCareer Implications: Why Software Engineering is Becoming a Leadership RoleStarting Out: How Junior Engineers Grow When AI Writes the BasicsSummary
2. From LLMs to Agents
How LLMs Work: An Engineer’s-Eye ViewTokensThe Transformer and AttentionIn-weights knowledge versus in-context knowledgeThe context window is your working-memory budgetWhy LLMs Are Good at CodeTraining with verifiable outcomes: RLHF and RLVRChain-of-thought and reasoning modelsNondeterminism, Temperature, and SamplingThe Model LandscapeOpen source versus closed sourceSmall language modelsMultimodal modelsEmbeddings and semantic searchWhere LLMs Excel and Where They FailBenchmarks: What They Do and Don’t MeasureThe API Layer: How Engineers Talk to LLMsWhat Makes an Agent: LLM, Tools, Context, LoopThe LLM: The reasoning coreTools: How agents act on the worldContext: Accumulated stateThe agentic loop: Reason, act, observe, adjustBeyond single agentsBuilding an Agent in 50 Lines of CodeStopping conditions and iteration limitsAgent frameworksWhy this matters for users of coding agentsThe Agent Execution Model: Reason, Act, ObserveThe self-correction loop: Tests as observationsTool Use and Function CallingHow function calling works under the hoodMemory and StateIn-context memoryLong-term memory through filesRetrieved memory with RAGAgent-generated memoryContext rotAgent Economics: Cost, Latency, and ScopeHuman-in-the-LoopHITL as a design principleThe agent decides when it needs youCalibrating HITL to riskThe AI Tool LandscapeIDE-integrated coding assistantsCLI and terminal-native agentsCloud and background agentsCode review assistantsDesign and UI generation toolsChoosing tools without chasing hypeSummary
3. Context Engineering Fundamentals
From Prompt Engineering to Context EngineeringThe Core Problem: Right Context, Right Time, Limited WindowThe Attention ProblemThe Lost-in-the-Middle PhenomenonContext RotThe Human Working-Memory ParallelThe Right-Time ProblemThe Two Failure ModesMandatory and Optional Context ComponentsA Taxonomy of Context ComponentsSystem PromptsUser Input and User-Provided ContextRules, Style Guides, and ConstraintsSkillsToolsCustom AgentsEnvironment Context: Runtime and MetadataConversation History and Memory ManagementThe Context Assembly ProcessAutonomous Context Discovery: How Agents Explore Before They WriteCode Indexing and Semantic SearchCLI-Based ExplorationLanguage Servers and Symbolic Code UnderstandingWhat Autonomous Discovery Does and Doesn’t ReplaceThe Agent Runtime Pipeline: From Request to ActionContext Assembly, Planning, and Tool ExecutionThe Iterative Loop: Reason, Act, Observe, AdjustThe Golden Balance: Too Little Focus, Too Much DistractionAvoiding Context RotSession ManagementToken Efficiency for Large PayloadsSummary
4. Model Context Protocol
What MCP Is and Why It MattersWhat MCP actually doesWhy the MCP standard matters for engineersThe MCP Architecture: Clients, Servers, and TransportsHosts, clients, and serversTransportsLocal servers versus remote serversHow it connects in your daily workflowThe MCP EcosystemConfiguring a server: a typical exampleThe Economics of MCPWhat you pay for in an MCP sessionControlling tool output sizeMCP Security ModelThreatsWhat Real Incidents Teach Us About MCP SecurityMCP Security Best PracticesFour Security PrinciplesOperating MCP in ProductionMCP Approved RegistryDebugging MCPThe server won’t startThe server connects but shows no toolsThe agent doesn’t use the tool you expectA tool call fails with an errorReading tool-call logsMCP and Context PollutionWhy Too Many MCP Servers Degrade PerformanceAgent-Specific MCP Server ConfigurationBuilding Your Own MCP ServerWhen to build rather than useHow hard is it?Writing good tool descriptionsMCP in Agentic PipelinesWhat changes when there’s no human in the loopPractical use cases for MCP in pipelinesThe reliability constraintSkills and CLI Scripts: When You Don’t Need an MCP ServerThe patternSkills that reference project scriptsThe CLI-first movementWhen to use skills and CLI tools versus MCPAdvanced Tool Use: Scaling Beyond Static Tool ListsThe three bottlenecksTool search: Dynamic discovery instead of static loadingProgrammatic tool calling: Code as orchestrationTool-use examples: Teaching by showingMatching the solution to the bottleneckWhere the industry is headingSummary
5. Spec-Driven Development
The Root Problem: Why Do We Need SDD?Garbage In, Garbage Out: At ScaleThe Compounding ProblemThe Human ParallelYou Already Write SpecsWhen These Documents Are MissingThe Case for Spec-Driven DevelopmentThe Power of Learning by Writing a SpecUncovering Unclear Requirements with a SpecThe Economics of Writing SpecsWhen SDD Is Not the Right FitSpecs as Durable Artifacts That Survive Tool ChangesSpecs and Organizational KnowledgeSDD and Human-in-the-LoopWhy Engineers Resist Writing SpecsPlan Mode: The Bridge Between Vibe Coding and SDDPlan Mode in PracticePlan Mode and Spec-Driven DevelopmentThree Levels of SDD Maturity1. Spec-First: Writing Specs Before Implementation2. Spec-Anchored: Keeping Specs During Evolution3. Spec-as-Source: The Spec as Primary ArtifactWhat Good Specs Look LikeSummary
6. The SDD Workflow
The Canonical Loop: Specify, Plan, Execute, Verify, Integrate, LearnWhere Humans Must Stay in the LoopStop Conditions and Escalation RulesBefore the Loop: When You Need a Prototype FirstThe Throwaway Branch PatternScratch Repo PrototypesA Concrete ExampleConsolidating Learnings into the SpecWhen to Skip the PrototypeThe Core Artifact Setspec.md: Intent, Constraints, Acceptance Criteriaplan.md: Approach, Trade-Offs, Sequencingtasks.md: Atomic Tasks with Done ChecksOptional Artifacts: risks.md, rollback.md, adr.mdFrom Idea to Spec: Turning Intent into a DocumentFrom Spec to Plan: Turning Intent into ActionFrom Plan to Tasks: Decomposition and Dependency ManagementExecution Patterns and PromptsVerification as Hard Rails: CI Gates That Make Output ShippableIntegration and DeploymentLearning and Iteration: Closing the LoopThe Spec Lifecycle: What Happens After Implementation?The Two-Tier Model: What Works in PracticeThe Learning Phase as the BridgeSDD in Brownfield ProjectsThe Core Challenge: Specs for Code That Was Never SpecifiedStarting Small: The Spec Island StrategyReverse-Engineering Intent with AI AssistanceHandling Undocumented Behavior and Implicit ContractsPrioritizing What Gets Specified FirstSummary
7. SDD Frameworks Compared
Why Frameworks Exist: Structure, Consistency, Team AlignmentGitHub Spec KitOpenSpecBMAD MethodRoles, Personas, and Guided WorkflowsBMAD in PracticeBMAD in Brownfield ProjectsCustom Workflows, Custom Agents, and Adapting BMAD for Your Use CaseOther Tools Worth KnowingKiroAgent SkillsChoosing the Right FrameworkFrequently Asked Questions on Using SDD in ProductionSummary
8. Verification and Quality Gates
The Bottleneck MovesWhy Manual Review Doesn’t ScaleWhat This Chapter PromisesThe Two Big QuestionsHarness Validations and Self-Check LoopsBefore Merge, Layer 1: Deterministic GuardrailsLinting and Formatting as a BaselineDead Code and Unused DependenciesType Checks and CompilationThe Test SuiteMutation Testing as a Test Quality GateProperty-Based Testing for InvariantsStatic Application Security Testing (SAST)Dependency and Container ScanningSecrets ScanningInfrastructure as Code ScanningSupply-Chain IntegrityArchitecture Fitness FunctionsPerformance and Bundle BudgetsQuery and Data-Access PerformanceDependency UpdatesContract Gates: API and Schema BreakageAccessibility and InternationalizationPull-Request Size and Scope DisciplineBefore Merge, Layer 2: LLM-Based ReviewWhy Deterministic Checks Are Not EnoughAdversarial Review Before the PRHow an LLM Reviewer WorksTwo Ways to Organize the ReviewWhat to Look ForTuning the Reviewer to Your CodebaseAfter Merge, Layer 3: Safe Deployment StrategiesFeature Flags as the DefaultBlue-Green DeploymentsCanary DeploymentsShadow Traffic and Dark LaunchesProgressive Delivery by User SegmentAutomated Rollback on Error Budget BurnChoosing StrategiesData SafetyAfter Merge, Layer 4: Runtime Safety and AI-Powered OpsThe Three Pillars, BrieflyOpenTelemetry as the Common SubstrateSLOs and Error BudgetsReducing Alert FatigueWhere AI Changes the GameAI Anomaly Detection on Metrics and LogsPost-Deploy Observability AnalysisAI-Driven Root-Cause AnalysisThe Bug-Resolution PipelineClosing the Loop Back to the Coding AgentSynthetic Monitoring and Chaos EngineeringAfter Merge, Layer 5: The Human in the LoopTwo Mechanisms to Decide What Needs a HumanThe Deterministic Gate: Changes That Always Need a HumanThe AI Risk ScorerHow Human Review Is ChangingReviewing the ReviewerPutting It TogetherA Reference Pipeline, End to EndWhat to Adopt FirstMetrics for the System ItselfFailure ModesThe Trust LadderFurther readingSummary
9. Agent Orchestration Patterns
Why Software Engineers Need to Understand Agent Orchestration PatternsWhy Using a Single Agent Doesn’t ScaleThe Tradeoffs of Orchestrating Multiple AgentsOne Agent, Bigger Jobs: Compaction and ScratchpadsCompaction: The Automatic Fix That Gets MessyScratchpads: Memory in a File You ControlSDD as an Orchestration PatternUsing Different Models in Different SDD PhasesThe Generator-Critic LoopWorked Example: Adversarial Code ReviewThe Goal Pattern: Looping Until the Goal Is MetThe Ralph LoopHow It WorksWhat Makes It Work, and What Keeps It SafeToolsRunning Multiple Agents in Parallel on the Same CodebaseContext-Window IsolationGit WorktreesIsolated Cloud VMsThe Subagent PatternWays to Arrange WorkThe Advisor: A Stronger Model for the Hard PartsWorkflows: Orchestration as CodeA Fixed Script: Letting the Agent DecideThe Dark Factory: Where This Is All GoingTwo Modes of WorkingFinal Considerations

10. Scaling AI-Native Engineering in Teams
Why Scaling to the Team Level Is a Different ProblemThe Bottleneck Moves, It Doesn’t DisappearNew Failure Modes That Only Show Up at Team ScaleAI Is a Mirror and a MultiplierThe AI-Native Team Canvas: Design How Your Team Adopts AIA Business Model Canvas, but for AI AdoptionHow to Run ItThe Eight BoxesSkill Gaps and System GapsUsage Is Not ReadinessResistance Is Rational: Why Engineers Push BackThe Three Objections You Will HearReframing the CraftWhat This Means for LeadersStandardize the Team StackStandardize What MattersThe Shared Context Is the Real StackThe Harness Gets Better Over TimeSomeone Has to Own ItLeave Room to ExperimentHow an AI-Native Team WorksPair on the Agent, Not Just the CodeWrite and Review Specs as a TeamThe Team Gets Smaller and TighterThe Human Cost of Running a FleetAgents That Work OvernightProduct and Design Move Closer to the CodeMeasuring AdoptionSummary
About the Author

Content preview from AI-Native Software Engineering

Brief Table of Contents (Not Yet Final)

Preface (unavailable)

Chapter 1: The AI-Native Engineer

Chapter 2: From LLMs to Agents

Chapter 3: Context Engineering Fundamentals

Chapter 4: Model Context Protocol

Chapter 5: Spec-Driven Development

Chapter 6: The SDD Workflow

Chapter 7: SDD Frameworks Compared

Chapter 8: Verification and Quality Gates

Chapter 9: Agent Orchestration Patterns

Chapter 10: Scaling AI-Native Engineering in Teams

Chapter 11: AI-Native Engineering in Practice at Cogwheel (unavailable)

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 0642572352530Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

AI-Native Software Engineering

by Alfonso Graziano

Brief Table of Contents (Not Yet Final)

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.