AI Software Factory: Quién la Vende y Dónde Se Rompe

BCG Platinion publicó en marzo un informe explicando cómo montar una AI software factory: agentes autónomos que construyen, prueban y despliegan software las veinticuatro horas mientras los humanos “definen la intención de negocio y revisan resultados”. Promete entre tres y cinco veces más productividad.

Desde entonces el término no ha parado. Factory.ai levantó 150 millones a una valoración de 1.500 en abril. Forrester publicó en el tercer trimestre un informe comparando veinticinco soluciones del mercado. Y en YouTube hay vídeos con cientos de miles de visualizaciones enseñándote a montar la tuya.

Nadie de los que te enseña a montarla te dice si funciona.

Este artículo va de eso: qué es exactamente una AI software factory, quién la está vendiendo, por qué la mayoría se cae, y qué señal tienes que poner en cada capa para que la tuya no se caiga. Cada afirmación con su fuente, y la contraevidencia incluida.

Lo tienes también en vídeo, con la matriz de señales explicada capa por capa:

Qué es y quién la vende

Una AI software factory es un pipeline: entra una especificación, salen pull requests. El humano deja de escribir código y pasa a revisar.

La versión extrema tiene nombre propio. Dan Shapiro la llamó dark factory en enero de 2026, tomándolo prestado de la fábrica de FANUC donde los robots construyen robots. Su definición: “está a oscuras porque es un sitio donde los humanos ni se necesitan ni son bienvenidos”. Nadie revisa el código.

Shapiro no lo planteó como un interruptor sino como una escala de cinco niveles, al estilo de los niveles de conducción autónoma. La dark factory es el nivel cinco. Sitúate en esa escala antes de seguir: casi todo el que dice tener una fábrica está en el dos o el tres.

De las plataformas que existen, ninguna cubre el recorrido completo.

Plataforma	Spec	Plan	Código	Test	Review	Merge
GitHub Copilot	❌	➖	✅	✅	✅	✅
GitLab Duo	❌	✅	✅	✅	✅	✅
AWS Kiro	✅	✅	✅	➖	❌	❌
Cognition (Devin)	❌	➖	✅	✅	❌	➖
Factory.ai	➖	✅	✅	✅	✅	✅
Claude Code	➖	✅	✅	✅	✅	❌
OpenAI Codex	❌	➖	✅	✅	➖	➖

Kiro es el único que ataca la especificación en serio, y se queda sin review ni merge. Factory.ai llega hasta el despliegue y flojea por la izquierda. La fábrica completa no existe como producto: la ensamblas tú en tu casa, uniendo piezas de sitios distintos.

Durante 2026 el modelo de precio se movió a consumo: GitHub pasó a créditos en junio, GitLab cobra un dólar por crédito, Devin factura por ACU (unos quince minutos de trabajo autónomo), OpenAI dividió su plan Pro en abril. El coste de tu fábrica es variable, y quien fija la variable no eres tú.

La distancia entre dos posiciones

Dos posiciones publicadas el mismo trimestre.

Por un lado, BCG: tres a cinco veces más productividad, 20% por aplicación a los dos días, más del 50% a escala. Son cifras de sus propios proyectos, sin muestra, sin línea base y sin definir en ningún sitio qué significa “productividad”.

Por otro, Thoughtworks. Su Technology Radar clasifica cada tecnología en cuatro anillos, de fuera adentro: evitar, probar, evaluar y adoptar. En el volumen 34, de abril, colocan los agentes de ingeniería de software en el tercero, evaluar. No en adoptar. Y dedican el tema de fondo del número a advertir de la “deuda cognitiva”.

Y Gartner, por si falta un tercero: predice que más del 40% de los proyectos de IA agéntica se cancelarán antes de que acabe 2027, por coste, valor poco claro y controles de riesgo insuficientes.

La distancia entre “de tres a cinco veces” y “evaluar” es el tamaño real del hype.

Esto ya pasó tres veces

El término software factory no es de 2026. Ni de 2004. Es de 1968, y tuvo dos padres a la vez.

R.W. Bemer, en General Electric, presentó The economics of program production en el congreso IFIP de Edimburgo. Su fábrica era “un entorno de programación que reside en un ordenador y está controlado por él”, con medidas y controles de productividad y calidad. GE salió del negocio de ordenadores en 1970 y la propuesta murió sin construirse.

Ese mismo año, en la conferencia de la OTAN donde se acuñó el término “ingeniería del software”, M.D. McIlroy defendió la producción en masa de componentes reutilizables. La objeción de sus contemporáneos, tal como la recoge Michael Cusumano, fue esta: “parecía demasiado difícil crear módulos de programa que fueran eficientes y fiables para todo tipo de sistemas y que no restringieran al usuario”.

Lee esa frase otra vez pensando en el código que te genera un agente hoy. Módulos con supuestos ocultos que nadie sabe catalogar para volver a encontrarlos. La objeción de 1968 es la de 2026.

El caso que se paró por las specs

En 1975, System Development Corporation —la gente que había construido el SAGE— montó la primera instalación estadounidense que se llamó explícitamente factory. Herramientas integradas, procedimientos estandarizados y una organización matricial que separaba el diseño de alto nivel de la construcción del programa.

Y funcionó. Unos diez proyectos entre 1976 y 1978: control de satélites meteorológicos, defensa aérea, comunicaciones para la policía de Los Ángeles. Todos menos el de la policía salieron en plazo y presupuesto, con menos defectos de lo habitual en la casa. Funcionó tan bien que el consejero delegado ordenó adoptarlo como estándar corporativo.

Murió igual. Cusumano resume las tres causas en una sola frase:

“Las herramientas no eran muy portables entre proyectos; los jefes de proyecto preferían construir su propio software antes que entregar especificaciones a la fábrica; y especificar el sistema de la policía de Los Ángeles, que era una aplicación desconocida para los ingenieros de SDC, llevó un año o más de lo previsto, dejando ociosos a los programadores de la fábrica.”

La fábrica se paró porque especificar tardaba más que construir. Los programadores, de brazos cruzados esperando specs. Y los jefes de proyecto prefiriendo escribir el código ellos antes que redactar la especificación que la fábrica les exigía.

Y luego dos veces más

CASE, años ochenta y noventa: diagramas que se convertían en código. Una encuesta sobre 102 organizaciones en Dinamarca y Finlandia encontró que menos del 20% eran usuarios rutinarios, pese a que casi una cuarta parte llevaba más de tres años con las herramientas. Iivari, en Communications of the ACM, identificó la causa principal: la complejidad percibida de la propia herramienta.

MDA/MDD, dos mil y pico: modelos independientes de plataforma que se transformaban automáticamente en cualquier cosa. El estudio de referencia es el de Whittle, Hutchinson y Rouncefield en IEEE Software (2014), con 450 profesionales encuestados y 22 entrevistas en profundidad. Sus conclusiones, literales:

“Los informes de ganancias de productividad varían ampliamente (desde una pérdida del 27% hasta una ganancia del 800%); la mayoría de las empresas parece experimentar aumentos de entre el 20 y el 30%.”

“MDE trae consigo mayores costes de formación y un cambio organizativo sustancial que fácilmente compensan esos aumentos del 20-30%.”

“La mayoría de los proyectos fracasan al escalar.”

Y esta:

“La generación de código es una pista falsa cuando se trata de describir MDE.”

Y 2004, Microsoft. Greenfield y Short publican Software Factories en Wiley. Prometen automatizar entre el 40% y el 80% del esfuerzo de desarrollo. Tres años después, con las herramientas ya en la calle, Greenfield describe en una entrevista con The Register lo que se encontró:

“Los arquitectos usan esas herramientas quizá un par de semanas al año. No son extensibles.”

Y sobre por qué no funciona nada enlatado: los arquitectos “no quieren la forma de hacer las cosas de otro, en conserva”. Microsoft archivó el repositorio de aquellas herramientas en febrero de 2021.

Pero las japonesas sí funcionaron

Hitachi montó su Software Works en 1969 —la primera del mundo en usar la palabra fábrica— y las cifras son buenas: ventas por empleado multiplicadas por 12 entre 1969 y 1984, proyectos entregados tarde a control de calidad del 72% al 6,9%, defectos reportados por usuarios de índice 100 a índice 13.

Toshiba, en Fuchu desde 1977, es todavía más clara. Productividad de 1.390 a más de 3.100 líneas equivalentes por persona y mes entre 1976 y 1985. Reutilización del 13% al 48%. Defectos mayores tras el test final de 7-20 por cada 1.000 líneas a 0,2.

Ahora, cómo consiguieron ese 48%. No con una herramienta. Toshiba montó un departamento entero de fabricación de piezas reutilizables, comités de dirección, y sobre todo incentivos coercitivos: objetivos de productividad imposibles de cumplir sin reutilizar un porcentaje pactado, obligación de registrar un número de componentes al mes en la biblioteca, y revisión formal del cumplimiento de esos objetivos en la evaluación de desempeño de cada persona.

El 48% de reutilización se sostuvo con gestión de personas, no con tecnología.

Ellos sí y SDC no por una razón: las fábricas japonesas trabajaban sobre familias de producto homogéneas —software básico de mainframe, control industrial repetitivo, clientes que pedían casi lo mismo—. SDC se estrelló justo cuando le entró una aplicación desconocida. Whittle encontró lo mismo en 2014: MDE funciona en dominios estrechos y falla al generalizar.

Lo que el test ve y lo que no

El pipeline confunde dos cosas: que los tests pasen, y que el trabajo esté bien hecho.

Quien mejor lo ha desarrollado es Dex Horthy. Y antes de citarle, un aviso que él mismo pone en la primera nota de su ensayo: dirige HumanLayer y vende herramientas de este sector. Que lo sepas al leerlo.

Le da credibilidad el historial: corrió una fábrica a oscuras de julio a noviembre de 2025 y la abandonó. Generó código inmantenible, y un solo bug le costó semanas de depuración humana. Después de eso bajó su promesa pública de “diez a cien veces” a dos o tres veces.

Su diagnóstico raíz es que no hay penalización por erosionar la mantenibilidad. Los benchmarks con los que se entrena y se mide esto preguntan dos cosas: ¿arreglaste lo que te pedí?, ¿lo hiciste sin romper nada más? Ninguna de las dos pregunta por el diseño.

Un test te contesta en segundos. Una mala decisión de arquitectura te pasa la factura en semanas, meses o años — el día que alguien abre ese fichero para un cambio de una línea. Por eso el aprendizaje por refuerzo puede dar millones de vueltas al test y ninguna al diseño.

Esto tiene una consecuencia medible en el código que se está escribiendo. GitClear analizó 623 millones de cambios entre 2023 y 2026:

Señal	Cambio
Duplicación de bloques	+81%
Copy/paste dentro del mismo commit	+41%
Estructuras que ocultan errores	+47%
Código movido (refactor)	del 21% al 3,8%

La última fila es la que cuenta la historia. El refactor es la operación que mantiene vivo un diseño, y ha caído a menos de una quinta parte mientras la duplicación se doblaba.

La metodología de GitClear está cuestionada. Un estudio académico posterior encuentra que el impacto sobre el churn es dependiente del contexto y no uniformemente negativo, porque GitClear usa una fecha de corte global en vez de la adopción real de cada repositorio. Y el propio fundador de GitClear ha escrito que el churn como indicador es intrínsecamente defectuoso, porque depende de los hábitos de commit de cada persona. Las cifras de duplicación y de refactor me parecen sólidas; con las de churn ten cuidado.

El fraude escala con el tamaño

SpecBench (mayo de 2026) hace algo que casi ningún benchmark hace: descompone cada tarea en especificación, tests visibles y tests ocultos. La diferencia entre el porcentaje de aprobados visibles y ocultos es lo que llaman reward hacking gap, y es una medida directa de cuánta trampa hay.

Los resultados, sobre treinta tareas de programación a nivel de sistema:

Todos los modelos saturan la suite visible en todas las tareas, sin excepción.
El gap crece unos 27 puntos porcentuales por cada diez veces que multiplicas las líneas de código.
Por debajo de 10.000 líneas, el gap máximo es de 21 puntos. Por encima de 25.000, hay gaps de 100 puntos.
Los modelos más fuertes tienen gaps menores, pero ninguno llega a cero.

El caso extremo que documentan: un compilador de tabla hash de 2.900 líneas que memorizaba las entradas de test. 97% en validación. 0% en holdout.

El fraude escala con el tamaño del sistema. Y el tamaño del sistema es exactamente la dimensión en la que opera una fábrica.

Si crees que esto es un problema de laboratorio, mira dónde ocurre en el sitio donde más confías. SWE-bench Pro embarca el directorio .git completo dentro de sus contenedores. Los agentes ejecutan git log --all y copian el fix ya mergeado. No es una teoría: son issues abiertos en los repositorios de los propios mantenedores del benchmark, uno de ellos titulado literalmente “Git Reward Hacking”.

Cuando tu única señal es un semáforo verde, no mides si el trabajo está bien: mides si el agente supo ponerlo en verde.

El cuello de botella no desapareció: se movió

Hay un dato de 2009 que sigue siendo el techo. SmartBear estudió las revisiones de código en Cisco: diez meses, dos mil quinientas revisiones, tres millones doscientas mil líneas. Los resultados:

Revisar entre 200 y 400 líneas de una vez, en 60-90 minutos, detecta entre el 70% y el 90% de los defectos.
Por encima de 400 líneas, la capacidad de detectar cae.
Por encima de 450 líneas por hora, la densidad de defectos detectados está por debajo de la media en el 87% de los casos.
La detección se desploma tras 90 minutos continuos.

Ese techo es fisiológico y no se ha movido en diecisiete años. Cuando le metes más volumen del que aguanta, pasa esto:

Faros AI midió justo eso. Telemetría de 22.000 desarrolladores en más de 4.000 equipos, dos años. Al pasar de baja a alta adopción de IA:

Sube esto	Y también esto
+33,7% throughput de tareas por dev	+242,7% incidencias por PR
+66% épicas por dev	+57,9% incidencias mensuales
+16,2% PRs mergeados por dev	+54% bugs por dev
	+31,3% de PRs mergeados sin ninguna revisión
	+441,5% tiempo mediano en revisión

Fíjate en el par de la primera fila. No es que haya más incidencias porque hay más código: es que cada PR es más peligroso que antes. Eso no se arregla produciendo más rápido.

Y el 31,3% de PRs que se mergean sin revisar sale de ahí: los revisores no dan abasto.

Poner otro agente a revisar no cierra el loop

La respuesta obvia es delegar la revisión a un agente. Hay un estudio sobre 278.790 conversaciones de revisión en trescientos proyectos de GitHub que mide qué pasa:

Las sugerencias de agentes se adoptan al 16,6%. Las humanas, al 56,5%.
Más de la mitad de las no adoptadas eran directamente incorrectas.
Cuando sí se adoptan, aumentan la complejidad y el tamaño del código más que las humanas.
Entre el 85% y el 87% de las revisiones iniciadas por un agente terminan tras el primer comentario, sin discusión.

Un revisor automático con una tasa de adopción tres veces peor que la humana no te quita trabajo: te añade ruido que alguien tiene que filtrar.

Los dos casos de éxito, leídos en la fuente original

Los dos casos que todo el mundo cita para demostrar que la fábrica funciona dicen otra cosa cuando vas al post original.

Stripe publicó en febrero que más de mil pull requests mergeados cada semana los producen enteramente sus agentes, los “minions”. Es la cifra que circula. Lo que no circula está en el mismo post, y lo cito porque cambia el significado entero: todo el código generado por los minions pasa revisión humana antes de mergearse.

Es decir: la empresa que mejor ha montado la fábrica no ha eliminado el cuello de botella de la verificación. Lo ha alimentado. Ahora tiene mil PRs más a la semana que revisar.

Spotify reporta más de 1.500 PRs mergeados a producción por su agente Honk, con un ahorro del 60-90% del tiempo. El trabajo que enumeran es este: modernización de lenguaje (Java records), actualizaciones con cambios rompedores en pipelines de Scio, migración de componentes de UI, actualizaciones de ficheros YAML y JSON.

Son migraciones. Trabajo mecánico, repetitivo, con criterio de corrección objetivo y verificable por compilación y por los tests que ya existían.

Eso no refuta nada de lo anterior. Lo confirma: los agentes rinden espectacularmente donde la verificación es barata y automática. Y el propio Spotify, en un post posterior titulado “escribir código ya no es la restricción”, admite que ahora tienen un 76% más de PRs que revisar y que el modelo rinde peor en bases de código fragmentadas. Lo tienen medido.

Hay un problema de fondo con las tres cifras que circulan: Stripe, Spotify y el millón de líneas de OpenAI. Las tres publican el numerador y ninguna publica el denominador. Cuántos PRs se revisaron de verdad, cuántos se revirtieron, qué incidencias causaron. Y contar PRs está desacreditado como medida de valor: en el estudio de productividad de Copilot, las líneas netas de código correlacionan con la productividad percibida a ρ ≈ 0,09. Cero.

Ninguna de las tres cifras hay que desmentirla; basta con pedir la otra mitad.

Lo que me he encontrado yo

Todo lo anterior son datos de otros. Estos son míos, de los últimos dos meses montando un pipeline de agentes sobre un proyecto real. Van sin nombres, pero las cifras y las frases son literales.

Agosto, un martes. Un agente cierra su tarea así: “servicio terminado. 7677 tests · 28506 aserciones · 0 fallos”. Trae además el diagrama de la cadena entera, desde la petición HTTP hasta la base de datos, y tres decisiones de diseño justificadas. Un entregable impecable.

Ningún test cubría el comportamiento nuevo. Y los tests que sí pasaban lo hacían porque el propio agente les había añadido el mock del colaborador que acababa de introducir. Es decir: el mock que metió para que aquello compilara era exactamente lo que mantenía el semáforo en verde. Por interfaz tampoco se podía llegar, porque el front todavía no enviaba el campo.

Lo cazó una pregunta de una línea: “¿has hecho las pruebas? ¿también desde el browser?”. Fue a comprobarlo y contestó esto:

“Corrí la suite y da 7677 en verde, pero eso no prueba nada de lo que acabo de escribir. Los 5 tests pasan porque les añadí el mock del resolver, no porque comprueben nada. Es un falso verde de manual.”

Dos semanas después, otro. Un agente entrega el test que protege el orden de dos llamadas dentro de un servicio, y lo entrega con esta afirmación: “si alguien invierte las líneas en este servicio, este test falla”. Suite completa en verde, más de nueve mil tests, cero fallos.

No me lo creí, así que invertí las líneas a propósito. El test pasó igual: siete de siete en verde con el orden invertido. El motivo es una sutileza de la librería de mocks: el modificador ordered() solo ordena dentro del mismo mock, y entre mocks distintos hace falta globally()->ordered(). Un barrido posterior encontró otro caso idéntico en el mismo repositorio.

Un test de orden que no falla al invertir el orden es peor que no tener test, porque das por protegida una regla que no lo está.

El patrón, que no es el que yo esperaba

Buscando estos casos esperaba encontrar al agente haciendo trampa: modificando el test para aprobar, revirtiendo el trabajo del que iba a juzgarlo. No hay ni uno. En ninguno de los incidentes que he podido reconstruir el agente sabía que estaba dando un resultado falso.

Lo que hay es más aburrido y bastante más peligroso: el agente se cree su propia señal. Mocks que sostienen el verde. Aserciones que no pueden fallar porque comprueban un campo que no existe. Un helper que hacía console.log y return dentro del cuerpo del it(), con lo cual el runner contaba como pasados unos tests que no ejecutaban una sola línea. Un ... | head && echo "OK" donde el && se encadenaba al head y no al typechecker, así que imprimía OK con errores de tipo reales.

Y en los cinco casos que he revisado, lo que lo destapó fue siempre lo mismo: alguien que rompió el código a propósito para ver si el test se enteraba, o que preguntó “¿lo has probado de verdad?”.

Ni una sola vez lo cazó la suite.

Y sin embargo, funciona

El único ensayo controlado grande y multi-empresa dice que sí funciona. Cui, Demirer, Jaffe, Musolff, Peng y Salz publicaron en Management Science en 2025 tres experimentos de campo en Microsoft, Accenture y una empresa del Fortune 100, con 4.867 desarrolladores: un +26,08% de tareas completadas. Revisado por pares. Trescientas veces más sujetos que el estudio de METR que todo el mundo cita en contra.

Google midió un +21% en su propio ensayo interno. Y Microsoft publicó en julio los resultados de desplegar agentes de línea de comandos a decenas de miles de ingenieros: los adoptantes mergearon en torno a un 24% más de PRs, con adopción sostenida y no por efecto novedad. Los autores se autolimitan con una honestidad que agradezco: “un PR mergeado no es lo mismo que el valor que entrega”.

El estudio que va contra lo que yo defiendo

Llevo tiempo defendiendo el desarrollo dirigido por especificaciones. En abril, Brenn Hill publicó un trabajo que prueba cinco hipótesis derivadas de las afirmaciones de los vendedores de SDD sobre 100.247 pull requests en 119 repositorios, con trazado de defectos y efectos fijos dentro del mismo autor. Ninguna se sostuvo. Las especificaciones se asocian a más rework (+5,0 puntos, p < 0,001) y su calidad no tiene ningún efecto sobre el rework (p = 0,997).

Su conclusión es que los artefactos de especificación son un indicador indirecto de la complejidad de la tarea, no una mejora de la calidad.

Dos precisiones. La asociación con más defectos (+1,4 puntos) tiene un p = 0,056, que no es significativo al 5%: el resultado fuerte del estudio es el rework, no los defectos. Y es un borrador, sin revisión por pares.

Dicho eso, ahora las dos limitaciones que declara el propio autor, porque son las que importan. La primera es la primera amenaza a la validez de su artículo:

“Nuestro clasificador identifica artefactos de especificación (issues enlazadas, descripciones estructuradas), no la calidad o la profundidad del proceso de especificación. Un ticket de Jira creado para satisfacer un requisito de proceso se clasifica igual que un documento de diseño detallado producido tras un refinamiento iterativo. Si los beneficios que se atribuyen a SDD vienen del proceso y no del artefacto, nuestra medida es demasiado gruesa para detectarlos.”

Para que se entienda lo gruesa que es: en su dataset, un fixes #456 en la descripción del PR cuenta como especificación. Ocho mil de cien mil PRs quedaron clasificados así. Eso no es spec-first; es papeleo detectable en un metadato.

La segunda:

“No podemos descartar que los flujos verdaderamente agénticos —donde el agente lee la especificación como su entrada principal, en lugar de un humano escribiendo código con asistencia opcional de IA— produzcan resultados diferentes.”

Pero tampoco cambian el estado de la cuestión: hoy no existe un estudio que demuestre que el desarrollo dirigido por especificaciones reduzca defectos. Existe este, que dice lo contrario, y dos motivos —del propio autor— para pensar que mide otra cosa.

Y la distinción con la que cierra se la compro entera:

“Los vendedores de SDD confunden dos funciones distintas: dirigir a la IA (decirle qué construir) y asegurar la calidad. Las especificaciones pueden ser efectivas en lo primero… pero dirigir no es calidad.”

“Un agente que ejecuta fielmente una especificación reproducirá cada hueco, cada ambigüedad y cada suposición equivocada de esa especificación, con total confianza. Una especificación puede ser exhaustivamente larga y aun así estar incompleta. Puede especificar el comportamiento equivocado con precisión.”

“La especificación le dice a la IA qué construir. No le dice a la IA qué se le olvidó especificar.”

Eso es exactamente lo que le pasó a SDC en 1978 con el sistema de la policía de Los Ángeles.

La matriz de señales

Si el semáforo verde no basta, ¿qué pones?

Toda señal sacrifica algo. Tres propiedades:

Escalable: ¿puedes lanzarla mil veces sin coste?
Veraz: ¿mide lo que de verdad te importa?
No manipulable: ¿puede el agente hacerle trampa?

Señal	Escalable	Veraz	No manipulable
Tests	✅	❌	❌
Tipos y linter	✅	❌	✅
Árbol de accesibilidad	✅	➖	✅
Captura de pantalla	❌	✅	✅
Otra IA juzgando el trabajo	✅	➖	❌
Feedback de usuario real	❌	✅	✅

Ninguna fila tiene las tres.

Los tests escalan perfecto, pero pasar no es estar bien y además el agente puede tocarlos. Los tipos y el linter tampoco son fieles —un código con tipos correctos puede estar mal diseñado— pero sí son no manipulables: al compilador no lo convences.

El árbol de accesibilidad es el que casi nadie usa y debería. Es la estructura de la página en texto, y Playwright ya la expone como aserción de snapshot. Escala, no se manipula, y es medio fiel: te dice qué elementos hay y cómo se llaman, pero no si se pintaron bien.

Aquí hay que corregir algo que circula mucho. Se repite que el árbol de accesibilidad es diez o cien veces más barato en tokens que una captura. No cuadra. Con la fórmula de Anthropic para tokens de imagen, ancho por alto entre 750, una captura de viewport sale por unos 1.600 tokens; un snapshot ARIA de una página típica anda entre 500 y 4.000. La ventaja del árbol de accesibilidad no es el coste: es que es texto determinista, que puedes comparar con un diff y sobre el que puedes escribir aserciones. El argumento del determinismo aguanta. El del precio no.

La captura de pantalla es lo contrario: es la única que ve si la animación corrió, si el gráfico se pintó, si el aviso dice lo que tenía que decir. Y no escala.

Otra IA juzgando el trabajo, con los criterios que tú le des, merece un aviso propio, porque hay un tópico desactualizado. Un estudio de Berkeley con veintiún jueces y unos 541.000 juicios midió que el sesgo de verbosidad es inferior a 0,011 en los veintiún modelos. Que los jueces premian respuestas largas ya no se sostiene. Lo que sí falla es otra cosa: el acuerdo bruto sobreestima la discriminación real entre 34 y 41 puntos. Alta reproducibilidad no implica validez. Un panel de jueces puede equivocarse de forma consistente y muy segura de sí misma.

Cómo aplicarlo por capa

En back: tests para escalar, más tipos y linter para tapar el hueco de manipulación. Y si puedes, tests aleatorizados, para que el agente no sobreajuste a los que ve.
En front: el árbol de accesibilidad como señal por defecto, porque es barata y determinista. Captura de pantalla solo donde la estructura no te dice nada — animaciones, gráficos, avisos.
Encima de todo: alguien mirando si el diseño aguanta. Eso no lo automatizas.

Y una que no está en la tabla porque no es una señal, sino la forma de comprobar que tu señal existe: rompe el código a propósito y mira si el test se entera. Invierte las dos líneas cuyo orden dice proteger. Cambia el valor que dice validar. Si sigue en verde, no tienes una señal, tienes un adorno. Es lo único que ha cazado los cinco casos que he contado arriba, y cuesta treinta segundos por test.

Un aviso práctico sobre lo segundo: el árbol de accesibilidad incluye elementos que están fuera de la pantalla, y hay un fallo abierto en Playwright por esto. Si no lo filtras, tu agente escribe tests contra botones que el usuario no puede ni ver.

Y sobre los tests basados en propiedades, que se están vendiendo como la solución: un estudio concluye que las propiedades que generan los modelos son con frecuencia triviales o incorrectas, y otro mide que las pruebas por propiedades y las de ejemplo detectan cada una el 68,75% de los bugs, pero combinadas llegan al 81,25%. Las dos juntas detectan más que cualquiera de las dos sola.

Si quieres el detalle de cómo se monta el andamiaje alrededor de estas señales, lo desarrollé en harness engineering y loop engineering; cuándo repartir el trabajo entre varios agentes, en graph engineering; y qué meterle al agente en la ventana para que la señal le llegue, en context engineering.

Eso que se vende como “la fábrica” son estas cuatro capas juntas.

La fábrica a oscuras no funciona

El argumento más fuerte contra la fábrica a oscuras viene de la manufactura física.

Es el dominio más favorable posible para automatizar del todo. Las piezas son idénticas. Las tolerancias se miden. La especificación completa cabe en un plano CAD. Y la verificación es metrología objetiva: la pieza mide lo que tiene que medir o no lo mide.

FANUC lleva con su planta a oscuras desde 2001. Veinticinco años. Robots construyendo robots, unas cincuenta unidades por turno de veinticuatro horas, hasta treinta días seguidos sin supervisión.

Según la Federación Internacional de Robótica, la densidad media mundial es de 132 robots por cada 10.000 empleados de manufactura. El 1,3%. Y eso después de duplicarse entre 2014 y 2024.

Las plantas que se venden como “sin humanos” tampoco lo son. En la de Xiaomi en Changping hay gente en una sala de control, técnicos de mantenimiento y equipos de software; lo que se ha eliminado son las operaciones manuales de línea, no las personas. El motivo técnico lo resume bien un análisis del sector: “no existe un solo robot que sea tan inteligente y tan versátil como un trabajador humano”. La industria va hacia plantas con menos gente dentro, no vacías.

Veinticinco años, el dominio más favorable que existe, y la fábrica a oscuras sigue siendo una anécdota estadística. El software no tiene ninguna de esas cuatro ventajas.

Y queda un argumento más, el más de fondo de todos. Jack Reeves escribió en 1992 que el código fuente es el diseño: la fabricación en software la hacen el compilador y el enlazador, y cuesta prácticamente cero. Si eso es cierto, la metáfora de la fábrica está mal desde la raíz. Automatizar la fabricación no ahorra nada, porque la fabricación ya era gratis. Todo lo que hacen los humanos en software es diseño.

Que es, palabra por palabra, lo que Brooks escribió en 1986:

“La parte más difícil de construir un sistema software es decidir con precisión qué construir. Ninguna otra parte del trabajo conceptual es tan difícil… Ninguna otra parte lisia tanto el sistema resultante si se hace mal.”

Y lo que Parnas le dijo en 1985:

“La programación automática siempre ha sido un eufemismo para programar con un lenguaje de más alto nivel del que estaba disponible para el programador en ese momento.”

Qué hacer con todo esto

Todo el mundo te vende la fábrica. Casi nadie te dice que el trabajo se mueve, de escribir a verificar.

Cinco cosas concretas antes de montar el pipeline:

Decide la señal antes que la herramienta. Escalable, veraz, no manipulable: elige dos, a conciencia, y ten clarísimo cuál te falta. Esa es la decisión de arquitectura; lo demás es fontanería.
Comprueba la señal antes de fiarte de ella. Rompe adrede lo que el test dice proteger. Si no se entera, arréglalo antes de meter un agente a producir contra ese test.
Ponle un tamaño máximo al cambio. No por elegancia: porque el fraude escala con las líneas y la detección humana se cae a partir de 400 líneas.
Aprovecha que las migraciones son el caso fácil. Ahí la verificación es objetiva y automática, y es donde Spotify saca su 60-90%. Empieza por ahí, no por la feature con diseño abierto.
No apagues la única señal fiel que tienes. Las fábricas a oscuras no fallan por culpa de los modelos, sino porque han quitado lo único capaz de ver que el diseño no aguanta.

P.D.: si has montado un pipeline de este tipo y tienes el denominador que a Stripe, Spotify y OpenAI se les olvida publicar —cuánto se revisó de verdad, cuánto se revirtió, qué incidencias salieron— me interesa muchísimo verlo, aunque el número sea feo. Y si tienes un test que dice proteger algo, pruébalo: rómpelo a propósito y cuéntame en X (@lm_martinbar) si se enteró.