Delegate one bug to a coding agent: from plan to a reviewable repair

You delegated one bug

Reloading a list changes the order of rows with the same timestamp. An engineer delegates the fix to a coding agent and returns to other work, then receives a large diff including a database schema change. This is a hypothetical design example. A passing-test notification leaves work behind if the engineer must investigate why the change was necessary and how it resolved the original defect.

This article follows that task through investigation, planning, execution, intervention, and acceptance using material published by OpenAI, Anthropic, GitHub, Google, and AWS by April 13, 2026. It does not rank products measured on the same task. Alongside code-generation capability, compare what progresses while the engineer is away and what can be decided on return.

My judgment is to assess repair capability together with the design that makes the work usable by its owner. Connecting opportunities to redirect work, visible execution boundaries, and evidence that the change answers the request can support broader delegation. Running for a long time is not itself evidence that the job is resolved.

Interactive repairs and work that progresses while you are away

OpenAI's February 2 Codex app announcement presents project-organized tasks, diff review, and worktrees that provide separate working copies. Its interface helps people oversee multiple tasks and return where needed. It also describes skills for extending procedures, without establishing that every task in the app executes in the cloud.

The February 12 Codex-Spark announcement introduces a research preview for iterating on targeted changes interactively. Its default working style does not run tests automatically unless requested. Rapid editing and returning a verified fix need separate assessment.

Google's May 2025 Jules announcement describes cloning code into a cloud VM, working asynchronously, and returning plans and diffs. Its August public launch also describes reusing previous environment setups. Product-managed preparation provides a comparison with interactive work on the engineer's machine.

For one localized list change checked immediately on screen, short interactive exchanges remain a candidate. Background execution may help when investigation, dependency installation, and relevant tests take longer. Include waiting and rework if the environment cannot subsequently be reproduced and validation must start again.

Plans need enough detail to judge the size of a change

GitHub's April 1 update describes Copilot cloud agent working on a branch without creating a PR and producing a plan before code when requested. People can approve or amend the approach, inspect the diff, and then create a PR. Research-only sessions also separate completing an investigation from publishing code.

In the hypothetical task, reproduce ordering with equal timestamps and investigate presentation logic versus ordering during retrieval. If existing identifiers can resolve ties, ask why a schema change is needed. Do not exclude a necessary database-query change; connect the cause with the proposed scope.

“Fix sorting and test it” gives little basis for recognizing an excessive change. Reproduction conditions, affected areas, and a definition of success help the engineer redirect implementation before it begins. Jules also describes changing plans before and during execution, but visibility alone does not establish mandatory explicit approval in every configuration. Check start and stop conditions in the configuration actually used.

Separate branch history from executable access

A Git branch separates change history. A worktree creates another working copy, and a VM separates the place commands execute. Collapsing them into “isolation” encourages assuming that separate history also prevents network or credential use. Supplying production credentials requires separately examining paths to external services.

Anthropic's March 25 auto mode explanation describes warnings for retrieved content and a classifier for executable actions. Allowlisted operations and edits within the project can bypass that classifier. Model judgments retain errors; this is not a fixed boundary applying the same inspection to every operation.

The Codex app announcement also describes configurable sandboxing and permissions. For the list repair, consider repository and test-environment access separately from authority to change production data. Writing “do not change the schema,” reviewing a plan, and restricting connectivity serve different purposes. Inspect the relevant files, destinations, and operations concretely.

Give verification a running application and criteria

Anthropic's March 24 long-running development report separates planner, generator, and evaluator roles, agreeing on completion criteria for chunks before implementation. The evaluator exercises the application through Playwright and reports defects such as rectangle filling affecting only drag endpoints. This concretely distinguishes a function existing in code from its being usable on screen.

Compared runs also differ in duration, cost, and the feature scope expanded by planning. The report does not measure three roles making every repair cheaper, faster, and more accurate. A separate evaluator can still miss a mistake if both roles adopt the same incorrect specification.

For the list repair, define expected behavior with equal timestamps, reloads, page navigation, and existing sorting controls. Exercise the screen with fixed data alongside code inspection. Whether one test suffices or another person or evaluator is needed depends on change scope and the consequences of missed errors.

When dividing investigation, implementation, and verification among specialized agents, return more than short conclusions: include revision, reproduction conditions, executed checks, and unknowns. A test passing on another working copy does not establish the integrated diff passes. Recheck what the combined change affects and include handoff effort when judging specialization.

The receiving engineer has five different questions

This is the article's organization of the evidence an engineer needs, not five guarantees automatically supplied by a product. Even a small change can briefly show the original defect and checked outcome. The purpose is to make decision-relevant information findable, rather than require reading every log.

GitHub's persistent signature-verification announcement describes retaining verification records associated with commits. A Verified badge does not decide whether list ordering is correct. Diff and behavior review remain necessary after checking origin.

Its April 10 Copilot update describes parallel CodeQL, dependency vulnerability checks, secret scanning, and code review, claiming 20% shorter validation time. This concerns its validation tools, not a measured 20% reduction across implementation and human review. These checks and the list's expected-behavior test detect different problems.

Returning to work differs from reversing execution

The April 1 GitHub Mobile update covers session logs, PR creation and review, and stopping execution. The April 13 CLI remote-control public preview supports messages and permission decisions from another device for a session running on the original machine. Their availability conditions differ; remote control does not relocate execution to the cloud.

If investigation turns toward a schema change in the hypothetical task, the engineer can ask why and adjust scope. Stopping does not establish that completed file changes or external operations were reversed. Inspect progress and remaining work before deciding how to continue.

Reopening a session, resuming conversation, and restoring work in another execution environment are also different capabilities. Check revision, amended plan, and incomplete tests before continuing. Remote supervision gains value from reaching relevant evidence at the right point, rather than from notification volume.

Operational investigation changes what a diff means

AWS's March 31 DevOps Agent general availability announcement describes investigating problems across observability, runbooks, code, CI/CD, and deployment information. This extends product support for examining operational events before proposing a code repair. The article does not measure fully autonomous incident response or shorter recovery time.

If the list defect appeared immediately after deployment, dependencies, configuration, and retrieved-data conditions may deserve investigation alongside changed code. Temporal proximity alone does not establish causation. Pass observations leading to a repair candidate separately from unverified hypotheses.

The engineer needs more than “the database is the cause.” Knowing which logs and revision were inspected, what was reproduced, and which proposed change can be tested enables the next action. Broader operational access also requires separating investigative reads from authority to change shared systems.

Compare through acceptance in the same repository

Anthropic's February 5 experiment report compares six resource configurations with the same Claude model, harness, and Terminal-Bench 2.0 tasks. Success differs by six percentage points between strict limits and uncapped resources. Its explanation includes fewer infrastructure failures and enabling more resource-intensive strategies. The magnitude cannot be transferred to every model or internal repair task.

For an internal trial, match defect, repository revision, dependencies, time and spending caps, and executable permissions. Record investigation, plan intervention, diff review, and repeated validation alongside turnaround time. Include corrections and failed dependency installation rather than selecting only a successful demonstration.

To compare models, match execution environments and procedures where possible. To select products, also record differences in setup and intervention, evaluating total time and acceptable outcomes. Mixing these questions prevents attributing a single score solely to model quality.

For the hypothetical list repair, acceptance requires the original defect no longer reproducing, related checks passing, and understanding remaining uncertainty. Test names, revision, results, and reasons for unexecuted checks show the verified scope. This is a trial proposal, not results from testing every product under these conditions.

Let the engineer take over from the right point

Public material shows planning, execution environments, diffs, intervention, and behavioral verification being incorporated alongside code generation. I read these as designs for delegating work under human supervision. This does not imply identical guarantees across products or that model repair capability has become unimportant.

Delegate one defect, correct direction when needed, and receive the change with supporting evidence. Broaden delegation from the scope where that sequence works. A coding agent's value includes letting the engineer choose what to accept and what to continue without restarting the entire investigation.