Protecting Critical Code in the Age of AI

AI has changed the shape of software delivery, but not in the simple way people often describe it.

The easy version of the story is that developers can now write code faster. That is true, but it misses the more important shift. Code itself is no longer the scarce part of engineering. Trust is.

A developer can now ask an AI agent to generate a feature, refactor a module, update tests, rewrite documentation, and open a pull request in the same morning. The output often looks polished. The naming is reasonable. The structure is familiar. The tests may even pass. That is exactly why the review stage has become more important, not less.

The new danger is not only bad code. Bad code is often obvious. The harder problem is plausible code: code that looks right, compiles cleanly, passes the happy path, and quietly changes behaviour nobody meant to change.

As Addy Osmani writes in his excellent article on agentic code review, “Writing got cheap, understanding didn’t.” That line gets to the heart of the problem. AI has made it dramatically easier to produce code, but it has not made it dramatically easier for a team to understand whether that code should be trusted, whether it belongs in the system, whether the right people have reviewed it, or whether somebody is accountable for the change once it reaches production.

For Bitbucket teams, this shift lands directly in the pull request workflow. The pull request is no longer just a collaboration tool. It is the point where machine-speed output is either converted into controlled engineering change, or allowed to flow into the codebase with too little human ownership.

That is where the human in the loop matters.

Not as a person reading every line of every AI-assisted pull request. That model will not scale. The human in the loop now needs to be more deliberate than that. Humans need to own the high-stakes gates, the accountability, and the judgment of whether the change was the right thing to build in the first place.

The Old Review Model Was Built for Human-Speed Output

For years, code review relied on a simple assumption: humans could review code slightly faster as other humans could write it, but not order-of-magnitude faster.

That assumption is starting to break.

When developers use AI to make larger changes in faster iterations the pull request review queue grows faster than the team’s review capacity. Confronted with much higher pull request review demand, most teams do not consciously decide to lower their standards. They drift into it. A pull request looks harmless. A reviewer is busy. The tests are green. Someone approves. Someone merges. The team moves on.

Until production reminds them that “green” and “understood” are not the same thing.

The concern is not theoretical. Faros AI’s 2026 Acceleration Whiplash report describes the downstream pressure created by AI-assisted development, including larger pull requests, 5x median review time, 3x incidents per pull request, and 10x code churn. Their related analysis also notes that pull requests merged without review are up 31.3%, suggesting that review systems are struggling to keep up with the volume of code entering the pipeline.

This is where the conversation about “human in the loop” often becomes confusing. Some people imagine a senior engineer reading every line of every AI-assisted pull request forever. That is not realistic. Others hear “AI code review” and assume the answer is to let agents write the code, let agents review the code, and let the pipeline ship the code. That is not governance. It is a self-validating loop in which AI-generated code is approved by other automated systems without meaningful human accountability..

The answer is more deliberate than either extreme. Machines should handle the checks they are good at. Humans should own the judgments only humans can make. The review system should know the difference.

AI Review Is Useful, but It Is Not Ownership

One of the strongest ideas in Osmani’s article is the case for heterogeneous AI review. Different AI review tools catch different classes of problems. A tool like CodeRabbit, Greptile, Seer, or another AI reviewer may find issues that another reviewer misses, and teams can benefit from using more than one style of automated review.

That is a good direction. It recognises that AI can be a useful sensor in the review process. It can flag suspicious logic, missing tests, risky patterns, inconsistent style, or possible security issues before a human spends time on the pull request.

But a sensor is not the same thing as an accountable owner.

An AI reviewer can say, “This looks good,” but it cannot take responsibility when something goes wrong. It does not understand your customer commitments, regulatory context, release obligations, internal architecture history, or the long-term maintenance cost of a change in the same way an experienced team member can.

This is the uncomfortable but necessary distinction. AI review can scale checking. Human review still owns judgment.

For Bitbucket teams, the practical question becomes: how do you make sure the right human judgment happens in the right places, without forcing every person to manually inspect every change?

The Real Risk Is Uncontrolled Change in the Wrong Files

Not every file in a repository carries the same risk.

A small documentation edit is not the same as a change to a deployment pipeline. A UI copy change is not the same as a change to authentication logic. A harmless refactor in a low-risk module is not the same as a change to infrastructure configuration, permissions, release scripts, billing rules, compliance workflows, or customer data handling.

This matters because AI does not naturally know which files are politically, operationally, or commercially sensitive inside your organisation. It may understand code structure, but it does not automatically understand your blast radius. It does not know that a certain YAML file controls production deployment, that a particular folder contains validated workflow logic, or that a small-looking config change could impact every customer.

That is where many teams need to think more carefully. The question is not just “can AI produce a good diff?” The question is “which parts of the repository should AI never be able to change uncontrolled?”

For many companies, that list might include files such as:

• CI/CD pipeline configuration
• Infrastructure-as-code files
• Deployment scripts
• Security and permission configuration
• Authentication and authorisation logic
• Database migration scripts
• Billing, payment, or licensing logic
• Regulated workflow code
• Critical assets or configuration used by customers

These are not files where “someone approved it” is always enough. These are files where the organisation may need a specific person, team, or group to review and approve the change before it can be merged.

No tool can honestly promise that AI will never generate a change to those files. AI can suggest anything. A developer can commit anything. But a strong pull request workflow can make sure those changes do not enter protected branches unless the right human gate has been satisfied.

That is the difference between hoping humans stay in the loop and enforcing that they do.

Workzone Turns “The Right Human Should Review This” Into a Merge Rule

Workzone for Bitbucket is built around a simple idea: pull request rules should match how your team actually works.

Not every repository has the same risk. Not every branch has the same purpose. Not every file path needs the same diligence when reviewing. Not every missing human approval should block a merge. In an AI-assisted development environment, these distinctions become much more important.

With Workzone’s reviewer and approval configuration, teams can define review rules based on branch patterns, file or module patterns, reviewer users, reviewer groups, and approval quotas. This means review ownership can be tied to the actual area of code being changed, rather than relying on a generic approval count across the entire repository.

For example, a Bitbucket team could configure rules so that changes under src/ui/** require approval from the UI team, changes under src/main/** require approval from backend reviewers, and changes under src/test/** require QA involvement. For more sensitive paths, such as deployment configuration, security or regulated workflow code, the team can require approval from specific mandatory reviewers or reviewer groups before the pull request can be merged.

This is where Workzone becomes especially relevant in the AI era. It gives teams a way to say: “AI can help write code, but changes to this part of the system must still pass through these humans.”

That is a much stronger control than hoping someone notices a risky file in a large AI-generated diff.

This turns sensitive file protection from a manual habit into an enforced gate.

Humans in the loop are enforced by assigning true ownership to critical assets. Instead of relying on reviewers to spot every risky file in a large AI-assisted pull request, Workzone can enforce that changes matching certain paths must receive approval from the responsible people or groups. The AI can still propose the change. A developer can still commit the change. But the pull request cannot satisfy the Workzone merge requirements until the configured human review gate has been met.

That is the kind of control teams need when AI-assisted development becomes normal.

Independent Review Matters More When Authorship Gets Messy

AI also makes authorship messier.

A pull request may include code written by a developer, generated by an AI agent, modified by another teammate, and adjusted again after the first review. Someone might approve a pull request and later add a commit to the same branch. Another person might make a small change after the approval quota has already been met.

In low-risk situations, this may be acceptable. In compliance-sensitive or high-risk workflows, it creates a problem. If someone contributed to the change, should their approval still count as independent review?

Workzone’s Ignore approvals from committers feature helps teams handle this. When enabled, approvals from users who contributed commits to the pull request are not counted toward the configured Workzone approval quota. The approval remains visible in Bitbucket, but Workzone excludes it when evaluating whether the pull request has enough valid approvals to be merged.

That distinction is important because approval and independent approval are not the same thing.

If your process depends on independent human review, your tooling needs to understand when an approver has also become a contributor. Otherwise, the pull request may look approved while the independence behind that approval has quietly disappeared.

Automation Should Accelerate the Safe Path, Not Remove Accountability

There is nothing wrong with automation in code review. In fact, teams need more of it.

Linters, tests, build checks, AI review agents, security scanners, and merge automation all have a role to play. The goal is not to slow teams down. The goal is to stop wasting human attention on checks that machines can perform reliably, so humans can focus on the decisions that require context, ownership, and accountability.

Workzone supports this through branch configurations and merge control. Teams can require successful builds, no unresolved tasks, no requested changes, reviewer approvals, group quotas, mandatory approvals, digital signatures, and other merge conditions before a pull request can be merged.

This may sound like removing humans from the loop. In practice, it is the opposite.

The human judgment happens when the rules are designed. The system then enforces those rules consistently.

That is the difference between automation and abdication. Automation says, “We know what good looks like, and the system can enforce it.” Abdication says, “The system said yes, so nobody has to think.”

Modern Bitbucket teams need the first, not the second.

Some Changes Need a Signature, Not Just an Approval

For many teams, a normal approval is enough. For others, especially teams working in regulated industries or high-risk environments, approval needs to be more explicit and traceable.

If a change affects a regulated workflow, medical device software, financial controls, release governance, or customer-impacting production logic, the organisation may need clear evidence of who approved the change, when they approved it, and whether the required approval threshold was met.

Workzone’s digital signatures support that kind of workflow by allowing teams to require signed pull request approvals before merge. This turns review from a lightweight “looks good” gesture into a more explicit act of responsibility.

That distinction will matter more as AI-assisted development becomes normal. If code can be produced faster, the evidence around review and release decisions needs to become stronger, not weaker.

The Human in the Loop Is a Design Choice

The real question is not whether AI should be involved in code review. It already is.

The real question is where the human stays.

For low-risk changes, the human may only need lightweight oversight supported by automated checks. For high-risk changes, the human must remain load-bearing: accountable, independent, and traceable.

These are not administrative details. They are the shape of trust.

That is the line teams need to draw deliberately.

Workzone exists for Bitbucket teams that want that line to be clear. Teams that want pull request workflows to reflect real ownership, real reviewer rules, real approval quotas, and real compliance needs. Teams that want to benefit from AI-assisted development without allowing important files, branches, and workflows to be changed uncontrolled.

Because the future of software delivery will not belong to the teams that generate the most code.

It will belong to the teams that can still stand behind what they merge.

How can I achieve this in Bitbucket today?

Bitbucket Cloud’s native .codeowners approach takes care of adding file or path based reviewers, but unfortunately it does not enforce approvals and approval quotas as merge-gates.

We have put down the IRL comparison of Workzone cloud vs Bitbucket code owners here.

We have also created an interesting article on comparing the Cost of Workzone + Bitbucket Standard vs Bitbucket Premium + .codeowners. You could save yourself a fortune!

Want to feel safe and sleep tight while your AI agent’s code gets merged? Put Workzone “in the loop”

Visit Workzone for Bitbucket on the Marketplace here

Happy coding,

Sean Manwarring

Izymes Team