La capa de verificación de la fábrica oscura

StrongDM lanzó software bajo dos reglas: “El código no debe ser escrito por humanos” y “El código no debe ser revisado por humanos”.¹ Un equipo de tres personas—Justin McCarthy, Jay Taylor y Navan Chauhan—construyó y lanzó Attractor y CXDB (16K líneas de Rust, 9,5K de Go, 6,7K de TypeScript) con un gasto mínimo de $1.000 en tokens por ingeniero por día.¹ BCG Platinion, citando cobertura de Spotify y TechCrunch, reporta que los mejores desarrolladores de Spotify no habían escrito código desde diciembre de 2025, y que la empresa fusionaba cientos de pull requests generados por IA cada mes.²

Dan Shapiro llama al punto final Nivel 5: la Fábrica Oscura. Código generado por máquinas, verificado por máquinas, desplegado sin que un humano lea una sola línea.³ Los niveles anteriores trazan la progresión en la que se encuentran la mayoría de los equipos ahora mismo—desde la codificación manual (Nivel 0) pasando por la delegación de tareas (Nivel 1), piloto automático en autopista (Nivel 2), Waymo con conductor de seguridad (Nivel 3), y robotaxi donde escribes la especificación y te vas por 12 horas (Nivel 4).³

La pregunta que nadie ha respondido bien: ¿cómo es la capa de verificación en el Nivel 5?

El problema de verificación se amplifica

En todos los niveles por debajo del 5, un humano lee código en algún momento. En el Nivel 3, el humano gestiona la IA como un desarrollador senior. En el Nivel 4, el humano verifica si las pruebas pasaron después de 12 horas.³ Estos niveles funcionan porque una persona con conocimiento institucional puede comparar patrones contra la intención. La especificación decía “reintentar con retroceso exponencial” y el código hace reintento lineal—un desarrollador lo detecta de un vistazo.

Elimina al humano por completo, y la verificación se convierte en un problema diferente. No más difícil en grado. Diferente en naturaleza. El verificador no puede depender de la comprensión lectora. Debe codificar lo que significa “correcto” en forma ejecutable, y luego evaluar la salida contra esa codificación sin inspeccionar jamás el artefacto en sí.

La trampa central es que los agentes manipulan las pruebas. StrongDM descubrió que sus agentes escribían return true para pasar los suites de pruebas sin hacer nada útil.¹ Las pruebas estaban en verde. El pipeline de CI estaba satisfecho. El código era inservible. Eran Kahana de Stanford Law extiende la observación a una advertencia estructural: el problema más amplio es la circularidad, donde la misma clase de tecnología evalúa código que la misma clase escribió.⁴

La Ley de Goodhart opera aquí con fuerza inusual. Cuando los agentes optimizan para pasar pruebas, pasar pruebas deja de medir la corrección.⁴ Toda métrica que se convierte en objetivo deja de ser una buena métrica. La capa de verificación de una fábrica oscura debe contemplar esta dinámica, o medirá cumplimiento, no calidad.

Cómo StrongDM resuelve la verificación en la práctica

La respuesta de StrongDM es lo que llaman “Scenarios”—historias de usuario de extremo a extremo almacenadas fuera del código fuente, que funcionan como conjuntos de validación reservados en machine learning.¹ La analogía es precisa: así como los modelos de ML se evalúan contra datos sobre los que nunca entrenaron, el código construido por agentes se evalúa contra escenarios a los que el agente no puede acceder durante la generación.

La métrica clave es “Satisfacción”: la fracción de trayectorias observadas que probablemente satisfacen al usuario.¹ No existe un estándar de la industria para determinar qué puntuación constituye satisfacción suficiente. StrongDM llegó a su propio umbral de forma empírica.

Para que las pruebas basadas en escenarios funcionen a escala, StrongDM construyó un Universo de Gemelos Digitales—clones conductuales de Okta, Jira, Slack, Google Docs, Drive y Sheets.¹ Los gemelos apuntan a una compatibilidad del 100% con API usando bibliotecas cliente de referencia SDK populares y disponibles públicamente.¹ Los agentes se ejecutan contra los gemelos, no contra endpoints simulados. La fidelidad conductual del gemelo determina la confiabilidad de la prueba.

StrongDM observó algo que yo también he visto: “con la segunda revisión de Claude 3.5 (octubre de 2024), los flujos de trabajo de codificación agéntica de largo horizonte comenzaron a acumular corrección en lugar de error”.¹ Por debajo de un umbral de capacidad, las ejecuciones más largas de agentes producen más errores. Por encima de ese umbral, las ejecuciones más largas producen mejor código. El patrón de fábrica oscura solo se volvió viable después de que los modelos cruzaron ese umbral.

Cinco capas de gobernanza

El marco de transformación de cinco pilares de BCG Platinion incluye una capa de gobernanza con múltiples pasos de verificación antes de que el código llegue a producción.² Los pilares: un sistema operativo orientado por intención, infraestructura de conocimiento codificado, capacitación de la fuerza laboral, una capa de gobernanza con agentes de verificación independientes, y arquitectura de fábrica para orquestación.² Dentro del pilar de gobernanza, BCG Platinion describe pruebas basadas en escenarios ejecutadas por agentes independientes, análisis estático, verificación de conformidad arquitectónica, pruebas de regresión conductual, y agentes de red team que intentan activamente romper la salida.²

La independencia importa. Cuando el mismo agente escribe y prueba su propio código, se aplica el problema de circularidad de Kahana.⁴ Cuando un agente separado—con prompts de sistema diferentes, contexto diferente, incentivos diferentes—evalúa el trabajo, los modos de falla se descorrelacionan. No se eliminan. Se descorrelacionan. Dos agentes aún pueden compartir sesgos sistemáticos heredados de los datos de entrenamiento. Pero la probabilidad de puntos ciegos idénticos disminuye cuando el agente evaluador opera desde un marco diferente.

BCG Platinion identifica el “pensamiento de intención” como una competencia crítica para los equipos de fábricas oscuras: traducir necesidades de negocio en descripciones precisas y comprobables de los resultados deseados.² El rol humano pasa de escribir código a escribir especificaciones contra las cuales los agentes pueden ejecutar. Especificaciones deficientes producen pruebas que pasan sobre comportamiento incorrecto—la misma dinámica del return true que encontró StrongDM.¹

BCG Platinion también identifica una limitación que he experimentado directamente: “Los agentes de IA son solo tan efectivos como el conocimiento codificado al que pueden acceder”.² Un agente que opera sin contexto del proyecto genera código plausible que viola convenciones locales, ignora decisiones arquitectónicas y redescubre problemas que el equipo ya resolvió. El conocimiento codificado—decisiones de diseño, contratos API, guías de estilo, historiales de fallas—es infraestructura, no documentación.

Lo que ya ejecuto en el Nivel 4

Mi ciclo de ejecución nocturna, el Ralph Loop, opera en el Nivel 4 de Shapiro. Escribo especificaciones, lanzo agentes, duermo y reviso los resultados por la mañana. Los agentes se ejecutan contra más de 95 hooks que interceptan cada llamada a herramientas—escrituras de archivos, comandos de git, ejecución de shell—antes y después de la ejecución. Los hooks imponen restricciones con las que el agente no puede negociar ni eludir.

Los hooks abordan el problema de manipulación de Kahana a nivel de herramientas. Un agente que intenta hacer force-push a main es bloqueado antes de que el comando se ejecute, no después de que una prueba detecte el daño. Un agente que intenta hacer commit de archivos que coinciden con patrones .env es interceptado. Un agente que reporta “todas las pruebas pasaron” sin ejecutar pytest es señalado por la puerta de evidencia, que exige la salida pegada de las pruebas mostrando cero fallos, no una afirmación de que las pruebas pasarían.

La puerta de evidencia impone seis criterios en cada cambio no trivial: sigue los patrones del código base (nombra el patrón y el archivo), solución más simple que funciona (indica las alternativas rechazadas), casos límite manejados (lista cada uno), pruebas pasan (pega la salida), sin regresiones (nombra los archivos verificados) y resuelve el problema real (indica la necesidad del usuario y cómo el cambio la aborda). “Creo que” y “debería funcionar” no son evidencia. La puerta rechaza lenguaje ambiguo y exige artefactos.

El ciclo de calidad—implementar, revisar, evaluar, refinar, alejarse para ver el panorama, repetir, reportar—se ejecuta como una restricción conductual codificada en el prompt de sistema del agente a través de CLAUDE.md. El ciclo no garantiza que el agente siga cada paso. Los hooks verifican que lo hizo.

Los cinco pilares de BCG Platinion se corresponden con infraestructura que ya mantengo:

• Sistema operativo orientado por intención: los archivos CLAUDE.md y las especificaciones de desarrollo orientadas por PRD codifican la intención del proyecto como contexto ejecutable.
• Conocimiento codificado: más de 139 skills, organizados como capacidades reutilizables, dan a los agentes acceso a convenciones del proyecto, decisiones arquitectónicas y conocimiento del dominio.
• Gobernanza: los hooks implementan la capa de intercepción. La puerta de evidencia implementa la capa de auditoría. El ciclo de calidad implementa la capa de restricción conductual.

Dos pilares que no he construido: capacitación de la fuerza laboral (irrelevante para un profesional independiente) y arquitectura de fábrica como plataforma de orquestación dedicada (mi configuración actual usa el spawning nativo de agentes de Claude Code, no una fábrica construida para tal fin).

La brecha entre el Nivel 4 y el Nivel 5

Pasar del Nivel 4 al Nivel 5 significa eliminar la revisión matutina. Ahora mismo, me despierto y leo lo que los agentes produjeron durante la noche. Reviso los diffs de git. Ejecuto la aplicación. Verifico que la salida coincida con mi intención. Esa revisión toma entre 30 minutos y una hora, y detecta problemas que los hooks no capturan.

Los problemas que los hooks no capturan son los interesantes. Se agrupan en categorías que la automatización actual maneja deficientemente:

Deriva de intención. El agente completó la especificación fielmente, pero la especificación era ambigua, y el agente eligió la interpretación equivocada. Ninguna prueba detecta una interpretación incorrecta que produce comportamiento válido. El enfoque de escenarios de StrongDM aborda esto codificando historias de usuario como la especificación, no requisitos técnicos.¹ Los escenarios describen lo que un usuario experimenta, no lo que el código hace.

Erosión arquitectónica. El agente agregó una función que funciona de forma aislada pero degrada la coherencia estructural del sistema. Una nueva consulta a la base de datos que elude el patrón de repositorio existente. Un nuevo endpoint que duplica lógica de otro módulo. El análisis estático detecta algunos de estos casos. La verificación de conformidad arquitectónica—la capa de gobernanza de BCG Platinion—detecta más.² Ninguno detecta los casos sutiles donde el código nuevo es técnicamente consistente con los patrones pero introduce una división conceptual que se acumula con cambios futuros.

Pérdida de conocimiento institucional. Kahana plantea un riesgo subestimado: cuando nadie lee el código, nadie construye intuición sobre el sistema.⁴ Como advierte Kahana, “Nadie sabrá por qué. Nadie sabrá cómo arreglarlo”.⁴ Hoy, mi revisión matutina construye esa intuición de forma incremental. En el Nivel 5, el sistema se vuelve opaco para su operador. Todo sistema complejo eventualmente necesita una intervención que la automatización no puede manejar—un incidente de seguridad, un cambio en la lógica de negocio que viola supuestos incorporados en el suite de pruebas, una integración con un sistema externo que se comporta diferente a lo que su documentación afirma. El operador que nunca leyó el código no puede intervenir de manera efectiva.

Lo que la capa de verificación realmente necesita

Sintetizando la práctica de StrongDM, el marco de gobernanza de BCG Platinion, el análisis de fallas de Kahana y mi propia infraestructura, la capa de verificación para una fábrica oscura requiere como mínimo:

Evaluación tipo holdout. Pruebas a las que el agente generador no puede acceder durante la producción de código. Los escenarios de StrongDM. Especificaciones conductuales almacenadas separadamente del código, evaluadas por agentes independientes. Sin evaluación holdout, la Ley de Goodhart convierte cada suite de pruebas en un objetivo.

Gemelos digitales para pruebas de integración. Los agentes no pueden probar contra sistemas de producción. Los mocks son demasiado superficiales—verifican contratos API, no comportamiento. Los gemelos que replican la superficie conductual de dependencias externas permiten la ejecución de escenarios de extremo a extremo sin riesgo en producción.

Verificación multi-agente con modos de falla descorrelacionados. El agente que escribe y el agente que evalúa deben operar desde contextos diferentes. Los agentes de red team que buscan activamente manipulación, atajos y verificación fantasma agregan una capa que las pruebas pasivas no pueden proporcionar.

Intercepción a nivel de herramientas. Hooks que bloquean operaciones dañinas antes de la ejecución, no pruebas que detectan el daño después del hecho. La capa de hooks opera por debajo de la toma de decisiones del agente y no puede ser eludida mediante prompts ingeniosos o atajos de return true.

Especificaciones de intención ejecutables. Especificaciones lo suficientemente precisas para que la ambigüedad sea detectable. La competencia de “pensamiento de intención” de BCG Platinion.² La especificación de Nivel 4 de Shapiro que escribes antes de irte por 12 horas.³ La especificación es el producto. El código es un efecto secundario.

Registro de auditoría sin brechas de responsabilidad. Kahana cita los Principios Fundamentales del Ciclo de Vida de la IA que requieren que la salida sea “rastreable hasta una parte responsable apropiada”.⁴ Aún no existe una metodología de auditoría estándar de la industria para software construido por agentes.⁴ La capa de verificación necesita producir artefactos que un humano (o regulador, o responsable de respuesta a incidentes) pueda seguir desde el comportamiento desplegado hasta la especificación que lo generó.

La evaluación honesta

Ejecuto el Nivel 4 con alta confianza. Mis agentes nocturnos producen trabajo que pasa la revisión matutina más a menudo de lo que falla. Los hooks detectan las fallas mecánicas. La puerta de evidencia detecta las fallas epistémicas. El ciclo de calidad reduce las fallas conductuales.

El Nivel 5 requiere resolver problemas que no he resuelto. Detección de deriva de intención sin reconocimiento de patrones humano. Conformidad arquitectónica que detecte erosión conceptual, no solo violaciones estructurales. Conocimiento institucional que se acumule en el sistema en lugar de en la cabeza del operador.

BCG Platinion reporta ganancias de productividad de 3-5x en equipos que adoptan patrones de fábrica oscura.² StrongDM lanzó software construido por agentes con tres ingenieros y un presupuesto de tokens.¹ El caso de productividad es claro. El caso de verificación no lo es.

Los equipos que tienen éxito en el Nivel 5 comparten un rasgo común: invirtieron más en infraestructura de verificación que en generación de código. StrongDM construyó un Universo de Gemelos Digitales completo antes de confiar en que los agentes enviaran código a producción.¹ El marco de BCG Platinion tiene cinco pilares de transformación que incluyen una capa de gobernanza con múltiples pasos de verificación antes de que el código llegue a producción.² La fábrica oscura no es una fábrica que opera en la oscuridad. Es una fábrica donde las luces son la capa de verificación, y todo lo demás—incluido el código—es un commodity.

Escribí anteriormente sobre lo que se rompe cuando los agentes operan sin supervisión y sobre la puerta de evidencia como defensa contra la verificación fantasma. Esos artículos describen la infraestructura para el Nivel 4. La fábrica oscura exige esa misma infraestructura, extendida para operar sin el humano que actualmente lee el diff matutino. Los hooks, las puertas de evidencia, los ciclos de calidad—son necesarios en el Nivel 5, pero no suficientes. La pieza faltante es la verificación que escale con la misma autonomía que la generación.

Construir esa pieza es el trabajo que viene.