AI coding tools have mostly been discussed as developer assistants: write some code, explain an error, create tests, or help review a change.
That boundary is starting to move.
OpenAI recently introduced its Agents API, giving developers a way to build longer-running agents that can work with files, run code, use tools and coordinate other agents. OpenAI says these agents can continue working for long periods rather than handling only a single prompt-and-response task.
Around the same time, another development caught my attention for a different reason: OpenAI is reportedly using AI as a mandatory security reviewer for its own pull requests. If the review finds a security problem, the merge can be blocked.
That may sound like a small extension of AI code review.
It is not.
It marks a shift from AI helping a developer to AI becoming part of the decision about whether code can move forward.
We already trust automation in CI/CD
There is nothing unusual about software being blocked automatically.
A pull request may already stop because:
- a build failed;
- unit tests failed;
- a security scanner found a vulnerability;
- a required reviewer has not approved the change;
- a policy check did not pass.
So an AI review becoming another gate in the pipeline is not a completely new idea.
The difference is in how the decision is made.
| Signal Category | Execution Mechanism | Evaluation Nature | Enforcement Authority | Override & Exception Path |
|---|---|---|---|---|
| Automated Build & Tests | Deterministic compilation and test runs | Binary pass/fail against defined assertions | Required CI status check blocks merge | Requires code modification or test suite amendment |
| Static Analysis (SAST) | Deterministic rule matching against code AST | Scored vulnerability signatures against CVE database | Policy gate blocks if severity exceeds threshold | Documented inline rule exclusion with owner justification |
| AI Code Review Findings | Probabilistic semantic inspection of code diffs | Advisory recommendations, code summaries, and risk flags | Advisory signal; only blocks if bound to repository ruleset | Explicit human reviewer sign-off with audit trail |
| Repository Ruleset Gate | Platform branch protection rules (e.g. GitHub/GitLab) | Deterministic check of all required gate conditions | Sole authoritative barrier preventing git merge | Restricted administrative bypass with compliance logging |
A test normally checks a defined condition. The expected result is known.
An AI reviewer may need to read the code, understand the surrounding logic and decide whether something looks unsafe. That is a more judgement-based decision.
If that judgement can stop a merge, the AI is no longer simply giving advice. It has been given some authority inside the delivery process.
That does not mean AI should approve everything
There is an important distinction here.
Allowing AI to block a suspicious change is not the same as allowing AI to declare a change safe.
If the model spots what looks like an authentication or authorization problem, stopping the pull request and asking for another look can be useful.
But if the model finds nothing, that should not automatically mean:
The code is secure.
It only means that this particular review did not find a problem.
The usual controls – tests, security scanning, code ownership and human review – still have a role.
Governance Principle: AI review produces evaluative findings, not merge authority. A robust CI/CD pipeline uses AI recommendations to inform review decisions without bypassing repository rulesets, required checks, or human accountability.
What happens when the AI gets it wrong?
This is where CI/CD governance becomes important.
Suppose an AI reviewer blocks a pull request, but the engineer knows the finding is a false positive.
There needs to be a clear answer to some very ordinary questions:
Who can override the block?
Does another person need to review the exception?
Is the reason recorded?
Can teams see how often the AI is being overridden?
These controls are not needed because AI is uniquely dangerous. They are needed because any mandatory control needs a way to deal with mistakes.
There is another side to this as well.
If AI starts writing more of the code and another AI reviews it, teams need to be careful not to assume that two AI steps automatically give them independent verification. The systems may still miss the same kinds of problems.
This is where agent governance starts becoming practical
Atlassian is already using the term “governed agent loops” as it builds AI deeper into the software-development lifecycle.
That direction makes sense.
As agents become capable of writing code, running tools, creating pull requests and working across development systems, the question is no longer simply:
What can the agent do?
Teams also need to ask:
What is the agent allowed to decide?
For many organisations, the sensible progression may be gradual:
AI suggests a change.
Then AI prepares a change.
Then AI reviews a change.
Perhaps later, AI is allowed to block certain changes.
Each step gives the system a little more responsibility.
That is very different from immediately allowing an agent to write code, approve it and deploy it.
The important shift
The interesting part of OpenAI’s Agents API is not only that agents can perform longer and more complex work.
The more important shift is what happens when those agents become part of the controls around that work.
AI helping a developer is already familiar.
AI being able to say “this change cannot proceed” is something different.
As AI agents become part of CI/CD pipelines, teams will need to think about authority as carefully as capability.
The question is no longer only whether the AI can do the work.
It is also how much of the decision we are prepared to give it.
To understand how autonomous agentic loops execute bounded tool workflows before reaching production pull requests, read our guide on what AI agents are and how they operate.