AI coding workflows easily treat the pull request as the finish line.

The worker edits code, tests pass, a PR opens, a human reviews it, and the PR is merged. It looks like the task is complete.

In real software systems, PR merged is often not done.

It is only one boundary: the code has entered the main branch. Release, verification, rollback readiness, and whether the user problem is truly solved may still be unresolved.

Why AI confuses merge with done

The AI worker usually operates inside a local repository.

It can read files, run tests, produce a diff, and write a PR summary. Its environment naturally frames “code changed” as the end of the task.

But production closure often lives outside the repository:

  • Was the change deployed?
  • Was a feature flag enabled?
  • Is data backfill required?
  • Do queues or caches need observation?
  • Does the user still see the problem?
  • Did monitoring detect anything unusual?
  • Is there a rollback plan?
  • Do product, operations, support, or customers need communication?

These decisions should not silently belong to a one-shot coding worker.

Split the states

A reliable workflow keeps these states separate:

  • PR opened;
  • PR reviewed;
  • PR merged;
  • release prepared;
  • release deployed;
  • production verified;
  • issue closed.

Different teams can combine some of these states in practice. They should not collapse them conceptually into one “done”.

For a documentation-only issue, PR merged may be enough to close the task.

For user-visible behavior, data flow, security, permissions, financial records, or production operations, PR merged should only move the issue into the release boundary.

The release boundary needs a clear owner

Codex can help prepare release notes. It can write verification steps from the PR evidence.

But someone or something else must own release.

That owner can be a human release owner, a CI/CD pipeline, or a release bot. The important part is that ownership should be explicit, not hidden inside the worker prompt.

If a team has mature automatic release, the rules should be written down:

  • Which changes may deploy automatically?
  • Which changes require human confirmation?
  • How does rollback work?
  • Who verifies production?
  • When may the issue close?

Without those rules, the AI worker should not treat merge as done.

Record release state in the issue

A simple issue comment is often enough:

PR merged, release verification still required.
Release owner: human
Verification plan:
- confirm dashboard status refresh after deploy
- check error logs for 30 minutes
Final issue closure: after production verification

This comment makes responsibility visible.

Even without automation, humans can see that the task has not actually reached its final boundary.

Done should attach to the user problem

An issue starts with a user problem, not a code action.

The definition of done should return to that problem:

  • Is the user-visible problem gone?
  • Does the expected behavior now happen?
  • Does evidence cover the acceptance criteria?
  • Was the target environment verified?
  • Has remaining risk been accepted?

If those questions are unanswered, PR merged is an intermediate state.

The biggest risk in AI engineering is not that PRs open slowly. The bigger risk is marking an unverified code action as a solved user problem.