Vai al contenuto
cd /blog

Prima la mappa, poi la revisione

[Ecosystem] [Workflow] [Code Review]

> Fonda l'agente di coding su una mappa del repository prima che scriva. Lascia che Greptile revisioni la pull request dopo. Una coppia complementare, non una sostituzione.

Due lavori diversi si trovano ai due lati di una pull request. Prima che l’agente scriva, ha bisogno di una mappa dell’albero che sta per cambiare. Dopo che l’agente apre una PR, qualcosa dovrebbe leggere quella modifica contro il resto del sistema e lasciare commenti su cui un umano può agire.

Questi lavori sembrano simili da lontano perché entrambi coinvolgono ‘capire la codebase’. Non sono lo stesso prodotto. Uno risponde a ‘dove dovrebbe atterrare questa modifica?’. L’altro risponde a ‘cosa ha rotto questo diff che un linter riga per riga si perderà?’. Confonderli produce una prima bozza peggiore e una revisione più rumorosa.

Questo articolo è una guida a un workflow congiunto. Maguyva è la mappa che l’agente interroga per primo. Greptile è l’agente di revisione che commenta la PR dopo. La coppia è complementare per costruzione: Maguyva non revisiona pull request, e Greptile non sostituisce il livello di contesto che l’agente ha usato per scriverle.

Perché questa suddivisione è utile

Un agente di coding che parte da priori di addestramento più qualche file incollato inventerà un percorso plausibile e lo modificherà. Questo è il fallimento del ‘file sbagliato’, ed è un problema di recupero. Maguyva è un livello di contesto della codebase MCP remoto: recupero semantico, strutturale (AST), a grafo/dipendenze e testuale fuso in risultati classificati, più ricerca di simboli e recupero di file. Le risposte fondate tornano come path/file.ext:line, così puoi rifiutare un errore prima che esista una patch. L’affermazione resta modesta: meno modifiche allucinate. Il modello può ancora indovinare. È solo che il primo passo smette di essere un’indovinello.

Greptile è un agente di revisione del codice basato su AI. Nelle loro stesse parole, revisiona automaticamente ogni pull request con comprensione completa della codebase, e lo contrappone ai linter tradizionali che controllano i file isolatamente invece che l’intero sistema. La configurazione consiste nell’installare l’app GitHub o GitLab e selezionare i repository. Non c’è nessun indice locale da gestire. L’hosting è Greptile Cloud (dichiarano conformità SOC 2 Type II, con un report disponibile su richiesta), con un’opzione self-hosted offerta alle aziende.

Il loro flusso numerato è: connettersi e costruire un grafo delle dipendenze di ogni funzione, classe e dipendenza; a ogni pull request, analizzare la modifica usando quel grafo completo del repository e pubblicare i risultati come commenti PR con correzioni suggerite, in circa tre minuti; ogni commento può passare il problema a un agente di coding che il team già usa. Dichiarano anche di leggere nel tempo i commenti umani precedenti sulle PR, per imparare gli standard di codice di un team e ridurre i suggerimenti rumorosi. Il loro sistema di apprendimento, secondo quanto dichiarano, ha bisogno di 2-3 settimane per adattarsi.

Questa è revisione, non stesura. Il punto di forza di Greptile è il contesto del grafo completo del repository sulla modifica già atterrata in una PR, seguito da un ciclo chiuso che invia il risultato a Claude Code, Codex, Conductor, Cursor, o Devin. Il punto di forza di Maguyva è la mappa classificata che l’agente ha interrogato prima che quella modifica venisse scritta. Usali entrambi. Non chiedere a nessuno dei due di fare il lavoro dell’altro.

Un’integrazione di prodotto di prima parte tra Maguyva e Greptile non è dichiarata. Non ti serve neanche. Maguyva parla con l’agente via MCP. Greptile parla con GitHub o GitLab tramite la propria app. Si incontrano alla pull request. Nessuno script collante, nessun cron che collega uno strumento all’altro. La coppia fa a meno di bash perché ogni prodotto sta già sulla superficie che gli appartiene.

Cosa non è questo

Questa non è una demolizione di Greptile. Non è una pagina ‘cambia revisore’. Greptile è stato lanciato su Hacker News il 5 marzo 2024 come azienda Y Combinator W24, e quel thread è come molte persone hanno conosciuto per la prima volta il prodotto. Se è così che li hai trovati, continua a usarli. Questa pagina è la metà anteriore mancante di quel ciclo: fondare l’agente in anticipo, così che la PR vista da Greptile miri già ai file giusti.

I materiali di marketing di Greptile guidano con affermazioni su velocità di revisione e cattura di bug. Trattale come affermazioni proprie di Greptile, non come numeri verificati in modo indipendente. Questo testo non le ripete come fatti.

La copertura linguistica è lo stesso tipo di onestà. Greptile inquadra il supporto come copertura di tutti i linguaggi di programmazione invece che come un elenco enumerato; un numero preciso non è indicato. Maguyva pubblica supporto per oltre 279 lingue e tecnologie basate su testo, con una suddivisione tecnica (AST supportato da parser contro solo testo) sul sito quando la domanda è tecnica. Sono prodotti diversi che fanno affermazioni diverse. Non mescolarle.

I prezzi di Greptile non sono indicati nei materiali che questo testo può usare. I piani a pagamento esistono; vedi la loro pagina prezzi. Maguyva addebita per spazio di lavoro, non per posto. I piani iniziano gratis. La pagina prezzi elenca i livelli pubblicati se ti servono i numeri dello spazio di lavoro.

Workflow

Tre fasi con un nome. Eseguile in questo ordine. Non saltarne nessuna la prima volta che provi la coppia.

1. Contesto Maguyva

Indicizza un repository che già conosci. Collega il client MCP in cui già scrivi — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, o un altro client compatibile con MCP. Maguyva ha guide di configurazione per 24 client MCP documentati e può connettersi ad altri client che supportano la configurazione MCP standard.

Fai una domanda che puoi valutare prima che chiunque scriva una riga. ‘Dove viene gestita la scadenza della sessione, e cosa la chiama?’ è una prima mossa migliore di ‘sistema l’autenticazione’. Esigi citazioni. Apri i risultati file.ext:line. Segui il simbolo. Conferma la dipendenza che stai per toccare.

Maguyva espone 11 strumenti MCP rivolti al cliente per ricerca, simboli, analisi delle dipendenze, recupero file, contesto del repository e workflow di utilità deterministici. Quattro modalità di recupero vengono fuse in risultati classificati; find_symbol è uno strumento separato quando già conosci il nome. La documentazione descrive il percorso più breve: iniziare gratis, indicizzare un repository che già conosci, collegare il client, poi fare una domanda che puoi verificare.

Gli snapshot hanno un timestamp, così l’agente può dire quale versione dell’albero sta leggendo. Il limite onesto è il lavoro locale non sincronizzato. Se la modifica esiste solo in un working tree e non è stata pushata, la mappa ospitata ancora non la contiene. I file di istruzioni (CLAUDE.md, AGENTS.md) trovano ancora posto qui, per convenzioni e per ciò che non va toccato. Non sono una mappa viva. Usali per il comportamento. Usa Maguyva per i fatti.

Non lasciare che l’agente apra una PR prima che le citazioni sopravvivano al contatto con il repository. Quel cancello è tutto il senso di questa fase.

2. PR dell’agente

Lo stesso agente ora scrive la modifica nel client per cui già paghi. Maguyva non è un editor né un revisore. L’agente continua a produrre il diff. Tu continui ad aprire la pull request su GitHub o GitLab come già fai.

Ciò che dovrebbe essere diverso è il primo file. La PR dovrebbe nominare l’handler che implementa davvero il comportamento, il chiamante che si romperà, e il test che fallirà se la modifica è sbagliata. Se la fase 1 è stata saltata, la fase 3 spenderà i suoi commenti su una modifica atterrata nel pacchetto sbagliato. Greptile può comunque trovare problemi sistemici. Non dovrebbe anche doversi riprendere da un percorso allucinato.

Tieni la PR circoscritta. Un primo file fondato non è una licenza per riscrivere il modulo. Questa coppia complementare funziona quando l’agente ha fatto un lavoro con una mappa, e poi ha chiesto a un revisore di fare un altro lavoro su un diff delimitato.

3. Revisione Greptile

Greptile è già connesso al repository tramite l’app GitHub o GitLab. Sulla nuova pull request analizza la modifica usando il grafo completo del repository che ha costruito, e pubblica i risultati come commenti con correzioni suggerite. I loro materiali collocano questo passaggio a circa tre minuti.

Leggi i commenti come leggeresti un collega attento: apri la posizione citata, decidi se il risultato è reale, poi agisci. Dove Greptile offre ‘Fix with your Agent’, invia il problema — percorsi di file, numeri di riga, codice suggerito — a Claude Code, Codex, Conductor, Cursor, o Devin. ‘Fix All’ invia tutti i problemi della revisione in una volta. Forniscono anche un Greptile MCP e un plugin per Claude Code per quel passaggio. Maguyva non è su quella lista di destinazioni nominate; quell’assenza non è un problema. Maguyva ha già fatto il suo lavoro nella fase 1. L’agente di coding che ha scritto la PR è quello che dovrebbe ricevere il payload di correzione.

Aspettati rumore nelle prime 2-3 settimane mentre il sistema di apprendimento di Greptile si adatta ai commenti che il tuo team lascia davvero. Questo è il loro programma dichiarato, non un difetto della coppia. La revisione umana resta nel ciclo. Greptile è il primo passaggio automatizzato, non il pulsante di merge.

Se un commento di Greptile punta a un file che l’agente non ha mai interrogato nella fase 1, è un segnale utile. O la mappa ha perso un chiamante, o l’agente ha saltato una citazione. Correggi la bozza in base al commento. Non disattivare il revisore.

Come mantenere onesto questo complemento

  • Maguyva sempre prima. Una revisione di una PR con il file sbagliato resta comunque una revisione del file sbagliato.
  • Greptile sempre dopo. Una bozza ben citata ha comunque bisogno di una lettura del diff a livello dell’intero sistema.
  • Non chiedere a Maguyva di pubblicare commenti sulle PR. Non lo fa.
  • Non chiedere a Greptile di essere il primo livello di recupero dell’agente mentre sta ancora scegliendo un percorso. Non è il lavoro per cui è collegata la loro app GitHub o GitLab.
  • Non inventare una pipeline bash che li ‘sincronizza’. La PR è l’interfaccia.
  • Verifica entrambi i lati in modo indipendente. Indicizza un repository che già conosci. Fai una domanda che puoi verificare. Poi apri una piccola PR e leggi cosa commenta davvero Greptile.

Il ciclo è ordinario una volta che gli si dà un nome. Prima la mappa. Poi la PR dell’agente. Poi la revisione. Ogni prodotto resta sul lato della pull request in cui è bravo.

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

Letture correlate

Altro dal diario di sviluppo di Maguyva