Cómo escribo software con LLMs: Un flujo de trabajo práctico multi-modelo

El 10 de marzo de 2026, Stavros publicó lo que podría ser la guía más honesta y práctica para construir software con modelos de lenguaje grandes. No es un artículo de hype. Es un flujo de trabajo real, probado en múltiples proyectos entregados.

El punto de partida: Hacer cosas, no programar

Stavros hace una distinción que reencuadra toda la conversación. No le importa la programación como fin en sí misma. Le importa hacer cosas. Los LLMs cambiaron la ecuación al acercar la programación a la construcción directa.

Ha usado este enfoque para construir y mantener varios proyectos: un asistente personal llamado Stavrobot, un dispositivo de notas de voz, un proyecto de reloj-artístico y una simulación de pueblo llamada Pine Town.

La arquitectura de tres modelos

1. El modelo de planificación (Arquitecto)

El primer modelo actúa como arquitecto. Stavros pasa hasta 30 minutos en conversación antes de escribir código. La instrucción clave: no empieces a implementar hasta que apruebe explícitamente el plan.

2. El modelo de desarrollo (Implementador)

Una vez aprobado el plan, un modelo más barato maneja la implementación. Este modelo tiene libertad limitada — ejecuta el plan, no lo rediseña.

3. Los modelos de revisión (Múltiples revisores)

Después de la implementación, Stavros pasa el código por múltiples modelos de revisor. Usa Codex, Gemini y Opus. La diversidad importa — diferentes modelos detectan diferentes problemas.

El humano escribe las instrucciones del agente

Stavros escribe las instrucciones del agente a mano. No permite que un LLM genere su propio archivo de habilidades. El humano define las restricciones; los modelos ejecutan dentro de ellas.

Dónde funciona bien

El flujo de trabajo multi-modelo funciona mejor cuando Stavros ya entiende el stack tecnológico. En ese contexto, los LLMs funcionan como un multiplicador de productividad.

Dónde falla

En territorio desconocido, el flujo de trabajo funciona mucho peor. Las malas decisiones se acumulan. La deuda técnica de arquitecturas mal entendidas es la más cara de reparar.

Conclusiones prácticas

Separe planificación de implementación. Use diferentes modelos para diferentes roles. Diversifique sus revisores. Escriba sus propias instrucciones. Manténgase en territorio familiar. Vigile los errores acumulados.