- Usa varios agentes de IA (claude/o3/sonnet, etc.) para automatizar desde la generación de código hasta su validación dentro de un flujo de trabajo personal de “fábrica de IA”
- Cuando surge un problema, la clave es no corregir directamente el código generado (Output), sino mejorar las entradas (Input), como el plan, los prompts y la configuración de agentes, para elevar el nivel de automatización
- Al mejorar repetidamente las entradas de esta manera, los agentes siguen evolucionando y se maximiza la productividad en tareas repetitivas
- Distribución de roles entre agentes: planificación (o3/sonnet4), ejecución (sonnet3.7/4), validación (o3/sonnet4), etc., para implementar procesamiento en paralelo y un bucle automático de retroalimentación
- Incluso los errores de código o problemas de estilo se incorporan a la plantilla del plan para que mejoren desde la siguiente generación, de modo que la propia fábrica crece mediante la mejora iterativa de las entradas
Resumen de la fábrica de IA y principios clave
- Mantiene entornos de trabajo separados abriendo varias ventanas de claude code en distintos
git-worktree
- o3 y sonnet 4 se usan para la planificación, sonnet 3.7 o sonnet 4 para la ejecución, y o3 para la evaluación de resultados
- La planificación, ejecución y validación se distribuyen en paralelo entre agentes para ganar eficiencia
Principio central – “Mejorar la propia entrada (Input) en vez de corregir el resultado (Output)”**
- Si aparece un problema, en lugar de parchar directamente el código generado, se busca una mejora automatizada ajustando el plan, los prompts y la combinación de agentes
- El concepto es construir, como en el juego Factorio, una red de agentes de IA tipo fábrica que crece automáticamente
- Dentro de esta estructura, circula un bucle de planificación-codificación-validación-mejora, creando un entorno donde los agentes de IA producen, validan y mejoran código por sí mismos
Flujo de trabajo diario – Estructura de la fábrica
- La interfaz principal es claude code y, en local, se usan mcp, Goose (para conectar modelos de Azure OpenAI), o3 y otros recursos
Paso 1: Planificación (Planning)
- Se ingresa una tarea de alto nivel en claude code → o3 hace preguntas adicionales y genera un plan (
<task>-plan.md)
- El plan incluye la solicitud original y el plan de implementación
Paso 2: Ejecución (Execution)
- sonnet 4 revisa el plan y lo convierte en una lista de tareas
- claude code ejecuta el trabajo y usa sonnet 3.7 o 4 según la complejidad de la tarea
- claude deja un historial de commits en cada etapa del trabajo, por lo que es fácil hacer rollback si surge algún problema
Paso 3: Validación y retroalimentación (Verification → Feedback)
- sonnet 4 realiza una validación inicial del código generado con base en el plan
- Luego, o3 lo valida de forma más estricta comparándolo con el plan y los requisitos iniciales
- o3 señala con rigor el código innecesario (por ejemplo, flags para ignorar lint) o estructuras obsoletas
- Los problemas detectados en la validación no se reflejan mediante correcciones directas al código, sino mediante mejoras en la plantilla del plan
- Con
git worktree, se ejecutan varias instancias de claude code en paralelo, lo que permite múltiples tareas simultáneas
Por qué la “entrada” es más importante que la “salida”
- El resultado (Output) puede desecharse, pero el plan y los prompts (la entrada) son un activo acumulativo que sigue acumulándose y mejorando
- Si se depura en la parte de entrada (plan, prompts), esa mejora puede ampliarse a todos los trabajos futuros
- Esto transforma a los agentes de simples generadores en entidades que aprenden y colaboran por sí mismas
- Ejemplo: hacer que el código deje de cargar un CSV completo en memoria y pase a procesarlo en stream; después, ese patrón se incorpora al plan para todos los CSV y puede validarse automáticamente en el futuro
Escalado de la fábrica y colaboración entre agentes
- Con MCP, asigna agentes especializados a distintas tareas y los paraleliza
- Ejemplo: reunir todo el código Clojure y operar un agente dedicado exclusivamente a aplicar reglas de estilo locales, mientras claude corrige problemas de estilo surgidos en los ciclos de lint/test/debug
- Incluso en el código de bibliotecas internas, se refuerzan la productividad y la consistencia sustituyendo, por ejemplo, el uso antiguo de retry y
Thread/sleep por una biblioteca propia de retry
- Al construir varios agentes pequeños, es posible combinarlos por subtareas específicas y automatizar incluso flujos de trabajo complejos
- Ejemplo: a partir de una especificación de API y casos de negocio, una combinación de agentes puede encargarse automáticamente de la integración, pruebas y documentación
- La clave es seguir ajustando la entrada y repetir la ejecución; cuando hay fallos, bloqueos o falta de contexto, la retroalimentación se incorpora al siguiente intento para mejorar
- El código en sí es desechable; el activo real son las instrucciones (entrada) y la configuración de agentes
- Las lecciones de todos los problemas —fallos, bloqueos, falta de contexto, etc.— se reflejan en la siguiente entrada para completar el bucle de la fábrica
Siguientes pasos y dirección futura
- Busca reforzar la coordinación general entre agentes para rastrear todo el flujo de trabajo e introducir más automatización
- Quiere conectar mejor los documentos de negocio y la información de los agentes, y mejorar su aprovechamiento capturando sobre todo información de abstracción de alto nivel
- Pretende implementar flujos de trabajo cada vez más complejos y ampliar la colaboración e interacciones complejas entre agentes
- También está explorando formas de aprovechar al máximo las cuotas de tokens de varios proveedores y cambiar entre ellos con facilidad (especialmente para lidiar con los límites de tokens de bedrock sonnet 4)
Conclusión
- En la actualidad, la fábrica de IA ya tiene automatizada de forma cotidiana la generación y validación de código, hasta el punto de que puede desplegar código mientras uno se toma un café
- Aunque todavía no está en una etapa de automatización total, el principio de “mejorar la entrada en vez de corregir la salida” ya quedó establecido como la esencia de la fábrica
1 comentarios
Comentarios de Hacker News
Creo que este post será casi imposible de entender para quien no haya tenido ese momento de "ajá" con Claude Code
Si le quitas las restricciones de permisos con
claude --dangerously-skip-permissionsy le dejas un problema complejo, puedes ver a Claude resolverlo usando libremente varias herramientasHoy también le hice compilar, ejecutar y hasta depurar por su cuenta un generador de fractales de Mandelbrot hecho en ensamblador 486 usando Docker
Lo resolvió increíblemente bien
enlace al gist
Me parece que este es un ejemplo extremadamente fácil para este tipo de IDE o LLM
Hay bastante ensamblador en los datasets de entrenamiento, y lo mismo pasa con Docker
También he dejado que Cursor se mueva con total libertad por mi codebase
Espero que las herramientas actuales algún día realmente lleguen a eso, pero siento que todavía no estamos en ese punto
También quisiera recomendar este video de Dagger (y del fundador de Docker) presentado en la conferencia AI Engineer
Este video también puede ser algo difícil de seguir
Lo escribo por si acaso le sirve a alguien
Yo bajé de Claude max a pro, y por 20 dólares al mes el límite de uso me alcanza de sobra
Parece que están compitiendo con Gemini CLI, así que me alegra estar pagando menos ahora
Creo que casi cualquier LLM puede resolver este nivel de ejemplo o de contexto sin mucha dificultad
Yo he pasado por upgrades mucho más complejos de dependencias en Rust, repitiéndolos más de 30 veces, y procesándolos con código wasm personalizado
Claude va conectando varias herramientas como context7 o mcp-lsp y reuniendo los detalles
Pero si lo usas de forma continua, terminas topándote con sus límites, y cuando lo presionas con tareas más sofisticadas y difíciles, se le notan las debilidades
Sobre esa frase de que si le das un problema complejo con
claude --dangerously-skip-permissions, usa varias herramientas para resolverloYo he visto a Claude pasarse más de una hora intentando arreglar código de la forma equivocada
Al final tuve que intervenir yo mismo y decirle: "primero escribe pruebas unitarias y, cuando pasen, escribe el código y avísame de nuevo"
Claude Code es una herramienta realmente genial, pero la realidad es que hay que seguir repitiéndole el mapa básico de la arquitectura
Me parece difícil evaluar estas configuraciones sin saber cómo se usa realmente el código resultante
Si es una app de vibe coding para uso personal, es una historia muy fácil de creer,
pero me cuesta aceptar tan fácilmente que esté escribiendo código de alta calidad para entornos de producción complejos
Totalmente de acuerdo
Claude Code me acelera muchísimo la velocidad de programación, pero siempre reviso yo mismo cada cambio de código para asegurarme de que se esté construyendo el mejor sistema posible
En los pocos intentos donde simplemente lo dejé correr, terminó metiéndoles bugs a los usuarios
La verdad es que no termino de entender bien el flujo de trabajo ni el concepto que describe este post
Supongo que porque la explicación es algo vaga
Yo manejo a diario sistemas de producción complejos usando estructuras donde varios agentes conversan entre sí, agentes asíncronos, git work tree y cosas por el estilo
No es que nunca cambie la salida, pero si no obtengo el resultado que quiero, tiendo a tomarlo como una señal para mejorar mi flujo de trabajo
Yo también he estado probando un flujo de trabajo parecido, así que quisiera compartir mi experiencia
La codebase de Go con la que trabajo tiene cientos de miles de líneas y la usan en producción entre decenas y cientos de miles de usuarios B2C reales
Tenemos margen de rendimiento, pero estamos en finanzas, donde la precisión y la confiabilidad son extremadamente importantes
Como estoy en un entorno donde solo uso claves de OpenAI, solo utilizo una configuración básica con codex-cli y scripts simples para clonar repos, configurar agentes y ejecutar prompts
La instancia de codex me avisa por notificaciones del sistema cuando llega mi turno, y uso fzf para conectarme a la sesión de tmux cuando hace falta
Todavía no he usado MCP, pero está en mi lista de cosas por probar
Esta forma de trabajar ayuda muchísimo para tareas pequeñas y dispersas, y ahora estoy sacando muchos más PR chicos que antes
La metáfora de "cattle not pets" sigue aplicando: a las tareas pequeñas simplemente les lanzo prompts rápido para reducir la distracción
Para trabajos más grandes todavía no parece encajar muy bien, aunque quizá yo tampoco haya construido todavía un flywheel de contexto suficientemente bueno
Casi siempre leo y ajusto personalmente el código resultante antes de subirlo a revisión
También sigo haciendo casi todo el manejo de cambios de forma manual; ramas, commits y push los hago yo mismo
He probado algunas herramientas de automatización, pero todavía no he logrado pasarme por completo
Estoy 100% de acuerdo con la mentalidad de "arregla la entrada, no la salida"
Es un principio potentísimo incluso sin IA, y la industria lo está adoptando cada vez más
Con procesos no deterministas como los LLM no es tan fácil aplicarlo, y se siente más como práctica que como ciencia
Gracias por el buen post
Yo presento un flujo de trabajo parecido, aunque un poco más simple, en un texto llamado "Vibe Specs"
post relacionado estilo paper en blog
Yo uso esta regla sobre toda la codebase y hago que la IA actúe de dos maneras distintas
(1) que antes que nada haga preguntas
(2) que antes de programar cree un documento
spec.mdLa idea de fondo es parecida, pero yo me limito a un solo LLM
Creo que la mayoría estamos intentando esto de maneras parecidas
Como desarrollador independiente, experimento con distintas automatizaciones de producción desde una lógica centrada en la ingeniería
Para mí, el objetivo final es un esquema donde el agente obtenga confianza sobre el código a partir de pruebas e2e generadas automáticamente, independientemente de la implementación
Todavía no lo he conseguido por completo
Ahora Claude Code también soporta este tipo de flujo de forma nativa con “plan mode”
La verdad es que crear manualmente archivos
.mdse siente lento y tediosoLa idea base es que puedes seguir documentando qué comportamiento debe tener el sistema (tanto a alto nivel como en funcionalidades concretas), cómo vas a demostrar que funciona, e incluso cómo debe implementarse, incluyendo arquitectura y estilo de código
La razón para usar varios modelos es reducir sesgos y ampliar las opciones de ajuste fino según la tarea específica
Algún día quizá incluso sistemas complejos y grandes puedan rehacerse a partir de un conjunto de requisitos, y recién entonces el software realmente coincidirá con la especificación
En ese punto, el único "código legado" que quede serán documentos de especificación heredados
La idea es corregir la especificación, no el código generado
imagen de meme relacionada
Me pregunto qué están construyendo realmente
Cada vez que hablan de flujos de trabajo con IA, cuesta saber si están describiendo un flujo medio de ensueño o algo que de verdad usan productivamente
Si el LLM escribe todo el código, simplemente se me va el interés
De unos 50 proyectos, solo 2 los hice con LLM, y aun así los retocé yo mismo
Con los demás, solo tenía la idea de que "estaría bueno tener algo así", pero en realidad no me importaba tanto el resultado
Al final uno queda atrapado en un bucle peleándose con la computadora, metiendo documentos de diseño, prompts y datos de ejemplo cada vez que no sale el comportamiento esperado, mientras lidia con varios modelos y detalles de implementación
Es mucho más rápido y menos estresante usarlo solo para completar un poco de código
Cuando miro atrás, siento que gasté tiempo y dinero para terminar con software que apenas funciona
Si hay requisitos claros o una codebase existente, y yo llevo la batuta guiando el proceso, los agentes ayudan bastante, pero todo ese flujo de vibe coding, fuera de scripts pequeños o apps de nicho, no me resulta nada divertido ni me da la calidad que quiero
Además es demasiado caro y el código sigue siendo desordenado
Al final se siente como pasar el tiempo en una discusión interminable con la computadora
Para eso, mejor hacerlo yo mismo
El problema cuando varios agentes trabajan cada uno en su propio work tree es que cada agente propone ideas completamente distintas en cada detalle, así que la experiencia de usuario termina sin ninguna uniformidad
Por ejemplo, los agentes que construyen el dashboard de Documents y el dashboard de Design lo diseñan desde perspectivas totalmente diferentes
No hay consistencia ni en el diseño, ni en la estructura, ni en el esquema de base de datos, ni en el diseño de la API
Incluso con la misma entrada, la salida cambia
Al final, si empiezas a agregar más y más archivos de instrucciones para mantener consistencia, en proyectos grandes ya se vuelve normal tener miles de líneas y ni siquiera alcanza la ventana de contexto
En conclusión, creo que tiene más sentido usar un LLM pequeño entrenado solo con ciertas reglas y esquemas
Parece más correcto un LLM pequeño que un LLM grande al que intentas abarcarle un universo entero de ideas mediante prompts
Resultados totalmente distintos entre agentes, falta de consistencia en el diseño
Al final sí o sí hace falta alguien senior
Sea IA o sean humanos, uno termina teniendo que proporcionar personalmente el mínimo de estructura y flexibilidad para que las cosas avancen en la dirección deseada
Si no hay estructura, es mucho mejor programar directamente
Yo hice la primera versión por mi cuenta y luego, para lo siguiente, le decía a Claude Code "hazlo como este ejemplo", y así me fue mucho más fácil mantener la consistencia
¿Programación estilo ADHD, intentar generar un producto a lo loco y repetir hasta que encaje?
¿No sería mejor simplemente escribir uno mismo código que pueda expandirse a futuro?
Mi postura es que no hace falta aumentar la huella de carbono por gusto
El objetivo final es sacar al desarrollador de este proceso
Que el dueño del negocio pida una nueva app CRUD y se despliegue directo a producción
Claro, el resultado estará lleno de bugs, será lento y guardará datos en una base no autenticada, pero esa ya no sería mi responsabilidad
Y termina con una expresión intensa equivalente a beberse un té hirviendo de un trago
La programación cambió para siempre, y hay que aceptar ese cambio rápido
Decir “solo escribe el código” es como si todos insistieran en volver a arreglar carruajes con las manos
No es tan distinto de decir que, como los autos también se descomponen, entonces deberíamos aferrarnos a los métodos viejos
Me pregunto por qué siempre sale eso de “mejor escríbelo tú mismo como código expandible a futuro”
Los asistentes de código de hoy también pueden escribir código extensible y mantenible en zero-shot; me gustaría saber si realmente han intentado pedírselo
Los humanos también, al final, encuentran respuestas mediante prueba y error una y otra vez
La única diferencia es que, mientras más experiencia tienes, más puedes simular las cosas en tu cabeza
Y si el problema es la huella de carbono, entonces queda la pregunta de si sería aceptable cuando los centros de datos de IA funcionen con energía renovable
Creo que hay que encontrar formas de integrar la IA de manera más efectiva en el flujo de trabajo
Quienes la han adoptado activamente seguramente se han topado con preocupaciones parecidas, pero todavía no hay una solución clara
En esta etapa, me parece clave asignarle a la IA solo roles mínimos y bien definidos
Por ejemplo, en un flujo de trabajo de agentes para research bursátil, puedes crear dos IA, “Bullish Guy” y “Bearish Guy”, y hacer que debatan pros y contras sobre una misma acción
Si les haces investigar desde posturas opuestas, obtienes un análisis más integral y más profundo
La idea en realidad salió de ver cómo discute la gente en redes sociales
En el vibe-coding, siento que el resultado rara vez pasa de ser algo más que un discurso autorreferencial, y termina viéndose como el siguiente hobby caro después de la impresión 3D: una actividad infinita de fabricar juguetitos
Me pregunto si el equivalente al “benchy” en el vibe coding de hoy no será simplemente la app de tareas pendiente
Todos los que diseñan productos o hacen ingeniería la usan
La única razón por la que los consumidores comunes no la aprovechan es que ya pueden pedir por Amazon casi cualquier objeto de plástico que necesiten
Si las compras online no existieran, sería muchísimo más útil para una persona promedio
En adelante, probablemente será una tecnología realmente necesaria solo para quienes puedan diseñar por su cuenta archivos personalizados