Transformacja AI, etap 2: strategia i wybór narzędzi do pracy z AI

Praktyczna strategia AI dla zespołu programistycznego mieści się na jednej stronie. Potrzebne są trzy decyzje.

Zasady danych. Zespół musi wiedzieć, które informacje mogą trafić do modelu. Najpierw organizacja zatwierdza konkretną usługę, typ konta i konfigurację. Sprawdza przy tym warunki umowy, retencję, wykorzystanie danych do trenowania modeli, region przetwarzania oraz podprocesorów. Następnie określa klasy danych dopuszczone w tej konfiguracji. Sekrety, dane produkcyjne, dane osobowe i kod objęty ograniczeniami umownymi pozostają poza modelem, chyba że polityka firmy wyraźnie dopuszcza konkretny przypadek.

Budżet. Widełki kosztu na osobę powinny być znane przed porównywaniem narzędzi, bo eliminują połowę ofert, zanim zacznie się właściwa dyskusja. Bez ustalonego pułapu decyzję może zablokować dział finansowy po zobaczeniu pierwszej faktury za subskrypcje.

Swoboda wyboru. Trzeba ustalić, kto testuje i zatwierdza narzędzia. W obserwowanych przeze mnie zespołach dobrze działało podejście organiczne: zainteresowani programiści wypróbowują narzędzia na własnych zadaniach, a pozostają te, które przyjęły się w codziennej pracy. Formalne pilotaże z kryteriami akceptacji rzadko wnosiły więcej niż kilka tygodni rzeczywistego użycia.

Te trzy ustalenia zamykają temat strategii. Dokument opisujący transformację AI całej organizacji nie zmieni ani jednego pull requesta.

Najmniej oczywisty wniosek z doboru narzędzi jest taki: skupienie na samym modelu niewiele daje. O wyniku pracy decyduje dopasowanie modelu, harnessu i konkretnego projektu. Surowe możliwości mierzone benchmarkami mają mniejsze znaczenie niż to dopasowanie.

Harness obejmuje wszystko, co otacza model w narzędziu: sposób zbierania kontekstu z repozytorium, możliwość uruchamiania poleceń i testów, pętlę samodzielnego poprawiania błędów oraz obsługę instrukcji projektowych. Ten sam model w dwóch różnych harnessach potrafi dawać tak odmienne wyniki, jakby chodziło o dwa różne modele.

W projektach transformacji AI, w których uczestniczyłem, powtarzał się podobny podział ról:

• Claude Code najczęściej stawał się głównym narzędziem do pracy nad kodem dzięki dopracowanemu harnessowi i dużej społeczności użytkowników. Popularność zapewniała dostęp do udokumentowanych wzorców pracy, gotowych konfiguracji i szybkich odpowiedzi społeczności na typowe problemy.
• ChatGPT w aplikacji desktopowej wspierał analizę, planowanie i pracę poza terminalem.
• Modele open-weight obsługiwane przez OpenCode pojawiały się tam, gdzie zespół optymalizował koszty, a wybrany sposób przetwarzania spełniał jego zasady danych.

Przy wyborze narzędzia porównuj cały zestaw, czyli model i harness, na własnym repozytorium oraz własnych zadaniach. Ranking ocenia model w izolacji i pomija kontekst jego przyszłej pracy.

Agent działający lokalnie w terminalu to profesjonalne narzędzie programisty, równie istotne jak edytor i kompilator. Pracuje bezpośrednio w repozytorium, wykonuje polecenia, uruchamia testy i poprawia własne błędy w pętli kontrolowanej przez programistę.

Do tej klasy trafiają zadania rdzeniowe: implementowanie funkcji, refaktoryzacja, naprawianie błędów i tworzenie testów. Lokalny agent daje kontrolę nad wykonywanymi poleceniami, ale kontekst nadal może być przetwarzany przez zewnętrzny model. Każda zmiana przechodzi przez standardowy proces przeglądu kodu.

Trzeba tu sprostować pierwszy mit: kod tworzony z AI może mieć wysoką jakość. Wynik zależy od pętli weryfikacji, czyli testów, kontroli statycznych i przeglądu człowieka. Gdy te mechanizmy działają, kod agenta przechodzi przez ten sam proces kontroli jakości co kod programisty. Gdy zawodzą, problem istniał już przed włączeniem AI.

Druga klasa obejmuje agentów działających asynchronicznie w chmurze, bez wykorzystywania komputera programisty. W praktyce pełnią dwie główne role.

Pierwsza rola obejmuje zadania poboczne: drobne poprawki, aktualizacje zależności i proste funkcje o jasno określonych kryteriach akceptacji. Takie zadanie można przekazać agentowi i wrócić do własnej pracy, a rezultat ocenić podczas przeglądu pull requesta.

Druga rola obejmuje pracę zdalną i mobilną. Chmurowy agent pozwala rozpocząć zadanie z telefonu między spotkaniami albo kontynuować pracę na urządzeniu bez skonfigurowanego środowiska. Realnie zmienia to codzienną pracę osób, które często podróżują.

Podział ról wynika z charakteru zadania. Rozwój kluczowych elementów produktu zostaje w terminalu, przy programiście i jego narzędziach. Chmura przejmuje pracę, która nie wymaga ciągłego nadzoru.

Osobna klasa narzędzi do przeglądu kodu, testów i dokumentacji wydaje się naturalnym elementem zestawu. W praktyce zwykle nie jest potrzebna na początku. Ten sam agent, który pisze kod, tworzy też testy, uzupełnia dokumentację i pomaga w przeglądzie zmian.

Wyspecjalizowane narzędzia dochodzą później, gdy liczba powtarzalnych zadań uzasadnia ich użycie. Przykładami są automatyczny przegląd kodu w CI, który komentuje każdy pull request według ustalonych reguł, oraz baza wiedzy w formie notebooka AI, gromadząca kontekst projektu poza repozytorium. Oba rozwiązania odpowiadają na rzeczywisty problem skalowania pracy.

Kolejność ma znaczenie ekonomiczne. Zespół, który najpierw kupuje agenta do kodu, a dodatkowe narzędzia dopiero po udokumentowaniu potrzeby, wydaje mniej i szybciej sprawdza, co jest faktycznie używane na co dzień.

Pozostają dwa mity dotyczące kosztów i odpowiedzialności za kod.

Pierwszy dotyczy kosztu narzędzi AI. W obserwowanych przeze mnie zespołach miesięczny koszt mieścił się zwykle między 20 a 200 dolarów na osobę, zależnie od intensywności pracy i sposobu rozliczania. Zakres ten dotyczy konkretnych wdrożeń i nie stanowi uniwersalnego cennika. Opłacalność planu trzeba sprawdzić na realnych zadaniach, porównując koszt subskrypcji z czasem faktycznie zaoszczędzonym w danym zespole.

Drugi mit zakłada, że skoro narzędzie działa, można oddać mu wszystko i przestać czytać kod. Prowadzi to do systemu, którego nikt w zespole nie rozumie. Agent przyspiesza programistę, który wie, czego chce i potrafi ocenić wynik. Rozumienie systemu pozostaje obowiązkiem człowieka. Agent skraca drogę do celu.

Na koniec wracają zasady danych, ponieważ ograniczają wszystkie wcześniejsze decyzje. Zgoda dotyczy konkretnej usługi, typu konta i konfiguracji. Przed wysłaniem pierwszego fragmentu kodu zespół dokumentuje dopuszczone klasy danych oraz tryb przetwarzania, retencję, wykorzystanie danych do trenowania modeli, region przetwarzania i listę podprocesorów.

Punkty kontrolne tego etapu:

• Czy zasady danych, budżet na osobę i sposób wyboru narzędzi są ustalone i znane zespołowi?
• Czy porównano model wraz z harnessem na własnym repozytorium, zamiast polegać na rankingach?
• Czy podział ról między agentem terminalowym a chmurowym wynika z charakteru zadań?

Pozytywne odpowiedzi pozwalają przejść do etapu trzeciego: wyboru pola startowego transformacji. Decyzja o tym, gdzie AI zacznie pracować w produkcie, opiera się na narzędziach i zasadach ustalonych na tym etapie.