OpenAI GPT-6 Code Maintenance Moves Agents From Writing Features to Deleting Them

OpenAI says GPT-6 models helped five engineers merge more than 1,400 maintenance pull requests, despite starting with requests too ambiguous for earlier models. The OpenAI GPT-6 code maintenance effort removed over 800,000 lines while the engineers continued working on other projects. It also exposed a harder problem: finding deletions is easier than proving those deletions are safe.

The company’s Core Experimentation team used GPT-6 Astra and GPT-6.1 Sol through Codex, OpenAI’s agentic software development environment. The models investigated unused code, stale experiments, flaky tests, and continuous integration bottlenecks. Instead of stopping at repository search, they consulted project history, internal discussions, configuration data, and production telemetry.

That changes the contest from AI-generated code against human-written code to agentic investigation against deterministic maintenance systems. Static analysis remains useful, but it often lacks the organizational context needed to explain whether an apparently dead path is obsolete, dynamically invoked, or retained as an emergency safeguard.

The results are substantial, but they come from an internal OpenAI case study rather than an independent benchmark. Engineers reviewed the proposals, rejected work that did not justify its complexity, and manually examined findings with operational consequences. The story is therefore less about autonomous software repair than about turning neglected maintenance into reviewable work.

OpenAI GPT-6 Code Maintenance Started With a Deliberately Vague Request

The notable change was not that GPT-6 could edit code, but that it could assemble evidence before proposing what to remove.

OpenAI engineer Rodrigo Roim described the workflow in an October 14 software maintenance report. His Core Experimentation team maintains systems supporting experiments across OpenAI, including front-end work and model-serving efficiency projects.

Before GPT-6, the team used GPT-5.6 Sol to create targeted static analysis and remove dead code. A developer could identify an area, specify validation criteria, and let the model implement an analyzer. Roim says those prompts were easier to maintain than existing static analysis systems while delivering similar reliability.

That method still placed most investigative decisions in the prompt. Engineers had to decide where the model should look, what counted as evidence, and which conditions made deletion acceptable. The agent could execute a defined investigation, but it could not consistently construct the investigation from a broad request.

The team tested GPT-6 Astra with a looser instruction. It asked Codex to identify and clean up dead code while consulting sources such as Slack, Statsig, or anything else needed to verify that the code was no longer used. Statsig is the feature flag and experimentation platform involved in the team’s workflow.

Astra reportedly searched past pull requests, internal project trackers, and Slack discussions. It also checked production performance profiles to determine whether candidate lines were reached. The model then documented its reasoning for each deletion so reviewers could inspect the supporting evidence.

That distinction matters. A repository rarely contains a complete explanation of why code exists. A dormant branch might support an incident response process. A constant flag might be a kill switch. Reflection can hide a runtime dependency from static analysis, while generated names can obscure references across services.

Five engineers eventually ran variations of the cleanup prompt across repositories. OpenAI says they merged more than 1,400 pull requests and removed over 800,000 lines, with most of the work conducted part-time over two weeks. Reviews were distributed to teams familiar with the affected projects.

One service’s container image reportedly fell from 3.31GB to 1.72GB, a 48 percent reduction. Another cleanup removed roughly 400 visual snapshot variants from the test suite. These outcomes suggest the work reached build artifacts and test infrastructure, not only formatting or local refactoring.

The scale does not establish that every deletion created equal value. It does show that an agent can convert a broad maintenance goal into many small review units. That makes accumulated cleanup work visible enough for engineering teams to evaluate.

The Pressure Falls on Deterministic Maintenance Systems

GPT-6 challenges workflows that treat source code as the only reliable record of whether software remains necessary.

Traditional analyzers excel when teams can define a stable rule. They can find unreachable statements, unused imports, dependency cycles, and other patterns encoded in syntax or program structure. Their output is repeatable, relatively inexpensive to rerun, and often easy to integrate into continuous integration.

Large production systems introduce exceptions that a rule cannot evaluate in isolation. A code path might be activated only during an incident. A feature gate can depend on remote configuration. A string may be assembled dynamically before another service consumes it. An apparently constant experiment might still represent a contractual or operational safeguard.

OpenAI’s workflow applies an agent to that uncertain layer. The model searches several systems, creates a case for removal, and turns the case into a draft change. It is closer to delegated investigation than an enhanced linter.

This puts pressure on engineering organizations that keep critical context in disconnected systems. When design intent sits in chat, ownership information lives in project trackers, and production behavior appears only in observability tools, humans must reconstruct the record before approving a cleanup.

An agent can reduce that reconstruction cost if it has authorized access to each source. That condition is significant. A coding model without the relevant discussions, telemetry, or configuration state cannot reason its way around missing evidence. Higher reasoning effort does not grant missing access.

The same issue appears across the coding-agent market. GitHub Copilot, Claude Code, and other agentic development products increasingly compete on their ability to navigate repositories and complete multi-step tasks. OpenAI’s example pushes the target further by treating organizational evidence as part of the software environment.

That creates a new infrastructure requirement. Teams need searchable records, consistent permissions, and sufficiently durable explanations of important decisions. An agent cannot reliably recover a rationale that was never documented or retained.

This is where an engineering knowledge base becomes relevant. The purpose is not to let an AI make final deletion decisions. It is to make supporting documents, specifications, and previous conclusions available during investigation.

The broader GPT-6 guidance reinforces this access requirement. OpenAI’s model usage guide recommends GPT-6.1 Sol for complex coding and professional work when users want performance near Astra at lower cost. Yet model choice cannot compensate for incomplete context or unavailable tools.

Deterministic analysis will not disappear. It remains a useful source of evidence and a valuable validation layer. The pressure is on systems that stop after producing a candidate list, leaving engineers to gather every piece of operational context manually.

The Real Advantage Is Evidence Gathering, Not Code Generation

The mechanism behind the results is a loop of discovery, evidence collection, review, and prompt revision.

The stale-experiment work demonstrates this mechanism more clearly than ordinary dead-code removal. Stale experiments may still execute in production even when their business decision has already been settled. Eligibility rules can also change which users encounter a branch, making simple runtime counts misleading.

OpenAI previously combined deterministic analysis with database queries for this task. GPT-5.6 Sol helped the team create and improve the scripts. Roim says the approach still produced false negatives because the system could not identify every experiment that had become obsolete.

Astra received a prompt asking it to locate substantial code associated with stale or abandoned experiments in selected projects. The prompt required the model to verify live Statsig configuration, inspect Git history, check overlapping pull requests, and preserve safeguards or kill switches.

The model produced small draft pull requests with evidence for review. Roim then commented on those proposals and asked Astra to incorporate the feedback into a wider audit. In other words, the review process did not only accept or reject code. It generated better instructions for the next investigative pass.

Astra subsequently created a broader prompt covering constant gates, shipped experiments, wrappers, aliases, schemas, dynamically assembled names, and cross-service consumers. The instructions also asked for production telemetry and CPU profiles when available. The requested output was a report organized into parallel workstreams, not immediate production changes.

That separation is important. Discovery can cover a broad surface, while modification remains narrow and reviewable. The agent first creates an inventory, then humans decide which findings deserve implementation.

The audit surfaced experiments that had escaped prior cleanup for years. OpenAI says the team removed hundreds of experiments and feature flags after validating the findings. Some of the highest-priority results were tied to measurable compute costs.

One case involved an internal flag that allowed developers to override many feature flags for testing. A single Python mapping connected it to a broad set of features. The line looked similar to hundreds of other mappings, but it reportedly caused extensive CPU fan-out because it affected every linked feature.

Astra found the CPU impact but did not simply remove the flag. It raised the case for human review because the configuration was marked as permanent and might still have served an operational purpose. After review, the team removed it and estimated a 0.42 percent CPU saving in the main affected service.

This is the strongest example in the case study because it combines technical discovery with restraint. The model found a likely optimization, recognized contradictory evidence, and escalated the decision. The value came from making a difficult judgment legible, not from maximizing deletion volume.

OpenAI’s separate guidance on skills and prompts offers a related warning. Instructions created for earlier agents can become unnecessary or counterproductive as models improve. Excessive scaffolding can consume context and push an agent toward outdated behavior.

The maintenance workflow therefore depends on continuous prompt revision. Teams observe where a model misses evidence, adjust the instructions, and retest. A prompt is not a permanent policy. It is part of an evolving control system that must change with models, repositories, and operational practices.

GPT-6.1 Sol Changes the Economics, but It Misses More Edge Cases

The model comparison presents a practical tradeoff between investigation depth and the cost of reviewing incomplete results.

OpenAI tested GPT-6 Astra and GPT-6.1 Sol on the same stale-experiment workflow. The evaluated repository areas contained more than 6,000 files and one million lines across Python, TypeScript, Go, and Rust.

Astra at Ultra effort produced 142 accepted findings. GPT-6.1 Sol at Ultra produced 131, while Sol at Medium produced 86. OpenAI reports that Sol Ultra delivered 92 percent as many findings as Astra Ultra while consuming 14 percent of the API cost.

Those figures make GPT-6.1 Sol attractive for wide maintenance sweeps. A team can use a more economical configuration to search many directories, then reserve Astra for ambiguous findings or high-risk services. That creates a model-routing strategy based on the consequence of missing an issue.

The comparison also shows why a cheaper run is not automatically equivalent. OpenAI found that Astra detected constant feature flags used as dependencies by other flags, while Sol missed many of them. That is precisely the kind of indirect relationship that makes stale configuration difficult to identify.

The difference may be addressed through better prompts. Once engineers recognize a recurring failure pattern, they can instruct Sol to search for that relationship explicitly. OpenAI says such prompt changes can move the lower-cost model closer to the more capable model’s results.

That solution carries its own maintenance burden. A corrective instruction can become obsolete after a model update. It can also create unnecessary work if applied to repositories without the same patterns. Teams need to revisit both prompts and validation rules when changing models.

OpenAI’s Astra launch overview describes the model as designed for demanding software engineering, browsing, and computer-use tasks. Its practical advantage in this case was not a benchmark score. It was the ability to follow dependencies across heterogeneous evidence without requiring every step to be specified in advance.

Sol offers a different operational value. It can make repeated repository audits affordable enough to run as a routine maintenance process. The remaining question is whether the savings survive the downstream cost of validating weaker findings or recovering omissions.

A team that measures only accepted pull requests might miss that cost. Engineers also spend time reviewing rejected proposals, investigating false positives, refining prompts, and confirming that an agent did not overlook a protected dependency.

The case study does not provide review-hour totals, false-positive rates, rollback counts, or production incident data. It also does not report the output of a comparable human-only process over the same repository areas. Those missing measurements limit conclusions about total productivity.

The evidence supports a narrower finding. Sol can reproduce much of Astra’s accepted output on this internal task at lower model cost, while Astra retains an advantage on indirect dependencies. Organizations must decide whether those missed edge cases matter enough to justify a more capable model.

Human Review Remains the Boundary Between a Proposal and a Safe Deletion

OpenAI’s own results do not support unattended cleanup across a large production codebase.

Every major outcome in the report includes a validation step. Engineers reviewed pull requests, distributed them to knowledgeable teams, manually checked high-value CPU findings, and preserved operational safeguards unless their removal was justified.

OpenAI also acknowledges that some proposals added more complexity than their expected benefit warranted. An optimization can be technically correct yet still impose maintenance costs through extra abstractions, tests, or configuration. The agent’s ability to find a change does not establish that the change should be merged.

Deletion introduces asymmetric risks. The benefit might be a smaller image, a faster test, or reduced CPU use. The downside can include an incident path that fails only under rare conditions. Historical execution data helps, but it cannot guarantee that a path will never become necessary.

Permissions create another boundary. The prompt in OpenAI’s example allowed Astra to inspect internal conversations, trackers, profiles, and live configuration. Many companies would restrict an agent from viewing some of those systems or combining their contents.

A secure implementation needs least-privilege access, audit logs, data retention controls, and clear ownership for generated proposals. These controls are not incidental deployment details. They determine which evidence the agent can legally and safely collect.

Review quality also depends on the presentation of evidence. A pull request with a concise account of call sites, configuration values, production observations, and preserved safeguards is easier to assess than a large deletion with a confident summary. The agent should expose uncertainty rather than conceal it.

The Core Experimentation team’s use of small draft pull requests provides a useful pattern. A draft creates a clear boundary between recommendation and approval. It also gives reviewers a concrete change against which they can test the agent’s evidence.

Long-running maintenance work benefits from explicit completion criteria. OpenAI’s Codex goals workflow frames a goal around an objective and a verification surface, such as a test, benchmark, report, or command output. That structure helps prevent an agent from treating activity as completion.

For cleanup, the verification surface might include a build, targeted tests, dependency searches, runtime profiles, configuration state, and approval from the owning team. Different repositories need different combinations. A passing unit test alone cannot validate a rarely used operational path.

The internal evidence also leaves open the question of generalization. OpenAI develops the models, operates Codex, and employs engineers familiar with how those systems behave. Its repositories may have instrumentation, documentation, and internal tooling that other organizations lack.

Teams with fragmented telemetry or unclear ownership may receive weaker proposals. Legacy systems can also rely on undocumented integrations that no agent or analyzer can see. The right response is not to reject agentic maintenance, but to begin where evidence is strongest and consequences are limited.

Three Signals Will Show Whether Agentic Maintenance Becomes Routine

The next test is whether other engineering teams can repeat these results with measurable safety, predictable review effort, and less specialized infrastructure.

The first signal is independent replication. Companies need to publish results that include accepted findings, false positives, review hours, escaped defects, and rollbacks. Large deletion totals are easy to communicate, but they do not capture the full cost or safety of a maintenance program.

Replication would strengthen OpenAI’s case if teams using different repositories and observability stacks report similar gains. It would weaken the case if agents require extensive internal customization or shift too much work into manual verification.

The second signal is better evaluation of indirect dependencies. OpenAI’s comparison found that Sol missed some constant feature flags used by other flags. Future model releases, repository benchmarks, or prompt techniques should show whether agents can identify these relationships consistently without narrowly tailored instructions.

Progress should be measured against realistic repository states. Tests need dynamic configuration, cross-service references, generated names, incident-only paths, and intentionally permanent controls. Simple dead-code benchmarks will not represent the decisions that made OpenAI’s experiment interesting.

The third signal is integration with routine engineering controls. Agentic cleanup becomes durable when it fits established ownership, review, security, and deployment processes. Draft pull requests, auditable evidence, scoped access, and measured post-merge outcomes should become standard features rather than custom prompt instructions.

OpenAI has already suggested additional applications. GPT-6.1 Sol Medium was prompted to inspect recent continuous integration runs, find flaky tests, attempt clear fixes, and open pull requests. Another prompt asked Codex to identify ways to reduce daily CI minutes based on repository history.

The team says about 30 CI optimization pull requests helped reduce median completion time from roughly 10 minutes to 4.5 minutes. The 90th percentile fell from 12.5 minutes to six minutes. A later change added a missing mock and reduced a 63-test resolver suite from 592.6 seconds to 29.8 seconds, while retaining all tests.

These results extend OpenAI GPT-6 code maintenance beyond deletion. The common mechanism is evidence-based investigation: inspect historical runs, estimate impact, propose a bounded change, and verify the result. That loop can address flaky tests, excessive CI work, stale instructions, and inefficient configuration.

The practical starting point is deliberately small. Select one unused component, stale flag, flaky test, or slow test group. Require the agent to gather evidence and prepare a draft proposal. Compare models and reasoning settings on the same task, then measure both accepted output and reviewer effort.

If the process works, expand to a directory or clearly owned service. Feed review findings into the next prompt, but keep the evidence requirements explicit. Whole-repository audits should follow successful smaller trials, not replace them.

The larger question is no longer whether coding agents can add more software. They clearly can. The harder question is whether they can help teams remove yesterday’s decisions without erasing tomorrow’s safeguards.

OpenAI’s case study offers a credible starting point, not a final answer. What maintenance task in your codebase already has enough tests, telemetry, ownership, and historical context for a small agent-assisted audit? That bounded experiment will reveal more than a sweeping automation mandate, especially if you track review time and rejected proposals alongside merged changes.