Transformacja AI w projekcie IT, etap 1: ocena stanu wyjściowego

Zanim ocenimy repozytorium, trzeba ustalić, jak zespół korzysta z AI przy pracy nad tym projektem. W rozmowach przed wdrożeniami często słyszę, że narzędzia są znane i używane na co dzień. Pomiar potrafi jednak pokazać aktywność zerową albo sporadyczną. Nie musi to oznaczać celowego wprowadzania w błąd. Jednorazowy kontakt z czatem albo użycie prywatnego konta może wystarczyć, aby odpowiedź „używam” wydawała się uczciwa.

Dlatego ocena stanu wyjściowego nie powinna opierać się wyłącznie na deklaracjach. Trzeba zestawić je z weryfikowalnymi śladami:

• Statystyki wykorzystania licencji. Narzędzia zarządzane przez firmę często udostępniają panele użycia. Licencje nietknięte od tygodni pozwalają porównać deklarowaną znajomość z rzeczywistą aktywnością.
• Zgłoszenia i prośby o narzędzia. Autentyczne zainteresowanie zostawia ślady: wnioski o dostęp, pytania o budżet na subskrypcję, prośby o zgodę na nowe narzędzie. Brak takich zgłoszeń jest sygnałem, który warto sprawdzić razem ze statystykami i rozmowami z zespołem.
• Przegląd repozytorium. Praca z agentami może zostawiać ślady w kodzie: pliki konfiguracyjne, wersjonowane instrukcje kontekstu albo wzorce widoczne w historii zmian. Ich brak nie dowodzi, że agent nie był używany. Oznacza jednak, że repozytorium nie zawiera wersjonowanego sposobu pracy, który da się potwierdzić i odtworzyć.

Rozbieżność między deklaracją a zmierzonym użyciem nie przesądza o braku kompetencji. Jest sygnałem, by zamiast szkolenia przypominającego przeprowadzić wspólne zadanie na tym repozytorium i sprawdzić, w którym miejscu workflow się zatrzymuje.

Drugi obszar oceny to sam projekt. Nie chodzi o wiek technologii ani o etykietę „legacy”. Chodzi o to, ile system mówi o sobie sam i ile pracy wymaga jego uruchomienie.

Dług technologiczny warto oceniać przez przewidywalność, nie przez metrykę wieku. Starszy kod o spójnych konwencjach, czytelnych granicach modułów i stabilnych interfejsach bywa dla agenta łatwiejszy niż młody projekt pisany chaotycznie. Pytanie diagnostyczne brzmi: czy po przeczytaniu kilku modułów można przewidzieć, jak wygląda reszta.

Dokumentacja i wiedza nieformalna decydują o tym, co agent w ogóle może wiedzieć. Agent czyta repozytorium, nie pamięć zespołu. Każda reguła, która istnieje tylko w głowach lub na prywatnych kanałach, jest dla niego niewidoczna. Ocena powinna wskazać, które ustalenia mają formę zapisu w kodzie, testach lub dokumentach, a które trzeba dopiero spisać.

Środowisko deweloperskie to najprostszy miernik praktyczny. Jeżeli nowa osoba potrzebuje tygodnia i pomocy dwóch kolegów, żeby uruchomić projekt lokalnie, agent zatrzyma się na tym samym progu. Czas wdrożenia nowego członka zespołu jest dobrym przybliżeniem kosztu wdrożenia agenta.

Ten obszar pozwala też sprawdzić popularne przekonanie, że system jest „za trudny dla AI”. Traktuję je jako hipotezę, nie jako fakt. W praktyce zgłaszana trudność często nie wynika z samej domeny. Bywa sumą braków, które da się nazwać i po kolei usuwać: brakującej konfiguracji, nieopisanych poleceń, wiedzy poza repozytorium.

Kontrole statyczne, testy oraz mocne i szybkie CI to praktyki uznawane za słuszne od dekad, a mimo to często odbierane jako wygórowane wymagania. Powód jest prosty. Człowiek kompensuje słabą pętlę zwrotną cierpliwością, pamięcią i doświadczeniem. Agent nie ma dostępu do tych samych nieformalnych sposobów kompensacji, dlatego wynik kontroli jest jego podstawową informacją o stanie systemu.

Stan pętli trzeba zmierzyć liczbami, nie przymiotnikami:

• Czas pełnego przebiegu CI. Przebieg liczony w godzinach nie dyskwalifikuje projektu, ale wyznacza pierwszy cel. W projektach, które obserwowałem, realne było skrócenie go dwu- lub trzykrotnie. Dla nowego systemu traktuję 5–8 minut jako praktyczny budżet pełnego przebiegu, a okolice 4 minut jako ambitny cel. To punkt odniesienia do pomiaru, nie uniwersalny standard dla każdego stosu i zakresu testów.
• Testy niestabilne. Test, który raz przechodzi, a raz nie, trzeba traktować jako blokadę do usunięcia, nie jako niedogodność do ponawiania. Człowiek uruchomi go drugi raz i pójdzie dalej. Agent odczyta losowy wynik jako skutek własnej zmiany i zacznie poprawiać kod, który działa.
• Uruchamialność lokalna. Kluczowe kontrole muszą działać po jednym poleceniu, lokalnie, bez ręcznie przygotowanego środowiska. Każdy krok wymagający wiedzy spoza repozytorium zatrzymuje agenta w połowie pracy.

Wynikiem oceny tego obszaru jest lista braków pętli z przybliżonym kosztem usunięcia każdego z nich. Zwykle właśnie tu rozstrzyga się, czy pierwszy kwartał transformacji przyniesie efekty w produkcie, czy będzie kwartałem porządkowania.

Kompetencje można zmierzyć zadaniem próbnym. Trudniejsze i ważniejsze są postawy, bo to one decydują, czy narzędzia będą używane po zakończeniu wdrożenia.

Za deklaracjami o powszechnym użyciu kryją się zwykle dwie grupy. Pierwsza to osoby, które naprawdę pracują z AI, ale nie mówią o tym otwarcie, z obawy przed opinią, że ich kod pisze za nich narzędzie. Druga to sceptycy, którzy wykonali jedną próbę bez konfiguracji, otrzymali słaby wynik i uznali temat za rozstrzygnięty. Obie grupy wzmacniają się nawzajem: cisi praktycy milczą, więc jedyną publiczną narracją pozostaje nieudany eksperyment.

Z moich obserwacji wynika, że sam komunikat zarządu rzadko zmienia tę równowagę. Większy wpływ ma demonstracja na miejscu, w tym konkretnym systemie, wykonana przez osobę o mocnej pozycji technicznej. Dowód pozwala ocenić wynik tam, gdzie argumenty pozostają abstrakcyjne. Taki moment potrafi wywołać przejściowe napięcia, zwłaszcza wobec osób, które publicznie broniły tezy o niewykonalności.

Przy budowaniu konsensusu sprawdza się kilka zasad. W obserwowanych przeze mnie wdrożeniach jednomyślność nie była warunkiem startu. Potrzebna była grupa praktyków oraz większość gotowa oceniać wyniki prób. Demonstracja działa lepiej niż przekonywanie. Jeżeli organizacja rzeczywiście podjęła decyzję o transformacji, komunikacja powinna oddzielać przyjęty kierunek od elementów podlegających dyskusji, takich jak tempo, narzędzia i zabezpieczenia. Pytania zasługują na rzeczowe odpowiedzi, łącznie ze wskazaniem obszarów, w których AI zawodzi. Gdy pracownik odmawia korzystania z zatwierdzonych narzędzi mimo uzgodnionych zasad, jest to temat organizacyjny wymagający decyzji przełożonego, a nie spór światopoglądowy do prowadzenia na forum zespołu.

Nawet dobrze przygotowane repozytorium nie wystarczy, jeśli zespół nie zna zasad pracy z kodem i danymi albo nikt nie może zaakceptować kosztu oraz ryzyka. Ta część oceny sprawdza warunki organizacyjne, które bezpośrednio ograniczają pracę agentów w projekcie.

Jakość wejścia do zespołu. Wynik agenta zależy od jakości materiału wejściowego. Jeżeli wymagania są nieprecyzyjne, a zadania wymagają dopytywania na każdym kroku, niejasność przejdzie również do proponowanego kodu. Przegląd kilkunastu ostatnich zadań z backlogu mówi o gotowości procesu więcej niż deklaracje o metodyce.

Dane i zasady ich użycia. Przed startem musi być jasne, co wolno przekazać do modelu: kod objęty umowami, dane klientów, zapisy kontraktów, wymagania regulacyjne. Brak takiej polityki może zatrzymać wdrożenie nawet wtedy, gdy projekt jest technicznie przygotowany, bo odpowiedzialny zespół w niejasnej sytuacji wybierze niekorzystanie z narzędzi.

Sponsor i budżet. Ocena powinna wskazać, kto podejmuje decyzję o transformacji, kto finansuje licencje i pracę nad środowiskiem oraz jaki poziom ryzyka organizacja akceptuje. Bez tego raport ze stanu wyjściowego pozostaje dokumentem bez adresata.

Mierniki. Jeżeli organizacja nie mierzy dziś ani czasu realizacji zmian, ani stabilności dostarczania, trudno będzie jej rzetelnie wykazać efekt transformacji. Ustalenie choćby prostego punktu odniesienia jest częścią tego etapu, bo pomiar efektów w dalszej części serii musi mieć do czego wracać.

Zebrane ustalenia mają trzy warstwy. Stan projektu pokazuje, co agent może samodzielnie zrozumieć i sprawdzić. Sposób pracy zespołu decyduje, czy nowy workflow będzie powtarzany po pierwszej próbie. Warunki organizacyjne wyznaczają granice danych, umów, budżetu i odpowiedzialności. Zakres oraz tempo pierwszej zmiany muszą pasować do wszystkich trzech.

Projekt z mocną pętlą zwrotną, na przykład ze stabilnymi testami end-to-end obejmującymi zmieniane zachowanie, pozwala szybciej rozszerzać zakres pracy agentów. Automatyczne kontrole mogą wtedy wychwycić część błędów wcześniej niż przegląd ręczny. Tempo należy zwiększać proporcjonalnie do pokrycia, stabilności i czytelności tych kontroli.

Projekt w złym stanie odwraca kolejność, ale nie odwołuje kierunku. AI zaczyna wtedy od porządkowania i wzmacniania: skracania przebiegu CI, stabilizowania testów, uzupełniania kontroli statycznych, spisywania wiedzy dostępnej dotąd tylko w głowach. Dokładanie kolejnych funkcji do nieuporządkowanego systemu powiększa dług, który właśnie ograniczył tempo.

Niezależnie od tempa dobrym pierwszym zadaniem bywa duża, lecz dobrze ograniczona zaległość zespołu: praca odkładana od miesięcy z braku czasu, z jasnymi kryteriami akceptacji i odwracalnym skutkiem. Takie otwarcie może poprawić morale, bo zespół widzi zmianę działającą na jego rzecz, i dostarcza konkretnego dowodu użyteczności.

Ustalenia domyka kilka pytań kontrolnych:

• Czy repozytorium uruchamia się lokalnie po jednym poleceniu, ile trwa pełny przebieg CI i które testy są niestabilne?
• Jak zespół używa AI przy pracy nad tym projektem i czy potrafi wspólnie zakończyć zadanie próbne?
• Jaki kod i dane wolno przekazywać do modeli, kto finansuje narzędzia i kto akceptuje ryzyko zmiany?

Odpowiedzi nie tworzą wyniku „gotowi lub niegotowi”. Wyznaczają bezpieczny zakres pierwszej zmiany oraz braki, które trzeba usunąć przed rozszerzeniem pracy agentów. To punkt wejścia do kolejnego etapu serii: strategii i wyboru narzędzi do pracy z AI.