Décryptage sur Habr : les agents IA consomment des tokens avant la première ligne de code, cinq patterns pour y remédier

Sur une grande base de code, la consommation de tokens des agents IA augmente nettement plus vite que le volume de code qu'ils écrivent. Une part importante du budget part avant même la première ligne : recherche de fichiers, lecture, analyse de l'architecture. C'est la thèse que défend l'auteur d'un récent décryptage publié sur Habr, qui propose cinq patterns universels d'économie. Seule l'introduction figure dans l'annonce RSS. Les patterns eux-mêmes sont détaillés dans l'article complet ; ce qui suit s'en tient donc à ce que l'annonce affirme, complété par du contexte sur les pratiques du secteur.

Où partent les tokens

Les agents ne se limitent plus depuis longtemps à générer des fonctions isolées. L'auteur énumère ce qu'ils font dans des projets réels : explorer le dépôt, chercher les fichiers utiles, analyser l'architecture, lancer des tests et vérifier le résultat. Les tâches, elles, restent courantes. Ajouter une page au frontend, créer un endpoint, modifier le schéma de la base, comprendre une file de messages, réparer un data pipeline, mettre à jour le CI/CD, brancher un nouveau service.

Dans tous les cas, l'agent commence par une phase de reconnaissance. Il lit des fichiers, récupère des résultats de recherche et des listings de répertoires, consulte les logs de tests. Tout cela entre dans la fenêtre de contexte et est renvoyé au modèle à chaque étape suivante. Plus le dépôt est volumineux, plus cette reconnaissance s'allonge, et le coût de la tâche cesse de dépendre de la taille du diff final.

Ce que l'annonce affirme

• Sujet : économiser les tokens des agents IA lorsqu'ils travaillent sur une base de code.
• Format : cinq patterns universels, non liés à un stack particulier.
• Périmètre : frontend, backend, schémas de bases de données, files de messages, data pipelines, CI/CD, nouveaux services.
• Thèse principale : la consommation de tokens croît plus vite que le volume de code écrit.
• Observation clé : une part importante des tokens est dépensée avant l'écriture de la première ligne.

Le fragment disponible ne donne aucun chiffre d'économie. Impossible de juger l'efficacité des patterns à partir de l'annonce.

Les techniques qui fonctionnent en général

Voici les pratiques courantes dans le secteur, que les ingénieurs appliquent au même problème. Ce n'est pas un résumé de l'article, et on ignore si elles recoupent les cinq patterns de l'auteur.

• Chercher d'abord, lire ensuite. Repérer les symboles et chemins utiles par une recherche ciblée, et ouvrir des plages de lignes plutôt que des fichiers entiers.
• Une carte compacte du dépôt. Une description courte de la structure et des modules clés, pour que l'agent n'ait pas à la reconstituer à chaque session.
• Un fichier de règles du projet. Commandes de build et de tests, conventions, zones interdites, consignées une fois pour toutes.
• Le filtrage de la sortie. L'agent a besoin des tests en échec et de la stack trace, pas du log complet de l'exécution.
• L'isolation de la reconnaissance. L'exploration lourde est déléguée à une session distincte ou à un sous-agent, et seule une synthèse brève revient dans le contexte principal.
• La mise en cache du préfixe stable du prompt, si le fournisseur la prend en charge.

Que faire côté équipes

Commencez par mesurer. Sans ventilation des tokens par phase (reconnaissance, modifications, vérification), toute optimisation avance à l'aveugle. Journalisez la consommation par tâche et comparez-la à la taille du diff : si la reconnaissance coûte systématiquement plus cher que l'écriture du code, le problème vient de la navigation dans le projet, pas du modèle.

Fixez ensuite un budget par tâche et regardez où l'agent le consomme. Ce sont généralement des relectures répétées des mêmes fichiers, des recherches trop larges et des logs non tronqués. Ces trois sources se corrigent à peu de frais, sans changer de modèle ni d'outils.

Il vaut la peine de lire l'article complet sur Habr avec une question précise en tête : lesquels des cinq patterns peut-on tester sur votre dépôt en une journée, et comment mesurer le résultat ? Si l'auteur fournit des mesures avant et après, elles auront plus de valeur que les recommandations elles-mêmes.