Wdrożenie agentów kodujących, które nie kończy się na kilku pierwszych zespołach

Decyzje podjęte na początku wdrożenia trudno później zmienić. Dotyczą tego, które repozytoria i rodzaje pracy idą na pierwszy ogień, jak agenci współpracują z twoimi narzędziami i CI oraz jakie zasady obowiązują przy ich używaniu. Obejmują też to, kto ma dostęp i z którego budżetu pokrywane są koszty. Każdą z nich uzgadniamy z liderami twoich zespołów inżynierskich, zanim zostanie włączony pierwszy agent.

Agenci potrzebują też konfiguracji w każdym repozytorium, w którym pracują. Budujemy ją w ramach usługi harness engineering.

Pilotaż prowadzimy w jednym zespole albo w niewielkiej grupie zespołów, na zadaniach podobnych do ich zwykłej pracy. Review przez ludzi i twoje automatyczne kontrole zostają dokładnie takie jak dotąd. Więcej autonomii agenci dostają tylko tam, gdzie przemawiają za tym wyniki pilotażu.

Jeśli w trakcie pilotażu trzeba porównać narzędzia lub modele, przeprowadzamy ewaluację na pracy już zmergowanej przez twoje zespoły.

Zanim agenci zaczną pracę w repozytorium, sprawdzamy je pod kątem poniższych punktów. Jeśli części z nich brakuje, inżynierowie pracują z agentami interaktywnie. Praca bez nadzoru zaczyna się dopiero wtedy, gdy wszystkie punkty są spełnione.

• Jedno polecenie buduje i testuje świeży checkout
• Testy nie wymagają ręcznego przygotowania i padają tylko wtedy, gdy coś jest naprawdę zepsute
• Konwencje, których przestrzegania wymagają recenzenci, są udokumentowane
• Konfiguracja agenta w repozytorium ma swojego właściciela
• Ani repozytorium, ani środowisko agenta nie zawiera sekretów
• Recenzenci są w stanie przyjąć więcej pull requestów

Szkolenie odbywa się w repozytoriach, w których twoi inżynierowie pracują na co dzień, z użyciem wybranych przez ciebie narzędzi. Najwięcej czasu poświęcamy na określanie zakresu zadania, decydowanie, jakiego kontekstu potrzebuje agent, i review tego, co zwraca.

Od tego momentu twój zespół platformowy prowadzi wdrożenie bez nas. Na życzenie spotykamy się raz w miesiącu i omawiamy najnowsze zmiany w narzędziach i modelach.

Chmurowy agent Devin przejmuje zadanie we własnym zdalnym środowisku i oddaje wynik jako pull request. Najpierw trzeba ustalić, jaką pracę da się opisać na piśmie i sprawdzić po jej zakończeniu. Typowo nadają się do tego pokrycie testami, migracje, aktualizacje utrzymaniowe i jasno opisane pozycje z backlogu. Dla każdego takiego zadania recenzent potrzebuje kryteriów ukończenia, które da się zweryfikować bez odtwarzania przebiegu sesji.

Przed pilotażem upewniamy się, że repozytorium za każdym razem uruchamia się tak samo w środowisku Devina. Obejmuje to jego zależności, dane testowe i usługi, a także polecenia, które je budują i uruchamiają jego testy. Playbooks przechowują prompty zadań do wielokrotnego użytku wraz z historią ich wersji. Konwencje projektu trafiają do Skills i instrukcji repozytorium, a nie do Playbooks. Devin Desktop, dawniej Windsurf, to edytor działający lokalnie jako osobny kontekst wykonania. Jeśli twój plan obejmuje handoff, możesz przekazać lokalną sesję do chmury, a my sprawdzamy, co się przy tym przenosi, zanim jakikolwiek zespół zacznie na tym polegać.

Zadania trafiają do Devina przez twój zwykły proces przyjmowania zgłoszeń, a jego pull requesty przechodzą przez ten sam obieg co dotąd. Obowiązuje je ta sama ochrona gałęzi co wszystkie inne, a każdy z nich sprawdza człowiek. Dzięki profilom bezpieczeństwa możesz ograniczyć dostęp do git, MCP i sieci. Twój plan określa, które z tych mechanizmów masz do dyspozycji, więc sprawdzamy to, zanim na którymkolwiek z nich się oprzemy. W pilotażu każdy typ zadania uruchamiamy więcej niż raz. W tych uruchomieniach liczymy, ile zrecenzowanych pull requestów zostało zaakceptowanych, i śledzimy koszt operacyjny, czas review oraz poprawki. Raport obejmuje tylko to, co zmierzył twój własny pilotaż. Danych dostawcy o produktywności do niego nie włączamy.

• Typy zadań i ich kryteria ukończenia, ustalone, zanim cokolwiek zostanie delegowane
• Wyznaczony właściciel dla każdego Playbooka i dla instrukcji repozytorium
• Recenzenci i osoby odpowiedzialne za merge, wskazani z imienia i nazwiska, a do tego sposób eskalacji, gdy uruchomienie utknie

Konfiguracja harnessu dla środowisk delegowanych · Ewaluacja zmiany w twoim workflow · Dokumentacja Devina o handoffie z sesji lokalnej do chmury

Niektóre narzędzia, w tym Kilo, zostawiają wybór dostawcy i modelu każdemu inżynierowi. Decyzje, które inne narzędzia podejmują za ciebie, stają się wtedy częścią twojego wdrożenia. Ktoś musi odpowiadać za listę zatwierdzonych dostawców i modeli oraz za klucze albo konta w gatewayu. Potrzebny jest też ktoś, kto zdecyduje, co się dzieje, gdy na liście wyboru pojawi się model, którego nikt jeszcze nie przetestował. Tych właścicieli i ścieżkę dla wyjątków ustalamy podczas pilotażu. Zespoły dostają wspólną konfigurację zamiast indywidualnych ustawień. Samą konfigurację obejmuje harness engineering.

Konfiguracja Kilo

Narzędzia do kodowania szybko się zmieniają i co jakiś czas zmiana oznacza konieczność migracji. Google przeprowadził przejście z Gemini CLI na Antigravity CLI. Od 18 czerwca 2026 plany konsumenckie Google nie obejmują już Gemini CLI, ale licencje Gemini Code Assist Standard i Enterprise zachowały dostęp. 30 kwietnia 2027 AWS zakończy wsparcie wtyczek IDE dla Amazon Q Developer, a użytkowników kieruje do Kiro. Windsurf zmienił się w Devin Desktop.

Do migracji podchodzimy jak do małego wdrożenia. Tam, gdzie oba narzędzia czytają AGENTS.md, wspólne instrukcje trafiają właśnie do tego pliku. Dostęp do modeli i uprawnienia przenosimy do nowego narzędzia i ponownie uruchamiamy zadania akceptacyjne z pilotażu. Sprawdzamy też, jak zmiana wpłynie na twój rachunek, i dopiero wtedy wyłączamy stare narzędzie.

Testowanie nowego narzędzia przed zmianą · Komunikat Google o Gemini CLI i Antigravity CLI · Informacja AWS o końcu wsparcia dla wtyczek IDE Amazon Q Developer

• Które zespoły dają agentom prawdziwą pracę i jakiego rodzaju jest to praca
• Nakład pracy na review i poprawki w pull requestach od agentów w porównaniu z poziomem sprzed wdrożenia
• Koszt wdrożenia w przeliczeniu na każdą zaakceptowaną zmianę