Votre travail consiste à livrer du code dont le fonctionnement est prouvé

 (simonwillison.net)
31 points par GN⁺ 2025-12-19 | 4 commentaires | Partager sur WhatsApp
  • Dans les environnements de développement assistés par l’IA, les cas où des ingénieurs peu expérimentés soumettent de gros PR non vérifiés se multiplient
  • La mission essentielle d’un développeur n’est pas simplement d’écrire du code, mais de fournir du code dont le fonctionnement est démontré
  • Pour y parvenir, il faut impérativement suivre deux étapes : les tests manuels et les tests automatisés
  • Il faut aussi configurer les agents de codage pour qu’ils vérifient eux-mêmes les modifications qu’ils produisent
  • Au final, la responsabilité incombe aux développeurs humains, et seul le code accompagné de preuves de vérification a une véritable valeur

Le problème des soumissions de code non vérifié

  • Le texte évoque des cas où des ingénieurs juniors utilisant des outils LLM soumettent de très gros PR non vérifiés en s’en remettant à la revue de code
    • C’est présenté comme impoli, inefficace et comme un abandon de responsabilité de la part du développeur
  • Le rôle d’un ingénieur logiciel n’est pas simplement de produire du code, mais de fournir du code dont le fonctionnement est prouvé
    • Le code non vérifié est considéré comme une manière de transférer la charge au relecteur

Les deux étapes pour prouver qu’un code fonctionne

  • La première étape est le test manuel : il faut vérifier soi-même que le code fonctionne correctement
    • Cela implique de remettre le système dans son état initial, d’appliquer les modifications, puis de valider le résultat
    • On peut le prouver en joignant des commandes de terminal et leurs sorties dans un commentaire de revue de code, ou via une capture vidéo d’écran
    • Une fois le fonctionnement normal confirmé, il faut rechercher d’éventuels problèmes via des tests de cas limites
  • La deuxième étape est le test automatisé, présenté comme une procédure indispensable grâce aux progrès des outils LLM
    • Les modifications doivent être accompagnées de tests automatisés, et si l’on annule l’implémentation, ces tests doivent échouer
    • L’écriture des tests suit la même procédure que les tests manuels, et la capacité à les intégrer au test harness est essentielle
    • Considérer que les seuls tests automatisés suffisent et omettre les tests manuels est décrit comme une mauvaise approche

Le rôle des agents de codage et la vérification

  • Parmi les grandes tendances du domaine des LLM en 2025 figure la croissance fulgurante des agents de codage, avec notamment Claude Code et Codex CLI
    • Ils peuvent exécuter du code et corriger eux-mêmes les problèmes
  • Les agents de codage doivent eux aussi prouver leurs propres modifications, en réalisant des tests manuels et automatisés
    • Pour les outils CLI, on peut entraîner l’agent à les exécuter directement, ou automatiser cela avec un système comme CLIRunner de Click
    • En cas de modification CSS, on peut les configurer pour vérifier le résultat à l’aide de captures d’écran
  • Si le projet dispose déjà de tests, l’agent peut les étendre ou réutiliser les motifs existants
    • La structure et la qualité du code de test ont un impact direct sur la qualité des tests générés par l’agent
    • Un sens esthétique appliqué au code de test est présenté comme une compétence clé qui distingue les ingénieurs seniors

La responsabilité humaine et la valeur du code

  • Un ordinateur ne peut pas être tenu responsable : ce rôle doit être assumé par un humain
    • Le fait qu’un LLM puisse générer de gros patchs n’a plus, en soi, une grande valeur
  • La véritable valeur réside dans la capacité à fournir du code dont le fonctionnement est prouvé
    • Lors de la soumission d’un PR, il faut impérativement inclure des preuves montrant que le code fonctionne correctement

À lire aussi

4 commentaires

 
ethanhur 2025-12-19

Je suis tout à fait d’accord. Avec le mode de fonctionnement actuel des PR, la responsabilité du code est en pratique reportée sur les mainteneurs et les reviewers. Il n’y a aucun désavantage pour ceux qui soumettent du code généré par un LLM sans l’avoir revu.

Quand on contribue à la codebase de Google, il me semble qu’ils mesurent des choses comme le crédit du contributeur ; j’ai l’impression que d’autres projets open source / entreprises vont aussi adopter ce genre de mécanisme. Je pense que la confiance va devenir un actif encore plus important.
 
roxie 2025-12-19

Oh, donc Google utilise ce concept.
 
GN⁺ 2025-12-19
Réactions sur Hacker News

  • On voit souvent ces temps-ci une anecdote déprimante : un ingénieur junior dopé aux outils LLM balance une PR énorme, non testée, à ses collègues ou à un mainteneur open source, en s’attendant à ce que la code review fasse le reste. Le pire, c’est que ce comportement ne vient pas seulement des juniors, mais aussi de développeurs seniors

    • C’est exactement ce que j’ai fait hier et aujourd’hui. Mon équipe a reçu un bug report, qu’on a attribué à un problème chez un fournisseur externe. Mais le fournisseur nous l’a renvoyé en disant que le problème venait de chez nous. J’ai donc demandé à Codex d’examiner le sujet, il a trouvé le problème et préparé une PR. Je n’ai ni relu ni testé moi-même, et j’ai laissé l’équipe faire la validation. Au passage, ça a aidé l’équipe à apprendre à utiliser les LLM comme outil de travail
    • Ces deux derniers jours, deux membres non développeurs de l’équipe ont demandé à un agent IA comment corriger un bug mobile, puis ont publié la réponse comme contenu principal du ticket. J’ai finalement dû tout relire et reconstituer les vrais besoins
    • Beaucoup de gens portent le titre de “senior” tout en se comportant comme des juniors. J’ai l’impression que c’est un effet du fait qu’aujourd’hui, après seulement deux ans de carrière, on est déjà appelé senior
    • Les développeurs capables d’ignorer ou de contourner les règles sont les plus dangereux. Ça me rappelle les développeurs 10x que j’ai connus. Quand on ignore les règles pour livrer uniquement des fonctionnalités, c’est toujours quelqu’un d’autre qui doit nettoyer derrière
    • Pendant les code reviews, je me demande où sont les juniors. S’ils ne participent pas aux revues, il est difficile qu’ils se sentent responsables de la qualité de leur code

  • Les bonnes pratiques pour rédiger une PR valent autant pour le code généré par IA que pour tout le reste. Quand j’écris la description d’une PR, j’organise toujours dans l’ordre le fonctionnement actuel, la raison du changement, puis ce qui change. J’ajoute aussi la méthode de test, des captures d’écran, et même les commandes de test E2E pour réduire la charge côté reviewer. C’est aussi très utile pour la collaboration asynchrone ou les équipes réparties sur plusieurs fuseaux horaires

    • Avant de demander une review, je relis moi-même une dernière fois. Corriger à l’avance les petites fautes de frappe ou supprimer les logs inutiles permet de faire gagner du temps au reviewer. Les reviews de Copilot repèrent bien ce genre de détails aussi
    • Même quand on écrit une explication soignée, souvent personne ne la lit. Si je continue à le faire, c’est par sens des responsabilités
    • Qu’il s’agisse ou non d’une PR aidée par l’IA, elle doit inclure des preuves de test et de validation
    • Avant, j’écrivais des descriptions longues, puis j’ai compris que personne ne les lisait. Résumer l’essentiel en puces était bien plus efficace
    • Dans le template de PR de notre équipe, il y a le numéro du ticket, la description de la demande, l’état actuel, l’état après modification, et même un « mood gif »

  • L’essence du métier d’ingénieur, c’est de comprendre les exigences, de les transformer en enchaînements logiques, d’arbitrer les trade-offs et d’assumer le résultat. Générer du code ou soumettre des PR au hasard est le symptôme d’un manque sur ces fondamentaux. Les agents de code sont même l’occasion de redécouvrir ce qu’est réellement l’ingénierie

    • Cet article montre le cas d’une seule ligne de code ayant entraîné 60 millions de dollars de pertes. Une PR de 10 000 lignes produite par IA sans compréhension du code est une catastrophe potentielle
    • En pratique, les entreprises privilégient le marketing et la rentabilité à la qualité. Les produits avec un label « premium » se vendent mieux que les produits de haute qualité. Au final, ce qui compte avant l’ingénierie, c’est ce qui se vend
    • Mais si une organisation vous met la pression avec un « utilisez l’IA et bouclez la fonctionnalité en trois jours, sinon entretien avec les RH », il devient difficile de respecter les principes idéaux de l’ingénierie

  • Les tests sont nécessaires, mais pas suffisants. Il faut aussi valider le code sur le plan logique. Les tests ne font que démontrer un fonctionnement correct sur certaines entrées et dans un environnement donné

    • Je suis du même avis. Un code qui fonctionne bien peut quand même rester mauvais
    • « Démontrer » est un terme plus juste que « prouver ». Les tests ne sont qu’un élément de preuve sur des cas particuliers
    • Je ne me contente pas de faire confiance aux tests ; j’essaie aussi de casser l’application de plusieurs façons. C’est souvent comme ça qu’on finit par améliorer le code
    • Comme la plupart du code ne peut pas être formellement prouvé, une approche comme le property-based testing semble utile
    • Même avec 100 % de couverture de test, si le code n’est pas robuste, ça ne sert à rien

  • Je ne fais pas des tests par obligation. Je les fais simplement parce que j’ai envie de voir que le code fonctionne vraiment. Si voir son code tourner ne vous enthousiasme pas, ce métier n’est peut-être pas fait pour vous

  • J’ai entendu dire que, grâce aux LLM, des juniors jetaient d’énormes PR, mais dans notre organisation, on ne voit pas encore ça

    • Ce ne sont pas forcément d’énormes PR, mais on voit souvent du code généré par LLM que le développeur ne comprend pas
    • Nous avons aussi ce genre de cas dans notre organisation. Les problèmes sont les suivants
      • l’agent annule des retours précédents
      • il ne respecte pas les standards de la codebase
      • il réinvente des solutions déjà existantes
      • il répond aux retours sur la PR avec la sortie de l’agent
      • là où 10 à 20 lignes suffiraient, il soumet une PR de 50 000 lignes
      • tests insuffisants, gestion d’erreurs médiocre
    • Les gens qui soumettaient déjà des PR de mauvaise qualité le font simplement plus vite grâce aux LLM
    • Si vous regardez WireGuard Android PR #82, #80, on y trouve encore des réponses copiées-collées de l’IA. L’onglet « files changed » est déroutant
    • Un ami travaille dans une startup de 11 personnes, et leur CTO pousse directement à 3 heures du matin 10 000 lignes de code sur main. Ça peut passer en phase d’exploration, mais en phase de stabilisation, c’est un risque terrible

  • Je ne suis pas d’accord avec l’idée que « votre travail consiste à livrer du code dans un état prouvé ». Le vrai travail, c’est de résoudre un problème métier. Bien sûr, dans la plupart des cas cela passe par du code, mais la distinction est importante

    • Mais prouver la justesse du code fait partie de la résolution du problème métier. Ce n’est pas un sujet distinct
    • On ne peut pas résoudre un problème métier en livrant du code qui ne satisfait pas les exigences
    • L’important est de résoudre le problème sans en créer de nouveaux. D’où l’importance de la sécurité et de la stabilité
    • Comme j’ai encore peu d’expérience, j’ai du mal à comprendre comment on peut résoudre un problème avec du code non validé
    • Au fond, tous les métiers consistent à résoudre des problèmes. Nous, nous le faisons simplement à travers des ordinateurs

  • Dans mon ancien emploi, je travaillais chez un fabricant japonais de matériel haut de gamme, et si le service QA trouvait un bug, la sortie du produit était suspendue. Chaque département de développement avait donc mis en place sa propre équipe QC pour renforcer les tests en amont. Résultat : le logiciel était validé de manière extrêmement rigoureuse

    • Je me demande ce que signifie « get dinged ». Une telle structure peut aussi finir par rendre les gens réticents au changement

  • Aujourd’hui, l’essence du travail s’est réduite à fermer des tickets. Comme la qualité du code n’apparaît pas dans les statistiques, elle cesse d’avoir de l’importance. Je ne participe pas à ce genre de système. L’artisanat a disparu ; tout le monde ne veut plus que du contreplaqué bon marché et de la colle

    • À partir du moment où l’on adopte les LLM partout en attendant que tout le monde s’en serve, le software engineering n’est plus une ingénierie sérieuse
    • Certains répondent à ceux qui critiquent cette attitude : « Alors quoi, vous vivez de subventions publiques ? »

  • Le problème, c’est ce qu’on entend par « code prouvé ». Il arrive aussi qu’on soumette d’énormes PR en y joignant des tests générés par LLM. Moi aussi, je fais du vibe coding sur mes projets perso, mais à l’échelle d’une équipe, c’est une mauvaise habitude. Si l’on embauche des ingénieurs, c’est pour acheter leur expertise

    • C’est pourquoi j’insiste sur les tests manuels. Montrer le comportement réel avec des captures d’écran ou des vidéos peut déjà apporter une grande confiance