« Tu es un ingénieur très expérimenté qui effectue une revue de code. Ta tâche est de comprendre si les changements proposés suivent les instructions. »

Ainsi débute un des prompts système que Spotify a définis dans le cadre de son architecture de codage agentique.

L’entreprise avait amorcé sa réflexion à ce sujet en février 2025. Son système Fleet Management automatisait alors déjà une grande partie de la maintenance logicielle. À partir d’extraits de code, il exécutait les transformations à l’échelle dans un environnement GKE et ouvrait les PR sur les dépôts cibles.

Ce mécanisme facilitait des opérations telles que la mise à niveau des dépendances dans les fichiers de build, la mise à jour des fichiers de configuration et le refactoring simple (par exemple, supprimer ou remplacer un appel de méthode). La moitié des PR poussés depuis mi-2024 l’avaient été par ce biais.

Fleet Management était moins adapté aux changements complexes nécessitant de manipuler l’arbre de la syntaxe abstraite d’un programme ou d’utiliser des expressions régulières. Illustration avec le gestionnaire de dépendances Maven. Autant sa fonction principale est simple (identifier les fichiers pom.xml et mettre à niveau les dépendances Java), autant les cas particuliers avaient fait grossir à plus de 20 000 lignes le script de transformation associé. Plus globalement, peu d’équipes avaient l’expertise et le temps adéquats.

Un premier focus sur la migration de code

La mise en place de l’approche agentique s’est d’abord portée sur la déclaration du code de transformation. Objectif : permettre la définition et l’exécution de changements en langage naturel, en remplacement des scripts de migration déterministes.

Plutôt que de choisir un agent sur étagère, Spofity a conçu un CLI. Celui-ci peut déléguer l’exécution d’un prompt à divers modèles d’IA. Mais aussi exécuter des tâches de formatage et de linting en utilisant MCP, évaluer une diff par LLM as a judge, uploader des logs vers GCP et capturer des traces dans MLflow.

Début novembre 2025, quelque 1500 PR fusionnés étaient passés par ce système. Spotify s’attaquait alors à des opérations telles que :

• Modernisation de langage (par exemple, remplacer des value types par des records en Java)
• Upgrades sans breaking changes (migration de pipelines data vers la dernière version de Scio)
• Migration entre composants UI (passage vers le nouveau système front-end de Backstage)
• Changements de configuration (mise à jour de paramètres dans des fichiers JSON et YAML en respectant schémas et formats)

Spotify disait alors avoir gagné, sur ces tâches de migration, 60 à 90 % de temps par rapport à l’écriture du code à la main. Il se projetait sur l’amélioration du ROI avec la perspective de l’élargissement à d’autres codebases.

Slack, Jira et C^ie intégrés dans une architecture agentique

En complément à cette démarche sur la migration, les travaux se sont orientés sur un système plus généraliste, capable de remplir des tâches ad hoc. On en est arrivé à une architecture multiagent qui planifie, génère et révise des PR.

Au premier niveau, il y a des agents associés à différentes applications (Slack, Jira, GitHub Enterprise…). L’interaction avec eux, éventuellement additionnée de contexte récupéré sur des serveurs MCP, produit un prompt. Ce dernier part vers l’agent de codage, lui aussi exposé par MCP. Ses actions sont vérifiées par un autre groupe d’agents.

Entre autres usages « satisfaisants », Spotify mentionne la capture de décisions d’architecture depuis des threads Slack et la possibilité, pour les product managers, de proposer des changements simples sans avoir à cloner de dépôts sur leur machine.

Des agents open source à Claude Code

Les premiers essais se sont faits avec des agents open source comme Goose et Aider. Appliqués à la migration, ils n’ont cependant pas produit de PR fiables. Spotify a donc construit sa propre boucle agentique superposée aux API de LLM. Principe : l’utilisateur fournit un prompt et une liste des fichiers que l’agent édite en incorporant à chaque étape le feed-back du système de build. La tâche s’achève quand elle réussit les tests ou qu’elle dépasse certaines limites (10 tours par session ; 3 retries).

Cette approche a convenu à de « petits » changements : éditer une ligne de code, modifier un manifeste, remplacer un flag… Mais l’agent restait difficile à utiliser. Le chargement des fichiers dans la fenêtre de contexte reposait sur une commande git-grep. En fonction de pattern de recherche, on pouvait saturer la fenêtre ou au contraire ne pas fournir assez de contexte. L’agent avait de plus du mal avant l’édition de multiples fichiers. Souvent, la boucle atteignait la limite de tours. Et lorsque la fenêtre de contexte se remplissait, l’agent finissait par oublier la tâche.

Dans ce contexte, Spotify a basculé vers Claude Code. Lequel a permis des « prompts plus naturels » tout en apportant sa capacité native de gestion de to-do lists et de création de sous-agents. Il couvre désormais la majorité des PR fusionnés en production.

Savoir interdire… et ne pas tout faire à la fois

L’agent initial fonctionnait au mieux avec des prompts stricts structurés étape par étape. Claude Code se débrouille mieux avec des prompts qui décrivent l’état final et laissent de la latitude sur le chemin à suivre.

Spotify constate qu’il peut être utile de dire clairement à l’agent quand il ne doit pas agir. Cela évite des tâches impossibles à réaliser, notamment au cas où on réutilise des prompts entre repos qui n’utilisent pas forcément les mêmes versions de langages.

Fournir des exemples de code influence par ailleurs beaucoup le résultat. Idéalement, on définira l’état souhaité sous forme de tests, l’agent ayant besoin d’un objectif vérifiable pour pouvoir itérer. On s’assurera de surcroît de ne demander qu’un changement à la fois pour éviter l’épuisement de la fenêtre de contexte. Et on n’hésitera pas à demander à l’agent un retour d’expérience à la fin de la session.

Une ouverture limitée via MCP

Spotify a privilégié les longs prompts statiques, sur lesquels les modèles raisonnement plus simplement.

Une approche alternative consiste à commencer avec un prompt plus court, mais à donner à l’agent l’accès à des outils MCP. Le contexte qu’il peut ainsi récupérer lui permet théoriquement de traiter des tâches plus complexes. Mais il rend aussi son comportement moins vérifiable et moins prévisible.

Pour le moment, Spotify permet à son agent d’accéder à un vérificateur (formatage, linting, tests), à une sélection de sous-commandes Git (pas de push ou de change origin, par exemple) et à un ensemble de commandes Bash (comme riggrep).

Encoder la méthode d’invocation des systèmes de build dans un MCP a été jugé plus simple que de s’appuyer sur des fichiers AGENTS.md. La raison : les configurations de build peuvent être très différents à travers les milliers de repos sur lesquels travaille l’agent. Cela permet aussi de réduire le bruit dans les outputs des outils en les résumant avant transmission à l’agent.

Une boucle de vérification déterministe…

Il arrive que le système échoue à générer des PR. Parfois, il en produit, mais qui ne passent pas le CI ou s’avèrent fonctionnellement incorrects. Parfois, c’est lié à un problème de couverture des tests sur le composant cible. Dans d’autres cas, l’agent va au-delà des instructions ou ne comprend tout simplement pas comment bien exécuter build et tests.

Là interviennent des boucles de vérification qui guident l’agent vers le résultat désiré. Ce dernier ignore tout de leur fonctionnement : il sait simplement qu’il peut y faire appel.

La boucle comprend plusieurs vérificateurs indépendants, exposés – par MCP – en fonction du composant logiciel. Par exemple, le vérificateur Maven ne s’active qu’en présence d’un fichier pom.xml à la racine de la codebase.

L’ensemble permet de faire abstraction d’une grande partie du bruit qui remplirait sinon la fenêtre de contexte. L’agent n’a effectivement pas besoin de comprendre les spécificités de l’appel aux différents systèmes de build ou du parsing des résultats de tests.

Qu’ils aient été ou non déclenchés pendant l’exécution de la tâche, les vérificateurs pertinents s’activent avant toute ouverture d’un PR. Avec Claude Code, cela passe par le hook stop.

… et du LLM as a judge

Au-dessus de ces vérificateurs déterministes, Spotify a ajouté une couche LLM as a judge. Nécessaire face à la tendance de l’agent à sortir du cadre des instructions.

Le LLM juge évalue la diff du changement proposé et le prompt d’origine. Il s’exécute après les autres vérificateurs. Les métriques internes indiquent qu’il rejette environ un quart des sessions. Pour la moitié d’entre elles, l’agent finit par se corriger.

Spécialisé (il ne pousse pas de code, ne rédige pas de prompts, n’interagit pas avec les utilisateurs), l’agent en est aussi plus prévisible. Et potentiellement plus sécurisé.

Début décembre, Spotify déclarait vouloir étendre son infrastructure de vérification à davantage de plates-formes (au-delà de Linux-x86). Nombre de ses systèmes ont en effet des besoins spécifiques. Entre autres ses applications iOS, qui exigent des hôtes macOS pour une exécution correcte des vérificateurs. L’entreprise a de surcroît des back-ends Arm. Elle compte aussi intégrer son agent plus profondément dans son systèmes de déploiement continu, en lui permettant d’agir sur les CI checks dans les PR. Et développer des évaluations plus structurées favorisant l’exploration de nouvelles architectures agentiques.

Illustration générée par IA

The post Codage agentique : le retour d’expérience de Spotify appeared first on Silicon.fr.

Dans un atelier bruxellois à Noël, Bernard Lambeau n’a pas ouvert son IDE comme d’habitude. Il a ouvert Claude Code. En quelques prompts — dont un README décrivant l’idée d’un nouveau langage d’expression — il a piloté l’IA d’Anthropic jusqu’à un résultat qui ressemble à une petite anomalie dans l’histoire du logiciel : Elo, un langage […]

L’article Elo : un développeur et Claude Code créent un langage complet en 24 heures est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

Il y a encore deux ans, « coder » supposait un bureau, un écran large, un clavier sérieux. Début 2026, une autre idée s’installe : la production logicielle peut devenir asynchrone, mobile, et pilotée par agents — au point de tenir dans une poche. À l’origine de cette bascule : Claude Code, l’outil de développement « agentique » d’Anthropic, dopé par l’arrivée […]

L’article Claude Code sur smartphone : quand l’IA transforme le « temps mort » en temps de dev est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

Vous utilisez Claude Code, le CLI d'Anthropic ? Hé bien figurez-vous qu'il y a des fonctionnalités cachées dedans, et pas des moindres ! Un dev nommé Mike Kelly a fouillé dans le JavaScript minifié du CLI et il a découvert un truc dingue : un mode "Swarms" qui transforme votre assistant en véritable chef d'équipe capable de déléguer le travail à plusieurs agents en parallèle.

En gros, au lieu de parler à une seule IA qui code, vous parlez à un team lead. Et ce team lead, lui, il ne code pas... il planifie, découpe les tâches et les dispatche à une équipe de spécialistes qui bossent en même temps. Du coup quand vous validez un plan, il spawn plusieurs agents workers qui partagent un tableau de tâches, communiquent entre eux via une sorte de boîte aux lettres interne, et reviennent vous faire leur rapport une fois le boulot terminé.

Le truc c'est que cette fonctionnalité existe DÉJÀ dans le code de l'outil CLI, mais elle est verrouillée derrière un feature flag côté serveur (un truc qui s'appelle tengu_brass_pebble pour les curieux). Mike a donc créé claude-sneakpeek , un outil qui patche le CLI pour forcer ce flag à true. Hop, les fonctionnalités cachées deviennent accessibles. Si vous avez déjà lu mon article sur Auto-Claude , vous voyez le genre... Ce sont des agents en parallèle qui bossent pendant que vous faites autre chose, genre lire mes articles pour entrapercevoir le futur ^^.

Ce qui se débloque

Une fois le patch appliqué, vous avez accès à :

• TeammateTool : pour spawner des équipes d'agents
• Delegate mode : le Task tool peut lancer des agents en arrière-plan
• Teammate mailbox : les agents peuvent s'envoyer des messages entre eux
• Swarm spawning : orchestration native multi-agents

Concrètement, quand vous demandez une tâche complexe, l'IA peut maintenant découper le travail, créer des sous-tâches avec dépendances, et lancer plusieurs workers qui vont bosser en parallèle sur leurs morceaux respectifs. Et ça consomme moins de tokens que de tout faire séquentiellement, contrairement à ce qu'on pourrait croire.

Comment l'installer

L'installation est hyper simple. Vous lancez :

npx @realmikekelly/claude-sneakpeek quick --name claudesp

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

function i8(){if(Yz(process.env.CLAUDE_CODE_AGENT_SWARMS))return!1;return xK("tengu_brass_pebble",!1)}

function i8(){return!0}

npx @realmikekelly/claude-sneakpeek update claudesp
# Mise à jour

npx @realmikekelly/claude-sneakpeek remove claudesp
# Désinstallation

Vous utilisez Claude Code et vous passez votre temps à copier-coller vos logs de terminal pour lui donner du contexte ? Du genre, vous lancez une commande, ça se plante comme une merde, et là faut expliquer à l'IA ce qui s'est passé en faisant des screenshots ou du copier-coller à la main.

C'est vite relou mais heureusement, c'est totalement le problème que résout Wake , un petit outil en Rust qui enregistre automatiquement tout ce qui se passe dans votre terminal et le donne en offrande sacrée à Claude Code via le protocole MCP. Du coup, plus besoin de jouer les secrétaires IA, puisque Claudo Code, euuh Claude Code peut interroger votre historique de commandes avec les sorties et le contexte git quand il en a besoin.

Au début, vous lancez wake shell et hop, vous êtes dans une session enregistrée. Ensuite toutes vos commandes, leurs sorties, et même les infos de votre repo git, tout est capturé et stocké localement dans une base SQLite bien planquée dans ~/.wake/. Puis quand vous posez une question à Claude Code, il peut aller piocher dans cet historique pour comprendre ce que vous avez fait.

L'installation se fait en une seule ligne (allez lire le script comme d'hab, hein) :

curl -sSf https://raw.githubusercontent.com/joemckenney/wake/main/install.sh | sh

Après faut ajouter l'init dans votre .zshrc ou .bashrc :

eval "$(wake init zsh)"

Et pour brancher ça sur Claude Code :

claude mcp add --transport stdio --scope user wake-mcp -- wake-mcp

Côté commandes, y'a wake log pour voir l'historique récent, wake search "machin truc" pour fouiller dedans, wake dump pour exporter en markdown et wake annotate "note" si vous voulez ajouter des petites marqueurs pour vous y retrouver plus tard. Le stockage reste en local sur votre machine, et les sorties sont limitées à 1 Mo par commande pour éviter de saturer la base.

Donc si vous êtes le genre de gaillard.e sans peur à laisser Claude piloter votre terminal ou à utiliser plusieurs agents en parallèle , c'est le genre d'outil qui peut vraiment vous faire gagner du temps car là où avant fallait tout expliquer à l'IA, maintenant elle voit directement ce que vous avez fait et pourquoi ça a merdé.

Le projet vient de sortir en v0.1.0, donc c'est encore tout frais. Ça supporte zsh et bash pour le moment. Par contre, fish c'est pas encore au programme.

Vous rêvez de lancer Claude sur un projet et de le laisser bosser tout seul pendant que vous faites autre chose, du genre jouer à Animal Crossing en attendant la fin de la journée ? Hé bien c'est exactement ce que propose Auto-Claude, un outil open source qui transforme l'assistant IA préféré des devs en armée de développeurs plus autonomes que votre mère quand il s'agit d'échanger un billet de train.

J'avais déjà parlé de Claude Engineer c'est vrai. C'est un framework CLI en Python qui permettait de faire bosser Claude en autonomie. Mais Auto-Claude, alalalala, c'est un autre délire les amis ! Déjà c'est une vraie application desktop avec interface graphique, tableau Kanban pour gérer vos tâches, et surtout... 12 terminaux qui peuvent tourner en parallèle. Oui, DOUZE agents Claude qui bossent simultanément sur votre code pendant que vous candy crushez pépouze dans les WC de votre entreprise.

Les terminaux d'Auto-Claude en action, chacun gérant un agent autonome

Le truc génial, c'est que chaque agent travaille dans son propre git worktree. Du coup, pas de conflit (de canard ^^ - J'ai pas pu résister désolé), pas de branches qui s'emmêlent, et chaque tâche est isolée proprement.

Puis quand c'est fini ? Hop, vous validez et ça merge parfaitement sans vous prendre la tête. Ce truc est fou !

Installation

Alors pour commencer, il vous faut un abonnement Claude Pro ou Max. Pas le choix...

Ensuite, installez Claude Code via npm si c'est pas déjà fait :

npm install -g @anthropic-ai/claude-code

Maintenant on clone Auto-Claude :

git clone https://github.com/AndyMik90/Auto-Claude.git
cd Auto-Claude

Et on installe les dépendances. L'outil gère à la fois le frontend Electron et le backend Python :

npm run install:all

Et c'est tout. Si si sérieux. Bon, là je vous l'ai fait en mode installe de barbu.e.s mais sachez aussi qu'il y a des binaires à télécharger directement pour Windows, macOS (Intel ou Silicon) et Linux (AppImage, deb ou flatpak).

Lancement et utilisation

Pour démarrer l'interface graphique, ensuite, c'est :

npm start

Une fenêtre s'ouvre avec le fameux tableau Kanban. Vous ajoutez vos tâches, vous les assignez aux agents disponibles, et c'est parti. Chaque terminal affiche en temps réel ce que fait son agent.

Le tableau Kanban pour orchestrer vos agents IA

Pour les fans de ligne de commande, y'a aussi un mode CLI :

python run.py --spec 001

Le numéro correspond à un fichier de spec dans le dossier specs/. Vous écrivez ce que vous voulez, et Auto-Claude s'occupe du reste.

Comment ça fonctionne ?

L'architecture est plutôt bien pensée puisque le frontend Electron communique avec un backend Python via WebSocket. Chaque agent a son propre processus isolé, sa propre branche git, son propre contexte.

Ainsi, quand vous lancez une tâche, Auto-Claude :

1. Crée un worktree git dédié
2. Lance un agent Claude Code dessus
3. Monitore l'avancement en temps réel
4. Gère le pipeline QA automatiquement

Le tout avec une interface qui vous permet de suivre 12 conversations en parallèle, soit de quoi bien jouer au chef d'orchestre si vous avez un gros projet à abattre.

Je commence à peine à découvrir l'outil et faut que je le ponce un peu plus pour voir ce que je peux faire avec ça, mais si vous êtes chaud bouillant comme moi sur ce genre de truc, je vous invite à tester l'autonomie IA poussée à fond avec Auto-Claude.

C'est gratuit, open source, et ça tourne sur Mac, Windows et Linux . Et un grand merci à Louis pour la découverte !

Alors, est ce que vous AUSSI, vous avez succombé à la tentation de Claude Code, le nouvel agent en ligne de commande d'Anthropic ?

J'suis sûr que oui !! Ahaha, C'est vrai que c'est hyper pratique de laisser une IA fouiller dans son repo pour corriger des bugs ou refactorer du code. Mais comme toujours avec ces outils qui ont un pied dans votre terminal et un autre dans le cloud, la question de la sécurité finit toujours par se poser.

Est-ce que Claude Code est vraiment sûr ?

Pour Anthropic, la réponse est un grand oui, avec tout son système de permissions basé sur une "blocklist" d'arguments dangereux...

Sauf que voilà, RyotaK , un chercheur en sécurité chez GMO Flatt Security, a décidé d'aller voir sous le capot, et ce qu'il a trouvé devrait normalement, vous faire lever un gros sourcil.

En effet, le gars a dégoté pas moins de 8 façons différentes de faire exécuter n'importe quelle commande arbitraire à Claude Code, le tout sans que vous ayez à cliquer sur "Approuver".

En fait, Claude Code autorise par défaut certaines commandes jugées "inoffensives" comme man, sort ou sed, parce qu'elles sont censées être en lecture seule. Et pour éviter les dérives, Anthropic filtre les arguments avec des expressions régulières.

C'est du classique mais RyotaK a montré que c'est un vrai champ de mines. Par exemple, sur la commande "man", il suffisait d'utiliser l'option --html pour lui faire exécuter un binaire arbitraire chargé de "formater" la page.

man --html="touch /tmp/pwned" man

sort --compress-program "gzip"