Dla zespołów deweloperskich
Pilotaż Grok Build: od prywatnych ustawień do wspólnej konfiguracji w repozytorium.
Pilotaż Grok Build dla zespołu, który już z nim pracuje: wspólna konfiguracja w jednym repozytorium i pisemna decyzja go/no-go według uzgodnionych kryteriów.
Oferta: pilotaż dla jednego zespołu w jednym repozytorium, zakończony pisemną decyzją go/no-go według kryteriów spisanych przed startem. Czas i koszt ustalamy na piśmie, zanim zaczniemy.
- AGENTS.mdzasady projektu
- .grok/skills/procedury zespołu
- .grok/agents/subagenty
- .grok/config.tomlreguły allow, ask i deny oraz serwery MCP
- .grok/hooks/kontrole przy zdarzeniach
- .github/workflows/bramka PR
Gdy każdy deweloper konfiguruje Grok Build po swojemu
Twoi deweloperzy już pracują z Grok Build, każdy na własnych ustawieniach. Przy pojedynczych eksperymentach to wystarcza. Gdy agent zmienia kod, za który odpowiada cały zespół, brak wspólnych zasad widać w przeglądach kodu i w pytaniach działu bezpieczeństwa.
- Różne uprawnienia
- Jeden deweloper pozwala agentowi uruchamiać polecenia bez pytania, inny zatwierdza każde z osobna. To samo zadanie przebiega u każdego inaczej.
- Brak wspólnych zasad
- Konwencje projektu, sposób testowania i obszary, których nie wolno ruszać, każdy opisuje agentowi sam albo wcale.
- Nikt nie wie, co agent może uruchomić
- Nie ma jednego miejsca, w którym widać, do jakich poleceń, plików i systemów agent ma dostęp w danym repozytorium.
- Pytania o bezpieczeństwo bez odpowiedzi
- Dział bezpieczeństwa pyta o dane, uprawnienia i kontrolę zmian, a nikt nie potrafi odpowiedzieć w imieniu całego zespołu.
Po co pilotaż, skoro jest dokumentacja?
Dokumentacja xAI opisuje, co można skonfigurować i jak. W pilotażu robimy to w Twoim repozytorium, razem z Twoim zespołem, a kończymy pisemną decyzją, czy iść dalej.
Pilotaż
Od diagnozy do decyzji na piśmie
Pracujemy z jednym zespołem w jednym repozytorium. Przy każdym kroku widać, co robi Aurora AI, co wnosi Twój zespół i co sprawdzamy.
- Zespół
- Jeden zespół, który już używa Grok Build
- Repozytorium
- Jedno repozytorium, wybrane razem z Tobą
- Zakończenie
- Pisemna decyzja go/no-go według kryteriów spisanych przed startem
- Czas i koszt
- Ustalone na piśmie przed startem
Diagnoza
Diagnoza i kryteria decyzji
Sprawdzamy, jak Twoi deweloperzy używają dziś Grok Build, wybieramy zespół i repozytorium do pilotażu i spisujemy kryteria decyzji.
- Aurora AI
- Rozmawia z deweloperami, przegląda ich obecne ustawienia i proponuje zespół, repozytorium oraz kryteria go/no-go.
- Twój zespół
- Lider wskazuje zespół, repozytorium i osobę, która na końcu podejmie decyzję. Deweloperzy pokazują, jak dziś pracują z agentem.
- Sprawdzamy
- Kryteria go/no-go są spisane, a osoba, która podejmie decyzję, zaakceptowała je przed startem.
Konfiguracja
Wspólna konfiguracja w repozytorium
Zasady pracy, uprawnienia i narzędzia agenta trafiają do repozytorium: AGENTS.md, skille, subagenty, hooki oraz reguły uprawnień i serwery MCP w pliku .grok/config.toml.
- Aurora AI
- Przygotowuje konfigurację na podstawie diagnozy i każdą zmianę zgłasza jako PR.
- Twój zespół
- Deweloperzy przeglądają każdy PR i decydują, co wchodzi do repozytorium, a co wymaga poprawki.
- Sprawdzamy
- Konfiguracja leży w repozytorium, a każda jej zmiana przeszła przegląd zespołu w PR.
Zadania
Praca na zadaniach z backlogu
Zespół pracuje z Grok Build na prawdziwych zadaniach z bieżącego backlogu.
- Aurora AI
- Pracuje w parach z deweloperami i dostosowuje konfigurację tam, gdzie przeszkadza albo czegoś w niej brakuje.
- Twój zespół
- Zespół wybiera zadania z bieżącego backlogu i zgłasza, gdzie konfiguracja pomaga, a gdzie spowalnia pracę.
- Sprawdzamy
- Zmiany przygotowane z agentem przechodzą ten sam przegląd kodu co reszta pracy, a poprawki konfiguracji idą przez PR.
Ład
Ład i bezpieczeństwo
Zasady z repozytorium uzupełniamy o politykę organizacji, bramkę w CI i odpowiedzi dla działu bezpieczeństwa.
- Aurora AI
- Przygotowuje politykę organizacji i reguły deny, ustawia bramkę PR dla zmian zrobionych z agentem i spisuje odpowiedzi na pytania działu bezpieczeństwa.
- Twój zespół
- Administratorzy wdrażają politykę organizacji, a dział bezpieczeństwa zadaje pytania i ocenia odpowiedzi. Licencje i dostęp zostają w Twoim własnym planie xAI albo na Twoim koncie API.
- Sprawdzamy
- Zabroniona akcja zostaje zablokowana, zmiana bez przeglądu nie trafia do głównej gałęzi, a dział bezpieczeństwa ma odpowiedzi na piśmie.
Decyzja
Decyzja i przekazanie
Pilotaż kończy się memo, które ocenia wynik względem kryteriów spisanych na początku.
- Aurora AI
- Pisze memo z rekomendacją go albo no-go i przekazuje dokumentację konfiguracji.
- Twój zespół
- Osoba odpowiedzialna podejmuje decyzję, a zespół przejmuje konfigurację i utrzymuje ją dalej jak kod.
- Sprawdzamy
- Decyzja jest zapisana i uzasadniona kryteriami. Konfiguracja zostaje w repozytorium niezależnie od wyniku.
Co zostaje w Twoim repozytorium
Konfiguracja powstaje w Twoim repozytorium i przechodzi przegląd Twojego zespołu. Zostaje u Ciebie także po decyzji no-go.
AGENTS.md
Wspólne zasady projektu
Zasady pracy w repozytorium, które Grok Build wczytuje w każdej sesji, gdy folder projektu jest oznaczony jako zaufany.
.grok/skills/
Skille zespołu
Opisane procedury zespołu, które agent wczytuje dopiero wtedy, gdy zadanie ich wymaga.
.grok/agents/
Subagenty
Definicje subagentów projektu. Każdy subagent pracuje we własnym kontekście, oddzielnie od głównej sesji.
.grok/config.toml
Reguły uprawnień i serwery MCP
Wspólne reguły allow, ask i deny oraz lista serwerów MCP projektu, zapisane w repozytorium. Reguła deny ma pierwszeństwo przed ask i allow.
.grok/hooks/
Hooki
Kontrole, które uruchamiają się przy określonych zdarzeniach i mogą zablokować użycie narzędzia przez agenta.
managed_config.toml / requirements.toml
Polityka organizacji
Ustawienia domyślne i podpisane wymagania, które administratorzy wdrażają poza repozytorium. Ustawienia domyślne deweloper może zmienić u siebie, wymagań nie. Wymagania ustalają na przykład listę dozwolonych modeli albo wyłączają tryb, w którym agent zatwierdza wszystko sam.
.github/workflows/
Bramka PR w CI
Kontrola w CI, która nie wpuszcza zmiany przygotowanej przez agenta do głównej gałęzi bez testów i przeglądu człowieka.
memo go/no-go
Memo decyzyjne
Pisemna ocena pilotażu względem kryteriów ustalonych przed startem, z rekomendacją go albo no-go.
zespół
Przeszkolony zespół
Deweloperzy, którzy znają konfigurację, zmieniają ją przez PR i potrafią ją utrzymać samodzielnie.
Politykę organizacji wdrażają Twoi administratorzy dla całej firmy, poza repozytorium. Memo trafia do osoby, która podejmuje decyzję, a umiejętności zostają w zespole.
Na własnym przykładzie
Pracujemy tak samo u siebie
Stronę, którą czytasz, rozwijają agenci AI według tych samych zasad, które wprowadzamy w pilotażu.
- Agenci mają określone role, takie jak planowanie, teksty, budowa strony, SEO i QA.
- Każdy agent pracuje przez PR, a każdą zmianę sprawdzają automatyczne bramki.
- Zmiany w definicjach agentów, w skryptach i w bramkach czekają, aż człowiek je sprawdzi i ręcznie scali.
Wdrożenie Groka u klienta zostało już dostarczone, a nazwy firmy, jak przy każdej realizacji, nie podajemy.
# Scope: any open PR targeting main whose checks are green (operator's
# explicit choice), EXCEPT a PR that changes code or gates: `scripts/**`,
# `.github/**` (incl. pr-guards.yml), `.claude/**`, `package.json`,
# `package-lock.json` (any folder). […]
# […] Gated PRs get the label `needs-adam` and a comment, and wait for
# Adam to merge by hand […]Fragment reguły auto-merge z naszego repozytorium
PR, który zmienia definicje agentów, skrypty albo bramki, nie jest scalany automatycznie: czeka, aż założyciel scali go ręcznie. Tę zasadę wprowadziła decyzja bezpieczeństwa: treść, którą ktoś z zewnątrz podsunie agentowi, nie może zmienić kodu ani bramek tak, żeby zmiana sama trafiła do publikacji.
Co dalej po decyzji
Pilotaż sam nie przechodzi w dalsze wdrożenie. O następnym kroku decydujesz Ty, na podstawie memo.
Decyzja go
Następny krok to wdrożenie w kolejnych zespołach. Jego zakres, czas i koszt ustalamy osobno, na podstawie wniosków z pilotażu.
Decyzja no-go
Konfiguracja w repozytorium i memo zostają u Ciebie. Wiesz, dlaczego teraz nie warto iść dalej.
Kiedy pilotaż Grok Build ma sens
Pilotaż pomaga, gdy
- Twoi deweloperzy już używają Grok Build, każdy na własnych ustawieniach.
- Chcesz mieć wspólne zasady, zanim agent trafi do kolejnych zespołów i repozytoriów.
- Ktoś po Twojej stronie może podjąć decyzję go/no-go i za nią odpowiadać.
- Dział bezpieczeństwa pyta, co agent może robić w Twoim kodzie, i potrzebuje odpowiedzi na piśmie.
Pilotaż nie jest dobrym wyborem, gdy
- Dopiero wybierasz narzędzie. Wtedy zacznij od rozmowy o tym, jak pracuje Twój zespół.
- Nikt po Twojej stronie nie może wziąć odpowiedzialności za decyzję.
- Oczekujesz, że dostarczymy licencje. Nie sprzedajemy ich: kupujesz je bezpośrednio od xAI.
- Chcesz, żeby zmiany przygotowane przez agenta trafiały do kodu bez przeglądu.
- Twój zespół używa modeli Grok tylko w innym edytorze albo agencie. Ten pilotaż obejmuje sam Grok Build.
Najczęstsze pytania
Czy Aurora AI jest partnerem xAI?
Nie. Aurora AI jest niezależną firmą doradczą. Nie sprzedajemy licencji i nie pośredniczymy w rozliczeniach. Licencje i dostęp kupujesz bezpośrednio od xAI, w planie biznesowym Grok albo przez API xAI. Grok Build to produkt xAI.
Czy nasz kod posłuży do trenowania modeli?
Według dokumentacji xAI (stan na październik 2026) zależy to od planu i od ustawienia „Coding data, retention, and training”, które na kontach zespołowych zmienia tylko administrator zespołu. Administrator może też włączyć dla zespołu Zero Data Retention (ZDR), które blokuje to ustawienie. W pilotażu zapisujemy, który plan i które ustawienia obowiązują w Twoim zespole, i potwierdzamy to z Twoim działem bezpieczeństwa.
Ile trwa pilotaż i ile kosztuje?
To zależy od zespołu, repozytorium i kryteriów decyzji, dlatego nie podajemy cen na stronie. Czas i koszt ustalamy na piśmie przed startem, po pierwszej rozmowie.
Grok Build często się zmienia. Co wtedy z konfiguracją?
Konfiguracja leży w Twoim repozytorium i zmienia się przez PR, jak każdy inny kod. Gdy narzędzie dostaje nową funkcję albo zmienia sposób działania, zespół aktualizuje konfigurację w zwykłym PR. W pilotażu ćwiczy dokładnie ten tryb pracy.
Nasi deweloperzy używają też innych agentów. Co wtedy?
Według dokumentacji xAI Grok Build wczytuje zasady z AGENTS.md, a dla zgodności także z CLAUDE.md i katalogu .claude/. W pilotażu ustalamy, który plik jest źródłem prawdy, żeby te same zasady nie istniały w kilku rozbieżnych wersjach.
Co, jeśli decyzja brzmi no-go?
Konfiguracja i memo zostają u Ciebie. Memo pokazuje, których kryteriów nie spełniono, więc wiesz, co musiałoby się zmienić, żeby wrócić do tematu.
Czy możecie wdrożyć Grok Build w całej firmie?
To możliwy następny krok po decyzji go. Taki etap planujemy i wyceniamy osobno, gdy poznamy wnioski z pilotażu.
Więcej w bazie wiedzy
Artykuły i przewodniki, które rozwijają tematy pilotażu. Ostatni dotyczy Grok Bota, innego produktu xAI niż Grok Build.
Opisz, jak Twój zespół używa dziś Grok Build
Napisz, z jakich ustawień korzystają dziś deweloperzy, w którym repozytorium chcesz zacząć i kto podejmie decyzję go/no-go. Odpowiemy e-mailem i zaproponujemy rozmowę o pilotażu.
Strona kontaktu prowadzi do e-maila. Nie potrzebujesz gotowej specyfikacji.
Aurora AI jest niezależną firmą doradczą. Nie jesteśmy partnerem xAI, nie sprzedajemy licencji i nie pośredniczymy w rozliczeniach. Licencje i dostęp kupujesz bezpośrednio od xAI. Grok Build to produkt xAI.