Le développement assisté par IA exige encore du jugement

L'accélération déplace le goulot

L'IA peut produire options d'implémentation, tests, migrations, documentation et investigations à une vitesse remarquable. Cette vitesse déplace le goulot de la frappe vers le jugement. Les ingénieurs doivent définir le problème, choisir les contraintes, reconnaître les erreurs plausibles, et décider si le résultat s'inscrit dans le système qui le possédera.

Un changement généré peut être syntaxiquement correct et architecturalement faux. Il peut dupliquer une abstraction existante, contourner l'autorisation, ignorer les contraintes de déploiement, ou optimiser une fonction locale tout en affaiblissant la frontière produit. La compréhension du dépôt reste la différence entre génération de code et ingénierie.

Donner à l'agent un résultat borné

Les tâches fortes décrivent le résultat visible à l'utilisateur, les fichiers ou modules pertinents, les invariants qui doivent rester vrais, et comment le succès sera vérifié. Elles évitent de prescritre chaque ligne tout en empêchant l'agent d'élargir vers des refactors non liés.

Avant d'éditer, inspectez les conventions locales, la documentation du framework et les versions actuelles des dépendances. Les systèmes IA sont entraînés sur des patterns historiques ; les frameworks rapides invalident fréquemment des API familières. Ancrer le travail dans le dépôt réel fait partie de la correction, pas de la cérémonie.

• Énoncez le comportement non négociable
• Nommez les tests et environnements qui comptent
• Préservez les changements utilisateur non liés
• Demandez des alternatives quand une décision est coûteuse à inverser

Reviewer le diff comme un design

Reviewer le travail généré à plusieurs niveaux. Le flux utilisateur a-t-il du sens ? Les frontières et l'ownership des données sont-elles claires ? Les états d'échec sont-ils gérés ? Le code est-il lisible dans l'idiome du dépôt ? Puis inspectez sécurité, accessibilité, performance et comportement opérationnel.

Les grands diffs générés réduisent la qualité de revue. Préférez de petits incréments cohérents avec vérification entre eux. Quand un changement est mécanique, l'automatisation peut être large ; quand il contient du jugement architectural, gardez la surface assez compacte pour qu'un humain puisse vraiment la comprendre.

La vérification n'est pas optionnelle

Exécutez analyse statique, type checks, tests et builds de production. Pour le travail d'interface, inspectez le comportement réel du navigateur aux breakpoints et états d'interaction pertinents. Pour les migrations, testez l'exécution avant et la récupération. Pour les API, vérifiez autorisation et entrées malformées, pas seulement le happy path.

L'IA peut aider à concevoir cette vérification, mais elle ne peut pas faire disparaître la responsabilité. Si la suite de tests est faible, la confiance générée l'est aussi. Ajoutez le plus petit test à haute valeur qui protège le comportement modifié.

Garder l'ownership humaine

Les agents de coding sont de puissants collaborateurs quand l'ingénieur reste accountable de l'intention et des conséquences. Enregistrez les décisions importantes, divulguez les dépendances générées, et évitez d'envoyer secrets ou données de production sensibles dans des outils sans frontière approuvée.

L'avantage durable n'est pas de produire plus de code. C'est de raccourcir le chemin d'un problème bien cadré vers un résultat vérifié tout en maintenant la cohérence du système.