Beyond Code

1Écrire du code ne coûte presque plus rien, se tromper coûte toujours autant

Première famille : la vérification, parce que c'est là que se trouve le coût. Le cours s'appuie sur une expérience menée mi-2025 par METR, un organisme de recherche (section 1). Seize développeurs open source chevronnés ont traité 246 tâches réelles. Un tirage au sort décidait pour chaque tâche : avec l'IA ou sans.

Avant, ils prédisaient un gain de 24 %. Après, ils se sentaient 20 % plus rapides. La mesure a dit l'inverse : 19 % plus lents. Entre le ressenti (20 % de gain) et la réalité (19 % de perte), il y a 39 points d'écart. Pour le cours, cet écart est plus grave que la lenteur : il montre que personne ne mesurait.

La raison est simple. Générer du code se voit, les lignes défilent. Vérifier ne se voit pas : il faut parcourir tout ce que le code touche. « La génération est un flux. La vérification est un paysage. »

2Une porte mécanique répond, une relecture donne un avis

Si la vérification coûte, encore faut-il qu'elle vérifie quelque chose. « Ce code est-il bon ? » n'a pas de réponse définie, dit le cours (section 6). Chaque relecteur juge avec sa propre idée de la qualité. Frédéric Brochet, à l'université de Bordeaux, a servi à 54 étudiants en œnologie un vin blanc teint en rouge. Ils l'ont décrit avec le vocabulaire du vin rouge. Le cours oppose donc deux sortes de contrôle :

• La relecture (le cours dit « revue consultative ») : une personne ou un agent lit le code et donne son avis. Deux relecteurs compétents peuvent conclure l'inverse.
• La porte mécanique : un test ou un contrôle de types (l'outil qui vérifie que chaque valeur a le type attendu) confronte le code à une spécification. La réponse est oui ou non, la même à chaque passage.

L'exemple du cours est Knight Capital, une société de trading, en 2012. Une mise à jour déployée à la main a oublié un serveur sur 8. En 45 minutes, la société a perdu 460 millions de dollars. Une porte mécanique aurait vu l'écart avant l'ouverture du marché : il suffisait d'un script qui compare les 8 serveurs. D'où la formule : « La relecture demande si quelqu'un a fait le travail. La porte mécanique demande si le travail a réussi. »

Le cours ajoute une observation : remplacer les relecteurs humains par des relecteurs IA ne règle rien. Ses relecteurs IA, sans ego ni carrière, chipotaient quand même sur des détails sans enjeu. Le défaut vient donc de la relecture elle-même, pas des personnes.

3Les tests sont le produit, le code est jetable

Une porte mécanique a besoin d'une référence : le contrat. Pour le cours, un contrat décrit ce qu'un composant doit faire, sous forme de tests qu'on exécute (section 6). Une documentation se lit sans être obéie, un test non. L'exemple est une fonction de paiement avec une clé d'idempotence. Cette clé est un identifiant unique par demande, qui permet de reconnaître une demande envoyée deux fois :

• Une carte valide et un montant donnent un paiement réussi.
• La même clé envoyée deux fois renvoie le premier paiement, sans en créer un second.
• Une carte expirée renvoie l'erreur « card_expired », et rien n'est débité.

Le cours en tire une règle pour les incidents, à partir d'un cas. Un client est débité deux fois, parce qu'une coupure réseau a fait renvoyer la demande. Le réflexe serait de déboguer le code fautif. Le cours fait l'inverse. On écrit d'abord un test qui reproduit la panne : la même clé doit renvoyer le paiement existant en 50 millisecondes au plus. Puis l'agent réécrit le code de zéro. La nouvelle version doit passer les anciens tests et celui-là, sinon on la jette. Le cours le dit avec une image d'éleveur : le code est du bétail, pas un animal de compagnie. On remplace une bête sans la pleurer.

// Exemple imaginé, pas du livre : le test écrit après l'incident
public function testMemeCleRenvoieLePaiementExistant(): void
{
    $premier = $this->paiements->debiter('tok_visa', 4990, cle: 'cmd-1042');
    $second  = $this->paiements->debiter('tok_visa', 4990, cle: 'cmd-1042'); // la demande renvoyée
    $this->assertSame($premier->id, $second->id);           // le même paiement
    $this->assertCount(1, $this->banque->transactions());   // un seul débit
}

Le cours nomme lui-même la limite. Un test ne vérifie que ce qu'on a pensé à écrire. Un contrat reste un indicateur, et la loi de Goodhart le guette : quand une mesure devient un objectif, on optimise la mesure au lieu du but. La parade : compléter le contrat à chaque incident, pour qu'il colle peu à peu au vrai besoin.

4Un tutoriel bien écrit mais hors sujet trompe plus qu'un texte tiré au hasard

Seconde famille : organiser le travail, à commencer par ce qu'on donne à l'agent. Ce qu'il a sous les yeux s'appelle le contexte : votre demande, les fichiers collés, la conversation. L'exemple du cours parlera à tout développeur web (section 5). Une connexion à PostgreSQL expire, et le développeur colle tout le README de la bibliothèque qui sert à s'y connecter.

Le README est le fichier de présentation du projet, clair et bien écrit. Il parle aussi du chiffrement SSL et des transactions. Il décrit aussi le pool de connexions, c'est-à-dire les connexions gardées ouvertes pour être réutilisées. Chaque élément a ses délais d'attente. Le modèle les confond et conseille d'agrandir le pool. Avec la seule section de configuration et le message d'erreur, il trouve le vrai coupable : le réglage TCP keepalive, qui décide quand une connexion inactive est considérée comme morte.

Le cours généralise ce cas. Un tutoriel bien écrit mais hors sujet, comme ce README, dégrade la réponse plus qu'un texte tiré au hasard de même longueur. Un texte tiré au hasard ne ressemble à rien, donc le modèle l'ignore. Un tutoriel sur un sujet voisin partage le vocabulaire de la question, donc le modèle mélange les deux. D'où la formule : « Le tutoriel bien écrit est un piège. »

Le cours en tire trois gestes :

• Une tâche par échange, au lieu de six questions dans le même message.
• Dans un fichier de 4 000 lignes, donner les 200 lignes qui concernent la tâche.
• Poser la question de façon neutre : « analyse ce code pour repérer les problèmes » plutôt que « ce code a l'air correct, non ? ». Le modèle tend à confirmer la réponse qu'on lui souffle.

5Découper un système, c'est déjà le concevoir

Une tâche par échange suppose de savoir découper un gros travail en tâches. Le cours fait de ce découpage l'acte principal de la conception (section 7). En 1999, la NASA perd la sonde Mars Climate Orbiter, 327 millions de dollars. Lockheed Martin, qui l'a construite, livre ses données de poussée en livres-force-secondes. Le JPL (Jet Propulsion Laboratory, le laboratoire de la NASA), qui la pilote, attend des newtons-secondes, soit un facteur 4,45 d'écart. Aucune des deux équipes n'avait tort de son côté. La frontière entre elles manquait d'un contrat typé, qui force chaque valeur échangée à porter son unité. « La sonde n'a pas été perdue à cause d'une mauvaise ingénierie. Elle a été perdue à cause d'un mauvais découpage. »

Pour décider s'il faut découper, le cours pose trois questions :

• La capacité : un token est un morceau de mot, l'unité que compte le modèle. Si toute la spécification entre dans environ 10 000 tokens, on ne découpe pas. Le cours ne donne aucune source pour ce seuil.
• Le couplage : écrivez le contrat entre les deux morceaux. Si ce contrat demande un paragraphe pour s'expliquer, dit le cours, la frontière est sans doute au mauvais endroit.
• Le coût de l'erreur : si une frontière coûte cher à défaire, on attend de comprendre le domaine. C'est l'argument du monolithe d'abord, une seule application avant des services séparés.

Le cours ajoute un repère : regardez où la donnée change de forme, comme la requête brute reçue par le serveur web (HTTP) qui devient un objet métier validé.

6Un agent seul a eu 28 sur 28, un pipeline de onze agents zéro

Le découpage vaut aussi pour les agents, et le cours le met à l'épreuve (section 2). Même modèle, même tâche. Le pipeline disposait de 50 dollars, et l'agent seul a coûté à peu près autant que sa seule planification. La tâche : le backend d'une plateforme de réservation de locations de vacances, en 7 services indépendants. Seule change l'organisation du travail, avec quatre montages :

• Un agent seul : 28 sur 28, avec les 7 services bien raccordés.
• Une hiérarchie, un coordinateur qui délègue à des spécialistes : 18. Le coordinateur a fini par tout coder lui-même.
• Un essaim de 8 agents en parallèle sur des fichiers partagés, sans chef : 9.
• Un pipeline de onze agents spécialisés à la file, du diagnostic à la revue : 0.

Le pipeline a dépensé les 50 dollars en cinq étapes de planification, sans écrire une ligne de code. L'essaim a produit 152 fichiers, presque deux fois et demie ce qu'il a fallu à l'agent seul. Une moitié de ses agents écrivait les noms en snake_case (nom_du_client), l'autre en camelCase (nomDuClient), et aucun raccord entre services ne marchait.

Le résultat frappe, mais il faut le lire pour ce qu'il est. La note sur 28 additionne sept critères de conformité à la spécification. Le cours admet que c'est un indicateur, pas la qualité (section 11). Le texte ne dit ni le modèle employé, ni le nombre d'essais, ni qui a mené l'expérience. L'auteur prévient que ces montages ne représentent pas l'état de l'art. C'est une expérience marquante, pas une preuve. Le cours rapporte aussi un cinquième montage, avec contrats typés et tests à la place des relectures : il a évité les rejets absurdes, mais a épuisé son budget à écrire des spécifications de plus en plus longues. Un test n'est donc pas une baguette magique.

7Un test rouge coordonne mieux qu'une réunion

Reste le cas où la tâche dépasse un seul agent. Plusieurs agents doivent alors se coordonner, et le cours compare deux façons de le faire (section 9). La première est le dialogue : chacun parle avec chacun. La seconde s'inspire des termites. Leur termitière monte à quatre mètres sans qu'aucun termite n'ait le plan. Chacun réagit aux traces chimiques laissées par les autres. Le biologiste Pierre-Paul Grassé a nommé ce mécanisme en 1959. La stigmergie est la coordination par les traces que le travail laisse dans un environnement partagé.

Le cours chiffre la différence. Avec 8 agents en dialogue, chacun parle aux 7 autres : 8 × 7 = 56, et chaque canal compte deux fois, soit 28 canaux. À 50 personnes, on passe à 1 225. Par les traces, chaque agent fait une lecture et une écriture, quel que soit leur nombre.

En logiciel, les traces sont le dépôt de code, le tableau des tâches et l'intégration continue (CI). La CI relance les tests à chaque envoi de code et affiche vert ou rouge. Le scénario du cours : un développeur modifie le module de paiement, et un test du service de notifications passe au rouge. Un second développeur voit le rouge, lit l'échec et corrige l'analyse des réponses. Aucun message n'est passé entre eux. « La description d'un bug est une compression avec perte du bug. L'échec du test est le bug. »

Le cours n'en fait pas une solution miracle : deux agents peuvent réagir à la même trace, ou modifier le même fichier chacun à sa façon. Il garde une règle en trois cas (section 10) :

• La tâche entre dans le contexte d'un agent : un agent seul.
• Elle se découpe en morceaux peu liés : la coordination par les traces, tests et contrats.
• Elle demande un arbitrage ambigu (un compromis entre services, une priorité métier) : la hiérarchie, et seulement là.