When an Automated Coding Run Should Make No Changes

Quick answer: A scheduled coding agent should finish without edits when its permitted scope contains no justified improvement. Define that outcome in advance, preserve evidence of what was considered, and distinguish it from missing inputs, failed checks, or exhausted budgets. A schedule creates an opportunity to inspect; it does not create a requirement to change code.

A daily maintenance agent can become a source of daily review work. If its instructions imply that every run must produce a pull request, it has an incentive to keep searching until it finds something that resembles an improvement.

Eventually that may mean renaming a clear variable, rearranging working code, or expanding into a neighboring subsystem. The repository receives activity without a corresponding reduction in maintenance burden.

Design the completion contract around useful outcomes. A documented decision to leave the candidate set unchanged can be a successful inspection.

The maintenance policy and outcome record below are illustrative designs. They have not been run as an automation system.

Give the schedule one narrow job

“Improve the codebase every morning” leaves the agent to invent both the target and the definition of improvement. A more useful assignment might inspect recently changed examples for references to commands that the project has removed.

That example has a discoverable candidate set, a specific defect, and an understandable review boundary. It still requires judgment: an old command may appear intentionally in a migration guide.

Write the task as a contract with a permitted change and a completion condition. Define where the agent may look, what evidence justifies a patch, and when the run should end without one.

GitHub's public Code Simplifier workflow offers a documented example of this approach. As reviewed on 25 September 2026, it uses precomputed inputs, restricts candidate discovery, specifies validation, and provides explicit pull-request or no-op paths. That source describes intended behavior; it is not proof of aggregate reliability or savings. GitHub's Code Simplifier workflow.

Filter candidates before spending judgment

Use ordinary code for rules that ordinary code can decide: eligible directories, changed files, generated-file exclusions, recently examined revisions, and duplicate findings.

Then ask the model to assess the smaller set where interpretation is useful. The candidate generator should retain why each item was selected, so the agent and reviewer can inspect the scope without rediscovering it.

For the fictional documentation task, a policy could look like this:

task: removed-command-references
inputs:
  command_manifest: CURRENT_APPROVED_MANIFEST
  documentation_revision: FULL_COMMIT_ID
candidate_rules:
  include: [docs/tutorials/]
  exclude: [docs/history/, docs/migrations/]
  maximum_files: 12
allowed_change: Correct a demonstrably obsolete command reference.
required_evidence:
  - Reference location and surrounding explanation
  - Current supported replacement from the approved manifest
  - Relevant documentation checks
completion:
  - patch_ready
  - no_useful_change
  - blocked
  - budget_exhausted
  - failed_validation

The cap of 12 is an example, not a recommended universal value. Choose a bound that fits the task and review capacity. A cap also creates an obligation to report deferred work: inspecting the first 12 files does not establish that the rest need no attention.

Select candidates predictably, retain a cursor or backlog where appropriate, and prevent the same early files from starving the rest indefinitely.

Make “no changes” an explainable decision

Several very different runs can leave an empty diff. Give them different outcomes:

Outcome	Meaning	Follow-up
No candidates	The configured filter returned nothing	Record the filter and input revision
No useful change	Eligible candidates were assessed; none justified a patch	Retain brief reasons and scope coverage
Blocked	Required data, tools, or access were unavailable	Name the dependency that prevented assessment
Budget exhausted	Work stopped before the planned assessment finished	Preserve completed and deferred coverage
Failed validation	A proposed patch did not satisfy required checks	Preserve the failure and account for remaining edits
Patch ready	A scoped change has the required evidence	Hand it to the authorized review or delivery process

A process exit code may encode only success or failure. Keep a more descriptive result record alongside it. A scheduler can treat a deliberate no-op as a healthy execution while still surfacing blocked work and repeated budget exhaustion.

Do not let the label conceal the state of the checkout. If a failed attempt left edits behind, say exactly which files remain changed. An empty public pull-request list does not prove that the worker restored its workspace.

Require a reason to create review work

Before producing a patch, ask whether it fixes an identifiable problem inside the approved scope. “I prefer this style” is insufficient unless the task is explicitly a style migration with an agreed rule.

For the documentation example, a justified patch needs both the obsolete reference and a supported replacement. A suspected mismatch without an authoritative replacement should become a finding or blocked item, depending on the task contract.

Keep the acceptance rule stable during the run. If the required checker fails, the agent should not remove the check, broaden the allowed files, or relabel the result to reach a success state.

Link each check to the candidate it examined. The release verification guide describes how source identity and evidence can remain connected through later steps.

Discovery does not expand the permitted action

An agent checking documentation may discover a broken build script. That finding can be useful without authorizing a build-system rewrite.

Record the finding and continue within the existing task if possible. If the defect prevents a meaningful assessment, report it as a blocker. Change the scope through the established approval process rather than treating the diagnosis as permission.

OpenAI's agent guidance distinguishes automatic validation from human approval and places controls around tool calls that create side effects. Its scope-review guidance supports checking the proposed action before execution. These controls belong in the surrounding system; a written task alone does not enforce them. OpenAI guardrails and human review.

Use tools and credentials with only the access this maintenance task needs. GitHub's security guidance likewise recommends minimum necessary credential privileges. GitHub secure use reference.

Measure useful coverage as well as restraint

A high no-op rate can mean the code is in good shape. It can also mean the filter is broken, the task is poorly defined, or the agent lacks necessary context.

Track candidate counts, inspected counts, deferred counts, outcome reasons, validation failures, review time, and accepted patches. Periodically inspect a sample of no-op decisions. The purpose is to check the quality of restraint without creating a quota for changes.

A compact final record might say: “Inspected 8 of 8 eligible files at revision X. Three historical references were intentional; five matched supported commands. No patch justified. No remaining edits.” That is a fictional example of an auditable result, not a report from a real run.

Make limits visible in the tool contracts as well as the task instructions. Then the next scheduled run can begin from an honest account of what happened, whether the previous run produced a patch or left the repository exactly as it found it.