Vibe Coding Cleanup Specialist : le métier qui nettoie les projets codés par IA
Le vibe coding est redoutablement efficace pour démarrer un projet. Une idée, quelques prompts, et l'application prend forme à une vitesse difficile à obtenir en codant tout à la main. Puis arrive un moment que je rencontre souvent sur mes propres projets : le code grossit, les dépendances se multiplient et l'agent commence à perdre la vision d'ensemble. Il sait encore produire du code. Il peut même réaliser un bon refactoring. Mais pour le faire correctement, il doit relire une partie importante du dépôt, reconstruire les dépendances, retrouver les règles métier et lancer les tests. Le coût en contexte et en tokens augmente fortement. C'est dans cet espace qu'apparaît le terme Vibe Coding Cleanup Specialist : un développeur qui reprend les prototypes générés avec l'IA pour leur redonner une architecture cohérente, des tests et un code maintenable.
Le Vibe Coding Cleanup Specialist n'est pas encore un métier officiel
Le terme circule sur des profils de développeurs, des offres de services et des publications consacrées au développement assisté par IA. Il décrit moins un nouveau métier parfaitement défini qu'une spécialisation d'un travail déjà connu : audit de code, refactoring, sécurisation, ajout de tests et remise à plat d'une architecture devenue difficile à maintenir.
Le changement vient de l'origine du problème. Le développeur n'arrive plus forcément après plusieurs années de dette technique accumulée par une équipe. Il peut intervenir après quelques semaines de vibe coding intensif, sur une application qui a grandi beaucoup plus vite que sa structure.
Le prototype fonctionne. Les écrans existent. Les fonctionnalités principales répondent. Pourtant, modifier une règle métier commence à déclencher des régressions ailleurs. Des fonctions proches apparaissent dans plusieurs dossiers. Des conditions compensent d'anciennes conditions. L'application reste utilisable, mais chaque nouvelle demande devient plus coûteuse.
Le problème apparaît quand le projet dépasse le contexte facile à reconstruire
Sur un petit projet, un agent de code peut rapidement lire les fichiers importants et comprendre leurs relations. Cette phase donne une impression de fluidité : il crée une route, modifie un composant, ajoute un appel API et corrige les erreurs dans la même session.
Quand la base grossit, comprendre l'existant devient une tâche à part entière. L'agent doit rechercher les fichiers concernés, suivre les imports, retrouver les abstractions existantes, lire les tests et reconstituer les conventions du dépôt. Même avec une grande fenêtre de contexte, tout charger en permanence n'est ni gratuit ni nécessaire.
Le risque n'est donc pas uniquement que l'IA écrive du mauvais code. Une modification peut être correcte localement et mauvaise à l'échelle du projet. L'agent peut recréer une fonction déjà présente, ajouter une exception là où il faudrait modifier le modèle de données ou résoudre un problème dans trois fichiers alors qu'une abstraction commune existe déjà.
Des travaux publiés en 2026 sur le développement agentique décrivent un phénomène proche : les agents donnent de meilleurs résultats lorsque les contraintes, le contexte métier et l'architecture sont explicités avant l'implémentation. L'effort du développeur se déplace alors de l'écriture du code vers la préparation et la vérification du cadre dans lequel l'agent travaille.
Un bon refactoring par IA reste possible, mais il consomme du contexte
Dire que l'IA devient incapable de travailler sur un gros projet serait faux. Je lui fais régulièrement réaliser des refactorings efficaces. La différence se voit dans le coût de préparation.
Pour nettoyer correctement une base importante, l'agent doit parfois cartographier plusieurs dossiers, rechercher les doublons, comprendre les appels croisés, identifier les tests concernés puis vérifier que ses changements n'ont pas modifié une règle métier. Plus la tâche touche de composants, plus le nombre de lectures, de recherches et d'itérations augmente.
Cette dépense n'est pas forcément un problème. Un refactoring qui aurait occupé un développeur plusieurs heures peut rester rentable avec un agent. Mais elle casse l'idée du vibe coding comme boucle infinie où il suffirait de demander une fonctionnalité après l'autre. À mesure que le projet grandit, il faut investir davantage dans la compréhension avant de produire davantage de code.
AGENTS.md peut transformer des habitudes de développement en règles pour l'agent
Une des pratiques qui m'aide le plus consiste à utiliser AGENTS.md comme garde-fou. Plutôt que de rappeler les mêmes consignes à chaque session, j'y écris les vérifications que l'agent doit effectuer avant et après une modification.
Dans mes projets, j'impose notamment de chercher une implémentation équivalente avant de créer une nouvelle fonction et de lancer les tests métier concernés. Ce sont des règles simples, mais elles attaquent deux sources fréquentes de dérive : la duplication et les régressions silencieuses.
Codex prend officiellement en charge ces fichiers. Un AGENTS.md peut indiquer comment naviguer dans le dépôt, quelles conventions suivre et quelles commandes de test exécuter. Les fichiers peuvent aussi être placés plus profondément dans l'arborescence afin d'appliquer des instructions propres à une partie du projet.
Il faut toutefois éviter de transformer le fichier racine en manuel de 200 pages. Son rôle est de donner des règles stables et une carte permettant de trouver le reste de la documentation. Charger systématiquement des informations inutiles recrée le problème que l'on cherchait à résoudre.
L'ossature du dépôt compte davantage quand une IA écrit une grande partie du code
L'autre pratique qui change nettement mes résultats consiste à construire l'ossature du dépôt avant de lancer la génération massive. Les responsabilités des dossiers, les couches principales et les frontières entre modules sont décidées tôt. L'agent complète ensuite ce cadre au lieu de réinventer l'architecture à chaque fonctionnalité.
Cela favorise des fichiers cohésifs, avec une responsabilité identifiable, et des modules qui peuvent être compris avec peu de dépendances externes. Un agent chargé de modifier la facturation devrait pouvoir ouvrir le module de facturation, ses interfaces et ses tests sans devoir lire toute l'application.
Il ne faut pas confondre cette approche avec une course au fichier le plus court. Fragmenter une opération métier en vingt-cinq fichiers minuscules peut coûter autant de contexte qu'un fichier gigantesque. Le meilleur découpage est celui qui permet de comprendre une fonctionnalité en ouvrant un petit ensemble prévisible de fichiers.
Cette idée rejoint une règle ancienne du génie logiciel : forte cohésion, couplage limité et responsabilités explicites. Les agents de code lui donnent une nouvelle conséquence économique. Une architecture lisible ne réduit plus uniquement la charge cognitive des humains. Elle réduit aussi le volume de contexte que l'IA doit reconstruire.
Les tests métier deviennent la mémoire exécutable du projet
Les tests prennent une valeur particulière dans un projet fortement assisté par IA. Un commentaire peut devenir obsolète et une documentation peut être ignorée. Un test qui échoue donne immédiatement à l'agent une information exploitable.
Les plus utiles ne vérifient pas uniquement qu'une fonction renvoie la bonne valeur. Ils décrivent les invariants du produit : un utilisateur dont l'abonnement est expiré ne reçoit plus sa remise, une commande annulée ne peut plus être facturée, un changement de statut déclenche tel comportement.
Ces tests servent alors de mémoire exécutable des règles métier. L'agent n'a pas besoin de deviner toutes les intentions historiques du développeur. Il peut modifier le code, exécuter la suite et constater qu'une règle qu'il n'avait pas identifiée vient d'être cassée.
Une étude exploratoire publiée en juillet 2026 sur vibe coding et Test-Driven Development observe justement que les workflows agentiques peuvent produire rapidement du code fonctionnel tout en ajoutant des décisions d'implémentation qui n'étaient pas explicitement demandées. Les auteurs insistent sur la valeur de tests mieux structurés pour encadrer ces décisions.
Le développeur devient aussi architecte du contexte
Le Vibe Coding Cleanup Specialist est amusant comme intitulé, mais le phénomène qu'il décrit est plus large. Utiliser davantage d'IA ne supprime pas le besoin d'ingénierie logicielle. Cela change l'endroit où cette ingénierie produit le plus de valeur.
Une partie du travail se déplace vers la définition de frontières claires, l'écriture de règles vérifiables, la création de tests, la documentation des décisions et la préparation du contexte nécessaire à l'agent. Autrement dit, le développeur ne structure plus uniquement le logiciel. Il structure aussi la manière dont l'IA pourra comprendre ce logiciel demain.
C'est peut-être la meilleure façon d'éviter d'avoir besoin d'un cleanup specialist après coup : ne pas attendre que l'application soit devenue opaque. Donner dès le départ à l'agent un dépôt dans lequel les responsabilités sont visibles, les règles métier testables et les chemins de recherche prévisibles.
Sources
- OpenAI, Introducing Codex : fonctionnement des fichiers
AGENTS.md, portée des instructions et importance d'un environnement de développement et de tests bien configuré. - OpenAI, Unrolling the Codex agent loop : chargement des instructions de projet et limites appliquées au contexte des fichiers d'instructions.
- Mise en Place for Agentic Coding : proposition d'une méthode de préparation du contexte avant implémentation avec des agents de code.
- Context Before Code : retour d'expérience sur l'importance des contraintes architecturales explicites dans des projets développés avec l'IA.
- Vibe Coding: An Experiment with Test-Driven Development : étude exploratoire sur le vibe coding, le TDD et les décisions supplémentaires introduites par des workflows agentiques.
- Fiverr, Vibe Coding Cleanup Specialist : exemple concret d'un développeur commercialisant ses services sous cet intitulé.
Qu'est-ce qu'un Vibe Coding Cleanup Specialist ?
C'est un développeur qui reprend une base de code créée en grande partie avec une IA afin de la rendre plus maintenable, cohérente, testée et adaptée à la production. Le terme est encore informel et décrit surtout une spécialisation du refactoring et de la maintenance logicielle.
Pourquoi un projet codé avec l'IA devient-il plus difficile à maintenir en grandissant ?
Parce que l'agent doit reconstruire de plus en plus de contexte avant chaque modification : architecture, dépendances, règles métier, abstractions existantes et tests. Une modification correcte dans un fichier peut devenir incohérente à l'échelle du projet si ce contexte manque.
À quoi sert AGENTS.md dans un projet Codex ?
AGENTS.md permet de fournir à Codex des instructions persistantes sur l'organisation du dépôt, les conventions à respecter et les tests à exécuter. Des fichiers placés dans des sous-dossiers peuvent fournir des règles plus locales à une partie du projet.
Faut-il utiliser de très petits fichiers pour aider les agents de code ?
Pas systématiquement. Le meilleur objectif est d'avoir des modules cohésifs qui peuvent être compris avec peu de fichiers et peu de dépendances externes. Trop fragmenter le code peut augmenter le nombre de fichiers que l'agent doit ouvrir et produire l'effet inverse.
Quels tests sont les plus utiles avec du code généré par IA ?
Les tests métier sont particulièrement utiles car ils décrivent les comportements que l'application doit préserver. Ils permettent à l'agent de détecter une régression même lorsqu'il n'avait pas identifié la règle métier concernée en lisant le code.
