Zanim dodam AI, chcę zobaczyć workflow

Ludzie pokochali ChatGPT i trudno się dziwić. Pierwszy raz można wrzucić bałagan w okno rozmowy i dostać odpowiedź, plan, analizę albo gotowy tekst. Po takim doświadczeniu bardzo łatwo zrobić kolejny krok w głowie: skoro AI umie tak dobrze odpowiadać, to może oddajmy mu więcej. Niech myśli za nas, przejmie proces i podejmie decyzję.

Ja też rozumiem tę pokusę. Przy tworzeniu własnych aplikacji i wdrożeniach coraz częściej łapię się jednak na tym, że zanim zacznę wyobrażać sobie model, który sam przechodzi cały proces od A do Z, muszę zrobić krok wstecz i zapytać: jak ta praca wygląda, zanim dotknie jej automatyzacja?

Nie chodzi o wersję z prezentacji, gdzie proces jest narysowany na diagramie i wszystko przechodzi gładko z jednego prostokąta do drugiego. Chodzi o prawdziwy workflow: kto dostaje pierwszy dokument, kto go poprawia, gdzie pojawia się mail z dopiskiem "to jeszcze trzeba sprawdzić", który arkusz jest źródłem prawdy, chociaż wszyscy udają, że nim nie jest, kto podejmuje decyzję, a kto tylko przygotowuje materiał dla kogoś innego.

Dopiero wtedy da się sensownie zapytać, czy AI w ogóle powinno tam wejść. I dopiero wtedy zaczyna się dla mnie najciekawsza część tej nauki, bo coraz mocniej widzę, że umiejętność, której próbuję się nauczyć, nie polega po prostu na "używaniu AI". Bardziej chodzi o zrozumienie pracy na tyle dobrze, żeby wybrać najmniejszą bezpieczną interwencję.

Najmniejsza bezpieczna interwencja

To sformułowanie coraz częściej wraca mi w głowie, bo dobrze hamuje odruch budowania najbardziej efektownej wersji. Jeśli proces ma stabilne reguły i stabilne dane wejściowe, zwykłe oprogramowanie często będzie lepsze niż agent. Jest tańsze, prostsze do debugowania, bardziej przewidywalne i zwykle mniej teatralne.

Jeśli dane są messy, ludzie pracują na dokumentach, mailach, arkuszach i języku naturalnym, a system po drodze musi użyć kilku narzędzi, agent zaczyna mieć więcej sensu. Jeśli w procesie pojawia się odpowiedzialność, ryzyko prawne, gust, interpretacja albo domenowa ocena, człowiek prawdopodobnie powinien zostać w pętli, nawet jeśli system potrafi zrobić przekonujące demo.

To jest mniej ekscytujące niż zdanie, że wdrażamy agentów AI w firmie. Ale im więcej pracuję z takimi systemami, tym bardziej ufam tym spokojniejszym rozróżnieniom. One chronią przed sytuacją, w której technologia staje się odpowiedzią, zanim ktokolwiek dobrze zrozumiał pytanie.

Dobrym zwykłym przykładem jest tygodniowy raport projektu. Jeśli te same osoby co tydzień wypełniają te same pola, z tymi samymi statusami i w tym samym rytmie, autonomiczny agent prawdopodobnie nie jest najlepszym punktem startu. Formularz, walidacja, uprawnienia, przypomnienia i mały skrypt mogą rozwiązać problem lepiej.

Ta lekcja jest dla mnie ważna, bo naturalnie pociąga mnie ciekawsze narzędzie. Agent jest ciekawszy do zbudowania niż formularz. Ale dobry system nie musi być interesujący dla osoby, która go buduje. Musi pasować do pracy, którą ma wspierać.

Z natury staram się być ostrożny

Moim domyślnym punktem odniesienia nadal jest architektura, bo stamtąd wychodzę i tak nauczyłem się myśleć o wielu złożonych problemach. Wyobraźmy sobie inwestora, który pyta, co da się zbudować na konkretnej działce. Na poziomie demo brzmi to jak idealny problem dla AI. Prezentacja NVIDIA pokazała, jak taka przyszłość może wyglądać w idealnym świecie: człowiek wskazuje działkę, przekazuje szkice, moodboard i intencję projektową, a agent przechodzi przez kolejne narzędzia projektowe.

Wrzucamy miejscowy plan, warunki zabudowy, parametry działki i kilka życzeń inwestora. System odpowiada możliwą powierzchnią, wysokością, liczbą kondygnacji, wymaganiami parkingowymi i powierzchnią biologicznie czynną. Jako demo wyglądałoby to czysto i użytecznie.

Tylko że prawdziwa praca architekta nie wygląda jak formularz z jedną ostateczną odpowiedzią. Masz język planu miejscowego, który w jednym paragrafie jest bardzo precyzyjny, a w innym zostawia dziwnie dużo miejsca na interpretację. Masz odległości od granic, dojazd, parkingi, geometrię dachu, intensywność zabudowy, funkcje usługowe, wyjątki, lokalne interpretacje i czasem rozmowę z kimś, kto wie, jak takie rzeczy przechodzą w danej gminie.

AI może w takiej sytuacji bardzo pomóc. Może szybciej przeczytać dokumenty, wyciągnąć ograniczenia, zacytować paragrafy, zbudować checklistę ryzyk i pokazać, gdzie ambicja inwestora zderza się z zapisami planu. Może przygotować architektowi lepszy materiał do decyzji.

Ale nie powinno udawać architekta z pieczątką. Odpowiedzialność nie znika tylko dlatego, że odpowiedź wygenerował model. Ktoś podpisuje projekt, ktoś odpowiada za interpretację i ktoś bierze na siebie ryzyko, że decyzja była sensowna.

To jest dla mnie ciekawsze niż samo demo. Dobrze ustawiony system nie musi podejmować ostatecznej decyzji. Może zmniejszyć tarcie, złapać przeoczone rzeczy i pokazać człowiekowi, gdzie trzeba się zatrzymać i pomyśleć.

Agent nie jest nagrodą za złożoność

Przez chwilę miałem odruch, że jeśli proces jest skomplikowany, to pewnie potrzebuje agenta. Teraz wierzę w to coraz mniej, bo skomplikowany proces często potrzebuje porządku zanim zacznie potrzebować autonomii. Może potrzebuje jednego źródła prawdy, lepszych statusów, prostszego formularza, mądrzejszej walidacji albo jasnej odpowiedzi na pytanie, kto za co odpowiada.

To wraca, kiedy myślę o systemach wiedzy i asystentach. Na papierze pomysł brzmi prosto: mamy dokumenty, procedury i użytkowników zadających pytania, więc budujemy asystenta, który odpowiada. RAG, interfejs czatu, może kilka narzędzi i wygląda na gotowe.

W praktyce niewygodne pytania pojawiają się bardzo szybko. Która procedura jest aktualna? Kto ją zatwierdził? Czy użytkownik ma dostać gotową odpowiedź, czy tylko sugestię? Co jeśli system odpowie pewnie, ale na podstawie starego dokumentu? Gdzie ma się zatrzymać i powiedzieć, że człowiek musi podjąć decyzję?

To nie są pytania o to, czy model "da radę". To są pytania o workflow, odpowiedzialność i źródła prawdy. Agent zaczyna mieć sens dopiero wtedy, kiedy rozumiem, co może zrobić sam, co może zasugerować, a czego nie wolno mu dotknąć.

W obrazie też trzeba wiedzieć, czego nie ruszać

Podobną lekcję widzę w pracy z wizualizacjami architektonicznymi. Z zewnątrz łatwo opisać ten proces prosto: bierzesz stary render, wrzucasz go do systemu i dostajesz coś bardziej atrakcyjnego, bardziej sprzedażowego i bardziej dopracowanego. Ta historia nie jest fałszywa, ale ukrywa najtrudniejszą część.

W praktyce najważniejsze nie jest tylko powiedzieć systemowi, co ma poprawić. Najważniejsze jest powiedzieć mu, czego nie wolno ruszyć. Bryła budynku ma zostać, materiały nie mogą losowo zmienić charakteru projektu, a podziały elewacji nadal muszą mieć architektoniczny sens.

Zieleń może być lepsza, światło może być lepsze i atmosfera może być bardziej dopracowana. Ale intencja architektoniczna nie może się rozpaść tylko dlatego, że system uznał, że "lepiej" znaczy "bardziej luksusowo". W tym miejscu praca przestaje być naciskaniem przycisku, a zaczyna być oceną.

To jest różnica między automatyzacją a odpowiedzialną interwencją. Jeśli słaba wizualizacja ma pomóc sprzedać projekt, AI może być mocnym narzędziem, ale nie jako magiczna maszyna do estetyki. Lepiej działa jako część procesu, w którym ktoś rozumie projekt, pilnuje masek, porównuje wersje i zauważa, kiedy atrakcyjny wynik zaczyna fałszować obiekt.

W pracy z AI "lepsze" nie zawsze znaczy bardziej efektowne. Czasem lepsze znaczy bardziej wierne temu, co już było dobre. Ta mała różnica jest dla mnie ważna, bo dojrzałe użycie AI często polega na ograniczaniu systemu, a nie na proszeniu go o więcej.

Uczę się rozumieć pracę

Kiedy patrzę na to z perspektywy osoby konsultującej wdrożenia i pracującej blisko realnych procesów, coraz bardziej rozumiem, że taka rola nie polega na zrobieniu najbardziej imponującego demo w pokoju. Jest bliżej wejścia w cudzy bałagan i zbudowania czegoś, co przeżyje kontakt z prawdziwą pracą. To jest dużo trudniejsze, niż brzmi.

Dokumenty są niepełne. Ludzie mają swoje obejścia. Systemy są stare. Decyzje nie zawsze są zapisane. Ktoś używa Excela, bo tak jest szybciej, a ktoś inny trzyma ważną wiedzę w głowie, bo nikt nigdy nie zamienił jej w system.

Dla mnie właśnie w tym miejscu zaczyna się prawdziwe wdrażanie AI. Nie od wyobrażenia sobie agenta, który zrobi wszystko naraz, tylko od zrozumienia, co właściwie próbujemy usprawnić, kto ponosi odpowiedzialność, gdzie błędy są tanie, a gdzie mogą zaboleć. Warstwa techniczna ma znaczenie, ale nie powinna przychodzić przed zrozumieniem pracy.

Gdybym dzisiaj pomagał firmie wdrożyć AI w wewnętrznym procesie, nie zacząłbym od listy narzędzi. Poprosiłbym o pokazanie pracy: dokumentów, maili, arkuszy, decyzji, akceptacji, wyjątków, rzeczy, które zwykle działają, ale raz na tydzień się psują, oraz miejsc, w których ludzie ręcznie przepisują informacje z jednego systemu do drugiego.

Dopiero po tym można zdecydować, czy właściwą interwencją jest agent, asystent, klasyczna aplikacja, integracja, checklista albo lepiej opisany proces. To jest mniej spektakularne niż hasło "budujemy agentów", ale wydaje mi się dużo bardziej uczciwe. Jest też bliższe typowi buildera, którym chcę się stać.

Gdzie system powinien się zatrzymać?

Nadal buduję ten mięsień. Nadal zdarza mi się ekscytować narzędziem wcześniej niż w pełni zrozumiem problem, bo pierwszy moment, w którym agent sam wykonuje kilka kroków, naprawdę potrafi wyglądać jak magia. Nie chcę udawać, że jestem ponad tym uczuciem.

Ale coraz częściej po tej pierwszej ekscytacji wracam do prostszego pytania. Nie tylko: co ten system może zrobić? Raczej: gdzie ten system powinien się zatrzymać, żeby człowiek nadal miał kontrolę, odpowiedzialność i zaufanie do wyniku?

To pytanie wydaje mi się coraz ważniejsze z każdym projektem. Jeśli AI ma wejść do prawdziwej pracy, nie wystarczy, że będzie szybkie i efektowne. Musi siedzieć w procesie, który ktoś rozumie, potrafi ocenić i potrafi zatrzymać w odpowiednim momencie.

I chyba tego uczę się teraz najbardziej. Nie tylko tego, jak używać AI, ale jak rozumieć pracę na tyle dobrze, żeby wiedzieć, kiedy AI pomaga, kiedy przeszkadza, a kiedy nudny kawałek zwykłego software'u jest lepszym wyborem.