What AI Coding Tools Don't Ship: The Work That Starts After the PR

The pitch for every AI coding tool sounds like the same story. Describe a change, watch the code get written, marvel at how fast that used to take. The demos are impressive, and the productivity claims are, on the surface, real. What’s rarely shown in those demos is what happens next: getting that change through review and merged across every repo it touches.

A pull request opens. That’s where the demo ends. That’s also where the actual work starts. Writing code in one repo and automating code changes across multiple repos are different problems, and most AI coding tools only solve the first one.

At small scale, this is fine. Ten repos, three engineers, one team. The developer who described the change reviews the PR themselves, fixes what needs fixing, and merges it. The window between “AI wrote the code” and “code is in production” is short. The tool looks like the answer.

The pattern breaks at scale, all at once rather than gradually. The moment you go from ten repos to a hundred, from one team to twenty, the AI tool that felt like a productivity revolution stops solving anything meaningful. The code got written. The change didn’t ship.

AI coding tools generate code changes. They don’t get those changes merged. Once a pull request opens, someone still has to read CI failures, resolve review comments, fix merge conflicts, track down repo owners, and decide when the initiative is done. Across a hundred repos, that coordination work, not the code generation, is what determines whether a change actually ships.

The gap between generated and merged

At a hundred repos, running a single change (dependency upgrade, config standardization, security patch) means opening a hundred pull requests. Under ideal conditions, every one of those PRs would pass CI, get one thoughtful review, address one round of feedback, and merge in a week.

Ideal conditions don’t exist. What actually happens across a hundred PRs:

• Twenty of them fail CI on the first push. Some of the failures are real bugs in the change. Some are environment-specific: a flaky integration test, a missing secret in one repo, a build cache misbehaving. Some are pre-existing failures that were there before the PR and would have stayed there without it.
• Thirty of them get review comments requesting a minor change. A different variable name. A comment added. A test case renamed to match the repo’s conventions. Each comment is reasonable. Each comment requires another commit.
• Fifteen of them hit merge conflicts because someone else touched the same file in the meantime. Now the change has to be rebased and re-tested.
• Ten of them land in repos owned by teams that are heads-down on a release. The PR sits in review for two weeks because no one on the team has capacity to look at it.
• Five of them land in repos that used to have an owner but the owner left. Nobody knows who’s supposed to approve it. The PR ages out of Slack visibility and gets forgotten.
• Twenty of them merge cleanly in the first week.

That’s the reality of one change across one hundred repos: twenty merge, eighty stall. The AI tool wrote the code for all one hundred. The tool doesn’t know that eighty of them are still open.

Twenty percent of the work merges without intervention. The other eighty percent is where engineering time actually goes.

The work AI tools don’t do

Everything between “PR opened” and “code merged” is work. Real work, most of which nobody writes about because it’s unglamorous.

Reading CI failure output. A test is red. What’s the actual failure? Is it in the change or upstream of the change? Is it flaky? Does it happen in this repo’s CI environment but not locally? Someone reads the log, decides whether to retry, patch, or investigate. Multiply by twenty repos with different CI setups.

Addressing review comments. A reviewer left five comments on the PR. Two are typos. Two are style preferences that vary by repo. One is a legitimate bug the change introduced. Someone reads each comment, decides which to accept, writes the fix, pushes a new commit. Multiply by thirty PRs.

Resolving merge conflicts. Someone touched the file after the PR was opened. Now the automatic merge fails. Someone reads both diffs, decides how to resolve, tests the resolution locally, pushes. Multiply by fifteen PRs.

Chasing owners. The PR has been open for a week with no review. Who owns this repo? Who’s the right person to ping? Is it Slack, email, GitHub review request, a Jira ticket, or an in-person conversation? Someone tracks it down. Multiply by ten PRs.

Coordinating across teams. Some of the changes need to land in a specific order. Repo A depends on repo B. Repo B has a slower review cadence. Someone coordinates the sequence. Multiply by however many dependencies exist.

Deciding when the initiative is done. Eighty PRs merged, twenty still open. Is the initiative complete? Are those twenty still relevant? Do they need to be closed, escalated, or transferred to a new owner? Someone makes the call.

None of this is code writing. All of it is code shipping, and AI coding tools have gotten astonishingly good at the first part while staying almost entirely silent about the second.

Why the second half never gets solved

The first reason is that the second half of the work is boring. It’s not an interesting technical problem. It’s project management applied to code changes, which nobody wants to build a startup around because the outcome doesn’t feel like innovation. But the fact that the work is unglamorous doesn’t change the fact that it exists, and doesn’t change how much of your platform team’s time it consumes.

The second reason is that the second half of the work looks different in every repo. The rules for what counts as a passing CI run vary. The conventions for review comment resolution vary. The threshold for what’s an acceptable style comment versus a blocker varies. Coordination happens in Slack channels, in email threads, in GitHub review requests, in Jira tickets, sometimes in verbal handoffs. There’s no single API to automate against, because the workflow itself is fragmented across every tool an engineering organization uses.

Which means the tools that could theoretically address this problem have to be built as coordination layers on top of everything else, not as new code editors. That’s a different kind of software with a different go-to-market and a different demo. It doesn’t show up in a five-minute product tour.

What “shipping” actually requires

If a tool is going to ship changes and not just generate them, it needs to do five things AI coding tools currently don’t. Running a single maintenance change across a hundred or more repos and getting it merged requires this sequence:

1. Open the pull requests. Generate the change for every targeted repo and create the PRs, in bulk, from one place.
2. Watch CI, not just run it. After each PR opens, see whether CI passes or fails, understand what the failure means, and either fix it or flag it for a human.
3. Address review comments as they come in. Read each comment, understand the request, produce a change that addresses it, and push a new commit. That’s regeneration in response to feedback, not one-shot generation.
4. Resolve conflicts as they happen. When someone else’s change lands in the meantime, rebase, resolve, and re-push without a human doing it manually every time.
5. Track ownership for every repo. Know who the right reviewer is, and know which stalled PRs need a nudge and when.
6. Report the true state of the initiative. Not “one hundred PRs opened,” which is what generation tools report, but “eighty merged, twenty still open, here’s why each of the twenty is stuck, and here’s what needs to happen to unblock them.”
7. Decide when the initiative is done. Close, escalate, or reassign whatever hasn’t merged, and confirm the change actually shipped everywhere it needed to.

That’s a different product than an AI code editor. It’s the difference between generating a change and shipping a change.

Where this leaves you

If your engineering team is using AI coding tools today (Cursor, Copilot, Claude Code, Devin, one of the dozen others) then congratulations, you’ve solved the code-writing problem. The person who described the change no longer has to type out the code. That’s a real productivity gain.

You have not solved the code-shipping problem. If anything, you’ve made it more visible. When it took a week to write the change, the writing was the bottleneck. Now that it takes five minutes, the writing is fast and every other step in the process is exposed as the actual work.

The next round of productivity in engineering isn’t going to come from making generation faster. Generation is already faster than anyone needed. The next round comes from closing the loop between “PR opened” and “change merged.” That’s where your platform team’s time is going right now, and that’s where the next generation of engineering tools has to live.

A platform engineer we work with described the shift plainly: “Generating the PR was the easy part. Everything after that was the actual job.”

That’s the honest way to think about AI in engineering right now: generation is a solved problem, and shipping is the open one.

Tidra is a Maintenance Agent that automates repetitive code changes, dependency upgrades, runtime migrations, config updates, across large engineering organizations, delivering every change as a reviewable pull request.