What Breaks When AI Opens Pull Requests: Making GitOps Work for Your Team | Harness Blog

More than half of cloud-native teams say they have adopted GitOps, according to CNCF Annual Cloud Native Survey. While some studies suggest as high as 90% adoption, the panel's own research told a different story: most organizations apply GitOps to under half of their production applications, and only about 16% follow four or more of the practices that define mature GitOps. 

That gap between claimed adoption and actual depth was the backdrop for the webinar “What Breaks When AI Opens Pull Requests.” The speakers’ real question: what happens to that gap once AI agents start opening a meaningful share of the pull requests GitOps is supposed to reconcile?

GitOps adoption is wide, but most teams are only a few practices deep

A live poll during the webinar put a finer point on the stat: over half of attendees said they were still learning what GitOps actually is, a small share were evaluating or piloting it, and roughly a third said it was standard practice across most of their delivery. 

Martin Reynolds’ definition grounded the rest of the conversation: GitOps means using Git as the source of truth for a system's desired state, built on four practices, declarative configuration, version control, automatic pulling, and continuous reconciliation. Larry Garfield added that these practices stack. Teams can adopt some and get partial benefits, but the more of the four they combine, the more they get out of each one.

At Zalando, AI already authors a large share of pull requests

Syamala Umamaheswaran described a team where most engineers already rely on coding agents day to day, producing a steady stream of AI-generated or AI-assisted pull requests that her team treats similarly to how it already treats automated dependency-update bots, just at higher volume. That volume lands on an existing review structure: a two-reviewer approval standard, a large automated test suite that exercises the Kubernetes platform end to end, and a first-pass review from an LLM that flags each pull request's relative risk before a human ever looks at it.

A model's risk label can miss the context a human would catch

That risk-flagging step is also where Umamaheswaran raised her central concern: treating a model's "low risk" label as equivalent to a human's judgment, when the model may be working from an incomplete picture of the change's real context. 

A pull request mislabeled as low risk can still cause an incident. Her response is to reduce the blast radius of any single change and build feedback into every step along the way, rather than letting one upstream label decide how much scrutiny a change receives downstream.

The panel split on whether AI changes GitOps at all

Garfield argued that GitOps itself does not change based on who or what opens a pull request. The same automated tests run, the same human reviewer makes the final call, and an oversized change gets pushed back regardless of whether a person or a model authored it. He drew one hard line: models should never write the tests that validate their own code. 

Reynolds pushed back on the first point while agreeing with the second. In his view, AI already changes the pipeline by doing the risk triage itself, by surfacing the specific code segments a reviewer needs to see, and by spotting patterns across many drifting clusters faster than a human scanning them one at a time. On testing, he agreed with the underlying caution but drew a narrower line: a model can write tests, as long as it is a different model from the one that wrote the code being tested, so nothing is grading its own work.

AI’s best use is tackling ambiguous problems 

Umamaheswaran's broader position was that deterministic problems should stay deterministic. If a task can be solved with ordinary, predictable code, reaching for an agent adds cost without adding value. Where she sees a real role for AI is in genuinely ambiguous situations, incident response chief among them, where pulling together a first read on a fast-moving, unstructured problem is something a model can do in minutes that would take a person hours. 

Reynolds agreed with that framing even as he argued AI's footprint across the pipeline is already broader than people assume.

Guardrails for change predate the AI era

Asked how a flawed or hallucinated change gets caught before it reaches production, Umamaheswaran described guardrails her team built well before AI entered the picture. Those guardrails are now more important than ever.

Changes roll out in stages rather than all at once. Alerts are tiered, so a lower-severity issue appears on a dashboard rather than paging someone overnight. The observability investment is sufficient to support more than 250 clusters with varied traffic patterns, rather than a single one-size-fits-all test. The team's goal is that no one manually changes a cluster's state, since that is exactly the moment auditability breaks down, and in practice a Git revert resolves the overwhelming majority of incidents without anyone touching a cluster by hand.

More environments mean drift

Reynolds pointed to environment sprawl as a long-standing GitOps risk that AI-driven volume only intensifies: more merges moving through more environments means more chances for configuration to drift between them. 

Umamaheswaran confirmed Zalando runs a build through four environments before production, structured as a dev stage for platform engineers followed by alpha, beta, and production channels, each one a checkpoint for catching regressions before they reach the next.

AI raises the stakes on scanning code

Garfield's view was that most of what counts as good GitOps hygiene, automated testing, observability, and the ability to roll back is not new. AI adds new tooling on top of those fundamentals without changing what the fundamentals are. 

Reynolds largely agreed but argued the bar has moved: he cited research suggesting a meaningful share of AI-generated code, in the mid-40% range across a broad set of models, carries security vulnerabilities.

His conclusion was that scanning can no longer happen once at the start of a pipeline. It needs to repeat at every stage, alongside an up-to-date software bill of materials, artifact verification at every deployment, and monitoring that compares each release against the pattern of prior releases to flag anything that looks different.

What holds companies back from GitOps

The panel named three barriers. Reynolds pointed to a weak benefit case in large, brownfield environments running thousands of services across infrastructure that is not uniformly Kubernetes, where it is genuinely hard to say GitOps would make things better. 

Garfield pointed to the real cost and complexity of running a GitOps workflow well, whether built in-house or bought as a managed service, plus a more basic issue: teams that do not yet trust their own test suite or their own reviewers will not trust an automated pipeline either, and that trust has to be earned before the workflow pays off. 

Umamaheswaran reframed the whole question as a business case rather than a technical one, pointing to the operational calm of not being paged overnight as the argument that resonates even outside engineering. 

Poll results shared during the session backed up that framing: 81% of respondents said GitOps improves auditability, 78% said it reduces drift, and 63% said it improves security.

AI belongs in the same audit trail as everything else

Reynolds extended the auditability argument to AI itself: if a model is generating code, generating tests, or approving a pull request as low risk, the audit trail needs to capture which model made that call, under what identity or credentials, and where that decision sat in the pipeline. The more a team trusts AI to act within a set of guardrails, the more that provenance matters, not less.

The metrics that justify GitOps

Closing on what proves the investment is working, Umamaheswaran started from the business side: recurring breakages, unhappy customers, a burned-out team that’s constantly firefighting instead of delivering on the roadmap are signals pointing back to the need for a platform team that eliminates the toil of reconciling cluster state so product engineers can spend their time on features instead. 

Garfield added a concrete metric to track alongside that: the time from a pull request going up to that change reaching production. Getting that down to a day or two, even without multiple deploys per day, reduces accidental complexity and speeds up how quickly new features reach users. 

Reynolds tied both points back to DORA metrics specifically: lead time for speed, recovery time and rollback rate for stability. He observed that the trend over time matters more to a business audience than any single snapshot, since consistent improvement without added risk is what makes an investment easy to keep funding. 

Garfield's closing observation: teams with stronger GitOps maturity tend to post better DORA metrics overall, which is reason enough to keep measuring them.