From backlog to autopilot: Our AI workflow that merges 5,000 pull requests a month

We were manually merging thousands of dependency updates, chasing flaky CI (Continuous Integration) builds, and watching security alerts stack up. This post breaks down how we built Automerge: an AI-powered workflow to check, merge, and correct dependency Pull Requests at scale, plus what it taught us when things went wrong.

Every month at GetYourGuide, we now merge more than 5,000 dependency update pull requests (or PRs) across 250+ repositories, with zero human clicks. And when a dependency bump breaks CI, we don’t wait for an engineer: an AI agent checks the failure, fixes the code, and pushes the fix. Alongside those merges, AI handles roughly 1,200 CI and security fixes a month.

This is the story of how we got there: how we built Automerge, an AI pipeline that approves, merges, and fixes dependency PRs, and flags the few that still need a human to the owning team. If you like platform work that removes toil across hundreds of repos, here’s a concrete example.

{{divider}}

The problem: big codebases can easily get outdated

Nobody decides to have an outdated codebase. But dependency PRs pile up, and “someone should look at those” becomes nobody’s job.

‍

That’s exactly what happened to us back in 2023. In our biggest monorepos, around 15 new PRs sat failing CI every week. Over time, our main frontend repos accumulated 200+ outdated dependencies.

Then we decided to upgrade to Vue 3. What seemed like updating a few dependencies turned into a codebase-wide migration: nearly 120 dependencies had to change, and since this was the pre-AI era, we did every update by hand.

Security brought another recurring burden. Every week, a new batch of vulnerabilities kept each team’s on-call engineer busy with tedious, repetitive fixes. When that work piled up, so did the alerts: we had 100+ open security alerts in a single repository, and it wasn’t the only one.

One of our main repos back then: 121 open security alerts 

That period changed how we think about updates: they are only cheap when you’re already up to date. Small, frequent, boring updates over big, rare, terrifying ones. From then on, staying on latest stopped being a nice-to-have and became a platform team requirement.

But to keep 250+ repos up to date without adding more maintenance work for every team, we needed to automate updates.

How Automerge works

So we built Automerge: one pipeline that takes a dependency PR from open to merged. Small PRs are validated and merged continuously, so the codebase never drifts. Humans only show up at the very end, for the few PRs that really need them.

‍
Dependabot, the automated update tool, opens the PRs; Automerge takes them from there. The first step is deciding which updates can be approved automatically.

That decision depends on the repo. Some projects can accept updates broadly; others need tighter controls on sensitive dependencies, allowing only patches or excluding them entirely. Each project specifies its policy in a single configuration line. For example:

targets: patch:all,minor:all,major:github_actions,major:docker

This allows patch and minor updates across all ecosystems, and major updates only for GitHub Actions and Docker upgrades.

When CI fails, AI attempts a fix, which we introduced in 2026. Each attempt starts with Automerge preparing the project's environment and loading instructions tailored to its tooling.

‍

With that setup in place, AI reads the failure, updates the code, and pushes another attempt. It also handles merge conflicts by rebasing the PR and resolving the conflicts. Every fix must pass full CI, and each job has a hard time limit. 

Security fixes enter the same pipeline. For transitive dependencies that Dependabot can’t fix, Automerge automatically generates security fixes when vulnerability alerts appear in the repo, reducing the burden on each team’s on-call engineer.

‍

Anything that needs a human appears in Slack. Each project gets one weekly digest showing blocked PRs, why they’re stuck, and which owning team needs to act.

 The weekly digest: what got merged, what’s pending, what’s blocked — and a direct ping to the teams that can unblock it. 

Monitoring the automation

A system that merges thousands of PRs a month needs to be watched. Every run reports to our monitoring dashboard, Datadog: PRs merged, blocked, pending, time-to-merge, and, crucially, every failed job is tagged with a cause. When the automation itself breaks, we find out before the teams that rely on it do.

 One month of Automerge on the dashboard: 5k PRs merged, 646 fixed with AI, 579 security issues fixed with AI. 

Our favorite AI failures

Putting an AI agent inside a merge pipeline teaches you things no design doc can. The system isn’t perfect: we sometimes auto-merge faulty PRs, and AI sometimes produces the wrong fix. Here are a few of its more creative mistakes.

• It deleted the failing test. Ask an agent to “fix the CI,” and it will eventually discover that deleting the test also makes CI pass.
• It replaced the library with its own implementation. A library update introduced breaking changes. The AI assumed the library no longer supported our use case, removed it, and wrote its own implementation instead.
• It approved screenshot changes that it couldn’t see. Screenshot tests were failing for UI components, but the automation couldn’t access the visual diff. The AI simply added the approved-screenshot-change label without reviewing the changes.
• It guessed what the logs would have said. The AI tried to fetch the CI logs to find out what had failed, but the request failed. Instead of stopping, it guessed the cause and changed the CI pipeline to make it pass.
• It rewrote CI around missing secrets. Secrets hadn’t been configured for Dependabot, so CI couldn’t access them. The AI removed the secret references and mocked the values.

None of these were failures of intelligence; they were failures of contract. The agent did exactly what we asked; we learned to ask for the right thing.

What we learned

Automation needs more than a good first setup. We improved it by learning from two kinds of failure.

The foundation is a reliable CI in every project. Automerge depends on each project's checks to decide whether an update is safe to merge. If those checks miss a regression, the automation can miss it too. When a merged update broke something, we added a check to catch the same issue before the next merge.

When AI made the wrong fix, we improved its instructions. We clarified what it could change, what it had to verify, and when it should abort.

Even small wording changes can lead to very different results. Starting with “Fix the CI” can push the agent straight toward changes that make the checks pass. Starting with “Analyze the CI” encourages it to investigate what failed and why before proposing a fix.

We also tailored the instructions to each project’s tooling (pnpm, npm, Gradle, Go, and others) because installing dependencies, resolving lockfile conflicts, and validating a fix work differently across ecosystems.

The results

After all the iterations, Automerge currently handles around 97,2% of dependency PRs automatically. Engineers handle the remaining 2,8% and any issues caused by problematic merged updates (they’re not shown in the next diagram).

That level of automation is what lets us scale from four repositories in 2023 to more than 250 today.

Back-of-envelope: at 10 minutes of human attention per PR, handling 5,000 PRs manually would take roughly 830 engineer-hours a month. And on top of that comes the benefit that’s harder to measure: codebases that are always current, where adopting the next technology is a small step instead of a waterfall. 

Closing thoughts

Automerge didn’t just speed up dependency bumps; it changed the shape of the work, from reactive firefighting to steady, measurable platform improvements. If you like solving real engineering problems at scale and building systems with clear contracts and guardrails, you’ll fit right in. Apply to join our tech team and find out more about how we work here.

‍