The problem
ACF Repeater for Elementor fixes a real gap in WordPress: Elementor has no native way to render ACF Pro’s Repeater fields inside its widgets. I built the plugin to add dynamic Elementor blocks that read and render any ACF Repeater field, and it’s now running in production across several client environments.
Once it was live, the plugin needed the same thing every piece of production software needs: a steady stream of pull requests reviewed, merged, and kept moving. That’s a small, repetitive cost per PR — but it’s a recurring one, and recurring costs are exactly what I look to automate first.
The decision
I didn’t want a CI script that just runs tests and blocks on red. I wanted something that could read a diff the way I would, decide whether it was safe to ship, and act on that judgment without waiting for me to be at a keyboard. That meant treating code review as an agent’s job, not a pipeline’s.
I built a scheduled Claude Code agent that runs daily against the plugin’s repository. Each run:
- Lists every open PR.
- Reads the diff of each one.
- Merges (squash + delete branch) anything that clears its review criteria.
- Fixes trivial issues directly, in place, when that’s faster than a round-trip comment.
- Leaves a comment on anything that needs a human, explaining why.
- Sends a summary email of what happened.
The safety net isn’t the agent’s judgment alone — it’s what’s already around it: branch protection rules and semantic versioning were in place before the agent started merging anything, so a bad merge still has to pass the same gates a human’s would.
Where autonomy stops
The agent decides what it can merge safely, not everything. Non-trivial changes — anything touching the plugin’s core rendering logic, anything the agent isn’t confident reading — get a comment and a human review, not a merge. That boundary is the actual design work here: an agent that merges everything isn’t autonomous, it’s just unsupervised, and an agent that escalates everything isn’t saving anyone time. Getting that line right took more iteration than the merge logic itself.
The multi-agent pilot
Once the single review agent was stable, I piloted a second layer: a security-focused agent and a frontend/design agent, both working in parallel on the same repository — one watching for vulnerable patterns in PHP, the other reviewing how new Elementor blocks would actually render.
It’s currently paused. Running two agents against the same repo surfaced a coordination problem I hadn’t designed for: overlapping comments on the same PR, and no shared sense of priority when their feedback disagreed. Rather than ship that as-is, I paused the pilot to redesign how they hand off to each other — which is the honest state of it right now, not a finished feature.
Results
- 100% of trivial PRs merged autonomously since the agent went live — nothing routine waits on me anymore.
- Zero manual merge time spent on the changes the agent can already judge correctly.
- The plugin has stayed in production across every client environment with no incidents traceable to an autonomous merge.
What this proves
This isn’t “I used AI to help me code.” It’s designing where an autonomous system’s authority ends, wiring in the guardrails that make that boundary hold (branch protection, semantic versioning, human escalation), and being willing to pause a piece of it — the multi-agent layer — the moment it stops being trustworthy rather than shipping it broken. That’s the same judgment call that scales from “should this PR merge” to “should this feature ship” at any size of team.
