Automating Code Maintenance Without Removing Rare Safeguards

A cleanup agent can remove code that never runs and still remove something the service needs. The difficult case is a safeguard kept for an incident that ordinary production traffic has never exercised.

Rodrigo Roim's October 14 engineering account from OpenAI describes using Codex to investigate unused code, stale experiments and maintenance of automated software checks. The account makes a useful distinction: evidence that something is inactive is not necessarily authority to remove it.

Roim describes agents consulting project history, discussions, live feature configuration and production profiles. The stale-experiment prompt asks for small draft pull requests, preservation of operational safeguards and checks for indirect consumers. A later audit prompt explicitly forbids changes to live configurations or services. Finding a candidate and changing the running system are separate actions in this account.

The revealing example is a feature flag, a switch controlling application behavior, that let internal developers override other flags. Its mapping created expensive work, but it was marked permanent and might still have an operational purpose. The agent raised it for human review. Roim says the team subsequently removed it after review. Evidence that a flag is costly did not by itself settle whether its purpose could be retired.

Consider a hypothetical banking agent that processes routine supplier payments within approved limits. Its workflow pauses a payment if the supplier's bank details have changed and routes that exception for review. An agent improving the workflow notices that this check has never triggered and proposes removing it to simplify processing.

The quiet history does not mean the check is unnecessary. It means the triggering situation has not been observed. Removing it could let a payment go to a changed account without the required review. The improvement agent can simplify routine processing, but it cannot treat an unused exception rule as an expired one.

For WTK, the intended destination is humans governing objectives, boundaries and exceptions while routine factory work proceeds within delegated authority. That does not require a person to approve every cleanup. It requires a policy that says which changes may proceed, which behaviors must remain available and when missing evidence stops the automatic path.

Our proposed maintenance policy would distinguish evidence of inactivity from evidence that a responsibility has ended. A candidate would need an explanation tied to the affected version, the systems that depend on it and the behavior the change must preserve. A conflict between activity records and an operational designation would become an exception under that policy. Those are proposed requirements, not controls this note establishes as implemented in WTK.

This extends our feedback record, which leaves autonomous promotion unproven, with a particular maintenance question: who can retire an obligation that normal execution does not reveal? Our workflow revision note asks whether permitted repairs can finish. Cleanup adds the question of whether the resulting system still retains the required exceptional behavior.

OpenAI's described workflow includes human code review. It does not demonstrate WTK's proposed automatic maintenance path, and we have not evaluated that path. The account also leaves some detailed prompt instructions unpublished and acknowledges proposals whose complexity outweighed their expected benefit. Under WTK's research method, this is a design question for further review, not an established WTK maintenance result.