L’anxiété liée au fait de devoir écrire du code avec l’IA

Petit dialogue d’ouverture : Quand le code devient une boîte noire

Shiwen：Hier, un post sur Hacker News a été très populaire. Un ingénieur de Meta a dit que, après tant d’années de travail, c’était la première fois qu’il se sentait si incertain dans son travail. Son message était à peu près le suivant : Lorsqu’on écrit du code aujourd’hui, on a l’impression de travailler avec une boîte noire. On comprend la logique générale, mais on ne sait pas toujours tous les détails de chaque ligne. Cela pourrait devenir une nouvelle norme dans le secteur. Qu’en penses-tu ?

Yongliang：J’ai lu les citations dans le document de référence de ce post. La principale angoisse n’est pas liée à l’AI, mais plutôt au changement dans la manière de comprendre les choses. J’ai travaillé en technologie pendant dix-sept ans, et j’ai dirigé des équipes de soixante-dix personnes. Avant, on considérait que le code soumis par un ingénieur devait être expliquable ligne par ligne. Maintenant, cette norme s’est affaiblie, mais pas au point de ne plus avoir de normes. La norme est passée de « comprendre chaque ligne » à « jusqu’où comprendre est responsable ». C’est la question que je veux clarifier dans cette édition.

Shiwen：Donc tu n’es pas venu pour dénigrer l’assistance de l’AI à la programmation ?

Yongliang：Non. Dans mon équipe, nous utilisons déjà l’AI pour écrire des tests, ajouter des commentaires, modifier le code ancien. C’est vraiment rapide. Mais même si c’est rapide, qui est responsable en cas de problème ? C’est une question que les managers ne peuvent pas ignorer. Aujourd’hui, je veux analyser cette angoisse à partir de quatre angles : le phénomène, l’expérience personnelle, les mécanismes de l’équipe et les limites du point de vue adverse.

Q1 : Quelle est donc l’angoisse de cet ingénieur ?

Shiwen：Dis-nous d’abord le phénomène. En un mot, quelle est l’angoisse de cet ingénieur de Meta ?

Yongliang：Il n’a pas peur que l’AI écrive mal, mais il a peur de livrer un produit qu’il ne comprend pas complètement. En langage simple : Je sais ce que fait ce code, mais si on me demande pourquoi certaines conditions sont traitées ainsi, je ne peux peut-être pas répondre. Avant, on appelait ça « ne pas avoir compris », maintenant on appelle ça « la norme de génération par l’AI ».

Shiwen：Cette angoisse est représentative ?

Yongliang：Oui, beaucoup. Mais c’est juste une nouvelle forme d’angoisse. Avant, nous avions aussi des angoisses : les bibliothèques n’ont pas été écrites par vous, les frameworks n’ont pas été écrits par vous, le fondement des services cloud n’a pas été écrit par vous, alors pourquoi osez-vous l’utiliser ? La réponse est que vous avez établi un « niveau de confiance ». Vous croyez au noyau Linux, à React, à AWS, parce qu’ils ont été testés et fonctionnent dans la réalité. Le problème avec le code généré par l’AI n’est pas qu’il soit toujours faux, mais que son « niveau de confiance » n’a pas été bien établi avant que vous l’intégriez au dépôt principal.

Shiwen：Donc le problème n’est pas que le code vient de l’AI, mais que la base de confiance n’a pas été établie ?

Yongliang：On peut comprendre cela. Et je dois ajouter quelque chose : plus un ingénieur est expérimenté, plus il a cette angoisse, car il sait à quel point une information non testée peut devenir un problème dans le environnement de production. Les nouveaux employés n’ont pas ce fardeau, parfois c’est bon, mais aussi le risque est grand.

Q2 : Comment tu géries cette boîte noire personnellement ?

Shiwen：Passons au niveau personnel. Avec dix-sept ans d’expérience en technologie, écris-tu encore du code ligne par ligne maintenant ?

Yongliang: Je me poserai d’abord la question : à qui appartient “la propriété” de ce code. Si c’est à moi, je dois comprendre ; si c’est à l’AI, je dois vérifier. C’est mon expérience, pas une statistique. La méthode consiste en trois étapes. Premièrement, l’AI me fournit une fonction, écrit une régularité, génère des données de test ; je parcours rapidement les entrées et sorties pour vérifier qu’il n’y a pas de déviations significatives dans le sens du discours, puis je l’utilise. Deuxièmement, lorsque l’AI fournit un code impliquant la concurrence, la sécurité ou les mécanismes d’état, je lui demande de l’expliquer pas à pas et de réexécuter les cas d’utilisation limites par moi-même. Troisièmement, si ce code doit entrer dans le processus central, je le traite comme une PR soumise par un collègue : je relis, ajoute des tests, demande à quelqu’un de le revoir, plutôt que de l’accepter simplement parce que “l’AI dit que c’est bon”.

Shiwen: Y a-t-il des cas où vous ne laissez pas l’AI intervenir ?

Yongliang: Oui. Deux types. Le premier sont les codes impliquant les fonds, les droits d’accès ou la confidentialité, comme la vérification des paiements, la logique d’authentification, la déshumainisation des données. Ces domaines ont des règles strictes et des conséquences graves ; une hallucination de l’AI peut entraîner un accident. Le deuxième type sont les décisions architecturales que je ne comprends pas moi-même. Si vous ne savez même pas ce que vous allez faire, laisser l’AI écrire le code pour vous, c’est lui permettre de penser à votre place, et le résultat sera sûrement une boîte élégante mais dévoyée.

Shiwen: Donc votre principe est “Je peux ne pas écrire moi-même, mais je ne dois pas ne rien savoir”.

Yongliang: Exactement. Ce principe s’applique à tout outil. Que vous utilisiez Git, IDE ou AI, cela ne change rien : la personne qui signe en fin de compte est vous, et la responsabilité repose sur vous. L’AI ne peut pas comparaître devant un tribunal, expliquer ou assumer des erreurs.

Q3: Comment établissez-vous un mécanisme de révision dans une équipe de soixante-dix personnes ?

Shiwen: Passer du niveau individuel au niveau de l’équipe. Avez-vous géré soixante-dix personnes, comment le code généré par l’AI circule-t-il dans l’équipe ?

Yongliang: Disons d’abord une règle stricte : le code généré par l’AI doit être indiqué dans la description de soumission. Ce n’est pas pour discriminer l’AI, mais pour savoir où se trouvent les risques lors de la révision. Quand j’étais en charge de l’équipe, il y avait une évaluation spéciale pour cela : “Dans cette modification, quelles décisions viennent de l’homme et quelles viennent de l’outil ?” Si le soumetteur ne peut pas répondre, on lui demande de révoir.

Shiwen: Mais avec autant de code généré par l’AI, est-il possible de revoir chaque ligne ?

Yongliang: Non, il n’est pas possible. C’est pourquoi nous utilisons un mécanisme hiérarchisé. À l’époque, nous avons divisé les modifications en trois catégories. La première catégorie concerne les modifications de modules ordinaires, où la proportion de code généré par l’AI est faible, et qui sont soumises à une révision conventionnelle. La deuxième catégorie concerne les modifications entrant dans les modules centraux, qui doivent être révisées par au moins deux personnes, avec des tests unitaires et intégratifs. La troisième catégorie concerne les parties ayant le plus d’impact et impliquant des fonds ou des droits d’accès ; l’AI ne peut que soutenir, elle ne doit pas générer directement du code, et finalement il faut écrire chaque ligne manuellement et signer. Les limites de ces trois catégories sont clairement indiquées dans le wiki de l’équipe ; les nouveaux arrivants doivent regarder cette section avant de commencer.

Shiwen: Y a-t-il des exigences particulières pour les tests ?

Yongliang: Oui. Pour le code écrit par l’AI, le taux de couverture des tests doit être un niveau supérieur à celui écrit manuellement. Ce n’est pas une punition, c’est une mesure de protection. Comme vous ne comprenez pas les détails, il faut que les tests gardent les limites du comportement. De plus, pour le code écrit par l’AI, les tests des parcours clés ne doivent pas être générés par la même modèle, comme l’a souligné le commentaire d’edwin0 : l’AI peut écrire le code et les tests selon la même logique, et finalement les bugs peuvent être parfaitement cachés.

Shiwen: Y a-t-il des collègues qui sont réticents à cette méthode ?

Yongliang：Bien sûr que oui. Certains disent que cela ne fait qu’augmenter la charge de travail. Mais l’AI n’est-elle pas là pour améliorer l’efficacité ? Ma réponse est : l’AI augmente l’efficacité « écrite », pas celle qui est validée, testée et prête à être mise en ligne. Si vous intégrez du code non vérifié simplement parce qu’il est rapide, le temps nécessaire pour le débugger et le corriger sera multiplié par dix ou cent. Depuis que je dirige mon équipe, j’ai vérifié cette idée à maintes reprises, c’est pourquoi je suis prêt à l’intégrer dans nos processus.

Shiwen：En plus du code, qu’en est-il des documents, des rapports hebdomadaires, des prototypes de conception ?

Yongliang：La même logique. L’AI peut vous aider à clarifier les choses, mais il ne peut pas assumer la responsabilité. Chaque décision, chaque choix dans les documents doit être réalisé par une personne physique. À l’intérieur de notre équipe, nous appelons cela le « système de signature » : c’est la personne qui exprime ses idées qui signe ; même les documents rédigés par l’AI doivent être confirmés par une personne avant d’être publiés. Cette règle peut sembler formelle, mais elle concrétise le concept de « responsabilité ».

Q4 : Quelles sont les opinions de l’opposition, et où se trouvent leurs limites ?

Shiwen：Il y a beaucoup d’opinions opposées ou complémentaires sur HN. Je cite quelques-unes qui sont représentatives.

Yongliang：Je reprends les points de vue les plus populaires mentionnés dans le package de faits. Le premier vient de spacedcowboy, qui dit : tant que cela fonctionne, je suis d’accord ; c’est comme si je ne vérifiais pas chaque ligne de code écrite par chaque collègue. Mais je mettrai beaucoup de tests et de programmes réels comme critère de validation. Je suis d’accord avec cela, car cela place le code généré par l’AI à une position raisonnable : vous n’avez pas besoin de comprendre chaque ligne, mais vous avez besoin de moyens de vérification observables.

Shiwen：Quelle est l’opposition à cela ?

Yongliang：Le deuxième point de vue vient de edwin0 : il est inquiétant que l’AI écrive le code et les tests en même temps, car ils peuvent commettre les mêmes erreurs. Ce rappel est crucial. Si le code et les tests sont générés par le même modèle, les tests peuvent facilement devenir une « auto-proclamation » : le modèle écrit le code selon ses propres idées, puis écrit les tests selon les mêmes idées. Les tests passent bien sûr, mais les bugs sont également cachés. Donc, notre approche est que l’AI peut écrire le code, mais les tests doivent être rédigés par des personnes ou vérifiés de manière croisée.

Shiwen：Y a-t-il d’autres points de vue ?

Yongliang：Le troisième point de vue vient de mattbrewsbytes, qui dit que c’est en fait une sorte de « compression conceptuelle », comme le ORM de Rails. La plupart du temps, cela fonctionne bien, mais lorsque la taille de la base de données augmente, vous deviez retourner à SQL. En d’autres termes, le code généré par l’AI est basé sur une abstraction qui vous permet de lancer le système, mais lorsque cette abstraction atteint des limites, vous devez descendre plus en profondeur. Cette analogie que j’utilise souvent pour nous rappeler : ne oubliez pas les principes fondamentaux simplement parce que l’AI est pratique.

Shiwen：Et le quatrième point de vue ?

Yongliang：Le point de vue de billylo est plus axé sur la pratique de l’ingénierie : utiliser la visibilité en temps réel, les vérifications croisées et les alertes pour compenser les risques. C’est une autre expression de notre mécanisme de travail. Vous ne pouvez pas éliminer tous les risques non transparents à l’avance, mais vous pouvez faire en sorte que ces risques soient détectés dès qu’ils surviennent.

Shiwen：Alors, où se trouvent les limites ?

Yongliang：Les limites sont la « vérifiable ». Si les entrées et sorties d’un module peuvent être clairement testées, couvertes par les logs et la surveillance, et révisées par des collègues, alors il n’y a pas de problème avec le code non transparent. Mais si cela ne peut pas être vérifié, si personne ne peut assumer la responsabilité, si cela ne peut pas être audité, alors que ce soit écrit par l’AI ou non, il ne devrait pas être mis en ligne directement. Cette limite n’a rien à voir avec l’AI, mais avec les compétences de conception.

Conclusion : La boîte noire ne disparaîtra pas, mais la responsabilité ne peut être transférée

Shiwen：Pour conclure cette édition. Une phrase pour cet article.

Yongliang：L’anxiété liée à la boîte noire où l’AI écrit des codes est essentiellement un transfert de responsabilité. Avant, la responsabilité reposait sur « avez-vous écrit le code » ; maintenant, elle repose sur « comprenez-vous le code, le vérifiez-vous, êtes-vous capable de prendre la responsabilité ». Plus les outils sont puissants, plus le jugement humain devient précieux. La boîte noire ne disparaîtra pas, mais vous pouvez en faire une entité acceptable grâce à des tests, des reviews, du monitoring et des mécanismes de signature.

Shiwen：Plus concrètement, que peut emporter un ingénieur ordinaire aujourd’hui ?

Yongliang：Trois phrases. Premièrement, l’AI peut être votre copilote, mais la carte de conduite est à vous. Deuxièmement, pour les codes incompréhensibles, soit vous les comprenez, soit vous les soumettez à des tests et des moniteurs pour éviter que la boîte noire ne fonctionne sans surveillance. Troisièmement, tous les codes entrant dans un environnement de production doivent être finalement responsables devant une personne humaine. Même si la technologie change, cette règle reste inchangée. La prochaine fois que l’AI écrit un code pour vous, ne vous précipitez pas pour le soumettre. Demandez-vous d’abord : si ce code cause des problèmes demain, puis-je expliquer pourquoi il est écrit de cette manière ?

Sources d’information

• Poste de discussion sur Hacker News, 2026-10-19, Ask HN : L’ingénieur Meta Ali Hamie a dit « Ces jours-ci, je écris des codes et tout cela me semble être une boîte noire… Vous comprenez le niveau général, mais pas tous les détails. Peut-être que c’est devenu la nouvelle norme. » (Résumé d’une citation originale)
• Commentaire bien noté sur HN par spacedcowboy : « Si ça fonctionne, ça me va ; je ne vérifie pas chaque ligne de code écrite par chaque collègue, mais je compte sur les tests et les programmes réels comme barrières. » (Résumé d’une citation originale)
• Commentaire bien noté sur HN par edwin0 : « Que l’AI écrive des codes et fasse des tests est plus inquiétant car ils peuvent commettre les mêmes erreurs. » (Résumé d’une citation originale)
• Commentaire bien noté sur HN par mattbrewsbytes : L’analogie avec les ORM de Rails ; la couche d’abstraction fonctionne la plupart du temps, mais lorsque la base de données devient grande, il faut revenir à SQL. (Résumé d’une citation originale)
• Commentaire bien noté sur HN par billylo : Gestion des risques grâce à la visibleité au moment de l’exécution, les vérifications croisées et les alertes. (Résumé d’une citation originale)
• Expérience personnelle du participant : Dix-sept ans d’expérience technique, équipe de soixante-dix personnes à son apogée ; système de signature pour les reviews de code, annotation des codes par l’AI, couverture des tests, review par deux personnes pour les modules clés, etc. sont tous des pratiques personnelles.