D'abord la carte, ensuite la revue

Deux tâches différentes se situent de part et d’autre d’une pull request. Avant que l’agent n’écrive, il a besoin d’une carte de l’arbre qu’il s’apprête à modifier. Une fois que l’agent a ouvert une PR, quelque chose devrait lire ce changement au regard du reste du système et laisser des commentaires qu’un humain peut exploiter.

Ces tâches se ressemblent de loin car toutes deux impliquent de « comprendre la base de code » . Ce ne sont pas le même produit. L’une répond à « où cette modification devrait-elle atterrir ? » . L’autre répond à « qu’est-ce que ce diff a cassé qu’un linter ligne par ligne va manquer ? » . Les confondre produit un premier jet plus mauvais et une revue plus bruyante.

Ce texte est un guide de workflow conjoint. Maguyva est la carte que l’agent interroge en premier. Greptile est l’agent de revue qui commente la PR ensuite. Le duo est complémentaire par construction : Maguyva ne relit pas les pull requests, et Greptile ne remplace pas la couche de contexte que l’agent a utilisée pour les écrire.

Pourquoi cette répartition est utile

Un agent de code qui part de priors d’entraînement plus quelques fichiers collés inventera un chemin plausible et le modifiera. C’est l’échec du mauvais fichier, et c’est un problème de récupération. Maguyva est une couche de contexte de code MCP distante : récupération sémantique, structurelle (AST), par graphe/dépendance et textuelle, fusionnée en résultats classés, plus recherche de symboles et récupération de fichiers. Les réponses fondées reviennent sous forme de path/file.ext:line, afin que vous puissiez rejeter une erreur avant qu’un correctif n’existe. L’affirmation reste modeste : moins de modifications hallucinées. Le modèle peut toujours deviner. La première étape cesse simplement d’être une supposition.

Greptile est un agent de revue de code par IA. Selon leurs propres mots, il relit automatiquement chaque pull request avec une compréhension complète de la base de code, et positionne cela face aux linters traditionnels qui vérifient les fichiers isolément plutôt que le système entier. La configuration consiste à installer l’application GitHub ou GitLab et à sélectionner des dépôts. Il n’y a aucun index local à faire tourner. L’hébergement se fait sur Greptile Cloud (ils déclarent une conformité SOC 2 Type II, avec un rapport disponible sur demande), avec une option auto-hébergée offerte aux entreprises.

Leur propre déroulé numéroté est : se connecter et construire un graphe de dépendances de chaque fonction, classe et dépendance ; à chaque pull request, analyser le changement en utilisant ce graphe complet du dépôt et publier les résultats sous forme de commentaires de PR avec des corrections suggérées, en environ trois minutes ; chaque commentaire peut transmettre le problème à un agent de code que l’équipe utilise déjà. Ils déclarent aussi lire les commentaires humains passés sur les PR au fil du temps pour apprendre les standards de code d’une équipe et réduire les suggestions bruyantes. Leur système d’apprentissage aurait, selon eux, besoin de 2 à 3 semaines pour s’adapter.

C’est de la revue, pas de la rédaction. L’atout de Greptile est le contexte du graphe complet du dépôt sur le changement déjà atterri dans une PR, puis une boucle fermée qui envoie le résultat à Claude Code, Codex, Conductor, Cursor ou Devin. L’atout de Maguyva est la carte classée que l’agent a interrogée avant que ce changement ne soit écrit. Utilisez les deux. Ne demandez à aucun des deux de faire le travail de l’autre.

Une intégration produit de première partie Maguyva–Greptile n’est pas annoncée. Vous n’en avez pas besoin. Maguyva parle à l’agent via MCP. Greptile parle à GitHub ou GitLab via son application. Ils se rencontrent au niveau de la pull request. Pas de script de liaison, pas de cron qui relie un outil à l’autre. Le duo se passe de bash parce que chaque produit occupe déjà la surface qui lui appartient.

Ce que ceci n’est pas

Ce n’est pas un dénigrement de Greptile. Ce n’est pas une page « changez de relecteur » . Greptile a été lancé sur Hacker News le 5 mars 2024 en tant qu’entreprise Y Combinator W24, et ce fil de discussion est la façon dont beaucoup de gens ont découvert le produit. Si c’est comme cela que vous les avez trouvés, gardez-les. Cette page est la moitié avant manquante de cette boucle : ancrer l’agent pour que la PR que Greptile voit vise déjà les bons fichiers.

Les supports marketing de Greptile mettent en avant des affirmations de vitesse de revue et de détection de bugs. Traitez-les comme les propres affirmations de Greptile, pas comme des chiffres vérifiés indépendamment. Ce texte ne les répète pas comme des faits.

La couverture linguistique relève de la même honnêteté. Greptile présente son support comme couvrant tous les langages de programmation plutôt qu’une liste énumérée ; un chiffre précis n’est pas indiqué. Maguyva publie plus de 279 langages et technologies textuelles, avec une distinction technique (AST soutenu par un parseur contre texte seul) sur le site quand la question est technique. Ce sont des produits différents qui font des affirmations différentes. Ne les mélangez pas.

Les tarifs de Greptile ne sont pas indiqués dans les notes que ce texte est autorisé à utiliser. Des plans payants existent ; voir leur page de tarification. Maguyva facture par espace de travail, pas par siège. Les plans démarrent gratuitement. La page de tarification liste les niveaux publiés si vous avez besoin des chiffres d’espace de travail.

Workflow

Trois étapes nommées. Exécutez-les dans cet ordre. N’en sautez aucune la première fois que vous essayez ce duo.

1. Contexte Maguyva

Indexez un dépôt que vous connaissez déjà. Connectez le client MCP dans lequel vous écrivez déjà — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, ou un autre client compatible MCP. Maguyva propose des guides de configuration pour 24 clients MCP documentés et peut se connecter à d’autres clients prenant en charge la configuration MCP standard.

Posez une question que vous pouvez évaluer avant que quiconque n’écrive une ligne. « Où l’expiration de session est-elle gérée, et qu’est-ce qui l’appelle ? » est un meilleur premier mouvement que « corrige l’authentification » . Exigez des citations. Ouvrez les résultats file.ext:line. Suivez le symbole. Confirmez la dépendance que vous êtes sur le point de toucher.

Maguyva expose 11 outils MCP orientés client à travers la recherche, les symboles, l’analyse de dépendances, la récupération de fichiers, le contexte de dépôt et des workflows utilitaires déterministes. Quatre modes de récupération sont fusionnés en résultats classés ; find_symbol est un outil séparé quand vous connaissez déjà le nom. La documentation décrit le chemin le plus court : commencer gratuitement, indexer un dépôt que vous connaissez déjà, connecter le client, puis poser une question que vous pouvez vérifier.

Les instantanés sont horodatés, afin que l’agent puisse dire quelle version de l’arbre il lit. La limite honnête est le travail local non synchronisé. Si la modification n’existe que dans un arbre de travail et n’a pas été poussée, la carte hébergée ne la contient pas encore. Les fichiers d’instructions (CLAUDE.md, AGENTS.md) ont toujours leur place ici, pour les conventions et ce qu’il ne faut pas toucher. Ce ne sont pas une carte vivante. Utilisez-les pour le comportement. Utilisez Maguyva pour les faits.

Ne laissez pas l’agent ouvrir une PR avant que les citations n’aient survécu au contact avec le dépôt. Cette barrière est tout l’intérêt de cette étape.

2. PR de l’agent

Le même agent écrit maintenant le changement dans le client pour lequel vous payez déjà. Maguyva n’est ni un éditeur ni un relecteur. L’agent produit toujours le diff. Vous ouvrez toujours la pull request sur GitHub ou GitLab comme vous le faites déjà.

Ce qui devrait être différent, c’est le premier fichier. La PR devrait nommer le gestionnaire qui implémente réellement le comportement, l’appelant qui va casser, et le test qui échouera si le changement est faux. Si l’étape 1 a été sautée, l’étape 3 passera ses commentaires sur un changement atterri dans le mauvais paquet. Greptile peut quand même trouver des problèmes systémiques. Il ne devrait pas en plus avoir à se remettre d’un chemin halluciné.

Gardez la PR ciblée. Un premier fichier fondé n’est pas une licence pour réécrire le module. Le duo complémentaire fonctionne quand l’agent a fait un travail avec une carte, puis a demandé à un relecteur de faire un autre travail sur un diff délimité.

3. Revue Greptile

Greptile est déjà connecté au dépôt via l’application GitHub ou GitLab. Sur la nouvelle pull request, il analyse le changement en utilisant le graphe complet du dépôt qu’il a construit et publie des résultats sous forme de commentaires avec des corrections suggérées. Leurs propres supports situent ce passage à environ trois minutes.

Lisez les commentaires comme vous liriez un coéquipier attentif : ouvrez l’emplacement cité, décidez si le constat est réel, puis agissez. Là où Greptile propose « Fix with your Agent » , il envoie le problème — chemins de fichiers, numéros de ligne, code suggéré — à Claude Code, Codex, Conductor, Cursor ou Devin. « Fix All » envoie tous les problèmes de la revue d’un coup. Ils livrent aussi un MCP Greptile et un plugin Claude Code pour cette transmission. Maguyva ne figure pas sur cette liste de cibles nommées ; cette absence n’est pas un problème. Maguyva a déjà fait son travail à l’étape 1. L’agent de code qui a écrit la PR est celui qui devrait recevoir la charge utile de correction.

Attendez-vous à du bruit pendant les 2 à 3 premières semaines pendant que le système d’apprentissage de Greptile s’adapte aux commentaires que votre équipe laisse réellement. C’est leur calendrier déclaré, pas un défaut du duo. La revue humaine reste dans la boucle. Greptile est le premier passage automatisé, pas le bouton de fusion.

Si un commentaire de Greptile pointe vers un fichier que l’agent n’a jamais interrogé à l’étape 1, c’est un signal utile. Soit la carte a manqué un appelant, soit l’agent a sauté une citation. Corrigez le brouillon en fonction du commentaire. Ne désactivez pas le relecteur.

Comment garder ce duo honnête

• Maguyva d’abord, toujours. Une revue d’une PR au mauvais fichier reste une revue du mauvais fichier.
• Greptile ensuite, toujours. Un brouillon bien cité a quand même besoin d’une lecture du diff à l’échelle du système entier.
• Ne demandez pas à Maguyva de publier des commentaires de PR. Il ne le fait pas.
• Ne demandez pas à Greptile d’être la première couche de récupération de l’agent pendant qu’il choisit encore un chemin. Ce n’est pas le travail pour lequel leur application GitHub ou GitLab est câblée.
• N’inventez pas un pipeline bash qui les « synchronise » . La PR est l’interface.
• Vérifiez les deux côtés indépendamment. Indexez un dépôt que vous connaissez déjà. Posez une question que vous pouvez vérifier. Puis ouvrez une petite PR et lisez ce que Greptile commente réellement.

La boucle est ordinaire une fois qu’on la nomme. D’abord la carte. Puis la PR de l’agent. Puis la revue. Chaque produit reste du côté de la pull request où il excelle.

// map first. review second. in that order.