L'étude qui fait réfléchir
Anthropic a mené une étude contrôlée : à un quiz de compréhension du code, les ingénieurs qui avaient laissé l'IA générer sans s'impliquer ont obtenu environ 17 points de moins (50% contre 67%) que ceux qui restaient dans le code. Déléguer sans relire, ça se paie en compréhension.
Autrement dit : plus vous copiez-collez du code IA sans le comprendre, plus vous perdez la capacité de maintenir votre projet. C'est l'équivalent de prendre un GPS partout et ne plus savoir lire une carte.
La bonne nouvelle : il suffit d'une habitude simple pour éviter ce piège. Expliquer avant de shipper.
La règle "Explain before you ship"
Avant d'intégrer du code IA dans votre projet, posez-vous une question : "Est-ce que je peux expliquer chaque ligne à un collègue ?"
Si la réponse est non, ne shippez pas. Prenez le temps de comprendre. Voici la méthode en 3 étapes :
- Lisez ligne par ligne : pas en diagonale, mais chaque instruction
- Surlignez ce que vous ne comprenez pas : une variable mystérieuse, une syntaxe inconnue, une logique obscure
- Demandez à l'IA d'expliquer CE point précis : pas "explique ce code", mais "explique ce que fait
array_reduceici et pourquoi pas une boucleforeach"
La technique "teach the AI" : expliquez le code à l'IA comme si elle ne le connaissait pas. "Ce code fait X, puis Y, puis Z." Si l'IA vous corrige, c'est que vous aviez mal compris une partie.
Un juge et partie : pour du code qui touche à l'argent, aux droits d'accès ou à la sécurité, ne vous arrêtez pas à l'explication que l'IA donne de son propre code. Elle a les mêmes angles morts pour l'expliquer que pour l'écrire. Tracez vous-même le chemin des données, ligne par ligne.
Le code IA « a l'air » correct la plupart du temps. Avant de dérouler : citez deux ou trois pièges fréquents qui se cachent derrière un code syntaxiquement propre.
Voir la réponse
Les classiques : un off-by-one dans une boucle (< confondu avec <=), un null check manquant, une injection SQL cachée dans une concaténation « simple », ou une condition inversée qui fait le contraire de ce que dit le commentaire. Rien qui saute aux yeux à la lecture rapide.
Patterns courants qui semblent corrects
L'IA génère souvent du code qui a l'air correct mais qui contient des bugs subtils. Voici les pièges les plus fréquents :
- Off-by-one : boucles qui itèrent une fois de trop ou de moins. L'IA confond souvent
<et<= - Null check manquant : l'IA suppose que les données existent toujours. Elle oublie que
document.querySelector()peut retournernull - Injection SQL : l'IA génère parfois des concaténations de strings au lieu de requêtes préparées, surtout dans les exemples "simples"
- Logique inversée : conditions
if/elsequi font le contraire de ce qui est décrit dans les commentaires
Le code IA est comme le code d'un stagiaire brillant : syntaxiquement correct, structurellement cohérent, mais potentiellement dangereux dans les détails.
Exercice de lecture
Regardez ce code généré par l'IA pour une fonction de recherche utilisateur. Trois lignes sont commentées avec "// Que fait cette ligne ?" : essayez de répondre avant de lire la suite :
L'ordre compte : ne demandez pas l'explication à l'IA en premier. Lisez, formulez votre hypothèse sur ce que fait la ligne, puis seulement demandez. Si vous demandez avant d'avoir cherché, vous lisez une réponse au lieu de construire une compréhension.
function findUser(users, searchTerm) {
const term = searchTerm.toLowerCase(); // Que fait cette ligne ?
return users.filter(user =>
user.name.toLowerCase().includes(term) // Que fait cette ligne ?
)[0]; // Que fait cette ligne ?
}Voir les réponses
Réponses :
- Ligne 2 : convertit le terme de recherche en minuscules pour une recherche insensible à la casse
- Ligne 4 : filtre les utilisateurs dont le nom (en minuscules) contient le terme recherché
- Ligne 5 : prend le premier résultat du tableau filtré : attention : retourne
undefinedsi aucun utilisateur ne correspond
Bug subtil : que se passe-t-il si searchTerm est null ? La ligne 2 plantera avec TypeError: Cannot read property 'toLowerCase' of null. L'IA n'a pas ajouté de validation d'entrée.
The study that makes you think
Anthropic ran a controlled study: on a code-comprehension quiz, engineers who let the AI generate without engaging scored about 17 points lower (50% vs 67%) than those who stayed in the code. Delegating without rereading costs you comprehension.
In other words: the more you copy-paste AI code without understanding it, the more you lose the ability to maintain your project. It is the equivalent of using GPS everywhere and no longer knowing how to read a map.
The good news: one simple habit is enough to avoid this trap. Explain before you ship.
The "Explain before you ship" rule
Before integrating AI code into your project, ask yourself one question: "Can I explain every line to a colleague?"
If the answer is no, do not ship. Take the time to understand. Here is the 3-step method:
- Read line by line — not skimming, but each instruction
- Highlight what you do not understand — a mysterious variable, unknown syntax, obscure logic
- Ask the AI to explain THAT specific point — not "explain this code", but "explain what
array_reducedoes here and why not aforeachloop"
The "teach the AI" technique: explain the code to the AI as if it does not know it. "This code does X, then Y, then Z." If the AI corrects you, it means you misunderstood a part.
Judge and defendant: for code touching money, access rights, or security, do not stop at the AI's own explanation of its own code. It has the same blind spots explaining it as writing it. Trace the data path yourself, line by line.
AI code "looks" correct most of the time. Before scrolling down: name two or three frequent traps hiding behind syntactically clean code.
Show the answer
The classics: an off-by-one in a loop (< confused with <=), a missing null check, an SQL injection hidden in a "simple" concatenation, or an inverted condition that does the opposite of what the comment says. Nothing that jumps out on a quick read.
Common patterns that look correct
AI often generates code that looks correct but contains subtle bugs. Here are the most frequent traps:
- Off-by-one — loops that iterate one time too many or too few. AI often confuses
<and<= - Missing null check — AI assumes data always exists. It forgets that
document.querySelector()can returnnull - SQL injection — AI sometimes generates string concatenations instead of prepared statements, especially in "simple" examples
- Inverted logic —
if/elseconditions that do the opposite of what is described in the comments
AI code is like the code of a brilliant intern: syntactically correct, structurally coherent, but potentially dangerous in the details.
Reading exercise
Look at this AI-generated code for a user search function. Three lines are commented with "// What does this line do?" — try to answer before reading on:
Order matters: do not ask the AI for the explanation first. Read, form your hypothesis about what the line does, and only then ask. If you ask before you have looked, you read an answer instead of building understanding.
function findUser(users, searchTerm) {
const term = searchTerm.toLowerCase(); // What does this line do?
return users.filter(user =>
user.name.toLowerCase().includes(term) // What does this line do?
)[0]; // What does this line do?
}See the answers
Answers:
- Line 2: converts the search term to lowercase for case-insensitive search
- Line 4: filters users whose name (lowercased) contains the search term
- Line 5: takes the first result from the filtered array — warning: returns
undefinedif no user matches
Subtle bug: what happens if searchTerm is null? Line 2 will crash with TypeError: Cannot read property 'toLowerCase' of null. The AI did not add input validation.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
✨ Prompt IA
Testez la technique 'teach the AI'. Copiez ce prompt dans Claude :
Je vais t'expliquer ce que fait cette fonction JavaScript, et tu me dis si j'ai bien compris : la fonction findUser prend un tableau d'utilisateurs et un terme de recherche. Elle convertit le terme en minuscules, puis filtre les utilisateurs dont le nom contient ce terme, et retourne le premier résultat. Est-ce que mon explication est correcte ? Qu'est-ce que j'ai oublié ?
💬 Ré-explique sans regarder
Sans relire : un collègue colle du code de l'IA et veut le merger tout de suite. Avec tes mots, explique-lui la règle « Explain before you ship » et pourquoi elle protège le projet.
Ce code IA semble correct mais contient 3 problèmes. Décrivez-les ci-dessous. Indices : pensez à la validation d'entrée, aux cas limites, et à la sécurité.
function getUserAge(birthDate) {
const today = new Date();
const birth = new Date(birthDate);
const age = today.getFullYear() - birth.getFullYear();
return age;
}⚖️ Juge le code de l'IA
Tu as demandé à l'IA une fonction qui renvoie le prix TTC d'un panier. Tu la relis ligne par ligne avant de la merger. Tu l'acceptes telle quelle ou tu la rejettes ?
function totalTTC(items) {
let total = 0;
for (let i = 0; i <= items.length; i++) {
total += items[i].price;
}
return total * 1.2; // TVA 20%
}i <= items.length fait une itération de trop. Au dernier tour, items[items.length] vaut undefined, et undefined.price jette TypeError. Le code « a l'air » correct (commentaire TVA rassurant, structure propre), mais il plante dès le premier appel. Correctif : i < items.length. C'est exactement pourquoi on relit ligne par ligne au lieu de faire confiance à l'allure du code.🧠 Rappel libre
Sans remonter dans la leçon : en une phrase, que dit la règle « Explain before you ship », et cite deux pièges fréquents du code IA qui « a l'air » correct.
< vs <=), null check manquant (querySelector() qui renvoie null), injection SQL par concaténation, logique inversée dans un if/else.Vous savez relire et comprendre ce que l'IA produit. Le souci, c'est qu'une grosse demande d'un seul coup donne du code illisible. La prochaine leçon, décomposer et itérer, montre comment découper une fonctionnalité en petites étapes que l'IA traite proprement, une à une.
Leçon 4 : Décomposer et itérer →