El merge solía ser la meta. Abrías un pull request, alguien lo revisaba, entraba, y el cambio estaba hecho. Los agentes de programación han movido esa línea sin hacer ruido. Cuando un agente toma un issue de Linear, escribe el código y abre un merge request mientras estás en una reunión, el merge deja de ser el final del trabajo: es el comienzo de todo lo que el merge toca.
El merge dejó de ser la meta
Un merge nunca es solo un merge. Cada cambio se apoya en los sistemas que lo rodean: el issue que ahora debería cerrarse, la documentación que desde esta mañana describe algo ligeramente falso, el CI un poco más rojo que ayer, las notas de versión que nadie ha escrito, la conversación de soporte que sigue esperando un fix que en realidad se envió hace horas.
Cuando una persona enviaba un puñado de cambios por semana, ese trabajo posterior cabía en los huecos. Cerrabas el issue mientras tenías el pull request abierto; te acordabas de la doc porque acababas de tocar el código. Cuando un agente —o una flota de ellos— envía muchos cambios al día, los huecos se desbordan. El código ya no es el cuello de botella. Lo es todo lo que viene después del código.
El modelo de mantenimiento no cambió
El desarrollo se aceleró. El mantenimiento no. Las herramientas que usamos para mantener un proyecto coherente siguen siendo en su mayoría manuales, y siguen dependiendo de que alguien se acuerde de usarlas en el momento justo:
- Un merge request entra, pero el issue de Linear que resuelve se queda abierto.
- La documentación sigue describiendo el comportamiento antiguo, y nadie sabe muy bien en qué página.
- El CI lleva una semana fallando de forma intermitente y todos han aprendido a ignorarlo.
- Un feature flag de hace tres meses no tiene responsable ni fecha de retirada.
- Soporte responde un ticket con un workaround para un bug que se corrigió el martes.
- Alguien pregunta qué salió en esta versión, y la respuesta honesta es "déjame leer el git log".
Nada de esto es nuevo, y nada de esto es realmente un problema del agente. Es la entropía habitual de un proyecto de software. El agente solo sube el ritmo hasta que el sistema informal que antes lo absorbía deja de dar abasto.
La limpieza a petición no escala
La solución obvia es pedirle al agente que también limpie, y puedes hacerlo. Menciona @taskgoblin en el merge request y dile que actualice la documentación, cierre el issue, redacte la nota de versión. Funciona. Pero depende del recurso más escaso de todo el ciclo: que una persona se acuerde de pedirlo, cada vez, en el momento justo.
El mantenimiento no es una tarea puntual; es un ciclo. "Revisar que la documentación esté al día" no es algo que se hace una vez. "Asegurarse de que los issues fusionados se cierren" no es algo que se hace una vez. Cualquier cosa que espere a que una persona note que toca ejecutar el ciclo se ejecutará de forma inconsistente, porque las personas notan de forma inconsistente, sobre todo cuando el sentido del agente era, precisamente, dejar de cargar con todo esto en la cabeza. La limpieza a petición mueve el trabajo al agente, pero deja la programación del trabajo exactamente donde estaba: en ti.
Por qué construimos las Loops
Una ejecución normal del agente la dispara un evento: la asignación de un issue, una mención, un nuevo pull request. Un Loop lo dispara el tiempo. Le das al agente una instrucción permanente y una cadencia —cada mañana de día laborable, cada lunes, el primero del mes— y se ejecuta solo, en un sandbox, con las mismas herramientas y el mismo acceso que cualquier otra ejecución.
La instrucción es toda la tarea, y las buenas se leen como una descripción de puesto más que como un deseo: qué mirar, en qué repositorio, qué hacer, qué no hacer y —la parte que la hace segura para correr sin supervisión— qué hacer cuando no hay nada que hacer, que es nada.
Cada día laborable a las 09:00, mira los merge requests fusionados en el último día en
grupo/repoy cierra cualquier issue de Linear que resuelvan y siga abierto. Si no hay ninguno, no hagas nada.
Eso es un ciclo de mantenimiento con responsable. No espera a que te acuerdes. Como una ejecución programada es una ejecución completa del agente, puede llegar hasta el final: no solo señalar la doc desactualizada, sino abrir el merge request que la arregla; no solo notar que hay issues que quedaron abiertos, sino cerrarlos, y luego reportar donde de verdad lo verás: como comentario en el issue de Linear, como mensaje en el canal de Slack que indicaste, o como correo si no hay mejor sitio.
Y como reutiliza todo lo que ya hace una ejecución normal, los bordes afilados están resueltos. El tiempo perdido se omite en lugar de recuperarse, así que un programador que estuvo caído una hora no despierta y te dispara cien ejecuciones atrasadas. Cada ejecución tiene su propio presupuesto y sus guardarraíles. Enviamos un conjunto de plantillas de inicio para exactamente estos ciclos —mantener issues y merges sincronizados, vigilar un CI que lleva demasiado tiempo en rojo, perseguir feature flags que sobrevivieron a su responsable, redactar notas de versión a medida que salen las cosas— porque los útiles son los mismos en casi todos los equipos. Tú rellenas tu repositorio y tu canal; los guardarraíles ya están escritos.
El trabajo del ingeniero sube un nivel
Debajo de todo esto hay una inquietud: que automatizar el mantenimiento signifique automatizar el criterio. No es así. Sube el criterio un nivel. Cuando los ciclos se ejecutan solos, dejas de ser la persona que se acuerda de cerrar issues y pasas a ser la persona que decide qué ciclos deben existir, cuáles son sus guardarraíles y qué significa "hecho" para cada uno. Revisas la instrucción permanente en lugar de hacer el recado.
Esa es, de todos modos, la versión más sénior del trabajo. El agente abarató escribir el código; lo que queda es decidir qué debe ser verdad sobre el sistema y asegurarse de que siga siendo verdad. Las Loops son cómo lo mantienes verdadero sin cargarlo todo en la cabeza: el agente crea el trabajo, y un ciclo permanente lo mantiene.
