Integración y entrega continua es donde el control deja de depender de que alguien se acuerde. Pero un pipeline armado para código escrito a mano no cubre lo que cambia cuando el que escribe es un agente.
Un pipeline no revisa código. Comprueba que la revisión ya ocurrió — y se planta si el contenido cambió después.
Un cambio no sale de un salto: pasa por puntos. Cada uno establece algo distinto, y el error más caro es pedirle a uno lo que le corresponde a otro. Estos son los nombres que usa gentle-ai, y sirven igual si tu pipeline se llama de otra forma.
post-applyQue el cambio está terminado y que lo miró algo que no es quien lo escribió.
Saltearlo porque “lo fui mirando mientras lo escribía”. El que escribe es el peor ubicado para juzgar: el mismo razonamiento que produjo el error es el que está revisando.
pre-commitQue lo que vas a guardar es exactamente lo que se revisó.
Poner acá un formateador que modifica archivos. Si toca un byte, lo que se revisó ya no es lo que se commitea, y el comprobante deja de aplicar. Normalizá antes de revisar, no después.
pre-pushQue lo que está por salir de tu máquina sigue siendo el contenido que se revisó, y que pasa entero y no por partes.
Repetir acá todo lo que ya corriste en el commit. El gate se vuelve lento, la gente lo saltea con una bandera, y a partir de ahí no existe.
pre-prQue el cambio es revisable por una persona, y que la evidencia de CI corresponde a ese contenido y no a otro.
Abrir un PR de dos mil líneas y esperar que la revisión humana encuentre lo que el pipeline no buscó. Un PR así no se revisa: se aprueba.
releaseQue lo que se publica es el árbol exacto que pasó todo lo anterior, y que la evidencia sigue siendo fresca.
Etiquetar una rama en vez de un commit. Una rama se mueve; un release no puede moverse después de publicado.
Nada de esto es nuevo del todo. Lo nuevo es la frecuencia: comportamientos que antes aparecían una vez por sprint ahora aparecen varias veces por día, y a esa frecuencia dejan de ser anécdotas y pasan a ser el sistema.
Cuando el pipeline falla, la salida más barata para un agente es tocar el test hasta que pase. Es la reparación correcta en una minoría de los casos y la que va a elegir en el resto. Un fix de CI se revisa al revés que otro cambio: primero mirás qué tocó, después si pasa.
Un test intermitente enseña que reintentar funciona. Un agente que puede reintentar lo va a hacer, y va a llegar a verde sin haber arreglado nada. Un test flaky dejó de ser una molestia: es una puerta abierta.
Generar cambios se abarató, así que hay más PRs, más chicos y más seguido. El límite del equipo pasó a ser la cola de CI y la capacidad de revisión. Optimizar la parte de escribir código ya no mueve la aguja.
Si corrés agentes dentro del pipeline —revisión, triage, generación de tests— cada push tiene un precio variable además del tiempo. Sin un presupuesto declarado, el gasto lo descubrís a fin de mes.
El agente escribe código que pasa lo que hay. Si tu pipeline solo corre lint y tests, estás midiendo si el código es plausible, no si es correcto. Lo que agrega señal real es lo que el agente no puede anticipar: tipos estrictos, contratos, y una revisión que no la haga quien escribió.
El criterio no es la importancia, es el tiempo y el determinismo. Local va lo rápido y lo que da siempre el mismo resultado; en CI va lo lento, lo aislado y lo que necesita un entorno limpio. Un gate local que tarda dos minutos se saltea con una bandera y todos lo sabemos.
Nada de esto reemplaza el juicio. Un gate determinista te dice que algo se rompió; nunca te va a decir que estás construyendo lo que no había que construir. Eso sigue siendo tuyo.