We Automated Our GitHub Pull Requests. Code Reviews Got Faster.
Kenji keeps a spreadsheet of how the engineering team spends its time. Not because anyone asked him to, but because he's the kind of lead who wants data before he complains about anything. In January, he showed me the row that bothered him most: "Routine PRs." The team was spending an average of 6.2 hours per week opening pull requests that didn't require any creative thinking. Config file updates across repos. Dependency version bumps that Dependabot flagged but didn't finish. Documentation fixes after API changes. README updates when endpoints moved.
Each one followed the same steps. Clone the repo or pull the latest. Create a branch. Open the file. Make the change. Commit. Push. Open the PR on GitHub. Tag the right reviewer. Wait. Follow up. Merge. Delete the branch. For a two-line config change, the actual edit took 30 seconds. The ceremony around it took 10 to 15 minutes.
Kenji's frustration wasn't that the work was hard. It was that the work was identical every time, and it still required a human to do each step manually.
The Routine PR Problem
We run 14 active repositories. The frontend, backend, three microservices, a shared component library, internal tools, infrastructure configs, and several customer-facing SDKs. When a shared config value changes, like an API base URL or a feature flag default, it needs to be updated across every repo that references it. When a dependency gets a security patch, every repo using it needs to bump the version.
In theory, Dependabot handles dependency updates. In practice, Dependabot opens a PR with the version bump, but our repos have custom linting rules, and roughly 40% of Dependabot PRs failed CI because the lockfile format didn't match our config or the import style had changed between major versions. Someone still had to look at the failure, fix it, and push the fix to the Dependabot branch. That someone was usually Anya, who had developed a muscle memory for these fixes and could resolve them in about five minutes each. But she was resolving eight to twelve of them per week.
Config file updates were worse. We store environment-specific configuration in YAML files across repos. When Elena changed the staging environment's database connection pooling settings, she had to update the config in seven repos. She spent a Wednesday afternoon doing this: opening each repo, finding the right YAML file, changing the value, making sure the indentation was correct, committing, pushing, opening the PR, tagging the repo owner for review. Seven PRs, each for a one-line YAML change. Total time: about 90 minutes. Total mental effort: zero. Total value of having an engineer do it: zero.
The documentation drift was subtler but more expensive in the long run. Every time the backend team changed an API response schema, the SDK documentation needed to match. The process was supposed to be: backend engineer updates the schema, then updates the docs in the SDK repo. The reality was: backend engineer updates the schema, forgets about the docs, and two weeks later a customer files a support ticket because the documented response format doesn't match what the API actually returns. Rafael spent about three hours a week tracking down these mismatches and opening corrective PRs.
What a Manual PR Actually Costs
Kenji's spreadsheet broke it down by type. Config changes: 1.5 hours per week across the team. Dependency bumps (including Dependabot fixes): 2 hours per week. Doc sync PRs: 1.5 hours per week. Miscellaneous routine PRs (license file updates, CI config changes, template updates): 1.2 hours per week. Total: 6.2 hours per week, spread across four engineers.
That's 6.2 hours of engineering time spent on work that requires repository access and git proficiency but zero judgment. The engineer isn't deciding what to change. They already know the change. They're just executing the mechanical steps to get it into a PR.
Kenji's pitch to me was direct: "If I could get those hours back, that's nearly a full day of engineering time per week. That's a feature. Or a round of tech debt payoff. Or both."
The Agent Approach
We started with the config file updates because the pattern was the most repetitive. Every config update followed the same sequence: read the current file, find the value that needs to change, update it, open a PR with a descriptive title and a note about why the value changed.
We set up a config file updater agent that takes a simple instruction: which repos, which file path, what to change, and why. The agent authenticates with GitHub, reads the current file contents from each repo, makes the specified change, creates a branch, commits the change, and opens a pull request with the right title, description, and reviewer tags.
The first test was Elena's next config update. Instead of spending 90 minutes on seven repos, she described the change to the agent in about two minutes. The agent opened seven PRs in under three minutes. Each PR had the correct file change, a clear description explaining the reason for the update, and the right team lead tagged as reviewer.
Elena reviewed all seven PRs in about ten minutes. The changes were exactly what she would have made. The branch names followed our convention. The PR descriptions were better than what most of the team writes manually because the agent included the before and after values and the reason for the change in a consistent format.
What Changed After the First Month
Anya stopped being the Dependabot fixer. The agent now handles dependency version bumps by reading the update Dependabot suggests, applying our linting rules, fixing any format mismatches, and opening a clean PR that passes CI. The number of dependency PRs that fail CI dropped from about 40% to under 5%. Anya got about two hours per week back.
Rafael set up the agent to run whenever the backend API schema changes. It reads the updated schema, compares it to the documentation in the SDK repos, identifies the mismatches, and opens PRs with the corrected docs. The documentation lag dropped from an average of 11 days to under 24 hours. Customer support tickets about outdated docs dropped to near zero.
Kenji's spreadsheet for February showed total routine PR time at 1.8 hours per week, down from 6.2. Most of that remaining time was reviewing the PRs the agent opened, which is work the team actually wants to do. Reviewing a clean, well-described PR takes about two minutes. The review process got faster because the PRs were consistently formatted, the descriptions were clear, and the changes were isolated to exactly what needed to change.
The engineers reported something I didn't expect. Code reviews on human-authored PRs also got faster. When the routine PRs were mixed in with feature PRs in the review queue, reviewers were context-switching between trivial config changes and complex feature work. Removing the routine PRs from human authorship meant the review queue was smaller and more focused. Tomás said his average time-to-first-review on feature PRs dropped from about 8 hours to about 4 hours because reviewers weren't spending their review time on one-line config changes.
What the Agent Doesn't Do
The agent handles mechanical work. It doesn't design systems, make architectural decisions, or write feature code. It reads a file, makes a specified change, and opens a PR. The human still decides what to change and why. The human still reviews and approves the PR. The agent handles the parts between the decision and the review.
It also doesn't replace CI/CD. The PRs the agent opens still go through the same pipeline as any other PR: linting, tests, security scans, and reviewer approval. The agent is authoring the PR, not merging it. The safety checks remain exactly the same.
The boundary is clear: if the change requires understanding context beyond what's in the file, a human should do it. If the change is "update this value from X to Y in these locations," the agent handles it without error and without the 15 minutes of git ceremony per repo.
The Math After Three Months
Kenji's March spreadsheet showed the cumulative impact. The team recovered an average of 4.4 hours per week of engineering time. Over the quarter, that's about 57 hours. At our average engineering cost, that's a meaningful amount of money. But the real value wasn't the hours saved on routine PRs. It was the hours gained on everything else.
Anya used her recovered time to refactor the shared component library's build pipeline, which reduced CI times across all repos by about 30%. Rafael used his to write integration tests for three API endpoints that had been untested for months. Elena used hers to prototype a feature that shipped in the next sprint.
None of that work would have been impossible without the agent. But all of it would have been delayed, squeezed into the margins between routine PR tasks that didn't need an engineer's attention in the first place.
Try These Agents
- GitHub Config File Updater -- Update config files across multiple repos and open PRs automatically
- GitHub Dependency Version Bumper -- Bump dependency versions with correct formatting and passing CI
- GitHub Documentation Sync Agent -- Keep documentation in sync with code changes across repos