IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Si vous êtes doué pour la révision de code, vous serez doué pour utiliser les agents IA
Par Sean Goedecke

Le , par Sean Goedecke

1PARTAGES

6  0 
Si vous êtes doué pour la révision de code, vous serez doué pour utiliser les agents IA, par Sean Goedecke

Utiliser correctement les agents IA revient à réviser du code. Si vous êtes doué pour réviser du code, vous serez doué pour utiliser des outils tels que Claude Code, Codex ou l'agent de codage Copilot.

Pourquoi ? Les grands modèles de langage sont doués pour produire beaucoup de code, mais ils n'ont pas encore la profondeur de jugement d'un ingénieur logiciel compétent. Sans supervision, ils passeront beaucoup de temps à prendre de mauvaises décisions de conception.

Les agents IA et les mauvaises conceptions

La semaine dernière, j'ai créé VicFlora Offline : une PWA hors ligne qui héberge certaines des données VicFlora permettant d'identifier les plantes, afin que vous puissiez toujours utiliser les clés si vous vous trouvez sur le terrain dans un endroit où la réception Internet est mauvaise. Codex a consacré beaucoup d'efforts à essayer de rétroconcevoir le code frontal VicFlora pour la clé dichotomique. Honnêtement, c'était assez impressionnant à voir ! Mais je me suis dit qu'il devait y avoir un moyen plus simple d'accéder aux données brutes, et j'avais raison. Cela se produit régulièrement lorsque j'utilise des agents de codage IA : environ une fois par heure, je remarque que l'agent fait quelque chose qui semble suspect, et lorsque j'approfondis la question, je parviens à le remettre sur la bonne voie et à économiser des heures d'efforts inutiles.

Je travaille également sur une application qui m'aide à apprendre des choses grâce à l'IA. Considérez-la comme un flux infini de répétitions espacées qui s'ajuste automatiquement. Lorsque je veux faire plusieurs choses en parallèle (par exemple, générer un plan d'apprentissage en arrière-plan), Codex et Claude Code veulent vraiment mettre en place une infrastructure complète de tâches en arrière-plan : avec des entités de tâches, des sondages de résultats, etc. J'aime les tâches en arrière-plan, mais pour un travail parallèle ordinaire de courte durée, elles sont manifestement excessives. Il suffit de faire une requête non bloquante depuis le frontend ! Si je ne recherchais pas constamment la simplicité, mon code serait beaucoup plus complexe à comprendre.

C'est d'ailleurs pour cette raison que je pense que le « vibe coding » pur n'a pas donné lieu à une explosion d'applications utiles. Si vous n'avez pas les compétences techniques nécessaires pour repérer quand le LLM s'égare, vous vous retrouverez rapidement bloqué. Essayer de faire fonctionner une solution mal conçue coûte du temps, des jetons et complique la base de code. Tous ces éléments réduisent la capacité de l'agent à résoudre réellement le problème. Une fois que deux ou trois d'entre eux s'accumulent, l'application n'est plus gérable pour l'agent et tout s'arrête.

Révision du code

Ces exemples devraient être familiers à tous ceux qui ont passé suffisamment de temps à travailler dans une équipe d'ingénieurs avec des juniors enthousiastes. Se lancer tête baissée dans une idée précoce et la faire fonctionner à force d'efforts est une erreur très courante. C'est au reste de l'équipe de freiner cette tendance. Travailler avec des agents IA, c'est comme travailler avec des juniors enthousiastes qui ne développent jamais le jugement qu'un véritable humain acquiert avec le temps.

Remarque : Chaque fois que je vois cet argument avancé, je me demande : si vous avez commencé à utiliser des outils de codage IA avec Copilot dès 2022 et que vous utilisez toujours des outils IA de pointe en 2025, n'avez-vous pas l'impression que ces outils ont évolué au même rythme qu'un être humain ? Si l'on comparait la première version de Copilot à un jeune diplômé et l'actuel Claude Code (ou tout autre outil similaire) à un ingénieur ayant trois ans d'expérience, serait-ce trop exagéré ? Dans trois ans, travailler avec des outils d'IA reviendra-t-il à travailler avec un ingénieur ayant six ans d'expérience ?

C'est une bonne occasion de parler de ce que je considère comme la plus grande erreur commise par les ingénieurs lors de la révision du code : ne penser qu'au code qui a été écrit, et non au code qui aurait pu être écrit. J'ai vu même des ingénieurs expérimentés effectuer des révisions de code en passant au peigne fin les différences, sans se demander si c'était le bon endroit pour le code.

À mon avis, la meilleure révision de code est structurelle. Elle apporte le contexte provenant de parties du code que la comparaison ne mentionne pas. Idéalement, ce contexte rend la comparaison plus courte et plus élégante : par exemple, au lieu de créer un nouveau système pour l'opération X, nous pouvons réutiliser un système qui existe déjà. Au lieu de créer un pipeline de scraping fragile qui extrait des identifiants dichotomiques du code SPA frontal, téléchargeons simplement les clés dichotomiques à partir de cet autre endroit où elles sont explicitement disponibles. Au lieu de créer tout un système de tâches en arrière-plan, effectuons simplement notre travail en parallèle sur le client, en utilisant tous les mécanismes existants dont disposent les sites web pour faire deux choses à la fois.

Si vous êtes un réviseur de code pointilleux, je pense que vous aurez du mal à utiliser efficacement les outils d'IA. Vous passerez votre temps à modifier des lignes de code individuelles, à demander un .reduce au lieu d'un .map.filter, à débattre du nom des fonctions, etc. Dans le même temps, vous manquerez l'occasion d'éloigner l'IA des impasses architecturales.

De même, si vous êtes un réviseur de code qui approuve tout sans réfléchir, vous risquez de faire trop confiance aux outils d'IA. Cette approche fonctionne avec des collègues compétents, mais elle ne fonctionne pas bien lorsque vous intégrez des ingénieurs juniors, ni lorsque vous travaillez avec des agents de codage IA.

Conclusion

Que signifie « être doué en IA » ? Être doué pour un outil normal comme git est simple : si vous maîtrisez la structure arborescente de base d'un dépôt git et que vous connaissez la plupart des opérations git, vous êtes doué pour git. Mais la structure de base de l'IA est une masse impénétrable de poids de modèles, et les « opérations » qu'elle peut effectuer sont « pratiquement tout ce que vous pouvez faire avec un ordinateur ». Il n'existe aucun outil d'ingénierie logicielle comparable.

Les partisans les plus optimistes de l'IA pensent que « être doué en IA » consiste à adopter au maximum les outils d'IA dans tous les aspects de votre vie. L'argument ici est que l'IA joue en quelque sorte le rôle du personnel de Jeff Bezos. Utiliser un personnel hyper compétent et doté de ressources illimitées ne nécessite pas beaucoup de compétences : il suffit de demander ce que vous voulez, et d'énormes efforts seront consacrés à vous le fournir. Mais Bezos utilise certainement son personnel plus efficacement que je ne le ferais si j'étais téléporté à sa place aujourd'hui. Je n'envisagerais même pas de demander la moitié des choses que je voudrais : il ne me viendrait tout simplement pas à l'esprit que je pourrais avoir un croissant Lune tout chaud qui m'attend à ma descente de mon jet privé, par exemple, même si j'apprécierais vraiment cela. Les adeptes de l'IA pensent que les outils d'IA fonctionnent un peu comme cela. Selon eux, lorsque vous aurez véritablement intégré le fait que vous pouvez demander à votre assistant IA personnel de coder n'importe quel programme, de trier n'importe quelle quantité de données ou de rédiger tous vos e-mails, vous commencerez à utiliser l'IA beaucoup plus fréquemment, à votre avantage.

Je ne pense pas que nous en soyons encore là. J'utilise beaucoup les outils de codage agentique : GitHub Copilot au travail et pour le travail, et Codex et Claude Code pour mes projets personnels. Bien qu'ils puissent accomplir un nombre surprenant de tâches de manière autonome, ils nécessitent une supervision assez étroite. Le modèle de programmation dominant s'apparente au « jeu d'échecs centaure », où un humain compétent est associé à un assistant informatique. Plus vous êtes doué pour la révision de code (pour évaluer si une approche logicielle particulière est judicieuse), plus vous serez à même d'utiliser les outils d'IA agentielle.

Remarque : Le fait que j'utilise Codex et Claude Code ne signifie pas que je les trouve meilleurs que Copilot. À mon avis, l'utilisation de divers outils d'IA fait partie de mon travail.

Source : "If you are good at code review, you will be good at using AI agents"

Et vous ?

Pensez-vous que cette comparaison est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Comment j'utilise les LLM en tant qu'ingénieur logiciel, par sean goedecke

Le Vibe Coding crée des codeurs sans cervelle, par Namanyay Goel

L'utilisation de code généré par l'IA fera de vous un mauvais programmeur, par Rudis Muiznieks
Vous avez lu gratuitement 6 755 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !