Jak pracuję i w jakiej roli wchodzę do firmy.

Zwykle w projekcie tego rodzaju biorą udział trzy różne osoby. Analityk rozmawia z firmą i spisuje, co się dzieje. Architekt decyduje, jak to poskładać. Programista buduje. Między nimi są dwa przekazania i to właśnie tam najczęściej gubi się sens: analityk usłyszał wyjątek, architekt uznał go za detal, a programista dowiedział się o nim po uruchomieniu, od użytkownika.

U mnie te trzy role wykonuje jedna osoba, od 2009 roku. To znaczy, że ta sama głowa, która słucha, jak wygląda Twój poniedziałek rano, ponosi potem konsekwencje tego, co usłyszała — bo sama będzie to budować i sama będzie tłumaczyć, dlaczego coś nie zadziałało. Nazywam to senioralną odpowiedzialnością i to jest cała różnica, którą wnoszę: nie ma etapu, na którym problem staje się cudzy.

Pracuję sam i uczciwie jest powiedzieć, co z tego wynika także po drugiej stronie. Jedna osoba pracuje w jednym tempie i nad ograniczoną liczbą rzeczy naraz. Jeśli Twoja sytuacja wymaga kilku równoległych frontów albo opieki o dowolnej porze doby, potrzebujesz zespołu z obsadą i lepiej, żebyśmy oboje wiedzieli to przed rozmową, a nie w jej trakcie.

Zaczynam od obejrzenia tego, co dzieje się dziś, krok po kroku, z osobą, która to wykonuje. Nie od pytania „czego oczekujecie od systemu”, bo odpowiedź na nie jest zwykle listą życzeń zebranych z całej firmy, a nie opisem rzeczywistości. Pytam, co przychodzi na wejściu, kto to dotyka, gdzie zapada decyzja i co się dzieje, gdy sprawa wygląda nietypowo. Wyjątki są ważniejsze od reguły — to one decydują o tym, ile ta robota naprawdę kosztuje.

Efektem jest rozłożenie procesu na części i wskazanie, które z nich w ogóle warto ruszać. Jeśli chcesz zobaczyć, jak to wygląda w praktyce, zanim się umówimy, napisałem pełną przykładową analizę procesu w sklepie internetowym — cały tok rozumowania, łącznie z miejscami, w których wychodzi, że najtańsze rozwiązanie to nic nie budować.

Ta kolejność ma jeszcze jeden skutek uboczny, który klienci zauważają dopiero później: bardzo często okazuje się, że nie trzeba przepinać całych systemów ani wymieniać programu, tylko poprawić jeden punkt wejścia albo usunąć krok, który powstał kiedyś na czyjąś jednorazową prośbę. To najmniej efektowna część tej pracy i zwykle najbardziej opłacalna.

AI traktuję jak każde inne narzędzie: ma zakres zastosowań, w którym jest bardzo dobre, i zakres, w którym jest kosztownym sposobem na zrobienie czegoś gorzej niż zwykłą regułą. Świetnie radzi sobie tam, gdzie wejście jest nieuporządkowane — w tekście pisanym prozą, w dokumentach o różnych układach. Radzi sobie źle tam, gdzie wynik musi być za każdym razem identyczny i weryfikowalny co do znaku. Rozpisałem to dokładniej w tekście o tym, do jakich zadań AI się w firmie nadaje, a do jakich nie, bez obiecywania procentów oszczędności.

Osobnym tematem są agenci, czyli programy, które same decydują o kolejnych krokach. Brzmi to jak wersja lepsza od zwykłej automatyzacji i czasem nią jest, ale samodzielne decydowanie o krokach bywa też wadą — w procesie, który musi przebiegać zawsze tak samo, swoboda jest ostatnią rzeczą, jakiej potrzebujesz. Kiedy ta granica przebiega gdzie indziej, niż się wydaje, tłumaczę przy okazji tego, czym agent AI różni się od zwykłego chatbota.

Wraca też pytanie o dane: czy korzystanie z AI oznacza wysyłanie dokumentów firmy na cudze serwery. Nie musi. Model może działać na sprzęcie, który stoi u Ciebie, i to jest realna opcja — pokazuje to opisane wdrożenie obiegu dokumentów u operatora logistycznego, gdzie model działa lokalnie. Warto zadać to pytanie na początku, bo odpowiedź zmienia architekturę całego rozwiązania.