La tentation grandit avec la capacité. Sur une petite tâche, donner à l'assistant une autonomie complète et réviser l'output a l'air d'un compromis raisonnable. Sur un gros projet, la même approche appliquée à travers des dizaines de sessions produit un codebase qui reflète le jugement de l'assistant plus que le tien — un dans lequel la cohérence architecturale que tu n'as pas spécifiée a été remplacée par les defaults de l'assistant.

Ce n'est pas un échec de l'assistant. C'est un échec de supervision à l'échelle où la supervision compte le plus. Les petites tâches ont un petit rayon d'explosion. Les gros projets accumulent des décisions à travers plusieurs sessions, et les décisions prises sans ton guidage à la session trois contraignent ce qui est possible à la session trente. L'autonomie qui était productive sur la petite tâche devient une dérive sur le gros projet.

La réponse n'est pas de faire plus de travail toi-même — c'est d'augmenter la fréquence et la profondeur de la revue, pas de la diminuer. Plus de sessions veut dire plus de points de contrôle, pas moins. Plus de code généré veut dire plus de lecture soigneuse, pas moins. L'overhead de la supervision grandit avec les enjeux, pas avec le volume d'output.

Les développeurs qui maintiennent le contrôle sur de gros projets assistés par IA sont ceux qui restent proches des décisions architecturales — qui révisent non seulement si le code marche mais s'il reflète le design qu'ils avaient en tête. Ils traitent chaque session comme une collaboration où leur jugement gouverne la direction et où l'assistant contribue l'exécution. Ils ne laissent pas le momentum de la génération rapide remplacer la délibération du bon design.

L'assistant est plus rapide que toi. Tu es responsable de l'endroit où il va. Les deux choses sont vraies en même temps.