- 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.8.1 What an invariant is
- 3.8.2 Why invariants matter
- 3.8.3 Types of invariants
- 3.8.4 How a system degrades without invariants
- 3.8.5 Invariants and AI
- 3.8.6 Invariants as a gate mechanism
- 3.8.7 The relationship between invariants and architecture
- 3.8.8 The most important principle
- 3.8.9 Key insight
- 3.9 Definition of Failure
- 3.10 Traceability
- 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 What the System Must Load
- 4.4 The Knowledge Bank as Stable Context
- 4.5 Task Specification as the Context of Change
- 4.6 Context for the *Agent* and Context for the Human
- 4.7 Selective Loading
- 4.8 Context as a Control Mechanism
- 4.9 Transition to Architecture and Repository Anchors
- 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
- 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 Sequence Diagram as a Communication Model
- 6.4 State as the Source of Truth
- 6.5 Diagrams as Verification
- 6.6 Connecting Flow and Architecture
- 6.7 Transition to Implementation
- 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 Combining Skills
- 8.5 Controlling Complexity
- 8.6 The Agent as a Participant in the System
- 8.7 Transition to Enforcement
- Chapter 9 - The Harness
- 9.1 Why Law and Architecture Are Not Enough
- 9.2 What a Harness Is
- 9.3 Guides - rules before action
- 9.4 Sensors - checking after action
- 9.5 Deterministic Control
- 9.6 Inferential Control
- 9.7 Invariants as Enforceable Rules
- 9.8 The Harness as an Anti-Drift Mechanism
- 9.9 The Harness as System Memory
- 9.10 Connecting to Gates and Tests
- 9.11 Transition to the Agent Loop
- 9.12 What a Harness Looks Like in a Real System
- Chapter 10 - Agent Loop and Execution
- 10.1 Plan -> Execute -> Evaluate
- 10.2 Agent Constraints
- 10.3 The Agent as Executor of the Law
- 10.4 Context as Behavior Control
- 10.5 The Link to the Harness
- 10.6 Decisions and Boundaries
- 10.7 Controlled Autonomy
- Chapter 11 - Failure and Repair
- 11.1 Where Failure Really Begins
- 11.2 Detection — how the system learns that an issue exists
- 11.3 Logs and Signals as Input for Diagnosis
- 11.4 From Signal to Diagnosis
- 11.5 The Agent as a Repair Operator Under Constraint
- 11.6 Harness-guided repair
- 11.7 Safe Repair and False Repair
- 11.8 Return to a Verified State
- 11.9 Key insight
- 11.10 Repository anchors and maps of repository changes
- Chapter 12 - System Evolution
- 12.1 Drift as a Process
- 12.2 Controlled Change
- 12.3 Traceability in Evolution
- 12.4 Preserving Invariants
- 12.5 Scaling Complexity
- 12.6 A Stable System Over Time
- 12.7 Repository Anchors
- Chapter 13 - Human + System
- 13.1 The Role of the Engineer
- 13.2 The Human as Guardian of the Law
- 13.3 From Code to System
- 13.4 Starting the Work: From Intent to a Controlled System
- 13.5 Working with Agents Without Losing Control
- 13.6 Scaling Understanding
- 13.7 Organizational Effects
- 13.8 What Must Not Be Delegated
- Chapter 14 - Toward Self-Enforcing Systems
- 14.1 From spec-anchored to spec-as-source
- 14.2 The Harness as a Point of Convergence
- 14.3 What Self-Sustaining Systems Really Are
- 14.4 AI as a Constrained Participant in the System
- 14.5 The Future of Development as a System Discipline
- 14.6 Final Insight
- Appendix A - Practical Agent Operating Model
- A.1 What Agents Are and What Skills Are
- A.2 The Role of Working Rules and Context Files
- A.3 Instruction Files, Prompts, and Project Rules
- A.4 How Context Is Chosen Instead of Loading Everything
- A.5 The Knowledge Bank and Task Specification in Practice
- A.6 How 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
- Appendix B - References and URLs
- 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
Becoming a Harness-Driven Developer
Building Reliable Systems in the Age of AI-Generated Code
AI can generate code faster than ever. But speed is no longer the hardest part of software development.
The real challenge is building systems where generated code remains correct, controlled, and aligned with architectural intent.
Becoming a Harness-Driven Developer introduces a new development model for the age of AI-assisted engineering - one where developers focus less on writing every line by hand and more on defining the rules, structure, and enforcement mechanisms within which AI code agents operate.
Through a practical repository mapped directly to the book’s chapters, this book shows how to move from ad hoc coding to a harness-driven approach based on specification, architecture, invariants, controlled execution, and system evolution.
This is a book about staying in control while software development changes.
Minimum price
$19.00
$29.00
You pay
$29.00Author earns
$23.20PDF
About
About the Book
About This Book
Software development is undergoing a fundamental shift.
As AI-generated code becomes increasingly capable, the bottleneck is no longer writing code - it is ensuring that the code is correct, consistent, and aligned with the system's intent.
This book addresses that problem directly.
Becoming a Harness-Driven Developer introduces a new approach to building software in the age of AI-assisted development - one where developers no longer focus primarily on writing code, but on designing the environment in which code is generated, validated, and enforced.
Instead of relying on intuition, manual reviews, or fragile conventions, this approach is built on three pillars:
- Specification as law clearly defined system behavior and constraints
- Architecture as structure explicit ownership, boundaries, and flow
- Harness as enforcement a system that ensures generated code stays correct
Together, these form a development model where:
- AI agents can generate code safely
- systems remain stable as they evolve
- complexity is controlled rather than accumulated
This book is both practical and theory-backed.
It connects real-world implementation with foundational ideas from modern software architecture, system design, and emerging practices like harness engineering and agent-driven development.
Alongside the book, readers also get access to a practical repository ( https://github.com/miloskec/frontend-song-request ) developed according to these same principles. The chapters are mapped to that repository so the ideas explained in the book can be seen immediately in a real, working example - not only as theory, but as a concrete system built with specification, architecture, harness, and controlled execution in mind.
You will learn how to:
- define systems before writing code
- translate specifications into enforceable rules
- design architectures that guide both humans and AI
- build harnesses that prevent drift and enforce correctness
- structure development as a controlled loop instead of ad hoc coding
This is not a book about using AI tools.
It is a book about how software development itself changes when AI becomes part of the system.
And how to stay in control of that system.
Author
About the Author
Contents
Table of Contents
Get the free sample chapters
Click the buttons to get the free sample in PDF or EPUB, or read the sample online here
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.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
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.)
In fact, authors have earned over $15 million writing, publishing and selling 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.