OpenAI Deploys AI to Police Its Own Code, Raising Questions About Blind Spots

At OpenAI, artificial intelligence now serves as a gatekeeper for code submissions, with models capable of blocking merges when they spot potential security issues. The company's engineers report that this approach is fundamentally changing how they conduct maintenance work, refactoring, and code review processes.

All pull requests from OpenAI staff members undergo automated security screening, during which an AI model can prevent code from being merged if it identifies a vulnerability. Thibault Sottiaux, who leads OpenAI's Codex team, discussed this system in a recent conversation on The Pragmatic Engineer, noting that the security check is mandatory and operates independently without requiring human enforcement.

Beyond security screening, OpenAI has assigned its models additional responsibilities including code review, regression detection, dependency management, and assistance with modifications that Sottiaux indicates could have previously required months of engineering effort. The company has begun evaluating certain code-review models as performing at a "superhuman" level.

AI reviewers block every merge

OpenAI initiated development of specialized code-review models during the early stages of Codex. In his discussion, Sottiaux outlined how these models could identify logical and reasoning errors that human engineers might need hours to uncover.

When we benchmark them, it's like they're superhuman in code review. This is not just true for correctness. This is also true for security.

Thibault Sottiaux

These capabilities emerged in dedicated review models and have since been incorporated into OpenAI's primary models. For security matters, any flagged concern automatically prevents the merge from proceeding.

Intent replaces inspection

As artificial intelligence assumes greater responsibility for code review mechanics, Sottiaux believes the human contribution may shift to an earlier stage in development.

OpenAI's review, deployment, and regression-detection workflows have become, according to Sottiaux, "pretty much automated." Engineers are able to deploy a pull request on the same day to ChatGPT, which he noted has approximately a billion active users.

Really what we see, and I see, is there's this sort of discussion around the intent that takes place around the pull request. It's like, what are you even trying to do? And is that the right thing to attempt to do?

Thibault Sottiaux

Sottiaux contends that this conversation should take place sooner, during the planning phase rather than in the review queue. Engineers must still align on objectives and evaluate proposed modifications. Transferring review responsibilities to AI does not eliminate human involvement; rather, it relocates the critical assessment to before anyone submits a PR.

Agents tackle maintenance backlogs

While security concerns dominate discussions, routine maintenance may be where engineering teams experience the most immediate impact, particularly with external libraries that introduce breaking changes and remain unaddressed across multiple sprint cycles because feature development always takes precedence. Sottiaux's argument is that with a clear changelog and adequate documentation, an agent can complete these routine updates within a single afternoon, and the same applies to standard security updates.

The same reasoning extends to substantial refactoring efforts. A team might have a precise vision of what requires cleanup and even possess a superior architectural design. However, when the effort estimate reaches two or three months of work, it becomes understandable why teams continue to work around the issue instead. The code may be suboptimal, but it functions, and other priorities always emerge.

This dynamic shifts when an agent can shoulder much of the burden. A refactoring project that would have been shelved because justifying a quarter of engineering time seemed impossible might now require only days instead of months, making it substantially more feasible to approve.

When models outgrow their scaffolding

Sottiaux outlined a pattern in agent development that contrasts with typical software evolution.

Codex included a feature called /goalbuilt designed to maintain a model's concentration on a single task across days or weeks without losing focus. This was a "crutch" (Sottiaux's characterization) to compensate for the model's difficulty sustaining attention on extended tasks, yet more recent models do not require it.

You don't need slash goal anymore. You don't need a harness around it.

Thibault Sottiaux

The Codex team frequently constructs supplementary infrastructure to address model limitations, only to discover that subsequent generations manage the same functionality independently, rendering the previous workarounds obsolete.

Sottiaux indicated the team now incorporates this reality into its strategy, sometimes choosing not to develop a workaround if researchers anticipate the next model will resolve the issue on its own within several months. As models advance, the system prompt and surrounding code can shrink, while features once considered essential may vanish entirely.

The blind spot question

When AI generates code and AI evaluates that code, both systems may harbor identical blind spots. This represents the apparent objection, though Sottiaux's remarks do not comprehensively address it.

OpenAI has sufficient confidence in these models to permit them to reject a pull request, which means their errors carry concrete consequences. If the model proves overly cautious, engineers face delays on code that was actually acceptable. If it overlooks a genuine vulnerability, that code could advance with an automated security check providing false assurance of safety.

The situation becomes more complicated as AI-generated code becomes more prevalent. Code may compile successfully, pass all tests, and still contain problems that are not apparent from the pull request alone. Certain issues may not originate with the code being submitted. When supply chain vulnerabilities become the attack vector, the vulnerability might be a library compromised weeks or months prior, leaving a PR reviewer to identify a problem that started elsewhere.

Code can compile, pass its tests, and still have problems that aren't obvious from the pull request itself.

Source: The New Stack