Des agents IA à la place du vibe coding : comment un pipeline autonome mène une tâche jusqu'à la PR

Une analyse du vibe coding ramène le problème à une idée simple : les modèles déraillent non parce qu'ils écrivent mal le code, mais parce qu'on leur donne des bribes de contexte. Plutôt qu'une énième série de prompts « magiques », l'auteur propose un schéma opérationnel où les agents reçoivent de la structure, se vérifient les uns les autres et mènent la tâche jusqu'à la PR presque sans intervention humaine.

Là où tout casse

Dans le scénario type, le développeur lance une tâche dans un chat, obtient une belle réponse et attend du modèle qu'il comble seul tous les détails manquants. Sur un court périmètre, cela fonctionne parfois, mais sur un vrai projet les lacunes apparaissent vite : l'agent ignore les contraintes du dépôt, ne voit pas les accords d'architecture, ne comprend pas l'objectif métier et ne se souvient pas des décisions passées de l'équipe. D'où l'impression que le vibe coding est instable : une fois il livre un bon résultat, la suivante il casse le build, se heurte au style de code et se perd dans les détails.

La thèse principale de l'analyse est que le problème n'est pas une IA faible, mais un mauvais conditionnement de la tâche. Un beau prompt système ne remplace ni les documents, ni les exemples, ni l'état du dépôt, ni l'historique des discussions, ni des critères d'acceptation clairs. Si le modèle ne reçoit que la phrase « fais la fonctionnalité », il se met à improviser là où il faudrait un appui précis. Le contexte n'est donc pas ici un complément agréable, mais une part entière du processus d'ingénierie.

Trois niveaux de maturité

L'auteur décrit le chemin que suivent généralement les équipes qui tentent d'intégrer l'IA au développement. À chaque niveau, ce n'est pas seulement la qualité des réponses qui progresse, mais aussi le degré de formalisation du travail lui-même. Moins il y a de magie manuelle et d'indications aléatoires, plus on a de chances d'obtenir un résultat reproductible qu'on ne rougit pas d'envoyer en production, ou au moins en relecture sérieuse. C'est la formalisation qui transforme une expérience avec l'IA en outil répétable.

• Le premier niveau est un chat isolé avec un long prompt, où le résultat dépend entièrement de la justesse de la formulation trouvée par la personne.
• Le deuxième niveau consiste à connecter le dépôt, les fichiers, les règles du projet et des modèles de tâches, afin que l'agent voie le contexte de travail et pas seulement une description textuelle.
• Le troisième niveau est un pipeline autonome à plusieurs rôles, où certains agents planifient, d'autres écrivent le code, et d'autres encore relisent et renvoient des remarques.
• La dernière étape est la livraison du résultat fini sur un canal pratique, par exemple Telegram, pour que l'humain n'intervienne qu'aux points de contrôle.

La différence entre ces niveaux n'est pas cosmétique. Au premier, l'IA ressemble à un jouet pour esquisses rapides. Au deuxième, elle devient un assistant utile au sein d'un vrai projet. Au troisième, elle s'intègre à une chaîne de production, où ce qui compte n'est plus une réponse isolée du modèle, mais la façon dont sont organisés la transmission du contexte, la vérification des hypothèses et l'échange de remarques entre agents. C'est pourquoi l'auteur se montre sceptique face à l'idée qu'un prompt parfait puisse tout résoudre d'un coup.

Comment fonctionne la boucle

Dans le schéma proposé, l'utilisateur formule la tâche et peut littéralement fermer son ordinateur ensuite. La boucle prend alors le relais : un agent décompose la demande, rassemble les fichiers pertinents et établit un plan ; un deuxième implémente les modifications ; un troisième joue le rôle de relecteur et cherche les points faibles ; au besoin, les agents débattent entre eux et affinent la solution jusqu'à obtenir une version digne d'une pull request. Ce processus ressemble davantage à une petite équipe qu'au « question-réponse » habituel dans une seule fenêtre.

L'intérêt pratique est que l'autonomie repose non sur la liberté du modèle, mais sur la discipline du processus. On fixe d'avance aux agents les rôles, les sources de contexte, le format des artefacts et les règles d'escalade. Si le relecteur trouve un problème, la tâche ne meurt pas dans le chat, elle retourne dans le cycle de correction. Si toutes les vérifications passent, le système envoie la PR et une notification sur Telegram. Pour le développeur, cela suppose un changement de rôle : moins de micromanagement manuel, plus de pilotage des exigences, du contexte et des points de contrôle.

Ce que cela signifie

L'analyse montre bien où se déplace l'IA pratique dans le développement. La valeur quitte peu à peu les démos spectaculaires pour aller vers l'infrastructure de contexte et les processus en plusieurs étapes. Pour les équipes, c'est le signal de revoir non seulement leurs prompts, mais aussi la façon dont elles conservent la connaissance du projet, décrivent les tâches et intègrent les agents IA dans le cycle de développement ordinaire. Gagneront ceux qui sauront bâtir un environnement de travail autour du modèle plutôt que d'espérer une formulation heureuse.