10 błędów przy wdrażaniu AI w zespole programistów

Pierwsza wersja tego wpisu była listą ogólnych porad, które mógł napisać każdy. Przepisałem ją na tym, co widzę u klienta, z którym pracuję od ponad roku. Zespół liczy kilkadziesiąt osób: programiści z 15–25-letnim stażem w C++, .NET i SQL, wdrożeniowcy, osoby od dokumentacji i dział handlowy. Nazw nie podaję. Liczby pochodzą z moich notatek miesięcznych i z DevLens, którym mierzymy repozytorium zespołu.

Wspólny mianownik całej listy: narzędzie jest najmniejszym problemem. Błędy siedzą obok kodu i w głowach.

1. Zakładacie, że instalacja się udała

Na pierwszych warsztatach trzeba było dokończyć instalację u osób, które były pewne, że zrobiły ją same. Agent się uruchamiał, więc wyglądało to na sukces.

Co robić: pierwsze spotkanie to wspólna instalacja i jedno małe zadanie na prawdziwym kodzie. Dopiero po nim wiadomo, że każdy ma działające środowisko.

2. Uczycie Gita zamiast obsługi agenta, który obsługuje Gita

Część doświadczonych programistów przez lata pracowała na SVN, bez Gita. Klasyczne szkolenie z Gita to kilka dni i dużo frustracji. Poszliśmy inaczej: uczymy, jak zlecić agentowi gałąź, commit czy rozwiązanie konfliktu i jak sprawdzić, co zrobił.

Co robić: narzędzia okołoprogramistyczne (Git, wdrożenia, paczki) uczcie przez agenta. Nie tracicie czasu na naukę narzędzia na pamięć, a programista od razu pracuje w nowym trybie.

3. Jeden model i jeden poziom wysiłku do wszystkiego

To kuleje u wszystkich w tym zespole. Ten sam model poprawia literówkę i przepisuje moduł na nowy .NET. Efekt to albo przepalone limity, albo płytkie rozwiązania trudnych zadań. Z tym wiąże się koszt: u jednego z kierowników plan za 200 USD miesięcznie okazał się niepotrzebny.

Co robić: osobne, krótkie szkolenie z doboru modelu i poziomu rozumowania do zadania. Plan subskrypcji podnoście dopiero wtedy, gdy limity naprawdę blokują pracę.

4. Zakładacie, że legacy się nie nada

Stary program w C++ Builderze uchodził za coś, czego agent nie ruszy. W czerwcu agent skompilował go z linii poleceń, a potem powstał skill do szybkiego przenoszenia starych okien do wersji webowej. Legacy nie jest balastem. Programista, który zna domenę od 20 lat, a nic nie robi ręcznie, ma szansę być najszybszy w zespole.

Co robić: zacznijcie od najstarszego, najbardziej „nieruszalnego” kawałka systemu. Jeśli agent sobie z nim poradzi, znika główny argument przeciw.

5. Szukacie zysku w kodzie, a on leży obok kodu

W tym zespole nikt nie ma problemu z SQL-em. Problem zaczyna się po napisaniu kodu: paczki wdrożeniowe, wdrożenie u klienta, dokumentacja, instrukcje. Moja ocena: przeniesienie gotowej zmiany do klienta trwa tam około 10 razy dłużej, niż powinno.

Co robić: szkolenie z wdrażania agentem i budowania paczek, dokumentacja i instrukcje użytkownika generowane ze zrzutów ekranu. Tu agent oddaje najwięcej godzin, a mało kto od tego zaczyna.

6. Pomijacie ludzi, którzy nie programują

Na jednym z warsztatów programistów wyprzedzała osoba, która sama programistą nie jest. Na co dzień robi agentem dokumentację i instrukcje użytkownika ze zrzutów ekranu. W dziale handlowym działania wokół sprzedaży (przygotowanie do spotkań, oferty, analiza dokumentacji przetargowej) zajmują 60–75% czasu. Agent porównuje dokumenty przetargowe i sprawdza zgodność z wymaganiami.

Pada też pytanie: „co ja będę robić, skoro programista wygeneruje dokumentację agentem?”. Trzeba na nie odpowiedzieć wprost i wcześnie.

Co robić: osobna ścieżka dla wdrożeniowców, dokumentacji i handlu, na ich własnych dokumentach.

7. Bierzecie obawy za opór

Są dwa rodzaje obaw. Programiści mówią „AI robi niedokładnie”. Zarząd pyta, co będzie, gdy dostawca podniesie ceny albo odetnie dostęp, i co z dokumentami, które nie mogą wyjść z firmy.

Trzech sceptycznych programistów przeszło tę samą drogę: od „AI robi niedokładnie”, przez „agent musi dobrze rozumieć kod”, do oddawania agentowi całych warstw pracy, łącznie z grafiką interfejsu. Trwało to 2–3 miesiące. To obserwacja jednej grupy, nie obietnica dla każdego zespołu. Obawy zarządu rozbrajaliśmy testami: modele alternatywne, rozliczenie za tokeny i model lokalny do dokumentów, które nie mogą wyjść z firmy (testy na naszym sprzęcie).

Co robić: sceptykom dajcie zadania na ich własnym kodzie. Zarządowi pokażcie plan B, zanim o niego zapyta.

8. Jeden agent i brak kontroli

Najlepszy nawyk w tym zespole wprowadził jeden z programistów: dwóch agentów, z których drugi sprawdza pracę pierwszego i poprawia błędy, zanim kod trafi do klienta. Proste i bardzo skuteczne.

Co robić: wpiszcie drugiego agenta-recenzenta do standardu pracy, tak jak code review między ludźmi.

9. Wiedza zostaje w jednej głowie

W lipcu DevLens pokazał, że czterech programistów to jedyne osoby, które znają swoje obszary systemu. Jeśli któryś odejdzie, firma traci wiedzę, której nie ma nigdzie zapisanej.

Agent zmienia to na dwa sposoby. Może opisać obszary, które zna jedna osoba (DevLens sam podpowiada to jako priorytet). I zostawia ślad w repozytorium: cztery osoby pracujące z agentem piszą opisy commitów o średniej długości od 226 do 752 znaków, reszta zespołu od 0 do 13. Jeden z programistów zaproponował wspólną pamięć dla agentów, żeby wiedza jednej osoby była dostępna dla wszystkich. Ten kierunek właśnie sprawdzamy.

Co robić: zacznijcie od obszarów z jednym właścicielem. Tam dokumentacja generowana przez agenta daje najszybszy zwrot.

10. Mierzycie nastroje zamiast repozytorium

Ankieta „czy AI Ci pomaga?” mówi niewiele. Repozytorium mówi więcej. W lipcu u dwóch programistów DevLens pokazał mniej więcej dwukrotny wzrost wydajności. Ciekawsze od tempa są jednak opisy commitów z punktu 9: widać po nich, kto naprawdę zmienił sposób pracy, zanim zmieni się tempo.

Co robić: zmierzcie historię repozytorium przed startem i powtarzajcie pomiar co miesiąc. Jak ułożyć całe wdrożenie krok po kroku, opisałem w osobnym wpisie: wdrożenie AI w zespole programistów krok po kroku. Ile z tych błędów jest u Was, sprawdzicie w quizie gotowości na AI, a jak omijamy je na Waszym kodzie, pokazuje Coaching Sprint.