Esta es la segunda parte de Por qué fallan las fábricas de software
La versión en charla de este artículo 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 los modelos para mantener la calidad del código a lo largo del tiempo. Por qué ninguna cantidad de ingeniería de arnés o de 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 volver a poner la revisión de código en el centro.
Vamos a abrazar 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 palancas, y vamos a usar la IA para ayudarnos con esto, a lo largo de 4 fases:
- Requisitos del producto
- Arquitectura del sistema
- Diseño del programa
- Rebanadas 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 una nota de voz larga y convertirla en algo semiestructurado.
Primero, nos alineamos en el problema a resolver — el dolor real del usuario, en sus propios términos. Segundo, cómo se ve el éxito — qué podemos leer después del lanzamiento para decidir que valió la pena construirlo. Idealmente, esto es un resultado para el usuario como "puede hacer el flujo de trabajo XYZ en menos tiempo" o "alcanza el hito de onboarding ABC antes". A veces es algo más bajo nivel como una tasa de error o un número de latencia, otras veces solo "dejan de llegar los tickets de soporte sobre X".
Intentamos 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 la tecnología, a menudo me encuentro derivando hacia los detalles técnicos aquí. Cuando eso sucede, intento anotarlo para fases posteriores y volver a lo que el usuario realmente experimenta. Si las decisiones técnicas están bloqueando las decisiones de producto, entonces comprometemos lo que tenemos y pasamos a 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 — lo maqueto. Un maqueta HTML aproximada de la pantalla real zanja una discusión que tres párrafos solo alargarían.
Aquí hay un ejemplo real en progreso: el documento define la función con un esquema JSON, luego dos maquetas HTML aproximadas de las pantallas reales:
https://x.com/dexhorthy/status/2078592010852982977
Por supuesto, no todo recibe una revisión de producto. Un ajuste de copia, un script único, un bug con una reproducción obvia — todavía los enviamos directamente al agente de una sola vez. 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 opción de participación del autor. Si quieres ahorrar tiempo durante la revisión, eliges a la persona que revisaría el PR, y repasas las especificaciones de producto/técnicas con ellos, 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 programadores por vibra 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 de producto/técnicas con ellos 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 llevarte a una falsa sensación de que estás alineado. La arquitectura tiene bastante palanca y hay muchos posibles tics de modelo 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 esto que creo que está criminalmente subestimado en la codificación agéntica: el diseño del programa.
La mayoría de la gente asume que una vez que la arquitectura está bien, el modelo puede simplemente cocinar. Puedes seguir adelante y hacer esto, pero puede que no te guste lo que recibes.
Pero lo que veo que funciona bien es que antes de que nadie (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 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 están 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 aún podría hacer mal
Ninguno de estos lleva mucho tiempo producirlos (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.
Rebanadas verticales
A continuación, nos encanta hacer lo que llamo "rebanadas verticales" — Matt Pocock y yo tuvimos una
charla sobre rebanadas verticales o "balas trazadoras" en un stream en vivo en enero de 2026 — también se conoce como balas trazadoras
A los modelos les encanta lo que llamo "planes horizontales": hacer las cosas en orden de pila:
- Migraciones de base de datos
- Capa de servicios
- API
- 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 función que haya construido, leer las pruebas era un comienzo, pero levantar algo en un navegador, o hacerle un 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 empezaba en el medio y trabajaba hacia afuera. Vagamente:
- Crear el contrato de API y servir datos simulados, probar con curl
- Crear el frontend para consumir datos simulados, iterar y pulir en el navegador
- Conectar la API a la capa de servicios (los servicios sirven datos/comportamiento simulados)
- Agregar migraciones de base de datos, conectar servicios a la base de datos
- Agregar un montón de lógica de negocio
- Agregar un montón de manejo de errores
Y probaba/iteraba/pulía 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 bucle aquí. Créeme. Si pudiera externalizar el pensamiento
30 minutos de planificación ahorran horas de revisión
Y así tenemos algunos pasos en los que argumentaría que los humanos deben estar en el bucle, si quieres mantener un nivel de calidad casi humano sin esclavizarte sobre montañas de código basura tratando de limpiarlo después. (es decir, si realmente quieres ir rápido)
- Diseño del producto
- Arquitectura del sistema
- Diseño del programa
- Rebanadas verticales
Obviamente no hacemos todo este proceso para cada cosa que lanzamos (ver la misión secundaria abajo). Supongo que la distribución es aproximadamente:
- ~40% de las tareas se hacen de una sola vez o de una sola vez con 1-2 rondas de retroalimentación ligera
- para tareas medianas, hacemos el diseño de producto/sistema todo en un solo documento de planificación, y no nos molestamos en dividir el trabajo en fases
- para cosas grandes, hacemos todos los pasos. Omitiremos la parte del producto para cosas donde no tiene sentido, como grandes refactorizaciones.
Y en la mayoría de los casos, envío un modelo para hacer de 1 a 3 rebanadas a la vez, y reviso 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 pull
No tienes demasiados PRs. Tienes demasiados PRs malos.
Todos hemos revisado muchos PRs que necesitaban retrabajo, desde mucho antes de la IA.
Pero un buen PR es un placer de revisar. Te desplazas por cada archivo, el código está 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 pull necesita incluso un 20% de retrabajo (y eso es generoso, diría que la mayoría de los PRs de una sola vez de IA tienden más hacia el 50%), eso es tanto una carga intelectual como una carga emocional tanto para el que envía como para el revisor. (Incluso si el que envía 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 (ya casi terminamos), divagué más sobre esto en una misión secundaria:
Una teoría de restricciones (edición 2026)
Es fácil sentirse un poco desanimado 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 cocinaran y no leer el código y obtener un hermoso software de producción que evoluciona con el tiempo y no se va 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:
- Aprende bien las restricciones, desarrolla intuición trabajando mucho con modelos
- Optimiza los sistemas dentro del ámbito de estas restricciones
- Busca palancas
- 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 agéntico 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 a 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 empezar, 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 escenario para explorar estas ideas, y a todos nuestros increíbles clientes, inversores, amigos y familiares que nos animan.
Si quieres saber más, básicamente no me callo sobre esto, así que puedes encontrar todos los enlaces de este artículo, así como algunas otras proyecciones del material en podcasts, pizarra larga, 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 atemporales de codificación con IA (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 una mejor contrapresión
- Aplicando principios de agentes de 12 factores a la codificación con IA
Enlaces de este artículo:
- Keynote de Por qué fallan las fábricas de software — AI Engineer World's Fair 2026
- Fábrica de software sin luces de StrongDM
- OpenAI: Ingeniería de arnés (Feb 2026)
- Ryan Lopopolo sobre Symphony (charla, Abr 2026)
- Mario en AI Engineer Europe: "Construyendo pi en un mundo de slop"
- FT: Cortes de Amazon por percances de agentes de codificación
- Matt Pocock: bases de código desmoronándose
- Faros AI: el informe de latigazo de aceleración de IA
- Ingeniería de contexto avanzada para agentes de codificación (charla 8/25)
- No se permiten vibraciones (charla 11/25)
- Todo lo que entendimos mal sobre RPI (charla 3/26)
- Awesome-RLVR - Recursos de aprendizaje por refuerzo
- Ingeniería de contexto avanzada para agentes de codificación (artículo)
- Agentes de 12 factores
- Addy Osmani sobre codificación por vibra vs. mantenimiento
- Conferencia de Ingeniería de Software de la OTAN, 1968
- Documento de diseño de referencia de DevSecOps del DoD (PDF)
- Plataforma de agentes de codificación de Ramp
- Stripe: Minions, agentes de codificación de extremo a extremo de una sola vez
- WorkOS: Project Horizon
- Brex (Latent Space)
- Dan Shapiro: los cinco niveles hacia la fábrica de software
- Simon Willison sobre la fábrica de software de StrongDM
- "Hervir el océano"
- Cirugía de escopeta (refactoring.guru)
- John Ousterhout — Una filosofía del diseño de software
- Robert C. Martin — Código limpio
- Martin Fowler — Refactorización
- aider
- cline
- codebuff
- Artículo de SWE-Agent (2024)
- Charla de OpenAI Codex (Nov)
- Charla de Calvin French-Owen en AI Council
- SWE-bench Multilingüe (dataset)
- AIE Worlds Fair 2026 - El gran debate de los bucles ("el hype está superando a la disciplina")
- SWE-Marathon (Abundant AI)
- DeepSWE (Datacurve)
- Frontier Code (Cognition)
- Pruebas de mutación (Wikipedia)
- Dillon Mulroy sobre grafos de llamadas en la planificación
- Dex × Matt Pocock: rebanadas verticales / balas trazadoras (livestream, Ene 2026)
- "El trabajo duro de pensar no se puede externalizar" (Jake Nations)
