Selon Gwen Davis, à mesure que l’utilisation des agents d’intelligence artificielle se développe, la valeur des développeurs reposera davantage sur l’orientation des outils, la vérification de leurs résultats et la prise de décisions techniques que sur l’écriture de chaque ligne de code. L’article propose trois pratiques : gérer les agents, ne pas accepter la première réponse et consacrer le temps gagné à la résolution de problèmes plus vastes.
Le travail des développeurs évolue à mesure que les outils d’intelligence artificielle passent de l’aide à l’écriture du code à l’exécution de parties de plus en plus importantes des tâches de programmation. Selon Gwen Davis, l’écriture du code ne suffit plus à elle seule ; il devient plus important de définir le problème, de fournir le contexte approprié, d’évaluer les résultats et d’expliquer les compromis techniques avant d’adopter la solution.
1. Orienter l’intelligence artificielle plutôt que de simplement l’utiliser
L’article explique que l’exécution, dans un environnement reposant sur l’intelligence artificielle, commence par une définition claire du travail, suivie de la répartition des tâches et de la vérification des résultats. Pour une tâche consistant à ajouter un parcours d’authentification, un agent peut se charger de préparer l’implémentation, tandis qu’un autre prépare la documentation et qu’un troisième met en place l’ensemble des tests.
Cela ne supprime pas la responsabilité du développeur quant au résultat final. Le changement pratique est que le développeur consacre moins de temps à exécuter manuellement chaque partie, et davantage de temps à définir les exigences, à coordonner les résultats des agents et à décider de ce qui est prêt à être révisé ou déployé. Davis conclut que l’apprentissage de l’orientation des agents d’intelligence artificielle est devenu une compétence pratique à part entière.
2. Ne pas faire confiance à la première réponse sans la vérifier
Les outils peuvent produire en quelques secondes une solution qui semble convaincante, mais qui peut comporter des défauts ne se révélant pas à une lecture rapide. L’article prend l’exemple d’une requête SQL renvoyant la commande la plus récente pour chaque client : la solution peut ne pas gérer les horodatages identiques, ne pas proposer un index approprié ou voir ses performances se dégrader avec des tables volumineuses.
Davis propose d’utiliser un deuxième modèle pour critiquer le travail du premier, puis d’appliquer le jugement technique aux deux réponses. Elle souligne que les modèles diffèrent par leurs points forts et leurs angles morts, et mentionne que l’agent Rubber Duck intégré à GitHub Copilot utilise un deuxième modèle pour critiquer les plans, le code et les tests. Toutefois, la vérification humaine reste indispensable ; l’objectif n’est pas de remplacer le jugement humain, mais d’ajouter une perspective critique avant de poursuivre.
3. Utiliser le temps gagné pour résoudre des problèmes plus vastes
Lorsque l’intelligence artificielle prend en charge une plus grande partie de l’exécution, le développeur peut consacrer le temps disponible à la compréhension des besoins des clients, à l’évaluation des compromis architecturaux, à la conception des systèmes et à la prise de décisions que l’outil ne peut pas prendre à sa place.
Dans un exemple concernant l’ajout du mode sombre, l’intelligence artificielle peut effectuer les modifications, générer les tests et mettre à jour la documentation. La liste des tâches du développeur comprend quant à elle la vérification du problème rencontré par les clients, l’examen des compromis architecturaux, le contrôle de l’accessibilité, la définition des indicateurs de réussite et la validation de la solution.
Qu’est-ce qui change concrètement ?
Le message essentiel n’est pas que la compétence en programmation a perdu sa valeur, mais que l’étendue des responsabilités s’élargit. Le développeur demeure responsable de la qualité du résultat, mais il doit combiner la capacité à orienter les outils avec celle de détecter leurs erreurs et de relier l’exécution à l’objectif réel du projet. L’article fournit des recommandations pratiques générales, mais ne définit pas de mesures permettant d’évaluer l’impact de ces pratiques ni les limites des tâches qui devraient être déléguées aux agents ; les décisions d’application restent donc liées à la nature du projet et au niveau de risque.