The old question was: can AI help developers write code? The new question is: who verifies the work when AI can create the pull request?
For a few years, AI in software meant a smarter autocomplete — a helpful suggestion as a developer typed. That framing is now out of date. AI coding agents can take a task, work through it, and open a pull request of their own. The capability is genuinely useful. But it quietly moves the hard part of software downstream: not writing the change, but confirming the change was needed, correct, and safe. Creating a pull request is not the same as verified delivery.
From autocomplete to autonomous pull requests
The shift is from suggestion to action. Early AI tools completed a line or a function inside the editor, with the developer in the driver's seat for every keystroke. Agentic tools operate at the level of a task: they can read context, edit several files, run checks, and package the result as a pull request for a human to review.
That is a real productivity unlock — and it is becoming normal, not niche. GitHub's own Octoverse report describes AI accelerating activity across the platform, and the broad direction of travel is more code, produced faster, by more contributors (human and machine). The point is not that the tools are magic; it is that the volume and origin of changes is changing, and the way we check them has to keep up.
What the GitHub Copilot coding agent changes
A concrete example: GitHub's Copilot coding agent can be given a task in a session, work on it, and — depending on how the team sets things up — open a pull request with its proposed changes for review. The agent does the drafting; the pull request is the handoff point where a person inspects the work and decides whether to merge.
This is the important detail for anyone managing delivery: the agent's output still arrives as a pull request. The familiar review surface does not go away — if anything it becomes more central, because it is now the place where human judgment meets machine-generated work. The PR is still where you find out what actually changed. (For founders who are new to reading them, we cover the basics in how non-technical founders can understand pull requests.)
Why more pull requests do not automatically mean more business value
When an agent — or a developer using one — can produce twice the pull requests in a week, it is tempting to read that as twice the progress. It might be. It might also be twice the review load, more fragmented changes, and more work that moves code around without moving the product forward.
- More PRs can mean faster delivery — genuine acceleration on the right tasks
- …or more fragmentation — many small changes that are harder to reason about as a whole
- …or more review burden — output grows, but the hours available to verify it do not
- …or more code movement than value — activity that looks like progress on a dashboard but does not map to outcomes
Volume is an output metric. Value depends on whether each pull request was needed, in scope, and safe — which a raw count cannot tell you. Google's DORA research is direct about the trade-off: AI can lift throughput, but without strong review and testing that throughput can come at the cost of stability.
The new bottleneck is verification
When writing code gets cheaper, the scarce resource becomes trust in the result. The questions that matter are not about typing speed; they are about judgment:
- Does the PR match the Jira task? Or did the agent build something adjacent to what was asked?
- Was the work actually needed? Useful-looking changes can still be off-priority.
- Is it safe? Did it touch payments, auth, permissions, or customer data?
- Was the logged time reasonable? For the scope of the change, do the hours fit?
- Is it business-relevant, or just code movement? Real outcome, or churn?
None of these are answered by the existence of a pull request. They are answered by reading it in context — which is exactly the work that scales poorly when the number of PRs jumps.
What founders and PMs should ask for
Whether a human or an agent produced the change, the evidence that makes it verifiable is the same. Insist that every pull request carries:
- A linked Jira issue — so the work traces back to what was agreed
- A PR summary — a plain-English description of what changed and why
- Risk notes — a flag when sensitive areas are touched
- Test notes — what was checked, especially for anything users depend on
- A time-log explanation — how the hours map to the work, for human and AI-assisted effort alike
- A demo or screenshot — where the change is visual or user-facing
An agent that opens a clean, well-described, task-linked pull request is doing exactly what you want. The risk is not AI authorship — it is unverified delivery, whoever produced it.
Where AI code review helps — and where it does not
It is worth being precise, because "AI writes the code" and "AI reviews the code" are now both real, and they solve different problems. AI code review tools — from GitHub, Anthropic's Claude, Atlassian's Rovo Dev, and others — can read a diff and flag likely bugs, risky patterns, missing edge cases, and suspicious changes. That is valuable, and it raises the floor on quality.
But automated code review answers "is this code plausibly correct?" It does not answer the questions a person paying for the work actually has: was this the right thing to build, is its scope honest, and is the effort behind it reasonable? Those are business questions, not bug questions. An AI reviewer can pass a change that is technically fine and entirely off-brief. Verification of value and effort is a separate layer that sits on top of code review, not inside it. (The downstream cost of all this checking is what we call the verification tax.)
How InsightPM helps
InsightPM works at that business layer. It connects your GitHub and Jira (read-only), reads each pull request, and ties it to its Jira context. For every PR it produces two independent estimates of the effort the change should take — one assuming manual work, one assuming active AI assistance — and compares both against the hours actually logged. Then it explains the change in plain English: what was touched, how complex and risky it was, and whether the work links to its task.
That gives a founder or PM a fair frame for AI-era delivery without reading code: when an agent opens ten pull requests, you can see which ones are substantial, which touched sensitive areas, and whether the logged effort lines up with the scope. To be clear about the boundary: InsightPM does not audit code quality or replace engineering review — it makes scope, risk, and effort legible, whether a human or an agent wrote the change. It is the same artifact-based evidence that makes a pull request the new invoice evidence. See why InsightPM exists.
FAQ
What is an AI coding agent?
An AI system that does more than suggest the next line of code. Given a task, it can plan, edit multiple files, run checks, and — depending on the workflow — open a pull request with its proposed changes. It participates in the development workflow rather than just autocompleting inside an editor.
Can AI coding agents open pull requests?
Yes. Depending on how a team configures it, tools like GitHub's Copilot coding agent can take an assigned task in a session and open a pull request with its changes for human review. The pull request is the handoff point where a person checks and decides whether to merge.
Do AI coding agents replace developers?
No. Agents accelerate parts of the work and can draft changes, but a human still owns the decision to merge, the responsibility for what ships, and the judgment about whether the change was needed, safe, and correct. Agentic workflows increase the need for verification rather than removing it.
Does more AI-generated pull requests mean more business value?
Not automatically. More PRs can mean faster delivery, but also more fragmented changes, more review load, and more work that is code movement rather than value. Volume is an output metric; value depends on whether each PR was needed, scoped, and safe.
How do you verify AI-generated pull requests?
Treat an agent's PR like any other: confirm it links to the task it was meant to deliver, check whether it touches risky areas, look for tests, and judge whether the change matches what was asked. AI code review can flag bugs, but verifying scope, need, and effort is a separate, business-level question.
Does InsightPM review the AI's code quality?
No. It does not audit code quality or replace engineering review. It reads each pull request, connects it to its Jira context, estimates both manual and AI-assisted effort, and explains the work in plain English — so a non-technical stakeholder can see scope, risk, and whether logged time lines up, whether a human or an agent wrote it.