Por qué fracasan las fábricas de software: Cómo retomar el control

Esta es la segunda parte de Por qué fallan las fábricas de software

La versión en charla de esta publicación está disponible en YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M

Volviendo a encender las luces

En la parte 1, profundicé en por qué no se puede confiar en que los modelos mantengan la calidad del código base con el tiempo. Por qué ninguna cantidad de ingeniería de harness o tokenmaxxing resolverá un problema de entrenamiento de modelos y benchmarks. Por qué el "modelo como juez" para la calidad del código no funciona tan bien como algunos quieren hacerte creer.

Por ahora, el juez eres tú — así que vamos a devolver la revisión de código.

Vamos a adoptar lo mismo que hemos estado haciendo desde antes de la IA, que es hacer un poco de planificación por adelantado, para reducir las probabilidades de una revisión larga y difícil.

Vamos a encontrar apalancamiento, y vamos a usar IA para ayudar con esto, en 4 fases:

• Requisitos del producto
• Arquitectura del sistema
• Diseño del programa
• Slices verticales

Revisión del producto

Todo comienza con una revisión del producto: un documento corto que define qué estamos construyendo y por qué. El objetivo es poder tomar dos frases o un largo audio de voz desordenado y convertirlo en algo semiestructurado.

Primero, nos alineamos en el problema a resolver — el dolor real del usuario, en los términos del usuario. Segundo, cómo se ve el éxito — qué podemos leer después de lanzar para decidir que valió la pena construir la cosa. Idealmente, esto es un resultado para el usuario como "puede hacer el flujo de trabajo XYZ en menos tiempo" o "alcanza el hito de incorporación ABC más temprano". A veces es de nivel más bajo como una tasa de error o un número de latencia, a veces solo "los tickets de soporte sobre X se detienen".

Tratamos de mantener esto bastante anclado en el espacio del producto, no en el técnico. Como alguien que vive con un pie en el mundo del producto y otro en el de la tecnología, a menudo me encuentro derivando hacia los detalles técnicos aquí. Cuando eso sucede, trato de anotarlo para fases posteriores y volver a lo que el usuario realmente experimenta. Si las decisiones técnicas bloquean las decisiones del producto, entonces comprometemos lo que tenemos y entramos en la arquitectura o hacemos más investigación de prototipos sobre lo que es factible

Y como la mayor parte de esto trata sobre lo que el usuario ve, no lo describo — hago un mockup. Un mockup HTML burdo de la pantalla real resuelve una discusión que tres párrafos solo prolongarían.

Aquí hay uno real en progreso — el documento define la funcionalidad con un esquema JSON, luego dos mockups HTML burdos de las pantallas reales:

https://x.com/dexhorthy/status/2078592010852982977

Por supuesto, no todo recibe una revisión del producto. Un ajuste de copia, un script único, un error con una reproducción obvia — todavía los enviamos directamente al agente. Esto es para los cambios donde un malentendido del agente sobre nuestra intención es costoso.

Para este y todos los documentos de la serie, hacemos revisiones con opt-in del autor. Si quieres ahorrar tiempo durante la revisión, eliges a la persona que revisaría el PR y repasas las especificaciones del producto/técnicas con ella, ya sea de forma asíncrona mediante comentarios en el documento (nosotros usamos humanlayer para esto, pero puedes hacerlo igualmente en GitHub/Notion/Plannotator/etc).

Arquitectura del sistema

Una vez que la revisión del producto está resuelta, hacemos la arquitectura del sistema. Esto no es particularmente novedoso y es algo que incluso los codificadores de vibraciones están empezando a adoptar.

Si quieres ahorrar tiempo durante la revisión, eliges a la persona que revisaría el PR y repasas las especificaciones del producto/técnicas con ella antes de llegar a la parte de codificación.

En esta fase nos alineamos en cómo los servicios, endpoints, esquemas, colas y almacenes se comunican entre sí, sin entrar en los detalles del diseño del programa. Para maximizar el ancho de banda de comunicación humano<>agente, hacemos un uso intensivo de visualizaciones aquí — por ejemplo, diagramas de secuencia:

Formas de contratos / endpoints:

Modelos de datos y transformaciones:

Mermaid está bien aquí, pero a veces puede ser excesivo y a veces puede tentarte a una falsa sensación de que estás alineado. La arquitectura tiene bastante apalancamiento y hay muchos tics de modelo potencialmente malos que puedes evitar durante esta fase. Pero es insuficiente para producir código de alta calidad. Para eso necesitamos el diseño del programa.

Diseño del programa

Después de la arquitectura hacemos algo que creo que está criminalmente subestimado en la codificación agentiva: diseño del programa.

La mayoría de la gente asume que una vez que la arquitectura es correcta, el modelo puede simplemente cocinar. Puedes hacer esto, pero puede que no te guste lo que obtienes.

Pero lo que veo que funciona bien es que antes de que alguien (humano o agente) escriba la implementación, bajamos un nivel desde la arquitectura hacia la forma del código: los tipos, las firmas de métodos, la disposición del programa y las pilas de llamadas.

La primera versión de nuestra habilidad de diseño de programa apestaba. Era difícil de leer, era agotadora. Probamos Mermaid, que tiene su lugar, pero lo que realmente amamos son visualizaciones ligeras en pseudocódigo:

Árboles de pila de llamadas, para cualquier cambio de orquestación o flujo de control. Usa sintaxis de diff cuando la parte interesante es lo que está cambiando:

Dillon Mulroy habla sobre el uso de grafos de llamadas como parte de su proceso de planificación, y creo que eso es exactamente correcto.

Diffs de árbol de archivos — para que puedas mantenerte en contacto con la disposición de tu base de código y dónde viven las cosas

Tipos y firmas de métodos para las nuevas funciones clave — lo que es demasiado interno para un documento de arquitectura pero que un agente podría equivocarse

Ninguno de estos toma mucho tiempo para producir (el modelo los redacta, tú discutes con él), y cada uno de ellos es una decisión que de otro modo estarías tomando implícitamente durante la revisión de código — en el momento más caro posible para cambiar de opinión.

Slices verticales

A continuación, nos encanta hacer lo que llamo "slices verticales" — Matt Pocock y yo tuvimos una

charla sobre slices verticales o "balas trazadoras" en un stream en vivo en enero de 2026 — esto también se conoce como balas trazadoras

A los modelos les encanta lo que llamo "planes horizontales" — hacer las cosas en orden de pila:

1. Migraciones de base de datos
2. Capa de servicios
3. API
4. Frontend

En la práctica, esto significa que no hay una forma real de "tocar" la solución mientras avanzas. Puedes probar cosas con código, pero para casi cualquier funcionalidad que haya construido, leer las pruebas era un comienzo, pero levantar algo en un navegador, o probarlo con curl mientras trabajaba siempre fue una parte frecuente del flujo de trabajo.

Antes de la IA, era raro que alguien escribiera más de 2000 líneas de código o incluso 500 líneas de código sin verificar algo en el camino.

Me tomó un tiempo notar la diferencia con lo que estaba acostumbrado — cuando escribía código antes de la IA, siempre comenzaba en el medio y trabajaba hacia afuera. Vagamente:

1. Crear el contrato de API y servir datos mock, probar con curl
2. Crear frontend para consumir datos mock, iterar y pulir en el navegador
3. Conectar la API a la capa de servicios (los servicios sirven datos/comportamiento mock)
4. Agregar migraciones de base de datos, conectar servicios a la base de datos
5. Agregar un montón de lógica de negocio
6. Agregar un montón de manejo de errores

Y estaría probando/iterando/puliendo en cada paso.

Si me importa mucho el código o soy escéptico sobre la capacidad del modelo para hacer un buen trabajo en esta parte de la base de código, también reviso el código en cada paso. Revisar 100-200 líneas y reorientar es mucho más barato

aquí, lo haría. La mayoría de los modelos frontera no diseñarán un plan como este sin dirección humana, y es difícil generalizar por base de código o incluso por tarea, así que prefiero mantenerme en el ciclo aquí. Créeme. Si pudiera externalizar el pensamiento

30 minutos de planificación ahorran horas de revisión

Y así tenemos algunos pasos que argumentaría que los humanos deben estar en el ciclo, si quieres mantener un nivel de calidad cercano al humano sin esclavizarte sobre montañas de código basura tratando de limpiarlo después. (es decir, si realmente quieres ir rápido)

1. Diseño del producto
2. Arquitectura del sistema
3. Diseño del programa
4. Slices verticales

Obviamente no hacemos todo este proceso para todo lo que lanzamos (ver la misión secundaria abajo). Supongo que la distribución es aproximadamente:

• ~40% de las tareas se envían de una sola vez o con 1-2 rondas de retroalimentación ligera
• para tareas medianas, hacemos el diseño del producto/sistema todo en un documento de plan, y no nos molestamos en dividir el trabajo en fases
• para cosas grandes, hacemos todos los pasos. Omitimos la parte del producto para cosas donde no tiene sentido, como grandes refactorizaciones.

Y en la mayoría de los casos, enviaré a un modelo a hacer 1-3 slices a la vez, y revisaré el código sobre la marcha. Es mucho más fácil reorientar temprano, ya sea en los aspectos internos o en la funcionalidad real, que terminar al otro lado de más de 2k líneas de código sin idea de qué está roto.

Probablemente sientes que tienes demasiadas solicitudes de extracción

No tienes demasiados PRs. Tienes demasiados PRs malos.

Todos hemos revisado muchos PRs que necesitaban reelaboración, mucho antes de la IA.

Pero un gran PR es un placer de revisar. Estás desplazándote por cada archivo, el código es limpio, sigue todas tus decisiones/discusiones/opiniones ganadas con esfuerzo sobre cómo debería ser el software.

Por otro lado, si una solicitud de extracción necesita incluso un 20% de reelaboración (y eso es generoso, diría que la mayoría de los PRs de una sola vez de IA tienden a acercarse al 50%), eso es tanto una carga intelectual como una carga emocional tanto para el remitente como para el revisor. (Incluso si el remitente es una IA, alguien probablemente inició este trabajo o pulió el resultado de la IA o, como mínimo, se preocupa por el resultado).

Para ahorrarte tiempo (casi estamos al final), divagué más sobre esto en una misión secundaria:

"a dónde va el tiempo"

Una teoría de las restricciones (edición 2026)

Es fácil sentirse un poco decepcionado por la tesis central aquí: "por ahora estamos atrapados leyendo el código".

Estaba bastante emocionado por un mundo donde pudiéramos simplemente pedir cosas y dejar que los modelos cocinen y no leer el código y obtener software de producción hermoso que evolucione con el tiempo y no se vaya al carajo.

Pero lo que he hecho todo lo posible por exponer aquí no son más que restricciones. Los modelos son buenos en algunas cosas, no tan buenos en otras. ¿Cómo optimizas tu proceso a la luz de esas restricciones?

Los modelos son buenos en algunas cosas, no tan buenos en otras. ¿Cómo optimizas tu proceso a la luz de esas restricciones?

Es posible que estés demasiado ocupado tratando de moverte 10-100 veces más rápido y tratando de convencerte de que la calidad del código ya no importa, cuando podrías aceptar las restricciones y moverte 2-3 veces más rápido, de manera segura.

Mi tipo de consejo final aquí es básicamente:

1. Aprende bien las restricciones, desarrolla intuición trabajando mucho con modelos
2. Optimiza los sistemas dentro del ámbito de estas restricciones
3. Busca apalancamiento
4. Lee el maldito código

Eso es todo. Si quieres quedarte para el discurso de venta, sigue desplazándote, supongo. Espero que esto te ayude a evitar el desastre o al menos que te hayas divertido viendo algunas animaciones lindas.

Gracias por leer

-dex

PD Estamos obsesionados con esto

Estamos construyendo humanlayer.com, un IDE agentivo y plataforma de colaboración para ayudarte a moverte 2-3 veces más rápido mientras mantienes un nivel de calidad de código humano (o bastante cercano al humano).

Estamos construyendo hacia dos ideas: "bloques de construcción para tu fábrica de software" y "mejores verificadores para la mantenibilidad del software" (quizás incluso mejores modelos).

HumanLayer es gratuito para equipos pequeños de hasta 3 personas, y si quieres ayuda para comenzar, puedes venir a nuestro discord o enviarnos un mensaje a founders@humanlayer.dev

Un rápido agradecimiento a @calvinfo por la inspiración, a mi cofundador @0xBlacklight, a @swyx y al equipo de @aiDotEngineer por darme un espacio para explorar estas ideas, y a todos nuestros increíbles clientes, inversores, amigos y familiares que nos animan.

Si quieres aprender más, básicamente no me callo sobre esto, así que puedes encontrar todos los enlaces de esta publicación, así como algunas otras proyecciones del material en podcasts, pizarra de formato largo, etc., a continuación.

PPS Otros recursos

Podcasts y artículos:

• Dex y Gergely hablan sobre ingeniería de contexto y fábricas de software en The Pragmatic Engineer - Julio 2026
• Dex y Matt Pocock hablan sobre consejos de codificación con IA atemporales (y bucles ralph) - Enero 2026

Episodios de AI That Works:

• Los benchmarks no prueban nada
• Especificaciones de producto para codificación con IA
• Pruebas de aprendizaje para mejor contrapresión
• Aplicando principios de agentes de 12 factores a la codificación con IA

Enlaces de esta publicación:

• Why Software Factories Fail keynote — AI Engineer World's Fair 2026
• StrongDM's lights-off software factory
• OpenAI: Harness Engineering (Feb 2026)
• Ryan Lopopolo on Symphony (talk, Apr 2026)
• Mario at AI Engineer Europe: "Building pi in a world of slop"
• FT: Amazon outages from coding-agent mishaps
• Matt Pocock: codebases falling apart
• Faros AI: the AI acceleration whiplash report
• Advanced Context Engineering for Coding Agents (talk 8/25)
• No Vibes Allowed (talk 11/25)
• Everything We Got Wrong About RPI (talk 3/26)
• Awesome-RLVR - Reinforcement Learning resources
• Advanced Context Engineering for Coding Agents (write-up)
• 12-Factor Agents
• Addy Osmani on vibe-coding vs. maintenance
• NATO Software Engineering Conference, 1968
• DoD DevSecOps Reference Design (PDF)
• Ramp's coding-agent platform
• Stripe: Minions, one-shot end-to-end coding agents
• WorkOS: Project Horizon
• Brex (Latent Space)
• Dan Shapiro: the five levels to the software factory
• Simon Willison on StrongDM's software factory
• "Boil the ocean"
• Shotgun surgery (refactoring.guru)
• John Ousterhout — A Philosophy of Software Design
• Robert C. Martin — Clean Code
• Martin Fowler — Refactoring
• aider
• cline
• codebuff
• SWE-Agent paper (2024)
• OpenAI Codex talk (Nov)
• Calvin French-Owen — AI Council talk
• SWE-bench Multilingual (dataset)
• AIE Worlds Fair 2026 - The Great Loops Debate ("the hype is outrunning the discipline")
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutation testing (Wikipedia)
• Dillon Mulroy on call graphs in planning
• Dex × Matt Pocock: vertical slices / tracer bullets (livestream, Jan 2026)
• "The hard work of thinking can't be outsourced" (Jake Nations)