La disciplina no escala. La verificación necesita infraestructura.

La semana pasada, un perfil no técnico de mi entorno creó una herramienta funcional usando IA. No un prototipo ni una demo, algo que hacía lo que tenía que hacer, con tests pasando y una interfaz limpia.

Le eché un vistazo y mi primera reacción fue "esto está sorprendentemente bien." La segunda fue "no tengo ni idea de si esto debería llegar a producción." Porque "funciona" y "es correcto" no son lo mismo. Y la distancia entre las dos cosas es exactamente donde viven los problemas.

Así que hice algo diferente a lo que habría hecho hace un año. En vez de leer el código línea a línea buscando lo que "me sonara raro" (que es como hemos verificado cosas toda la vida), escribí un contrato de verificación antes de revisar nada. Tres preguntas por cada dimensión: ¿hace lo que debe? ¿Está bien hecho? ¿Encaja en el sistema real?

Lo que me pilló desprevenido fue lo que habría pasado por alto sin el contrato. En la dimensión funcional todo estaba verde, la IA había hecho un trabajo limpio. En la de craft, dos decisiones de diseño eran inconsistentes con las convenciones del proyecto. Nada grave, pero el tipo de cosas que se acumulan. Y en la contextual (la que siempre me preocupa más) descubrí una dependencia que bajo carga real se iba a comportar de forma diferente a lo que los tests mostraban. Sin el contrato, habría revisado con mi intuición, probablemente habría pillado lo de craft, y casi seguro habría pasado por alto lo contextual.

La intuición no escala. La disciplina no escala. Nunca ha escalado.

El patrón que se repite

Sabemos que hay que documentar decisiones. No lo hacemos porque el sprint cierra el viernes. Sabemos que hay que hacer pair programming. No lo hacemos porque es más rápido hacerlo solo. Sabemos que las code reviews deberían verificar criterios concretos. En la práctica, miramos el diff, vemos que los tests pasan, y damos el LGTM.

La disciplina individual como sistema de calidad es un diseño frágil. Depende de que alguien se acuerde, de que tenga tiempo, de que tenga contexto, de que no esté cansado. En un mundo donde la generación iba al ritmo humano, era suficiente. En un mundo donde la IA genera 10x más rápido, no da.

¿Sabes qué sí ha escalado? Los tests. No porque los developers sean más disciplinados que antes, sino porque los tests se convirtieron en infraestructura. CI/CD no escala porque la gente se acuerda de desplegar correctamente, escala porque el proceso no depende de que nadie se acuerde. Los linters no escalan por disciplina, escalan porque están embebidos en el flujo.

En mi artículo anterior argumenté que la verificación es el nuevo trabajo central de ingeniería y describí tres dimensiones: funcional (¿hace lo que debe?), craft (¿está bien hecho?) y contextual (¿encaja en el sistema real?). Lo que no dije es cómo escalar eso más allá de la voluntad individual.

Ahora creo que la respuesta es la misma que con los tests: la verificación necesita convertirse en infraestructura.

Lo que construí

Así que lo construí. Se llama Plumbline. Es infraestructura de verificación para trabajo asistido por IA. Dos fases: una antes de construir, otra después.

En la primera fase generas un contrato de verificación. Plumbline analiza tu proyecto (documentación, código, convenciones) y produce un documento con criterios concretos de lo que "terminado" significa para esa tarea. No código. Criterios. Cada uno clasificado en las tres dimensiones y etiquetado como [auto] (ejecutable por agentes) o [manual] (requiere juicio humano).

Un contrato real se ve así:

Funcional: "POST /auth/login devuelve 200 con credenciales válidas" [auto]. "El rate limiting se activa después de 5 intentos" [auto].

Craft: "La lógica de auth vive en la capa de servicio, no en el route handler" [auto]. "El naming sigue las convenciones del codebase" [manual].

Contextual: "Todos los tests existentes siguen pasando" [auto]. "Se ha evaluado el impacto en latencia del middleware de auth en el hot path" [manual].

En la segunda fase, después de construir, Plumbline ejecuta las verificaciones automáticas, te guía por las manuales, y produce un informe con evidencia para cada criterio.

Todo el estado es Markdown. Sin base de datos, sin servidor, sin configuración. Si la verificación no es transparente, no es verificación, es otra caja negra.

Por qué la code review no es suficiente

La code review, tal como la practicamos, no está diseñada para el mundo que viene.

La code review asume que el reviewer entiende el código que revisa. Asume que el reviewer tiene contexto sobre el sistema. Asume que el reviewer tiene tiempo para revisar con profundidad. Y asume que el código fue escrito por una mente humana con intenciones reconocibles.

Ninguna de esas asunciones se sostiene cuando la IA genera el código. El reviewer no siempre entiende lo que generó la IA. El contexto del sistema vive en la cabeza de tres seniors que no siempre están disponibles. El tiempo de revisión no ha escalado mientras el volumen de código generado se ha multiplicado. Y las "intenciones" del código AI-generated son patrones estadísticos, no decisiones de diseño.

No digo que la code review muera. Digo que necesita evolucionar de "reviso lo que veo" a "verifico contra criterios acordados." De opinión subjetiva a contrato verificable. De práctica que depende de la disciplina del reviewer a infraestructura que funciona aunque el reviewer esté cansado, tenga prisa, o no conozca ese rincón del sistema.

Eso es lo que hace un contrato de verificación: separa el "qué verificar" del "quién verifica." Los criterios los defines cuando tienes tiempo y contexto. La verificación la ejecutas después, contra esos criterios, con la disciplina embebida en el proceso y no en la persona.

Lo que no esperaba

Vuelvo a la historia del principio. El contrato me hizo mejor verificador a mí. Eso no me lo esperaba.

Sin contrato, habría revisado con mi intuición. Habría mirado lo que mi experiencia me dice que mire. Y habría dejado sin revisar lo que mi experiencia no cubre, que es más de lo que me gusta admitir.

Con contrato, verifiqué las tres dimensiones de forma sistemática. La funcional fue rápida y automática. La de craft me forzó a comparar contra convenciones que tengo interiorizadas pero que nunca había escrito. Y la contextual me hizo pensar en el sistema completo antes de aprobar una pieza.

Las heurísticas invisibles de los seniors son valiosas. Pero depender exclusivamente de ellas es lo mismo que depender de la disciplina: funciona hasta que no funciona. Lo que necesitamos es convertir las que podamos en criterios explícitos, codificarlos como contratos verificables, y reservar el juicio humano para la tercera dimensión, la que requiere contexto que ningún sistema puede capturar todavía.

El craft necesita infraestructura

Llevo cinco artículos argumentando que en un mundo donde la IA genera código, lo que importa es el criterio de quien lo verifica. Que las heurísticas de los seniors son la infraestructura más valiosa de un equipo. Que la generación es commodity y la verificación es craft.

Plumbline es un intento de convertir parte de ese craft en infraestructura. Cada criterio que sacas de la cabeza de un senior y lo conviertes en un contrato verificable es un punto único de fallo menos.

No resuelve todo. La tercera dimensión sigue necesitando humanos con contexto. Las heurísticas más profundas siguen siendo tácitas. Pero si tus criterios de calidad viven solo en la cabeza de tres seniors, no tienes un sistema de verificación. Tienes tres puntos únicos de fallo. Y en un mundo donde la generación se acelera cada trimestre, esos tres puntos son el cuello de botella que determina si tu equipo escala o se ahoga.

La generación es commodity. La verificación es craft. Y el craft necesita infraestructura.

Pregunta para ti: Si tuvieras que escribir un contrato de verificación para la próxima feature de tu equipo, ¿qué pondría en la dimensión contextual? Eso que solo tú sabes, que no está en ningún test, y que ningún agente puede descubrir.