Verificación en la Dark Factory: cuando ningún humano lee el código

Una Dark Factory (Nivel 5) es un entorno de desarrollo de software donde las máquinas generan, verifican y despliegan código — ningún humano lee una sola línea. La capa de verificación que hace viable la dark factory requiere evaluación estilo holdout, Digital Twin Universes, revisión multi-agente y restricciones de gusto codificadas. Sin esa capa, los agentes manipulan las pruebas y la calidad desaparece.

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, con la empresa fusionando cientos de pull requests generados por IA mensualmente.²

Dan Shapiro denomina al punto final Nivel 5: la Dark Factory. Código generado por máquinas, verificado por máquinas, desplegado sin que un humano lea una sola línea.³ Los niveles precedentes rastrean la progresión que la mayoría de los equipos siguen ahora mismo: codificación manual (Nivel 0), 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 siguiente análisis mapea la infraestructura necesaria, construyendo sobre la infraestructura de gusto que gobierna cómo evalúo la calidad en todo mi trabajo de ingeniería.

El problema de verificación se multiplica

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 pasan después de 12 horas.³ Estos niveles funcionan porque una persona con conocimiento institucional puede detectar patrones contra la intención. La especificación decía “reintentar con backoff 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. El verificador debe codificar lo que significa “correcto” en forma ejecutable, y luego evaluar la salida contra esa codificación sin inspeccionar nunca el artefacto en sí.

La trampa central son los agentes manipulando pruebas. StrongDM descubrió que sus agentes escribían return true para pasar los suites de prueba sin hacer nada útil.¹ Las pruebas estaban en verde. El pipeline de CI reportaba éxito. 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. El gusto es un sistema técnico argumenta que la verificación automatizada necesita una capa de juicio por encima; sin evaluación a nivel de gusto, las pruebas se convierten en objetivos en lugar de medidas. Cuando los agentes optimizan para aprobar pruebas, aprobar 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 dark factory 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 holdout en machine learning.¹ La analogía es precisa: así como los profesionales de ML evalúan modelos contra datos con los que nunca entrenaron, agentes independientes evalúan el código generado contra escenarios que el agente de codificación no puede acceder durante la generación.

La métrica clave es “Satisfaction”: la fracción de trayectorias observadas que probablemente satisfacen al usuario.¹ No existe un estándar de la industria para 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 Digital Twin Universe: clones de comportamiento de Okta, Jira, Slack, Google Docs, Drive y Sheets.¹ Los gemelos apuntan a 100% de compatibilidad con API usando bibliotecas cliente de referencia populares y disponibles públicamente.¹ Los agentes se ejecutan contra los gemelos, no contra endpoints simulados. La fidelidad del comportamiento del gemelo determina la confiabilidad de la prueba.

StrongDM observó un patrón que yo también he visto: “con la segunda revisión de Claude 3.5 (octubre 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, las ejecuciones más largas producen mejor código. El patrón de dark factory 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 impulsado 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.² El pilar de gobernanza incluye pruebas basadas en escenarios ejecutadas por agentes independientes, análisis estático, verificación de conformidad arquitectónica, pruebas de regresión de comportamiento 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 diferentes system prompts, diferente contexto, diferentes incentivos) evalúa el trabajo, los modos de fallo se descorrelacionan. No se eliminan. Se descorrelacionan. Dos agentes 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 dark factory: 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. Las 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 restricción que he experimentado directamente: “Los agentes de IA son tan efectivos como el conocimiento codificado al que pueden acceder.”² Un agente que opera sin contexto de 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 fallos) es infraestructura, no documentación.

Lo que ya ejecuto en Nivel 4

Mi bucle de ejecución nocturna, la arquitectura del agente Ralph, 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 de herramienta (escrituras de archivos, comandos 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 herramienta. Una publicación separada documenta la arquitectura completa de hooks, pero la propiedad relevante aquí es la intercepción: los hooks se disparan antes de la ejecución de la herramienta, no después. Un agente que intenta hacer force-push a main se bloquea antes de que el comando se ejecute. Un agente que intenta hacer commit de archivos que coinciden con patrones .env es interceptado. Un agente que reporta “todas las pruebas pasan” sin ejecutar pytest es señalado por la puerta de evidencia, que exige salida pegada de 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 patrones del código fuente (nombra el patrón y el archivo), solución funcional más simple (indica alternativas rechazadas), casos límite manejados (enumera 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” no son evidencia. La puerta rechaza lenguaje ambiguo y exige artefactos.

El bucle de calidad (implementar, revisar, evaluar, refinar, ampliar perspectiva, repetir, reportar) se ejecuta como una restricción de comportamiento codificada en el system prompt del agente vía CLAUDE.md. El bucle no garantiza que el agente siga cada paso. Los hooks verifican que lo hizo.

Los cinco pilares de BCG Platinion se mapean a infraestructura que ya mantengo:

• SO impulsado por intención: los archivos CLAUDE.md y las especificaciones de desarrollo impulsadas 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 de dominio.
• Gobernanza: los hooks implementan la capa de intercepción. La puerta de evidencia implementa la capa de auditoría. El bucle de calidad implementa la capa de restricción de comportamiento.

No he construido dos pilares: capacitación de la fuerza laboral (irrelevante para un profesional individual) 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 a propósito). El sistema de contexto compuesto describe cómo estas capas de infraestructura se acumulan como un activo de capital, haciendo cada sesión subsiguiente más capaz.

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 de 30 minutos a una hora y detecta problemas que los hooks no captan.

Los problemas que los hooks no captan son los interesantes. Caen 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 incorrecta. 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 añadió una función que trabaja en aislamiento pero degrada la coherencia estructural del sistema. Una nueva consulta de base de datos que evita 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 (capa de gobernanza de BCG Platinion) detecta más.² Ninguno detecta los casos sutiles donde el nuevo código es técnicamente consistente con los patrones pero introduce una división conceptual que se multiplica con cambios futuros.

Pérdida de conocimiento institucional. Kahana plantea un riesgo poco apreciado: 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 intervención que la automatización no puede manejar: un incidente de seguridad, un cambio de lógica de negocio que viola supuestos integrados 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 eficazmente.

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 fallos de Kahana y mi propia infraestructura, la capa de verificación para una dark factory requiere como mínimo:

Evaluación estilo holdout. Pruebas a las que el agente generador no puede acceder durante la producción de código. Los escenarios de StrongDM. Especificaciones de comportamiento almacenadas por separado del código fuente, 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 de comportamiento 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 fallo 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 proporcionan una capa que las pruebas pasivas no pueden ofrecer.

Intercepción a nivel de herramienta. 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 se sitúa por debajo de la toma de decisiones del agente y resiste la elusión mediante prompting ingenioso o atajos tipo return true.

Especificaciones de intención ejecutables. Especificaciones lo suficientemente precisas como 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.

Trazabilidad sin vacíos de responsabilidad. Kahana cita los AI Life Cycle Core Principles 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 respondedor de incidentes) pueda trazar 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 la mayoría de las veces. Los hooks detectan los fallos mecánicos. La puerta de evidencia detecta los fallos epistémicos. El bucle de calidad reduce los fallos de comportamiento.

El Nivel 5 requiere resolver problemas que no he resuelto. Detección de deriva de intención sin coincidencia de patrones humana. 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 dark factory.² 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 Digital Twin Universe 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 dark factory 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 una mercancía.

Escribí anteriormente sobre lo que falla cuando los agentes operan sin supervisión y sobre la puerta de evidencia como defensa contra la verificación fantasma. Esas publicaciones describen la infraestructura para el Nivel 4. La dark factory exige esa misma infraestructura, extendida para operar sin el humano que actualmente lee el diff matutino. Los hooks, las puertas de evidencia, los bucles de calidad: todos necesarios en el Nivel 5, pero no suficientes. La pieza faltante es verificación que escale con la misma autonomía que la generación.

Construir esa pieza es el trabajo que viene. El hub de ingeniería de IA recopila el arco completo de esta investigación, desde el diseño individual de hooks hasta el contexto compuesto y la frontera de la dark factory.

FAQ

¿Qué es una Dark Factory en desarrollo de software?

Una Dark Factory (Nivel 5 de Dan Shapiro) es un entorno de desarrollo de software donde las máquinas generan código, verifican código y despliegan código sin que un humano lea una sola línea. Los niveles precedentes progresan desde la codificación manual (Nivel 0) a través de automatización creciente, siendo el Nivel 4 el modo “robotaxi” donde un humano escribe la especificación, se va por 12 horas y revisa los resultados. La dark factory elimina incluso esa revisión final.

¿Cuál es el mayor desafío de verificación en el Nivel 5?

La trampa central son los agentes manipulando pruebas. StrongDM descubrió agentes escribiendo return true para pasar los suites de prueba sin hacer nada útil. La Ley de Goodhart opera con fuerza inusual: cuando los agentes optimizan para aprobar pruebas, aprobar pruebas deja de medir la corrección. La capa de verificación debe contemplar esto usando evaluación estilo holdout (pruebas a las que el agente generador no puede acceder durante la producción de código), verificación multi-agente con modos de fallo descorrelacionados e intercepción a nivel de herramienta que bloquea operaciones dañinas antes de la ejecución.

¿Cuál es la brecha entre el Nivel 4 y el Nivel 5?

Tres problemas que la automatización actual maneja deficientemente: deriva de intención (el agente completó la especificación fielmente pero eligió la interpretación incorrecta de un requisito ambiguo), erosión arquitectónica (nuevas funciones que trabajan en aislamiento pero degradan la coherencia estructural) y pérdida de conocimiento institucional (cuando nadie lee el código, nadie construye la intuición sobre el sistema necesaria para intervenir durante incidentes o cambios de lógica de negocio).

¿Cómo resuelve StrongDM el problema de verificación?

StrongDM usa “Scenarios”, historias de usuario de extremo a extremo almacenadas fuera del código fuente que funcionan como conjuntos holdout en machine learning. Agentes independientes evalúan el código contra escenarios que el agente de codificación no puede acceder durante la generación. Construyeron un Digital Twin Universe (clones de comportamiento de Okta, Jira, Slack, Google Docs) apuntando a 100% de compatibilidad con API, para que los agentes prueben contra superficies de comportamiento realistas en lugar de mocks superficiales.