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. Los que usaron IA tardaron un 19% más. Pero lo demoledor no es eso. Es esto: 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.

Lee esa frase otra vez. 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.

¿Sabes qué? Ese dato me lleva persiguiendo semanas. Porque 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.

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. Confiaba en lo que había generado.

Un experimento independiente lo confirma: 449 code reviews hechas por IA, auto-evaluadas con un 98.6% de validez. Cuando un evaluador externo las revisó contra el código real, la cifra bajó a 68.9%. Un gap de 30 puntos entre "parece correcto" y "es correcto."

Humanos y máquinas, el mismo punto ciego. 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

La solución de Anthropic 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 misma persona (o equipo) que crea es la que asegura la calidad. 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.

Y alguien tiene que verificar que lo que llegó tiene calidad de producción.

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 dependía de un servicio que, bajo carga real, tiene latencias intermitentes que no aparecen en ningún test. Lo sabía porque vivió el incidente hace dos años. 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. Estaba en la cabeza de alguien que llevaba tiempo operando el sistema.

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

Las tres capas de verificación

Observando tanto los sistemas de agentes como los equipos humanos, veo que la verificación efectiva opera 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. En equipos humanos, es lo que ya tenemos (o deberíamos tener). Necesaria pero no suficiente.

Verificación de criterio: ¿lo hace bien? Aquí es donde las cosas se ponen interesantes. "Funciona" no es lo mismo que "es bueno." ¿Es mantenible? ¿Escala? ¿Es seguro? ¿Las abstracciones tienen sentido? Anthropic descubrió que tenía que definir criterios explícitos para esto ("design quality", "originality", "craft", "functionality") porque sin criterios, el evaluador (sea agente o humano) 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 que me quita el sueño. Ninguna herramienta puede automatizarla todavía. ¿Este código se va a comportar bien junto con el resto del sistema? ¿Las decisiones de diseño son coherentes con la arquitectura existente? ¿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 que el senior frenó. 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.

Lo que esto significa para tu equipo

Si la verificación es el nuevo trabajo central, hay consecuencias prácticas. Y las hay a partir de mañana, no en un futuro abstracto.

Los criterios de calidad tienen que ser explícitos. Anthropic no pudo hacer funcionar su evaluador hasta que definió criterios concretos y calificables. "¿Este diseño es bueno?" es una pregunta que no se puede responder consistentemente. "¿Este diseño sigue nuestros principios de design quality, originality, craft y functionality?" sí.

Lo mismo aplica a equipos humanos. Un ejemplo concreto: en vez de revisar un PR pensando "¿esto tiene buena pinta?", define tres preguntas que toda verificación debe responder. Algo como: "¿Podría alguien diagnosticar esto a las 3 AM sin ayuda?", "¿Las decisiones de diseño son consistentes con la arquitectura del dominio?", "¿Los edge cases del negocio están cubiertos?"

Si tus criterios de calidad viven solo en la intuición de tus seniors, nadie más puede verificar nada. Necesitas hacerlos explícitos. No como documentación burocrática, sino como contratos operativos que todos entienden.

El contrato de "terminado" se define antes de generar. En el sistema de Anthropic, el generador y el evaluador negocian qué significa "terminado" antes de escribir una línea de código. Eso elimina la ambigüedad.

En equipos humanos, rara vez hacemos esto. El código llega, se revisa sobre la marcha, y "terminado" significa "no veo nada raro." Imagina la diferencia si antes de implementar una feature, el equipo acuerda: "Esta feature está terminada cuando: pasa los tests de carga con 5x del tráfico esperado, la degradación del servicio externo devuelve un fallback correcto, y un ingeniero que no la implementó puede explicar el flujo leyendo solo el código y los comentarios."

Eso convierte la verificación en un checklist contra un acuerdo, no en una opinión subjetiva.

La verificación tiene que escalar más allá de las personas. Los criterios explícitos y los contratos de "terminado" son el primer paso. Pero el siguiente es codificar esa verificación como infraestructura: contract testing entre servicios, property-based testing, mutation testing. Verificación que no dependa de que un senior esté disponible a las 3 AM sino que esté embebida en el sistema. La dirección es clara: si la generación se acelera 10x, la verificación tiene que automatizarse en todo lo que sea automatizable, para que los humanos nos podamos concentrar en la tercera capa, la que requiere contexto y juicio.

Por qué verificar es más difícil que generar

Esto parece contraintuitivo. Generar un sistema completo debería ser más difícil que revisarlo. Pero no es así, y la razón me parece importante.

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.

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 se va a comportar bien bajo presión, 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 esa decisión de diseño se tomó por una razón que no está en el código. 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.

Ese contexto es exactamente lo que la IA no tiene. Y es exactamente lo que los seniors llevan años acumulando sin ser conscientes de ello. Es lo que describí en El código que nadie entiende ya está en producción: la IA no cobra por escribir código, pero alguien va a pagar por operarlo.

La asimetría que nos define

Estamos en una asimetría temporal: la capacidad de generar ha dado un salto de 10x, pero la capacidad de verificar apenas se ha movido. Es como si hubiéramos multiplicado por diez la velocidad a la que construimos edificios, pero los inspectores de obra siguen revisando al mismo ritmo.

Los datos lo confirman. 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, y esperan que llegue al 65% en 2027. Pero el 96% de esos mismos developers 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 dice que envían código a producción más rápido desde que adoptaron 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.

Algo va a ceder. Y creo que lo que va a ceder es el modelo actual donde todo el mundo genera y nadie tiene tiempo de verificar.

Esto es lo que veo cuando pongo a cada rol en un mapa:

El ingeniero como evaluador

Hay una frase del post de Anthropic que se me ha quedado grabada: "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. De implementar a diseñar los contratos de calidad que otros (humanos o máquinas) deben cumplir.

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? ¿Cómo adquieres memoria arquitectural si nunca has operado un sistema que se rompe a las 3 AM?

No tengo la respuesta completa. Pero sé que nombrar la pregunta es más honesto que fingir que el camino está claro. Y 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, cada uno en su proporción según el momento y la madurez.

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. Y en un mundo donde la generación se acelera cada trimestre, esos tres puntos se van a convertir en el cuello de botella que determina si tu equipo puede escalar o se ahoga revisando código que no entiende.

Tratar esa infraestructura como lo que es, hacerla explícita, codificarla, escalarla. Ese es el trabajo de ingeniería de los próximos años.