La règle empirique : laissez l'IA écrire où les erreurs sont peu coûteuses et évidentes, et utilisez-la pour examiner/refactoriser où les erreurs sont coûteuses ou subtiles. Le facteur décisif est le coût de vérification du résultat.
La règle empirique : laissez l'IA écrire où les erreurs sont peu coûteuses et évidentes, et utilisez-la pour examiner/refactoriser où les erreurs sont coûteuses ou subtiles. Le facteur décisif est le coût de vérification du résultat.
Dans ces cas, le coût d'un bogue est faible et vous pouvez lire le résultat de haut en bas.
Ici, vous gardez l'IA comme un deuxième regard : elle suggère, vous décidez.
Cost of a bug LOW Cost of a bug HIGH
New code ✅ let AI write ⚠️ AI drafts, you verify hard
Existing code ✅ AI refactors ✅ AI reviews, you write the change
Écrire à partir de zéro est rapide mais l'IA peut inventer des APIs (hallucination) ou manquer le contexte qu'elle ne peut pas voir. Examiner est plus sûr mais plus lent et seulement aussi bon que le contexte que vous lui fournissez. De toute façon, vous êtes l'auteur responsable — l'IA est un outil, pas celui qui signe le commit.
Mal juger cela est là où le développement assisté par IA échoue : les gens laissent l'IA générer de la logique critique qu'ils ne peuvent ensuite pas vérifier complètement, ou ils écrivent à la main du boilerplate trivial que l'IA aurait pu produire en secondes. Adapter le mode (écrire vs examiner/refactoriser) au coût d'avoir tort vous garde rapide sur le code peu coûteux et prudent sur le code dangereux. La compétence testée est le jugement sur où dépenser votre effort de vérification — pas si vous pouvez faire un prompt à une IA.