Cleaning up after AI rockstar developers - Jesse Skinner
- Auteur
- Jesse Skinner
- Thème
- Leadership
- Mots-clés
- rockstar developer, technical debt, maintainability, AI code, legacy
- Ton
- opinion
Résumé
Jesse Skinner décrit le « rockstar developer » : énergique, brillant, plein d'idées d'architecture, qui réécrit le cœur du système avec du code que personne d'autre ne comprend — puis qui s'en va, laissant l'équipe ensevelie sous une base de code impossible à suivre. L'auteur, qui a passé sa carrière à nettoyer ces héritages, en dégage un schéma : ces développeurs adorent coder, apprendre et repousser leurs limites, et écrivent le code le plus malin possible, optimisé pour leur propre vitesse — pas pour la maintenabilité. Le parallèle avec le code généré par IA à grande vitesse est limpide.
💡 Pourquoi ça compte
Cet article transpose parfaitement le problème du « rockstar » au code généré par agents : malin, rapide, optimisé pour la vélocité du producteur, pas pour le mainteneur. Il donne un nom à la dette que l'accélération par IA risque d'industrialiser.
Analyse approfondie
Nous avons tous travaillé avec un rockstar developer. Il a rejoint l'équipe il y a des années, plein d'énergie. Il avait de grandes idées sur les nouvelles technos, les nouveaux paradigmes, les nouvelles architectures. Ses idées de pointe laissaient tous les autres avec un sentiment d'être un peu en retard et dépassés.
Il a réécrit l'essentiel de l'architecture cœur de l'entreprise. Il a introduit de nouveaux processus de build, de nouveaux outils, de nouveaux langages. Il rejetait la plupart des pull requests, relevant la barre de ce qu'on attendait de tous les autres. Personne ne comprenait le code qu'il écrivait, mais personne n'aurait admis ne pas comprendre.
Toutes les tâches les plus dures étaient assignées au rockstar. Il les finissait plus vite que quiconque. L'ingénierie sonnait toujours très impressionnant, même si le rockstar était le seul à savoir comment tout s'emboîtait.
Tous les autres avançaient bien plus lentement en comparaison. Tout le monde peinait à suivre, à apprendre les nouvelles librairies, et à faire les choses à la manière du rockstar.
Quelques années après son arrivée, soudain il était parti. Il s'était ennuyé, et voulait un meilleur poste sur un projet plus stimulant dans une plus grande entreprise.
Gérer les conséquences. Soudain, on vous demandait de reprendre les projets du rockstar. Vous avez plongé dans le code, et vous vous êtes retrouvé enseveli vivant. Le flux des données était si difficile à suivre qu'on aurait dit que quelqu'un essayait de couvrir un meurtre.
Vous avez commencé par essayer de corriger un bug simple. Rien que faire tourner le code sur votre laptop a pris une semaine.
La moitié du code était écrite dans un langage que vous ne compreniez pas. L'autre moitié utilisait des librairies dont vous n'aviez jamais entendu parler.
Vous avez tenté de dire à votre patron que le code avait besoin d'une réécriture. Il ne vous a pas cru, parce que c'était écrit par le rockstar lui-même. En pataugeant dans le slop, vous parcouriez les offres d'emploi en fantasmant sur un départ.
Nettoyer après un rockstar. J'ai travaillé avec de nombreuses équipes et agences qui avaient besoin de moi pour nettoyer après ces rockstars. J'adore en fait le défi d'essayer de comprendre et de sauver une base de code en pagaille. C'est comme s'asseoir avec une boîte de guirlandes de Noël emmêlées, et les démêler jusqu'à ce qu'elles soient de nouveau utilisables.
Au fil du processus, j'ai vu des schémas se dessiner. Ces rockstars adorent absolument coder, apprendre et utiliser de nouveaux paradigmes, et ça se voit. Ils se poussent toujours à la limite de leurs capacités, écrivant le code le plus malin qu'ils peuvent. Ils sont focalisés sur le fait d'aller le plus vite possible. (Le billet poursuit en montrant comment cette quête de cleverness et de vélocité produit une dette de maintenabilité — un parallèle direct avec le code généré par IA.)