Anthropic, OpenAI et Cursor : les huit niveaux de maturité de l'ingénierie agentique

Habr AI a publié la traduction d'un article sur les huit niveaux de l'ingénierie agentique, une pratique qui fait passer le LLM du statut d'assistant d'autocomplétion à celui d'équipe de développeurs presque autonome. L'idée centrale du texte : un bond de qualité des modèles ne garantit pas à lui seul un gain de productivité si l'équipe n'a pas structuré le contexte, les règles, les outils et le retour d'information.

Des suggestions aux agents

L'auteur juge les deux premiers niveaux déjà familiers : tab complete et agent IDE. À ce stade, l'IA accélère les tâches locales : elle complète des fragments de code, aide à modifier plusieurs fichiers et construit un plan à partir d'une idée. Mais le vrai tournant intervient au troisième niveau, où le context engineering passe au premier plan. Il ne s'agit plus d'un joli prompt, mais de discipline : quels fichiers, quelles règles et quelles descriptions d'outils le modèle reçoit, ce que contient l'historique de session et combien de bruit inutile engloutit la fenêtre de contexte. Moins il y a de déchets, plus le résultat est stable.

« Chaque token doit mériter sa place dans le prompt ».

Le quatrième niveau est le compounding engineering : l'équipe ne se contente pas d'utiliser le modèle, elle transforme les trouvailles utiles en système. Quand l'agent se trompe, les enseignements sont consignés dans des fichiers de règles, la documentation et des patterns de travail, afin que la session suivante ne répète pas les mêmes erreurs.

Le cinquième niveau ajoute des outils d'action : MCP, skills, accès aux API, aux bases de données, à la CI et au navigateur. À partir de là, le LLM cesse d'être un simple interlocuteur sur le code et commence à modifier réellement la base de code, à la tester et à participer à la relecture.

Où le rendement augmente

L'auteur voit dans le sixième niveau le moment où le codage par IA devient réellement industriel. Ce n'est plus seulement le contexte qui compte, mais tout l'environnement autour de l'agent : tests, linters, typage, journaux, vérifications dans le navigateur et autres feedback loops. Ce sont eux qui permettent au modèle non seulement de générer un patch, mais de repérer une erreur, de se vérifier et de faire une nouvelle itération sans intervention humaine.

L'article appelle cela le harness engineering : concevoir un runtime où l'agent peut voir les conséquences de ses propres modifications et se heurter à des contraintes concrètes plutôt qu'à des consignes floues.

• fichiers de règles et documentation qui posent le contexte
• outils CLI ou MCP pour accéder aux données, aux tests et à l'interface
• backpressure automatique : types, linters, hooks, CI
• séparation des rôles entre exécutant et relecteur, pour que l'agent ne se contrôle pas lui-même

De là naît le septième niveau : les agents en arrière-plan. Si le modèle sait construire un plan, se repérer dans le dépôt et valider son résultat, il n'a plus besoin de rester dans un onglet interactif. L'agent peut travailler de manière asynchrone : explorer la base de code, écrire une fonctionnalité, lancer les vérifications, ouvrir une PR et ne revenir qu'avec des questions ou un résultat. Pour l'équipe, cela change la manière même de travailler : le développeur jongle moins à la main avec les tâches et agit de plus en plus en chef d'orchestre, qui fixe l'intention, les contraintes et les priorités.

Où va le marché

Ce qui suit ressemble pour l'instant davantage à une pointe avancée qu'à une pratique quotidienne. Le huitième niveau, ce sont les équipes d'agents autonomes, où plusieurs LLM se coordonnent directement entre eux, sans passer par un opérateur central unique. Le texte cite des exemples d'Anthropic et de Cursor : des agents parallèles ont déjà servi à écrire un compilateur C, à construire un navigateur et à mener de grandes migrations dans une base de code.

Mais avec l'échelle resurgissent aussitôt les vieux problèmes du développement : régressions, conflits, blocages, prudence excessive et coût de calcul croissant. L'auteur tire donc une conclusion sobre : pour la plupart des équipes, il importe davantage d'atteindre au moins un septième niveau mature que de rêver de départements d'IA entièrement indépendants. Autrement dit, bâtir un contexte propre, accumuler des règles, soigner les skills, installer des boucles de vérification fiables et une orchestration en arrière-plan.

C'est là, selon lui, que se trouve le gain pratique le plus proche. Et c'est là que l'écart entre une équipe d'IA solide et une équipe faible devient particulièrement visible : les unes accélèrent leurs livraisons, les autres se noient dans le chaos qu'elles ont elles-mêmes automatisé.

Ce que cela signifie

L'article de Habr AI est utile parce qu'il déplace la discussion sur les « modèles intelligents » vers celle de la maturité d'ingénierie. Le marché du codage par IA ne va pas vers un bouton magique, mais vers des systèmes où les modèles reçoivent le bon contexte, des outils opérationnels et des garde-fous de vérification stricts. Les gagnants ne seront pas ceux qui disposent simplement d'un modèle plus récent, mais ceux qui construiront le plus vite une chaîne de travail fiable autour de lui.