- How to read this book
- Running example used in this book
- Chapter 1 - The Problem
- 1.1 Development Speed and Loss of Control
- 1.2 Implicit Knowledge as a Hidden Risk
- 1.3 AI as an Amplifier of Existing Problems
- 1.4 Local Correctness vs. System Correctness
- 1.5 Degradation as a Process
- Chapter 2 - The Model
- 2.1 The System as Structure, Not Code
- 2.2 Law, City, and Behavior
- 2.3 Specification as Law
- 2.4 Architecture as Space
- 2.5 Enforcement as a Necessary Layer
- 2.6 From Law to Structure
- Chapter 3 - Specification Before Implementation
- 3.1 Why Specification Matters Again
- 3.2 What It Means for the Specification to Be Law
- 3.3 Specification as a System, Not a Document
- 3.4 Three Modes of Specification
- 3.4.1 Spec-first - law as the starting point
- 3.4.2 Spec-anchored - law as an active system
- 3.4.3 Spec-as-source - law as the system engine
- 3.4.4 The relationship between the modes
- 3.4.5 Where most systems actually are
- 3.4.6 Practical conclusion
- 3.5 Memory Bank and Task Spec
- 3.5.1 Memory bank - stable system knowledge
- 3.5.2 Task spec - local knowledge of change
- 3.5.3 Why this split is critical
- 3.5.4 Context control
- 3.5.5 The relationship between the memory bank and the task spec
- 3.5.6 A practical working model
- 3.5.7 Key insight
- 3.6 System Responsibilities
- 3.7 System Boundaries
- 3.8 Invariants - Rules That Must Not Be Broken
- 3.9 Definition of Failure
- 3.10 Change Trace
- 3.11 Specification as Input for Agents
- 3.12 The Limitation of Specification
- 3.13 Key Insight
- 3.14 Transition to Architecture
- 3.15 What Law Looks Like in a Real System
- Chapter 4 - Context and Knowledge Control
- 4.1 The Problem of Uncontrolled Context
- 4.2 Context as Constraint
- 4.3 From System Knowledge to Working Context
- 4.4 The Context Loading Order
- 4.5 The Memory Bank as Selectable Context
- 4.6 Task Specification as the Local Frame
- 4.7 Context for the Agent and Context for the Human
- 4.8 Context Budget and Selective Loading
- 4.9 What Must Stay Unloaded
- 4.10 When Missing Context Must Stop the Work
- 4.11 Context as the First Control Layer
- 4.12 Transition to Architecture and Repository Anchors
- Key insight
- Chapter 5 - Architecture Before Code
- 5.1 Why Architecture Comes Before Code
- 5.2 From Law to City
- 5.3 Architecture as a System of Ownership
- 5.4 Three Load-Bearing Architectural Layers
- 5.4.1 State layer - the truth of the system
- 5.4.2 Flow layer - the change of truth
- 5.4.3 Structure layer - where things live
- 5.5 Central Architectural Document: docs/ARCHITECTURE/overview.md
- 5.6 Ownership by layer - who owns what
- 5.7 Dependency direction - the traffic rules of the city
- 5.8 State vs service vs UI boundary
- 5.9 What Must Never Happen - forbidden zones of the city
- 5.10 Route-level ownership - the public, auth, and DJ districts of the city
- 5.11 src/stores/README.md as proof that architecture lives in the code
- 5.12 Why "Why not Redux initially?" is not a side note
- 5.13 How this chapter maps law onto the real repo
- 5.14 What good architecture enables for change
- Example: queue visibility
- 5.15 Key insight
- 5.16 What comes next
- Chapter 6 - Seeing the System
- 6.1 Why the System Must Be Visible
- 6.2 Flow as System Behavior
- 6.3 Reading a Flow: Event, Owner, State, Output
- 6.4 Sequence Diagram as a Communication Model
- 6.5 State Transition as the Proof of Truth
- 6.6 Wrong Flow vs Controlled Flow
- 6.7 Diagrams as Verification
- 6.8 The Visibility Trace
- 6.9 Connecting Flow and Architecture
- 6.10 Transition to Implementation
- Key insight
- Chapter 7 - Implementation as Mapping
- 7.1 Code as Consequence
- 7.2 Mapping the Specification
- 7.3 Mapping the Architecture
- 7.4 Ownership in Implementation
- 7.5 Where Each Logic Belongs
- 7.6 Avoiding Bypass Solutions
- 7.7 Consistent Implementation
- Chapter 8 - Roles, Skills, and Structured Work
- 8.1 Division of Responsibilities
- 8.2 Roles in the System
- 8.3 Skills as Units of Work
- 8.4 Structured Work as a Change Path
- 8.5 Four Modes of Responsibility
- 8.6 Example: Hidden Queue Leak
- 8.7 Combining Skills Without Losing Control
- 8.8 Controlling Complexity
- 8.9 The Agent as a Participant in the System
- 8.10 Transition to Enforcement
- Chapter 9 - The Harness
- 9.1 Why the Previous Layers Need Enforcement
- 9.2 What a Harness Is
- 9.3 The Harness Around One Change
- 9.4 Guides - Rules Before Action
- 9.5 Sensors - Checks After Action
- 9.6 Deterministic Control
- 9.7 Inferential Control
- 9.8 Invariants as Enforceable Rules
- 9.9 The Harness as an Anti-Drift Mechanism
- 9.10 The Harness as System Memory
- 9.11 Connecting Guides, Sensors, Gates, and Evidence
- 9.12 What a Harness Looks Like in a Real System
- 9.13 Beginner Harness Inventory
- 9.14 Transition to the Wider Harness Landscape
- 9.15 Key Insight
- Chapter 10 - Understanding the Harness Landscape
- 10.1 A Term with More Than One Working Meaning
- 10.2 A Functional Map of Harness Approaches
- 10.2.1 Project/System Harness - Control of System Change
- 10.2.2 Agent Runtime Harness - Control of Agent Execution
- 10.2.3 Evaluation Harness - Control of an Evaluation Procedure
- 10.2.4 Other Dimensions of the Same Landscape
- 10.3 How the Control Perspectives Work Together
- 10.4 Where the Harness in This Book Fits
- 10.5 One Change, Three Harness Perspectives
- 10.6 Key Insight and Transition to the Agent Loop
- Chapter 11 - Agent Loop and Execution
- 11.1 The Controlled Agent Loop
- 11.2 Plan -> Execute -> Evaluate
- 11.3 From Intent to Verified Change
- 11.4 Agent Constraints
- 11.5 The Agent as Executor of the Law
- 11.6 Context as Behavior Control
- 11.7 Decisions and Boundaries
- 11.8 Evidence as Part of Execution
- 11.9 Memory After Acceptance
- 11.10 Controlled Autonomy
- 11.11 Transition to Failure and Repair
- 11.12 Key Insight
- Chapter 12 - Failure and Repair
- 12.1 Where Failure Really Begins
- 12.2 Detection - How the System Learns That an Issue Exists
- 12.3 Logs and Signals as Input for Diagnosis
- 12.4 Failure Patterns
- 12.5 From Signal to Diagnosis
- 12.6 The Repair Task Frame
- 12.7 The Agent as a Repair Operator Under Constraint
- 12.8 Harness-Guided Repair
- 12.9 Safe Repair and False Repair
- Example: rejected request that returns after refresh
- 12.10 Return to a Verified State
- 12.11 Repository Anchors for Failure and Repair
- 12.12 Transition to System Evolution
- 12.13 Key Insight
- Chapter 13 - System Evolution
- 13.1 Drift as a Process
- 13.2 Controlled Change Over Time
- 13.3 Harness Debt
- 13.4 Harness Maintenance
- 13.5 Change Trace in Evolution
- 13.6 Preserving Invariants During Evolution
- 13.7 Evolution of System Memory
- 13.8 Scaling Complexity
- 13.9 A Stable System Over Time
- 13.10 Repository Anchors for Evolution
- 13.11 Transition to Human + System
- 13.12 Key Insight
- Chapter 14 - Human + System
- 14.1 The Role of the Engineer
- 14.2 Human Ownership of System Law
- 14.3 From Code to System
- 14.4 Harness as a Project-Shaped Framework
- 14.5 Starting the Work: From Intent to a Controlled System
- 14.6 Working with Agents Without Losing Control
- 14.7 Scaling Understanding
- 14.8 Organizational Effects
- 14.9 Decisions That Need Ownership
- 14.10 Transition to Self-Enforcing Systems
- 14.11 Key Insight
- Chapter 15 - Toward Self-Enforcing Systems
- 15.1 From spec-anchored to spec-as-source
- 15.2 The Harness as a Point of Convergence
- 15.3 What Self-Sustaining Systems Really Are
- 15.4 AI as a Constrained Participant in the System
- 15.5 Development as System Discipline
- 15.6 Final Insight
- Appendix A - Practical Agent Operating Model
- A.1 What Agents, Subagents, and Skills Are
- A.2 The Role of Working Rules and Context Files
- A.3 Instruction Layers
- A.4 How Context Is Chosen Instead of Loading Everything
- A.5 The Memory Bank and Task Specification in Practice
- A.6 How Roles and Skills Are Combined
- A.7 Handoff Between Roles
- A.8 Gates, Verification, and Repeatability
- A.9 Practical Mapping to the Repo
- A.10 One Example of the Entire Workflow
- A.11 Platform Mapping and Universality
- Appendix B - References and URLs
- B.0 Project Repository
- B.1 Harness and the Enforcement of Discipline
- B.2 Context, Reasoning, and the Agent Loop
- B.3 Architecture, Map-Not-Manual, and Systemic Structure
- B.4 Roles, Subagents, Skills, and Multi-Agent Work
- B.5 Practical Codex Work and Good Practices
- B.6 The Gemini Agent Model and Context Files
- B.7 Platform and Organizational Scaling
- B.8 Harness Terminology, Agent Runtimes, and Evaluation
- Appendix C - Practical Templates and Starting Prompts
- C.1 Repository Entry Map
- C.2 Task Contract Template
- C.3 Context Pack Template
- C.4 Agent Assignment Template
- C.5 Harness Review Template
- C.6 Starting Prompt - Shape Product and Scope
- C.7 Starting Prompt - Update or Validate System Law
- C.8 Starting Prompt - Map a Change to Architecture
- C.9 Starting Prompt - Update a PlantUML Flow
- C.10 Starting Prompt - Bounded Implementation
- C.11 Repair Prompt - Hidden Queue Leak
- C.12 Evidence Report Template
- C.13 Appendix C Key Use Rule
Becoming a Harness-Driven Developer
Building Reliable Systems in the Age of AI-Generated Code
This book is 100% completeLast updated on 2026-10-28
The fastest practical path to understanding harness-driven development as a complete system. Through clear visual diagrams and a real repository mapped to the book, you will see how a harness guides AI agents, evaluates their work, detects drift, enforces constraints, supports repair, and keeps software evolution visible, verifiable, and under control.
Minimum price
$29.00
$39.00
You pay
Author earns
Buying multiple copies for your team? See below for a discount!
PDF
EPUB
About
About the Book
About This Book
A practical, visual introduction to Harness-Driven Development. Understand how the pieces fit together, see them applied in a real project, and learn how to start building a harness for your own software.
AI coding agents such as Claude Code and OpenAI Codex are changing software development. Writing code is becoming faster and easier. The greater challenge is keeping that code correct, consistent, maintainable, and aligned with the system's architecture.
This is where harness engineering comes in.
You may already know how to use prompts, agent instructions, skills, hooks, and automated checks. But how do these elements work together? What does each one protect? And how do you organize them into a reliable development process?
Becoming a Harness-Driven Developer explains the engineering principles behind these practices and shows how to apply them systematically.
The Bigger Picture, Explained Visually
This book connects the essential parts of harness-driven software development into a coherent model.
Through clear explanations, UML diagrams, architectural models, and a continuous practical example, you will see how specifications, context management, architecture, agent execution, verification, repair, and evidence support controlled software changes.
You will understand how the pieces fit together, why they matter, and how they help prevent a software system from drifting away from its intended design.
The approach is built on three fundamental pillars:
- Specification as Law: Define expected behavior, responsibilities, constraints, and invariants.
- Architecture as Structure: Establish ownership, system boundaries, dependencies, and visible flows.
- Harness as Enforcement: Connect instructions, checks, gates, and evidence to guide and verify changes.
Together, these principles form the foundation of a Project/System Harness, a control environment designed around the needs of a particular software project.
New to Harness Engineering? Start Here.
If you are discovering harness engineering for the first time, this book helps you understand the concepts before implementing individual techniques.
You will learn what a harness does, which problems its components solve, and how those components support one another.
The explanations build progressively, using diagrams and examples to make architectural concepts easier to follow.
The book also includes a guided quick-start reading path, helping you learn the essentials and begin applying the approach to a small, controlled project change.
Already Using Claude Code, Codex, or Other AI Coding Agents?
If you already use agent instructions, skills, hooks, tests, or automated workflows, this book helps you connect those practices to a broader engineering model.
You will see how familiar tools and techniques contribute to project-level control, architectural consistency, and reliable change acceptance.
The principles complement development workflows using Claude Code, OpenAI Codex, Gemini CLI, and other coding agents, while remaining independent of any particular platform.
The book also explains the distinctions between Project/System Harnesses, Agent Runtime Harnesses, and Evaluation Harnesses, including their responsibilities and how they work together.
Its main focus is the Project/System Harness: maintaining the integrity of a software system as humans and AI agents change it.
Learn Through a Real GitHub Project
The concepts are connected to a companion repository:
Frontend Song Request — Practical Harness-Driven Development Example
This React-based example demonstrates how specifications, architecture documentation, agent instructions, context selection, tests, and quality gates support a controlled development workflow.
The chapters reference the same project, helping you follow the connections between requirements, architectural decisions, implementation, verification, and repair.
You can explore the repository, examine its diagrams and development rules, and use its structure as a practical reference when adapting the approach to your own projects.
From AI-Assisted Coding to Software Architecture
Learning harness-driven development also introduces you to the foundations of software architecture.
As you learn to guide AI-generated changes, you begin to reason about system boundaries, responsibilities, dependencies, contracts, state, and long-term maintainability.
You see why architecture matters, how it influences implementation, and how verification helps preserve it as software evolves.
This makes the book particularly useful for developers who want to move beyond individual coding tasks and develop a stronger understanding of software systems.
You begin learning to think like a software architect while working with AI coding agents.
What You Will Learn
By the end of the book, you will have a practical foundation for:
- Understanding how a Project/System Harness works as a connected control system.
- Turning requirements into specifications, boundaries, and verifiable rules.
- Designing architectural guardrails that guide humans and AI agents.
- Managing context, agent responsibilities, execution, and verification.
- Detecting drift, investigating failures, and organizing evidence-based repairs.
- Starting and adapting a Project/System Harness for your own software projects.
- Understanding how project-level, runtime, and evaluation harnesses complement one another.
What's Included in the Updated Edition
The updated edition contains 15 chapters, including a dedicated chapter explaining the wider harness engineering landscape.
It features refined UML diagrams, a continuous GitHub repository example, and reusable templates for task contracts, context packs, agent assignments, harness reviews, implementation tasks, repairs, and evidence reports.
The book is available in PDF and EPUB, with improved navigation and reader-friendly formatting.
Whether you are new to harness engineering or already developing software with AI coding agents, this book helps you understand the principles behind reliable AI-assisted development and gives you a practical starting point for building your own Project/System Harness.
Understand the principles. See how the system works. Start building your harness.
Feedback
Team Discounts
Team Discounts
Get a team discount on this book!
Up to 3 members
- Minimum price
- $47.00
- Suggested price
- $72.00
Up to 5 members
- Minimum price
- $76.00
- Suggested price
- $116
Up to 10 members
- Minimum price
- $133
- Suggested price
- $203
Up to 15 members
- Minimum price
- $190
- Suggested price
- $290
Up to 25 members
- Minimum price
- $285
- Suggested price
- $435
Author
About the Author
Miloš Kecman
Milos Kecman is a full-stack software engineer, architect, entrepreneur, and founder with more than 15 years of experience, primarily building SaaS products and startup platforms. He has designed and developed several platforms end to end, working across architecture, backend and frontend systems, integrations, payments, infrastructure, and product delivery. His experience includes serving as a payment lead and building business-critical software systems.
He is the founder of EduToolsFactory and is currently developing several additional software products.
Since 2024, his work has increasingly focused on applied AI systems and intelligent automation, particularly solutions that help founders move from an initial idea to a working product, coordinate complex workflows, evaluate opportunities, and build toward sustainable growth.
He is a Senior Laravel Certified Engineer and Zend Certified PHP Engineer.
Contents
Table of Contents
Get the free Community Edition
You can get the free Community Edition in PDF or EPUB just by sharing your name and email address with the author.
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.