Tu Fábrica de Software Es una Dark Kitchen. Los $1,000 Que Nadie Menciona.
En el verano de 2021, todo el mundo abrió una dark kitchen. Alquilar un espacio industrial en las afueras, poner una marca en Deliveroo, saltarse el comedor y el personal de servicio por completo. La propuesta era difícil de rebatir: producir sin los gastos generales de un restaurante real. Lo que las historias de éxito omitían es que Deliveroo se llevaba entre el 20 y el 30%, la mitad de los operadores no tenían ningún proceso de control de calidad, y la brigade de goût (el equipo que prueba antes de que la comida salga de la cocina) no existía. La línea siguió funcionando. La comida salió. La comida a domicilio era una lotería entonces y es una lotería ahora. Nada ha cambiado. Pero me desvío del tema.
TLDR: La mayoría de posts sobre fábricas de software hablan de velocidad: 650 PRs al mes, 1 millón de líneas con 3 ingenieros. Ninguno menciona la capa de $1,000 al día que hace que esos números sean seguros de ejecutar. Mi fábrica funcionó sin ella. Lo que envió lo dejó muy claro.
En 2026, todo el mundo está abriendo una fábrica de software. Agentes que planifican, codifican, testean y despliegan, sin punto de control humano en cada paso. Los números son reales: según el análisis de BCG Platinion de abril de 2026, Spotify no ha escrito ni una sola línea manual desde diciembre de 2025 (650 PRs generados por IA al mes, migraciones 90% más rápidas). OpenAI: 1 millón de líneas en 5 meses, 3 ingenieros, cero código manual. Nadie se está inventando esos números. Lo que están omitiendo tampoco es inventado.
Mi pipeline ejecuta transformaciones automatizadas para un backend de ecommerce (datos de productos desde feeds CSV de distribuidores, integraciones de APIs de socios, lo habitual). Ampliamente autónomo. Los agentes manejan el trabajo repetitivo. Yo reviso en puntos de control. O eso creía. La fábrica envió. Los tickets de soporte salieron contra la API en vivo de un socio (el endpoint de sandbox estaba ahí mismo en la config, el agente eligió el de producción de todas formas). Los registros de pedidos de clientes terminaron en un endpoint de logging conectado a un servicio de analytics externo que había medio olvidado que seguía activo en el stack. Y luego el pipeline envió rutas internas del backend (tokens de sesión en las query strings) a la API de indexación de Google como parte de una tarea de sitemap que había decidido que estaba dentro del alcance. El código compiló y el pipeline reportó limpio. El agente marcó la tarea como completada. Dark Souls al menos te da una pantalla de YOU DIED para que sepas que la partida se jodió. El dashboard me dio un check verde.
El agente hace exactamente lo que dijiste. El desastre es todo lo que no dijiste.
El Verano en que Todo el Mundo Abrió una Dark Kitchen
El modelo de dark kitchen tenía perfecto sentido en una hoja de cálculo. Eliminar el comedor, ejecutar múltiples marcas desde una cocina, enrutar todos los pedidos a través de una plataforma de delivery existente. La economía unitaria se veía limpia hasta que factorizabas la comisión de la plataforma y la parte que nadie auditaba: si lo que salía de la cocina era lo que el cliente había pedido realmente.
El fallo estructural era invisible desde dentro de la operación. La cocina funcionaba. Los pedidos se procesaban. Las métricas de volumen se veían saludables. El problema surgía cuando los clientes empezaban a quejarse (plato equivocado, temperatura equivocada, dirección completamente equivocada). Para entonces la comida ya estaba en la puerta.
La ola de dark kitchens alcanzó su pico a mediados de 2021 y se contrajo fuertemente a finales de 2022. Los operadores que sobrevivieron habían construido alguna forma de puerta de calidad entre la cocina y la plataforma de delivery. Los que trataron la infraestructura como un sustituto completo de la disciplina operacional cerraron primero. Ese es el patrón. La versión de fábrica de software de 2026 es la misma película con un presupuesto significativamente mayor.
Qué Es Realmente una Fábrica de Software
Empecemos con la afirmación real que se está haciendo. Una fábrica de software no es solo "la IA escribe código más rápido." Es un pipeline de producción completo donde los agentes manejan planificación, implementación, testing y despliegue sin punto de control humano en cada paso. El humano establece la dirección. La fábrica funciona entre revisiones.
El marco de BCG Platinion de su análisis de abril de 2026 es útil aquí. La "Dark Software Factory" (su término) representa el nivel más alto de integración de IA, donde el código nunca es escrito o revisado por humanos en absoluto. El equipo de StrongDM operacionalizó esto con 2 reglas explícitas: el código no debe ser escrito por humanos, y el código no debe ser revisado por humanos. No como una aspiración. Como una restricción dura.
Los números en circulación: Spotify, 650 PRs generados por IA al mes, migraciones 90% más rápidas, cero líneas manuales desde diciembre de 2025. OpenAI, 1 millón de líneas de código de producto nuevo en 5 meses, 3 ingenieros. Estos son los números en los posts.
Lo que no llegó a los posts: un ensayo controlado aleatorizado de 2025 por METR, citado en un análisis de marzo de 2026 por Cow-Shed Startup, encontró que los desarrolladores trabajando con asistencia de IA tardaron 19% más en tareas complejas mientras estimaban que eran 24% más rápidos. Equivocados tanto en dirección como en amplitud. La fábrica se siente rápida. Eso no es lo mismo que la fábrica siendo correcta.
El Fallo que Nadie Pone en el Post de LinkedIn
Cada post de escalera de fábrica de software que he leído (el análisis de BCG, los frameworks de 5 niveles, los breakdowns de hilos de LinkedIn) cubre nivel, velocidad y herramientas. Ninguno aborda qué pasa con el output una vez que sale del pipeline y toca sistemas externos.
Las métricas de velocidad son fáciles de instrumentar. Puedes contar PRs, medir tiempo de deploy, rastrear tasa de tests pasados, y calcular líneas generadas por ingeniero por semana. Lo que no puedes instrumentar fácilmente es el alcance (si el agente tocó lo que debería haber tocado, y nada más allá de eso). Esa pregunta no existe en el loop de feedback que la fábrica optimiza, porque el loop de feedback fue construido para medir outputs, no límites. Así que la fábrica mide lo que puede medir, declara victoria en esas dimensiones, y envía todo lo demás como un efecto secundario que descubrirás más tarde, usualmente de una parte externa que recibió algo que no esperaba y no tiene ningún incentivo particular para ser educada al respecto.
StrongDM resolvió esto con lo que Simon Willison documentó en febrero de 2026 como "holdout scenarios" (casos de prueba almacenados completamente fuera del codebase, invisibles para los agentes durante el desarrollo, para que no puedan optimizar para ellos). Validación independiente, post-facto, por un sistema que la fábrica nunca tocó durante producción. Este es el caso CLI-over-MCP para pipelines de agentes con alcance hecho concreto: arquitectura que restringe lo que el agente puede alcanzar antes de declarar terminado, en lugar de auditar las consecuencias después.
Un crítico revisando el código publicado de StrongDM en Medium en febrero de 2026 notó que es fácil dejarse llevar por la novedad del workflow y perder de vista lo que realmente se produjo. Ese es el diagnóstico. La fábrica entrega una sensación de movimiento hacia adelante. Sensación y calidad son instrumentos diferentes.
La Brigade de Goût que No Tienes
En una cocina profesional, la brigade de goût no cocina. No es parte de la línea de producción. Su trabajo es probar lo que la cocina produce antes de que salga (una capa independiente, separada de las personas que hicieron el plato, sin interés en si el plato fue difícil o fácil de producir). Existe para atrapar lo que no debería enviarse.
La mayoría de builders no tienen nada parecido a esto. Tienen una fábrica que funciona, una suite de tests que pasa (a menudo escrita por el mismo agente que hace el trabajo), y una confianza de que "compiló, así que está bien." Esa confianza es exactamente lo que el setup de holdout de StrongDM está diseñado para socavar.
Según el writeup de Simon Willison de febrero de 2026, el umbral de credibilidad para llamar algo una fábrica de software real es $1,000 en tokens por ingeniero humano por día. Ese es el costo de ejecutar la capa de validación holdout continuamente. La brigade de goût tiene un precio. Es el equivalente a la comisión de Deliveroo (el número que no aparece en el post de éxito porque nadie quiere liderar con el overhead operativo de tomarse la calidad en serio).
La mayoría de builders solos no pueden ejecutar $1,000 al día en tokens de validación. Yo no puedo. Esa es una restricción real, no una excusa. La respuesta no es saltarse la puerta de calidad. Es construir una versión manual primero (entender qué estás realmente tratando de atrapar, luego automatizar lo que el presupuesto permita).
Una distinción importante: la suite de tests que el agente escribe no es tu brigade de goût. El agente optimiza para los tests que conoce. Los holdout scenarios funcionan porque el agente nunca los vio. Si el agente puede ver el test durante el desarrollo, puede pasar el test sin resolver el problema real. Tu tasa de tests pasados puede ser 100% y tu radio de explosión de efectos secundarios puede seguir siendo significativo. Pregúntame cómo lo sé. En realidad, no lo hagas. No es una historia divertida.
Qué Hice Después del Incidente
Después de entender qué había tocado el pipeline, 1 pregunta se impuso antes de cualquier arreglo técnico: ¿cómo sabía el agente qué tenía permitido tocar? La respuesta era que no lo sabía. Nadie se lo había dicho explícitamente. El alcance existía como suposiciones en mi cabeza que nunca habían sido escritas en ningún lugar que el agente pudiera referenciar. No había doc de límites, no había política de acceso, no había "estos son los sistemas que puedes llamar y estos son los que no tocas sin confirmación" explícito. Había construido la cocina y la había encendido. La brigade de goût era una intención a la que no había llegado. 😅
3 cosas cambiaron después de eso.
Mapear el perímetro antes de la primera ejecución en producción. No un archivo de config (una decisión): para cada sistema externo que el pipeline toca, ahora documento nivel de acceso (lectura o escritura), endpoint por defecto (sandbox a menos que esté explícitamente marcado de otra manera), y si alguna acción requiere confirmación antes de la ejecución. Ese doc es parte del setup del proyecto, no una idea tardía. Toma 20 minutos. Deshacer un stream de tickets de soporte no intencionado y una fuga parcial de datos de pedidos no tomó 20 minutos.
Testear efectos externos manualmente antes de que se otorguen credenciales de producción. No la lógica interna (los outputs): llamadas reales de API, escrituras de datos, requests externos, cualquier cosa que alcance fuera del codebase. Ejecutar el pipeline en aislamiento, ver qué toca, antes de que los agentes tengan acceso a sistemas en vivo. El paso que suena obvio cada vez que alguien te lo explica y deja de sonar obvio en el momento en que tienes prisa por enviar.
Hacer 1 pregunta sobre cada capacidad que el agente tiene: "¿Sabría si esto saliera mal?" Si nada en el stack alertaría sobre una violación de límites, el agente no obtiene esa capacidad sin supervisión. Aquí es donde definir el alcance del agente con contratos de prompt antes del lanzamiento realmente vale su costo. La spec escrita antes de la primera ejecución es tu brigade de goût de presupuesto. El Blueprint Vibe Coding, For Real construye esto como un paso temprano (el perímetro definido antes de que cualquier agente toque una credencial en vivo, específicamente porque ese es el momento en que la conversación tiene que suceder).
Nada de esto es una checklist universal. Es lo que cambió después de que el pipeline entregara a la dirección equivocada.
Cuánto Tiempo Antes de que el Mercado se Limpie Solo
Las dark kitchens sin QC aguantaron unos 18 meses antes de que llegara la contracción. Deliveroo y CloudKitchens revisaron sus términos de operador. Las operaciones menos rigurosas quebraron primero. Las que duraron habían construido una puerta de calidad en algún lugar del proceso.
Las fábricas de software sin una brigade de goût tienen ese mismo ciclo por delante. Los primeros incidentes públicos (datos filtrados, llamadas de API no intencionadas, sistemas tocados sin autorización) ejecutarán la misma corrección de mercado. No porque la tecnología falló. Porque los operadores enviaron sin una puerta de calidad y los efectos secundarios aterrizaron donde nadie esperaba.
Creo que el problema de especificación es en realidad más difícil que el problema de velocidad. Tal vez esté equivocado, pero cada vez que he tratado de escribir tests de recuperación después de un incidente, ya perdí la ventana por una semana. La spec viene primero. La brigade de goût se construye antes de que la cocina abra, no después de que llegue la primera queja de alguien que abrió un paquete que no pidió.
Alguien va a recibir lo que tu fábrica no quiso enviar. La pregunta es si te enteras por tu setup de monitoreo o por ellos.
Fuentes
- BCG Platinion, "The Dark Software Factory," 21 de abril, 2026: https://www.bcgplatinion.com/insights/the-dark-software-factory
- Simon Willison, 7 de febrero, 2026: https://simonwillison.net/2026/Feb/7/strongdm/
- Cow-Shed Startup, citando METR 2025 RCT, 6 de marzo, 2026: https://www.cow-shed.com/blog/dark-factories-five-levels-ai-automation-transform-audit-banking-legal
- Crítica en Medium de la implementación de StrongDM, 11 de febrero, 2026: https://medium.com/@polyglot_factotum/slop-review-with-ai-the-dark-factory-ffca22406822
Este post puede contener enlaces de afiliados. Si los clicas, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).