El cuello de botella que nadie se espera
Pregúntale a la mayoría qué limita la velocidad de publicación de software con un agente de IA y te van a decir lo obvio: qué tan rápido escribe la IA el código. Compra más capacidad, genera más código, publica más seguido.
Ahí no está el límite. Y lo sé porque vivo del otro lado.
El sistema que tengo en mente es la plataforma de registro que mi colaborador Marek y yo mantenemos en funcionamiento para un campeonato mundial de robótica: dos voluntarios, con empleos de tiempo completo en otro lado, y varios pull requests al día. Durante una ventana de registro en vivo, eso de “mañana lo arreglamos” no existe; hay operadores de verdad que dependen de la plataforma en ese preciso momento.
La generación de código nunca fue nuestro cuello de botella. El cuello de botella —lo que de verdad determina qué tan rápido puedes publicar sin arriesgar— es qué tan rápido puedes confiar en lo que el agente escribió. Generar sale barato hoy. La confianza no. Y la confianza se construye en un solo lugar: la revisión.
Ese es el argumento de este texto y lo defenderé sin rodeos. En la ingeniería asistida por IA, la revisión es el producto. No un palomeo al final. El evento principal. (Si quieres el replanteamiento de fondo detrás de esto —por qué el trabajo del ingeniero se movió a los dos extremos de la obra—, lo desarrollé en Del vibe coding a la ingeniería de IA.) Esta es la maquinaria que lo hace realidad.
Lo que “revisar” deja de significar
La revisión de código tradicional se basa en una sola pregunta: ¿el código que se ve en la pantalla se ve bien? Para un cambio hecho con IA, esa pregunta se rompe calladita por dos razones.
Primero, el volumen. Cuando un agente produce cientos de líneas por minuto, leer línea por línea deja de escalar. Te pasarías el día entero entrecerrando los ojos ante un código que parece razonable.
Segundo, y peor: el código puede verse completamente correcto y aun así estar mal —mal de una forma que no vive en ninguna línea en particular, sino en la distancia entre lo que el código hace y lo que en realidad querías. Esos son los errores que se publican. Pasan la prueba del ojo precisamente porque la IA es muy buena para producir código que la supera.
Así que la pregunta tiene que cambiar. Ya no “¿Esto se ve bien?”, sino: "¿Esto hace lo que decía el plan, ni más ni menos, y qué le pasa a la gente de verdad cuando corre?" Responder eso bien, rápido y de forma repetible: ahí está la disciplina. Todo lo que sigue es cómo lo volvemos manejable.
La revisión más barata ocurre antes de que exista una sola línea
Todo lo que he dicho hasta aquí da por hecho que hay código que revisar. Pero la revisión de mayor palanca ocurre antes: antes de que el agente haya generado nada.
Mira la economía del asunto. Si el enfoque está mal, cacharlo en el plan te cuesta una frase: “No toques ese módulo; la restricción que se te está pasando es esta.” Cachar ese mismo enfoque equivocado después de que el agente produjo una solución completa, pulida y convincente te cuesta el diff entero y, peor todavía, te cuesta las ganas de conservarlo, porque ahí está y se ve terminado. El costo hundido pesa de verdad, aunque lo hundido haya sido barato de generar. Una solución convincente pero equivocada es la más difícil de rechazar cuando ya la tienes enfrente, lista.
Por eso, la primera compuerta de revisión no es el código. Es el plan. Antes de que el agente escriba una línea, un humano lee el enfoque propuesto y hace preguntas orientadoras: ¿este es siquiera el cambio correcto? ¿El alcance está bien? ¿Cachó la restricción que no está escrita en ningún lado? Un plan equivocado que se caza aquí es una plática de dos minutos. Ese mismo plan equivocado, una vez cazado, es un día que ya no recuperas.
Por eso, planear y revisar son el mismo movimiento visto desde dos lados. El plan que describí en Del vibe coding a la ingeniería de IA no es solo cómo le pasas el encargo al agente; es lo más temprano y barato que puedes revisar y la revisión que menos te puedes permitir saltarte. La revisión se corre a la izquierda, antes de que el código exista. Todo lo que sigue es cómo revisas lo que viene después de esa compuerta.
Ajusta el escrutinio al riesgo
La primera regla es la menos vistosa y la más importante: no revises todo de la misma manera.
Corregir una línea de texto y cambiar cómo se les da acceso a los usuarios no son el mismo animal, y tratarlos igual es la receta para acabar quemado o descuidado, casi siempre las dos cosas. Por eso el esfuerzo de revisión va por niveles, según el cambio:
- Un cambio trivial —unas cuantas líneas, sin tocar datos ni permisos— requiere pruebas y un visto bueno. Nada más. La ceremonia aquí es un desperdicio.
- Un cambio mediano lleva la pasada estructurada completa.
- Un cambio grande o transversal —un módulo nuevo, un cambio de esquema, cualquier cosa que toque accesos o dinero— lleva el escrutinio más pesado que tenemos, más de una vez.
Suena a sentido común. Casi nadie lo hace a propósito. La recompensa es que gastas tu energía de revisión donde de verdad está el riesgo, que es la única forma en que un equipo de dos personas sobrevive a un ritmo de varios PR al día sin que algo termine por tronar.
Muchos revisores, no un solo revisor con muchos sombreros
Aquí va la parte que más me costó interiorizar y que es la que más me gustaría que otro ingeniero me robara.
Cuando revisas un cambio serio, quieres que lo miren desde ángulos de verdad distintos: ¿respeta la arquitectura y se queda dentro del alcance? ¿Cuál es el radio de impacto si falla y el rollback es real? ¿De verdad entrega lo que quería quien lo pidió? Quien herede este código en seis meses, ¿podrá leerlo?
El atajo tentador es pedirle a un solo revisor —humano o IA— que “cubra todo eso”. No lo hagas. Un solo revisor al que encasillas en cuatro perspectivas te entrega un resumen, no una revisión. Vale más o menos como una perspectiva de las cuatro, porque una sola pasada con un solo contexto solo puede sostener cierta cantidad de foco a la vez, y va a privilegiar en silencio el ángulo que notó primero.
Lo que sí funciona son pasadas independientes, cada una con contexto fresco y una sola chamba. Cuatro revisores, mirando con lupa una pregunta cada uno, le van a ganar en cachadas a un revisor que le echa un ojo a las cuatro, todas las veces. Todo el valor está en la independencia. En el momento en que los colapsas para ahorrarte esfuerzo, tiras a la basura justo lo que hacía que valiera la pena revisarlos.
Mete a un revisor que no comparta tus puntos ciegos
Hay un segundo tipo de independencia, y es la que yo llamaría nuestra arma secreta: en los cambios más riesgosos metemos una segunda IA de otro proveedor —otro modelo, entrenado de forma distinta, con otros instintos sobre qué es sospechoso.
La razón es sencilla y un poco humillante. Todo modelo tiene puntos ciegos y, si tu autor y tu revisor son el mismo modelo, comparten esos puntos ciegos exactamente. Un revisor que piensa como el autor no es una segunda opinión; es un eco. Un modelo de otro linaje discrepa en puntos útiles. Marca cosas que el nuestro dejó pasar, precisamente porque a él no lo entrenaron para dejarlas pasar.
Esto no es “que la IA revise a la IA y ya, listo, seguro”. Es el instinto opuesto: dar por hecho que tu herramienta principal tiene un sesgo y reclutar a propósito a un revisor que no lo comparta.
La prueba: dos errores que pasaron la prueba del ojo
Mencioné dos cachadas en Del vibe coding a la ingeniería de IA. Aquí va lo que de verdad enseñan sobre en qué parte de la maquinaria se cachó cada una.
El primero fue un error de privacidad silencioso: una clase de usuario podía ver una rebanada de datos que le pertenecía a otro. Era invisible en el diff —cada línea se veía correcta— porque el error no estaba en la lógica del código; estaba en lo que el sistema en marcha le mostraría a cierto tipo de usuario. En nuestra primera pasada, al leer el cambio en sus propios términos, no lo vio. La cachada vino de una pasada de otro proveedor que hizo lo no obvio: rastreó, actor por actor, lo que cada tipo de usuario vería en pantalla. Leyó el comportamiento, no las líneas. Eso es exactamente para lo que sirve la capa de otro proveedor: ver lo que la mirada del autor no vio.
El segundo fue más sutil. Una etiquetita de “Nuevo” —de esas que señalan los elementos que cambiaron hace poco— dejaría de aparecer en silencio, como resultado de un cambio en cómo se agrupaban las actualizaciones. Sin error. Sin prueba fallando. Nada mal en el código tal como estaba escrito. Era una regresión que solo se observaba en el comportamiento renderizado una semana después. Un revisor vio correr el comportamiento hacia adelante en su cabeza: imaginando el estado del sistema la próxima semana, no solo leyendo el estado del archivo hoy.
Ninguno de los dos se encontró mirando el código con más ganas. Los dos se encontraron observando el comportamiento desde un punto de vista que el autor no tenía. Ahí está todo el juego.
El ciclo, y el único paso que nunca automatizamos
Junto todo, una revisión seria es un ciclo: las pasadas independientes sacan a la superficie los problemas, los problemas se arreglan y —en los cambios más pesados— le das otra vuelta, porque los arreglos mismos merecen que los mires. La IA desempeña un papel enorme en ese ciclo. Redacta las pasadas, propone los arreglos, escribe e incluso commitea el código.
Pero el ciclo termina en un solo lugar que se mantiene tercamente humano: el merge. Nada se mergea solo. Ningún cambio llega al sistema del que depende gente de verdad sin que una persona decida que así debe ser; la persona cuyo nombre figura en esa decisión cuando alguien pregunta después: “¿quién publicó esto?”. El agente escribe y commitea durante todo el día. Un humano mergea. Ese único paso sin automatizar es donde reside la rendición de cuentas y la razón por la que la velocidad no me da miedo.
Lo que aprendí: cuando dejé de tratar la revisión como el impuesto que pagas después del “trabajo de verdad” y empecé a tratarla como el trabajo, toda la economía de la ingeniería asistida por IA se volteó. Los errores que se habrían publicado y que habrían costado un segundo arreglo —y la confianza de un cliente— se cazan antes de salir del edificio. La atención humana, que es escasa, se va al juicio y la máquina carga con la tecleada.
Por qué importó: es la única razón por la que dos voluntarios pueden, con responsabilidad, correr un sistema para miles de personas a un ritmo que antes exigía un equipo completo. No porque generemos código rápido. Porque confiamos en él rápido, y construimos la maquinaria que se gana esa confianza.
Si Del vibe coding a la ingeniería de IA planteó la afirmación de que el trabajo del ingeniero se trasladó a la revisión, esto es la prueba de que vale la pena hacer ese movimiento. En un texto posterior me pongo concreto sobre la infraestructura poco glamorosa —la memoria, los guardarraíles, una habilidad de revisión— que vuelve a un agente lo bastante confiable para correr así (El prompt está sobrevalorado), y más adelante todavía, qué se sintió al apuntar todo esto al sistema que hace correr una competencia de IA de talla mundial (La competencia de IA que corría sobre hojas de cálculo).
Por ahora, una línea para llevarte:
Generar sale barato. La confianza es el producto. Construye la maquinaria que la fabrica y deja a un humano en el merge.