AI nie zaprojektuje architektury, której nie może przeczytać

Piotr pokazał sali diagram. Zwykły schemat systemu sklepu: kilka prostokątów, kilka strzałek.

„Czy ten diagram jest poprawny? Nie pytam, czy jest ładny, bo to kwestia gustu. Pytam, czy jest poprawny”.

I od razu dodał: „Ja jeszcze nie wiem. Odpowiem na to pytanie później”.

Organizatorzy, jak zauważył Piotr, chyba celowo ustawili go zaraz po wystąpieniu o vibe architectingu. Tamto było o chaosie, a on postanowił pokazać, jak ten chaos ograniczyć. Andrzej przyznał, że C4 i architektura jako kod to tematy bliższe programistom i architektom rozwiązań niż analitykom. Ale dodał, że analitycy też powinni wyjść ze strefy komfortu i się tego nauczyć.

Architekt żyje nadziejami

Piotr zaczął od pytania, czym właściwie jest praca architekta rozwiązań. Rzadko wymyślamy coś zupełnie nowego. Świat dawno opracował wzorce bezpieczeństwa, infrastruktury i komunikacji. Rola architekta polega na tym, żeby wybrać właściwe wzorce i ułożyć je tak, by spełnić wymagania. Każda decyzja to kompromis: coś zyskujemy, coś oddajemy.

A potem architekt żyje nadziejami. Po pierwsze, że zaprojektowany system zadziała tak, jak założył. Po drugie, że system w ogóle powstanie zgodnie z jego architekturą, a nie obok niej.

Z każdą kolejną rundą zmian system staje się coraz bardziej złożony, a rozumienie go maleje. Przed AI czwartą rundę osiągało się po kilku latach, dziś po kilku miesiącach. Skoro AI przyspieszyło wytwarzanie oprogramowania, musi też pomóc w projektowaniu architektury i w pilnowaniu, żeby wszystko było spójne.

7 tryliardów rozwiązań i 17 cyfr

Potem Piotr zadał sali zagadkę: ile poprawnych rozwiązań ma pusta plansza Sudoku 9×9?

Odpowiedź: prawie 6,67 × 10²¹, czyli blisko 7 tryliardów.

A ile cyfr trzeba wpisać, żeby zostało tylko jedno poprawne rozwiązanie? Wystarczy 17.

„Te 17 cyfr to są decyzje architekta”.

Bez ograniczeń nie ma błędnych rozwiązań. Ale to znaczy też, że nie ma tego najlepszego. Tak samo jest z AI: jeśli nie dostanie ograniczeń, każda odpowiedź będzie poprawna i żadna nie będzie właściwa.

Dwie zasady, zanim AI dotknie architektury

Z tego Piotr wyprowadził dwie zasady.

Pierwsza: kontekst zawężony do zadania. Im więcej materiałów wrzucimy modelowi naraz, tym gorzej sobie radzi, nawet jeśli to największy dostępny model. Liczy się nie to, ile można wrzucić, tylko ile naprawdę trzeba.

Druga: materiał, który AI zrozumie tak, jak chcę, i który mogę sprawdzić ja, a także kompilator. Piotr przyznał, że samo dobre promptowanie nie wystarczyło. W testach wciąż pojawiały się zmyślenia, bo model nie rozumiał systemów. Potrzebny był materiał, który da się sprawdzić automatycznie. Ta zasada ma swoją nazwę: architektura jako kod (Architecture as Code).

Architektura opisem i diagramem stoi

Jak dziś wygląda architektura w firmach? Enterprise Architect, Miro, Confluence, PlantUML, Word. A na końcu jeden doświadczony kolega, do którego wszyscy chodzą z pytaniami.

Architektura jest aktualna w dniu, w którym powstała. Potem ludzie się zmieniają, systemy rosną i po kilku latach mamy sześć nazw tego samego serwisu, czterdzieści diagramów (w większości nieaktualnych) i żadnej możliwości sprawdzenia, co się zmieniło.

Tymczasem piętro niżej siedzą programiści. Mają przeglądy kodu, pipeline’y, narzędzia do sprawdzania jakości i kompilatory. Dlaczego architekci tego nie mają?

Odpowiedź jest prosta: wcześniej się to nie opłacało, bo pisanie architektury jako kodu było drogie. AI sprawiło, że jest tanie.

„Architecture as Code nie zostało wymyślone przez AI, ale dzięki AI w końcu stało się opłacalne”.

C4: mapa kraju i mapa miasta

Co można zapisać jako kod architektury? Elementy (systemy, serwisy, bazy, kolejki, API), każdy z unikalnym identyfikatorem. Relacje między nimi, z określonym typem. Piotr podkreślił, że to, czy komunikacja jest synchroniczna czy asynchroniczna, to typ relacji, a nie komentarz dopisany przy strzałce. Do tego właściwości, takie jak właściciel, status, technologia czy oznaczenie danych osobowych.

Notacji jest wiele, ale Piotr poleca C4, konwencję zaproponowaną przez Simona Browna. Używa w niej tylko dwóch poziomów:

Kontekst: ludzie i sąsiednie systemy. To mapa kraju. Kontenery: wszystko, co da się osobno wdrożyć, czyli serwisy, bazy, kolejki i frontendy. To mapa miasta.

Niższych poziomów, czyli komponentów i kodu, architekci w C4 nie modelują. Prawdą o nich jest repozytorium programistów.

Odpowiedź na pytanie z początku

Piotr wrócił do diagramu sklepu, tym razem zapisanego jako kod. Ktoś zadeklarował w nim relację: zamówienia wywołują płatności.

Kompilator od razu zwrócił błąd: nie może znaleźć elementu o nazwie „payments”. Pipeline zatrzymał się.

I tu jest odpowiedź: diagram nie był poprawny. Serwis płatności w ogóle nie istniał w modelu firmy. Ktoś go po prostu dorysował.

Kiedy architektura jest kodem, można ją testować. Da się wykryć zależności, które kręcą się w kółko, zdarzenia, których nikt nie odbiera, albo procesy, które nie mogą spełnić wymagań. Na przykład proces ma działać przez 99,9% czasu, ale zależy od serwisów, które gwarantują tylko 99,7%.

„Diagram nie jest rysunkiem. Diagram jest widokiem do modelu”.

Kiedy model się zmienia, wszystkie widoki aktualizują się same.

Pilot, nie autopilot

Na tym fundamencie Piotr zbudował narzędzie Architect Cockpit. Działa według zasady: pilot, nie autopilot. Proces ma cztery kroki:

Rozmowa. Piotr odwrócił role: to AI zadaje pytania architektowi, w sposób sokratejski, i dopytuje o wymagania. Rozstrzyga człowiek. Koncepcja i plan. Decyzje są zapisane razem z całym łańcuchem: dlaczego tak, a nie inaczej. Delegowanie. AI samo przygotowuje dokumenty architektury, a kompilator sprawdza ich poprawność i powiązania. Akceptacja. Człowiek dostaje raport i zestawienie zmian. Jest jeden przycisk, którego AI nigdy nie może nacisnąć: MERGE.

Vibe architecting to skok od rozmowy od razu do wykonania. W Cockpicie trzy z czterech kroków należą do człowieka.

Pod spodem pracuje zespół agentów o wdzięcznych imionach. Sherlock zadaje pytania i drąży temat. MacGyver planuje. Gofer zbiera kontekst. Majster koordynuje modele. Doodle rysuje sekwencje. Plumber zajmuje się integracjami. Nitpick sprawdza poprawność.

Wszystko da się prześledzić: od wymagania, przez architekturę, po zadania w Jirze. A po zakończeniu programowania jest jeszcze jeden krok. Piotr klika „validate”, a narzędzie sprawdza, czy gotowy kod zgadza się z modelem architektury i z wymaganiami biznesowymi.

„AI nie zabiera architektowi pracy. Zabiera mu to, co nigdy nie było architekturą”.

Czyli ręczne rysowanie prostokątów i szukanie aktualnej dokumentacji.

Pytania z sali

Kiedy w środowisku analityków i architektów mówi się o C4, odzywają się głosy, że ci, którzy go używają, powinni spłonąć na stosie, bo prawdziwy analityk uznaje tylko BPMN, UML i ewentualnie ArchiMate. Jak przekonać firmę, że C4 ma sens?

Piotr odpowiedział, że najlepiej działa pokazanie. Przeniósł część systemów do C4 i dał ludziom dostęp do LikeC4, darmowego narzędzia, którego używa. Ludzie klikali, schodzili coraz niżej i po chwili widzieli konkretne punkty integracji i ich specyfikacje. To, jak szybko znajdowali to, czego szukali, było według Piotra zdumiewające. I to przekonało ich najlepiej.

Andrzej dodał od siebie, że to jest też graf, po którym może się poruszać AI. Moim zdaniem musimy zmienić myślenie: przez ostatnie 20 lat budowaliśmy repozytoria dla ludzi. Teraz coraz częściej będzie z nich korzystał agent, architekta albo programisty.