Skip to content
Article reader Listen + reading controls
LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

0:00 0:00
Reading settings
Text size
100%

Coding agents need a new definition of done

OpenAI's September 15 release introduces GPT-5-Codex, an artificial intelligence (AI) model optimized for agentic software engineering. The announcement emphasizes both quick interactive work and extended independent execution, including hours of iteration on large tasks and test failures.

When an agent can work longer, “the code runs” becomes an even less adequate definition of done.

A coding agent can traverse a repository, modify many files, run tools, and adjust its approach. That reach creates leverage. It also increases the distance between the human's initial request and the final set of consequences.

Software engineering teams need acceptance criteria that scale with that distance.

Completion is a bundle of evidence

For consequential software, done should include at least five forms of evidence:

  1. Behavior: the change satisfies explicit acceptance criteria and relevant tests.
  2. Integrity: existing behavior remains intact, including cases the agent does not target.
  3. Security: dependencies, permissions, inputs, and generated changes have received proportionate review.
  4. Operability: logging, failure handling, deployment, rollback, and documentation support real use.
  5. Comprehension: a responsible person can explain the change well enough to own it.

The last condition is easy to neglect. A team that merges more code than it can understand may appear faster while accumulating an operational liability.

Review should follow risk, not line count

Agent-generated changes can be large but mechanical, or tiny and dangerous. A one-line authorization change may deserve more scrutiny than a broad formatting refactor.

Review protocols should consider system criticality, blast radius, reversibility, novelty, sensitive-data exposure, and the strength of automated tests. High-risk changes may require independent human review, targeted security analysis, representative environment tests, or staged release. Lower-risk work can move through lighter controls.

The Secure Software Development Framework from the National Institute of Standards and Technology places security practices throughout development. Coding agents should operate inside that lifecycle, not bypass it because they can produce changes quickly.

Preserve the path to the result

Long-running tasks need checkpoints, concise change summaries, test records, and visible assumptions. The useful artifact is not a transcript of every token. It is an intelligible account of intent, material decisions, commands and tests, unresolved uncertainty, and the resulting diff.

That record supports the next engineer, the reviewer, the incident responder, and the future agent asked to modify the same component.

Protect team learning

The most subtle risk is skill atrophy. If agents consistently take the difficult debugging and integration work, junior engineers can lose access to the experiences through which judgment develops.

Teams should deliberately rotate modes of use: pairing for unfamiliar work, independent agent execution for well-bounded tasks, human-led incident analysis, and post-change walkthroughs for architectural decisions. Productivity should be measured alongside review time, escaped defects, recovery, and growth in team capability.

Longer-running coding agents change the unit of delegation. They also change the evidence required at the point of return. The new definition of done is not “the agent stopped.” It is “the team has enough evidence and understanding to operate what changed.”

Sources and research trail

READER-NEUTRAL SUBSCRIPTION

Follow Field Notes via RSS.

Copy this address into the RSS reader you already use. New notes will appear there automatically—no account, email address, or tracking required.