Compose the work. Conduct the flow. Let the agents play.

Code Quality Team Sep 15, 2026 / 76 min read

Episode 1

Link: https://thenextcommit.substack.com/p/episode-one-ian-johnson?utm_campaign=post&utm_medium=web

Episode summary

Ian Johnson is a staff engineer at Parento and the author of Harness Engineering. His team can ship six to eight small, reviewable tickets per developer each day—not by trusting an agent to get everything right, but by engineering the system around it.

In this episode, Ian explains how precise Jira cards and a truthful project charter control what goes into an agent, while tests, hooks, specialist reviewers and human judgement constrain what is allowed out. We discuss why one card should produce one small pull request, how recurring review feedback becomes part of the harness, why rules must reflect the codebase as it really exists, and how software developers are moving towards “building the thing that builds the thing.”

About Ian

Ian Johnson is a staff engineer at Parento, where he leads the adoption of agentic software-development practices. He is the author of Harness Engineering, a practical book about building reliable workflows around non-deterministic agents. His work explores how charters, harnesses, verification and deliberate feedback loops can increase delivery speed without surrendering engineering quality or accountability.

In this episode

01:14 — Introducing Ian and Harness Engineering
02:16 — Ian’s role at Parento and the origins of the book
03:10 — From Copilot autocomplete to agentic coding
04:42 — Claude Code, Codex, Pi and parallel agent workflows
06:34 — Why parallel agents need a carefully engineered system
08:08 — Review agents, deterministic checks and human accountability
10:01 — Keeping changes small enough for meaningful review
11:01 — One Jira card, one pull request
12:23 — Falsifiable acceptance criteria and explicit exclusions
13:28 — Using an AI refinement skill without letting it invent requirements
14:48 — Decomposing a feature into independently releasable work
17:01 — Shipping six to eight small cards per developer each day
17:59 — Turning repeated review feedback into harness improvements
20:20 — The charter as an agreement between the team and its agents
23:17 — Agents amplify both clean patterns and existing disorder
24:55 — How Ian structures and indexes project context
26:32 — Why generic or inaccurate rules make agent output worse
27:58 — Truthful rules and living migration plans
29:39 — Refactoring legacy software with characterization tests and TDD
31:58 — Using 100% coverage as a project-specific safety boundary
33:10 — Why maintainable code matters more when code is cheap
35:47 — Keeping humans in the loop to control comprehension debt
36:57 — Resisting cognitive surrender as a junior developer
39:33 — Pairing a junior, senior and coding agent
42:57 — Evaluating charter and harness changes
45:56 — Raising the developer’s abstraction level beyond code
47:33 — Building the thing that builds the thing
51:06 — The amplification thesis and acceptable reliability bands
53:19 — Why a hook is more powerful than a rule

Key ideas

A well-shaped ticket controls what the agent builds; the charter controls how it builds it.
Acceptance criteria should be falsifiable, and out-of-scope boundaries should be explicit.
Small batches preserve flow and comprehension. Ian’s one-card, one-PR rule typically produces a diff of around 250 lines.
A charter must describe the codebase truthfully. When the current architecture and desired architecture differ, the intended change belongs in a migration plan rather than a fictional rule.
Guidance and verification work together: rules feed standards forward, while tests, hooks and analysis feed evidence back.
Repeated review feedback should improve the production system. Ian uses a rule of three before promoting a recurring lesson into the charter or harness.
Agents amplify the environment around them. Good structure and strong standards become easier to repeat; inconsistency and debt accelerate too.
The model cannot own the product or answer a production incident. Humans retain accountability and need enough comprehension to exercise it.
The developer’s work moves towards designing the system that produces the software: shaping work, curating context, strengthening checks and applying judgement.