Una casa que no armaste

Cada vez aparecen más equipos que dejan de hacer code review tal como lo conocíamos. La revisión humano-a-humano desaparece: el agente abre el PR, otro agente lo revisa, los tests automatizados corren contra cada cambio y todo se valida en ambientes de prueba antes de impactar en producción. Visto así suena razonable. Ahora que los agentes generan código a una velocidad que ningún humano puede igualar, la ceremonia tradicional del PR, con autor, reviewer humano, comentarios y rondas de feedback, parece un cuello de botella heredado de una época en la que escribir código era el problema más caro de resolver.

Y probablemente lo era. Pero antes de aceptar el cambio o rechazarlo de plano, vale la pena detenerse en una pregunta más básica que casi nadie está haciendo: qué estaba haciendo en realidad el code review todos estos años. Porque puede que lo que estemos dejando atrás no sea exactamente lo que creemos que estamos dejando atrás.

Cómo gestionar PRs en distintos proyectos no tiene una respuesta única, depende del contexto. En una POC con dos personas codeando es razonable aprobar al toque, porque el costo de la coordinación supera al de un eventual error y todo el sistema lo tienen ambos en la cabeza. En un proyecto largo, con seis devs, meses de scope y un producto en producción, la dinámica del PR pesa de otra manera. Hay piezas que dependen unas de otras, decisiones que se sostienen en el tiempo, gente que rota y gente que se incorpora. Esa diferencia es la que hace que valga la pena detenerse a pensar qué estamos eliminando cuando eliminamos el code review en proyectos del segundo tipo.

Si le preguntás a cualquiera para qué sirve un code review, casi todos van a contestar lo mismo: para garantizar la calidad. Otro par de ojos sobre el cambio, evitar que se vaya algo roto a producción, mantener un mínimo común de prolijidad.

Pero el PR siempre hizo bastante más que eso. La descripción del cambio y los comentarios del review terminaban siendo, sin que nadie lo planeara, una documentación implícita de la decisión técnica. Pero hubo algo todavía más profundo y más invisible: el PR sostenía un mapa mental compartido del sistema. Bastaba con que el código pasara por más de un par de ojos antes de mergearse para que se fuera armando, como subproducto silencioso, una foto colectiva de qué estaba construido, dónde, y de qué manera.

Cuando un humano escribía cada línea, ese mapa mental venía gratis. Construir el sistema y entenderlo eran la misma actividad. Revisar el PR de un compañero te obligaba a leer su código, y al leerlo te enterabas no solo de qué había hecho él sino de cómo había resuelto el problema, qué piezas del sistema había tocado y qué decisiones había tomado por el camino. El equipo terminaba con una foto razonablemente actualizada de lo que estaba construido, sin que nadie tuviera que sentarse a producir esa foto a propósito, y eso permitía que las conversaciones técnicas y de producto tuvieran resolución suficiente para ser útiles.

El agente rompe ese acoplamiento. Le tirás un requerimiento, apretás enter cinco veces, y termina mergeado un feature que capaz ni el que lo hizo terminó de leer. El código existe y funciona, pero el mapa mental del equipo, ese que antes se actualizaba como subproducto natural del trabajo, ya no se actualiza solo. Los PRs salen más rápido, los features se entregan en menos tiempo, las métricas de velocidad mejoran. Lo único que se pierde es algo que no estábamos midiendo y que dábamos por sentado.

Seguís siendo el dueño del proyecto, pero entrás al código y es una casa que no armaste. Hay muebles que no compraste y paredes en lugares donde antes había puertas, y aunque todo funciona, no sabés en qué cajón están los cubiertos. Te perdés en tu propia casa.

Esta pérdida no aparece en cualquier proyecto. En uno chico, en una POC o en un experimento de fin de semana, no es un problema serio. Si todo se rompe lo tirás y arrancás de nuevo, y la velocidad gana sobre el modelo mental porque no hay nada que defender. Lo construido es desechable, y por lo tanto el conocimiento sobre lo construido también lo es.

Donde el problema empieza a doler es en proyectos largos, con equipos grandes, con clientes que dependen del producto y con features que se construyen encima de features anteriores. Ese mapa mental compartido es, en proyectos así, lo que te permite tomar decisiones de producto con resolución. Cuando alguien propone una funcionalidad nueva, necesitás saber qué impacta, qué rompe y qué habilita, y para eso necesitás tener cargado en la cabeza no solo qué existe sino cómo funciona, por qué se decidió de esa manera y qué se descartó en el camino. Si nadie en el equipo tiene ese mapa cargado, terminás discutiendo en abstracto, hablando del módulo de notificaciones o de la parte de onboarding sin tener claridad real de qué hay adentro. Y la conversación se queda flotando, porque nadie entiende lo suficiente del sistema como para evaluar nada que se proponga.

Lo que hasta hace poco era un problema típico de juniors recién entrados al equipo, que tardaban semanas en construir ese mapa mental, ahora puede ser el problema de todo el equipo, incluyendo a los seniors que llevan años en el proyecto.

El cuadro se complica todavía más cuando producto está separado de tecnología. En equipos donde las dos áreas operan como funciones distintas, alguien define un feature en un documento de producto, un PM lo traduce en specs técnicas, un dev recibe ese spec y se lo pasa al agente, el agente codea sin que el dev lo lea con detalle, y el feature termina mergeado en producción.

En cada capa se pierde resolución, y eso no es nuevo. El teléfono descompuesto entre producto y tecnología existe desde que existen las dos disciplinas separadas. Lo que sí es nuevo es que antes había una capa que cerraba el loop al final de la cadena: el dev escribía el código y el dev entendía lo que estaba escribiendo, y si en algún punto algo no cuadraba con la intención original era el dev quien se daba cuenta, levantaba la mano y forzaba una conversación. Esa capa hoy está mucho más débil. El dev no escribe, el dev no lee con profundidad, y el agente no detecta el desfasaje porque entender la intención original no es su tarea, ni siquiera está en condiciones de saber qué cosa contaría como un desfasaje.

El feature original tenía una intención que en producto entendían bien, pero para cuando llegó al código esa intención había pasado por cuatro traductores humanos y un agente que llenó los huecos como pudo. Si alguien le pregunta al equipo que la construyó cómo funciona realmente, no va a saber responder. Y si le preguntás qué se descartó, qué se pensó y se rechazó, qué decisiones se tomaron en el medio, la respuesta va a ser todavía más pobre, porque eso ni siquiera está en el código que el agente escribió.

Y entonces aparece la pregunta que importa: si el PR ya no es el momento donde el equipo se mantiene alineado, ¿dónde es?

Una posibilidad es mover la alineación pre-código, a la discusión técnica antes del kickoff o a la spec misma. Suena lógico: si el problema es que el equipo no sabe qué se está construyendo, lo arreglamos hablando antes de construir. Pero ahí te chocás con un límite que es difícil de saltar. La spec captura intención, no aprendizaje. Las sorpresas que te llevás construyendo, las cosas que resultaron más difíciles de lo esperado, los caminos que probaste y descartaste, todo eso no lo podés escribir antes de empezar porque todavía no pasó. Y eso, antes, se capturaba en la descripción del PR y en los comentarios del review, en una documentación implícita que se generaba sola a medida que el trabajo avanzaba. Hoy, si nadie escribe esa parte deliberadamente, simplemente se evapora.

Otra posibilidad es mover la alineación post-deploy, a las demos, a la observabilidad o a los tests de integración. Esto sí funciona para algo, pero solo para una parte del problema. Te sirve para verificar el comportamiento del sistema, para confirmar que lo que se construyó hace lo que tenía que hacer. No te sirve para que el equipo entienda cómo está construido aquello que ven funcionar, ni cuáles fueron las decisiones que llevaron a esa construcción, ni qué piezas se pueden reutilizar y cuáles no. Verificar comportamiento es una cosa, mantener un mapa del sistema es otra, y se confunden con facilidad porque desde afuera las dos cosas se parecen a estar alineados.

La tercera posibilidad es aceptar que ese mapa mental compartido ya no se mantiene con una sola ceremonia y nunca más se va a poder mantener así. Hay que armar varias, cada una más chica que el code review original y cada una cubriendo una porción de lo que el PR cubría sin nombrarlo. Algo parecido a tener demos semanales que muestren lo nuevo, ADRs vivos que vayan registrando las decisiones de fondo a medida que se toman, walkthroughs ocasionales del sistema en los que alguien que no construyó algo lo escuche y lo cuestione, momentos de pair-thinking antes de los cambios importantes. Una infraestructura humana de varias capas para reemplazar la única capa que antes alcanzaba sola. Es una solución que cuesta más, que requiere disciplina y que probablemente vaya a chocarse con la presión de velocidad que motivó delegarlo a un agente en primer lugar. Pero quizás sea inevitable.

En el fondo, lo que está pasando es que los humanos vamos a ser cada vez más responsables del qué y cada vez menos del cómo. El código lo va a escribir la máquina, pero la decisión de qué se construye, por qué, y si lo que se construyó tiene sentido sigue siendo nuestra. Y mientras haya un humano en el proceso, alguien que tenga que responder por el sistema, vamos a tener que diseñar incentivos y rituales que obliguen al equipo a no perder la foto de lo que están construyendo.