Frank Ray

Software expert witness for IT and software development disputes.

What a Quality AI Development Harness Incorporates

Frank Ray Agentic Development

Software built with AI assistance reaches a dispute the same way any other software does: defects emerge, a system proves unmaintainable, or a security failure surfaces. The question a dispute turns on is rarely whether the supplier used AI, because almost everyone does. It is whether the engineering discipline around the tool was adequate to what the software had to do.

That discipline now has a name. Harness engineering is the system of guides and automated checks a competent team builds around code generation, so that what ships is verified rather than merely produced. I set out the standard of care for AI-assisted development separately. This page is its concrete companion: a reference for what a quality harness actually contains.

What makes the list below more than one practitioner’s view is that every control on it is one the model-builders, independent senior practitioners, and my own cross-domain practice arrived at independently. The sources, and how they converge, are set out at the end.

The expectation scales with risk. A thin harness around a throwaway internal tool is a reasonable engineering choice; the same thinness around code handling money, personal data, or safety-critical behaviour is not. The controls below are what a competent team reaches for, weighted to what the software carries.

1. Intent Is Fixed Before the Code

The strongest harnesses settle what “done” means before implementation begins, and record it where it cannot quietly change.

  • A durable specification, written before implementation, that expands the brief into concrete requirements rather than a one-line prompt. Anthropic’s harness builds a feature list of more than 200 end-to-end behaviours from the prompt; my own practice uses a rigorous specification in normative form, gap-checked before any code.
  • Acceptance criteria captured as a structured, machine-checkable artefact, not prose the agent can quietly reinterpret. Anthropic holds these as JSON, each marked passing or failing, with status-only edits permitted and removal forbidden.
  • The test plan, or definition of done, committed to the branch before implementation starts, so the intent is locked and any later drift shows up in the diff.
  • Plans treated as first-class, versioned artefacts. OpenAI checks execution plans, progress, and decision logs into the repository alongside the code; I file a one-page decision record for the same reason.

Work is anchored to the primary sources themselves, the actual files, not the agent’s summary of them. A single notes file holding the settled decisions keeps a fresh agent from reinventing a strategy already chosen, a discipline that proved as important in the legal work as in the code.

2. The Repository Is the Single Source of Truth

Everything the agent needs to reason must live in the repository, versioned. OpenAI put it most sharply: what the agent cannot see in context effectively does not exist, so knowledge in a chat thread or someone’s head is invisible to it.

  • A map, not a manual: a short entry-point file acting as a table of contents into a structured documentation tree, revealed progressively, rather than one monolithic instruction file that, in OpenAI’s words, rots instantly and resists verification. Osmani makes the same point as a pilot’s checklist, not a style guide, kept to tens of lines.
  • Rules earned from real failures rather than brainstormed. Osmani calls this the ratchet: a constraint is added when a specific failure has been seen, and removed when a better model makes it redundant, so every line traces to something that actually went wrong. Read after the fact, that history is itself a signal of a maturing harness rather than a notional one.
  • A working log and clean commit history that let a fresh session, a future maintainer, or an examining expert reconstruct what was done and why.
  • The knowledge base enforced mechanically, with checks that documentation is current, cross-linked and structured, and a recurring agent that finds stale material and opens corrections.

3. Automated Verification Surrounds Every Change

Where generation outpaces reading, automated checks become the primary line of quality control, not the human eye.

  • A type checker and linter in the gate, the full test suite run automatically on a pre-commit hook or in CI rather than at the author’s discretion, an integration gate that blocks a broken change from merging, and security and dependency scanning. Thoughtworks treats security scanning of this kind as a mandatory pre-commit step covering common vulnerability classes, secret leakage, and insecure dependencies.
  • Checks placed as far to the left as their cost allows. Böckeler’s principle is to keep quality left: fast, cheap controls before a commit or integration, and expensive ones, such as broad review or mutation testing, afterwards. The earlier an issue is caught, the cheaper it is to fix.
  • Feedback written for the agent to act on. A failing check returns the error text, and ideally the remediation, into the loop so the agent self-corrects. Osmani’s phrase is that success is silent and failures are verbose; Böckeler and OpenAI both note that a custom lint message can carry its own correction instructions.
  • The continuous-integration configuration and release tooling treated as part of the deliverable, versioned and maintained rather than improvised.

4. Tests That Actually Prove Something

A green suite is not the same as a correct one, and this is where these disputes increasingly turn.

  • Every acceptance criterion mapped to a real test that genuinely exercises it, not a suite that asserts little. My own checks confirm each named scenario has a non-trivially-passing test that points back to it.
  • Independence between code and its tests. A suite written in the same pass as the implementation inherits its blind spots. Böckeler is explicit that this is the unsolved part of the problem, that current practice puts a lot of faith into AI-generated tests and that this is not good enough yet, which is precisely why a separately committed test plan matters.
  • End-to-end verification through the real interface, not unit tests alone. Anthropic drives the running application with browser automation to confirm a feature works as a user would experience it; OpenAI does the same through developer-tools instrumentation.
  • A discipline against declaring work done prematurely. Self-verification before a feature is marked complete was a named failure mode in Anthropic’s work, not an afterthought.

5. Architecture and Taste Enforced Mechanically

Documentation alone does not keep an agent-generated codebase coherent. The controls that hold are the ones the machine enforces.

  • A defined architecture with validated dependency directions and a limited set of permitted edges, enforced by custom linters and structural tests rather than by asking the model nicely. OpenAI built a rigid layered model early, the kind of structure usually postponed until a team has hundreds of engineers, because the constraints are what allow speed without decay.
  • Taste invariants encoded as custom lints, covering logging, naming, file size, and reliability requirements, with error messages that inject the remediation into the agent’s context.
  • Boundaries enforced centrally while autonomy is allowed locally: strict on correctness, interfaces, and reproducibility; free within them.
  • Deterministic mechanisms carrying the load-bearing guarantees. Böckeler’s distinction is between computational controls, which are deterministic, fast and reliable, and inferential ones, an AI acting as judge, which add richer judgement but no certainty. My own lesson from safety-critical coaching work was the same: better prompting is heuristic and guarantees nothing, so where a guarantee is needed it has to come from outside the model.

6. Independent, Anchored Review

Review is where an agent’s confidence is most dangerous, because a model grading its own work skews positive. Anthropic, OpenAI and Thoughtworks all reach the same conclusion: separate the generation from the evaluation.

  • Review anchored to a written standard set in advance, so a finding is the breach of a fixed rule rather than a matter of one reviewer’s taste. In my own workflow, specialist reviewers are each bound to a named rule on disk, which is what makes a finding defensible.
  • Engineered independence, not merely a second pass. A reviewer is briefed cold, on a fresh context, and told explicitly what not to read, so it cannot anchor to the author’s reasoning. The strongest form strips prior thinking from the inputs and corroborates across two different model families: agreement is corroboration, disagreement is a flag worth chasing.
  • A reusable, fixed brief that anchors each reviewer to a defined role and ruleset, the review equivalent of anchoring to a rule on disk.
  • Multiple review axes rather than one pass: logic, test coverage, silent-failure paths, and public-interface design, with findings severity-ranked and cited to file and line.
  • The reviewer treated as an input, not a verdict. A cold review that contradicts something the human knows first-hand is weighed, not obeyed. Deferrals are recorded as reasoned decisions, never silent skips.
  • Edits applied as small, targeted changes rather than wholesale regeneration, with verification re-run after each pass, because fixes can quietly reintroduce old errors.

7. The Running System Made Legible

An agent can only verify what it can observe. The mature harnesses make the running system inspectable to the agent, not just the source.

  • The application bootable in isolation per change, so a fix is validated against a live instance rather than read as code. OpenAI runs one instance per working branch; Anthropic scripts a development server and a basic end-to-end check at the start of each session.
  • Logs, metrics and traces made queryable by the agent, so a requirement such as a startup time or a journey latency becomes something it can check rather than guess at.
  • The ability to reproduce a reported failure, apply a fix, and demonstrate the resolution against the real interface, with the before and after preserved.

8. Incremental Progress and a Recoverable State

Agents tend to attempt too much at once and to leave the work half-finished. The harness pushes the other way.

  • One unit of work at a time, against the tendency to one-shot an entire feature set.
  • Each session ending in a clean, mergeable state: a descriptive commit and a progress note, so a bad change can be reverted and a working state recovered.
  • A short orientation routine at the start of each session, establishing where the work stands and whether it still runs before new work begins.
  • Short-lived branches rather than long-running ones.

9. Continuous Control of Drift

A fully agent-generated codebase drifts, because the agent replicates the patterns it already finds, including the poor ones. Left alone, that compounds.

  • Recognition that drift is structural, not occasional, and has to be actively corrected.
  • Opinionated principles encoded in the repository and enforced continuously, with human taste captured once and then applied to every change.
  • A recurring cleanup process. OpenAI runs background tasks that scan for deviations, grade quality per domain, and open targeted refactoring changes, paying technical debt down in small increments rather than in painful bursts.

10. Human Accountability and Escalation

The tool changes how code is written. It does not change who answers for it.

  • Humans steer and agents execute. People specify intent, prioritise, and validate outcomes; they do not discharge responsibility by delegating it to a model.
  • The binding decisions on the genuinely ambiguous calls, the ones no rule forces, stay with the human. The agent’s job is to widen the option space and surface the surprises.
  • A defined escalation path: the agent escalates when judgement is required rather than guessing.
  • The agent managed like a capable but unsupervised actor, with separation of duties, oversight, challenge mechanisms, and documentation, because it can be fluent and wrong at the same time.

11. Safe Execution and Change Control

Speed at the keyboard is no reason to relax the controls on what reaches production or what the agent is allowed to do.

  • Agent-generated code run in an isolated sandbox rather than on a developer’s machine, with allow-listed commands, network isolation, and environments created and torn down per task.
  • Hard blocks on irreversible actions, and approval required before high-consequence ones: no unguarded destructive commands, and human sign-off before a change opens a pull request or reaches the main branch.
  • A small, deliberate tool surface rather than a sprawling one, with the understanding that every connected tool or external service is trusted text the model will read, and therefore a supply-chain and prompt-injection surface in its own right.
  • Explicit security rules treated as first-class, with never-allow patterns for secrets, insecure dependencies and known vulnerability classes enforced rather than requested.

Where the Harness Can Mislead

A harness is evidence, but it is not proof on its own, and three failure modes recur.

It can test the wrong things, exercising the easy paths and leaving the risky ones untouched, so that a green suite reflects coverage of what did not matter. It can be trusted past what it proves, treating a passing suite as correctness when the same process generated both the code and the tests, so the blind spots in one are the blind spots in the other. And it can be absent altogether behind a confident claim that the system works. Each of these is observable after the fact, because the harness leaves a record: the test code, the pipeline configuration, and the build logs all show what was actually checked, and what was not.

One point invites misreading. OpenAI describe relaxing their merge gates at high throughput, with short-lived changes and flaky tests chased by a re-run rather than blocking, on the reasoning that corrections are cheap and waiting is expensive. They are explicit that this would be irresponsible in a low-throughput environment. The relaxation is defensible only where the surrounding harness is strong and the risk the code carries is low. It runs directly against the principle that review and testing scale up for code handling money, personal data, or safety. A thin gate is a reasonable choice for a low-risk internal tool with a thorough harness behind it, and a serious departure for a payment or safety-critical system. The same control can be sound practice or a failing, and which one it is depends on the risk it sits in front of.

How This Reference Was Assembled

What makes this reference more than one practitioner’s view is how it was assembled. Three teams arrived at the same controls independently: Anthropic, describing how to keep an agent productive across many sessions; OpenAI, reporting on an internal product of roughly a million lines written with no hand-typed code; and my own published agentic development practice, built and tuned over six months and applied in a second domain entirely, a multi-agent legal-case review. Independent senior practitioners describe the same boundary from outside the labs: Birgitta Böckeler of Thoughtworks, writing on Martin Fowler’s site; Addy Osmani of Google; and Thoughtworks as a delivery stack. When the firms that build the models, a respected consultancy’s distinguished engineers, and a practising expert all draw the same line, the result is no longer a matter of taste. It is a description of accepted practice, which is the standard a court applies.

Sources