De la discovery au merge, sans coder, en maîtrise.

Quand je travaillais chez Betclic, j'ai été embauché comme développeur front-end pour créer une nouvelle plateforme SaaS interne à destination des traders. J'ai longtemps été le principal contributeur du projet et son référent technique.

Puis je suis devenu engineering manager.

Hands off.

Je suis sorti du code pour manager une équipe dont le scope restait en partie sur cette application.

Et l'une de mes plus grosses tentations en tant qu'EM a été de vouloir continuer à peser sur le code. Dans les discussions techniques, je voyais l'équipe partir sur des choix architecturaux qui n'auraient pas forcément été les miens. Mais ce n'était plus mon rôle de dire comment faire. Mon rôle, c'était que le projet sorte, fonctionnel, dans les délais.

Alors j'ai appris à lâcher du leste. Si les solutions proposées, bien que pas les miennes, permettaient d'arriver à bon port, je m'effaçais. Il y a mille façons d'arriver à un résultat. Très vite, j'ai compris que mon équipe n'avait pas besoin de mes conseils techniques. Qu'ils me sollicitaient en cas de besoin. Et tout aussi vite, je n'ai plus ressenti la nécessité d'aller vérifier les PR.

Je vérifiais le résultat.

Et il était toujours satisfaisant.

Depuis, je suis revenu au code. Sauf que maintenant, c'est Claudio qui code. Moi, je l'oriente, je le brief, je le contrôle. Je le manage.

Et le déclic, c'est que ce job d'orchestrateur, je l'ai déjà appris une fois. Pas avec un agent. Avec une équipe de devs en chair et en os. Aujourd'hui je le rejoue. Pas le même médium mais presque la même posture.

Et le curseur de confiance avance vite.

Pas parce que l'agent est magique.

Parce que le dispositif qu'on a construit autour est solide.

C'est ce dispositif que je veux te raconter cette semaine.

Dans les numéros précédents, je t'ai parlé du curseur de confiance, du brief en amont, du lâcher prise pendant l'exécution. C'étaient des morceaux du puzzle.

Cette semaine, je dézoome. On regarde le flow complet.

De la discovery au merge.

En passant par les specs, le plan, le code, les tests, la review, la livraison, la documentation. Sans que je tape une ligne de code.

Et tout en maîtrise.

C'est ça la promesse du DAA (développement assisté par agent) quand il est mené à fond.

Pas "je délègue et je croise les doigts".

Mais plutôt: je déroule la chaîne complète en pilotant un dispositif, dont je vais te présenter chaque maillon.

Les deux premières étapes, je les ai déjà racontées dans les premiers numéros du Rebase. Le N°1 a posé l'enrichissement du brief (archi, sécurité, observabilité, anticipation des dashboards). Le N°2 a posé le lâcher prise une fois le brief solide.

En résumé : je reçois un ticket Linear. J'analyse, je projette les impacts, je discute avec Claudio, je le challenge, il me challenge. Il produit un plan d'implémentation en markdown. Je valide. Et là seulement il code.

Le brief, c'est mon travail. Le plan, c'est notre travail. Le code, c'est le sien.

Premier maillon du filet : les tests.

On connaît tous les vertus du TDD. Pas besoin d'argumenter.

Mais dans un contexte startup très concurrentiel, où il faut sortir la killer feature avant les concurrents, le TDD à la main est intenable. Au mieux on couvre les chemins critiques et on fait le minimum vital. Setuper des tests proprement, c'est lourd, c'est chronophage.

L'agent balaie cet argument.

D'une part, il sait monter un setup solide rapidement. D'autre part, il est meilleur, plus efficace, en méthode TDD. J’ai déjà évoqué les skills Superpowers : leur flow est full TDD. Pour chaque tâche, l'agent écrit d'abord les tests rouges qui couvrent les points du développement. Puis il implémente, joue ses tests, et ne ferme pas la tâche tant que tout n'est pas au vert.

Résultat : depuis que j'ai systématisé cette méthode, mon taux de bug a chuté. Les retours sont essentiellement fonctionnels, mais plus rarement techniques.

On a renforcé ça par des garde-fous CI. Un taux minimum de couverture imposé sur certains repos (tous ne s'y prêtent pas). Zéro erreur de lint, de compilation TypeScript, de build.

Et j'ai rajouté une règle perso pour Claudio : avant la moindre PR, il vérifie que sa branche est rebased sur origin/main, qu'elle compile, qu'elle passe le linter, que les tests sont verts. Pas d'exception.

Deuxième maillon : Claudio ne code pas seul. Il s'orchestre.

Quand le plan est validé, Claudio le découpe en phases et dispatche des sous-agents fresh, un par tâche, avec leur propre contexte isolé.

Un sous-agent implémente.

Un autre relit ensuite ce qu'il a fait, mais contre la spec uniquement, pour traquer le requirement manquant ou la feature en trop.

Si la spec est OK, un troisième sous-agent revoit la qualité du code : structure, nommage, lisibilité, taille des fichiers. Si ça coince à l'une des deux reviews, on reboucle vers l'implementeur jusqu'à ce que ce soit propre.

C'est un système qui ressemble beaucoup à une équipe avec un tech lead, des développeurs et des reviewers, sauf que tout tient dans une seule instance de Claude. Je consacrerai un numéro entier à ce système plus tard, parce qu'il mérite mieux que trois paragraphes. Pour aujourd'hui, retenons juste ça : Claudio n'est pas un dev solo, c'est déjà une mini-équipe.

Une fois le travail interne validé, Claudio crée la PR. Et là intervient le Lapin.

Le Lapin, c'est CodeRabbit. Un agent de review interfacé directement dans GitHub. Il a accès à nos repos, à nos tickets Linear, et il a une mémoire qui s'enrichit au fil de nos échanges.

Une fois la PR poussée, il déclenche automatiquement sa revue. Il lit le code, le met en contexte avec nos conventions, les CLAUDE.md, les règles métier. Il pose des commentaires inline quand il juge nécessaire. Au fil du temps, je dirais qu’il est devenu pertinent au moins neuf fois sur dix dès la première passe.

Et il s'améliore. Quand on lui répond, fix ou désaccord argumenté, il garde la trace. Il ne refait pas la remarque sur le même type de pattern dans une future PR. Il apprend nos conventions au lieu de les ignorer.

Mon rapport au Lapin a évolué par paliers.

Au début, je corrigeais moi-même chaque commentaire pertinent. Puis je me suis mis à utiliser le prompt qu'il propose à chaque suggestion : je le copiais-collais à Claudio, qui appliquait le fix. Puis je n'ai plus copié-collé : j'ai demandé à Claudio d'aller lire les commentaires lui-même et de juger leur pertinence.

Aujourd'hui, plus rien de tout ça. Mon skill /ship-feature prend en entrée un ticket Linear et orchestre tout, du brainstorming jusqu'à la boucle de réponse au Lapin. Une fois la PR créée, Claudio se met en mode loop. Toutes les quatre minutes trente (pourquoi cette durée ? Aucune idée, c'est lui qui me l'a proposée, j'ai dit OK), il vérifie si le Lapin a posté des commentaires. Si oui, il les analyse, fixe si pertinent, et lui répond de façon argumentée quand il n'est pas d'accord.

Toujours une réponse !

Jamais on ne laisse un commentaire en suspens.

Sans rien faire, je vois mon écran me notifier : "PR validée par CodeRabbit ✅".

Traditionnellement, dans notre équipe, quand on poussait une PR, on la partageait dans un canal Slack dédié et on attendait la validation d'un collègue.

Aujourd'hui, on continue à poster pour info. Mais la plupart d'entre nous, moi le premier, n'attend plus la validation systématique d'un humain. Il m'arrive d'aller solliciter directement la personne la plus compétente sur un sujet où je ne suis pas le plus à l'aise : indexes MongoDB, requêtes d'agrégation complexes, sujets infra pointus. À l'inverse, on me sollicite parfois sur des sujets front. C'est de la sollicitation experte, ciblée, pas de la review générique.

Le curseur de confiance dépend du dev, pas de l'agent. Sur les repos que je maîtrise, je merge seul. Sur ceux où je suis moins à l'aise, je vais chercher l'œil expert. Ce qui change, c'est qu'on a arrêté de faire passer toutes les PR par le même rituel par défaut.

Et pour être complètement transparent, je vais évoquer les incidents de prod qu'on a eus récemment. Oui, ça nous arrive. Toi jamais ? Menteur/se !!!

Bonne nouvelle : ils sont devenus plus rares à mesure que le DAA s'est généralisé chez nous.

Mauvaise nouvelle pour les anti-agents : tous ceux qu'on a connus dernièrement étaient exclusivement d'origine humaine. Aucun lié à un défaut de code généré.

La PR est mergée. C’est fini ? On passe au ticket suivant ?

Que nenni !

D'abord, la notion de "ticket suivant" n'existe plus vraiment chez moi. Pendant que Claudio code une feature, je brainstorme déjà la suivante, ou je relis le plan d'une troisième. J'ai ma petite batterie d'agents qui tourne en parallèle.

Ensuite, une fois mergée, je lance un autre de mes skills persos : /ship-Log.

Claudio va lire ce qui a été fait dans la branche, récupère le ticket Linear, la spec Notion si elle existe, et tout ce qu'on s'est dit pendant la session. Il rédige une page Notion structurée que je relis et que j'archive.

L'idée n'est pas de générer un changelog automatique de plus. L'idée, c'est de capturer le contexte qui se perd. Pourquoi cette feature existe. Quelle décision technique j'ai prise et pourquoi. Ce qui a cassé en route. Ce que je veux retenir pour la prochaine fois.

Le code raconte le quoi. Le ship-log raconte le pourquoi et le comment j'y suis arrivé.

Cette mémoire externe, elle sert trois publics.

D'abord moi dans trois mois, quand j'aurai oublié pourquoi tel pattern, pourquoi telle requête, comment checker ça dans Datadog.

Ensuite Claudio : quand on reprendra un dev sur la même thématique, il aura un contexte de grande qualité pour brieffer la suite.

Enfin, à terme, les collègues qui hériteront du code ou voudront comprendre une décision sans archéologie de repo.

Pour l'instant, le ship-log est une initiative perso. Je compte bientôt en faire profiter l'équipe. Et là aussi, ça mérite un numéro à part entière, dans lequel je détaillerai le gabarit.

Bientôt.

On a déroulé le flow complet. Discovery, brief, plan, code, tests, review, merge, doc.

Et sans taper une ligne de code.

Et tout en restant en totale maitrise de ce qui est livré.

C'est ça la mutation qui s'opère. Le dev qui déroule ce flow sans coder n'a pas perdu en maîtrise.

Il en a déplacé la nature.

Avant : la maîtrise passait par l’écriture du code.

Aujourd'hui : elle passe par l'orchestration du dispositif.

Et le dispositif est exigeant. Brief solide. Tests sérieux. Sous-agents bien rôdés. Lapin bien dressé. Ship-log discipliné. À chaque maillon, le dev fait un choix, pose une règle, valide une sortie. Si un maillon casse, c'est lui qui le détecte et le répare.

Le curseur de confiance peut aller loin parce que le dispositif est solide. Pas parce que l'agent est magique.

Le code est devenu commodité, la review aussi. Ce qui reste pleinement humain, c'est l'orchestration du flow complet, du premier brief à la dernière trace écrite. C'est ça, le Développement Assisté par Agent. Pas une délégation. Une nouvelle façon d’exercer notre métier.

Si cette vision te parle, transfère ce mail à un dev que ça pourrait intéresser. C'est le meilleur moyen de faire grandir Le Rebase.