La pile de développement qui a mis fin aux mensonges de l'IA

L'aide gratuite à la programmation par IA est assortie d'un poste que la plupart des équipes ne prévoient jamais dans leur budget : les heures perdues à démêler un code qui n'avait jamais eu la chance de fonctionner. Vous gagnez 30 secondes à générer un hook React, puis vous perdez deux heures à découvrir que l'API a changé l'année dernière et que votre « assistant » n'a jamais été informé. Ce fossé entre une sortie confiante et la réalité actuelle est là où se cache le véritable coût.

Le développeur et artisan de l'outil Robin Ebers a un terme direct pour cela : le code obsolète est "très coûteux". Lorsque l'IA vous fournit une intégration défectueuse pour Stripe, Next.js ou AWS, vous ne vous contentez pas de corriger la syntaxe ; vous reverse-engineering ce qui a changé depuis la date limite de formation du modèle. Chaque minute passée à comparer la documentation avec des extraits hallucinations représente une productivité que vous pensiez avoir sous-traitée.

Les LLM modernes embarquent un handicap intégré : une date de coupure du modèle qui fige leurs connaissances des mois ou des années dans le passé. Des frameworks comme Next.js, React et FastAPI proposent des changements majeurs tous les 6 à 12 semaines. Les API cloud d'AWS, Google Cloud et OpenAI évoluent encore plus rapidement, dépréciant des paramètres, renommant des méthodes et modifiant des flux d'authentification pendant que votre modèle reste figé dans le temps.

Cette inadéquation transforme les assistants AI en narrateurs peu fiables pour des piles en évolution rapide. Si vous demandez un exemple de Stripe Checkout, vous pourriez obtenir l'API de 2022, avec des champs obsolètes. En appelant l'API REST de GitHub, le modèle pourrait recommander avec assurance des points de terminaison qui n'existent plus ou nécessitent des autorisations qui ont changé après sa date de coupure. Le code semble plausible, se compile correctement et échoue silencieusement en production.

La plupart des conseils aujourd'hui essaient de masquer cela avec de meilleures invitations : « demandez-lui de vérifier », « dites-lui de vérifier par rapport aux documents », « soyez précis sur les versions ». Cela fait peser la responsabilité sur les développeurs, qui doivent désormais concevoir les invites aussi soigneusement qu'ils conçoivent les schémas. Vous dépendez toujours d'un système qui devine d'abord et ne vérifie son travail que parfois.

Le travail d'Ebers indique une réponse différente : changez la pile de développement, pas seulement les invites, afin que le modèle ne puisse pas mentir sur les API sans d'abord se heurter à la réalité.

L'hallucination semble mystique, mais pour les développeurs, cela signifie que votre assistant renvoie avec assurance du code qui n'a jamais fonctionné nulle part. Un grand modèle linguistique prédit le prochain jeton en fonction des motifs présents dans ses données d'entraînement, et non sur un compilateur ou un environnement d'exécution en direct. Lorsque ces données se figent à une date limite, votre IA fabrique joyeusement des méthodes, des paramètres et des drapeaux de configuration qui n'existent que dans son imagination.

Demandez une intégration de l'API Stripe aujourd'hui et un modèle statique pourrait encore suggérer des appels de style v2, obsolètes depuis des années. Demandez un exemple de client OpenAI et il pourrait utiliser des signatures antérieures à 2023 qui renvoient désormais des erreurs 400. Le modèle ne sait pas qu'il a tort ; il optimise pour la plausibilité, pas pour la vérité.

Les développeurs essaient souvent de compenser cela avec des recherches web génériques ajoutées au chat. Cela signifie généralement extraire les mêmes articles de blog saturés de SEO et les fils de discussion Stack Overflow de 2019 que vous avez déjà cessé de croire. Vous obtenez des modèles React de l'époque de jQuery, des exemples de `componentWillReceiveProps`, ou du YAML Kubernetes qui précède la version de votre cluster.

Les moteurs de recherche sont optimisés pour les clics, pas pour la documentation de vérité fondamentale. Ils mettent en avant des contenus qui sont bien classés, pas forcément ceux qui sont corrects pour la version `v4.2.1` de la bibliothèque que vous utilisez réellement. Votre IA résume ensuite ce fouillis, accumulant des conseils obsolètes pour en faire des absurdités qui semblent modernes.

Ce dont vous avez vraiment besoin, c'est d'un système capable de distinguer trois types d'informations : le contexte général, des exemples communautaires et des spécifications autorisées. Le contexte général peut provenir de blogs et de questions-réponses. Les exemples peuvent venir de la recherche de code. Mais lorsque les signatures, les indicateurs ou les comportements comptent, le modèle doit se référer aux documents officiels ou aux SDK typés.

Les LLM statiques reposent sur un instantané du monde, tandis que les logiciels avancent à un rythme de publication hebdomadaire. React, Next.js, Stripe, OpenAI, AWS et Kubernetes ont tous apporté des changements majeurs après la date limite d'entraînement des modèles les plus populaires. Cette déconnexion garantit un écart entre ce que votre IA « sait » et ce que votre chaîne d'outils fait réellement.

Sans possibilité d'acheminer les questions vers des sources à jour—références d'API, journaux de modifications, guides de migration—vous contraignez un générateur de texte probabiliste à se comporter comme un débogueur en direct. C'est ainsi que vous finissez par payer pour du code "gratuit" avec des heures de débogage et des erreurs 500 inexpliquées.

L'ingénierie des invites considérait le modèle comme un collaborateur artistique. L'orchestration des outils le traite comme un employé suivant un manuel d'exploitation. Vous arrêtez de demander avec des invites astucieuses et commencez à intégrer des règles strictes dans l'environnement que le modèle ne peut pas ignorer.

Les règles « toujours appliquer » de Cursor actionnent cet interrupteur. Au lieu d'instructions ad hoc enfouies dans une discussion, vous définissez un ordre permanent : chaque demande doit passer par un flux de recherche scripté. La règle injecte le contexte, des contraintes et une priorité stricte des outils, permettant au modèle de se comporter comme un agent déterministe, et non comme un chatbot capricieux.

La configuration de Robin Ebers montre à quel point cela peut être agressif. Sa règle oblige Cursor à privilégier d'abord le Exa MCP pour presque tout, car Exa est « suffisamment bon » la plupart du temps et « beaucoup moins cher » que de passer du temps sur les documents officiels. À l'intérieur d'Exa, un nouvel outil de « contexte de code » doit s'exécuter avant toute recherche web générique.

Ce n'est qu'après l'échec de cette chaîne que la pile s'intensifie. La recherche Web se déverrouille comme une option secondaire, et le Ref MCP pour la documentation officielle arrive en dernier, soumis à trois conditions : - Lorsque l'utilisateur demande explicitement Ref - Lorsque les résultats Exa se contredisent - Après deux tentatives échouées pour réparer une API ou une bibliothèque externe où la documentation a probablement changé après la date limite

Ces conditions sont des garde-fous, pas des suggestions. Le modèle ne peut pas "ressentir" son chemin vers une réponse ; il doit suivre le même parcours de recherche répétable à chaque fois, ce qui réduit les hallucinations et maintient les coûts prévisibles. Vous obtenez un flux de travail que vous pouvez déboguer et affiner, au lieu d'une boîte noire qui semble parfois intelligente.

Sous le capot, tout cela est alimenté par le Model Context Protocol (MCP), qui relie de manière fluide les LLMs à des outils externes comme Exa et Ref. Le MCP standardise la manière dont les modèles découvrent, appellent et enchaînent les outils, et la Documentation Officielle du Model Context Protocol ressemble moins à un discours marketing et plus à une spécification pour transformer les LLMs en véritables agents.

Votre nouvelle configuration repose sur deux serveurs MCP reliés directement à votre éditeur : Exa MCP et Ref MCP. Au lieu de demander à un modèle de "s'il vous plaît, utilisez les documents", vous codez en dur une stratégie de recherche qui détermine quel outil fonctionne, quand et pourquoi.

Exa se trouve dans la voie chaude. Robin Ebers configure Cursor pour que le modèle privilégie toujours Exa en premier, car il est « suffisamment bon » la plupart du temps et « beaucoup moins cher » que de consulter la documentation officielle pour chaque question.

Au sein d'Exa, un nouvel outil de contexte de code effectue le travail de fond. Le modèle appelle cet outil spécifique avant toute recherche Web générique, extrayant des extraits, exemples et discussions pertinents pour le code, adaptés aux bibliothèques et aux modèles que vous utilisez réellement.

Considérez Exa comme un jeune développeur astucieux qui vit sur Stack Overflow, les problèmes GitHub et les blogs. Vous posez une question ; il revient avec trois approches plausibles, des exemples de code récents et une idée générale des changements entre la version 5.2 et la 5.3.

Ref MCP joue un rôle opposé : plus lent, plus cher et beaucoup plus autoritaire. Ref se connecte directement à la documentation officielle, à jour, pour les API et les bibliothèques, agissant comme votre couche de vérité fondamentale lorsque vous soupçonnez que la date de couper le modèle vous nuit.

La règle de Robin n'autorise Ref que dans trois cas : - Lorsque l'utilisateur demande explicitement Ref - Lorsque les résultats d'Exa se contredisent - Après deux tentatives infructueuses de réparer une API externe ou une bibliothèque où la documentation a pu changer

Cette voie d'escalade transforme Ref en l'équivalent d'ouvrir la référence API officielle lorsque les suppositions du développeur junior ne s'avèrent plus fructueuses. Vous ne gaspillez pas de tokens sur des documents en texte intégral tant que vous n'avez pas de preuves concrètes que quelque chose dans le monde réel a bougé.

Exa plus Ref crée un système de recherche à deux niveaux qui reflète la manière dont les ingénieurs expérimentés travaillent réellement. Vous consultez la sagesse de la communauté pour 80 % des problèmes, puis vous plongez dans la documentation canonique lorsque les numéros de version, les flux d'authentification ou les changements importants commencent à avoir de l'importance.

Au lieu d'un modèle halluciné générant du code "probablement correct" à partir d'un instantané de npm de 2023, vous obtenez un pipeline dirigé. Exa trouve un contexte économique, conscient du code ; Ref confirme les noms exacts des méthodes, les paramètres et les cas particuliers qui décident si votre compilation réussit ou fait brûler deux heures de plus.

La priorité dans cette pile est extrêmement simple : dire à Cursor de viser Exa en premier, à chaque fois. Robin Ebers configure sa règle "toujours appliquer" de sorte que le modèle suive une hiérarchie stricte : 1) Exa pour le contexte de code, 2) Exa pour la recherche web, 3) Référence uniquement sur des déclencheurs spécifiques. Le modèle ne choisit jamais lui-même l'ordre de ses outils.

Au sein d'Exa, la vedette est le nouvel outil de « contexte de code ». Cursor demande au modèle de l'appeler avant toute recherche générique, afin que l'IA examine les résultats pertinents au code qui correspondent à votre pile, vos frameworks et vos problèmes récents. Ce n'est que lorsque ce contexte spécialisé échoue qu'elle revient à des résultats web plus généraux.

Cet ordre de priorité est autant économique que technique. Exa est "suffisamment bon la plupart du temps" et "beaucoup moins cher" que de marteler Ref MCP ou de faire une recherche web générique pour chaque question. Vous payez pour les appels réseau et la latence, mais vous payez beaucoup plus lorsque le modèle génère du mauvais code et que vous passez 2 heures à le déboguer.

Commencer avec un outil spécialisé et moins cher réduit également les hallucinations. Lorsque Cursor impose d'abord le contexte du code d'Exa, le modèle voit de véritables dépôts, des gists récents et des schémas d'utilisation concrets avant de faire des suppositions. Cela suffit à éliminer une vaste catégorie de fabrications telles que « Je pense que cette API fonctionne comme… ».

Ref MCP se situe à la toute fin de la chaîne en tant qu'escalade de coûts élevée. Le curseur n'autorise Ref que lorsque l'une des trois conditions se déclenche : - L'utilisateur demande explicitement Ref - Les résultats d'Exa se contredisent - Deux tentatives échouées de résoudre un API externe ou une bibliothèque suggèrent des modifications de document post-coupure

Ces garde-fous empêchent l'IA de se reposer sur des recherches de documentation coûteuses et génériques pour des problèmes qui ont une réponse simple et spécifique au code. Si le contexte du code d'Exa peut vous indiquer comment `fetch` se comporte dans un SDK populaire, vous n'avez pas besoin d'une exploration complète des documents du fournisseur. Vous ne devez escalader qu'au moment où la réalité et les connaissances antérieures du modèle se heurtent.

Dans Cursor, cette logique ressemble à une petite couche de politique impitoyable. Le pseudo-code pour la règle pourrait ressembler à :

```jsonc { "alwaysApply": true, "priority": [ "exa.code_context", "exa.web_search", "ref.docs" ], "usagePolicy": { "ref.docs": { "allowedWhen": [ "demande_explicite_utilisateur", "conflit_exa_results", "après_deux_fixes_API_externes_échoués" ] } } } ```

Ref n'est accessible que lorsque vous remplissez l'une des trois conditions strictes de « briser le verre ». Tout le reste fonctionne sur Exa car c'est plus rapide et « beaucoup moins cher », comme le souligne Robin Ebers. Considérez Ref comme la ligne d'urgence vers la documentation officielle, et non comme un autre onglet de recherche.

Premier déclencheur : demande explicite de l'utilisateur. Si un développeur tape "utiliser ref" ou demande clairement une documentation officielle, la pile doit appeler Ref MCP immédiatement. Cela permet de garder les humains responsables des coûts et de la latence, au lieu de cacher des appels coûteux derrière une logique d'agent opaque.

Deuxième déclencheur : Exa se contredit. Si un résultat d'Exa indique qu'une méthode est obsolète dans la version 4 et qu'un autre l'affiche comme le chemin recommandé dans la version 5, le système signale ce conflit. À ce moment-là, Ref devient le facteur décisif, tirant des documents canoniques du fournisseur pour que le modèle cesse de deviner quelle réponse correspond à la réalité.

Le troisième déclencheur opérationnalise la sensibilisation à la limite du modèle. Lorsque l'IA soupçonne un problème d'API externe ou de bibliothèque et a déjà essayé sans succès de le résoudre deux fois, elle suppose que le monde a changé depuis l'entraînement. Ce n'est qu'après ces deux tentatives échouées que la règle permet un appel Ref pour récupérer la documentation actuelle et officielle pour ce package, SDK ou point de terminaison REST.

Ces trois conditions transforment "le modèle est probablement obsolète" d'une peur vague en un flux de travail concret. Le modèle ne peut pas silencieusement forcer des solutions aléatoires indéfiniment ; il doit soit réussir rapidement avec Exa, soit escalader via Ref sous des règles strictes. Cette structure réduit considérablement le risque de perdre un après-midi sur des guides de migration hallucinés ou des indicateurs de configuration inexistants.

Les développeurs qui souhaitent reproduire cette pile dans Cursor intègrent ces déclencheurs dans une règle « toujours appliquer » qui régit l'utilisation des outils à travers Exa MCP et Ref MCP. En arrière-plan, il ne s'agit que d'une orchestration déterministe reposant sur le Modèle de Contexte du Protocole. Pour des détails d'implémentation plus approfondis, le Protocole de Contexte de Modèle - Dépôt GitHub documente comment enregistrer des outils, imposer des priorités et maintenir Ref comme dernier recours, voie d'accès aux documentations officielles.

La discussion sur les coûts survient généralement après la réception de la facture du cloud, et non pendant que vous déboguez une intégration Stripe défaillante à 1 heure du matin. Robin Ebers renverse cette dynamique : Exa est « beaucoup moins cher » que Ref, ce qui fait que le coût devient une partie intégrante de la conception du flux de travail, et non une réflexion tardive. La pile MCP intègre ce parti pris en se basant par défaut sur l'outil de contexte de code d’Exa et en n'escaladant que lorsque c'est absolument nécessaire.

Considérez Exa + Ref comme un plan de contrôle financier, pas juste un correctif d'exactitude. Chaque appel Ref extrait des documents officiels et consomme plus de jetons, de latence et de frais d'utilisation des outils qu'une rapide requête Exa MCP contre du code réel. En intégrant la règle de priorité directement dans la règle "appliquer toujours" de Cursor, Robin intègre efficacement une politique budgétaire dans l'assistant.

Les tentatives infructueuses sont là où l'argent s'évapore discrètement. Chaque solution halluciné signifie : - Des appels LLM supplémentaires pour réexpliquer le bogue - Plus de recherches Exa ou sur le web - Des vérifications potentielles de références lorsque vous suspectez enfin des problèmes de coupure.

Réduisez ces tentatives de moitié et vous coupez l'utilisation de tokens, les appels aux outils et le temps de développement, le tout en une seule fois. Deux tentatives échouées avant d'interagir avec Ref ne sont pas seulement un critère de qualité ; c'est un frein aux coûts.

Le routage intelligent des outils devient une forme de limitation de taux pour votre portefeuille. Routez 80 à 90 % des questions via le contexte de code d'Exa, utilisez la recherche web rarement et réservez Ref pour les trois déclencheurs "casse en verre". Vous aboutissez à un système qui se comporte comme un ingénieur senior : des suppositions rapides en premier, des recherches coûteuses uniquement lorsque des contradictions ou un dérivé d'API l'exigent.

La plupart des workflows d'IA se concentrent sur le choix du modèle et ignorent complètement cette couche. La pile MCP montre que le codage d'IA durable concerne moins le choix entre GPT-4 et Claude, et plus qui répond en premier, à quelle fréquence ils essaient à nouveau, et quand ils sont autorisés à escalader.

Vous construisez un petit tableau de bord en React, suivant la suggestion d'une IA d'utiliser `componentWillReceiveProps` pour synchroniser les props dans l'état. Vous collez le code, appuyez sur enregistrer, et votre terminal s'illumine d'un avertissement rouge vif : cette méthode de cycle de vie est dépréciée et ignorée dans React 18. Votre "gratuit" assistant IA vient de vous offrir une vraie bombe à retardement.

Selon la règle Exa‑first de Robin Ebers, le premier mouvement du modèle n’est pas de deviner. Cursor achemine l’erreur par l’outil de contexte de code de Exa MCP, demandant des exemples récents de la manière dont les gens gèrent les changements de props dans React moderne. Exa renvoie un mélange de tutoriels : l’un recommande `UNSAFE_componentWillReceiveProps`, un autre privilégie `getDerivedStateFromProps`, un troisième dit « utilisez simplement les hooks ».

L'IA choisit ce qui semble le plus populaire : un refactor de composant de classe utilisant `UNSAFE_componentWillReceiveProps`. Vous réessayez. React compile, mais vos mises à jour d'état échouent et un nouveau message d'avertissement vous informe que cette méthode est obsolète et doit être évitée. Deux tentatives ratées, votre terminal est toujours en panne et votre confiance en l'IA diminue.

C'est exactement à ce moment-là que le déclencheur « deux tentatives infructueuses » s'active. La règle du Curseur permet maintenant le chemin coûteux Ref MCP. Au lieu de collecter d'autres articles de blog, le modèle appelle Ref avec une requête très spécifique : « documentation officielle actuelle de React 18+ pour répondre aux changements de props ; composants de classe vs composants fonctionnels ; API recommandées. »

Ref fait référence à la documentation officielle react.dev et fournit des recommandations canonique : les cycles de vie de classe tels que `componentWillReceiveProps` et sa variante `UNSAFE_` sont obsolètes ; le nouveau code devrait privilégier les composants fonctionnels avec `useEffect`. Il met en avant un extrait précis de la page "Synchronisation avec les effets", incluant les dernières signatures et mises en garde concernant les tableaux de dépendances.

Armé de cela, l'IA réécrit votre composant en tant que fonction :

• 1Les props s'écoulent directement dans le JSX.
• 2L'état dérivé local utilise `useState`
• 3Les effets secondaires s'exécutent dans `useEffect` en fonction de la prop pertinente.

Vous collez le nouveau code, lancez l'application et les avertissements disparaissent. Pas d'appels obsolètes, pas de méthodes de cycle de vie fantômes, pas de modèles dépassés d'un blog de 2018. Exa a géré la recherche large et peu coûteuse ; Ref est intervenu une fois que le modèle a prouvé qu'il ne pouvait pas résoudre par lui-même un changement d'API probable après la coupure.

Les agents déterministes remplacent discrètement les copilotes bavards. Au lieu qu'un seul modèle devine dans votre code, vous bénéficiez désormais de MCPs spécialisés connectés à des tâches spécifiques : recherche, documentation, problèmes, dépôts, voire déploiement.

Le stack Exa + Ref de Robin Ebers n'est que le début de cette architecture. Exa gère 90 à 95 % des appels de recherche, tandis que Ref opère derrière une politique stricte de « casser le verre » pour la documentation officielle, transformant ce qui était autrefois un prompting basé sur des impressions en un pipeline de recherche prévisible.

Dézoomez et vous verrez le même schéma dans ses autres MCP. Un MCP GitHub ne « parle pas » des problèmes ; il les récupère, relie les PR et trace les erreurs jusqu’à des commits spécifiques. Un MCP de contexte de code ne résume pas votre dépôt ; il charge des fichiers concrets, des symboles et des graphes d'appels dans la mémoire de travail du modèle.

Au lieu d'un chatbot géant, vous obtenez un réseau d'outils spécialisés et déterministes. Chaque MCP expose une surface typée restreinte—“recherchez ce code”, “récupérez ce problème”, “obtenez ces documents”—et le LLM devient un orchestrateur qui les enchaîne sous des règles strictes et des plafonds de coûts.

Ceci est une rupture nette avec le modèle d'assistant « posez n'importe quelle question ». Dans Cursor, la règle permanente de Robin transforme l'agent en un moteur de flux de travail : il doit atteindre le contexte de code Exa, puis effectuer une recherche sur le web, puis consulter Ref, dans cet ordre, sinon il se comporte mal. Pas de navigation ad hoc, pas d'APIs hallucinées à moins que tous les chemins alternatifs, moins coûteux et rationnels aient échoué.

Vu de cette manière, la future pile de développement ressemble davantage à des pipes UNIX qu'à ChatGPT. Vous connectez : - Exa pour le code et le web - Ref pour les documents canoniques - GitHub MCP pour les problèmes et les PR - Repo MCPs pour un contexte complet de l'arbre

Chaque élément reste petit, auditable et remplaçable. Vous pouvez échanger de fournisseurs de recherche, changer de sources de documents ou diriger les mêmes règles d'orchestration vers un monorepo différent sans rien reprogrammer. L'« intelligence » réside dans le routage et les politiques, et non dans un modèle mythique omniscient.

La documentation comme la **Documentation de Cursor** sert désormais de surface API pour ces agents, et pas seulement d'aide lisible par un humain. Ce changement — de l'expérience utilisateur des chatbots aux réseaux MCP déterministes et conscients du contexte — est ce qui engage enfin l'IA à fournir un codage fiable, et non des suppositions créatives.

Commencez par votre éditeur. Installez Cursor si ce n'est pas déjà fait, puis ouvrez Paramètres → Règles. Créez une nouvelle règle et définissez-la sur « appliquer toujours » pour les sessions de codage qui touchent des API externes, des frameworks ou des SDK.

Ensuite, connectez les outils. Installez le serveur Exa MCP en suivant la documentation sur exa.ai et ajoutez-le à votre configuration Cursor MCP. Faites de même pour Ref MCP à partir de son dépôt ou de son annuaire de marché, mais conservez-le comme une option secondaire, plus coûteuse.

Maintenant, encodez l'ordre de priorité sous forme de modèle standard. Utilisez un langage que le Cursor peut interpréter comme des instructions pour le modèle, par exemple :

• 1Utilisez toujours d'abord l'outil de contexte de code Exa pour toute tâche de programmation ou de débogage.
• 2Si vous avez besoin de plus d'informations, utilisez la recherche générale sur le web d'Exa.
• 3N'utilisez Ref que sur demande explicite, lorsque les résultats Exa sont contradictoires, ou après deux tentatives infructueuses de réparer une API ou une bibliothèque externe.

Vous pouvez intégrer un modèle comme celui-ci dans votre règle :

"Vous devez suivre cet ordre d'outils : 1) Exa code-contexte, 2) Exa recherche web, 3) Référence pour les documents officiels uniquement sur ces déclencheurs : l'utilisateur demande explicitement ; les résultats Exa sont contradictoires ; deux tentatives infructueuses de réparer une API externe ou une bibliothèque où des changements de documentation après la coupure du modèle sont suspectés. Préférez les outils moins chers lorsque cela est possible."

Traitez cela comme une infrastructure, pas comme une solution ponctuelle. Enregistrez la règle, activez-la pour tous les espaces de travail de codage, et versionnez-la dans vos fichiers de configuration afin que toute votre équipe puisse partager les mêmes garde-fous.

Une fois que cette pile fonctionne, votre IA cesse de deviner et commence à récupérer. Vous échangez des spirales de débogage de deux heures contre des réponses guidées par des outils en quelques minutes, et vous livrez du code qui suit les documents actuels au lieu de la folklore des modèles. Le résultat : moins de temps à lutter contre les hallucinations, plus de temps à déployer des fonctionnalités fiables avec un assistant IA sur lequel vous pouvez enfin compter.

Quel est l'empilement MCP décrit dans l'article ?

C'est une pile à deux outils utilisant l'Exa MCP pour des recherches générales et rentables, et le Ref MCP pour récupérer la documentation officielle, le tout géré par une règle de priorité à l'intérieur de l'éditeur Cursor.

Pourquoi cette pile préfère-t-elle Exa aux autres outils ?

La règle privilégie Exa car il est considérablement moins cher que les alternatives et « suffisamment bon » pour la plupart des requêtes de codage. Elle commence par l'outil spécifique de « contexte de code » d'Exa avant de se tourner vers la recherche sur le web.

Quand est-ce que le stack utilise le Ref MCP pour les documents officiels ?

Le référent est utilisé en dernier recours dans trois cas spécifiques : lorsque l'utilisateur le demande explicitement, lorsque les résultats d'Exa sont contradictoires, ou après deux tentatives infructueuses de corriger une bibliothèque/API dont la documentation est jugée obsolète.

Quel problème majeur cette pile MCP résout-elle ?

Cela résout le problème des assistants de codage IA générant du code obsolète ou incorrect (hallucinations) en raison de la date limite de leurs données d'entraînement, ce qui permet aux développeurs de gagner un temps de débogage considérable et de réduire les coûts.