AI brain fry
Oyez, oyez ! Un mot désigne enfin ce que tout le monde ressent confusément depuis des mois, à des degrés divers : AI brain fry.
Alors que vous êtes censé mener 5 refactorings et 5 features en parallèle, vous finissez par en faire avancer 1 mollement et échouez sur Instagram en attendant que le LLM vous rende la main. Petit sentiment de dégoût en fin de journée.
Cela vous semble familier ? Rassurez-vous, vous êtes humain, et vous êtes fatigué.
Tandis que nous prenons la mesure des possibilités offertes par les LLMs, la nature-même du travail de développeur évolue, ce que j’évoquais dans un récent article intitulé « Vous voilà manager, que ça vous plaise ou non ». Certains prédisent que développer consistera bientôt à lancer 10 agents en parallèle sur des sujets différents, pour valider ensuite le résultat d’un simple coup d’œil. Dans les faits, on n’en est pas là, parce que l’humain reste le facteur limitant.
Relire autant de code est épuisant, car il faut à chaque fois s’imprégner d’une logique qui n’est pas la nôtre. Certains diront qu’il est plus facile de réagir (critiquer du code) que d’agir (créer du code), pourtant je constate que peu de personnes souhaitent ardemment relire 20 pull requests par jour.
Et puis il y a le context switching. Chacun sait à quel point il est difficile de se ménager des plages de deep work, surtout quand on exerce une responsabilité à mi-chemin entre la contribution individuelle et le management d’équipe (ex : Lead Developer). Le context switching quand vous menez 10 sujets de front, ce n’est tout simplement pas possible.
Il faut ensuite s’attaquer au mythe de la productivité. On sait tous d’expérience que le repos est essentiel à la créativité, et les neurosciences ne disent pas autre chose. C’est souvent lorsque le regard se perd au loin sans penser activement au sujet que jaillissent les meilleures idées. Et quand, parfois, une fenêtre de créativité intense s’ouvre à vous durant 3 ou 4 jours, il n’est pas rare d’en payer le contre-coup les jours suivants. Une telle productivité ne peut donc être qu’éphémère, notre cerveau a besoin de repos.
Mais, plus profondément, c’est la nature-même du travail qui est concernée. La valeur d’un développeur expérimenté réside dans sa capacité à alterner entre le microscopique (la ligne de code) et le macroscopique (l’architecture, à l’échelle de la codebase, mais aussi l’organisation). C’est, dans un sens, la capacité à traduire une simple idée en un logiciel fonctionnel et, dans l’autre, l’expérience du fait qu’un simple détail peut tout changer, voire tout compromettre. Ce savoir s’acquiert par l’expérience. C’est pourquoi certaines décisions très structurantes ne devraient être prises que par les personnes qui sont activement impliquées dans le développement, ce que Vincent Lextrait appelle le mentofacturing.
Cette intrication du macroscopique et du microscopique constitue selon moi une limite importante au développement assisté par LLM. Si vous tenez à la qualité, vous devez rester en prise avec le code, et probablement écrire certaines parties bien spécifiques par vous-mêmes (parce qu’elles sont critiques ou pour servir d’exemple au LLM). Exemple récent : algorithme d’exécution d’ordres d’achats/ventes sur les marchés.
Moi, je ne sais pas faire ça sur 10 sujets en parallèle.