Pilotaż GitHub Copilot
Wdrożenie GitHub Copilot: od autouzupełniania do wspólnej konfiguracji agentów w repozytorium.
Wdrożenie GitHub Copilot zaczynamy od pilotażu: wspólna konfiguracja agentów 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. Szersze wdrożenie wyceniamy osobno, dopiero po decyzji go.
- .github/copilot-instructions.mdinstrukcje dla całego repozytorium
- .github/instructions/instrukcje dla wybranych ścieżek
- AGENTS.mdinstrukcje dla agentów
- .github/agents/profile agentów
- .github/skills/procedury zespołu
- .github/hooks/kontrole przy zdarzeniach
- .github/workflows/copilot-setup-steps.ymlśrodowisko agenta w chmurze
- .github/CODEOWNERSprzegląd zmian w konfiguracji
Licencje są, a agentów każdy włącza po swojemu
Twoja firma płaci za GitHub Copilot albo deweloperzy używają go na własnych planach. W praktyce zespół korzysta głównie z autouzupełniania, a agentów każdy włącza i ustawia sam. Chodzi o tryb agenta w IDE, Copilot CLI, Copilot code review i Copilot cloud agent (wcześniej Copilot coding agent), który pracuje w chmurze na GitHubie i może sam otworzyć PR. 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.
- Repozytorium nic agentowi nie mówi
- W repozytorium nie ma instrukcji, więc konwencje projektu, sposób testowania i obszary, których nie wolno ruszać, każdy opisuje agentowi sam albo wcale.
- Każdy pracuje na innych ustawieniach
- Jeden deweloper korzysta z planu organizacji, inny z prywatnego, a każdy ma inne modele, serwery MCP i narzędzia. To samo zadanie przebiega u każdego inaczej.
- Nikt nie wie, do czego agent ma dostęp
- Nie ma jednego miejsca, w którym widać, po jakie narzędzia, serwery MCP i adresy w internecie agent może sięgnąć 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 GitHub publikuje wytyczne?
GitHub publikuje wytyczne do wdrożeń, w tym poradnik, jak przeprowadzić w firmie pilotaż nowej funkcji albo nowego modelu. My robimy to w Twoim repozytorium, razem z Twoim zespołem, a kończymy pisemną decyzją, czy iść dalej.
Pilotaż
Wdrożenie GitHub Copilot zaczyna się od pilotażu
Pilotaż to pierwszy krok wdrożenia, a nie całe wdrożenie. 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ż ma dostęp do GitHub Copilot
- Repozytorium
- Jedno repozytorium na GitHubie, 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, z których funkcji i na jakich planach korzystają dziś Twoi deweloperzy, wybieramy zespół oraz repozytorium i spisujemy kryteria decyzji.
- Aurora AI
- Rozmawia z deweloperami, przegląda ich ustawienia i obecne zasady organizacji, a potem 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 agentami.
- 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, role i narzędzia agentów trafiają do repozytorium: instrukcje dla całego repozytorium i dla wybranych ścieżek, AGENTS.md, profile agentów, skille, hooki i środowisko agenta w chmurze.
- 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 agentami na prawdziwych zadaniach z bieżącego backlogu: w IDE, w terminalu i na GitHubie, gdzie agent w chmurze przygotowuje zmianę na osobnej gałęzi i może otworzyć PR.
- 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, część z nich zleca agentowi w chmurze i mówi, gdzie konfiguracja pomaga, a gdzie spowalnia pracę.
- Sprawdzamy
- PR przygotowane przez agenta przechodzą ten sam przegląd kodu co reszta pracy, a poprawki konfiguracji idą przez PR.
Ład
Ład i bezpieczeństwo
Konfigurację z repozytorium uzupełniamy o zasady organizacji, bramkę PR i odpowiedzi dla działu bezpieczeństwa.
- Aurora AI
- Proponuje zasady organizacji: dostępne funkcje, modele i serwery MCP, wykluczenia treści i budżety. Przygotowuje bramkę PR, konfiguruje dostęp agenta w chmurze do internetu i serwerów MCP, a potem spisuje odpowiedzi dla działu bezpieczeństwa, także o tym, gdzie wykluczenia treści nie działają, na przykład w trybie agenta w VS Code.
- Twój zespół
- Administratorzy organizacji wdrażają zasady, a dział bezpieczeństwa zadaje pytania i ocenia odpowiedzi. Licencje zostają w planie Copilot Business lub Enterprise Twojej organizacji.
- Sprawdzamy
- Dostęp agenta do internetu i serwerów MCP odpowiada uzgodnionej liście, PR agenta nie trafia do głównej gałęzi bez przeglądu człowieka, 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.
.github/copilot-instructions.md
Instrukcje dla całego repozytorium
Wspólne zasady pracy w projekcie: konwencje, budowanie i testy. Instrukcje kierują pracą agenta, ale nie wymuszają zasad. Do tego służą hooki i bramka PR.
.github/instructions/
Instrukcje dla wybranych ścieżek
Pliki *.instructions.md z zasadami dla konkretnych części kodu, na przykład testów albo migracji bazy danych.
AGENTS.md
Instrukcje dla agentów
Zasady dla agentów, które agent w chmurze czyta razem z pozostałymi plikami instrukcji.
.github/agents/
Profile agentów
Agenci do powtarzalnych ról. Każdy ma własne instrukcje i może mieć ograniczoną listę narzędzi. Działają w agencie w chmurze, w Copilot CLI i we wspieranych IDE.
.github/skills/
Skille zespołu
Opisane procedury zespołu, zapisane w repozytorium jako skille projektu.
.github/hooks/
Hooki
Własne polecenia uruchamiane w określonych momentach pracy agenta. Hook wywołany przed użyciem narzędzia może na nie pozwolić albo je zablokować. Hooki działają w Copilot CLI i w agencie w chmurze.
.github/workflows/copilot-setup-steps.yml
Środowisko agenta w chmurze
Workflow GitHub Actions, który przygotowuje narzędzia i zależności, zanim agent w chmurze zacznie pracę.
MCP i dostęp do sieci
Ustawienia agenta w chmurze
Serwery MCP z listą dozwolonych narzędzi i zapora, która ogranicza dostęp agenta do internetu. To ustawienia repozytorium na GitHubie, a nie plik.
zasady organizacji
Zasady organizacji
Ustawienia administratora: które funkcje, agenci i modele są dostępni, które serwery MCP wolno podłączyć, które pliki Copilot ma pomijać i jakie obowiązują budżety.
.github/CODEOWNERS
Bramka PR
Właściciele konfiguracji agentów oraz reguły gałęzi z wymaganymi testami. Zmiana instrukcji, hooków albo środowiska agenta czeka na przegląd wskazanej osoby.
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.
Zasady organizacji, reguły gałęzi oraz ustawienia MCP i dostępu do sieci wprowadzają Twoi administratorzy w ustawieniach GitHuba, poza plikami 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. Nasze repozytorium też jest na GitHubie.
- 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 GitHub Copilot 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 i repozytoriach. 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ż GitHub Copilot ma sens
Pilotaż pomaga, gdy
- Twoja firma ma licencje GitHub Copilot, ale zespół korzysta głównie z autouzupełniania.
- Deweloperzy włączają agentów każdy po swojemu, część z nich na prywatnych planach.
- 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 GitHuba, w planie Copilot Business lub Enterprise.
- Chcesz, żeby zmiany przygotowane przez agenta trafiały do kodu bez przeglądu.
Najczęstsze pytania
Czy Aurora AI jest partnerem GitHuba albo Microsoftu?
Nie. Aurora AI jest niezależną firmą doradczą. Nie sprzedajemy licencji i nie pośredniczymy w rozliczeniach. Licencje kupujesz bezpośrednio od GitHuba, w planie Copilot Business lub Enterprise, albo w ramach umowy, którą Twoja firma ma już z Microsoftem.
Czy nasz kod posłuży do trenowania modeli?
Według dokumentacji GitHuba (stan na październik 2026) dane klientów planów Copilot Business i Enterprise nie są używane do trenowania modeli AI. W planach indywidualnych jest inaczej: dane z korzystania z narzędzia mogą trafić do trenowania, jeśli użytkownik tego nie wyłączy. Dlatego w pilotażu sprawdzamy, kto pracuje na prywatnym planie, rekomendujemy przejście na plan organizacji i potwierdzamy te warunki 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. Osobną pozycją jest samo narzędzie: według dokumentacji GitHuba praca agentów w planach Business i Enterprise jest rozliczana według zużycia, dlatego w pilotażu ustalamy z administratorami budżety. Więcej piszemy na blogu, w artykule o przejściu GitHub Copilot na rozliczenie od zużycia.
GitHub Copilot 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.
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ć GitHub Copilot 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. Jeśli dopiero wybierasz narzędzie, zacznij od porównania agentów do kodowania.
Opisz, jak Twój zespół używa dziś GitHub Copilot
Napisz, z których funkcji i na jakich planach 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 GitHuba ani Microsoftu, nie sprzedajemy licencji i nie pośredniczymy w rozliczeniach. GitHub Copilot to produkt GitHuba.