La fábrica que no necesita luz

En 2003, en una fábrica de FANUC cerca del monte Fuji, robots fabricaban otros robots a oscuras. Producían unos cincuenta cada veinticuatro horas y podían pasar hasta un mes trabajando sin que nadie los vigilara. Cuando se detenían, no era porque algo se hubiera estropeado. Era porque ya no quedaba sitio para almacenar más robots.

Llegaban los camiones, retiraban los que estaban terminados y la producción comenzaba de nuevo. Según explicaba uno de los vicepresidentes de la empresa, ni siquiera necesitaban mantener encendida la calefacción o el aire acondicionado. Dentro no había nadie que los necesitara.

La idea de una fábrica así no era nueva. Veinte años antes, Roger Smith, presidente de General Motors, había imaginado robots tan fiables que podrían atornillar una transmisión sin necesidad de luz. Pero los robots de sus fábricas apenas conseguían trabajar bien con las luces encendidas. Los encargados de pintar los coches, por ejemplo, acababan a menudo pintándose a sí mismos.

Se los había vendido FANUC, que pasó los años siguientes acercándose a la fábrica que Smith había imaginado, según relataba Business 2.0 en 2003.

La fábrica de FANUC podía funcionar sin vigilancia porque sus máquinas repetían un trabajo conocido, en un entorno preparado para hacerlo. Pero ¿qué ocurre cuando lo que hay que fabricar cambia con cada encargo?

Una fábrica de programas

A principios de 2026, la expresión fábrica a oscuras (dark factory, en inglés) empezó a utilizarse también para hablar del desarrollo de software. Los nuevos agentes de inteligencia artificial ya no se limitaban a completar fragmentos de código. Podían recibir una tarea, modificar varios archivos, ejecutar pruebas, corregir sus errores y continuar trabajando sin pedir instrucciones a cada paso.

Algunos equipos empezaron a llevar esa autonomía mucho más lejos. En StrongDM, por ejemplo, establecieron dos reglas para su fábrica de software: ninguna persona debía escribir código ni revisarlo. Los agentes se encargarían de ambas cosas. A los humanos les correspondía definir lo que debía hacer el programa y comprobar los resultados.

Lo difícil era conseguir que esa cadena de trabajo siguiera funcionando cuando nadie estaba pendiente de ella.

En febrero de 2026, Nicholas Carlini, investigador de Anthropic, contó un experimento que mostraba hasta dónde se podía llegar. Había puesto a dieciséis agentes a trabajar durante dos semanas en la construcción de un compilador de C, un programa capaz de traducir el código de otros programas para que pudiera ejecutarlos una máquina.

Los agentes se repartían el trabajo por su cuenta. Cada uno elegía una tarea, la reservaba para evitar que otro hiciera lo mismo, buscaba una solución y compartía sus cambios con los demás. Cuando terminaba, empezaba otra.

Después de casi dos mil sesiones y un gasto algo inferior a veinte mil dólares, habían producido unas cien mil líneas de código. El compilador podía construir una versión de Linux capaz de arrancar, además de programas como PostgreSQL y Doom. Tenía limitaciones importantes y todavía necesitaba apoyarse en herramientas existentes para algunas operaciones, pero hacía cosas que poco antes habrían parecido fuera del alcance de un equipo de agentes.

Carlini no había tenido que indicarles cómo resolver cada problema. Sin embargo, tampoco se había limitado a darles una orden y marcharse.

Según explicó, dedicó buena parte de su esfuerzo a preparar y mejorar las pruebas, el entorno de trabajo y la información que recibían los agentes cuando algo fallaba. Utilizó GCC, un compilador ya existente, para comparar resultados, y fue incorporando nuevas comprobaciones al descubrir errores que las anteriores no detectaban.

Los agentes podían avanzar solos porque tenían una forma de saber cuándo estaban haciendo algo mal. Y conseguir que lo supieran era precisamente la parte del trabajo que Carlini había tenido que preparar.

Esa manera de organizar el trabajo tiene más de un siglo.

El hilo roto

Sakichi Toyoda, el hombre que acabaría fundando el grupo industrial del que nació Toyota, creció viendo a su madre trabajar hasta tarde en un telar manual. Quería encontrar una manera de hacerle la tarea más fácil.

Uno de los problemas de los telares era que podían seguir tejiendo después de que se rompiera un hilo. Si nadie se daba cuenta, la máquina continuaba produciendo tela defectuosa. Por eso hacía falta alguien pendiente de su funcionamiento.

En 1896, Toyoda desarrolló un telar mecánico que se detenía automáticamente cuando se rompía el hilo de la trama. Continuó perfeccionando sus máquinas y, con el telar automático que terminó en 1924, un solo trabajador podía llegar a atender entre treinta y cincuenta telares.

Ya no tenía que observarlos continuamente. Podía ocuparse de otras tareas y acudir cuando uno se detenía, resolver el problema y buscar la manera de evitar que volviera a ocurrir.

La idea terminó convirtiéndose en uno de los principios del sistema de producción de Toyota, que todavía lo llama jidoka: automatización con un toque humano. No se trataba simplemente de conseguir que las máquinas trabajaran solas, sino de que fueran capaces de detectar cuándo algo iba mal y dejaran de producir defectos.

En cierto modo, Carlini había hecho algo parecido. Sus agentes tampoco necesitaban que alguien observara cada paso. Las pruebas detectaban los fallos y les permitían corregirlos sin esperar instrucciones.

Pero hay una diferencia importante entre un telar y una fábrica de software.

Un hilo roto es un hilo roto, independientemente de la tela que se esté fabricando. La máquina puede reconocer ese problema sin saber para qué se utilizará la tela.

En el software, en cambio, lo que constituye un error depende de lo que se quiera construir. Un programa puede superar todas sus pruebas y, aun así, no hacer lo que necesitaba quien lo encargó.

El experimento de Carlini tenía una ventaja: un compilador de C debía ajustarse a unas reglas conocidas desde hacía décadas. Existían programas con los que comparar sus resultados y numerosas pruebas que permitían comprobar si funcionaba correctamente.

Pero cuando alguien encarga un programa nuevo, no siempre existe una referencia así. Antes de construirlo hay que decidir qué debe hacer, qué situaciones debe resolver y cómo distinguir una respuesta correcta de una equivocada. Y esas decisiones no quedan resueltas por el simple hecho de automatizar la escritura del código.

Tampoco basta con preparar una fábrica que funcione bien una vez. Los modelos de inteligencia artificial cambian y, con ellos, su manera de interpretar instrucciones, resolver problemas y utilizar las herramientas. Un procedimiento fiable con un modelo puede comportarse de otra manera con el siguiente.

Algunos fallos hacen que las pruebas se detengan. Otros son más difíciles de reconocer. A veces la producción continúa, las comprobaciones se superan y nadie advierte que el resultado se está alejando de lo que se pretendía construir.

Los agentes pueden asumir cada vez más trabajo y necesitar menos intervenciones. Pero eso hace que las decisiones que quedan fuera de la cadena automática tengan más importancia. Una instrucción, una prueba mal diseñada o un criterio equivocado pueden condicionar miles de operaciones posteriores.

En FANUC se podían apagar las luces porque la fábrica sabía qué debía producir y cómo hacerlo. En el desarrollo de software, cada nuevo encargo obliga a establecer de nuevo qué significa que el trabajo esté bien hecho.

El problema ya no es tener que vigilar cómo trabaja cada máquina. Es asegurarse de que la fábrica sigue construyendo lo que se necesita.

Porque un hilo roto puede detener un telar. Pero a veces cambia la tela sin que nada se pare.