Une équipe peut produire davantage de code tout en comprenant moins bien ce qu’elle livre. Avec les agents IA, certaines étapes deviennent presque instantanées. D’autres demandent toujours du temps : examiner une hypothèse, comprendre une dépendance, décider si un changement est acceptable. Supprimer ces moments de réflexion au nom de la vitesse peut fragiliser le produit.
Imaginez une pull request qui corrige un bug, ajoute une dépendance et réorganise au passage la gestion des permissions. Les tests passent. L’agent fournit un résumé convaincant. Le développeur qui l’a lancé doit maintenant comprendre plusieurs décisions prises ensemble, puis les expliquer au relecteur.
Le code est disponible. La décision de le livrer reste à prendre.
Dans The Friction Is Your Judgment, Armin Ronacher et Cristina Poncela Cubeiro relient deux difficultés : préserver son jugement lorsqu’on travaille avec des agents, et organiser le logiciel pour qu’ils puissent intervenir correctement. Leur conférence s’appuie sur leur expérience chez Earendil, sans prétendre proposer une méthode définitive. Présentation originale.
Pour une équipe de développement, elle invite à examiner les étapes qu’on cherche à accélérer. Que perd-on exactement lorsqu’on supprime un obstacle ?
Le temps gagné devient une nouvelle attente
Cristina décrit une évolution des attentes : après avoir libéré du temps, les outils deviennent la norme et alimentent la pression à produire davantage. Elle évoque aussi la difficulté à interrompre une succession de prompts lorsque chaque résultat donne le sentiment d’avancer. Conférence, à partir de 3:29.
Pour un responsable technique, la conséquence mérite une décision explicite. À quoi sert le temps gagné ?
Prenons une fonctionnalité terminée plus tôt que prévu. L’équipe peut utiliser cette marge pour vérifier un parcours inhabituel, observer son fonctionnement ou préparer la prochaine évolution. Elle peut aussi commencer immédiatement un autre ticket.
Aucun de ces choix n’est absurde. Mais si le deuxième devient systématique, la validation doit trouver sa place dans un planning déjà rempli. Le gain de vitesse ne finance alors jamais une meilleure compréhension.
Cette pression peut aussi venir du développeur lui-même. Une correction fonctionne presque. Une nouvelle demande semble pouvoir régler le dernier problème. Puis une autre devient nécessaire. Avant de poursuivre, il serait pourtant utile de vérifier si l’approche choisie reste adaptée.
Une règle d’arrêt aide dans ces moments. Si un correctif commence à modifier des comportements sans rapport avec le bug initial, reprenez le diagnostic. Demandez ce que chaque changement cherche à résoudre et quelle observation le justifie.
Pour le management, cela suppose d’accepter qu’une session productive puisse se terminer par une décision de simplifier, de supprimer ou de ne pas livrer.
La capacité de revue devient une contrainte de production
Ronacher souligne un déséquilibre : les agents augmentent la capacité à produire du code sans augmenter dans les mêmes proportions la capacité humaine à le comprendre. La responsabilité reste portée par les personnes qui maintiennent le produit. Conférence, à partir de 5:29.
Revenons à notre pull request. Son principal défaut tient au mélange des décisions. Le relecteur doit évaluer simultanément le correctif, la dépendance et les nouvelles permissions.
Découper ce travail après sa génération demande déjà un effort. Le découpage devrait commencer dans la tâche confiée à l’agent : reproduire le bug, corriger sa cause, puis proposer séparément les évolutions qui dépassent ce périmètre.
Une petite pull request reste toutefois insuffisante si son intention est floue. Quelques lignes peuvent changer les droits de tous les utilisateurs. La taille facilite la lecture ; elle ne détermine pas le risque.
Une revue exploitable doit permettre de retrouver rapidement :
- le comportement attendu et le problème observé ;
- les décisions prises pour y répondre ;
- les vérifications réalisées et leurs limites ;
- les points qui demandent encore un arbitrage.
L’agent peut préparer ces éléments. Le développeur qui présente le changement doit pouvoir les discuter et repérer une explication incorrecte.
Pour un lead, la file de revues devient aussi un signal de capacité. Si les changements terminés attendent sans cesse une personne disponible, lancer davantage de tâches peut aggraver l’attente. Terminer les validations en cours devient alors une priorité d’équipe.
Ce sujet prolonge celui de la revue du code généré par IA : la validation doit apporter des preuves sur le comportement du produit.
Une correction locale peut cacher un problème plus large
Les intervenants décrivent deux dérives liées : des mécanismes de secours peuvent masquer une erreur, et une base de code désordonnée peut conduire l’agent à recréer ce qui existe déjà. Le désordre rend alors les interventions suivantes plus difficiles. Présentation, « Why Agent Code Drifts ».
Considérons un service qui importe des commandes. Il rencontre une ligne invalide, puis une correction lui permet de continuer en ignorant cette ligne. Le traitement termine désormais sans erreur.
Ce comportement peut être acceptable. Encore faut-il que le métier l’ait choisi. L’utilisateur voit-il combien de commandes ont été ignorées ? Peut-il les corriger ? Le total affiché correspond-il aux données réellement importées ?
Le problème dépasse le traitement d’une exception. Il concerne la signification de « terminé ».
Une revue utile doit donc examiner les conséquences du chemin de secours. Lorsqu’une opération échoue, le système doit-il s’arrêter, réessayer ou poursuivre partiellement ? Chaque réponse implique un comportement observable et une façon de reprendre le travail.
Le même raisonnement s’applique aux doublons. Supposons qu’une règle de remise existe dans le paiement, puis qu’une variante apparaisse dans l’export des factures. Chaque implémentation peut sembler raisonnable lorsqu’on la lit seule. Leur divergence apparaîtra au prochain changement commercial.
Le correctif durable consiste à identifier où cette décision doit être définie, puis à faire utiliser cette règle par les deux parcours. Ajouter une nouvelle condition dans chaque fichier prolongerait le problème.
Avant d’accepter une correction, il faut donc pouvoir expliquer ce qu’elle rétablit. Un test devenu vert peut confirmer le bon comportement, ou simplement refléter une attente modifiée pour correspondre au nouveau code.
L’architecture détermine ce que l’agent peut comprendre
La conférence distingue les tâches bien délimitées des produits où facturation, permissions et interface interagissent. Elle recommande des frontières claires, des conventions reconnaissables et des transitions explicites entre les parties du système. Présentation, sections consacrées à l’architecture.
Pour une équipe, cela rend très concrète une question d’architecture : quelles informations faut-il réunir pour modifier correctement un comportement ?
Prenons un export de données réservé à certains abonnements. Si le bouton, la vérification des droits et les limites d’usage appliquent chacun leur propre interprétation de l’offre, une modification impose de retrouver toutes ces décisions.
Une organisation plus lisible permet d’identifier la règle qui autorise l’export et les endroits qui l’utilisent. Elle facilite aussi le travail d’un nouveau développeur.
Il ne suffit pas de séparer le code en dossiers. Il faut clarifier ce qui passe d’une étape à l’autre. Un export demandé, autorisé, préparé puis téléchargé correspond à plusieurs états. Les confondre oblige ensuite à ajouter des conditions pour reconnaître les situations particulières.
Pour le CTO, l’enjeu est de choisir les zones où cette clarification aura un effet réel. Une réorganisation générale du dépôt peut attendre. Une règle commerciale copiée dans plusieurs parcours mérite probablement d’être traitée avant la prochaine évolution de l’offre.
La promesse « on nettoiera plus tard » doit ainsi être accompagnée d’un périmètre connu. Qu’a-t-on volontairement simplifié ? Quelles limites accepte-t-on ? Quel événement déclenchera la reprise ?
Sans ces réponses, le travail futur reste difficile à évaluer.
Automatiser les règles, préserver les arbitrages
Chez Earendil, les intervenants utilisent des contrôles mécaniques pour certaines conventions et distinguent les corrections automatisables des changements qui nécessitent une attention humaine. Les migrations de données et les permissions font partie de ces derniers. Conférence, à partir de 12:32.
Cette distinction permet de réserver l’attention de l’équipe aux questions qui restent ouvertes.
Un contrôle peut interdire un accès direct à la base en dehors du module prévu. Un test peut vérifier qu’un utilisateur sans permission ne télécharge pas un document. Mais quelqu’un doit d’abord décider quels utilisateurs devraient disposer de cette permission.
Ajouter une confirmation à chaque étape apporte peu si la personne n’a aucune information nouvelle à examiner. La friction utile doit avoir un objet précis.
| Changement | Preuve ou décision attendue |
|---|---|
| Modification visuelle limitée | Vérification du rendu et des interactions concernées |
| Nouvelle règle de permission | Définition des accès attendus et tests des refus |
| Transformation de données existantes | Validation sur des données représentatives et procédure de reprise |
| Nouvelle dépendance | Besoin identifié, coût de maintenance et alternatives examinées |
Ce tableau constitue un point de départ à adapter au produit. Il ne remplace pas l’analyse du changement.
Les agents restent utiles pour préparer ces validations : construire un cas de reproduction, explorer une solution ou réunir les éléments d’une revue. La conférence cite justement le prototypage et la reproduction de bugs parmi les usages où leur vitesse aide. Conférence, à partir de 16:00.
L’équipe gagne alors du temps sur la préparation de la décision, tout en conservant un moment identifiable pour la prendre.
Ce qu’il faut retenir
La friction utile oblige à répondre à une question encore ouverte : ce comportement correspond-il au besoin, que se passe-t-il en cas d’échec, qui pourra reprendre le système ? Les attentes répétitives et vérifiables peuvent être automatisées. Les arbitrages doivent rester visibles.
Pour évaluer un processus, regardez ce qu’une étape apporte réellement. Une approbation systématique mérite d’être repensée. Une revue qui révèle une hypothèse métier manquante remplit son rôle, même si elle retarde la livraison.
Conclusion
Lors de votre prochaine rétrospective, reprenez un changement récent qui a été difficile à valider. Identifiez ce qui manquait au moment de la revue : un périmètre clair, une règle métier ou une preuve de fonctionnement. Placez cette exigence plus tôt dans la prochaine tâche confiée à un agent.
Si ces difficultés se répètent dans votre équipe, un échange de 30 minutes peut aider à déterminer quels contrôles automatiser et quelles décisions rendre explicites.