Wdrożenie AI w zespole programistów: plan krok po kroku

W zespole trzech osób wystarczy, że wszyscy zainstalują agenta i zaczną pracować. W zespole dwudziestu i więcej osób nie wdrażacie narzędzia, tylko nowy sposób pracy. Robi się to falami, na prawdziwym kodzie, z pomiarem na początku i na końcu.

Poniżej kolejność, którą przeszliśmy u klienta z kilkudziesięcioosobowym zespołem IT (programiści, wdrożeniowcy, dokumentacja, dział handlowy). Nazw nie podaję. Typowe błędy z tego samego wdrożenia opisałem osobno: 10 błędów przy wdrażaniu AI w zespole programistów.

Harmonogram, który przeszliśmy

Miesiąc	Kto	Co
Czerwiec	zespół 7 osób	warsztaty na wspólnym projekcie, instalacja, dokumentacja ze zrzutów ekranu
Lipiec	pojedyncze osoby	szkolenia pod codzienną pracę, Git przez agenta, pierwszy pomiar efektów
Sierpień	programiści, handel	pętle agentowe, wdrożenia i paczki przez agenta, dobór modelu, osobna ścieżka dla handlu
Wrzesień	programiści	drugi agent jako recenzent, przepisywanie modułów na nowy .NET, pierwsze dostawy od agentów u klientów

Krok 0. Zmierzcie repozytorium, zanim ktokolwiek zainstaluje agenta

Bez pomiaru na starcie za kwartał nie odpowiecie zarządowi, co dało wdrożenie. U klienta DevLens przeszedł historię repozytorium: 21 aktywnych autorów, kto pracuje w jakim obszarze, jaki ma rytm pracy i gdzie wiedza siedzi w jednej głowie. Czterech programistów okazało się jedynymi osobami, które znają swoje obszary. To wskazuje, gdzie agent powinien najpierw pisać dokumentację.

Krok 1. Jeden prawdziwy projekt na pierwsze warsztaty

Pierwszy zespół (7 osób) pracował na wspólnym, prawdziwym projekcie: systemie zgłoszeń. Każdy miał własną lokalną bazę SQLite, więc nikt nikomu nie psuł danych. Zadania dopasowaliśmy do ról: programiści rozbudowywali formularze, osoba od dokumentacji robiła agentem dokumentację.

Przy okazji wyszło, że część osób tylko myślała, że ma działającą instalację. Dlatego instalacja jest częścią warsztatu, a nie zadaniem domowym.

Krok 2. Git i wdrożenia przez agenta

Część programistów latami pracowała bez Gita. Nie uczymy go od podstaw. Uczymy, jak zlecić agentowi gałąź, commit i rozwiązanie konfliktu oraz jak sprawdzić wynik. Tak samo z wdrożeniem na produkcję i budowaniem paczek wdrożeniowych. W tym zespole najwięcej czasu ginęło właśnie po napisaniu kodu, przy przenoszeniu zmian do klienta.

Krok 3. Szkolenia pod to, co ktoś robi na co dzień

Od drugiego miesiąca pracujemy indywidualnie, na zadaniach z kalendarza danej osoby:

• kompilacja starego programu w C++ Builderze z linii poleceń, a potem skill do szybkiego przenoszenia starych okien do wersji webowej;
• analiza dokumentacji przetargowej i porównywanie dokumentów;
• dokumentacja i instrukcje użytkownika ze zrzutów ekranu;
• przepisywanie modułów na nowy .NET.

Taki trening przekonuje lepiej niż jakakolwiek prezentacja, bo efekt widać na własnym kodzie.

Krok 4. Nie wybierajcie championów z listy entuzjastów

Klasyczna rada mówi: zacznijcie od entuzjastów. U nas nie wszyscy entuzjaści chcieli pokazywać, co robią. Za to jeden z początkowo nieufnych programistów jest dziś jednym z najmocniejszych użytkowników w zespole: pracuje w pętlach agentowych, a drugiego agenta puszcza do sprawdzania pierwszego. W lipcowym pomiarze DevLens miał najwyższy wskaźnik produktywności w zespole.

Championów widać po kilku tygodniach pracy, nie po deklaracjach na pierwszym spotkaniu.

Krok 5. Dobór modelu jako osobne szkolenie

Po dwóch miesiącach wszyscy nadal używali jednego modelu do wszystkiego. Dobór modelu i poziomu rozumowania do zadania to osobna umiejętność. Od niej zależy jakość rozwiązań trudnych zadań i koszt subskrypcji.

Krok 6. Drugi agent jako recenzent

Standard, który warto wpisać do procesu: jeden agent pisze, drugi sprawdza i poprawia błędy, zanim kod trafi do klienta. Działa jak code review, tylko szybciej, i nie zastępuje przeglądu przez człowieka przy ważnych zmianach.

Krok 7. Plan B dla zarządu: dane i dostawca

Na etapie wdrożenia zarząd pyta o dwie rzeczy: co z dokumentami, które nie mogą wyjść z firmy, i co, jeśli dostawca zmieni ceny albo warunki. Odpowiedzią są testy, nie zapewnienia: modele alternatywne, rozliczenie za tokeny i model lokalny do poufnych dokumentów. Decyzję o większych planach zespołowych klient świadomie odłożył, żeby nie uzależniać się od jednego dostawcy.

Krok 8. Osobna ścieżka dla handlu i nie-programistów

Działania wokół sprzedaży zajmują w dziale handlowym 60–75% czasu: przygotowanie do spotkań, oferty, dokumentacja przetargowa. To osobne szkolenie, na ich materiałach i na tańszym planie subskrypcji. Więcej w programie AI dla działu handlowego.

Krok 9. Pomiar po, na tych samych danych

Po miesiącu i po kwartale powtarzacie pomiar z kroku 0. W lipcu DevLens pokazał u dwóch programistów mniej więcej dwukrotny wzrost wydajności. Równie ważny sygnał to styl commitów: osoby pracujące z agentem piszą długie, ustrukturyzowane opisy zmian, reszta zespołu niemal puste. Po tym widać, kto naprawdę zmienił sposób pracy.

Czy AI zastąpi programistów w Waszym zespole?

Nie w tym sensie, którego boi się zespół. W projekcie systemu biletowego NFC (klient pod NDA) z czterech programistów utrzymujących stary system został jeden, z asystentem AI. Pozostali trzej przeszli do nowych projektów i nikt nie odszedł. Agent przejmuje rutynę: testy, parsery, dokumentację. Decyzje i odpowiedzialność za kod zostają u ludzi. Opór zespołu rozbrajamy danymi z kroku 0, nie deklaracjami. Szczegóły w case study systemu biletowego.

Ile to trwa

Pierwsze dostawy od agentów u klientów pojawiły się we wrześniu, trzy miesiące po czerwcowych warsztatach. U sceptyków zmiana podejścia trwała 2–3 miesiące. To obserwacja jednego zespołu, nie gwarancja. W programie Coaching Sprint przechodzimy tę kolejność razem z zespołem, na jego repozytorium. Jeśli chcecie sprawdzić, jak to wyglądałoby u Was, zacznijcie od krótkiej rozmowy.