31 points par GN⁺ 2025-12-19 | Aucun commentaire pour le moment. | 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

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.