Vibe architecting, czyli szybka droga do pięknego chaosu

Filip zaczął od prośby do sali: „Podnieście ręce, jeśli korzystacie z AI przy podejmowaniu decyzji. Nie chodzi o pogawędki z czatem, tylko o prawdziwe decyzje”.

Rąk było sporo.

„A teraz niech zostaną w górze ręce tych, którzy pamiętają szczegóły decyzji sprzed pół roku. Nie samo »wybieramy CRM«, tylko cały tok rozumowania, krok po kroku”.

Ręce zaczęły opadać.

Właśnie wokół tego problemu Filip i Anna z Axpo Polska zbudowali swoje wystąpienie. O vibe codingu, czyli pisaniu kodu „na wyczucie” w rozmowie z AI, słyszał każdy. O vibe architectingu przyznałem, że usłyszałem pierwszy raz, kiedy przyszło ich zgłoszenie. I od razu było jasne, że muszą wystąpić.

Tysiąc wymagań, cztery osoby

Axpo Polska produkuje i sprzedaje zieloną energię. Zespół prowadzi program usprawnień dla działu operacyjnego: pięć strumieni wartości, cztery osoby i ponad tysiąc wymagań. I nie są to drobiazgi, tylko wymagania w rodzaju „chcę wystawić fakturę za zużycie energii”.

Jako przykład prelegenci pokazali rozliczenie energii. Sprzedawca ma swoje dane o liczniku klienta, a operator sieci swoje. Żeby rozliczyć zużycie, dane po obu stronach muszą się zgadzać, na przykład taryfa. W teorii to prosta inżynieria danych. W praktyce, przy tysiącu wymagań, rozpisanie tego wszystkiego jest bardzo trudne.

Zespół wracał do tych samych tematów raz za razem i w końcu zrozumiał dlaczego. Duże decyzje spisywał, ale po drodze zapadały dziesiątki drobnych decyzji, których nikt nie zapisywał. Każda z nich zostawała tylko w czyjejś głowie.

„Mieliśmy kopię zapasową: cztery głowy to cztery cache’e. Tylko każdy cache trochę co innego pamięta”. - Filip Małecki

Efekt nastolatka

Pierwszy odruch był oczywisty: wrzućmy wszystko do modelu językowego i zapytajmy.

Anna przypomniała, że Andrzej Dragan nazwał kiedyś LLM-a elokwentnym nastolatkiem. Teraz mówi raczej o doktorancie, ale zdaniem Anny coś z nastolatka mu zostało: każdego ranka wstaje z innym humorem. Zespół nazwał to „efektem nastolatka”.

Eksperyment wyglądał tak: wszystkie wymagania, ten sam prompt powtórzony kilka razy i jedno pytanie: w której aplikacji umieścić daną funkcję? Odpowiedzi brzmiały kolejno:

W rejestrze umów i punktów poboru. W systemie danych pomiarowych. W silniku zgodności z regulacjami. W katalogu produktów i taryf.

Za każdym razem z pełnym przekonaniem. A kiedy zespół zajrzał w tok rozumowania modelu, okazało się, że za każdym razem zapadały decyzje o architekturze, tylko bez udziału architektów. I za każdym razem była to zupełnie inna architektura.

Tak wygląda vibe architecting: decyzje architektoniczne podejmowane gdzieś w łańcuchu myślenia modelu, poza kontrolą człowieka.

Dlaczego teraz to boli bardziej

Filip przypomniał, jak było przed AI. Architekci prosili biznes o priorytety i mówili: tę zmianę przejrzymy, a tamtej nie zdążymy, bo jest mniej ważna. Nadążali.

Dziś aplikacji i zmian przybywa w tempie, za którym nie da się nadążyć. Kiedyś wąskim gardłem było programowanie, a teraz, jak to ujął Filip, wszyscy „naparzają aplikacje”, a architekci muszą to wszystko sprawdzić. Do tego dochodzi góra dokumentacji generowanej przez AI, której nikt nie jest w stanie przeczytać.

Zgredek wchodzi do gry

Skoro programowanie przyspieszyło dzięki AI, zespół uznał, że architekturę też trzeba wpisać w proces. Tak powstał Zgredek, agent AI do pracy nad architekturą.

Najpierw trzeba go było wdrożyć, jak nowego pracownika. Dostał dostęp do dokumentacji w Confluence, do zadań w Jirze (bo czasem tam też trafiała dokumentacja) i do LeanIX, w którym Axpo trzyma swoją architekturę. Dostał zasady architektoniczne, które zespół, jak przyznał, spisał „na kolanie”, bo wcześniej ich nie miał. Dostał też podział na obszary i granice, w których ma się poruszać. TOGAF i ArchiMate znał już sam, ale zespół powiedział mu, jak chce, żeby z nich korzystał.

Od 1140 wymagań do 160 klocków

Pierwsze podejście, czyli całe wymaganie i prośba o wskazanie komponentów, nie zadziałało. Agent znów zachowywał się jak Hermiona: przynosił coraz to inne rozwiązania i kombinował po swojemu.

Przełom przyszedł, kiedy zespół zaczął rozbijać każde wymaganie na bardzo drobne części, nazwane aspektami. Z 1140 wymagań zrobiło się 5460 aspektów. Anna przyznała, że to nie wygląda na przyspieszenie pracy. Ale właśnie wtedy wyniki zaczęły być stabilne.

Potem było już tylko mniej:

5460 aspektów dało 240 zdolności biznesowych (capabilities), dopasowanych do firmowego katalogu i bez duplikatów, zdolności zostały pogrupowane w usługi biznesowe, a z nich powstało około 160 bloków aplikacyjnych (building blocks), każdy z jasno określonymi granicami.

Z tych bloków zespół buduje projekty rozwiązań i całą architekturę. Każdy etap jest powiązany z poprzednim: aspekt, zdolność, blok, dane. Wszystko trafia do trzech współpracujących baz: relacyjnej, wektorowej i grafowej.

Dzięki temu z jednego modelu widać dwie perspektywy: całej firmy (potrzeby, właściciele, wpływ na organizację) i konkretnego rozwiązania (elementy, dane, zależności). Widać też, które komponenty są najcenniejsze. Na przykład punkt poboru energii zasila trzy albo cztery inne obszary.

Filip zwrócił uwagę na jeszcze jedną rzecz: ten sam model ułatwia też podział na zespoły. Dla niego architektura to nie tylko aplikacje, ale cały ekosystem wokół nich.

„Nie wiem, czy chcecie w lewo, czy w prawo”

Podział pracy jest jasny:

model AI proponuje interpretację i dopasowanie, twarde reguły sprawdzają, czy wymagane powiązania istnieją, architekt rozstrzyga luki, decyduje o odpowiedzialności i wyznacza kierunek.

Filip opowiedział o momencie, który był dla niego najważniejszy. Przy jednym z wymagań Zgredek odpowiedział: „Nie wiem, czy chcecie w lewo, czy w prawo”.

Wtedy Filip, jako architekt odpowiedzialny za całą firmę, pomyślał, że tej technologii może zaufać. Wcześniej bał się, że model będzie zmyślał. Teraz widział, że Zgredek wyciąga fakty, a kiedy brakuje mu reguł, pyta człowieka.

Zespół zrobił setki testów. W 95% przypadków Zgredek wskazywał ten sam komponent.

„Nuda. Za każdym razem to samo. I bardzo dobrze!”. - Anna Maria Bober

I właśnie o to chodziło: tu nie ma vibe architectingu.

Przepis na jedno wymaganie

Anna podsumowała to w pięciu krokach:

Zachowaj wymaganie i jego źródło. Rozbij je na aspekty. Znajdź pasujące zdolności i usługi w katalogu. Opisz realizację, granice i wymianę danych. Rozstrzygnij luki i konflikty. Zapisz decyzję i jej powód.

Dzięki temu każdy może odtworzyć, jak zapadły ustalenia.

Dziś mają około 160 opisanych bloków i mogą świadomie decydować, co budować samemu, a co kupić. Własne rozwiązania powstają tylko tam, gdzie na rynku nie ma gotowego dostawcy. Jak mówił Filip, nieważne, czy firma kupi biogazownię, czy postawi magazyn energii, bo ma klocki, z których złoży rozwiązanie.

Zgredek pomaga dziś przy projektowaniu rozwiązań. Docelowo ma wspierać cały proces tworzenia oprogramowania. Ale kierunek nadal wyznacza architekt, nie Zgredek. A odpowiedź na pytanie „dlaczego tak zdecydowaliśmy?” zostaje w modelu architektury, a nie w pamięci modelu językowego.

Pytania z sali

Pod koniec padło pytanie, które nasunęło się wielu słuchaczom: skoro Zgredek pyta „w lewo czy w prawo”, to czy żeby dobrze odpowiedzieć, człowiek nie musi przejść całej ścieżki rozumowania od nowa?

Anna odpowiedziała, że niekoniecznie. W modelu są już istniejące bloki, więc można analizować to, co jest. Szerzej trzeba patrzeć tylko wtedy, gdy zaczyna się od zera. Poza tym przy każdej decyzji zespół zostawia komentarz z uzasadnieniem, do którego zawsze można wrócić, gdy pojawią się nowe dane.

Filip dodał, że całą ścieżkę da się odtworzyć: od wymagania, przez aspekt i zdolność, po blok. To nie jest ładny slajd zrobiony na prezentację. W każdej chwili można zajrzeć do repozytorium i sprawdzić, dlaczego wybrano takie, a nie inne rozwiązanie.