Inżynieria agentowa i zewnętrzny cykl: Jak Antigravity oraz Agents CLI pasują do tego modelu.

Kolejny etap rozwoju sztucznej inteligencji zależy mniej od lepszych modeli, a bardziej od doskonalszych systemów inżynieryjnych. Na konferencji Sequoia Ascent 2026 Andrej Karpathy opisał przesuw branży od programowania opartego na intuicji ku inżynierii agentowej. W tej dziedzinie ludzie opracowują specyfikacje, pętle oceny oraz zasady bezpieczeństwa, natomiast agenci zajmują się realizacją określonych zadań.

Zmiana ta ma znaczenie, ponieważ sztuczna inteligencja nie zastępuje dyscypliny inżynierii oprogramowania – ona jedynie wzmocnia już istniejącą dyscyplinę. Badania DORA przeprowadzone przez Google oraz powiązane z nimi wytyczne dotyczące platform wskazują na to samo: organizacje posiadające solidne podstawy inżynieryjne osiągają większe korzyści z procesów pracy wspomaganych przez sztuczną inteligencję niż te, których procesy są niestabilne, a weryfikacja słaba. Choć narzędzia do rozwoju przy użyciu sztucznej inteligencji są powszechnie stosowane, zaufanie do nich nie jest tak duże. Czynnikiem ograniczającym przestał być sam model, a stał się system wokół niego: specyfikacje, metody oceny, proces wdrażania oraz warstwa zarządzania. Inżynieria agentowa to praktyka budowania takiego systemu.

Co oznacza inżynieria agentowa

Krótko mówiąc, jest to uporządkowany sposób prowadzenia rozwoju z wykorzystaniem sztucznej inteligencji, w którym ludzie odpowiadają za architekturę, jakość i poprawność, podczas gdy agenci zajmują się zadaniami implementacyjnymi w określonych granicach. Karpathy wskazał trzy filary tego podejścia.

Najpierw specyfikacje. Zanim agent napisze jakikolwiek kod, inżynier określa cel, ograniczenia oraz kryteria sukcesu w formie specyfikacji czytelnej dla maszyn. Ustrukturyzowana umowa pomiędzy człowiekiem a agentem zastępuje niejasne instrukcje.

Ocena przed zaufaniem. Jeden udany test nic nie mówi o niezawodności. Agenci muszą być testowani na ustrukturyzowanych zbiorach danych do oceny, ocenianych za pomocą metryk oraz metod wykorzystujących LLM jako sędziego, aby zapewnić powtarzalność wyników przed wdrożeniem.

Zabezpieczenia i środowiska izolowane. Agent powinien znajdować się w bezpiecznym środowisku izolowanym z wyraźnymi uprawnieniami, elementami do łączenia narzędzi oraz mechanizmami kontrolnymi, aby jego działanie nie mogło przebiegać bez nadzoru. Obecnie tylko 12% projektów pilotażowych agentów AI w przedsiębiorstwach trafia do fazy produkcji, a winą nie są głównie modele. Główne luki w infrastrukturze to brak środowisk izolowanych, brak skanowania danych poufnych oraz brak mechanizmów kontrolnych.

Jaki jest obecny poziom narzędzi programistycznych

Każda uczciwa ocena zaczyna się od docenienia tego, co dzisiejsze narzędzia do programowania z wykorzystaniem AI robią dobrze, a wyniki są imponujące.

Siągają one doskonałych rezultatów w zadańach wymagających wielokrotnego działania: dzieleniu zadań na etapy, edycji kilku plików, wykonywaniu poleceń w terminalu oraz korygowaniu błędów kompilatora. Dawno przekroczyły już prostą generację kodu i funkcję autodopisywania.

Pętla wewnętrzna stanowi jednak tylko połowę problemu. Zespoły korporacyjne nie pytają już, czy agent potrafi pisać i edytować kod, ponieważ w 2026 roku niemal każde ważne narzędzie potrafi to robić. Trudniejszym zagadnieniem jest pętla zewnętrzna: jak organizacja ocenia, wdraża, monitoruje i zarządza agentami po tym, jak opuszczą lokalny terminal programisty. Wtedy właśnie zmienia się temat dyskusji. Różnica strukturalna wygląda następująco:

To wcale nie oznacza, że pozostałe narzędzia są gorsze. Jako silniki do wykonywania zadań w ramach pętli wewnętrznej pozostają one wśród najlepszych dostępnych rozwiązań. Jednak generowanie kodu to tylko punkt wyjścia, a narzędzia dostosowane do lokalnego terminala programisty nie są pierwotnie zaprojektowane do zarządzania całym cyklem życia agentów w pętli zewnętrznej. Aby odnieść sukces w 2026 roku, potrzeba czegoś więcej niż tylko zdolnych agentów – wymagana jest infrastruktura do ich oceny, wdrażania i zarządzania w środowisku produkcyjnym.

Agents CLI jako wejście

Podejście Google opiera się na jednej decyzji projektowej. Agents CLI ma służyć do współpracy z dowolnym asystentem kodowania, a to jest jego zaleta, a nie wada. Podczas instalacji dodaje siedem podstawowych umiejętności opracowanych na bazie Agent Development Kit (ADK), obejmujących tworzenie szkieletów, ocenę, ocenianie za pomocą LLM jako sędziego, konfigurację w czasie wykonywania, rozgłoszenie w Cloud Run oraz możliwości obserwacji w Cloud Trace. Użytkownik Claude Code lub Cursor może uruchamiać agents-cli scaffold, agents-cli eval i agents-cli deploy mniej więcej z taką samą łatwością jak użytkownik Antigravity.

To celowe. Google nie konkuruje na poziomie generowania kodu. Stawia na to, że wartość inżynierii opartej na agentach przeniesie się z frontendu, gdzie pisany jest kod, do backendu, gdzie agenty są uruchamiane, monitorowane i zarządzane. Niezależnie od tego, jaki frontend wybierze programista, polecenia CLI prowadzą w to samo miejsce:

• agents-cli deploy służy do wdrażania na Cloud Run, GKE lub Agent Engine, które wszystkie należą do GCP.
• agents-cli observe wysyła dane telemetryczne do Cloud Trace i BigQuery, również w ramach GCP.
• agents-cli publish rejestruje agenty w Agent Registry, co również odbywa się w GCP.
• Szczegóły dotyczące zarządzania, w tym Model Armor, Agent Identity oraz zasady bezpieczeństwa, również działają w GCP.

CLI stanowi wejście do systemu, a GCP jest jego końcowym celem. Każdy asystent kodowania, który go przyjmuje, staje się klientem GCP w procesie tworzenia produktu. Dlatego fraza „działa również z Cursor” wspiera tę strategię, zamiast jej podważać: Google nie potrzebuje, aby ktoś zmienił edytor, wystarczy, że produkcja będzie uruchamiana w GCP, a CLI sprawia, że jest to najprostsza droga dla każdego narzędzia.

Trzy warstwy koncentryczne

Ekosystem Google składa się z trzech warstw wzajemnie powiązanych. Każda z nich dodaje nowe możliwości, przy czym żadna nie wymaga porzucenia istniejących narzędzi.

Najgłębszą warstwą jest Agents CLI, kompatybilny z Cursor, Claude Code, Codex, Copilot, Antigravity lub innymi narzędziami obsługującymi wstrzykiwanie umiejętności. Oferuje on standardowy sposób tworzenia struktury projektu (agents-cli scaffold), uporządkowaną ocenę przeprowadzaną przez algorytm LLM (agents-cli eval), rozwiązanie problemu wdrożenia do Cloud Run lub GKE za pomocą jednego polecenia (agents-cli deploy) oraz automatyczne ustawienie funkcji obserwacyjnych Cloud Trace (agents-cli observe). Brakuje mu natomiast możliwości orkiestracji wielu agentów, tworzenia trwałego kontekstu oraz wbudowanych pętli weryfikacyjnych. Przekaz skierowany do użytkowników brzmi: zachowaj swój ulubiony edytor, uzyskaj powtarzalną ścieżkę od prototypu do wersji produkcyjnej i zaakceptuj fakt, że produkcja odbywa się na GCP.

Kwarstwa chmurowa jest wymagana przez każde narzędzie wykorzystujące Agents CLI, ponieważ to tam faktycznie działają agenci. Składa się z:

• Cloud Run, GKE oraz platformy agentów do skalowalnego zarządzanego hostingu
• Cloud Trace, służącego do pełnego śledzenia ścieżki wykonywania z telemetrią zgodną z standardem OTel
• BigQuery Agent Analytics, umożliwiającego tworzenie paneli kontrolnych dla całej grupy zainstalowanych agentów
• Agent Registry, centralnego katalogu do zarządzania, wersjonowania i udostępniania agentów
• Model Armor, który zapobiega wyciekom danych i filtrowa niebezpieczną treść
• Agent Identity, oferującego kryptograficzne identyfikatory powiązane z weryfikowalnymi tożsamościami ludzkimi lub podmiotami usługowymi
• Protokołu Agent2Agent (A2A), służącego do komunikacji między agentami podczas koordynacji grupy

Rozumowanie polega na tym, że samodzielne asystenty kodowania zazwyczaj polegają na zewnętrznej infrastrukturze chmurowej do wdrażania w produkcji, monitorowania i zarządzania, a także nie oferują zintegrowanego środowiska działania dla przedsiębiorstw. To kwestia strukturalna, a nie konkurencyjna. Claude Code nie konkujuje z Cloud Run, ponieważ oba znajdują się na różnych poziomach.

Czym wyróżnia się Antigravity

Jeśli wszyscy mają podagenty i pliki kontekstowe, to co odróżnia Antigravity? Odpowiedzią nie jest pojedyncza funkcja – to integracja pionowa z warstwą produkcyjną.

Podagenty w Claude Code działają wewnątrz terminala: piszą kod, uruchamiają testy i generują wyniki. Rozwijanie tego kodu, monitorowanie go w czasie rzeczywistym, zarządzanie zespołem agentów oraz koordynacja ich działania pomiędzy różnymi usługami spoczywa na użytkowniku, ponieważ Claude Code nie wie nic o instancjach Cloud Run, pipeline’u obserwowalności ani politykach zarządzania. To narzędzie do rozwoju oprogramowania. Podagenty Antigravity potrafią robić więcej:

• Rozwijają kod bezpośrednio w Cloud Run, GKE lub na platformie agentów za pomocą Agents CLI, ponieważ ten interfejs jest dostarczany przez producenta, a nie stanowi dodatku od third party.
• Dostępne są zapytania do telemetryki Cloud Trace podczas debugowania, gdyż Antigravity potrafi odczytywać dane obserwowalności GCP.
• Zarejestrowują ukończone agenty w Agent Registry, ponieważ publikacja jest integralną częścią ich procesu pracy.
• Koordynują działanie zainstalowanych agentów za pomocą protokołu A2A, ponieważ warstwa komunikacji należy do tego samego ekosystemu.

Podagenty Claude Code to potężne narzędzia do rozwoju, natomiast podagenty Antigravity to narzędzia do rozwoju świadome środowiska produkcyjnego, ponieważ korzystają z tego samego zestawu narzędzi od dostawcy. Wskazuje się na cztery funkcje, których obecnie nie posiadają inne narzędzia:

1. Kontynuowość na wielu powierzchniach: jeden kontekst agenta obejmuje IDE na pulpicie, interfejs wiersza poleceń, SDK do użycia programowego oraz zarządzaną API. Praca może rozpocząć się w IDE, kontynuować w terminalu i zostać uruchomiona z systemu CI/CD. Claude Code funkcjonuje głównie w terminalu, natomiast Cursor skupia się na IDE.
2. Integracja CLI z agentami pierwszej strony: funkcje scaffold, eval, deploy i observe zostały opracowane wspólnie z Antigravity, dzięki czemu agent doskonale zna interfejs wiersza poleceń i może łączyć polecenia dotyczące całego cyklu życia aplikacji bez konieczności specjalnej konfiguracji.

Kontekst świadomy GCP. Agenci mogą pobierać dane z Cloud Trace, wpisy z Agent Registry oraz metadane dotyczące implementacji do swojego kontekstu pracy, dzięki czemu agent rozwiązujący problem w środowisku produkcyjnym może przeczytać dane telemetryczne, przejrzeć konfigurację zainstalowanego agenta i zaproponować naprawy w ramach jednej sesji.

Zdolność odkrywania w środowisku korporacyjnym. Wiele niestandardowych agentów pozostaje odizolowanych za prywatnymi adresami URL endpointów, dostępnymi wyłącznie dla ich twórców i wymagających ręcznego udostępniania uprawnień. Natywny pipeline publikacji rozwiązuje ten problem: polecenie CLI do rejestracji agenta w Gemini Enterprise uruchamia agents-cli publish, a agent pojawia się jako bezpieczne, dostępne narzędzie w aplikacji Gemini Enterprise w całej organizacji. Natywny system IAM zarządza dostępem, dzięki czemu zespoły mogą go używać bez konieczności tworzenia własnej infrastruktury.

Porównanie ekosystemów

Aby ukonkretnić porównanie, poniższa tabela pokazuje, w których obszarach narzędzia są równoważne, a gdzie się różnią.

W górnej części porównania trzy te ekosystemy są podobne pod względem architektury – oferują one dobrą generację kodu, równoległą orkiestrację podagentów oraz zarządzane środowiska chmurowe do wykonywania zadań długotrwałych. W dolnej części Google podkreśla dodatkową wartość korporacyjną swoich rozwiązań. Inne platformy przenoszą kod, dane i dane uwierzytelniające do własnych, zamkniętych środowisk wykonawczych dostarczanych przez third party, natomiast Google umożliwia organizacjom wykonywanie, identyfikowanie, uwierzytelnianie, zarządzanie i monitorowanie agentów w obrębie ich własnego środowiska Google Cloud za pomocą Agent Runtime, Agent Identity, Model Armor i Agent Registry. Ta różnica jest widoczna w praktyce: wbudowana telemetria GCP, zintegrowane narzędzia do wdrażania na czterech poziomach oraz gotowe rozwiązania do zarządzania modelami.

Mówiąc prościej, możliwości lokalnego obiegu wewnętrznego są się rozwijając, natomiast to warstwa infrastruktury stanowi obszar, w którym integracja pionowa tworzy luki.

Jak podjąć decyzję

Ramy decyzyjne dla liderów i inżynierów są proste. Zespół skupiony głównie na przyspieszeniu obiegu wewnętrznego powinien pozostać przy swoich obecnych narzędziach. Claude Code, Cursor i Copilot są doskonałe i stale się udoskonalają co miesiąc. Można dodać Agents CLI ze względu na jego możliwości dotyczące całego cyklu życia aplikacji, z implementacją w GCP, gdy zespół będzie gotowy.

Organizacja przechodząca od kodowania wspomaganego przez AI do prac z wykorzystaniem agentów staje przed innymi wymaganiami. Zarządzanie flotą, jakość kierowana ocenami, regulacje w branżach podlegających nadzorowi oraz koordynacja wielu agentów wymagają innej architektury, a Google należy do nielicznych dostawców oferujących pionowo zintegrowany zestaw narzędzi obejmujący agenty do kodowania, procesy oceny, implementację, monitorowanie oraz zarządzanie.

Sytuacja ta nie zależy od przewagi modeli, ponieważ modele się ze sobą zbiegają. Zależy natomiast od integracji infrastruktury: od odległości pomiędzy pisaniem kodu agenta a obsługą flot agentów w środowisku produkcyjnym. Google skrócił tę odległość bardziej niż ktokolwiek inny, niezależnie od tego, z jakim edytorem zaczyna pracę dana zespół.