Comment doit-on construire et utiliser un agent de code ? Faut-il empiler les serveurs MCP et lui donner les pleins pouvoirs, ou bien restreindre ses outils et encadrer son état ?

Depuis 2025, Mario Zechner (créateur de libGDX et cofondateur d’Earendil) documente une vision opiniâtre de l’ingénierie avec les agents IA. Cette vision a abouti à la création de pi, un agent délibérément minimaliste. J’ai pris le temps de relire et de synthétiser ses essais de 2025 et 2026.

Voici ce que j’en retiens sur la façon d’intégrer les LLMs dans notre workflow d’ingénierie au quotidien.

La philosophie : Le minimalisme comme force

L’agent Pi repose sur un ensemble d’outils radicalement simple : read, write, edit, et bash. Son prompt système et la définition de ses outils pèsent moins de 1 000 tokens. Pourtant, les benchmarks (comme Terminal-Bench 2.0) prouvent que cette approche rivalise avec des frameworks bien plus lourds (Claude Code, Cursor, Codex).

La conclusion de Zechner est sans appel : les modèles actuels ont été suffisamment entraînés par apprentissage par renforcement (RL) pour comprendre ce qu’est un agent de code. Il n’y a plus besoin de 10 000 tokens de prompt système.

« If I don’t need it, it won’t be built. And I don’t need a lot of things. » — Mario Zechner

L’ingénierie du contexte avant tout

Le contexte est la ressource la plus précieuse d’un LLM. Au-delà de 100k tokens, la qualité des réponses chute de façon notable (les détails se perdent au milieu de la conversation). Cela implique une règle stricte : il faut minimiser ce qui entre dans le contexte.

  • Pas d’outils lourds (comme certains serveurs MCP) qui injectent 15 000 tokens à chaque requête.
  • Préférez pré-générer les données utiles plutôt que de laisser l’agent “explorer” ad-hoc un gros codebase.

Ralentir est une feature, pas un bug

Les agents génèrent du code vite. Trop vite. Dans son article de mars 2026, Thoughts on slowing the fuck down, Mario souligne un piège majeur : les petites erreurs, les code smells, la duplication et les mauvaises abstractions s’accumulent à un rythme effréné quand il n’y a plus de goulot d’étranglement humain. Un humain apprend de ses erreurs, un LLM les répète inlassablement.

L’humain doit donc rester la porte d’entrée et la porte de qualité finale :

« Anything that defines the gestalt of your system — architecture, API — write it by hand. »

6 Bonnes pratiques pour dompter les agents

1. Prompts are code, fichiers = state

Traitez les LLMs comme des ordinateurs lents et non déterministes. Le workflow d’un agent est un programme à part entière. Le prompt système est votre code source, vos scripts bash/jq sont vos bibliothèques, et vos fichiers markdown ou json sont votre état persistant.

L’exemple du portage Java vers C++ des “Spine Runtimes” le démontre : un portage qui prenait 2 à 3 semaines à l’humain est tombé à 2-3 jours. Comment ? En définissant un fichier porting-plan.json et un fichier de workflow port.md que l’agent suit scrupuleusement.

2. Ne laissez pas l’agent deviner, pré-générez

L’exploration ad hoc est coûteuse en tokens, non-déterministe et lente. Écrivez plutôt des scripts (par ex. generate-porting-plan.js) qui préparent les données exactes dont l’agent aura besoin.

3. Documentez vos conventions (pour l’agent)

Avant une tâche complexe, rédigez un fichier (ex: conventions.md) listant :

  • Le style de nommage
  • La gestion mémoire voulue
  • La structure de fichiers attendue L’agent le lira une fois, s’en imprégnera, et appliquera vos standards.

4. Imposez des points de contrôle

Le workflow ne doit pas être une boîte noire. Demandez à l’agent de demander confirmation avant de valider une grosse modification. C’est de la programmation défensive appliquée à l’IA.

5. Préférez des petits scripts composables

Construisez des petits pipelines de scripts. Chaque script prend des fichiers, produit des fichiers, et est testable indépendamment. C’est reproductible et auditable.

6. Fuyez les features intégrées, utilisez des CLI

L’agent Pi refuse d’intégrer des listes de to-dos, des serveurs MCP ou des environnements bash tournant en arrière-plan. Utilisez un bon vieux fichier TODO.md, des outils en ligne de commande (CLI), et tmux. Gardez l’agent “dumb” et transparent.

Les pièges du quotidien avec l’IA

  • Les LLMs manquent de goût : Ils produisent la “moyenne statistique” de GitHub. Résultat : du code souvent verbeux ou sur-ingéniérisé. L’humain doit écrire l’architecture et les APIs, l’agent ne fait que décliner.
  • La recherche agentique a un rappel faible : Plus le codebase grossit, plus l’agent “rate” des zones de code lors de ses recherches. L’humain doit guider l’agent ou utiliser des plans statiques pour identifier les zones à modifier.
  • Le surcoût du protocole MCP : Un serveur MCP comme Chrome DevTools expose 26 outils et pèse 18 000 tokens injectés dans le système. Ce coût est payé à chaque requête. Mario recommande d’utiliser des outils CLI avec des READMEs (divulgation progressive) : le modèle ne paie les tokens que lorsqu’il choisit de lire le README.
  • Les fournisseurs modifient l’IA dans votre dos : Des outils comme Claude Code voient leurs prompts système ou leurs outils mis à jour silencieusement, ce qui casse la reproductibilité de vos workflows. Gardez la main sur vos prompts systèmes (avec un outil comme pi).

Le Workflow recommandé

En combinant ces idées, voici la marche à suivre pour un développement assisté efficace :

  1. Phase 1 : Planification (sans agent). Comprenez le problème vous-même. Écrivez l’architecture, définissez les conventions en markdown, et pré-générez les listes de fichiers à modifier.
  2. Phase 2 : Exécution. Lancez l’agent avec un contexte strict et le fichier de plan. Laissez-le itérer par petits cycles avec vérification humaine.
  3. Phase 3 : Validation. Lisez le code via des diffs (ne vous fiez pas au résumé textuel du modèle). Testez, compilez, et corrigez immédiatement les erreurs.
  4. Phase 4 : Nettoyage. Supprimez le code mort et les abstractions génériques que le LLM a pu introduire pour “faire bien”.

« Let the agent do the boring stuff, the stuff that won’t teach you anything new. Then you evaluate, take the ideas that are actually reasonable, and finalize the implementation. »

La boîte à outils de Zechner

  • L’agent : pi (minimaliste, open-source, multi-fournisseurs)
  • Le Terminal : tmux (indispensable pour les serveurs de dev et sous-agents)
  • L’exploration : ripgrep (plus rapide que grep) et jq (pour l’état JSON)
  • Les outils CLI : agent-tools (au lieu de MCP)
  • L’analyse : lsp-cli pour extraire des types déterministes.
  • Recherche & Scraping : Sitegeist (scraping traçable).

Le développement logiciel a muté. L’IA produit du volume, mais c’est bien la discipline humaine (structuration du contexte, conventions, outils clairs) qui le transforme en valeur réelle. Et à ce jeu, la simplicité et le déterminisme restent rois.

Si vous souhaitez approfondir, je vous recommande vivement les articles originaux de Mario Zechner sur son blog : mariozechner.at, en particulier “Prompts are code, .json/.md files are state” (Juin 2025) et “Thoughts on slowing the fuck down” (Mars 2026).