Itérer progressivement
Le développement itératif avec l’IA
La tentation est grande de tout demander en un seul prompt. Mais avec grok-code-fast-1 comme avec tout modèle de code, l’approche itérative donne de meilleurs résultats. Vous construisez progressivement, en validant chaque étape avant de passer à la suivante.
Pourquoi itérer ?
Les limites du prompt unique
Un prompt qui demande de créer un système complet d’authentification avec JWT, refresh tokens, middleware, routes, tests et documentation va produire un résultat volumineux, difficile à vérifier, et probablement incomplet sur certains aspects.
L’avantage de l’itération
En découpant la même demande en étapes, vous :
- Vérifiez chaque étape avant de continuer — une erreur dans les fondations ne se propage pas
- Ajustez le cap en cours de route — si la première itération révèle un problème d’architecture, vous corrigez avant d’aller plus loin
- Gardez le modèle focalisé — un prompt court et ciblé produit de meilleures réponses qu’un prompt long et complexe
Stratégie d’itération
Étape 1 : La fondation
Commencez par la structure de base, sans les détails :
“Crée le schéma de la table users avec Drizzle ORM : id, email, passwordHash, createdAt. Ajoute les types TypeScript correspondants.”
Validez, testez, puis passez à la suite.
Étape 2 : La logique métier
Ajoutez la logique sur la fondation validée :
“Maintenant, crée le service d’inscription dans @src/services/auth.ts. Il doit hasher le mot de passe avec bcrypt, vérifier que l’email n’existe pas déjà, et insérer l’utilisateur. Utilise le schéma @src/db/schema.ts qu’on vient de créer.”
Étape 3 : Le raffinement
Une fois la logique en place, affinez :
“Ajoute la validation d’entrée avec Zod sur le service d’inscription. L’email doit être valide, le mot de passe doit avoir au moins 8 caractères avec une majuscule et un chiffre.”
Étape 4 : Les cas limites
Enfin, traitez les edge cases :
“Que se passe-t-il si la connexion à la base de données échoue pendant l’inscription ? Ajoute une gestion d’erreur appropriée avec des messages utilisateur clairs.”
Référencer les échecs précédents
L’itération inclut aussi l’apprentissage des erreurs. Si une suggestion du modèle ne fonctionne pas, dites-le explicitement :
“La solution précédente ne fonctionne pas parce que TypeORM ne supporte pas cette syntaxe dans la version 0.3. L’erreur est : [coller l’erreur]. Propose une alternative compatible.”
Le modèle utilise cette information pour éviter de reproduire la même erreur et pour mieux comprendre votre environnement.
Ajuster le contexte en cours de route
À chaque itération, vous pouvez affiner le contexte :
- Ajouter des fichiers que vous avez découverts en cours de développement
- Préciser des contraintes que vous n’aviez pas identifiées au départ
- Corriger des hypothèses initiales qui se sont révélées fausses
“En fait, le middleware d’authentification doit aussi gérer les clés API en plus des JWT. Voici le format de clé actuel dans @src/config/api-keys.ts.”
Quand tout demander en un coup
L’itération n’est pas toujours nécessaire. Pour les tâches simples et bien définies, un prompt unique suffit :
- Renommer une variable dans tout un fichier
- Convertir un callback en async/await
- Ajouter des types TypeScript à une fonction JavaScript existante
- Générer un test unitaire pour une fonction pure
Points clés à retenir
- Découper les demandes complexes en étapes validées progressivement
- Chaque itération construit sur la précédente après vérification
- Référencer les erreurs précédentes pour éviter les répétitions
- Ajuster le contexte au fur et à mesure des découvertes
- Les tâches simples ne nécessitent pas d’itération