Generar es fácil. Verificar es el trabajo.

Un estudio de METR puso a 16 developers experimentados a completar tareas reales en sus propios repositorios, aleatorizando si podían usar IA o no. Muestra pequeña, pero diseño experimental riguroso: tareas reales, repositorios propios, asignación aleatoria. Los que usaron IA tardaron un 19% más. Pero lo interesante es que, antes de empezar, estimaron que la IA les haría un 24% más rápidos. Y después de terminar (habiendo sido objetivamente más lentos), seguían creyendo que habían sido un 20% más rápidos.

Creyeron ser más rápidos mientras eran más lentos. Y no eran juniors. Eran developers con años de experiencia en esos repositorios concretos.

Un dato suelto no prueba nada. Pero cuando ves el mismo patrón en developers experimentados, en agentes autoevaluándose, y en code reviews automatizadas, el patrón empieza a pesar. Un experimento de Alexey Pelykh lo confirma: 449 code reviews hechas por IA, auto-evaluadas con un 98.6% de validez. Cuando un evaluador independiente las revisó contra el código real, la cifra bajó a 68.9%.

Creo que no es un dato sobre herramientas de IA. Es un dato sobre un sesgo humano fundamental: somos incapaces de evaluar bien la calidad de lo que acabamos de producir. Y ese sesgo está a punto de reconfigurar nuestra profesión.

Humanos y máquinas, resultado práctico similar aunque las causas sean distintas. Los LLMs no pueden autoevaluarse por diseño. Los humanos en teoría sí, pero el sesgo de autoconfianza que documenta METR sugiere que en la práctica lo hacemos mal. Si eso no es un argumento para separar al que genera del que verifica, no sé qué lo es.

La separación que cambió todo

Hace unos días, Anthropic publicó un post sobre harness design que conecta exactamente con esto. Construyeron un sistema de tres agentes (uno que planifica, uno que genera código, y uno que evalúa) para crear aplicaciones completas de forma autónoma durante horas.

Cuando le pedían al agente que evaluara su propio trabajo, se daba una nota alta aunque la calidad fuera mediocre. La solución fue separar al que genera del que evalúa. Un agente crea, otro juzga. Y descubrieron que afinar al evaluador para que sea escéptico es mucho más fácil que conseguir que el generador sea autocrítico.

Su evaluador no leía el código línea a línea. Navegaba la aplicación con Playwright, la usaba como un usuario, probaba flujos, y evaluaba contra criterios predefinidos. Cada sprint tenía un "contrato" (un acuerdo previo sobre qué significaba "terminado") y el evaluador verificaba contra ese contrato.

Ese patrón (generador y evaluador como roles separados) se está convirtiendo en un estándar. AWS lo documenta como patrón de arquitectura. OpenAI lo aplica en su modelo de harness engineering, donde un equipo pequeño construyó un millón de líneas de código sin escribir una sola línea a mano.

Pero no me interesa solo como patrón de agentes. Me interesa porque describe hacia dónde se mueve nuestra profesión.

El contrato que se está rompiendo

Durante décadas, el contrato implícito de la ingeniería de software era: tú generas y tú verificas. Escribes código, lo testeas, lo revisas, lo despliegas. La comprensión del sistema viene incluida en el acto de construirlo.

Ese contrato se está rompiendo. Y lo estoy viendo en tiempo real.

Ahora la IA genera. Un PM con Claude Code produce una feature. Un junior con Cursor acepta sugerencias que no comprende del todo. Un agente autónomo implementa un sprint entero sin supervisión. El artefacto llega igual (un PR, un deploy, una feature funcionando), pero la comprensión detrás es radicalmente diferente.

Lo vi hace unas semanas en uno de los equipos que apoyo. Un PR generado con asistencia de IA, limpio, bien estructurado, tests en verde. Parecía perfecto. Un ingeniero senior lo frenó porque sabía que ese endpoint de consulta de inventario dependía de un servicio externo que, bajo la carga de campañas comerciales, pasa de responder en 50ms a acumular latencias de varios segundos que no aparecen en ningún test. Lo sabía porque vivió el incidente hace dos años, un viernes a las 11 de la noche. Ese contexto no estaba en el código, no estaba en la documentación, no estaba en ningún sitio donde un agente pudiera encontrarlo.

Eso es verificación. Y es lo que la IA, hoy, no puede hacer.

Las tres capas de verificación

Una forma útil de pensarlo, observando tanto los sistemas de agentes como los equipos humanos, es en tres capas:

Verificación funcional: ¿hace lo que debe? La más obvia y la más automatizable. Tests, CI/CD, linters, type checking. Los agentes evaluadores de Anthropic usan Playwright para navegar la aplicación y verificar que los flujos funcionan. Necesaria pero no suficiente.

Verificación de criterio: ¿lo hace bien? "Funciona" no es lo mismo que "es bueno." ¿Es mantenible? ¿Escala? ¿Es seguro? Anthropic descubrió que tenía que definir criterios explícitos ("design quality", "originality", "craft", "functionality") porque sin criterios, el evaluador tiende a aprobar lo que parece razonable. En equipos humanos, estos criterios rara vez son explícitos. Viven en la cabeza de los seniors como intuición. Como heurísticas invisibles.

Verificación de contexto: ¿encaja en el sistema real? Esta es la capa más difícil de resolver. ¿Este código se va a comportar bien junto con el resto del sistema? ¿Hay algo en la historia del sistema (un incidente pasado, una dependencia frágil, una restricción de negocio) que este código ignora? Es exactamente lo que pasó con aquel PR del endpoint de inventario. La primera capa decía "todo verde." La segunda diría "código limpio." Solo la tercera detectó el problema. Esta capa requiere memoria arquitectural, exactamente el tipo de conocimiento que los seniors tienen y no saben que tienen.

Las herramientas cubren la primera capa. Los criterios explícitos cubren la segunda. La tercera solo la cubren personas con experiencia y contexto. Y es ahí donde está el trabajo real de ingeniería.

La asimetría que nos define

Generar es un problema de producción: dada una especificación, produce algo que la cumpla. Los LLMs son extraordinariamente buenos en esto. Producen código que compila, que pasa tests, que se ve razonable. Eso es lo que se ha commoditizado. Lo que no: descomponer el problema, elegir las abstracciones correctas, diseñar la especificación. Eso sigue siendo craft. Verificar es un problema de juicio: dado algo que parece funcionar, determina si realmente funciona en todos los casos que importan, si es mantenible, si las decisiones de diseño son sostenibles.

Y verificar requiere algo que generar no requiere: contexto. Saber que ese endpoint va a recibir 10x más tráfico en Navidad. Saber que ese servicio tiene una dependencia frágil con un sistema legacy. Saber que "funciona" no es lo mismo que "funciona en producción a las 3 AM con carga real."

El VP de AI de CodeRabbit lo describe así: el código generado por IA es más exigente cognitivamente de revisar que el código escrito por humanos. Y los pipelines de QA existentes se construyeron para el ritmo humano, no para el ritmo amplificado por IA.

Los datos confirman la asimetría. Un informe de Sonar con más de 1.100 desarrolladores encontró que el 42% de todo el código commiteado ya tiene asistencia significativa de IA, pero el 96% no confía plenamente en que ese código sea funcionalmente correcto. Y solo el 48% lo verifica siempre antes de hacer commit. Un estudio de Harness con 900 ingenieros completa el cuadro: el 63% de organizaciones envía código a producción más rápido con IA, pero el 45% de los deploys vinculados a código generado por IA provocan problemas. Lo llaman la "AI Velocity Paradox": vamos más rápido, pero rompemos más cosas.

Ambos informes vienen de vendors con skin in the game, con las reservas que eso merece. Pero los números son consistentes con lo que estoy viendo en los equipos que apoyo. Hemos multiplicado por diez la velocidad a la que generamos, pero los inspectores de obra siguen revisando al mismo ritmo. Algo va a ceder.

El mapa que lo hace visible

Cuando pongo a cada rol en un eje de generación vs. verificación, el patrón se hace obvio. Es un modelo observacional, no un estudio. Pero cuando lo pongo delante de un equipo, la conversación que genera siempre es productiva. Los roles que más generan son los que menos verifican, y viceversa. La IA ha empujado a todo el mundo hacia la derecha (más generación) sin que nadie se haya movido hacia arriba (más verificación). La diagonal vacía es el problema.

El ingeniero como evaluador

Una frase del post de Anthropic: "El espacio de combinaciones interesantes de harness no se encoge a medida que los modelos mejoran. Se mueve."

Creo que lo mismo aplica a los ingenieros. El trabajo no se encoge. Se mueve. De generar a verificar. De escribir código a definir los criterios que determinan si el código merece existir.

No voy a fingir que no hay una parte de mí que se resiste. Yo entré en esta profesión porque me encantaba escribir código. Pero lo que estoy descubriendo es que verificar con criterio es un trabajo intelectualmente más exigente, no menos. Requiere más experiencia, más contexto, más juicio. No es un paso atrás. Es un paso arriba.

Dicho esto, hay una tensión que no quiero ignorar. El contexto que hace bueno a un verificador viene de haber construido cosas. El senior que detectó el problema en aquel PR lo detectó porque vivió el incidente hace dos años. Si dejamos de generar del todo, ¿de dónde sale el criterio de los verificadores del futuro? No tengo la respuesta completa. Pero creo que la respuesta tiene que ver con que generar y verificar no son roles fijos, sino modos de trabajo que todo ingeniero necesita ejercitar.

Lo que sí tengo claro es esto:

La generación es commodity. La verificación es craft.

Las heurísticas invisibles de los seniors, los criterios de calidad que nadie ha escrito, la memoria arquitectural que vive solo en la cabeza de quien lleva años operando el sistema, todo eso es infraestructura de verificación. Y es la infraestructura más valiosa que tiene tu equipo. 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.

Así que esto es lo que te propongo hacer esta semana. No el trimestre que viene, no cuando tengas tiempo. Esta semana:

Elige un criterio de calidad que viva solo en la cabeza de alguien y escríbelo. No como documentación que nadie lee, sino como un ítem en la checklist de tu PR template o una regla en tu linter. Un criterio, hecho explícito, ya cambia cómo verifica el equipo.

Define "hecho" antes de que empiece la siguiente feature, no después. Siéntate con el equipo 10 minutos y acordad: ¿qué necesita esta feature para poder salir? Escríbelo en el ticket. Ese es tu contrato de verificación.

En tu próxima code review, haz una pregunta que los tests no puedan responder. "¿Qué pasa cuando este servicio tiene 500ms de latencia?" "¿Esta decisión de diseño entra en conflicto con algo que decidimos hace seis meses?" Esa es la tercera capa de verificación. Y ahora mismo, solo tú puedes proporcionarla.

Nada de esto requiere herramientas nuevas. Nada de esto requiere aprobación de presupuesto. Requiere decidir que la verificación es un trabajo que merece la misma intencionalidad que le das a construir features.

Este es el quinto artículo de la serie Operar a Ciegas. Hasta ahora he dedicado más tiempo a diagnosticar el problema que a mostrar cómo construir la solución. Quiero cambiar eso, hay mucho que explorar sobre cómo se construye infraestructura de verificación en la práctica. Si quieres seguir el hilo, la newsletter está justo debajo.