Pull requests used to be pretty straightforward.
Here's the code I changed. Here's why I changed it. Have a look when you get a chance.
That worked because the person opening the PR had usually written the code themselves. They knew what they were trying to do, understood the trade-offs, and could explain a weird-looking line if someone asked about it.
That assumption is getting harder to make.
Today, a lot of code is written with AI coding tools. Sometimes another AI tool reviews it. Automated tests make the green checks look reassuring, and a human eventually clicks approve. The problem is that it can become surprisingly difficult to understand what actually happened between "generate" and "merge."
The pull request isn't going anywhere. But what we expect a pull request to tell us is changing.
What a Pull Request Now Has to Prove
When a developer wrote every line of a change, the diff usually carried a lot of context by itself. Add a reasonable commit message and a few comments, and a reviewer could generally work out what was going on.
That gets much harder when AI is involved.
If an AI assistant wrote half the code and an AI reviewer checked it, the diff doesn't tell you enough on its own. Was the code generated by AI and then carefully reviewed by someone who understood the change? Or was it generated, glanced at, and approved because the tests were green and everyone was under pressure to move on?
Those are very different levels of review, and the difference tends to matter most several weeks later, when something breaks and someone has to work out what happened.
Increasingly, a useful pull request needs to give reviewers more context. Was AI used to generate the change? What tests actually ran? What did those tests cover? Did an AI reviewer flag anything? What did the human reviewer actually inspect before approving it? And, perhaps most importantly, who was responsible for the final decision?
That's less about the mechanics of Git and more about governance. But it's already starting to influence how engineering teams build their development workflows.
Some teams are beginning to label AI-generated code. Others require an explicit human sign-off when AI has contributed significantly to a change. These practices weren't really necessary a few years ago, because the underlying development process was different.
Now they're becoming much more relevant.
Why This Matters Even More Once AI Agents Get Involved
Things get more interesting when AI isn't just helping a developer write code but is actually opening the pull request itself.
An agent might pick up a ticket, make the change, run the tests, and open a PR without a developer touching the code until the review stage.
At that point, the pull request becomes more than a place to look at a diff. It becomes one of the main places where humans and AI systems coordinate.
An agent proposes a change. Automated tools run checks. Maybe another AI reviews the code. A developer looks at the results, asks questions, makes changes, or approves the PR. If something goes wrong later, someone needs to be able to go back through that chain and understand what happened.
That means the PR starts to serve another purpose: it's an audit trail. It's a record of the evidence behind a decision.
Teams that continue treating it as nothing more than "the diff plus some comments" can quickly lose track of accountability. When something goes wrong, the obvious questions become surprisingly difficult to answer. Who approved this? What did they actually review? Which checks were run? What did the AI tools do? What did the human reviewer verify? And what information was available when the decision was made?
Those questions aren't hypothetical anymore.
Where Teams Get This Wrong
The biggest mistake is assuming that a review process designed for human-written code will automatically work for AI-generated code.
It won't. At least, not without some changes.
Imagine a developer receives a large AI-generated PR. The automated tests are all green. The diff is huge. There's a deadline. They skim through it, see nothing obviously wrong, and hit approve.
Technically, the PR was reviewed.
But was it actually reviewed in the way the team intended? That's the part that's easy to miss.
AI can dramatically increase how quickly code gets produced. If review practices don't change at the same time, the bottleneck simply moves. Developers end up approving more code in less time, often relying heavily on automated checks because there's no realistic way to inspect every line with the same depth they once did.
The result is that an approval can still look exactly the same while meaning something quite different.
Teams that are dealing with this well are getting more explicit about what "approved" actually means. They're also adjusting the level of review based on the risk of the change and the role AI played in producing it.
A small change to log formatting doesn't need the same scrutiny as an AI-generated change to payment processing, authentication, or customer data handling. The important thing is to make that distinction deliberately, rather than leaving it to individual reviewers to figure out under pressure.
Why Mumbai's Fast-Moving Delivery Teams Are Feeling This First
This is particularly relevant for software teams in Mumbai that work with regulated clients, especially in banking and financial services.
These teams already have to deal with audits, compliance requirements, and client-side governance. As AI becomes part of the development process, the questions from those clients are becoming more specific.
It's no longer enough to say, "Yes, the change was reviewed." Someone may ask who reviewed it, what exactly they reviewed, what was tested, whether AI was involved, and what the human reviewer verified before approving the change.
Those questions are much harder to answer if AI involvement hasn't been tracked from the beginning.
That's why some development teams are starting to make AI involvement visible directly in their pull request templates. They capture things like whether AI was used to generate the code, which automated checks were performed, and what the human reviewer specifically verified.
Yes, it adds another step. But for teams working with regulated or high-stakes clients, having a clear record of how a change was produced and approved is becoming increasingly important.
The code still matters. But so does the story behind the code.
What Teams Actually Need to Do About This
The good news is that none of this requires some massive new engineering platform.
Start by keeping track of where code came from. If AI played a significant role in producing a change, make that visible rather than leaving someone to guess six months later.
Make the depth of review proportional to the risk. A tiny change to logging shouldn't require the same process as a change to payment logic, authentication, or access controls.
Keep testing information close to the pull request. Reviewers shouldn't have to jump between three different dashboards just to figure out what actually ran and whether it passed.
And most importantly, agree on what a human approval actually means. If a reviewer is expected to understand the entire change, say so. If certain parts are covered primarily by automated checks, make that clear too. If AI-generated changes above a certain risk level require additional review, define that upfront.
The technology isn't the difficult part. The harder part is accepting that the pull request has taken on a bigger job than it used to have.
It's no longer just showing what changed. It's increasingly showing how the change came about, what evidence supports it, and why the team decided it was safe to merge.
FAQ
Does AI-generated code need different review standards than human-written code?
Not necessarily a completely different standard, but it does make sense to adjust the depth of review based on the risk of the change and how AI was involved. A low-risk formatting change and an AI-generated change to payment logic shouldn't go through exactly the same level of scrutiny.
What does "test provenance" mean when it comes to a pull request?
It simply means being able to see what tests actually ran against the change, what they covered, and whether they passed. Ideally, that information is visible from the pull request itself rather than requiring a reviewer to hunt through other systems.
Why does this matter more for regulated industries like banking or fintech?
Because auditors and compliance teams care about more than whether someone clicked "approve." They may need to know who reviewed the change, what was tested, what was verified, and what evidence supported the decision. That becomes harder to demonstrate when AI is heavily involved and nobody is tracking its role.
Does every team need this level of pull request governance?
No. The right level of governance depends on the team and the risk of the software being built. But as AI-generated code becomes a larger part of a codebase, having some visibility into how changes were produced and reviewed becomes increasingly useful. For regulated and high-stakes environments, it can become essential.
Top comments (0)