Google Antigravity: agent, który sam pisze, uruchamia i sprawdza kod

Prośba „napisz prostą listę zadań w przeglądarce” brzmi jak zadanie na godzinę, dopóki nie okaże się, że trzeba jeszcze uruchomić plik, sprawdzić, czy przycisk działa po odświeżeniu strony, i cofnąć zmianę, która zepsuła zapisywanie. Antigravity zostało pomyślane właśnie do tej pętli: agent planuje, wykonuje polecenia systemowe, czyta i zapisuje pliki, steruje przeglądarką Chrome i przedstawia wynik jako artefakty do przejrzenia, zamiast wysypywać ścianę kodu do skopiowania. (Antigravity 2.0 - Overview)

Nazwa bywa myląca, bo pod nią kryje się dziś kilka różnych rzeczy. Poniżej ścieżka od zera dla osoby, która chce mieć działający efekt: wybór właściwego wariantu, wymagania i dostępność regionalna, instalacja na Windows, macOS i Linux, logowanie, pierwszy projekt, praktyczne zadanie z gotowym promptem i kryteriami odbioru, uprawnienia agenta, limity oraz odinstalowanie.

Materiał opiera się na dokumentacji producenta w serwisie antigravity.google. Procedura nie została uruchomiona na maszynie testowej w ramach tego opracowania - opisy ekranów i skrótów pochodzą z dokumentacji.

Co powstanie na koniec

Zainstalowana i zalogowana aplikacja Antigravity, jeden skonfigurowany projekt wskazujący na lokalny folder, świadomie ustawione uprawnienia agenta oraz jedna wykonana i sprawdzona zmiana w małej aplikacji webowej - lista zadań w HTML, CSS i JavaScripcie, bez zaplecza serwerowego, z zapisem w przeglądarce. To układ do pracy nad kodem i zadaniami wiedzy, a nie zamiennik znajomości technologii, w której się pracuje.

Kilka produktów pod jedną nazwą

Rozróżnienie jest konieczne, bo instrukcje krążące w sieci mieszają wersje z listopada 2025 z obecną.

Antigravity 2.0 to samodzielna aplikacja desktopowa dla macOS, Linuksa i Windows, opisywana jako centrum dowodzenia agentami, działające niezależnie od IDE. W odróżnieniu od poprzednika, czyli Agent Managera, jest osobnym programem. (Antigravity 2.0 - Overview)

Antigravity IDE to pierwotne, pełne środowisko programistyczne z agentem osadzonym w edytorze, terminalu i przeglądarce. Nadal jest dostępne i to ono ma agenta pracującego bezpośrednio na kodzie oraz uzupełnianie kodu w edytorze. (Antigravity IDE - Overview)

Antigravity CLI to lekki interfejs tekstowy w terminalu, oparty na tym samym rdzeniu agenta. Dokumentacja opisuje go jako narzędzie do szybkich lokalnych iteracji, pracy przez SSH i trybu bezgłowego; ustawienia, uprawnienia i konfiguracje bezpieczeństwa synchronizują się między CLI a aplikacją 2.0, a rozmowę można przenieść z terminala do interfejsu wizualnego. (Antigravity CLI Overview)

Rozszerzenia do innych edytorów to oficjalne wtyczki dla Visual Studio Code, Visual Studio 2026 w wersji zapoznawczej, JetBrains, Zed i Xcode - instalowane z poziomu danego edytora, a nie osobnym instalatorem. (Google Antigravity - Download)

SDK w Pythonie to piąta, osobna rzecz: pakiet do budowania własnych agentów, a nie gotowa aplikacja z interfejsem. (Google Antigravity - Download)

Na start najsensowniejsza jest aplikacja 2.0 albo IDE. CLI ma sens wtedy, gdy praca i tak toczy się w terminalu.

Zanim cokolwiek się pobierze: dostępność

Ten krok wyprzedza wymagania sprzętowe, bo potrafi zamknąć sprawę.

Antigravity jest dostępne dla osobistych kont Google w zatwierdzonych regionach. Dokumentacja radzi wprost, żeby przy problemach z kontami Google Workspace spróbować adresu w domenie gmail.com. Produkt jest niedostępny dla osób poniżej osiemnastego roku życia; kto spełnia wymóg wieku, może przejść weryfikację wieku na koncie Google. Lista objętych krajów i terytoriów obejmuje Polskę - znajduje się w części europejskiej wykazu w dokumentacji. Osobno wymienione są regiony bez dostępu do planów Google One AI. (FAQ - Google Antigravity)

Jest też zapis, który warto znać przed próbami obejścia limitów: korzystanie z oprogramowania, narzędzi lub usług osób trzecich w celu uzyskania dostępu do Antigravity narusza warunki korzystania i może być podstawą do zawieszenia albo zamknięcia konta; do pracy z modelami Gemini w cudzym agencie producent zaleca klucz API z Vertex albo AI Studio. (FAQ - Google Antigravity)

Wymagania systemowe

Dokumentacja podaje je krótko i identycznie dla aplikacji 2.0 oraz dla IDE:

macOS: wersje objęte aktualizacjami bezpieczeństwa Apple, czyli zwykle bieżąca i dwie poprzednie. Minimalna wersja to 12 (Monterey). Architektura x86 nie jest obsługiwana - liczy się tylko Apple silicon.
Windows: Windows 10 w wersji 64-bitowej.
Linux: glibc w wersji co najmniej 2.28 i glibcxx co najmniej 3.4.25, czyli na przykład Ubuntu 20, Debian 10, Fedora 36, RHEL 8. (Getting Started with Antigravity 2.0) (Getting Started - Antigravity IDE)

Wymóg dotyczący macOS jest tu najostrzejszy i przesądza sprawę dla starszych Maców z procesorami Intela.

Producent podaje same wymagane wersje i nie opisuje sposobu ich sprawdzenia, więc poniższe polecenia to standardowe narzędzia systemowe, a nie cytat z dokumentacji Antigravity.

Wersję glibc wypisuje:

ldd --version

Z wersją GLIBCXX sprawa jest bardziej podchwytliwa, niż wygląda. W bibliotece standardowej C++ nie ma pojedynczego pola z „wersją”, tylko lista symboli w rodzaju GLIBCXX_3.4.25, a obok nich zwykłe łańcuchy zaczynające się tak samo, na przykład GLIBCXX_DEBUG_MESSAGE_LENGTH. Dlatego samo grep GLIBCXX | tail -1 potrafi zwrócić ostatni napotkany łańcuch zamiast najwyższego numeru wersji - kolejność wystąpień w pliku nie jest kolejnością wersji. Poprawna postać wycina same numery i sortuje je porządkiem wersji:

strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep -o 'GLIBCXX_[0-9.]*' | sort -V | tail -1

Dwie rzeczy mogą tu zawieść. Polecenie strings pochodzi z pakietu binutils i w minimalnych instalacjach oraz w obrazach kontenerów bywa go po prostu brak - wtedy trzeba doinstalować binutils albo sprawdzić wersję inaczej. Ścieżka do biblioteki bywa też inna w zależności od dystrybucji i architektury; właściwy plik znajduje:

ldconfig -p | grep libstdc++

Wynik niższy niż wymagany oznacza, że system jest za stary i trzeba go zaktualizować - nie ma tu obejścia opisanego przez producenta. Powyższych poleceń nie uruchomiono na żadnym Linuksie w ramach tego opracowania.

Instalacja: trzy systemy

Pliki pobiera się wyłącznie ze strony pobierania producenta. (Getting Started with Antigravity 2.0)

Aplikacja Antigravity 2.0 oraz Antigravity IDE. Na stronie pobierania wybiera się swój system, pobiera instalator i go uruchamia. W trakcie instalacji może pojawić się pytanie, czy zachować obie wersje, czy zastąpić - producent wskazuje zastąpienie. Instalator zaproponuje też doinstalowanie IDE; jeżeli się je pominie, można je pobrać później z tej samej strony. (Getting Started with Antigravity 2.0) Aplikacja sama informuje o dostępnych aktualizacjach. (Getting Started - Antigravity IDE)

Antigravity CLI ma udokumentowane polecenia dla każdego systemu i to jedyne miejsce, w którym producent podaje gotowe komendy instalacyjne.

macOS i Linux - skrypt instaluje plik wykonywalny do ~/.local/bin/agy:

curl -fsSL https://antigravity.google/cli/install.sh | bash

Windows, PowerShell:

irm https://antigravity.google/cli/install.ps1 | iex

Windows, wiersz polecenia:

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

Na Windows skrypt rejestruje plik agy w katalogu użytkownika C:\Users\<nazwa-uzytkownika>\AppData\Local\agy\bin. (Installation & Auth - Antigravity CLI)

Skrypt instalacyjny przyjmuje dwie flagi: --skip-aliases pomija czyszczenie i aktualizowanie starych aliasów powłoki agy oraz antigravity, a --skip-path pomija dopisywanie ścieżki do profilu powłoki. (Installation & Auth - Antigravity CLI) Producent pisze tylko, że flagi „można dopisać”, i nie pokazuje składni - a w potoku dopisanie ich na końcu nie zadziała, bo trafiłyby do bash, a nie do skryptu. Argumenty przekazuje się przez -s --:

curl -fsSL https://antigravity.google/cli/install.sh | bash -s -- --skip-path

W wariancie CMD skrypt jest najpierw zapisywany do pliku, więc argument trafia do niego wprost przy uruchomieniu - install.cmd --skip-path zamiast samego install.cmd. W wariancie PowerShell irm ... | iex nie ma prostego sposobu przekazania argumentu: iex wykonuje pobrany tekst, a nie wywołuje skryptu z parametrami. Żeby użyć flag, trzeba najpierw pobrać skrypt do pliku i uruchomić go osobno. Ta kolejność i tak jest rozsądniejsza, o czym niżej. Producent nie pokazuje żadnego z tych wariantów, więc przed użyciem flag warto zajrzeć do pobranego skryptu i sprawdzić, jak czyta argumenty.

Warto zauważyć, że ta sama komenda obsługuje macOS i Linuksa - producent nie rozdziela ich na osobne skrypty. (Google Antigravity - Download)

Uwaga porządkowa: instalowanie oprogramowania przez potok z curl albo irm do powłoki oznacza wykonanie pobranego skryptu bez wcześniejszego przejrzenia. Kto tego unika, może pobrać skrypt do pliku, przeczytać go i dopiero potem uruchomić - producent podaje kanoniczne adresy skryptów, więc taka kolejność niczego nie łamie i przy okazji rozwiązuje sprawę przekazywania flag na Windows.

Logowanie

W aplikacji desktopowej logowanie odbywa się kontem Google przez okno przeglądarki.

W CLI mechanizm jest inny i opisany szczegółowo. Przy uruchomieniu agy na lokalnej maszynie narzędzie próbuje sięgnąć do systemowego pęku kluczy - Apple Keychain, Secret Service przez dbus na Linuksie albo Menedżera poświadczeń Windows. Gdy znajdzie ważny profil tokenu, loguje się po cichu, bez otwierania przeglądarki. Gdy nie znajdzie, uruchamia domyślną przeglądarkę i prosi o zalogowanie. (Installation & Auth - Antigravity CLI)

Przy pracy przez SSH przeglądarki nie da się otworzyć, więc CLI wykrywa środowisko zdalne i przechodzi na ręczną pętlę: wypisuje bezpieczny adres autoryzacji, który kopiuje się do przeglądarki na własnej maszynie, po zalogowaniu przeglądarka pokazuje kod alfanumeryczny, a ten wkleja się z powrotem w zdalnym terminalu. (Installation & Auth - Antigravity CLI)

Istnieje też wariant z własnym kluczem API Gemini, przeznaczony do uruchomień bezgłowych i w CI, gdzie nie ma przeglądarki do zalogowania. Wymaga dwóch rzeczy naraz - samo ustawienie zmiennej środowiskowej nic nie da. Najpierw w pliku ~/.gemini/antigravity-cli/settings.json ustawia się dostawcę:

{
    "modelProvider": "gemini"
}

Potem eksportuje klucz i uruchamia narzędzie:

export GEMINI_API_KEY="wlasny-klucz"
agy

Eksport obowiązuje tylko w bieżącej powłoce; żeby przetrwał, trzeba dopisać tę linię do profilu powłoki, na przykład ~/.zshrc albo ~/.bashrc. Przy tym wariancie polecenie /logout nie ma efektu, bo nie ma zapisanej sesji do wyczyszczenia. Powrót do zwykłego logowania polega na usunięciu wpisu modelProvider z pliku ustawień i ponownym uruchomieniu CLI. Uwaga na pułapkę: klucz podany przez zmienną GOOGLE_API_KEY albo plik .env nie zadziała - narzędzie czyta wyłącznie GEMINI_API_KEY ze środowiska. (Installation & Auth - Antigravity CLI)

Do tego samego wariantu należy jeszcze jedna zmienna, przydatna przy pracy bezgłowej i w CI: GOOGLE_GEMINI_BASE_URL kieruje żądania modelu na inny punkt końcowy zgodny z interfejsem Gemini. To jedyna udokumentowana droga pracy poza domyślną infrastrukturą.

export GOOGLE_GEMINI_BASE_URL="https://wlasny-punkt-koncowy.example.com"

(Installation & Auth - Antigravity CLI)

Wylogowanie w CLI, czyszczące profile uwierzytelnienia z pęku kluczy systemu:

/logout

(Installation & Auth - Antigravity CLI)

Projekt: co agent w ogóle widzi

W Antigravity 2.0 agenci pracują w ramach projektów, które wyznaczają granice folderów i repozytoriów dostępnych dla agenta. Utworzenie projektu:

Kliknąć ikonę folderu ze znakiem plus na lewym pasku bocznym.
Wybrać nowy projekt.
Kliknąć dodanie folderu i wskazać jeden lub więcej lokalnych folderów albo repozytoriów Git. Dodanie kilku folderów daje agentowi kontekst obejmujący wiele repozytoriów.
Zatwierdzić utworzenie.
Opcjonalnie skonfigurować ustawienia projektu - każdy projekt ma własne, odizolowane ustawienia i zasady bezpieczeństwa, których agent przestrzega. (Getting Started with Antigravity 2.0)

To istotna zmiana wobec starszego modelu. Wcześniejszy model przestrzeni roboczej był ściśle związany z jednym repozytorium, agent był zamknięty w jednej strukturze folderów, ustawienia dziedziczył globalnie z maszyny, a uprawnienia były szerokie i globalne. Projekt może obejmować wiele folderów naraz, ma własne ustawienia i dziedziczy uprawnienia globalne, ale może je uzupełniać na własnym poziomie. Nowo utworzony projekt startuje z domyślnym ustawieniem bezpieczeństwa: odczyt i zapis we wszystkich folderach projektu oraz pytanie o zgodę na każde polecenie w terminalu. (Projects - Google Antigravity)

Przy uruchamianiu rozmowy wybiera się tryb pracy z folderami:

Tryb lokalny - agent pracuje bezpośrednio w aktywnych folderach albo w checkoucie Gita. Nadaje się do szybkich, interaktywnych zmian w bieżącym folderze i do sytuacji, gdy kilka agentów ma pracować w tych samych plikach.
Tryb nowego worktree - agent działa w wydzielonym worktree Gita. Nadaje się do zadań złożonych, zostawia aktywny folder nietknięty i zapobiega konfliktom między równoległymi podagentami. Gdy folder nie ma Gita, używany jest istniejący folder lokalny. (Getting Started with Antigravity 2.0) (Projects - Google Antigravity)

Można też prowadzić rozmowy poza projektem. Takie rozmowy nie mają konfigurowalnego folderu i działają w lokalnym katalogu roboczym typu scratch, przy czym mogą mieć własne ustawienia wykonywania poleceń, dostępu do plików i uprawnień. (Settings - Google Antigravity)

Nawigacja i polecenia ukośnikowe

Podstawowe skróty w aplikacji 2.0, w wersji dla macOS oraz dla Windows i Linuksa: wybór rozmowy - ⌘K albo Ctrl + K; wyszukiwanie plików - ⌘P albo Ctrl + P; przejście do pola wprowadzania - ⌘L albo Ctrl + L; nowa rozmowa - ⌘N albo Ctrl + N; następna i poprzednia rozmowa - ⌥ ze strzałkami albo Alt ze strzałkami. (Getting Started with Antigravity 2.0)

Cztery polecenia ukośnikowe warto znać od początku, bo zmieniają zachowanie agenta:

/goal - działaj do pełnego ukończenia wskazanego zadania, bez pytania użytkownika o dane pośrednie.
/grill-me - przed rozpoczęciem wdrożenia zadaj pytania, żeby uzgodnić szczegóły planu.
/schedule - uruchom instrukcję jako jednorazowy odroczony timer albo cyklicznie, przez zadania zaplanowane.
/browser - jawne sterowanie zachowaniem debugowania w przeglądarce Google Chrome. (Getting Started with Antigravity 2.0)

Ustawienia otwiera skrót Cmd + , na dowolnej aktywnej powierzchni aplikacji, pozycja Settings na dole lewego paska bocznego albo ikona koła zębatego obok konkretnego projektu. (Settings - Google Antigravity)

Uprawnienia: co agent może zrobić bez pytania

To sekcja, którą warto przeczytać przed pierwszym zadaniem, a nie po nim.

Antigravity opisuje każdą wrażliwą operację jako zasób uprawnienia w formacie działanie(cel) i ocenia go na trzech listach: Deny blokuje natychmiast, Ask wstrzymuje agenta i prosi o jawną zgodę, Allow przepuszcza bez pytania. (Permissions - Google Antigravity)

Obsługiwane działania i ich domyślne zachowanie przy braku reguły:

Działanie	Co obejmuje	Domyślnie
`read_file`	odczyt plików i katalogów, rekurencyjnie	Ask, ale automatycznie dozwolone w przestrzeni roboczej
`write_file`	zapis; niejawnie przyznaje odczyt tej samej ścieżki	Ask, automatycznie dozwolone w przestrzeni roboczej
`read_url`	pobieranie treści stron; dopasowuje nazwy hostów i poddomeny, ignoruje ścieżkę	Ask
`execute_url`	klikanie, wpisywanie i sterowanie interaktywnymi przepływami w przeglądarce	Ask
`command`	polecenia terminala, dopasowanie po prefiksie tokenów lub wyrażeniem regularnym	Ask
`unsandboxed`	polecenia wykonywane poza izolacją kontenera, gdy piaskownica jest włączona	Ask
`mcp`	narzędzia serwerów MCP, lokalnych i zdalnych	Ask

(Permissions - Google Antigravity)

Dwie reguły niejawne warto zapamiętać: zezwolenie na zapis ścieżki automatycznie przyznaje jej odczyt, a zakaz odczytu ścieżki natychmiast blokuje zapis do niej. Domyślnie odczyt i zapis w aktywnym katalogu projektu są dozwolone automatycznie, a wszystkie pozostałe nieskonfigurowane działania - polecenia, MCP, sterowanie stronami i pliki spoza przestrzeni roboczej - trafiają na listę pytań. Nawigacja i działania w przeglądarce domyślnie pytają. (Permissions - Google Antigravity)

Przykładowe wpisy z dokumentacji, przydatne przy pierwszej konfiguracji. Lista blokad:

command(rm -rf)                    # blokada destrukcyjnych usunięć
command(curl .*)                   # blokada niesprawdzonych pobrań
command(sudo)                      # blokada uprawnień administratora
write_file(.git/)                  # ochrona historii Gita
write_file(/home/user/.ssh)        # ochrona kluczy SSH

Lista zezwoleń:

command(git)                       # standardowe polecenia git
command(npm run (build|lint|test)) # bezpieczne skrypty npm przez wyrażenie regularne
unsandboxed(git push)              # zezwolenie na git push poza piaskownicą
read_file(/var/log/app)            # odczyt zewnętrznych ścieżek z logami
write_file(src/)                   # zapis w względnym katalogu src/
read_url(google.com)               # pobieranie z poddomen google.com
mcp(linter/*)                      # narzędzia MCP serwera linter

(Permissions - Google Antigravity)

Dopasowanie ścieżek działa jednakowo na wszystkich systemach: na macOS i Linuksie używa się ukośników, a na Windows Antigravity normalizuje ścieżki przed oceną reguł, usuwając litery dysków i zamieniając odwrotne ukośniki na zwykłe. Dopasowanie poleceń jest tokenowe - każdy oddzielony spacją token traktowany jest jako zakotwiczone wyrażenie regularne, dlatego command(npm run (build.*)) obejmuje zarówno npm run build, jak i npm run build-prod. (Permissions - Google Antigravity)

Gdy pojawia się karta z pytaniem o zgodę, przy uprawnieniach do plików, adresów i MCP można w niej edytować cel, żeby poszerzyć zakres - na przykład z pojedynczego pliku na katalog nadrzędny. Antigravity sprawdza, czy edytowany cel bezpiecznie obejmuje operację, i stosuje poszerzone uprawnienie do końca tury, dzięki czemu nie powtarza pytań o pokrewne operacje. Edycja zakresu nie działa dla poleceń terminala. (Permissions - Google Antigravity)

W ustawieniach projektu dostępne są też polityka wykonywania poleceń w terminalu, polityka dostępu do plików poza folderem projektu w trzech wariantach - zawsze zezwalaj, zawsze pytaj, zawsze odmawiaj - oraz przełącznik trybu piaskownicy terminala. (Settings - Google Antigravity)

Przeglądarka ma osobne zabezpieczenie: agent działa w całkowicie oddzielnym profilu Chrome, a dostęp do adresów kontroluje dwuwarstwowy model list dozwolonych i zablokowanych. Narzędzia przeglądarki da się też wyłączyć zupełnie. Ten opis pochodzi z dokumentacji IDE (Browser Overview - Google Antigravity) - w aplikacji 2.0 odpowiednikiem jest pozycja Browser Integration w ustawieniach globalnych, gdzie konfiguruje się sposób pracy agenta z powierzchniami webowymi. (Settings - Google Antigravity)

Artefakty: sposób, w jaki agent pokazuje pracę

Artefakt to ustrukturyzowany produkt pracy agenta - bogaty plan w markdownie, różnice w kodzie, diagramy architektury, obrazy i nagrania z przeglądarki. Sens jest praktyczny: przy dłuższych, samodzielnych zadaniach nie trzeba śledzić każdego wywołania narzędzia, tylko przeglądać dostarczone rzeczy w kluczowych momentach. (Artifacts - Google Antigravity)

Najważniejszy z nich to plan wdrożenia. Agent tworzy go, żeby rozpisać zmiany w kodzie potrzebne do wykonania zadania. O ile polityka przeglądania artefaktów nie została ustawiona na zawsze kontynuuj, agent zwykle poprosi o przejrzenie planu przed wprowadzeniem zmian. Plan można zaakceptować przyciskiem kontynuacji albo skomentować - komentarze służą do zawężenia zakresu zmian, wskazania innego zestawu technologii albo poprawienia błędów agenta. Po skomentowaniu można nadal kontynuować albo przełączyć się na tryb przeglądu, obejrzeć wszystkie uwagi i odesłać je jako informację zwrotną zamiast od razu ruszać dalej. (Implementation Plan - Google Antigravity)

Po zakończeniu wdrożenia agent tworzy artefakt podsumowujący - zwięzły opis wprowadzonych zmian, przydatny wtedy, gdy nie śledziło się pracy na bieżąco. Przy zadaniach związanych z przeglądarką takie podsumowania zawierają zrzuty ekranu i nagrania. (Walkthrough - Google Antigravity)

Praktyczny projekt: lista zadań w przeglądarce

Poniżej ćwiczenie o sprawdzalnym wyniku. To propozycja do wykonania, a nie relacja z przeprowadzonego testu.

Przygotowanie. Utworzyć pusty folder, na przykład lista-zadan, i zainicjować w nim repozytorium Gita. To nie jest formalność: dzięki temu każda zmiana agenta jest widoczna w różnicach, a cofnięcie nietrafionej zmiany sprowadza się do jednego polecenia. W terminalu:

git init
git commit --allow-empty -m "punkt startowy"

Następnie dodać ten folder jako nowy projekt w Antigravity, zgodnie z procedurą z wcześniejszej sekcji, i przy pierwszej rozmowie wybrać tryb lokalny.

Zadanie pierwsze - działający szkielet. Prompt do wpisania w polu rozmowy:

Zbuduj lokalną listę zadań w trzech plikach: index.html, styles.css i app.js. Bez frameworków, bez zależności zewnętrznych, bez zaplecza serwerowego. Funkcje: dodawanie zadania, oznaczanie jako wykonane, usuwanie, licznik pozostałych zadań. Stan zapisuj w localStorage przeglądarki pod jednym kluczem i wczytuj przy starcie. Kod pisz w zwykłym JavaScripcie, bez modułów wymagających serwera, tak żeby plik index.html dało się otworzyć wprost z dysku. Najpierw przedstaw plan wdrożenia do zatwierdzenia, nie zmieniaj plików przed jego akceptacją.

Ostatnie zdanie ma znaczenie, bo plan wdrożenia jest miejscem, w którym najtaniej poprawia się kierunek pracy - komentowanie planu jest opisane wprost jako sposób zawężenia zakresu albo zmiany zestawu technologii. (Implementation Plan - Google Antigravity)

Kryteria odbioru pierwszego zadania. Wszystkie sprawdza się samodzielnie w przeglądarce, bez ufania podsumowaniu agenta: powstały dokładnie trzy zapowiedziane pliki; otwarcie index.html daje działającą stronę, a konsola przeglądarki nie pokazuje błędów; dodanie trzech zadań, oznaczenie jednego jako wykonanego i usunięcie innego działa; po odświeżeniu strony stan pozostaje ten sam; licznik zgadza się z liczbą zadań nieoznaczonych. Niespełnienie warunku o zachowaniu stanu po odświeżeniu oznacza zwykle, że zapis do localStorage jest wywoływany, ale odczyt przy starcie nie - to konkretna rzecz do zgłoszenia w kolejnej wiadomości, lepsza niż ogólne „nie działa”.

Po zaakceptowaniu wyniku warto zatwierdzić stan w Gicie, żeby mieć punkt powrotu:

git add -A
git commit -m "lista zadan: wersja podstawowa"

Zadanie drugie - zmiana na istniejącym kodzie. Prawdziwa wartość agenta ujawnia się dopiero przy modyfikacji, nie przy generowaniu od zera:

Dodaj filtrowanie zadań: wszystkie, aktywne, wykonane. Wybrany filtr ma się zachowywać po odświeżeniu strony. Nie zmieniaj struktury danych zapisywanej w localStorage i nie psuj zgodności z istniejącymi zapisami - użytkownik, który ma już zapisane zadania, po aktualizacji ma je nadal widzieć. Dodaj też obsługę sytuacji, w której zapis w localStorage jest uszkodzony: aplikacja ma wtedy wystartować z pustą listą zamiast rzucać błędem.

Kryteria odbioru drugiego zadania: trzy filtry działają i przełączają widok; po odświeżeniu strony aktywny pozostaje ostatnio wybrany filtr; zadania zapisane przed zmianą nadal są widoczne; ręczne wpisanie nieprawidłowej wartości pod klucz w localStorage z poziomu konsoli przeglądarki i odświeżenie strony daje pustą listę, a nie zablokowaną aplikację. Ostatni punkt to test najczęściej pomijany i jednocześnie ten, który najlepiej pokazuje, czy agent zrealizował warunek, czy tylko o nim napisał.

Kontrola zmian. Przed każdą kolejną turą agenta warto mieć czystą historię Gita - git status powinien nie pokazywać niezatwierdzonych zmian. Wtedy git diff po zakończeniu tury pokazuje dokładnie to, co zrobił agent, a nieudaną zmianę cofa git checkout -- . albo powrót do poprzedniego commita. Przy złożonych zadaniach dokumentacja sugeruje inne rozwiązanie tego samego problemu: tryb nowego worktree, w którym agent pracuje w odizolowanym worktree Gita i zostawia aktywny folder nietknięty. (Projects - Google Antigravity)

Ta sama praca w CLI. Producent opisuje analogiczne ćwiczenie w terminalu i warto znać jego skróty. Zaczyna się od utworzenia czystego katalogu i uruchomienia interfejsu tekstowego:

mkdir agy-demo && cd agy-demo
agy

Po wpisaniu polecenia w polu promptu agent czyta przestrzeń roboczą i planuje działanie. Gdy skończy generować plik, pojawia się powiadomienie; ekran przeglądu artefaktów otwiera Ctrl + R, nawigacja po plikach odbywa się strzałkami, klawisz Y zatwierdza utworzenie pliku, a Esc zamyka panel przeglądu. Uruchomienie kodu też przechodzi przez zgodę - agent proponuje polecenie, a klawisz Y je potwierdza. Sesję kończy Ctrl + D albo polecenie /exit. (Antigravity CLI Tutorial)

Reguły i umiejętności: jak nie powtarzać tych samych uwag

Gdy ta sama poprawka wraca w kolejnych rozmowach, jej miejsce jest w regułach, a nie w promptach.

Reguły to ręcznie zdefiniowane ograniczenia dla agenta, na poziomie lokalnym i globalnym. Dokumentacja reguł opisuje ich tworzenie w gałęzi IDE: z panelu dostosowań otwieranego z rozwijanego menu oznaczonego trzema kropkami u góry panelu agenta w edytorze, gdzie w sekcji reguł wybiera się regułę globalną albo związaną z przestrzenią roboczą. (Rules - Google Antigravity) W aplikacji 2.0 ten sam zestaw znajduje się w ustawieniach globalnych, w pozycji Customizations obejmującej serwery MCP, umiejętności i wtyczki. (Settings - Google Antigravity) Same pliki reguł są w obu wypadkach takie same, więc regułę można równie dobrze utworzyć edytorem tekstu. Reguła to zwykły plik markdown ograniczony do 12 000 znaków. Reguły globalne leżą w ~/.gemini/GEMINI.md i obowiązują wszędzie, a reguły przestrzeni roboczej w folderze .agents/rules przestrzeni roboczej albo katalogu głównego repozytorium. (Rules - Google Antigravity)

Sposób aktywacji ustawia się na poziomie reguły: ręczny przez przywołanie znakiem @ w polu wprowadzania, zawsze włączony, decyzja modelu na podstawie opisu w języku naturalnym albo dopasowanie wzorcem glob, na przykład *.js czy src/**/*.ts. W pliku reguły można odwoływać się do innych plików zapisem @nazwa-pliku - ścieżki względne rozwiązywane są względem położenia pliku reguły. (Rules - Google Antigravity)

Do opisywanego projektu nadaje się krótka reguła zawsze włączona, w pliku .agents/rules/lista-zadan.md:

- Bez frameworków i bez zależności zewnętrznych w tym projekcie
- Kod ma działać po otwarciu index.html wprost z dysku, bez serwera
- Nie zmieniaj struktury danych w localStorage bez wyraźnego polecenia
- Po zmianie w app.js napisz, co dokładnie trzeba kliknąć w przeglądarce, żeby to sprawdzić

Umiejętności to osobny mechanizm, oparty na otwartym standardzie. Umiejętność to folder z plikiem SKILL.md zawierającym instrukcje, których agent może się trzymać przy określonym typie zadań. Umiejętności przestrzeni roboczej leżą w <katalog-glowny>/.agents/skills/<folder-umiejetnosci>/, a globalne w ~/.gemini/config/skills/<folder-umiejetnosci>/; Antigravity domyślnie używa katalogu .agents/skills, zachowując wsteczną zgodność z .agent/skills. Plik SKILL.md wymaga nagłówka YAML, w którym pole description jest obowiązkowe, a name opcjonalne i domyślnie równe nazwie folderu. Działa to na zasadzie stopniowego odsłaniania: na starcie rozmowy agent widzi listę nazw i opisów, a pełną treść czyta dopiero wtedy, gdy uzna umiejętność za istotną. (Agent Skills - Google Antigravity)

Modele, plany i limity

Model rozumujący wybiera się z listy rozwijanej pod polem promptu rozmowy. Dostępność zależy od planu: modele z rodziny Gemini wymienione w dokumentacji - Gemini 3.8 Flash, 3.7 Flash, 3.6 Flash i 3.1 Pro - są dostępne we wszystkich planach łącznie z darmowym oraz w wersji dla przedsiębiorstw. Wybór modelu jest lepki między wiadomościami w rozmowie: zmiana modelu w trakcie pracy agenta nie przerwie bieżącej tury, bo dokończy ją na poprzednio wybranym modelu, chyba że wykonanie zostanie anulowane. (Models - Google Antigravity)

Z modelami firm trzecich - Claude Sonnet 4.6 i Opus 4.6 w wariancie z rozumowaniem oraz GPT-OSS-120b - dokumentacja producenta mówi dwie różne rzeczy i to jest miejsce, w którym łatwo o kosztowną pomyłkę. Tabela na stronie modeli stawia znaki potwierdzenia w kolumnach planu darmowego, Google AI Plus, Pro i Ultra, a wyklucza je tylko z wersji dla przedsiębiorstw. (Models - Google Antigravity) Strona planów wymienia natomiast „dostęp do modeli firm trzecich” jako wyróżnik samego planu Google AI Ultra i nie powtarza go przy Pro ani przy pozostałych. (Plans - Google Antigravity) Żadna z tych stron nie ma daty aktualizacji, więc nie da się rozstrzygnąć, która jest świeższa.

Praktyczny wniosek: nie kupować planu wyłącznie po to, żeby dostać w Antigravity konkretny model firmy trzeciej. Selektor modeli na własnym koncie pokazuje stan faktyczny - jego zawartość jest rozstrzygająca, a nie którakolwiek z tabel.

Poza modelem rozumującym Antigravity używa modeli niekonfigurowalnych - dokumentacja wymienia Nano Banana 2 do generowania obrazów, gdy agent tworzy makiety interfejsu, ilustracje do stron i aplikacji albo diagramy architektury. (Models - Google Antigravity)

Wszystkie plany mają wspólną podstawę: korzystanie z modeli Gemini jako podstawowego modelu agenta, nieograniczone uzupełnienia w edytorze oraz dostęp do wszystkich funkcji produktu, w tym zadań zaplanowanych i CLI. Użytkownicy planu Google AI Ultra mają najwyższy przydział odświeżany co pięć godzin, najwyższe limity tygodniowe i dostęp do modeli firm trzecich. Plan Google AI Pro daje wysoki przydział odświeżany co pięć godzin do wyczerpania limitu tygodniowego oraz wyższy limit tygodniowy. Poza tymi planami przydział odświeża się tygodniowo. (Plans - Google Antigravity)

Sposób liczenia limitów jest nietypowy i warto to rozumieć, zanim padnie pytanie „ile promptów mi zostało”. Limity są powiązane z ilością pracy wykonanej przez agenta, która różni się między poleceniami - przy prostych zadaniach, które agent kończy szybko, mieści się ich znacznie więcej, i odwrotnie. Producent zastrzega, że limity mogą się zmieniać w celu zarządzania przepustowością. (Plans - Google Antigravity)

Po wyczerpaniu podstawowego przydziału użytkownicy planów Pro i Ultra mogą sięgnąć po zakupione kredyty AI, zużywane według standardowego cennika. Steruje tym ustawienie z dwiema wartościami: nigdy nie używaj kredytów automatycznie i czekaj na odświeżenie przydziału albo zawsze używaj kredytów po wyczerpaniu przydziału, z automatycznym powrotem do przydziału po jego odświeżeniu. Zużycie podstawowego przydziału w podziale na modele widać na stronie ustawień. Nie ma obecnie obsługi własnego klucza ani własnego punktu końcowego w celu zwiększenia limitów, ani tierów organizacyjnych na podstawie umowy. (Plans - Google Antigravity)

Jedna praktyczna uwaga z dokumentacji: gdy agent pracuje, Antigravity blokuje uśpienie komputera. (FAQ - Google Antigravity)

Prywatność i telemetria

Ustawienie zbierania danych nazywa się w interfejsie włączeniem telemetrii i znajduje się w panelu ustawień w sekcji konta. Gdy jest włączone, Antigravity zbiera interakcje do oceny, rozwoju i doskonalenia produktu oraz modeli, które go obsługują. (Settings - Google Antigravity) Dokumentacja odsyła w tej sprawie do warunków korzystania i wskazuje, że z gromadzenia danych można zrezygnować w dowolnym momencie z panelu ustawień. (FAQ - Google Antigravity)

Osobną warstwą jest ochrona przeglądarki. Agent działa w oddzielnym profilu Chrome, co ma chronić dane osobiste użytkownika, a dostęp do adresów reguluje dwuwarstwowy model list dozwolonych i zablokowanych - opis ten pochodzi z dokumentacji IDE (Browser Overview - Google Antigravity), a w aplikacji 2.0 odpowiada mu sekcja Browser Integration w ustawieniach globalnych. (Settings - Google Antigravity)

Praktyczny wniosek dla pracy z kodem objętym poufnością: sam fakt, że agent działa lokalnie na plikach, nie oznacza, że nic nie wychodzi z komputera - model rozumujący jest usługą zdalną, a treść przekazywana do niego wychodzi poza maszynę. Decyzję o tym, jaki kod trafia do takiego narzędzia, trzeba podjąć przed pierwszym zadaniem, a nie po nim.

Błędy i sposoby ich rozwiązania

Konto Workspace nie działa. Antigravity jest dostępne dla osobistych kont Google w zatwierdzonych regionach, a przy problemach z kontami Workspace producent radzi spróbować adresu gmail.com. (FAQ - Google Antigravity) Logowanie kontem z projektu GCP opisuje osobna strona dla przedsiębiorstw. (FAQ - Google Antigravity)

Komunikat o niezweryfikowanym wieku. Produkt jest niedostępny dla osób poniżej osiemnastu lat; kto spełnia wymóg, przechodzi weryfikację wieku na koncie Google. (FAQ - Google Antigravity)

CLI kończy pracę przy starcie z komunikatem o braku GEMINI_API_KEY. Oznacza to, że modelProvider ustawiono na gemini, ale klucza nie ma w środowisku - trzeba wyeksportować klucz albo usunąć wpis modelProvider, żeby wrócić do zwykłego logowania. (Installation & Auth - Antigravity CLI)

CLI ignoruje ustawienie dostawcy. Wartość gemini jest jedyną akceptowaną - warto sprawdzić pisownię i zrestartować narzędzie. (Installation & Auth - Antigravity CLI)

Klucz podany w GOOGLE_API_KEY albo pliku .env nie działa. Narzędzie czyta poświadczenie wyłącznie ze zmiennej GEMINI_API_KEY w środowisku i nie wczytuje plików .env. (Installation & Auth - Antigravity CLI)

Żądania zaczynają zawodzić w trakcie sesji. Zwykle klucz jest nieprawidłowy, unieważniony albo nie ma dostępu do żądanego modelu. CLI sprawdza przy starcie tylko to, czy klucz nie jest pusty, więc nieużywalny klucz ujawnia się dopiero przy pierwszej rozmowie. (Installation & Auth - Antigravity CLI)

Agent ciągle pyta o zgodę na te same polecenia. To zachowanie domyślne - polecenia terminala trafiają na listę pytań, dopóki nie powstanie reguła zezwalająca. Warto dopisać wąskie reguły w rodzaju command(git) czy command(npm run (build|lint|test)) zamiast otwierać wszystko. (Permissions - Google Antigravity) Uwaga: przy poleceniach terminala nie da się poszerzyć zakresu bezpośrednio w karcie pytania, tak jak przy plikach i adresach. (Permissions - Google Antigravity)

Agent robi więcej, niż miał. Miejsce na korektę to plan wdrożenia, jeszcze przed zmianą plików - komentarze na planie służą właśnie zawężeniu zakresu. (Implementation Plan - Google Antigravity) Przy zadaniach ryzykownych lepszym rozwiązaniem jest tryb nowego worktree, który zostawia aktywny folder nietknięty. (Projects - Google Antigravity)

Nie widać funkcji opisanej w starszym poradniku. Model przestrzeni roboczej został zastąpiony modelem projektów, a samodzielny Agent Manager to poprzednik dzisiejszej aplikacji 2.0. (Projects - Google Antigravity) (Antigravity 2.0 - Overview) Instrukcje sprzed tej zmiany nie pasują do obecnego interfejsu.

Sprzątanie i cofnięcie zmian

W CLI sesję zamyka polecenie /logout, które rozłącza konto i usuwa zapisane profile uwierzytelnienia z pęku kluczy systemu operacyjnego. (Installation & Auth - Antigravity CLI) Sam plik wykonywalny agy leży w ~/.local/bin/agy na macOS i Linuksie oraz w C:\Users\<nazwa-uzytkownika>\AppData\Local\agy\bin na Windows - te ścieżki trzeba usunąć ręcznie, bo producent nie opisuje osobnego deinstalatora. (Installation & Auth - Antigravity CLI) Jeżeli przy instalacji nie użyto flagi --skip-path, skrypt zmodyfikował profil powłoki i wpis ze ścieżką trzeba usunąć osobno. (Installation & Auth - Antigravity CLI)

Aplikację desktopową odinstalowuje się standardowo dla danego systemu. Pliki konfiguracyjne i reguły pozostają w katalogach opisanych wcześniej - globalne reguły w ~/.gemini/GEMINI.md, (Rules - Google Antigravity) globalne umiejętności w ~/.gemini/config/skills/, (Agent Skills - Google Antigravity) ustawienia CLI w ~/.gemini/antigravity-cli/settings.json (Installation & Auth - Antigravity CLI) - więc jeżeli celem jest pełne uprzątnięcie, trzeba je sprawdzić świadomie. Reguły i umiejętności zapisane w projekcie, czyli w folderach .agents/rules i .agents/skills, zostają w repozytorium i usuwa się je jak zwykłe pliki projektu.

Zakres tego materiału

Opis powstał na podstawie dokumentacji producenta. Instalacja i przebieg zadań nie zostały wykonane na maszynie testowej w ramach tego opracowania; nazwy przycisków, skróty i ścieżki pochodzą z dokumentacji, a poleceń sprawdzających wersje bibliotek na Linuksie ani składni flag instalatora nie uruchomiono na żadnym systemie. Część opisów interfejsu - przeglądarka i panel dostosowań - producent publikuje w gałęzi dokumentacji dotyczącej IDE; zaznaczono to w tekście razem z odpowiednikiem w aplikacji 2.0. Rozbieżność między tabelą modeli a stroną planów w sprawie modeli firm trzecich również opisano wprost. Ćwiczenie z listą zadań jest propozycją do samodzielnego wykonania wraz z kryteriami odbioru, a nie relacją z przeprowadzonego przebiegu. Dostępność regionalna, plany, limity i lista modeli zmieniają się - przed decyzją trzeba je sprawdzić na aktualnych stronach producenta.