Nie potrzebujemy szybszych statków

Dwa dni na napisanie kodu z agentem AI. Wcześniej zajmowało to dwa tygodnie.

Trzy tygodnie na wdrożenie tej samej zmiany na produkcję.

Ten slajd Matyldy Wawrzak-Rajtar z Orange Polska streszcza całe wystąpienie: kodowanie przyspieszyło ale nie delivery. Programista czuje to przyspieszenie, ale organizacja go nie widzi.

Matylda zaznaczyła, że nie chce już dyskutować o tym, czy AI działa. Działa, a Jej zespół potrafi zbudować nową aplikację, prawie nie pisząc kodu ręcznie. Od wiosny tyle się zmieniło, że musieli przepisać całą roadmapę. Problem leży gdzie indziej.

Szybki statek, zakorkowany port

Żeby to wyjaśnić, Matylda sięgnęła do historii transportu morskiego z połowy XX wieku. Statki handlowe zrobiły się wtedy dużo szybsze, a mimo to spędzały około dwóch trzecich czasu w portach, czekając na rozładunek. Ekipy po dwudziestu dokerów przenosiły ręcznie każdy worek i każdą skrzynię. Statek był szybki, port nie.

Agent AI to właśnie taki szybki statek. A porty to nasze firmy.

W startupie trzy osoby to trzy kanały komunikacji. Ktoś ma pomysł i po kwadransie kod jest na produkcji. W korporacji jest cło, dokerzy, spedytorzy, regulacje, audyt i dekady starych systemów. Dziesięć osób to już 45 kanałów komunikacji, a pięćdziesiąt osób w procesie to 1225 kanałów. Na każdym z nich zmiana czeka w kolejce.

W dużej firmie samo programowanie skurczyło się do minimum, a coraz częściej do przeglądania kodu. Cała reszta procesu stoi jednak w miejscu.

„Kod przyspieszył. Dostarczenie - nie. Deweloper to czuje, organizacja tego nie widzi”. - Matylda Wawrzak-Rajtar

Gdzie naprawdę stoi zmiana?

Matylda rozpisała drogę zmiany na trzy etapy:

Przed kodem: biznes przynosi jedno zdanie, a potem przez tygodnie trwa doprecyzowywanie. Wiedza o architekturze jest w głowach ludzi i na tysiącach stron wiki, więc agent nie wie, co ma zbudować. Kod: dwa dni. Po kodzie: ręcznie składane pipeline’y, środowiska testowe, których zestawienie jest osobnym projektem, i szukanie przyczyn błędów w logach.

Recepta: usprawnić oba końce naraz. Lepiej przygotować to, co wchodzi do procesu (wymagania i architekturę zrozumiałą dla agentów), i szybciej przeprowadzić zmianę przez testy i wdrożenie.

Agent, który grilluje biznes

Adam Dąbrowski zaczął od wejścia do procesu. Biznes potrafi przyjść z jednym zdaniem, na przykład „zróbcie nam asystenta AI dla architektów”, i uważa to za wymaganie. Do tej pory analityk i architekt spędzali tygodnie na spotkaniach, żeby zrozumieć, o co chodzi.

W Orange, inspirując się podejściem Matta Pococka, zbudowali agenta, który „grilluje” biznes rundami pytań. Dopytuje o skrajne przypadki, rozbija potrzebę na części i drąży tak długo, aż temat się wyczerpie. Zamiast hasła zespół dostaje konkretny materiał do dalszej pracy.

Kod nie kłamie

Drugi problem to szukanie zależności na tysiącach stron Confluence’a, które w dużej firmie są nieaktualne albo nigdy nie powstały, bo wiedza jest tylko w głowach.

Adam doszedł do prostego wniosku: najbardziej aktualnym i wiarygodnym źródłem wiedzy o firmie jest kod działający na produkcji. Skoro kod działa, tak właśnie działa biznes.

„Jeśli dokumentacja mówi co innego niż kod, to dokumentacja kłamie”.

Dlatego zespół zbudował bazę wiedzy zasilaną bezpośrednio kodem z repozytoriów i udostępnił ją agentom.

Kiedy agent pisze kod dziesięć razy szybciej, dokumentacja rozjeżdża się z nim jeszcze szybciej. Orange wprowadził więc twarde reguły w pipeline’ach. Dokumentacja powstaje z kodu, w jednym standardzie. Zmiana dokumentacji jest obowiązkową częścią każdego pull requesta. A jeśli opis architektury nie zgadza się z kodem, pull request jest automatycznie odrzucany.

Z TypeScriptu na Rusta w tydzień

Testy to kolejny korek. Integracje zwykle sprawdza się dopiero na wspólnych środowiskach testowych, które często nie działają i blokują wdrożenia.

W Orange agent pisze scenariusze testów (BDD) i specyfikację równolegle z kodem. Zewnętrzne systemy, takie jak bazy danych czy obce API, są zastępowane lokalnymi kopiami uruchamianymi w kontenerach na komputerze programisty. Programista i agent sprawdzają integracje u siebie, zanim kod trafi na wspólne środowisko.

Jaki to daje efekt? Matylda podała przykład. Kiedy trzeba było zmienić technologię, zespół przepisał całą aplikację z TypeScriptu na Rusta w tydzień. Dzięki solidnym testom mieli pewność, że nowy kod działa tak samo jak stary. Zużycie pamięci spadło ponad dwudziestokrotnie.

Genialny stażysta bez przepustki

„Agent bez uprawnień i integracji jest jak genialny stażysta pierwszego dnia w korporacji. Bardzo mądry, ale bez dostępu do systemów nic nie zrobi”. - Adam Dąbrowski

Dlatego Orange zbudował wspólne serwery MCP (standard podłączania agentów do narzędzi), połączone z chmurą Google, GitHubem i GitLabem, logami w Elasticsearch i Jirą. Agent sam pobiera zadania, przegląda kod, analizuje logi i szuka przyczyn błędów.

Adam dodał jednak ostrzeżenie. Jeśli pobierzesz z internetu niesprawdzone rozszerzenie dla agenta (tzw. skill), na przykład takie, które robi ładne slajdy, może się okazać, że w środku jest kod wykradający dane z twojego komputera i wysyłający je na obcy serwer. Dlatego Orange ma własny, wewnętrzny sklep ze skillami, a wszystkie rozszerzenia i serwery MCP przechodzą wewnętrzny audyt.

Trzy rodzaje modeli, trzy rodzaje kosztów

Agenci przetwarzający ogromne, stare repozytoria potrafią spalić mnóstwo tokenów. Orange dzieli więc modele na trzy grupy:

Największe modele komercyjne służą tylko do planowania, architektury, trudnych decyzji i zarządzania innymi agentami. Za nie płaci się od tokena. Modele uruchamiane na własnej infrastrukturze analizują stary kod, piszą testy i wykonują powtarzalną pracę. Kosztuje utrzymanie serwerów, a nie rachunek za tokeny. Małe, szybkie modele podejmują proste decyzje w bramkach jakości.

Nagroda za szybkość? Więcej pracy

Ten fragment wywołał na sali poruszenie. Matylda pokazała trzech programistów: pierwszy z agentem pracuje pięć razy szybciej, drugi dwa razy szybciej, trzeci w dawnym tempie.

Co robi firma z tym najszybszym? Daje mu pięć razy więcej zadań.

Nikt nie widzi, ile kosztuje go to umysłowo, a wolniejsi się zniechęcają. To błędne koło. Czas odzyskany dzięki AI trzeba inwestować w usprawnianie „portu”, a nie w zasypywanie ludzi kolejnymi zadaniami.

Kontener zamiast szybszego statku

Co ostatecznie rozwiązało problem zakorkowanych portów? W 1956 roku Malcolm McLean wymyślił kontener. Zamiast worków pojawiła się skrzynia o stałych wymiarach, do portów trafiły dźwigi, a statki dostosowano do kontenerów. Przeładunek wzrósł z 1,7 tony do 30 ton na godzinę.

Kontener nie zmienił prędkości statków. Zmienił sposób działania portu.

Matylda zostawiła salę z trzema zadaniami:

Zmierzcie jedną zmianę. Gdzie na drodze od pomysłu do produkcji czeka najdłużej? Zapiszcie zasady ryzyka jako kod, czyli jako automatyczne bramki w pipeline’ie, a nie jako dokument PDF. Wybierzcie swój kontener: jeden spójny dokument, na przykład specyfikację w Markdownie, który przejdzie przez cały proces bez ręcznego przepakowywania.

Pytania z sali

Zwróciłem uwagę, jak przedstawiła się nasza prelegentka. Powiedziała, że zajmuje się transformacją IT. Potem dodała, że jeśli IT nie unowocześni własnego warsztatu, to nie nadąży za wymaganiami biznesu a dojrzała organizacja zaczyna zmianę od siebie.

Jeśli nie (tylko) kodowanie, to w co inwestować najpierw: w lepsze wymagania i architekturę czy w automatyzację testów i wdrożeń. Adam odpowiedział, że w jedno napędza drugie. Automatyzacja daje czysty kod, czysty kod pozwala utrzymać aktualną dokumentację, dokumentacja zasila bazę wiedzy, a dzięki niej analitycy i architekci mają wreszcie solidny materiał do rozmowy z biznesem.

Andrzej Sobczak zapytał o zmiany na rynku pracy dla programistów, analityków i architektów. Adam jest zdania, że analitycy i architekci są na wygranej pozycji, bo rozumieją i technologię, i biznes. Z programistami jest trudniej. Ci, którzy zamkną się w samym pisaniu kodu, zostaną zastąpieni przez agentów. Wygrają ci, którzy zrozumieją architekturę i procesy biznesowe.