Najpierw mapa, potem przegląd

Po obu stronach pull requesta znajdują się dwa różne zadania. Zanim agent napisze, potrzebuje mapy drzewa, które zamierza zmienić. Gdy agent otworzy PR, coś powinno odczytać tę zmianę na tle reszty systemu i zostawić komentarze, na podstawie których człowiek może działać.

Te zadania z daleka wyglądają podobnie, bo oba dotyczą „rozumienia bazy kodu”. To nie ten sam produkt. Jedno odpowiada na pytanie „gdzie ta zmiana powinna wylądować?”. Drugie odpowiada na pytanie „co ten diff zepsuł, czego linter przeglądający linia po linii nie zauważy?”. Pomieszanie ich daje gorszy pierwszy szkic i głośniejszy przegląd.

Ten tekst jest przewodnikiem po wspólnym przepływie pracy. Maguyva to mapa, którą agent odpytuje najpierw. Greptile to agent przeglądający, który komentuje PR potem. Ta para jest uzupełniająca się z założenia: Maguyva nie przegląda pull requestów, a Greptile nie zastępuje warstwy kontekstu, której agent użył, żeby je napisać.

Dlaczego ten podział jest przydatny

Agent kodujący, który wychodzi od wiedzy wyniesionej z treningu plus kilku wklejonych plików, wymyśli wiarygodną ścieżkę i ją edytuje. To jest porażka „złego pliku” i jest to problem wyszukiwania. Maguyva to zdalna warstwa kontekstu bazy kodu oparta na MCP: wyszukiwanie semantyczne, strukturalne (AST), grafowe/zależnościowe i tekstowe łączą się w uszeregowane wyniki, plus wyszukiwanie symboli i pobieranie plików. Ugruntowane odpowiedzi wracają jako path/file.ext:line, więc możesz odrzucić chybienie, zanim powstanie łatka. Twierdzenie pozostaje skromne: mniej zhalucynowanych edycji. Model wciąż może zgadywać. Po prostu pierwszy krok przestaje być zgadywaniem.

Greptile to agent przeglądający kod oparty na AI. Ich własnymi słowami, automatycznie przegląda każdy pull request z pełnym zrozumieniem bazy kodu, przeciwstawiając to tradycyjnym linterom, które sprawdzają pliki w izolacji, a nie cały system. Konfiguracja polega na zainstalowaniu aplikacji GitHub lub GitLab i wybraniu repozytoriów. Nie ma lokalnego indeksu, którym musiałbyś zarządzać. Hostingiem jest Greptile Cloud (deklarują zgodność z SOC 2 Type II, z raportem dostępnym na żądanie), z opcją samodzielnego hostowania oferowaną firmom.

Ich własny ponumerowany przepływ wygląda tak: połączyć się i zbudować graf zależności każdej funkcji, klasy i zależności; przy każdym pull requeście analizować zmianę, używając tego pełnego grafu repozytorium, i publikować wyniki jako komentarze PR z sugerowanymi poprawkami w około trzy minuty; każdy komentarz może przekazać problem agentowi kodującemu, którego zespół już używa. Deklarują też, że czytają wcześniejsze komentarze ludzi do PR w czasie, aby nauczyć się standardów kodowania zespołu i zmniejszyć liczbę hałaśliwych sugestii. Ich system uczący się, jak deklarują, potrzebuje 2–3 tygodni na adaptację.

To przegląd, nie tworzenie szkicu. Mocną stroną Greptile jest kontekst pełnego grafu repozytorium dotyczący zmiany, która już wylądowała w PR, a potem zamknięta pętla wysyłająca wynik do Claude Code, Codex, Conductor, Cursor lub Devin. Mocną stroną Maguyva jest uszeregowana mapa, którą agent odpytał, zanim ta zmiana została napisana. Używaj obu. Nie proś żadnego z nich o wykonanie pracy drugiego.

Integracja produktowa pierwszej strony Maguyva–Greptile nie jest zadeklarowana. Nie potrzebujesz jej też. Maguyva rozmawia z agentem przez MCP. Greptile rozmawia z GitHub lub GitLab przez swoją aplikację. Spotykają się przy pull requeście. Bez skryptu łączącego, bez crona łączącego jedno narzędzie z drugim. Ta para obywa się bez bash, bo każdy produkt już zajmuje powierzchnię, która do niego należy.

Czym to nie jest

To nie jest demolka Greptile. To nie jest strona „zmień recenzenta”. Greptile wystartował na Hacker News 5 marca 2024 roku jako firma Y Combinator W24, i ten wątek jest tym, jak wiele osób po raz pierwszy poznało ten produkt. Jeśli tak właśnie ich znalazłeś, zostań przy nich. Ta strona jest brakującą przednią połową tej pętli: ugruntowanie agenta z wyprzedzeniem, żeby PR, który widzi Greptile, już celował we właściwe pliki.

Materiały marketingowe Greptile prowadzą z twierdzeniami o szybkości przeglądu i wykrywaniu błędów. Traktuj je jako własne twierdzenia Greptile, nie jako niezależnie zweryfikowane liczby. Ten tekst nie powtarza ich jako faktów.

Pokrycie językowe to ta sama uczciwość. Greptile przedstawia wsparcie jako obejmujące wszystkie języki programowania, a nie wymienioną listę; dokładna liczba nie jest podana. Maguyva publikuje wsparcie dla ponad 279 języków i technologii tekstowych, z technicznym podziałem (AST wsparte parserem kontra tylko tekst) na stronie, gdy pytanie jest techniczne. To różne produkty, składające różne twierdzenia. Nie mieszaj ich.

Ceny Greptile nie są podane w materiałach, z których może korzystać ten tekst. Płatne plany istnieją; zobacz ich stronę cen. Maguyva pobiera opłaty za workspace, nie za miejsce. Plany zaczynają się za darmo. Strona cen wymienia opublikowane poziomy, jeśli potrzebujesz liczb dotyczących workspace.

Przepływ pracy

Trzy nazwane etapy. Wykonuj je w tej kolejności. Nie pomijaj żadnego z nich za pierwszym razem, gdy próbujesz tej pary.

1. Kontekst Maguyva

Zindeksuj jedno repozytorium, które już znasz. Połącz klienta MCP, w którym już piszesz kod — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, albo innego klienta zgodnego z MCP. Maguyva ma przewodniki konfiguracji dla 24 udokumentowanych klientów MCP i może łączyć się z innymi klientami obsługującymi standardową konfigurację MCP.

Zadaj pytanie, które możesz ocenić, zanim ktokolwiek napisze linijkę. „Gdzie obsługiwane jest wygaśnięcie sesji i co to wywołuje?” to lepsze pierwsze posunięcie niż „napraw uwierzytelnianie”. Wymagaj cytatów. Otwórz wyniki file.ext:line. Podążaj za symbolem. Potwierdź zależność, której zamierzasz dotknąć.

Maguyva udostępnia 11 skierowanych do klienta narzędzi MCP w zakresie wyszukiwania, symboli, analizy zależności, pobierania plików, kontekstu repozytorium i deterministycznych przepływów narzędziowych. Cztery tryby wyszukiwania łączą się w uszeregowane wyniki; find_symbol to osobne narzędzie, gdy już znasz nazwę. Dokumentacja opisuje najkrótszą ścieżkę: zacznij za darmo, zindeksuj repozytorium, które już znasz, połącz klienta, potem zadaj jedno pytanie, które możesz sprawdzić.

Migawki są opatrzone znacznikiem czasu, więc agent może stwierdzić, którą wersję drzewa czyta. Uczciwym ograniczeniem jest niezsynchronizowana praca lokalna. Jeśli edycja istnieje tylko w drzewie roboczym i nie została wypchnięta, hostowana mapa jeszcze jej nie zawiera. Pliki instrukcji (CLAUDE.md, AGENTS.md) nadal mają tu swoje miejsce, dla konwencji i tego, czego nie dotykać. Nie są żywą mapą. Używaj ich do zachowania. Używaj Maguyva do faktów.

Nie pozwól agentowi otworzyć PR, zanim cytaty przetrwają kontakt z repozytorium. Ta bramka to cały sens tego etapu.

2. PR agenta

Ten sam agent teraz pisze zmianę w kliencie, za który już płacisz. Maguyva nie jest edytorem ani recenzentem. Agent nadal produkuje diff. Ty nadal otwierasz pull request na GitHub lub GitLabie, tak jak już to robisz.

To, co powinno być inne, to pierwszy plik. PR powinien wskazać handler, który rzeczywiście implementuje zachowanie, wywołującego, który się zepsuje, oraz test, który zawiedzie, jeśli zmiana jest błędna. Jeśli etap 1 został pominięty, etap 3 wyda swoje komentarze na zmianę, która wylądowała w złym pakiecie. Greptile wciąż może znaleźć problemy systemowe. Nie powinien musieć dodatkowo dochodzić do siebie po zhalucynowanej ścieżce.

Trzymaj PR w ryzach. Ugruntowany pierwszy plik to nie licencja na przepisanie modułu. Ta uzupełniająca się para działa, gdy agent wykonał jedną pracę z mapą, a potem poprosił recenzenta o wykonanie innej pracy na ograniczonym diffie.

3. Przegląd Greptile

Greptile jest już połączony z repozytorium przez aplikację GitHub lub GitLab. Na nowym pull requeście analizuje zmianę, używając zbudowanego przez siebie pełnego grafu repozytorium, i publikuje wyniki jako komentarze z sugerowanymi poprawkami. Ich własne materiały określają ten przebieg na około trzy minuty.

Czytaj komentarze tak, jak czytałbyś uważnego kolegę z zespołu: otwórz zacytowane miejsce, zdecyduj, czy wynik jest prawdziwy, potem działaj. Tam, gdzie Greptile oferuje „Fix with your Agent”, wysyła problem — ścieżki plików, numery linii, sugerowany kod — do Claude Code, Codex, Conductor, Cursor lub Devin. „Fix All” wysyła wszystkie problemy z przeglądu naraz. Dostarczają też Greptile MCP i wtyczkę Claude Code do tego przekazania. Maguyva nie ma na tej wymienionej liście celów; ten brak nie jest problemem. Maguyva wykonała już swoją pracę na etapie 1. Agent kodujący, który napisał PR, jest tym, który powinien otrzymać ładunek naprawczy.

Spodziewaj się szumu przez pierwsze 2–3 tygodnie, gdy system uczący się Greptile adaptuje się do komentarzy, które twój zespół rzeczywiście zostawia. To ich zadeklarowany harmonogram, nie wada tej pary. Przegląd przez człowieka pozostaje w pętli. Greptile to zautomatyzowany pierwszy przebieg, nie przycisk scalania.

Jeśli komentarz Greptile wskazuje na plik, którego agent nigdy nie odpytał na etapie 1, to przydatny sygnał. Albo mapa przeoczyła wywołującego, albo agent pominął cytat. Popraw szkic zgodnie z komentarzem. Nie wyłączaj recenzenta.

Jak zachować uczciwość tego uzupełniania się

• Maguyva zawsze pierwsza. Przegląd PR ze złym plikiem nadal jest przeglądem złego pliku.
• Greptile zawsze potem. Dobrze zacytowany szkic i tak potrzebuje odczytu diffa na poziomie całego systemu.
• Nie proś Maguyva o publikowanie komentarzy do PR. Ona tego nie robi.
• Nie proś Greptile o bycie pierwszą warstwą wyszukiwania agenta, gdy ten wciąż wybiera ścieżkę. To nie jest praca, do której zbudowana jest ich aplikacja GitHub lub GitLab.
• Nie wymyślaj pipeline’u bash, który je „synchronizuje”. PR jest interfejsem.
• Weryfikuj obie strony niezależnie. Zindeksuj repozytorium, które już znasz. Zadaj jedno pytanie, które możesz sprawdzić. Potem otwórz mały PR i przeczytaj, co Greptile faktycznie komentuje.

Gdy nadać temu nazwę, pętla staje się zwyczajna. Najpierw mapa. Potem PR agenta. Potem przegląd. Każdy produkt zostaje po tej stronie pull requesta, w której jest dobry.

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