Por qué los LLMs están redefiniendo cómo se escribe software
Durante años, hablar de inteligencia artificial aplicada al desarrollo de software se limitaba a autocompletado de código o snippets básicos. En 2026, la conversación ha cambiado radicalmente. Stavros Korokithakis, ingeniero y autor del blog Stavros’ Stuff, publicó una de las guías más detalladas y honestas sobre cómo usa LLMs (Large Language Models) para escribir software real: no como asistente de línea, sino como sistema multi-agente que planifica, implementa y revisa código de forma coordinada.
Si eres founder o CTO de una startup y todavía estás usando IA de forma esporádica para programar, este flujo de trabajo puede cambiar tu perspectiva por completo.
El núcleo del método: arquitectura multi-agente
El método de Stavros no es un simple «pídele al modelo que te escriba código». Es un sistema con roles bien definidos, inspirado en cómo funcionan los equipos de desarrollo humanos:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad1. El Arquitecto
El primer agente en el flujo es el Arquitecto. Este rol utiliza el modelo más potente disponible (en el caso del autor, variantes de Claude) y su función es exclusivamente planificar. Antes de escribir una sola línea de código, el founder o desarrollador dialoga con el Arquitecto durante hasta 30 minutos, iterando sobre:
- Objetivos concretos del feature o fix
- Limitaciones técnicas del sistema existente
- Tradeoffs entre distintos enfoques
- Preguntas de clarificación que el propio modelo plantea
El resultado es un plan de bajo nivel que detalla exactamente qué archivos modificar, qué funciones crear o editar, y qué lógica aplicar. Este plan no deja margen de interpretación al siguiente agente.
Nota clave del autor: antes de que el Arquitecto empiece a implementar (algunos modelos lo hacen por eagerness), el usuario debe decir explícitamente «aprobado». Sin esa palabra, el modelo no avanza.
2. El Desarrollador
Una vez aprobado el plan, entra el Desarrollador: un modelo más liviano y eficiente en tokens (el autor usa Sonnet 4.6 para esta fase). Su única tarea es implementar el plan al pie de la letra, sin tomar decisiones de alto nivel. No razona sobre arquitectura, no propone alternativas: ejecuta.
Esta separación es brillante porque reduce drásticamente los errores acumulativos que ocurren cuando un solo modelo intenta planificar e implementar al mismo tiempo, perdiendo coherencia a medida que el contexto crece.
3. Los Revisores
Dependiendo de la criticidad del proyecto, se despliegan entre 1 y 3 agentes revisores. Estos modelos auditan el output del Desarrollador buscando bugs, inconsistencias con el plan original, problemas de seguridad o deuda técnica. Cuanto más importante el proyecto, más revisores.
Un caso real: soporte de email en un asistente personal
Para ilustrar el flujo, Stavros describe la implementación de soporte para gestión de emails en su asistente personal Stavrobot. El proceso incluyó:
- Definir con el Arquitecto las reglas de filtrado y clasificación de correos
- Implementar listas blancas con patrones de coincidencia flexibles
- Ajustar la UX del asistente para que las respuestas automáticas fueran coherentes y no invasivas
- Iterar sobre los prompts del sistema para afinar comportamientos edge-case
Lo relevante aquí no es solo el resultado, sino el proceso: el autor no programó casi nada manualmente. Describió el problema, aprobó el plan, revisó el output. El modelo hizo el trabajo pesado.
Por qué este enfoque supera al uso casual de LLMs
La mayoría de equipos de startups usa IA de forma reactiva: pegan un error en ChatGPT o le piden a Copilot que complete una función. El método de Stavros es proactivo y estructurado, y tiene ventajas claras:
| Uso casual de LLMs | Flujo multi-agente estructurado |
|---|---|
| Contexto fragmentado por sesión | Plan completo antes de ejecutar |
| El modelo decide sobre la marcha | Roles separados: planificación vs. ejecución |
| Errores acumulativos sin revisión | Revisores especializados por criticidad |
| Difícil de auditar o corregir | Plan documentado como artefacto |
El insight más profundo: no te gusta programar, te gusta crear
Una de las reflexiones más honestas del artículo es personal: Stavros admite que lo que creía que era amor por la programación, en realidad era amor por crear cosas. Los LLMs le quitaron el peso del código repetitivo y le devolvieron la parte que realmente le importaba: diseñar, decidir, construir.
Para muchos founders de startups tecnológicas, esto resuena profundamente. El código es un medio, no un fin. Y si los LLMs pueden encargarse del medio con suficiente calidad y supervisión, el founder puede enfocarse en product, estrategia y usuarios.
Lecciones accionables para founders que quieren implementar esto hoy
- Invierte tiempo en el Arquitecto, no en el código. La calidad del plan determina la calidad del output. 30 minutos de diálogo con el modelo ahorran horas de debugging.
- Usa modelos distintos para planificar y ejecutar. Un modelo potente para diseño arquitectónico, uno más eficiente (y económico) para la implementación.
- Obliga al modelo a pausar antes de ejecutar. Implementa un checkpoint explícito («aprobado») para evitar que el modelo empiece a escribir código antes de que hayas validado el plan.
- Escala los revisores según el riesgo. No es lo mismo un script interno que un módulo de pagos. Ajusta la cantidad de revisores en consecuencia.
- Documenta el plan como artefacto. El archivo de plan generado por el Arquitecto es un activo técnico: puedes versionarlo, compartirlo con el equipo y usarlo para onboarding.
- Mantén comprensión de la arquitectura. El autor es enfático: si no entiendes lo que el modelo está haciendo, los errores se acumulan silenciosamente. El founder/CTO debe seguir siendo el dueño del sistema.
El contexto más amplio: hacia dónde va el desarrollo asistido por IA en 2026
El flujo descrito por Stavros no es un experimento aislado. En 2026, los equipos de ingeniería más avanzados operan con agentes paralelos que manejan entre 2 y 6 proyectos simultáneamente, con humanos enfocados en gestión de alcance y feedback de calidad. Herramientas como Cursor, Aider y Claude Code han normalizado los flujos agenticos en editores de código.
La discusión en Hacker News alrededor de artículos similares confirma una tendencia: los ingenieros que más productividad obtienen de los LLMs son los que estructuran el diálogo, no los que simplemente hacen copy-paste de errores. El modelo necesita contexto, restricciones y validaciones humanas para producir código de calidad producción.
Conclusión
El flujo de trabajo de Stavros Korokithakis es uno de los ejemplos más completos y aplicables de desarrollo de software con LLMs publicados hasta la fecha. La separación de roles (Arquitecto, Desarrollador, Revisores), la exigencia de un plan detallado antes de ejecutar, y la supervisión activa del founder como dueño del sistema, son principios que cualquier startup tecnológica puede adoptar hoy.
No se trata de reemplazar al equipo de ingeniería. Se trata de multiplicar su capacidad, reducir fricción en las partes menos creativas del trabajo, y liberar tiempo para lo que realmente importa: construir productos que resuelvan problemas reales.
Si tu startup todavía no tiene un flujo estructurado para usar LLMs en desarrollo, este artículo es el punto de partida ideal. Lee el original, experimenta con el método, y adapta los roles a tu stack y contexto.
Descubre como otros founders implementan estas soluciones en su stack tecnologico. Unete gratis a la comunidad de Ecosistema Startup.
Fuentes
- https://www.stavros.io/posts/how-i-write-software-with-llms/ (fuente original)
- https://news.ycombinator.com/item?id=46488576 (discusion en Hacker News sobre desarrollo asistido por LLMs)
- https://www.stavros.io (blog del autor)
