TDD, agents IA et programmation - Kent Beck

Présentation de Kent Beck

• Créateur de l’Extreme Programming (XP)
• Co-auteur du manifeste Agile (premier signataire par ordre alphabétique)
• Pionnier du TDD (Test-Driven Development)
• Légende du secteur avec 52 ans d’expérience en programmation
• Écrit actuellement "Tidy Together" (sur le design logiciel et le travail en équipe)
• Passe actuellement "la période de programmation la plus agréable" en codant 6 à 10 heures par jour, voire plus, avec des outils d’IA

---

1. Les outils de codage IA et la métaphore du "génie"

Concept clé : un génie imprévisible

• Compare les agents IA à un "génie imprévisible"
• "Ils ne font pas exactement ce que je veux dire"
• "Ils ont leur propre agenda"

Expérience de travail avec l’IA

Aspects positifs :

• Résolution parfois de gros problèmes de design, comme par magie
• Implémentation de fonctionnalités utiles inattendues (ex. : un stress tester de B+ tree)

Aspects négatifs :

• Mauvaise interprétation de l’intention de l’utilisateur
• Tentatives de suppression ou de modification des tests
• Tendance espiègle à "résoudre" les problèmes avec une table de lookup

Une expérience addictive

• Récompense intermittente, comme une machine à sous
• "Je passe devant l’ordinateur la nuit et je me demande : et si je faisais encore un prompt ?"
• "Je lance un prompt d’une heure et je sors"

---

2. L’évolution des compétences à l’ère de l’IA

Recomposition de la valeur des compétences

"90 % des compétences perdent leur valeur, et 10 % voient leur valeur multipliée par 1000"

Compétences dont la valeur augmente :

• Définir une vision
• Gérer les jalons
• Maîtriser la complexité

Compétences dont la valeur baisse :

• Les détails propres à chaque langage (position de &, *, [] en Rust, etc.)

Changement de regard sur les langages de programmation

Avant : fort attachement émotionnel à Smalltalk
Aujourd’hui :

• Cet attachement a disparu, car il a "eu trop le cœur brisé"
• Fatigue face aux identités de "développeur Java" ou "développeur Clojure"
• "Apprentissage par osmose" : grâce à l’IA, il est possible de programmer sans connaître les détails d’un langage

Langages essayés récemment : Swift, Go, Rust, Haskell, C++, JavaScript

Projet ambitieux actuel : Server Smalltalk

• Persistant : fonctionne comme une base de données
• Transactionnel : supporte commit et abort
• Parallélisme : traitement parallèle multithread et entre machines
• Traitement de gros volumes de données

---

3. L’histoire du manifeste Agile

Contexte de sa naissance (2001)

• Recherche d’une alternative au modèle en cascade
• Résultat de plusieurs années d’ateliers sur les méthodologies logicielles
• Réunion préparatoire pour une croisière en Norvège → réunion finale dans l’Utah

Contribution de Kent Beck

• Ajout du mot "daily" (dans les 12 principes : "interagir quotidiennement")
• Premier signataire par ordre alphabétique

Insatisfaction vis-à-vis du terme "Agile"

Problèmes :

• Le terme était "trop séduisant", et il prévoyait que toutes les organisations en abuseraient
• Des organisations ont effectivement commencé à se dire agiles sans suivre les principes

Alternative qu’il préférait : "conversational"

• Met l’accent sur une communication bidirectionnelle plutôt qu’unilatérale
• N’a pas été retenu, faute d’attrait

---

4. Extreme Programming (XP)

Origine de sa création

Premières expériences de conseil :

• Au départ consultant technique (tuning de performance, manipulation de bits)
• Demandes croissantes de conseils en gestion de projet
• Découverte de l’importance de l’environnement : le simple fait de changer la disposition des sièges apportait des améliorations spectaculaires

Projet Chrysler :

• Transformation d’un projet en échec en réussite
• Toutes les pratiques efficaces ont été poussées "au maximum (jusqu’à 11)"

Principes clés de XP

Réaliser en parallèle ou en séquence, dans des cycles très courts, quatre activités :

1. Déterminer quoi faire
2. Concevoir quelle structure adopter
3. Implémenter la fonctionnalité
4. Vérifier si cela fonctionne comme prévu

Pair programming

• Approche expérimentale, pas une obligation
• Constat initial de l’équipe : tous les bugs détectés après développement provenaient du code écrit en solo
• "Zéro défaut en production avec le pair programming"

La stratégie derrière le nom

• Choix du terme "Extreme" : un nom provocateur que le concurrent (Grady Booch) n’utiliserait pas
• Le terme tombait bien avec la mode des sports extrêmes
• "Un athlète extrême est soit parfaitement préparé, soit mort" — une bonne métaphore

Facteurs de succès

• À l’époque de la bulle internet, cela a parlé aux développeurs désespérés par les cycles en cascade de 18 mois
• Promesse de résultats plus rapides et plus prévisibles

---

5. Test-Driven Development (TDD)

Origines et inspirations (années 1970)

Systèmes tape-to-tape :

• Concept découvert dans un livre de programmation de son père
• Entrée réelle → saisie manuelle de la sortie attendue → écriture du code → comparaison avec la sortie réelle
• Lu entre 8 et 12 ans, sans réellement le comprendre

Développement de S-Unit :

• Créé pour aider un client à écrire des tests
• Tentative de cette idée "ridicule" : "saisir la valeur attendue avant d’écrire le code"

Première expérience TDD : implémenter une pile

Tempérament anxieux :

• "Je suis une personne anxieuse. Je m’inquiète beaucoup."
• "La programmation est une source constante d’anxiété" (qu’est-ce que j’ai oublié ? qu’est-ce que j’ai cassé ?)

Résultat avec le TDD :

• "L’anxiété a complètement disparu"
• "Je suis sûr que ça marche"
• Transformation de l’expérience émotionnelle de la programmation

La valeur du TDD

Bénéfices techniques :

• Réduction de la densité de défauts
• Retour rapide sur les choix d’API
• Possibilité de faire évoluer le design de l’implémentation

Bénéfices émotionnels :

• "Rien que comme traitement contre l’anxiété technique, ça vaut largement le coût"

Réponse aux critiques sur le design

Critique de John Osterhout : "Le TDD n’aide pas au design et se concentre seulement sur les détails"

Réponse de Kent Beck :

• "C’est une question de choix"
• En pratique, les ingénieurs naviguent en permanence entre différents niveaux d’abstraction pour prendre des décisions de design
• Le moment de "relâchement de tension" dans le cycle Red-Green donne plus de liberté pour réfléchir à un design plus large

---

6. Agents IA et TDD

Mise en pratique

Toujours écrire les tests d’abord :

• Les tests permettent d’exprimer ce que l’IA a raté
• Ils bloquent les tentatives de l’IA de modifier ou supprimer les tests

Améliorations nécessaires :

• Besoin d’une "annotation immutable"
• "Ça, c’est correct. Si vous le changez, vous vous réveillerez pour l’éternité dans les ténèbres"

Limites de l’IA

• Faible capacité à réduire le couplage et augmenter la cohésion
• Manque de sens du design
• Tendance à prendre des décisions aux effets de bord lointains

Stratégie de réponse

• Grande suite de tests exécutée en 300 millisecondes
• Détection en temps réel des cassures de code involontaires causées par l’IA

---

7. Expérience chez Facebook (2011-2017)

Le choc à l’arrivée en 2011

Zéro participant au cours sur le TDD :

• Techniques Excel avancées : complet + liste d’attente
• Tango argentin : complet + liste d’attente
• TDD : aucun participant

Stratégie adoptée :

• "Oublier tout ce que je sais en ingénierie logicielle"
• Décision de "regarder les singes et les imiter"

L’environnement de développement unique de Facebook

Forte responsabilisation :

• Les programmeurs sont d’astreinte la nuit
• "Ils ressentent directement la douleur de leurs propres erreurs"

Boucles de feedback à plusieurs niveaux :

• Serveur de dev rapide (vérification immédiate après un changement bleu → vert)
• Code review
• Déploiement interne (utilisé par les employés à titre personnel et professionnel)
• Rollout progressif (quotidien / hebdomadaire)
• Excellente observabilité

Culture d’organisation :

• "Chez Facebook, rien n’est le problème de quelqu’un d’autre"
• Même si une grand-mère arrive avec un problème de harcèlement visant son petit-fils, "c’est aussi votre problème"

Pourquoi le TDD n’y convenait pas

Vraie nature des problèmes :

• Problèmes de configuration
• Relations entre sous-systèmes
• Des choses difficiles à capturer par des tests

Atouts propres à Facebook :

• Tests grandeur nature en production sur une base de millions d’utilisateurs
• Excellente observabilité
• Feature flags
• Un environnement difficile à reproduire dans une entreprise classique

Exemple concret :

• Implémentation d’une fonctionnalité d’état relationnel (single / married avec ajout de civil union / cohabitation)
• TDD utilisé, mais "une perte de temps"
• Problème dû à un couplage implicite dans le code de notification → hotfix par quelqu’un d’autre

Évolution selon les périodes

2011 (2 000 personnes) :

• Potentiel, échelle et sens de la responsabilité au plus haut
• Managers intermédiaires pensant en optimisation globale
• Coopération centrée sur "qui a vraiment besoin d’aide"

2017 (15 000 personnes) :

• Politique, pensée à somme nulle, micro-optimisation
• Il devient plus difficile d’avoir une vision d’ensemble
• Conflits d’intérêts entre équipes (ex. : textes longs vs équipe optimisant likes/commentaires)

L’expérience de l’échelle

• API Messenger : un quadrillion d’appels par semaine
• Un groupe expérimental de la taille de la "Nouvelle-Zélande" (un million de personnes)
• 1 quadrillion = un million × un milliard

---

8. L’avenir du développement logiciel à l’ère de l’IA

Changement de paradigme

Recomposition totale de la structure des coûts :

• "La frontière entre ce qui est bon marché et ce qui est cher change complètement"
• Ce qui était auparavant considéré comme coûteux devient "ridiculement bon marché"

Défis d’adaptation pour les organisations

Jeter davantage de code :

• Possibilité de produire 10 fois plus d’artefacts
• Mais un seul a encore de la valeur
• Besoin de systèmes de récompense pour "jeter des expériences terminées"

Hausse quantitative de l’expérimentation :

• La quantité d’idées explorées devient un avantage compétitif
• Une époque où il faut "tout expérimenter"

Évolution personnelle

• Coder redevient amusant
• Il devient possible d’avoir des ambitions plus grandes
• Des "idées extrêmement ambitieuses" deviennent réalisables

---

9. Q&R rapide

Préférences personnelles

• Langage préféré : Smalltalk
• Deuxième langage : JavaScript (similaire à Smalltalk)
• Outil IA actuel : Claude (moteur interne de Cursor et Augment)
• Livre recommandé : "The Timeless Way of Building" de Christopher Alexander

---

Idées clés

1. L’importance absolue du contexte

• Une même méthodologie peut avoir une efficacité complètement différente selon l’environnement
• Environnement Facebook à très grande échelle vs environnement bancaire à petites transactions

2. La relation entre émotion et technique

• La vraie valeur du TDD est "la disparition de l’anxiété"
• Le changement émotionnel est plus important que la logique technique

3. Une nouvelle manière de penser à l’ère de l’IA

• La vision et la capacité de design deviennent des compétences clés
• Les détails des langages ne comptent plus autant
• L’augmentation quantitative des expérimentations devient un avantage concurrentiel

4. La puissance de la culture d’organisation

• "Rien n’est le problème de quelqu’un d’autre" : un vrai sens de l’ownership
• Optimisation globale vs optimisation individuelle
• Importance de l’alignement des incitations

[mse9000]

L’environnement de développement atypique de Facebook
Sens aigu des responsabilités :
les programmeurs sont d’astreinte la nuit
« ressentent directement la douleur de leurs propres erreurs »

Au fond, ce n’est pas si différent de l’environnement de développement coréen… ?

[helloppfm]

Il est toujours là.

Il y a longtemps, j’avais animé un séminaire sur le TDD dans une entreprise de machines, et je n’oublierai jamais les regards de tout le monde, du genre « c’est quoi ce truc ? ».

Je pense que le TDD est une bonne chose, mais en pratique, ça marche moins bien que je ne le pensais...
Du coup, je fais des tests d’intégration un peu comme du TDD. Bien sûr, ce n’est pas du TDD. ^^

[kandk]

Les partisans inconditionnels du TDD et ceux qui le jugent toujours inutile continuent de s’affronter,
mais j’aimerais qu’une version 2 du TDD soit publiée à nouveau en phase avec la situation actuelle du secteur.
De nos jours, l’IA gère facilement les petites tâches, donc par exemple comment l’utiliser lorsqu’une grande quantité de contexte est nécessaire...

[codemasterkimc]

C’est un bon article.