El problema
ACF Repeater for Elementor resuelve una limitación real de WordPress: Elementor no ofrece soporte nativo para renderizar campos ACF de tipo Repeater dentro de sus widgets. Construí el plugin para añadir bloques de Elementor que leen y renderizan dinámicamente cualquier campo Repeater de ACF Pro, y hoy está en producción en varios entornos de cliente.
Una vez en producción, el plugin necesitaba lo mismo que necesita cualquier software vivo: un flujo constante de PRs revisadas, mergeadas y gestionadas. Es un coste pequeño por PR, pero recurrente — y los costes recurrentes son justo lo primero que busco automatizar.
La decisión
No quería un script de CI que solo corriera tests y bloqueara en rojo. Quería algo capaz de leer un diff como lo haría yo, decidir si es seguro publicarlo, y actuar sobre ese criterio sin depender de que yo estuviera delante del teclado. Eso significaba tratar la revisión de código como el trabajo de un agente, no como el de un pipeline.
Construí un agente de Claude Code programado que corre cada día contra el repositorio del plugin. Cada ejecución:
- Lista todos los PRs abiertos.
- Lee el diff de cada uno.
- Mergea (squash + delete branch) los que superan sus criterios de revisión.
- Corrige triviales directamente, in situ, cuando es más rápido que un comentario de ida y vuelta.
- Comenta los que requieren intervención humana, explicando por qué.
- Envía un resumen por email de lo ocurrido.
La red de seguridad no es solo el criterio del agente — es lo que ya estaba alrededor: branch protection y versionado semántico estaban en marcha antes de que el agente empezara a mergear nada, así que un merge malo sigue teniendo que pasar las mismas puertas que pasaría el de una persona.
Dónde termina la autonomía
El agente decide qué puede mergear con seguridad, no todo. Los cambios no triviales — cualquier cosa que toque la lógica central de renderizado del plugin, cualquier cosa que el agente no pueda leer con confianza — reciben un comentario y revisión humana, no un merge. Ese límite es el verdadero trabajo de diseño aquí: un agente que mergea todo no es autónomo, es solo no supervisado, y un agente que escala todo no le ahorra tiempo a nadie. Afinar esa línea costó más iteración que la propia lógica de merge.
El piloto multiagente
Con el agente de revisión ya estable, piloté una segunda capa: un agente especializado en seguridad y otro de frontend/diseño de los bloques Elementor, ambos trabajando en paralelo sobre el mismo repositorio — uno vigilando patrones vulnerables en PHP, el otro revisando cómo se renderizarían realmente los nuevos bloques.
Está en pausa ahora mismo. Correr dos agentes sobre el mismo repo sacó a la luz un problema de coordinación que no había diseñado: comentarios solapados en el mismo PR, y ningún criterio compartido de prioridad cuando su feedback discrepaba. En vez de publicarlo tal cual, pausé el piloto para rediseñar cómo se pasan el testigo entre ellos — que es el estado honesto en el que está, no una funcionalidad terminada.
Resultado
- 100% de los PRs triviales mergeados de forma autónoma desde que el agente se desplegó — nada rutinario me espera ya a mí.
- Cero tiempo manual de merge en los cambios que el agente ya puede juzgar correctamente.
- El plugin se ha mantenido en producción en todos los entornos de cliente sin incidencias atribuibles a un merge autónomo.
Qué demuestra esto
Esto no es “usé IA para ayudarme a programar”. Es diseñar dónde termina la autoridad de un sistema autónomo, montar las barreras que sostienen ese límite (branch protection, versionado semántico, escalado a humano), y estar dispuesta a pausar una pieza — la capa multiagente — en el momento en que deja de ser fiable, en vez de publicarla rota. Es el mismo criterio que escala de “¿debería mergearse este PR?” a “¿debería publicarse esta funcionalidad?” en un equipo de cualquier tamaño.
