DEV Community

Cover image for Développeurs dépossédés : visiteurs de notre propre code
Karkael
Karkael

Posted on

Développeurs dépossédés : visiteurs de notre propre code

#llm #productivity #devjournal #french

Version originale en anglais : https://dev.to/karkael/my-llms-write-all-my-code-i-dont-even-open-it-anymore-5ekc

Avant-propos : la sortie de secours est murée

Commençons par la fin, c'est plus honnête. Si demain je devais quitter les LLM — pour des raisons politiques, un déni de service prolongé, ou simplement parce que la facture deviendrait indécente — il me faudrait une étape de nettoyage massive pour reprendre possession de mon propre code. Aujourd'hui, j'estime que 60 % du code de mes projets est devenu illisible pour un humain, et cette portion grossit à chaque orchestration. Est-ce que quitter les LLM est envisagé ? Non. Bien sûr que non. C'est exactement ça, le problème.

Il était une fois un moteur de recherche amélioré

Tout a commencé innocemment. Des questions posées comme à Google, mais avec des réponses en phrases complètes. Puis des rédactions ciblées de code : « écris-moi cette fonction », « corrige ce test ». Puis des audits entiers de modules.

À ce stade, j'avais trouvé la bonne grille de lecture : les LLM sont des agents polyvalents, non-experts et démultipliables. Ni brillants, ni nuls, mais disponibles en quantité illimitée. Et c'est parfait pour toutes les tâches où je suis moi-même novice : organiser, planifier, produire la bureautique de chef d'équipe que personne ne m'a jamais apprise. Comptes-rendus, roadmaps, matrices de priorisation — l'agent non-expert fait ça mieux que moi, et il ne soupire pas.

Le vibecoding : trois essais, trois échecs, zéro leçon retenue

Distinguons d'abord les termes, parce que tout le paradoxe de cette histoire tient à cette frontière. Le développement assisté LLM : la machine génère, mais chaque incrément est relu par le développeur avant d'être intégré. Le vibecoding : rien n'est vérifié — au mieux, on valide le fonctionnel en exécutant l'application en local et sur l'environnement develop, et on appelle ça une revue.

J'ai tenté le vibecoding trois fois. Trois fois, le résultat ne correspondait à aucune architecture efficiente ou relisible. Les tentatives de branchement du code généré sur l'existant ont échoué. La seule chose qui a fonctionné : des changements radicaux, des réécritures complètes, pour finalement obtenir un code propre.

Cette fois, j'ai tiré la bonne conclusion : arrêter de vibecoder, et ne faire que du développement assisté LLM. Chaque incrément relu, chaque changement validé. Une résolution d'adulte. Retenez-la bien, elle ne va pas survivre longtemps.

L'escalade : MCP, skills, et l'option qui porte bien son nom

Alors l'usage s'est intensifié. Des serveurs MCP pour brancher les agents sur les outils. Des skills pour encoder les procédures. Des agents spécialisés, des automatisations, et — je le confesse en le tapant — le drapeau --dangerously-skip-permissions, dont le nom est un avertissement que j'ai choisi de lire comme une invitation.

Point d'orgue : une orchestration complète via Orca et ses git worktrees. Plusieurs agents en parallèle, chacun dans son worktree, qui fusionnent leur travail pendant que je fais autre chose.

Mon nouveau métier : arbitre à temps très partiel

Aujourd'hui, mon travail consiste à vérifier que les orchestrations se sont bien passées, et à répondre aux questions des LLM pour trancher sur l'infra ou le métier — uniquement quand l'agent doute de lui-même. Quand il est sûr de lui, j'ignore la plupart de ses changements.

Et c'est là que le paradoxe se referme. Ma grande résolution post-échecs — chaque incrément relu, jamais de vibecoding — n'a pas survécu à l'escalade des responsabilités confiées aux LLM. À force de déléguer toujours plus haut dans la chaîne, je me retrouve exactement dans l'état que j'avais juré de fuir : je ne vérifie plus le code. Je n'ai pas rechuté dans le vibecoding, je l'ai réinventé avec plus d'étapes. Je relis le code de mes agents à peu près aussi attentivement que les CGU d'une mise à jour d'application.

Le prix : un code écrit par des LLM, pour des LLM

À force de m'abstraire du code, le code s'est abstrait de moi. Il est devenu beaucoup plus verbeux, saturé de commentaires qui expliquent l'évident. Mais le plus dérangeant est ailleurs : les bonnes pratiques ont complètement changé sans que personne ne les décide. Face à des spécifications jamais précisées, les LLM ont tranché seuls — conventions, structures, patterns. Le résultat est un code fortement illisible pour un humain, et qui n'est désormais propice… qu'au vibecoding. La boucle est bouclée : le code généré par les LLM ne peut plus être maintenu que par des LLM.

Et pendant ce temps, le backlog

Soyons factuel une seconde : le travail achevé n'est pas plus conséquent. Le fonctionnel et l'architecture n'ont pas avancé plus vite. Les tickets urgents ne sont toujours pas dépilés depuis deux mois. J'ai multiplié les agents, pas les résultats.

Et ce détail n'en est pas un, parce que nous travaillons en méthode Agile. Toute notre culture d'équipe repose sur le résultat avant tout : la valeur livrée, le partage, l'évolution du produit, le collectif. C'est le pacte fondateur. Or que disent les indicateurs ? Les KPIs montrent un travail à vitesse mitigée — et ces chiffres ne dorment pas dans un tableau de bord ignoré : ils sont vus et relus par la direction, sprint après sprint. L'ironie est complète : nous avons industrialisé la production de code au nom de la vélocité, et la vélocité est restée là où elle était. Nous avons optimisé l'activité, pas le résultat. En Agile, c'est précisément la définition de l'échec — un échec très occupé, très outillé, et parfaitement documenté par nos propres métriques.

Conclusion : une fainéantise confortablement outillée

Ce que raconte vraiment cette histoire, c'est une certaine fainéantise — la mienne, la nôtre — à produire un code propre, concis, aligné sur les bonnes pratiques choisies par l'équipe. Cette rigueur-là demande un effort que nous avons délégué avec soulagement. Pendant que les LLM s'implantent toujours plus profondément dans le code, les développeurs n'ouvrent même plus leur IDE.

Le code est encore à nous sur le papier. Dans les faits, nous en sommes devenus les visiteurs.

Et vous, ouvrez-vous encore votre IDE ?

Lectures liées

Pour creuser — dans mon sens, et dans l'autre :

Top comments (0)