- Les outils de codage par IA automatisent la partie facile, l’écriture du code, ce qui crée un problème structurel où il ne reste aux développeurs que les tâches difficiles : recherche, compréhension du contexte et vérification
- Le fait que des développeurs disent « l’IA l’a fait à ma place » sans comprendre eux-mêmes la sortie de l’IA est un signal d’alerte comparable aux copier-coller d’autrefois depuis StackOverflow
- Le vibe coding est utile pour le prototypage, mais en environnement de production réel, l’IA peut faire perdre plus de temps qu’elle n’en fait gagner
- Lorsqu’un déploiement rapide est rendu possible une fois grâce à l’IA, cela devient une nouvelle référence, ce qui crée des problèmes de management menant à une pression continue sur les sprints et au burnout
- L’essentiel est d’utiliser l’IA non comme fournisseur de solutions, mais comme outil de recherche, et de faire en sorte que le développeur conserve la responsabilité de tout le code
Le problème avec la phrase « l’IA l’a fait à ma place »
- Par le passé, les développeurs lisaient des réponses StackOverflow, des articles ou des issues GitHub, puis vérifiaient eux-mêmes le contexte avant d’en tirer une conclusion
- Personne ne disait « Google a écrit le code » ou « c’est correct parce que c’est le premier résultat de recherche »
- Depuis peu, l’expression « l’IA l’a fait à ma place » a commencé à apparaître
- Cela exagère ce qui s’est réellement passé, ou signifie que le développeur n’a pas tiré lui-même la conclusion
- Dans les deux cas, c’est problématique, et cela soulève la même inquiétude qu’avec le copier-coller de code depuis StackOverflow : a-t-on réellement compris le code collé ?
Les limites du vibe coding
- Le vibe coding est amusant au départ, et utile pour le prototypage ou des projets personnels à faible risque
- Mais dans le travail réel, chaque ligne de code a des conséquences
- Dans un projet personnel, après avoir demandé à un agent IA d’ajouter des tests dans un fichier donné, un fichier de 500 lignes a été réduit à 100 lignes
- L’IA a affirmé ne rien avoir supprimé, puis a ensuite prétendu que le fichier n’avait jamais existé
- Lorsqu’on lui a montré l’historique git, elle s’est excusée et a reconnu qu’elle aurait dû vérifier d’abord l’existence du fichier
- Dans ce cas, l’assistance de l’IA a consommé plus de temps qu’elle n’en a fait gagner
- Discuter avec l’agent et restaurer le fichier a pris plus de temps que d’écrire directement les tests
- Si la même chose se produisait dans un environnement comme une codebase de santé, les conséquences pourraient être graves
- Il est important d’utiliser l’IA non comme fournisseur de solutions, mais comme outil de recherche, et il faut de la pratique pour repérer quand l’IA se trompe
Une structure où les parties difficiles deviennent plus difficiles
- Écrire du code était à l’origine la partie facile du travail de développement
- Les parties difficiles, ce sont la recherche, la compréhension du contexte, la vérification des hypothèses et le fait de savoir pourquoi une approche donnée est la bonne
- Si l’on confie la partie facile à l’IA, le travail ne diminue pas ; il ne reste que les tâches difficiles
- Si l’on saute la phase de recherche parce que l’IA a déjà donné une réponse, on se retrouve sans le contexte nécessaire pour évaluer la production de l’IA
- Lire et comprendre le code de quelqu’un d’autre est bien plus difficile qu’écrire du code
- Le code généré par l’IA est, par nature, le code de quelqu’un d’autre
- On confie à la machine ce que le développeur sait bien faire (écrire), et il ne reste que la partie plus difficile (lire et reviewer)
- Il faut alors reviewer sans le contexte accumulé pendant l’écriture
Attentes de sprint et burnout
- Lorsqu’un déploiement rapide est rendu possible une fois, notamment grâce à l’IA, cela devient la nouvelle référence et l’on exige ensuite cette vitesse en permanence
- La discussion passe de « comment as-tu fait ça ? » à « pourquoi n’arrives-tu pas à faire ça à chaque fois ? »
- Ce n’est pas un problème d’ingénierie, mais un problème de management
- Un ingénieur épuisé laisse passer des edge cases, saute des tests et met des bugs en production
- Plus d’incidents → plus de pression → plus de sprints : un cercle vicieux
- Face à l’affirmation selon laquelle « l’IA multiplie la productivité par 10 », il se peut qu’en réalité un ingénieur à 0,1x soit simplement devenu un ingénieur à 1x
- Techniquement, c’est bien du x10, mais la vraie question est de savoir s’il s’agit d’un gain de productivité ou de la mise en lumière d’un manque antérieur de recherche
- Le burnout et la mise en production de code de mauvaise qualité annulent les gains de productivité apportés par l’IA
Compétences senior, confiance junior
- Les agents de codage IA ont une capacité d’écriture de code de niveau senior, mais il faut aborder leur niveau de confiance sur le résultat comme celui d’un ingénieur junior
- Le code a l’air correct et fonctionnera probablement, mais faute d’expérience, il faut le vérifier plus minutieusement
- Pour prendre une analogie, un agent de codage IA, c’est comme si une personne capable de lire très vite rejoignait soudainement l’équipe
- Elle peut aider à la recherche et écrire du code, mais elle n’a pas assisté à la réunion de la semaine dernière où l’on a discuté du contexte et des éléments de fond importants
L’importance de la propriété du code
- Les développeurs doivent assumer une propriété responsable non seulement du code qu’ils écrivent eux-mêmes, mais aussi du code généré par l’IA
- Si l’on fait du copier-coller de sortie IA à cause d’objectifs de vitesse irréalistes, le problème apparaîtra six mois plus tard quand un nouveau membre de l’équipe essaiera de comprendre le code, ou à 2 heures du matin lorsqu’un incident surviendra
- Dire « c’est l’IA qui l’a écrit » n’aide dans aucune situation
Comment l’IA peut aider sur les parties difficiles
- Cas d’un bug en production : juste après une grosse release, des utilisateurs ont signalé un bug de edge case dans l’affichage du fuseau horaire
- Le développeur responsable devait partir en cours 30 minutes plus tard, et les autres étaient déjà partis
- L’IA a été utilisée pour mener l’enquête ; elle a indiqué qu’il s’agissait d’un bug lié à des changements récents et a expliqué comment le reproduire
- La cause était que certaines méthodes deprecated prenaient le dessus sur les méthodes actuelles prenant en charge les fuseaux horaires, ce qui empêchait la conversion de fuseau horaire de se faire correctement
- En 15 minutes, la cause racine, des idées de solution et des notes d’investigation ont été consignées dans une issue GitHub
- Le développeur responsable a validé le correctif, puis un autre membre de l’équipe a terminé les tests et le déploiement
- Le problème a été résolu sans urgence ni heures supplémentaires
- Ce cas montre l’essentiel : une structure de collaboration où l’IA prend en charge le travail répétitif d’investigation, tandis que l’humain apporte le contexte et la validation
- L’IA doit être utilisée pour renforcer la recherche, la vérification et la compréhension du contexte ; sinon, on fige une structure où les tâches faciles deviennent plus faciles et les tâches difficiles plus difficiles
Aucun commentaire pour le moment.