Quand devriez-vous demander à une IA d'écrire du code à partir de zéro plutôt que de simplement examiner ou refactoriser du code existant?

Question

Accepted Answer

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.

## Quand la laisser écrire à partir de zéro

- **Greenfield et boilerplate** — une nouvelle util, un fichier de configuration, un endpoint CRUD, une regex. Il n'y a pas de contexte caché à casser.
- **APIs/bibliothèques peu familières** — l'IA connaît la surface d'une bibliothèque que vous ne connaissez pas, et vous vérifiez par rapport à la documentation.
- **Code jetable/prototype** — la vitesse compte plus que la perfection.

Dans ces cas, le coût d'un bogue est faible et vous pouvez lire le résultat de haut en bas.

## Quand l'utiliser uniquement pour examiner/refactoriser

- **Logique critique pour l'entreprise** — facturation, authentification, mathématiques financières. Une réponse fausse mais plausible est dangereuse.
- **Code subtil** — concurrence, sécurité, algorithmes très dépendants des cas limites où « semble juste » n'est pas « est juste ».
- **Grands systèmes existants** — l'IA ne peut pas voir tous les invariants sur lesquels votre codebase s'appuie, donc générer dedans risque des ruptures silencieuses.

Ici, vous gardez l'IA comme un **deuxième regard** : elle suggère, vous décidez.

```text
                 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
```

## Compromis et risques

É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.

## Pourquoi c'est important

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.