La confianza no vive en el Code Review

La puerta en la que te convertiste

Los agentes escriben código más rápido de lo que cualquiera puede leerlo. Esto no es un pronóstico; es la línea base ahora. Un solo agente, en una tarde, entrega más código del que un equipo lee con cuidado en una semana. El code review asumió en silencio que escribir y leer ocurrían a la misma velocidad. Por primera vez, no es así.

Así que obtienes dos malas opciones. Mantén la línea y lee todo, y te conviertes en el cuello de botella detrás del cual todo el equipo hace cola. Déjalo pasar y la revisión se convierte en un sello. La mayoría de los equipos eligieron en silencio el sello. Lo peor no son los bugs que se escapan; un bug perdido es recuperable. La falsa confianza no lo es, y se fabrica en un calendario. El sello sigue produciendo la sensación de confianza, y tú envías basándote en esa sensación. No estás fallando en construir confianza. Estás construyendo una falsa.

Pero da un paso atrás, porque la puerta nunca fue el punto. Lo que necesitas no es la lectura. Es el control sobre el proyecto y la confianza fundamentada en él, la confianza sostenida de que sabes lo que estás enviando. Leer el diff solo fue siempre el proxy, confundido con la cosa misma. Lo que no puede ser externalizado es el control y la confianza. Esos siguen siendo tuyos. La lectura puede ir a quien, o lo que, esté mejor posicionado para hacerla.

No puedes escribirlo, así que no puedes leerlo

Comienza con por qué tu lectura alguna vez valió algo, y no es porque seas cuidadoso. Una revisión es tan buena como el desarrollador que la hace, y lo que hace bueno a un desarrollador es una cosa: sus manos están en el código lo suficientemente a menudo como para mantener sus detalles vivos. Esa comprensión viva es el motor de una revisión; la lectura es solo donde se muestra. Quítala y la lectura es movimiento vacío, ojos moviéndose sobre líneas.

La era de los agentes te saca de ser ese desarrollador, por una razón que surge en dos formas: tú y un agente no pagan por el código de la misma manera. El modelo de costos es diferente, y todo se sigue de eso.

En tiempo real, la brecha se lee como velocidad. Un agente itera a costo marginal casi cero; un humano escribiendo a mano entre ellos se convierte en el carril lento detrás del cual el trabajo espera. El movimiento honesto es detenerse y dejar que los agentes corran, y en el momento en que lo haces, tu comprensión viva se desvanece, porque ya no la estás construyendo.

Sobre la base de código, la misma brecha se lee como coherencia, y esto se mantiene incluso para un humano lo suficientemente rápido para seguir el ritmo. Una base de código es la cristalización de los mil pequeños juicios de un modelo de costos: si una duplicación merece una refactorización, cuánto logging vale el ruido, dónde cae realmente un límite. Los agentes sostienen ese rigor uniformemente, sin la fatiga o el aburrimiento que lleva a un humano cansado a cortar el logging o saltarse la refactorización. Un humano entrando con la mano no está escribiendo peor código, solo código optimizado para un modelo de costos diferente, y dejarlo caer en un sistema afinado para otro divide la coherencia que hizo al sistema legible. El alto nivel sigue siendo tuyo: para qué es el sistema, a dónde puede ir, qué riesgos vale la pena prever, qué trade-offs vale la pena hacer. El grano de implementación debajo se asienta en quien sea que esté pagando por el código.

Dilo claramente, dentro de un régimen específico hacia el que estamos construyendo en lugar de uno que ya gobierne en todas partes: una vez que un proyecto se ha vuelto nativo de agentes, con agentes al menos tan fuertes como tú en el dominio y una base de código ya en su grano, un humano ya no puede realmente escribir el código, ni por ritmo ni por grano. Y un humano que no puede escribir el código no puede mantenerlo lo suficientemente vivo para revisarlo. No es una ley de la naturaleza, pero dentro de ese régimen la conclusión es firme: sigue revisando y estás pasando tus ojos sobre líneas que ya no tienes la posición para juzgar. También es por qué, cuando los agentes no han acelerado tu proyecto, el cuello de botella es casi siempre el único humano que todavía está escribiendo y leyendo a mano. No la confianza, no el sentido de dirección; esos se quedan. El cuello de botella es la mano todavía en el teclado.

Nada de esto es nuevo; la era de los agentes solo hizo imposible ignorarlo. La confianza nunca vivió en el code review, no ahora y no antes de él. La persona que dirige un proyecto grande no lee el código: ¿cuándo fue la última vez que el ingeniero más senior que conoces leyó, línea por línea, el sistema del que es responsable? Dirigen basándose en la confianza en las personas debajo de ellos y una lectura de la arquitectura aproximada, y nadie llama a eso imprudente. La lectura línea por línea era algo que los niveles inferiores podían permitirse, y el permitirse se confundió con el confiar. La era de los agentes solo empuja a cada nivel a la posición en la que la cima siempre estuvo.

Entonces, ¿de dónde vino la confianza? De un autor con el que habías trabajado lo suficiente como para predecir, una suite de pruebas que se sostenía bajo carga, un compañero que había visto el sistema correr cien veces, una beta que volvió limpia, dashboards silenciosos a través de tres releases. El code review siempre fue uno de los canales más débiles en ese conjunto. Lo que seguía insinuando, y nunca entregaba del todo, era una respuesta a una pregunta: ¿el sistema como un todo todavía se mantiene unido? Esa pregunta no desaparece cuando el volumen sube. Se vuelve más aguda, y necesita un instrumento que nunca fue el diff.

Código más rápido, putrefacción más rápida

A medida que un sistema envejece bajo el cambio, el número de programas que podrían pasar por el tuyo sigue creciendo. En un sistema joven y ajustado, los sobrevivientes son casi el mismo programa. Déjalo envejecer sin cuidado y la familia se expande: la misma especificación, los mismos checks verdes, un espacio enorme de implementaciones mutuamente inconsistentes que todas pasan. Esa expansión es un tipo de entropía, y lo que la convierte en la palabra correcta es la dirección: dejada sola, solo crece. Cada límite afilado y cada prueba honesta la reduce; cada atajo y cada fuente duplicada de verdad la deja crecer de nuevo.

Nada de esto es nuevo tampoco. Lehman lo escribió en la década de 1970: un programa en uso sigue ganando complejidad, release tras release, a menos que alguien gaste trabajo real para contenerlo. Software rot, decadencia del código; el campo ha tenido palabras para ello desde que ha enviado software. Lo nuevo no es el fenómeno. Es la temperatura. Un producto funcional puede ser levantado en una hora y dejado inmantenible un día después, a la misma velocidad de cualquier manera. Los agentes no inventaron la entropía; solo subieron la temperatura, eliminando lo que solía mantener la tasa baja: qué tan rápido un humano podía escribir y leer código.

Sientes la entropía creciente como una pérdida: ya no puedes predecir tu propio sistema. No puedes decir, antes de cambiar algo aquí, qué hará allá. La confianza en un sistema siempre fue solo esto: la capacidad de predecirlo. No un sentimiento, no un check verde: la confianza ganada de que sabes cómo se comporta la cosa. Un diff no puede devolver eso, porque un diff muestra un cambio, y la predicción es una propiedad del todo. Así que la pregunta no es si un diff dado es correcto. Es si la entropía del todo está subiendo o sostenida. Eso es legible, y leerlo no toma diffs en absoluto.

Deja de leer el diff

Entonces, ¿cómo lees la entropía sin abrir cada diff? Un diff te muestra un cambio; nunca puede mostrarte un sistema. Dejas de leer el diff, y empiezas a leer el sistema. Las suites de pruebas y los dashboards eran de donde venía la confianza; las señales de abajo son cómo lo lees ahora, en vivo, mientras el sistema corre.

La revisión lee un artefacto: el cambio frente a ti, línea por línea. Pero lo que quieres saber no es una propiedad de ningún cambio. Es una propiedad de todo el sistema, y todo el sistema ya te está diciendo sobre sí mismo, todo el tiempo, sin que nadie abra un archivo. Emite señales; tú lees esas en su lugar. Es por eso que funciona donde la revisión no podía: la revisión estaba apuntada al artefacto, y lo que necesitabas saber nunca estuvo en el artefacto.

La lista de bugs es la más directa, porque no es un pronóstico: es el registro de dónde el sistema ya ha ido mal. Los bugs se agrupan, y la agrupación es el mapa. El mismo módulo surge semana tras semana, el mismo contrato crece un nuevo caso de borde cada mes, porque ahí es donde el sistema gotea. Los fallos de agentes son especialmente legibles, porque el error de un agente usualmente apunta de vuelta a una entrada que no estaba limpia: un contrato ambiguo, una especificación que dejó un caso sin decir. Un humano compensa por hábito y oculta la brecha; un agente entra en ella y marca el lugar.

Otras señales informan dónde todavía podría romperse. La prueba de mutación voltea una condición o elimina una rama en código funcional y pregunta si alguna prueba se pone roja; un mutante sobreviviente es una versión incorrecta de tu programa que tu suite todavía bendice, la brecha exacta entre "las pruebas pasan" y "el comportamiento está fijado." La estructura estática muestra dónde comienza la ruptura: una función gruesa con ramas tiene más estados de los que su especificación necesita, un hecho almacenado en dos lugares invita al día en que alguien actualice uno y olvide el otro. Y donde los agentes trabajan uno al lado del otro, una señal es en tiempo real: si sus cambios chocan. La colisión que importa no es dos agentes tocando código adyacente, que es concurrencia ordinaria; es la misma costura peleada una y otra vez, lo que significa que el límite allí está mal.

El mapa también te dice a dónde apuntar. Donde la lista de bugs es densa y las ramas son más profundas es donde los bugs desconocidos también son más densos, así que ahí es donde apuntas el marco de prueba: no para rellenar un número de cobertura, sino para construir los casos que sacan a la luz los fallos escondiéndose en las regiones enredadas. Un bug encontrado solo cuenta una vez que una prueba va de rojo a verde en él, así que la corrección está fijada y no puede volver silenciosamente.

Pero una prueba verde no es calidad gratis, y aquí es donde la mayoría de las suites te mienten. Una prueba gana su verde solo si su verificación es dura: tiene que afirmar contra el comportamiento real, en un payload real, así que una regresión verdadera la pone roja, y tiene que ser completa a través de los caminos que el comportamiento recorre, porque una verificación que pasa en un camino mientras otro va sin ejercitar es un caso no probado en ropa de prueba pasante. Una prueba que verifica la forma del código en lugar de su efecto es una luz verde conectada a nada. La misma sospecha cae sobre cada señal. Una lista de bugs silenciosa puede significar que el módulo está saludable, o que nadie lo ejercita, o que su instrumentación se oscureció. Una señal ausente significa algo solo si has establecido que habría disparado. Así que mantienes cada instrumento al estándar que estabas a punto de soltar para el diff: confiado solo una vez que has probado que puede fallar. La calidad vive en qué tan duras son tus verificaciones, nunca en que alguien haya leído las líneas.

Dos honestidades antes de que te apoyes en esto. Primero, la mayoría de estas lecturas son rezagadas: la lista de bugs es donde ya se rompió, el mutante sobreviviente es una brecha en pruebas que ya tienes. Atrapan la putrefacción un latido después de que aterriza, lo que supera a un sello que nunca la atrapa, pero no es prevención; la prevención se mueve río arriba, hacia las entradas. Y ninguna lectura única es la imagen completa, así que lees varias y las dejas triangular. Segundo, no toda entropía alta es decadencia. Un sistema de plugins donde cien extensiones satisfacen una interfaz es, por el conteo, enormemente de alta entropía, y ese es el diseño funcionando como se pretendía. Las señales te muestran dónde está la entropía; no te dicen qué tipo. Ese juicio no viene gratis.

Una revisión es un evento; la confianza es un estado

Todo esto tuvo que moverse fuera del diff por una razón más profunda que la velocidad: una revisión es la forma incorrecta para lo que estás tratando de sostener. Una revisión es un evento. La confianza es un estado. El evento ocurre una vez, deja un veredicto, y se va; nada se acumula en el sistema en el que estás tratando de confiar. El estado es lo que realmente quieres, la confianza sostenida de que puedes predecir tu propio sistema, y no puedes construir un estado a partir de eventos que no dejan nada atrás. Esa es la oración a la que el título estaba apuntando: la confianza no vive en el code review porque un evento no puede albergar un estado. Ejecuta el evento mil veces y todavía no tienes la cosa. Las señales son continuas, así que la confianza se acumula de ellas; el sello nunca pudo.

Así que la revisión, como tu instrumento de confianza, se va. Leer código no desaparece; se mueve a donde vive la comprensión, que en la era de los agentes son los agentes escribiendo el código, no tú. Ellos son los que tienen sus manos en los detalles, ronda tras ronda. Lo que se va eres tú, haciéndolo como la puerta. Y los casos de alto riesgo que la gente alcanza primero, el límite de seguridad, el release irreversible, son exactamente aquellos en los que un escaneo humano cansado siempre fue el peor. Montan sobre cosas más fuertes ahora: una propiedad que el sistema de tipos hace imposible violar, una verificación cuya afirmación es dura, un rollout escalonado vigilado por monitoreo que atrapa la regresión que una lectura perdería.

Aquí leer las señales se convierte en más que observar. Cada una apunta de vuelta a una causa. Un mutante sobreviviente apunta a comportamiento que nadie fijó. Un límite desviado apunta a un contrato que dejó de significar una cosa. Un grupo en la lista de bugs apunta más profundo: este código fue escrito por un modelo capaz, así que cuando un módulo sigue generando bugs, la causa más probable no es que el modelo sea débil ahí. Es que las interfaces del módulo engañan a cualquier cosa trabajando contra ellas. El bug es el sistema diciéndote que el límite está mal. Así que lo refactorizas bajo el marco de prueba que acabas de construir, que mantiene el comportamiento estable, así que cada cambio es o provablemente preservador de comportamiento o un bug real sacado a la luz.

El movimiento casi nunca es "revisar el próximo diff más duro." Es tratar el fallo como lo que es: entrada diagnóstica para el bucle. Un fallo no es un veredicto sobre el modelo; es un mapa de las entradas que dejaste sin limpiar. Te dice, precisamente, qué condición que le diste aún no estaba limpia, y una vez que lo ves de esa manera los errores del agente se convierten en la cosa más valiosa que produce: cada uno un puntero etiquetado a una brecha que de otro modo no podrías ver.

Esto es más fácil de sentir por rol. El agente que diseña la arquitectura falla, y la causa raramente es su razonamiento; es que la misión, la dirección hacia la que estás construyendo, nunca se dejó lo suficientemente clara en la entrada. El agente que escribe la implementación falla, y la causa raramente es inteligencia; es que el entorno, la superficie de prueba, el arnés de validación no estaban en su lugar, o los límites que dibujaste lo engañaron. El agente que prueba contra tu intención pierde lo que importó, porque la intención nunca se expresó lo suficientemente claramente para probar contra ella. El fallo nunca termina en el agente. Viaja hacia arriba en la cadena y aterriza en una entrada: algo que dijiste poco claro, una superficie que no construiste, un límite que dejaste blando.

Ese es el bucle cerrándose. Lees dónde la entropía está subiendo, rastrear el fallo a la entrada que la dejó subir, y aprietas esa entrada. A veces eso significa una especificación más afilada; a veces refactorizar el contrato que engañó al modelo; y en lo más fuerte, cambiar el diseño para que el fallo no pueda ocurrir en absoluto: un tipo que hace al estado malo irrepresentable, un invariante aplicado por construcción en lugar de verificado después del hecho. Ese último movimiento solo alcanza los fallos que puedes codificar como un estado ilegal. Los externos y de tiempo, una credencial que nunca responde, una carrera entre dos servicios, permanecen irreducibles, y vuelven a las verificaciones duras y rollouts escalonados de antes. El sistema se vuelve más predecible no porque alguien revisara más código, sino porque cada fallo se gastó haciendo las condiciones más verdaderas.

Esa es la práctica en una oración: deja de guardar la puerta, y empieza a leer el sistema y apretar sus entradas, ronda tras ronda. Es lo único que hemos encontrado que mantiene calidad y velocidad en la misma mano una vez que los agentes se mueven más rápido de lo que cualquiera puede leer.

Lo que deja una pregunta, la única hacia la que todo este artículo ha estado caminando. Si ya no eres la puerta, ya ni siquiera el que lee el código, si tu día es leer el sistema y apretar lo que lo alimenta, entonces ¿qué es, exactamente, el trabajo del humano ahora? Ese es el próximo artículo.