Le jour où j'ai demandé tout d'un coup
Un samedi matin, j'ai ouvert mon assistant IA et j'ai écrit : « Crée-moi une application complète de gestion de tâches avec authentification, base de données, notifications par email et un tableau de bord. » J'étais fier de mon prompt détaillé. Trente secondes plus tard, l'IA crachait 600 lignes de code réparties dans douze fichiers.
Rien ne marchait. La base de données pointait vers une table qui n'existait pas, l'authentification utilisait une bibliothèque jamais installée, et le tableau de bord affichait des données codées en dur. Pire : je ne savais même pas par où commencer pour réparer, parce que je n'avais lu aucune de ces 600 lignes.
Plus une tâche est large, plus l'IA accumule d'hypothèses non vérifiées. Un gros bloc de code généré d'un coup est presque toujours impossible à déboguer, parce que personne (ni vous ni l'IA) ne sait quelle partie est réellement cassée.
Découper en tâches atomiques
Une tâche atomique, c'est une unité de travail qui produit un résultat que vous pouvez vérifier immédiatement. Si vous ne pouvez pas dire en une phrase « c'est terminé et ça marche », la tâche est trop grosse.
Reprenons l'application de gestion de tâches. Au lieu d'un seul prompt géant, on découpe :
- Tâche 1 : créer la table
tasksen base et vérifier qu'elle existe - Tâche 2 : afficher la liste des tâches existantes (même vide)
- Tâche 3 : ajouter un formulaire pour créer une tâche
- Tâche 4 : permettre de marquer une tâche comme terminée
- Tâche 5 : ajouter l'authentification, une fois que le cœur fonctionne
Chaque tâche est testable seule. Si la tâche 3 casse, vous savez exactement où chercher, parce que les tâches 1 et 2 étaient déjà validées.
Règle d'or : une fonctionnalité à la fois. Ne demandez jamais à l'IA d'ajouter une nouvelle fonctionnalité tant que la précédente n'est pas testée et fonctionnelle.
La boucle : petit changement, vérifier, suivant
Coder avec l'IA n'est pas un sprint, c'est une boucle. Chaque tour de boucle suit le même rythme :
- Demander un petit changement précis
- Lire ce que l'IA a produit (pas juste copier-coller)
- Vérifier que ça marche : lancer le code, regarder le résultat
- Commiter si c'est bon, puis passer au changement suivant
Cette discipline a un bénéfice caché : à chaque commit, vous avez un point de sauvegarde. Si l'IA casse tout au tour suivant, vous revenez en arrière en une commande au lieu de tout perdre.
# Après chaque tâche validée, on fige le progrès
git add tasks.php
git commit -m "feat: affichage de la liste des taches"
# Si l'IA casse le code au prochain tour, on revient ici
git checkout tasks.phpGarder l'IA sur les rails
Plus une conversation s'allonge, plus l'IA dérive : elle oublie les contraintes du début, réintroduit des bugs déjà corrigés, ou « améliore » du code qui marchait très bien. Quelques techniques pour garder le cap :
- Recadrer régulièrement : rappelez l'objectif et l'état actuel au début d'un nouveau prompt
- Geler le périmètre : « Ne modifie que la fonction
addTask, ne touche à rien d'autre » - Repartir propre : si la conversation devient confuse, ouvrez une nouvelle session avec un contexte clair plutôt que d'insister
Comparez les deux demandes ci-dessous. La première laisse l'IA improviser ; la seconde la cadre.
# Trop vague (l'IA va déborder)
Améliore mon système de tâches.
# Cadré (l'IA reste atomique)
Ajoute UNIQUEMENT une fonction `markDone(int $id)` dans
tasks.php. Elle passe la colonne `done` à 1 pour la tâche
donnée. Ne modifie aucune autre fonction. Montre-moi
seulement le code de cette fonction.The day I asked for everything at once
One Saturday morning, I opened my AI assistant and wrote: "Build me a complete task management app with authentication, a database, email notifications, and a dashboard." I was proud of my detailed prompt. Thirty seconds later, the AI spat out 600 lines of code across twelve files.
Nothing worked. The database pointed to a table that did not exist, authentication used a library never installed, and the dashboard showed hardcoded data. Worse: I did not even know where to start fixing it, because I had read none of those 600 lines.
The broader a task, the more unverified assumptions the AI piles up. A large block of code generated at once is almost always impossible to debug, because nobody — neither you nor the AI — knows which part is actually broken.
Splitting into atomic tasks
An atomic task is a unit of work that produces a result you can verify immediately. If you cannot say in one sentence "it is done and it works", the task is too big.
Back to the task management app. Instead of one giant prompt, we split:
- Task 1 — create the
taskstable and verify it exists - Task 2 — display the list of existing tasks (even if empty)
- Task 3 — add a form to create a task
- Task 4 — allow marking a task as done
- Task 5 — add authentication, once the core works
Each task is testable alone. If task 3 breaks, you know exactly where to look, because tasks 1 and 2 were already validated.
Golden rule: one feature at a time. Never ask the AI to add a new feature until the previous one is tested and working.
The loop: small change, verify, next
Coding with AI is not a sprint, it is a loop. Each turn follows the same rhythm:
- Ask for one small, precise change
- Read what the AI produced (not just copy-paste)
- Verify it works: run the code, look at the result
- Commit if good, then move to the next change
This discipline has a hidden benefit: at each commit, you have a save point. If the AI breaks everything on the next turn, you roll back in one command instead of losing everything.
# After each validated task, we freeze progress
git add tasks.php
git commit -m "feat: display the task list"
# If the AI breaks the code next turn, we come back here
git checkout tasks.phpKeeping the AI on track
The longer a conversation gets, the more the AI drifts: it forgets the early constraints, reintroduces already-fixed bugs, or "improves" code that worked fine. A few techniques to stay on course:
- Reframe regularly: restate the goal and the current state at the start of a new prompt
- Freeze the scope: "Only modify the
addTaskfunction, touch nothing else" - Start clean: if the conversation gets confused, open a fresh session with clear context instead of insisting
Compare the two requests below. The first lets the AI improvise; the second frames it.
# Too vague (the AI will overreach)
Improve my task system.
# Framed (the AI stays atomic)
Add ONLY a `markDone(int $id)` function in tasks.php.
It sets the `done` column to 1 for the given task.
Do not modify any other function. Show me only the
code for that function.Demandez à l'IA de découper une grosse fonctionnalité en tâches atomiques avant d'écrire la moindre ligne :
Je veux construire [décrivez la fonctionnalité]. Ne génère aucun code pour l'instant. Découpe d'abord ce travail en tâches atomiques, ordonnées, où chaque tâche produit un résultat que je peux tester seul. Pour chaque tâche, indique comment je vérifie qu'elle est terminée. On les fera une par une.
Objectif : un formulaire de contact qui valide les champs, envoie un email et affiche un message de succès. Écrivez la liste des tâches atomiques (une par ligne), ordonnées, chacune testable seule.
L'IA vient de te rendre une liste de tâches. Avec tes mots, à quoi reconnais-tu qu'une tâche de cette liste est vraiment atomique, et pourquoi en faire une par une plutôt que tout demander d'un coup ?
Tu avais demandé UNIQUEMENT une fonction markDone(int $id) dans tasks.php, sans toucher au reste. Voici ce que l'IA te rend. Ton rôle de relecteur : accepter tel quel ou rejeter, et dire pourquoi.
function markDone(int $id): void {
$db = getDb();
$db->prepare('UPDATE tasks SET done = 1 WHERE id = ?')->execute([$id]);
}
// Pendant que j'y suis, j'ai aussi nettoye addTask :
function addTask(string $title): int {
$db = getDb();
// suppression de la validation, elle ralentissait l'insert
$db->prepare('INSERT INTO tasks (title) VALUES (?)')->execute([$title]);
return (int) $db->lastInsertId();
}markDone demandée est correcte, mais l'IA a débordé du périmètre : elle a aussi réécrit addTask et au passage supprimé une validation, exactement la dérive contre laquelle on cadre. C'est doublement dangereux : ça touche du code qui marchait et ça introduit une régression cachée dans un diff censé être minuscule. Le réflexe pro : on garde seulement markDone, on rejette le reste, et on recadre (« ne modifie que markDone, ne touche à rien d'autre »).Sans remonter dans la leçon : cite les quatre temps de la boucle d'itération avec l'IA, dans l'ordre.
Slicing into small steps cuts down errors, but never removes them: sooner or later it breaks. The next lesson, debugging with AI, teaches you to describe a bug usefully (message, context, what you expected) so it finds the cause instead of guessing.
Lesson 5: Debugging with AI →