Hay un sesgo que conoce cualquiera que haya escrito algo: el propio texto siempre parece correcto. Leemos lo que quisimos escribir, no lo que escribimos. Con el código pasa igual. Y con los modelos de lenguaje, el efecto es aún más fuerte.
Un agente que acaba de escribir una función va a explicar, con gran convicción, por qué es correcta. Pedirle que revise su propio trabajo es pedirle que confirme lo que ya cree.
Dos agentes, dos objetivos
En Kabran, escribir y revisar son papeles separados, con instrucciones distintas.
El agente que ejecuta recibe la issue y tiene un objetivo: entregar lo que se pidió, con el cambio más pequeño que lo resuelve, dentro de los estándares de la casa. Termina abriendo un merge request.
El agente que revisa recibe solo el merge request y la issue. No vio el razonamiento de quien escribió, no sabe qué atajos se consideraron, no tiene apego a nada. Su objetivo es otro: encontrar lo que impide que eso entre.
El revisor no está ahí para estar de acuerdo. Está ahí para buscar lo que nadie vio.
La misma regla de los dos lados
Una revisión solo es justa si quien escribe y quien revisa usan el mismo criterio. Por eso existe una regla única, leída por los dos. Entre otras cosas, dice qué bloquea una entrega:
- criterio de aceptación ausente o entregado a medias;
- comportamiento roto o regresión;
- falla de seguridad, incluido un secreto o un valor de entorno fijo en el código;
- pantalla por debajo del piso de accesibilidad.
Y dice, con la misma claridad, qué no bloquea: un nombre mejor, una refactorización deseable, una optimización que no es crítica. Una revisión que reprueba por gusto es tan mala como una que aprueba todo.
Qué pasa cuando reprueba
El dictamen vuelve con el motivo escrito y vinculado a la línea exacta. El trabajo regresa para corrección, y la nueva versión pasa por la revisión otra vez — desde cero, sin “esto ya lo había visto”.
Si el mismo tipo de problema aparece varias veces, deja de ser un problema del código y se convierte en un problema del estándar. La pregunta pasa a ser: ¿qué instrucción faltó para que esto no ocurriera? Y la respuesta va a los rieles, no a la memoria de alguien.
Revisar no es desconfiar
Separar a quien escribe de quien revisa no es señal de que la IA sea mala. Es el mismo principio que cualquier equipo serio de ingeniería aplica entre personas. Nadie es lo bastante bueno para ser el único par de ojos sobre su propio trabajo.
La diferencia es que, en una fábrica que nació con la IA, se puede aplicar ese principio en todas las entregas, todos los días, sin que se vuelva un cuello de botella.