--dangerously-skip-reading-code

L'auteur prolonge un précédent billet où il affirmait qu'il serait irresponsable de supposer qu'on n'aura plus jamais à lire ni à déboguer notre code — de croire que tout problème surgissant pourra être corrigé par les LLM. Jusqu'ici, c'était le travail du programmeur de comprendre et maintenir le code source, comme proxy de la compréhension et de la maintenance du système logiciel. Nous sommes tenus pour responsables de ce que produisent les LLM.

Mais, demande-t-il, et si ce n'était plus le cas ? Et si, après avoir dûment communiqué les risques et les arbitrages à la direction, celle-ci décidait quand même de prendre ces risques ? Rien d'inédit : les entreprises, surtout les startups tech, font régulièrement des compromis de court terme pour gagner en productivité, devancer la concurrence, séduire des investisseurs.

S'il existe un mandat organisationnel pour minimiser le temps passé à coder grâce aux LLM, c'est une nouvelle contrainte avec laquelle composer. On peut alors définir ce qu'est un bon travail d'ingénierie dans ce contexte. On peut cesser de lire le code généré par les LLM, exactement comme on ne lit pas l'assembleur, le bytecode ou le JavaScript transpilé : notre code source en langage haut niveau devient une autre forme de code machine.

Ce déclic est venu à l'auteur après la lecture du rapport de retraite de Thoughtworks. Les LLM produisent une sortie non déterministe et génèrent du code bien plus vite qu'on ne peut le lire ; on ne peut donc plus sérieusement espérer revoir, comprendre et approuver chaque diff. Mais cela ne signifie pas qu'on cesse d'être rigoureux : cela peut vouloir dire qu'il faut déplacer la rigueur ailleurs.

Point fondamental : ce n'est ni le choix d'un individu ni celui d'une équipe. Ce doit être une décision organisationnelle — non seulement pour des questions de gestion du risque et de responsabilité, mais aussi à cause de la loi d'Amdahl. Si l'on ne maximise que la vitesse de génération de code sans réorganiser les structures et les processus dans lesquels s'inscrit le travail, il n'y aura aucun gain de productivité tangible.

On ne peut pas avoir des devs qui pondent 20 000 lignes de « slop » par jour et attendre des autres qu'ils les lisent, les comprennent, et encore moins les approuvent. On ne peut pas tirer parti des agents si notre unité de travail reste « ajouter un endpoint à l'API REST ». On ne peut pas attendre d'un Product Owner qu'il alimente assez de travail pour occuper une équipe « two-pizza » si chaque ingénieur peut prendre quatre tâches à la fois et faire tourner des agents en dehors des heures.

La conclusion est structurelle : il faut retirer les humains-dans-la-boucle, réduire la coordination, la friction, la bureaucratie et le gatekeeping. Il faut un approvisionnement quasi infini d'exigences, des ingénieurs agissant comme des pseudo-designers produit, propriétaires de flux entiers de travail, avec le pouvoir de prendre des décisions autonomes.