Cómo hacer migraciones y tareas en lote con agentes de código

TLDR: El trabajo que nadie quiere (migrar veinte repositorios a la versión nueva, actualizar la librería en todo el monorepo, aplicar el mismo cambio mecánico en cien sitios) es donde los agentes rinden sin discusión. El método: una tarea piloto que define el patrón, Devin o Conductor para escalar en paralelo, y verificación por pruebas automáticas más muestreo humano. Lo que revisas no son veinte cambios, es un patrón aplicado veinte veces, y esa diferencia es todo el método.

El aviso de seguridad que lleva tres semanas en el tablero

La librería sacó su parche hace tres semanas y la dependencia vulnerable está en veintitrés servicios. Cada uno son quince minutos de trabajo mecánico: cambiar el import, ajustar dos llamadas que cambiaron de firma y ver pasar las pruebas. Nadie lo ha hecho porque veintitrés por quince minutos es día y medio, día y medio no entra en ningún sprint, y este es el tipo de tarea que no luce en ninguna demo. Así que sigue en la columna de pendientes mientras el aviso ya es público.

Ese es el trabajo del que habla esta guía. No es difícil, es que es mucho, y coordinarlo siempre ha costado más que hacerlo. Los agentes cambian esa cuenta y solo esa: el criterio de qué cambiar y la responsabilidad de lo que se fusiona siguen donde estaban.

La condición de entrada es que el cambio siga un patrón. Lo creativo y lo ambiguo van por la guía del primer proyecto con agentes, y si lo que tienes son tareas distintas que quieres correr a la vez, eso es trabajo en paralelo.

El recorrido, y quién responde en cada tramo

Fíjate en dónde está el color. Solo un tramo de los cuatro lo hace la máquina, y es el que parecía el trabajo entero. El que más lotes deja muertos es el último, porque el agente entrega veintitrés pull requests y ahí se acaba su parte.

1. Identifica el trabajo que es de lote

Se reconoce por su estructura: el mismo cambio conceptual aplicado en muchos sitios, donde cada aplicación pide adaptación local pero el patrón es idéntico. Los clásicos son migrar de versión de framework o librería, actualizar dependencias con cambios de API, renombrar de forma transversal, añadir el mismo instrumento (métricas, registros, manejo de errores) en todos los servicios y las correcciones de seguridad que tocan el mismo patrón en todas partes.

Lista los sitios afectados con dos columnas más: quién mantiene cada uno y si sus pruebas pasan hoy. El número convierte la decisión en una cuenta, y esas dos columnas evitan las dos sorpresas del paso 4.

2. Define el patrón con una tarea piloto

El error caro es lanzar el lote entero a la primera. El método empieza con un piloto: eliges el caso más representativo y lo resuelves con Claude Code en modo supervisado, atento a qué decisiones hubo que tomar y qué casos borde aparecieron.

De ahí sale el activo que escala, que es la descripción del patrón. No «migra a la versión nueva» sino el documento concreto: qué se cambia, en qué orden, qué casos especiales existen, cómo se comprueba cada uno y qué hacer cuando aparece algo que nadie previó. Se escribe en un fichero y no en el chat, porque cada réplica arranca sin recordar nada de la anterior y lo que no esté escrito no existe para la número doce. Es el mismo problema de memoria que trata la guía de contexto de producto para agentes.

3. Escala con la arquitectura adecuada

La escala tiene dos vías según dónde viva el trabajo.

Si está repartido en muchos repositorios, Devin es la pieza construida para eso: lanzas el mismo patrón documentado sobre cada repositorio y recibes un pull request por sitio. Parte de 20 dólares al mes sobre un plan gratuito de entrada, y el consumo por encima depende del volumen, así que la cifra que importa es la de tu piloto y no la de la página de precios.

Si se queda en tu máquina, Conductor corre varios agentes de Claude Code a la vez, cada uno en su copia de trabajo aislada. Dos límites antes de planificar con él: solo funciona en macOS, y su oficio es paralelizar tareas en tu equipo más que barrer veinte repositorios remotos. Es gratis, y toca decir lo que suele omitirse, que corre sobre Claude Code y eso parte de 17 dólares al mes. Llamar gratis a la vía local solo vale si esa suscripción ya la pagabas.

Elegir orquestador es una decisión propia y la tiene la guía de agentes en paralelo, con las vías de nube que esta no cubre. Lo que sí es de aquí es la regla que vale con cualquiera: lanza en tandas de cinco, no de veinte. Un fallo de patrón detectado en la primera tanda cuesta cinco correcciones. Y si lo que decide es la factura, el desglose está en cuánto cuesta programar con IA.

4. Verifica por muestreo y automatización

Revisar veinte pull requests línea a línea devuelve el ahorro por donde vino. La verificación de lote tiene dos capas y ninguna sustituye a la otra.

La automática cubre el cien por cien. Las pruebas de cada repositorio tienen que pasar, y si el cambio admite una comprobación específica (el script que verifica que el patrón viejo ya no aparece, la compilación con la versión nueva), se escribe una vez y se ejecuta en todo el lote. Es parte del patrón, no un extra que se hace si da tiempo.

La humana va por muestra dirigida: lectura completa de dos o tres réplicas y revisión de perímetro en el resto, mirando qué ficheros tocó cada una. Elige la muestra por riesgo real, que casi nunca es el repositorio más grande sino el que más se desvió del patrón según el propio agente. La técnica está en la guía de revisar código de IA, y si el cambio toca autenticación, dependencias o datos, la pasada que corresponde es la de seguridad del código generado.

Las cuatro excepciones que aparecen siempre

Los lotes se tuercen casi siempre por lo mismo, y ninguna de las cuatro es un fallo del agente:

El repositorio que ya estaba roto. Lanzas veintitrés y tres fallan las pruebas. No las ha roto el cambio, estaban rojas desde antes y nadie lo sabía. Se resuelve antes de empezar, ejecutando la suite de los veintitrés el día del inventario. Los que ya estén en rojo salen del lote y se apuntan en su propia lista, porque si entran vas a gastar la revisión depurando un fallo viejo y culpando al agente.

El que tiene la migración hecha a medias. Alguien la empezó a mano hace meses y lo dejó por la mitad, así que conviven el patrón viejo y el nuevo. El agente, que busca el viejo, «arregla» hacia atrás lo que ya estaba bien. Se resuelve con la regla del alto en el documento del patrón, y ese caso es el que justifica que el patrón se escriba en vez de explicarse en un mensaje.

El fork con parches locales. El repositorio raro, el que se separó hace dos años y lleva cambios que no están en ningún sitio. Ahí el patrón falla de formas que no se parecen entre sí. Márcalo en el inventario para lectura completa y sácalo de la cuenta de tiempo, porque va a costar como cinco.

El que pasa las pruebas y cambia el comportamiento. El lote entero en verde y aun así algo se movió: un formato de serialización, una zona horaria, un redondeo. Es la excepción cara porque no la ve ninguna capa automática. Se resuelve en el piloto, escribiendo en el patrón qué es lo que las pruebas de ese proyecto no cubren, y usando esa frase como guion de la muestra dirigida.

Qué mirar para saber si el método funciona

Tres números que cuentas tú, sin pedirle una métrica a nadie:

Cuántas réplicas salieron a la primera, sin tocar el patrón ni el resultado. Si en la tanda uno salen cinco de cinco, sube el tamaño de tanda. Si salen dos, el patrón está mal escrito.

Cuántas veces cambiaste el patrón después de lanzar. Es la medida directa de si el piloto valió para algo, y uno que cambia tres veces se hizo con prisa.

Cuántos pull requests siguen abiertos a los siete días. Este es el que nadie mira y el que de verdad dice si el lote sirvió. Veintitrés ramas abiertas no son una migración hecha, son deuda con otro nombre y con conflictos madurando.

La frontera de aprobación

El agente abre pull requests y no fusiona ninguno, y esto no es una preferencia de estilo.

La CI en verde es una puerta, no una aprobación: dice que nada de lo que sabíamos comprobar se ha roto, que es bastante menos que decir que el cambio está bien. Cada pull request necesita un responsable con nombre en ese repositorio, y por eso el inventario del paso 1 lleva la columna de quién mantiene cada sitio. Un repositorio sin dueño identificado no entra en el lote, porque su pull request se va a quedar abierto para siempre.

Conserva tres cosas por lote: el documento del patrón, qué réplicas se leyeron enteras y quién aprobó cada fusión. Con eso, la pregunta de dentro de seis meses («¿esto quién lo cambió y con qué criterio?») se responde mirando. Todo el sector, en IA para desarrollo de software.

Preguntas frecuentes

¿Qué tamaño de lote justifica este método?

Desde cinco réplicas, el piloto más las tandas ya compensa frente a ir uno a uno. Por debajo, montar el inventario y el documento del patrón para tres sitios cuesta más de lo que ahorra.

¿Devin o Conductor para lotes?

Devin para muchos repositorios en la nube. Conductor para el lote dentro de tu entorno, sobre la suscripción de Claude Code que ya tienes. Si dudas, empieza en local: la vía cara se justifica cuando el inventario pasa de los diez sitios.

¿Cuándo NO merece la pena montar un lote?

Cuando el patrón tiene más excepciones que casos limpios, y eso lo sabes al terminar el piloto. También cuando los sitios pertenecen a muchos equipos, porque entonces el cuello de botella no es hacer el cambio sino conseguir veinte aprobaciones, y eso no lo acelera ningún agente. Y cuando cada sitio pide una decisión de producto propia, que ya no es trabajo mecánico aunque lo parezca.

¿Y si en mi empresa no aceptan pull requests escritos por un agente?

Pasa, y no siempre es una manía: detrás suele estar que nadie quiere revisar código del que no responde una persona. La salida es que el pull request lo firmes tú, que el cuerpo diga con qué patrón y qué herramienta se generó y qué réplicas se leyeron enteras, y empezar por los repositorios de tu equipo.

¿Cuánto cuesta un lote de veinte migraciones?

Con Conductor, lo que ya pagas por Claude Code, que parte de 17 dólares al mes. Con Devin, que parte de 20 dólares al mes, la cuota más el consumo por encima del plan, que depende del volumen y por eso se estima con el piloto. Ninguna de las dos cifras incluye lo que de verdad cuesta un lote, que son las horas de revisión de la muestra.