En octobre dernier, j'ai confié une tâche plutôt ennuyeuse à Claude : « Créer un wrapper WordPress REST API en PHP, écrire des tests PHPUnit pour lui, les exécuter, corriger ce qui échoue. » Je lui ai donné accès à mon terminal via une configuration locale de tool-use Claude et je suis allé faire du thé. Revenu douze minutes plus tard. Les tests étaient au vert. J'avais un wrapper qui fonctionnait avec 94 % de couverture et un petit commentaire inline où Claude avait détecté un cas limite que je n'avais pas mentionné dans le brief. Je suis resté là, dans ma cuisine à Bermondsey, véritablement déstabilisé.Claude tool-use setup and walked away to make tea. Came back twelve minutes later. Tests were green. I had a working wrapper with 94% coverage and a small inline comment where Claude had caught an edge case I hadn't mentioned in the brief. I stood there in my kitchen in Bermondsey genuinely unsettled.
C'est ça, le développement agentic. Pas de l'autocomplétion, pas un Stack Overflow plus intelligent. Un modèle qui raisonne sur un objectif, choisit l'action suivante, l'exécute, observe le résultat et boucle jusqu'à la fin. Et ça change la façon dont je gère les projets chez Seahawk Media plus vite que presque n'importe quoi ces neuf dernières années.
Ce que « Agentic » Signifie Vraiment (Et Ce Qu'il Ne Signifie Pas)
Soyons précis, parce que ce mot est jeté à la légère partout. Une boucle agentic IA a trois choses : un objectif, un ensemble d'outils, et la capacité de décider quoi faire ensuite en fonction de ce qui vient de se passer. Le modèle ne génère pas juste du texte. Il agit, observe et replanie.
Ce que ce n'est pas, c'est de la magie. Le modèle peut toujours halluciner une signature de fonction. Il peut se boucler dans un coin en faisant le même mauvais correctif sept fois. Il peut mal comprendre ton objectif à l'étape une et construire avec assurance dans la mauvaise direction pendant dix étapes. J'ai vu tout ça. Une fois, sur un projet de tableau de bord React, Claude a passé environ vingt minutes à ajouter des vérifications null de plus en plus baroques pour résoudre un problème qui était en réalité un await manquant. Celui-là, c'était de ma faute, je lui avais donné une spécification initiale vague.not is magic. The model can still hallucinate a function signature. It can loop itself into a corner doing the same wrong fix seven times. It can misunderstand your goal at step one and build confidently in the wrong direction for ten steps. I've seen all of these. Once, on a React dashboard project, Claude spent about twenty minutes adding increasingly baroque null checks to solve a problem that was actually a missing await. That one was my fault, I gave it a vague initial spec.
La distinction qui compte pour les praticiens : les tâches agentiques étroitement ciblées battent les tâches ouvertes. « Écrire et tester une fonction de sanitisation de slug qui gère l'arabe, le japonais et les emoji » est une excellente tâche agentique. « Construis-moi un SaaS » n'en est pas une. Délimitez le champ étroitement, sinon vous passerez plus de temps à examiner les mauvais virages que vous n'auriez passé à écrire le code.narrow agentic tasks beat open-ended ones. "Write and test a slug sanitisation function that handles Arabic, Japanese, and emoji" is a great agentic task. "Build me a SaaS" is not. Scope it tight, or you'll spend more time reviewing wrong turns than you would have spent just writing the code.
La Stack Réelle que j'utilise
Les outils comptent énormément ici. Sans le bon échafaudage, « Claude agentique » n'est qu'une fenêtre de chat.
Ma configuration actuelle chez Seahawk :
- [Claude API](https://www.anthropic.com/api) avec utilisation d'outils, spécifiquement la bêta computer_use et des outils personnalisés bash/système de fichiers, specifically the
computer_usebeta and custom bash/filesystem tools - Cursor comme couche IDE, avec Claude 3.5 Sonnet configuré comme modèle backend as the IDE layer, with Claude 3.5 Sonnet set as the backend model
- pytest / PHPUnit / Jest selon le projet, parce que Claude a besoin d'un signal déterministe pour boucler dessus. Sans résultats de test, il vole à l'aveugle. depending on the project, because Claude needs a deterministic signal to loop on. Without test output, it's flying blind.
- Un court system prompt qui indique à Claude quelle est la structure du projet, quels sont les standards de codage, et, c'est important, d'arrêter et demander s'il est sur le point de créer un nouveau fichier en dehors du répertoire spécifié. that tells Claude what the project structure is, what the coding standards are, and, this is important, to stop and ask if it's about to create a new file outside the specified directory.
Cette dernière contrainte semble mineure. Ce ne l'est pas. Les modèles agentiques vont volontiers échafauder des modules entièrement nouveaux s'ils pensent que cela sert l'objectif. Les garde-fous sur le système de fichiers m'ont sauvé de plusieurs moments « d'où vient cela ? ».
Une chose que je n'utilise pas : les frameworks d'orchestration multi-agents pour la plupart du travail. LangChain, AutoGen, CrewAI, c'est véritablement intéressant, mais pour un développeur solo ou une petite agence, la surcharge de configuration d'agents qui se parlent n'en vaut généralement pas la peine. Une boucle Claude bien ciblée vaut mieux que trois agents mal ciblés qui se crient dessus.
Comment je structure une tâche qui vaut la peine d'être bouclée
Voici ce que j'ai finalisé après probablement 200+ sessions agentic cette année. Donnez au modèle un brief de tâche qui contient quatre choses :
- L'objectif, spécifique, testable, assez petit pour être terminé en moins de 30 étapes, specific, testable, small enough to finish in under 30 steps
- L'état de départ, quels fichiers existent, quels tests passent déjà, what files exist, what tests already pass
- La condition de succès, généralement « tous les tests au vert » ou une signature de fonction spécifique qu'il doit produire, usually "all tests green" or a specific function signature it must produce
- La condition d'arrêt, « si vous avez essayé le même correctif plus de trois fois, arrêtez et expliquez pourquoi vous êtes bloqué », "if you've tried the same fix more than three times, stop and explain why you're stuck"
Ce quatrième point est sous-estimé. Sans lui, Claude va parfois boucler indéfiniment. Pas indéfiniment-indéfiniment, mais je l'ai regardé faire 18 tentatives sur un problème regex vicieux, chacune légèrement différente, aucune correcte, jamais s'arrêter pour dire « je ne suis pas sûr ». Lui dire explicitement de surfacer la confusion est quelque chose que la spécification du modèle Anthropic aborde en termes d'approche du modèle face à l'incertitude, mais en pratique, vous devez encore le demander par prompt.Anthropic model spec discusses in terms of the model's approach to uncertainty, but in practice, you still need to prompt for it.
En 2022, un client nous a confié un travail migrant 14 000 listes de produits d'une ancienne installation Magento vers WooCommerce. À ce moment-là, Claude ne faisait pas de boucles agentic, donc nous avons écrit les scripts de migration à la main sur deux semaines. Le même travail aujourd'hui ? J'écrirais un spec serré, le confierais à Claude avec accès lecture au schéma de la base Magento et accès écriture à une instance WooCommerce de test, et le laisserais tourner. Je pense sincèrement que nous aurions terminé en deux jours. C'est le delta.
Où Claude est étonnamment bon
Refactoriser du code existant
C'est là où j'ai été le plus impressionné. Donnez-lui une classe désordonnée de 400 lignes, dites-lui de refactoriser vers la responsabilité unique, et laissez-le exécuter ses propres tests unitaires comme points de contrôle. Il maintient le contexte sur tout le fichier mieux que je ne l'aurais prévu et il fait vraiment attention à ne pas casser les tests qui passent. Le résultat n'est pas toujours l'architecture que j'aurais choisie, mais c'est généralement défendable.I would choose, but it's usually defensible.
Écrire des tests pour du code que vous n'avez pas écrit
Seahawk fait beaucoup d'audits de sites et de sauvetages. Nous héritons de bases de code tout le temps, souvent sans aucun test et sans développeur original en vue. J'ai commencé à utiliser Claude agentic spécifiquement pour écrire une suite de tests pour du code hérité avant que nous ne touchions à quoi que ce soit. Il lit la source, déduit l'intention à partir des noms de fonctions et des commentaires, écrit les tests, les exécute, et ajuste quand quelque chose échoue de façon inattendue. Le mois dernier, il a détecté un bug de corruption silencieuse de données dans un gestionnaire de commandes WooCommerce personnalisé qui y était probablement depuis deux ans. Personne ne le savait.
Broyer la boîte à outils
Échafaudage de points de terminaison REST, migrations CRUD, formulaires de panneau d'administration. Le truc ennuyeux qui prend un après-midi à un développeur compétent et que personne n'aime. Claude est rapide et cohérent ici, et la cohérence est effectivement ce que vous voulez dans la boîte à outils, il ne devient pas créatif, il ne se fatigue pas, il fait juste de la correspondance de motifs sur votre code existant et l'étend.
Là où ça tourne mal
Honnêtement, les échecs sont instructifs. Voici ceux que j'ai rencontrés le plus souvent :
- Débordement de fenêtre de contexte sur les grandes bases de code. Claude 3.5 Sonnet a une fenêtre de contexte de 200k tokens, ce qui semble énorme jusqu'à ce que vous le nourrissiez avec un plugin WP complet avec 40 fichiers. Il commence à oublier les choses qu'il a vues au début de la session. Solution : diviser le travail en boucles plus petites avec des points de contrôle explicites. Claude 3.5 Sonnet has a 200k token context window, which sounds enormous until you're feeding it a full WP plugin with 40 files. It starts forgetting things it saw early in the session. Solution: break the job into smaller loops with explicit checkpoints.
- Confiance sur des choses sur lesquelles il ne devrait pas être confiant. Claude va corriger une requête de base de données, exécuter le test, il passe, et signaler le succès, mais la requête est maintenant subtilement moins efficace parce qu'il a échangé une clause WHERE adaptée aux index pour une sous-requête. Il a résolu le problème déclaré et en a créé un non déclaré. L'examen du code est toujours important. Claude will fix a database query, run the test, it passes, and report success, but the query is now subtly less efficient because it swapped an index-friendly
WHEREclause for a subquery. It solved the stated problem and created an unstated one. Code review still matters. - Augmentation des permissions des outils. Si vous lui donnez un accès bash sans le contraindre, il va exécuter npm install pour des paquets que vous n'avez pas demandés, ou pire, faire une requête réseau que vous n'avez pas autorisée. Ce n'est pas malveillant, c'est le modèle qui fait ce qui semble utile. Définissez vos permissions d'outils avant de commencer, pas après qu'un truc bizarre se produise. If you give it bash access and don't constrain it, it will run
npm installfor packages you didn't ask for, or worse, make a network request you didn't sanction. This isn't malicious, it's the model doing what seems helpful. Set your tool permissions before you start, not after something weird happens.
Une note sur la sécurité : si vous exécutez des boucles d'agents contre quoi que ce soit connecté à des données de production, veuillez lire les conseils d'Anthropic sur la sécurité des outils. Ce n'est pas long, et cela vous évitera une mauvaise journée.guidance on tool-use safety. It's not long, and it will save you a bad day.
Prompting pour le comportement d'agent vs. le comportement de chat
Le modèle de prompting est différent et c'est ce qui trompe les gens. Dans un contexte de chat, vous êtes conversationnel, itératif, allez-retour. Dans un contexte d'agent, le prompt initial est un document de spécification. Vous ne serez pas là pour clarifier en cours de tâche.
Les choses qui font fonctionner les prompts d'agents :
- Énoncez les contraintes en premier, pas en dernier. La plupart des gens les cachent.
- Dites-lui ce qu'il ne faut pas faire. « Ne modifiez aucun fichier en dehors de /src/utils » est plus utile que dix lignes d'instructions positives.not to do. "Do not modify any file outside
/src/utils" is more useful than ten lines of positive instructions. - Donnez-lui une échappatoire. « Si vous atteignez un point de décision où continuer nécessiterait de modifier le schéma de la base de données, arrêtez et rédigez un résumé du pourquoi. »
- Référencez la commande du test runner explicitement. « Exécutez ./vendor/bin/phpunit tests/ après chaque modification et utilisez la sortie pour guider votre prochaine étape. »
./vendor/bin/phpunit tests/after every change and use the output to guide your next step."
Le changement de cadrage est : vous rédigez un cahier des charges pour un contractant très capable mais qui ne peut pas poser de questions. Alors écrivez comme on le ferait.
Le cadran d'autonomie : à quel point laisser tourner
C'est la question que je reçois le plus souvent d'autres agences. Est-ce qu'on le surveille ou on le laisse faire ?
Ma réponse après un an : ça dépend entièrement de la réversibilité des actions. Recherche en lecture seule, rédaction de tests, échafaudage dans un nouveau répertoire, laisse tourner. Tout ce qui touche à une base de données en production, modifie les manifestes de paquets, ou interagit avec des API externes, vérifiez tous les quelques étapes, ou au moins lisez le plan avant qu'il s'exécute.
Le motif de prompting ReAct (Reason + Act, tiré de l'article Yao et al. de 2022) vaut le coup d'être compris ici. C'est essentiellement ce que Claude fait en interne quand on lui donne des outils : ça réfléchit à voix haute sur ce qu'il faut faire, le fait, lit le résultat, réfléchit à nouveau. Rendre ce raisonnement visible, demander à Claude d'imprimer son plan avant chaque action, vous donne un point de contrôle naturel sans casser la boucle.ReAct prompting pattern (Reason + Act, from the 2022 Yao et al. paper) is worth understanding here. It's essentially what Claude does internally when you give it tools: it thinks out loud about what to do, does it, reads the result, thinks again. Making that reasoning visible, asking Claude to print its plan before each action, gives you a natural review point without breaking the loop.
J'ai commencé à traiter la sortie de raisonnement étape par étape de Claude comme je traite une PR d'un développeur junior. Je la survole. Si quelque chose me semble bizarre, j'interviens. Si ça semble raisonnable, je le laisse procéder. Ce modèle mental m'a bien servi.
FAQ
Claude agentic est-il vraiment prêt pour la production sur des projets clients ?
Pour des tâches spécifiques et délimitées dans des environnements hors production : oui, absolument. Je l'utilise régulièrement pour les phases d'échafaudage, de refactorisation et de rédaction de tests des projets. Pour tout ce qui touche à une base de données client en production ou à une API de paiement externe, je maintiens un humain dans la boucle à chaque étape d'exécution. Le modèle est capable ; le risque réside dans l'ampleur des dégâts d'une erreur, pas dans le modèle lui-même.
Quelle est la différence entre Claude agentic et l'utilisation de Cursor ou GitHub Copilot ?
Cursor et Copilot sont des suggestions de code en ligne et des interfaces de chat. Ils réagissent à ce que vous tapez. Claude agentic reçoit un objectif et exécute un plan multi-étapes tout seul, en utilisant des outils comme un terminal, un système de fichiers, ou un navigateur web. C'est la différence entre un moteur d'autocomplétion et un processus qui peut tourner sans surveillance pendant dix minutes et revenir avec une tâche terminée.
Faut-il savoir coder pour l'utiliser ?
Vous avez besoin de suffisamment de contexte pour écrire une spécification cohérente et pour examiner le résultat de façon critique. Si vous ne pouvez pas lire une diff et dire si la modification a du sens, vous allez avoir une mauvaise expérience. L'IA agentive amplifie la compétence. Elle ne remplace pas la base.
Quel modèle Claude devrais-je utiliser pour les boucles agentives ?
Claude 3.5 Sonnet est ma valeur par défaut actuelle. Il offre un bon équilibre entre la qualité du raisonnement et la vitesse, ce qui importe quand vous payez par token sur une boucle de 30 étapes. Claude 3 Opus est meilleur pour les tâches de raisonnement très complexe mais plus lent et plus cher, je l'utilise pour l'étape de planification initiale sur les gros projets, puis je passe à Sonnet pour l'exécution.
---
Ce à quoi je reviens sans cesse, c'est que le développement agentif n'est vraiment pas question de l'IA remplaçant les développeurs. C'est une question de changer la valeur du temps d'un développeur. Les douze minutes que je n'ai pas passées à écrire ce wrapper PHP en octobre dernier, je les ai consacrées à la réflexion sur l'architecture. C'est un échange que je ferais à chaque fois.