Comment j'écris des logiciels avec des LLMs : un flux de travail multi-modèles pratique
Le 10 mars 2026, Stavros a publié ce qui pourrait être le guide le plus honnête et pratique pour construire des logiciels avec des grands modèles de langage. Pas un article de promotion. Un flux de travail réel, testé sur plusieurs projets livrés.
Le point de départ : Faire des choses, pas programmer
Stavros fait une distinction qui recadre toute la conversation. Il ne se soucie pas de la programmation comme fin en soi. Il se soucie de faire des choses. Les LLMs ont changé l'équation en rapprochant la programmation de la construction directe.
Il a utilisé cette approche pour construire et maintenir plusieurs projets : un assistant personnel appelé Stavrobot, un dispositif de notes vocales, un projet d'horloge artistique et une simulation de petite ville appelée Pine Town.
L'architecture à trois modèles
1. Le modèle de planification (Architecte)
Le premier modèle agit comme architecte. Stavros passe jusqu'à 30 minutes en conversation avant d'écrire du code. L'instruction clé : ne commence pas l'implémentation tant que j'approuve explicitement le plan.
2. Le modèle de développement (Implémenteur)
Une fois le plan approuvé, un modèle moins cher gère l'implémentation. Ce modèle a une marge limitée — il exécute le plan, ne le redessine pas.
3. Les modèles de révision (Plusieurs reviewers)
Après l'implémentation, Stavros fait passer le code par plusieurs modèles de révision. Il utilise Codex, Gemini et Opus. La diversité compte — différents modèles détectent différents problèmes.
L'humain écrit les instructions de l'agent
Stavros écrit les instructions de l'agent à la main. Il ne demande pas à un LLM de générer son propre fichier de compétences. L'humain définit les contraintes ; les modèles exécutent dans ces limites.
Où ça fonctionne bien
Le flux de travail multi-modèles fonctionne mieux quand Stavros comprend déjà la stack technologique. Dans ce contexte, les LLMs fonctionnent comme un multiplicateur de productivité.
Où ça échoue
En terrain inconnu, le flux de travail fonctionne beaucoup moins bien. Les mauvaises décisions s'accumulent. La dette technique d'architectures mal comprises est la plus coûteuse à réparer.
Enseignements pratiques
Séparez planification et implémentation. Utilisez différents modèles pour différents rôles. Diversifiez vos reviewers. Écrivez vos propres instructions. Restez en terrain familier. Surveillez les erreurs cumulatives.