AI for Platform Engineering: Where It Helps and Where It Doesn't

“AI will automate platform engineering.”

You hear it in every vendor deck. It describes half the job.

Writing the code is real work, and AI has made it faster. That part is genuine and worth having. But code was only ever one source of the slowness. The other is that every change has to be adopted across dozens of teams, and AI does nothing for that.

AI automates one half of platform engineering: writing the code. It leaves the other half untouched. Producing a cross-repo change is quick. Getting dozens of teams to review and merge it across every repository is what takes weeks. AI writes the pull requests in minutes and cannot close them for you.

What the job actually is

Take a dependency that just hit end of life. The fix is small and you know exactly what it is. Writing it is an afternoon of work.

Then the afternoon ends and the real project starts. That change has to land in 150 repositories owned by 40 teams. You explain it to each team. You wait while they fit it around their own roadmaps. You track who merged, who is blocked, and who has not started. You follow up. Then you follow up again.

Writing the change is one part of the work. Driving it to completion across the org is the other, and at scale it is the part that runs into weeks.

Where does AI help platform teams, and where does it stop?

Start with what AI does well, because the gains there are real. Point it at a runtime upgrade and it produces the updated manifests, migration notes for the breaking changes, and a first pass at the test fixes. Run it across a fleet of repos and it flags the ones still on the deprecated auth pattern or the old database client. Work that took hours per repo takes a fraction of that now. Any engineer who has hand-patched the same library across hundreds of repos knows what that is worth.

Then the generation finishes, and the story the vendors tell breaks.

AI opens eighty pull requests in an afternoon. Some land clean, some need a second pass. Either way, eighty open PRs are not eighty merged changes. They are eighty teams who have not looked yet. The merge gap is the distance between a generated pull request and a change that is live across every repository in the org. It is where the weeks go.

A pull request stalls for reasons no model can resolve. The owning team is heads down on a launch. CI broke in a legacy repo and nobody there knows why. The PR landed in a notification feed and sank. The repo lost its owner when the tech lead left. Generating a cleaner PR does nothing for any of these.

The stall is not free. When the change is a CVE patch, every repo that has not merged is still exposed. A fix you wrote in an afternoon, merged in a third of your repos and pending in the rest three weeks later, is closed on paper and open in production. The gap compounds, too, because the next urgent initiative starts before the last one finished. Coordination is most of the work, and it is most of the risk.

A dashboard is not a fix

The common response is to bolt a tracking layer onto the code generation. AI writes the changes. A spreadsheet or a campaign tool holds the list. A human still chases every team through Slack. You have made the code faster and left the coordination as manual as it ever was. The bottleneck has not moved. It just has a dashboard now.

A head of platform engineering we spoke with put it plainly: “No more spreadsheets, no more chasing PRs, the real value is in the coordination.” Generating the code faster does not remove any of that chasing.

More AI will not close the merge gap. What closes it is an agent that coordinates the change as part of the same job as writing it.

What closes the gap

This is what Tidra does. Tidra is an AI coding agent for both implementation and coordination of code changes across your organization.

A dashboard tells you which teams have not merged. It does not change why. A team has not merged because merging is work for them: read the change, write it in their repo, test it, open the PR. Tidra does that work before it reaches them. The change is generated, the PR is already open against their repo, and the plan explains why it is needed. What is left for the owning team is to read a PR that is already written and approve it.

That is the difference that moves the number. A platform lead we work with described what changed for their teams: “all they have to do is accept the PR and move on.” Most teams will approve a change that is already written and explained. The ones who will not, because they are mid-launch or the repo is genuinely orphaned, are the ones Tidra surfaces. Your follow-up shrinks from every repo to the few that are actually stuck. You stop chasing the whole org and start escalating the handful that need a real conversation.

One honest limit, because it matters. Tidra does not force a merge, and it does not run on its own. It proposes a plan, and it proposes the code. Your engineers review the diffs and approve the PRs. Nothing direct-commits, and nothing merges without a person. If a generated change is wrong and you correct it ten times, it has saved you nothing, which is why the plan comes first, before any code is touched. A team that is slammed can still sit on a one-click PR. The point is that “review this” is a far smaller ask than “go build this,” and you can see exactly who you still need to talk to.

How to measure the maintenance time your team is losing

You do not have to take any of this on faith. Pick the last change you pushed across fifty or more repos and check four numbers.

1. How long it took to produce the correct change, from “we know what to do” to the first good PR.
2. How long it took to get from that first PR to the last merge across every repo.
3. How many reminders, pings, and escalations you sent to get there.
4. How many of those repos are still unmerged today.

AI compresses the first number. It does not touch the other three. The distance between number one and number two, measured in your own repos, is the part of platform engineering AI has not touched.

The bottom line

AI makes the code faster, and that is real. It does not get your changes adopted across the org. Those are two different problems. It solved one of them and left the other untouched.

So bring one question to your next planning meeting. AI can write the patch, and you already know that. The harder question is what keeps that patch sitting in an open pull request three weeks later, and what it costs you to leave it there.