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.
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.
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.