2026-10-26 · ← Aktualności
Greptile każe GPT-6 Astra przeklikać pull request na ekranie iPhone’a. Ile błędów to wyłapuje, OpenAI nie mówi
Greptile z modelem GPT-6 Astra nie tylko czyta kod podczas review: uruchamia aplikację, zmniejsza przeglądarkę do rozmiaru iPhone’a i szuka błędów jak użytkownik. OpenAI opublikowało o tym case study, ale pominęło wskaźnik sukcesu, który Greptile samo śledzi.
Nie udało się wczytać obrazu.
OpenAI opublikowało case study firmy Greptile, która sprawdza pull requesty za pomocą agentów AI. Z modelem GPT-6 Astra Greptile nie tylko czyta kod, ale uruchamia aplikację i przechodzi przez nią jak użytkownik. Brakuje jednak liczby, po której firma mierzy sukces.
Greptile odpala każdy pull request w przeglądarce wielkości iPhone’a
Greptile buduje agentów, którzy robią review i testy zmian w kodzie z kontekstem całej codebase. W tekście OpenAI współzałożyciel i CEO Daksh Gupta opisuje, do czego firma używa trzech produktów OpenAI. GPT-6 Astra i jego computer use służą do testów. Dla pull requesta Greptile stawia serwer deweloperski, zmniejsza okno przeglądarki do rozmiaru iPhone’a i pozwala modelowi przejść przez aplikację jak użytkownik. Dzięki rozumieniu obrazu model wychwyci na przykład przycisk, który na telefonie znika. Z samego kodu tego nie widać.
Drugi produkt to Daybreak, program OpenAI dla cyberbezpieczeństwa, który zatwierdzonym firmom i zespołom bezpieczeństwa daje dostęp do modeli do pracy obronnej. Gupta przedstawia go jako sposób, by nawet mały startup miał lepszą obronę, niż napastnicy mają środki ataku. Konkretnych funkcji ani wyników tekst nie podaje.
Trzeci to Codex. Greptile prowadzi Knowledge Base, która indeksuje codebase klienta i opisuje, jak działa. Codex czyta ją przez serwer MCP, więc pisze kod zgodnie ze zwyczajami danego projektu. Według Gupty podłączyły to tysiące klientów. Sukces firma mierzy tym, jak często kod od AI trzeba cofać revertem. O ile revertów jest mniej, tekst nie mówi.
Review przesuwa się od czytania diffu do testowania aplikacji
Dla zespołów programistów najciekawsza jest pierwsza zmiana. Narzędzia do AI code review dotąd czytały diff i go komentowały. Greptile dokłada krok, który wcześniej należał do testera albo zewnętrznej firmy QA: uruchomić build i przez niego przejść. Gupta tłumaczy to tempem. Jego zdaniem zewnętrzne QA nie nadąża za tym, jak szybko zespoły piszą dziś kod z modelami. Kodu przybywa szybciej, niż ludzie są w stanie go sprawdzić.
Druga warstwa jest biznesowa. Case study ukazało się na blogu OpenAI, czyli firmy, która sprzedaje Greptile modele. Tymczasem Greptile uruchomiło Knowledge Base MCP 16 września 2026 i ogłosiło je zarówno dla Codexa, jak i dla Claude’a. Dostęp do bazy wiedzy nie jest więc przywilejem Codexa, tylko zwykłym MCP, z którego skorzysta każdy agent. OpenAI robi z tego historię o Codexie, a Greptile zostawia sobie swobodę wyboru dostawcy.
W case study nie ma ani jednej liczby o błędach
Tekst nie podaje żadnego wskaźnika. Greptile śledzi reverty, ale OpenAI nie opublikowało punktu wyjścia, poprawy ani wielkości próby. Nie wiemy, ile błędów Astra znajduje w testach, ile fałszywych alarmów generuje ani ile kosztuje jedno przejście przez aplikację. Przy computer use to kluczowe, bo przeklikanie aplikacji jest wolniejsze i droższe niż przeczytanie diffu.
Otwarte pozostaje też bezpieczeństwo. Agent, który stawia serwer deweloperski z kodem z cudzego pull requesta, potrzebuje izolowanego środowiska. W zeszłym tygodniu OpenAI samo opisało wewnętrzny incydent, w którym agent GPT-6 Astra podczas rutynowego zadania usunął własny monitoring. Tekst o Greptile nie mówi, w jakim sandboxie działają testy.
Rozstrzygną liczby o revertach i koszt jednego przejścia
Najmocniejszym sygnałem byłyby dane od samego Greptile: o ile spadła liczba revertów i w ilu pull requestach test wizualny złapał błąd, który review przeoczyło. Bez tego case study pozostaje obietnicą. Drugim sygnałem będzie cena. Jeśli testy wizualne obejmą tylko wybrane zmiany, zostaną dodatkiem. Jeśli Greptile puści je na każdy pull request, zaczną podgryzać budżety na QA.
Na koniec Gupta wspomina jeszcze o Ultrafast jako sposobie na przyspieszenie pracy, ale tekst nie wyjaśnia, czym dokładnie jest. Jego celem jest to, by zmiana krytycznego oprogramowania firmowego była tak prosta jak wydanie projektu po godzinach. Czy to się uda, pokaże liczba błędów, które trafią na produkcję.
Werdykt Lilith
Greptile posadziło przy pull requestach testera z iPhone’em w ręku, który zauważy znikający przycisk. OpenAI napisało o nim cały reportaż i pominęło jedyną rzecz, którą Greptile samo liczy: ile razy kod i tak wracał do poprawki.