En la mayoría de los equipos, ningún PR avanza sin el OK de otra persona. En Mango no. Cada ingeniero decide, PR por PR, si confía en los rieles y avanza o si pide un humano. El review no es un peaje obligatorio: es una decisión de criterio.
Suena arriesgado hasta que ves por qué. Cuando buena parte del código lo escriben agentes, exigir review humano en todo no escala: se produce más rápido de lo que un humano puede leer, y el “revisor obligatorio” termina siendo un sello de goma —aprueba sin mirar— o un cuello de botella que se traga la velocidad. Ninguna de las dos protege nada.
Los rieles
Confiar en los rieles no es confiar en la suerte. Los rieles son una capa versionada
—la llamamos mango-agentic— que se propaga a cada repo: tests obligatorios, evidencia
real de que corrieron (no “debería andar”), estándares de seguridad y de manejo de
dinero, un contrato entre las fases de los agentes, y un check que mide el riesgo del PR.
Se escribe una vez y se aplica en todos lados. Eso es lo que un ingeniero deja que lo
respalde cuando decide no llamar a nadie.
El agujero: el criterio no está escrito
Acá está lo incómodo, y lo vimos escribiendo esto: el criterio para decidir cuándo pedir un humano no estaba escrito en ningún lado. Vivía en la cabeza de cada uno. Para un equipo que escala con agentes eso es deuda: si la regla es “confiá en los rieles o pedí un humano”, cuándo pedirlo no puede ser folklore.
Así que lo escribimos. Por default decide el ingeniero; y hay un piso chico que no se negocia: lo irreversible, que los rieles no pueden deshacer solos — la lógica de movimiento de dinero y las operaciones destructivas en producción. Es nuevo: todavía no sabemos si el piso quedó en el lugar justo, y eso lo vamos a ir midiendo en vez de adivinarlo.
Por eso prendí el gate: para medir, no para frenar
Antes de escribir ese criterio quería un dato: ¿cuántos de nuestros PRs ya son demasiado grandes para que un humano los revise, aunque quisiera? Ese techo existe y está estudiado: por encima de ~400 líneas la detección de bugs de una persona se desploma (el clásico dato de SmartBear, que en mi caso llegó vía Gentleman). Es la capacidad de un revisor humano, no un número que inventamos.
Así que prendí el check de tamaño en modo aviso —no bloquea, mide— con esa línea. Y en dieciocho meses de nuestro git el PR típico pasó de ~4 líneas a más de 100, y la cola sobre 400 de un dígito a ~30%. Es correlacional (crecimos, hay más repos, más agentes), pero la lectura no está en duda: una porción creciente de lo que mergeamos ya está por encima de lo que un humano podría revisar aunque se sentara a hacerlo. En esos PRs estamos confiando en los rieles — lo hayamos decidido conscientemente o no.
Lo que aprendimos
Cuando el review humano es opcional, dos cosas dejan de ser opcionales. Una: el criterio de cuándo pedirlo tiene que estar escrito, no en la cabeza de cada uno. Dos: los rieles tienen que ser lo bastante buenos como para cargar el peso que el humano ya no carga — y su techo real (cuánto puede revisar bien un agente, no un humano) es lo próximo que hay que medir, no heredar del 400.
El consejo barato: si estás dejando que la gente avance sin review —y con agentes, tarde o temprano lo vas a hacer— no lo dejes implícito. Escribí cuándo se confía en los rieles y cuándo se llama a un humano, y hacé los rieles dignos de esa confianza. El 400 te dice cuándo un humano ya no alcanza; no te dice en quién confiar cuando eso pasa. Eso lo decidís vos — y conviene decidirlo en voz alta.