Cómo se verifican a sí mismas las compilaciones

0:00 — un build termina. El agente dice que está listo, lo cual es una afirmación sobre haber escrito código, no sobre si el código funciona. Todo usuario de un constructor de IA ha sentido al menos una vez la brecha entre esas dos afirmaciones: se abre la vista previa, se hace clic en el tercer botón, no pasa nada. He visto una sala de demostración quedarse en silencio justo en ese momento. Así que antes de que cualquier humano vea un build, pasa por unos seis minutos de una cadena discutiendo consigo misma. Esto es lo que eso realmente parece, trazado a través de un build que vimos torcerse y luego arreglarse.

0:02 — empieza la revisión de código. No el agente que escribió el código releyendo su propia tarea, sino un agente distinto, con otro prompt, sin ningún interés en que el build pase. Esa separación importa más de lo que parece. Un agente que decidió a las 2:14pm que una llamada fetch sin manejo de errores estaba bien, seguirá pensando lo mismo a las 2:15pm si le pides que revise su propio trabajo. Un revisor nuevo al que se le dice "encuentra qué está roto, cita el archivo" se comporta como el ingeniero senior gruñón que realmente quieres para esta tarea. En un build anterior detectó un total del carrito que en silencio nunca se actualizaba: `updateTotal` estaba definida en `Cart.jsx` pero nunca conectada al manejador de cambio de cantidad, así que la función existía y sencillamente nunca se ejecutaba. Esa es la categoría para la que existe la revisión de código: cosas ante las que un compilador simplemente se encoge de hombros.

0:04 — auditoría de seguridad. Más acotada de lo que suena, deliberadamente: esto no es una prueba de penetración, es una búsqueda de patrones para el puñado de errores que realmente aparecen en código generado por IA. SQL concatenado por strings. Validación solo del lado del cliente, confiada como si fuera toda la historia. Y el especial de la casa: una clave de API escrita directamente en el código, porque el agente que escribía la función no tenía delante una convención de variables de entorno y recurrió a lo que funcionaba. Vemos ese caso lo suficientemente seguido como para que apenas cuente como sorpresa.

0:07 — enlaces y SEO. Poco glamoroso, y detecta lo que nadie nota hasta que un cliente lo hace: un enlace de navegación que apunta a /pricing cuando la página en realidad se generó en /price, una entrada de sitemap para una página que da error 404, una meta descripción que todavía conserva el texto de plantilla. Nada de eso rompe la compilación. Pero todo eso hunde silenciosamente lo que la mayoría de nuestros usuarios construyeron el sitio para lograr: que los encuentren, que hagan clic.

0:09 — accesibilidad. Esta es una pasada automatizada con axe-core, no una auditoría manual completa, y vale la pena ser honesto sobre lo que compra ese intercambio. axe-core detecta relaciones de contraste, texto alternativo faltante, campos de formulario sin etiquetar, trampas en el orden de tabulación: la capa mecánica, algo así como el 30-40% de lo que señalaría una revisión completa de WCAG. No detectará una experiencia de lector de pantalla que sea técnicamente conforme pero genuinamente confusa de usar. Elegimos solo automatizado porque se ejecuta en segundos y la mayor parte de lo que se lanza aquí son sitios de marketing y herramientas pequeñas, no el tipo de aplicación en la que una auditoría parcial es un riesgo real para alguien.

0:11 — conformidad. Esta capa no pregunta "¿es esto bueno?", pregunta "¿coincide esto con lo prometido?". El plan decía cuatro páginas, el build entregó tres: la conformidad es la que se da cuenta. El plan prometía un formulario de contacto funcional, lo entregado es un formulario sin acción de envío: misma capa, misma detección. Es la comprobación más directamente responsable ante el usuario, porque mide contra la intención declarada del usuario, no alguna noción abstracta de calidad.

0:13 — la comprobación en el navegador, y aquí es donde nuestro build realmente se rompió. Esta capa es la más difícil de simular porque no lee código, conduce un navegador real: hace clics, escribe, espera, comprueba que el DOM cambió como debía. El build en cuestión era un juego idle, y los juegos reciben una pasada extra aquí porque un juego puede renderizarse a la perfección y aun así ser injugable: la pantalla de puntuación puede verse impecable mientras está completamente desconectada de la lógica de puntuación. El verificador lo jugó. La puntuación se actualizaba bien. El audio no emitió ningún sonido.

Tres rondas, y luego una escalada

El hallazgo no nos llegó como un reporte de error: fue directo a una pasada de corrección, y la cadena volvió a verificar, hasta tres rondas dentro del build. Ronda uno: la corrección tocó la inicialización del mezclador, que ya estaba bien, así que el audio siguió en silencio. Ronda dos: una corrección diferente abordó un caso límite de estado de carga que parecía relacionado y —esto ocurre más de lo que uno esperaría— introdujo un pequeño problema nuevo sin resolver el original. Ronda tres: seguía en silencio, y a esta altura normalmente estás ante algo genuinamente difícil o ante una falsa alarma, y esta era del tipo difícil.

Así que la plataforma escaló por su cuenta. Puso en cola una ejecución de corrección de seguimiento, acotada por completo al hallazgo que persistía, trabajando sobre un clon del build en lugar del build en sí, lo que significa que la ejecución de escalada podía fallar sin costarnos la versión funcional que ya teníamos. Esa ejecución encontró la causa real: una marca de silencio (mute flag) establecida durante una pasada de depuración anterior que nunca se había revertido, ubicada en un archivo completamente distinto de los dos que habían tocado las correcciones anteriores. Se limpió la marca, se volvió a verificar, y pasó. Nadie miró este build hasta que ya funcionaba.

Lo que evitaría la próxima vez

Unos meses antes de que se ejecutara ese juego idle, probamos una versión más suave de todo el sistema: los verificadores podían plantear cualquier inquietud, expresada como quisieran. Producía hallazgos como "considera extraer esto en una función auxiliar" y "este nombre de variable podría ser más claro", que se leían como diligencia y no arreglaban nada. Las pasadas de corrección quemaban rondas enteras puliendo prosa en lugar de arreglar lo que realmente estaba roto. Ajustamos la regla a: nombra un archivo, describe un fallo, o no digas nada. La salida de los verificadores cayó aproximadamente a la mitad y casi todo lo que quedó era accionable. Si tuviera que rehacer esto desde cero, me saltaría por completo la versión suave e iría directo a la regla de la evidencia; no necesitábamos aprender esa lección de la manera costosa, pero así fue.

La regla tiene un costo real, y no voy a fingir lo contrario: una preocupación vaga pero cierta como "este diseño de API va a morder a alguien dentro de seis meses" ahora se descarta, porque un verificador no puede vincularla a un fallo concreto. Hemos hecho las paces con ese intercambio. Una cadena que también hiciera revisión de arquitectura no sería lo bastante rápida para ejecutarse en cada build, y la velocidad es todo el sentido de hacer esto automáticamente en lugar de pedirle a un humano que lo haga.

También me saltaría añadir una cuarta ronda, si alguien pregunta. Ajustamos el número de rondas contra builds reales, y el valor marginal después de la ronda tres cae en picada: la ronda uno resuelve la mayoría de los hallazgos corregibles, la ronda dos en general limpia los problemas que introdujo la ronda uno, y para la ronda tres lo que queda es genuinamente difícil o nunca estuvo realmente roto. Una cuarta ronda sobre todo compra tiempos de espera más largos para el mismo resultado.

Nada de esto es gratis, y nada de esto es infalible. Seis capas más las rondas de corrección que hagan falta añaden tiempo real a cada build: la diferencia entre terminar en menos de un minuto y terminar en varios. Creemos que ese es el intercambio correcto para cualquier cosa que estés a punto de poner delante de tus propios clientes, pero "rápido" y "verificado" tiran en direcciones opuestas, y elegimos verificado. Los verificadores también son LLM, así que en ocasiones señalan algo que en realidad no está roto, o pasan por alto algo que sí lo está. La regla de la evidencia y el ciclo de múltiples rondas son coberturas contra eso, no garantías.

Lo que obtienes al final es un registro: qué capas se ejecutaron, qué encontraron, qué se corrigió y qué queda para tu propio criterio. Ese registro está más cerca del producto real que el código: es la diferencia entre confiar en un build porque parece terminado y confiar en él porque algo adversarial trató primero de romperlo y fracasó.