« On trace tout » est une intention, pas une garantie : il suffit d'un nouveau chemin de code pour qu'un trou apparaisse sans que personne le voie. Ce qui tient la règle, c'est un test qui gèle l'inventaire des points d'appel — plus deux pièges qui m'ont coûté du temps.
« L'agent hallucine » est un mauvais diagnostic : ça cherche la solution du côté du modèle. Sur un agent qui extrait des données de documents, j'ai vu la garantie se déplacer — de la qualité du modèle vers trois contraintes d'ingénierie. Dont une qui m'a surpris.
J'éditais le prompt système, je relançais, et rien ne bougeait. Le coupable n'était pas le cache : c'est que le graphe est construit une fois au démarrage. Trois durées de vie cohabitent dans un agent, et savoir laquelle s'applique change la boucle de feedback.
Quand on délègue à des agents, on a toujours deux ou trois branches en vol. Le `git checkout` classique casse tout : stash, stack Docker qui redémarre, ports qui se marchent dessus. Voici le layout qui m'a débloqué — et ce qu'il coûte vraiment.
Un design d'access-control entier reposait sur une ligne de code qui n'existe pas. Ce n'est pas le code qui était faux, c'était le sol. Voici pourquoi un numéro de ligne inventé est le mensonge le plus efficace d'un agent — et le garde-fou qui l'attrape.
42 sessions, 913 messages, 155 commits. Le rapport ne dit pas ce que je pensais faire — il dit ce que je fais vraiment : déléguer des missions larges, laisser courir, et corriger en vol plutôt que spécifier en amont. Voici la boucle, et ce qu'elle coûte.
On dit qu'il faut apprendre 14 étapes pour devenir un agentic AI engineer. Spoiler: les vraies transformations tiennent en 5 patterns architecturaux. Voici comment j'ai compris qu'il ne s'agissait plus de parler au modèle, mais de construire un système qui décide.
Passer d'un agent à deux, ce n'est pas écrire deux fois plus de code. C'est ajouter une troisième pièce qui ne répond jamais : l'orchestrateur qui détecte l'intention et aiguille vers le bon spécialiste.
Développeur freelance basé à La Réunion, +2h de Paris, 100% remote. Spoiler : le décalage n'a rien changé. Ce qui comptait, c'était l'archi backend que j'ai posée pour une équipe qui devait scaler — DDD, découpage en microservices, guidelines qui tiennent.
Un LLM prédit du texte ; un agent exécute des tâches. Entre les deux : le harness. J'ai voulu le comprendre, et j'ai réalisé que mon pattern décrivait déjà le Claude Agent SDK.
Le métier de dev glisse de la frappe au pilotage : orchestrer des agents, écrire la spec, garantir que ce qui part est ce qui était attendu. Ce que ça change quand on ne code plus pour produire, mais pour valider.
Un agent IA produit du code « moyen » par défaut : fichiers de 300 lignes, any partout, logique dans le JSX. Voici les 10 règles que j'ai écrites pour VoiceJournal, et pourquoi elles tiennent.
Une issue GitHub depuis le tel, une session Claude Code qui s'auto-déclenche dans un container cloud, une PR qui apparaît dans Slack, un merge depuis l'app GitHub. Mon workflow indie quand je suis loin du laptop — et ce qui marche / ce qui ne marche pas.
Passer du Claude qui code au Claude qui s'auto-discipline. SessionStart pour bootstrap le repo, PreToolUse pour bloquer les commandes douteuses, Stop pour notifier la fin d'une tâche. Quatre hooks concrets que j'ai installés dans mes repos et qui tournent en silence.
Brainstorming → spec → plan détaillé → exécution par sub-agents avec review. Le workflow que j'utilise depuis quelques mois et qui rend l'IA enfin utilisable sur des projets multi-jours, pas juste sur du snippet.
Un proxy CLI en Rust qui s'insère entre Claude Code et tes commandes shell. Il compresse les sorties verbeuses (git status, ls, jest...) avant qu'elles atteignent le contexte. Installé en une commande, gain immédiat.
Un fichier markdown à la racine de ton repo qui décrit comment on code chez toi. Lu par Claude (l'agent) avant chaque session, et par les humains au premier coup d'œil. C'est devenu mon contrat d'ingénierie le plus important.