In issue-driven AI engineering, one boundary matters more than almost everything else: who schedules the work, and who executes it?

It is tempting to treat Codex or another coding agent as a complete engineer. It reads the issue, decides what matters, judges risk, edits code, opens a PR, follows up on release, and eventually closes the task.

That is convenient in a demo. It is fragile in a real engineering system.

Codex should be the worker. It should not be the scheduler.

A worker is good at bounded execution

Codex is strongest when the input is bounded.

It can read one issue, inspect the relevant code, identify likely causes, make a focused patch, run verification, and produce evidence. That shape is close to a worker run.

A worker run has useful properties:

  • It has an explicit input.
  • It has a bounded scope.
  • It has a start and an end.
  • It can time out.
  • It can fail.
  • It can be retried.
  • It can be reviewed by a human.

That is a good match for AI coding tools.

The problems start when the worker is also expected to watch the repository, scan every issue, manage concurrency, recover failed jobs, decide when a risky change is allowed, promote PRs into releases, and mark production work done.

At that point, the worker is no longer just a worker. It has become the scheduler.

Scheduling needs durable state

A scheduler does not need to sound intelligent. It needs to be reliable.

A scheduler has to answer questions such as:

  • Which issues are explicitly opted into automation?
  • Which issues still need triage?
  • Which worker claimed which issue?
  • Does this issue already have an active branch?
  • Did the worker time out?
  • Where did the last run stop?
  • Do labels, comments, PRs, and branches still agree?
  • Should a failed task be retried or escalated?
  • After merge, is release verification still required?

Those questions should not live inside one chat session.

Chat context can disappear. A worker process can crash. The model can change. A prompt can be edited. The coding tool itself can be replaced.

Long-lived state belongs in more durable places: GitHub labels, branches, comments, PRs, workflow logs, local state files, or a dedicated daemon.

AI can help make decisions. It should not be the only state store.

A clean division of labor

A healthy issue-driven workflow separates scheduler duties from worker duties.

The scheduler owns:

  • issue scanning;
  • opt-in filtering;
  • risk labels;
  • workspace allocation;
  • branch claims;
  • worker startup;
  • state transitions;
  • timeout handling;
  • reconciliation;
  • escalation to humans.

The Codex worker owns:

  • reading the issue contract;
  • reading the relevant code;
  • analyzing the cause;
  • stopping when a stop condition is hit;
  • making a patch when allowed;
  • running verification;
  • producing evidence;
  • preparing a PR summary;
  • reporting blocked or needs-human states.

This split has a practical benefit: the worker can be replaced without rewriting the lifecycle. The scheduler can improve without turning the worker prompt into a giant state machine.

The worker must not become the release controller

The release boundary is where this matters most.

Codex can open a PR. It can write release notes. It can suggest verification steps. But it should not mark an issue done just because tests passed, and it should not silently take ownership of production release.

PR opened means review has started. PR merged means code has entered the main branch. Production verified is a different state.

If the worker implements the change, decides it is complete, controls release, and closes the issue, the workflow loses audit layers. It becomes hard to tell whether a state transition came from product judgment, engineering judgment, release judgment, or the AI validating its own work.

The manual version is already useful

You do not need a daemon on day one.

You can simulate the boundary manually:

  • A human selects one issue.
  • A human decides the automation mode.
  • A human starts Codex in the repository.
  • Codex works only on that issue.
  • Codex produces evidence.
  • A human reviews the PR.
  • A human decides release and closure.

That is already a stronger workflow than asking AI to “just fix this” in a chat.

The important step is not early automation. The important step is separating responsibility.

When Codex is a worker, it can be very powerful. When it is forced to become the scheduler, reviewer, release controller, and product owner, it becomes a systems risk.