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 presents a practical operating model for building software with AI coding agents without losing architectural control of the codebase. It shifts the developer’s role from primarily producing code to designing the environment in which code is generated, constrained, validated, repaired, and accepted.

The model connects specification, context control, architectural ownership, visible system flows, harness enforcement, verification, repair, and evidence into one controlled development process.

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 work within explicit boundaries
systems remain stable as they evolve
complexity is controlled rather than silently accumulated
changes can be traced, verified, repaired, and accepted with evidence

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.

A separate Kindle edition is also available on Amazon .

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 individual AI tools; It is a practical guide to keeping software systems understandable, verifiable, and under control when AI becomes part of the development process.

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 Agent Loop
- 9.15 Key Insight
Chapter 10 - Agent Loop and Execution
- 10.1 The Controlled Agent Loop
- 10.2 Plan -> Execute -> Evaluate
- 10.3 From Intent to Verified Change
- 10.4 Agent Constraints
- 10.5 The Agent as Executor of the Law
- 10.6 Context as Behavior Control
- 10.7 Decisions and Boundaries
- 10.8 Evidence as Part of Execution
- 10.9 Memory After Acceptance
- 10.10 Controlled Autonomy
- 10.11 Transition to Failure and Repair
- 10.12 Key Insight
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 Failure Patterns
- 11.5 From Signal to Diagnosis
- 11.6 The Repair Task Frame
- 11.7 The Agent as a Repair Operator Under Constraint
- 11.8 Harness-Guided Repair
- 11.9 Safe Repair and False Repair
- 11.10 Return to a Verified State
- 11.11 Repository Anchors for Failure and Repair
- 11.12 Transition to System Evolution
- 11.13 Key Insight
Chapter 12 - System Evolution
- 12.1 Drift as a Process
- 12.2 Controlled Change Over Time
- 12.3 Harness Debt
- 12.4 Harness Maintenance
- 12.5 Change Trace in Evolution
- 12.6 Preserving Invariants During Evolution
- 12.7 Evolution of System Memory
- 12.8 Scaling Complexity
- 12.9 A Stable System Over Time
- 12.10 Repository Anchors for Evolution
- 12.11 Transition to Human + System
- 12.12 Key Insight
Chapter 13 - Human + System
- 13.1 The Role of the Engineer
- 13.2 Human Ownership of System Law
- 13.3 From Code to System
- 13.4 Harness as a Project-Shaped Framework
- 13.5 Starting the Work: From Intent to a Controlled System
- 13.6 Working with Agents Without Losing Control
- 13.7 Scaling Understanding
- 13.8 Organizational Effects
- 13.9 Decisions That Need Ownership
- 13.10 Transition to Self-Enforcing Systems
- 13.11 Key Insight
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 Development as System Discipline
- 14.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
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

You pay

Author earns

You pay

Author earns

About

About This Book

Share this book

Categories

Feedback

Team Discounts

Author

Contents

Get the free Community Edition

The Leanpub 60 Day 100% Happiness Guarantee

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

Free Updates. DRM Free.

Write and Publish on Leanpub