Pisałem kilka dni temu o bocie na Discordzie, którego buduję jako wirtualny zespół jednoosobowej firmy. Wtedy bot umiał czytać — przeszukiwać wiki, streszczać commity, raportować, co się dzieje w którym repo. Asystent.
W poniedziałek po południu bot zrobił coś jakościowo innego. Wpisał w bazie drugiego produktu nowy projekt grantowy i przypisał do niego dwie godziny mojej pracy. Bez mojego pośrednictwa. Po prostu komendą na Discordzie napisałem „zaloguj 2h na projekt X” — bot poszedł do drugiego produktu przez API i zapisał wpis.
To brzmi banalnie. Przez sześć miesięcy nie było banalne. To była dokładnie ta linia, której nie chciałem przekraczać do momentu, w którym wszystko po drugiej stronie nie było gotowe.
Co znaczy „czytać” a co „pisać”
Asystent AI, który czyta — może się pomylić, ale jego pomyłka kosztuje najwyżej moją uwagę. Powie mi nieprawdę o stanie projektu, ja sprawdzę i poprawię. Nic w świecie się nie zmieniło, oprócz pięciu minut mojego zmarnowanego czasu.
Asystent, który pisze — może się pomylić w sposób, który zostawia ślad w bazie. Może wpisać wpis w nieprawidłowym kontekście. Może źle przypisać projekt. Może utworzyć coś, czego nie powinno być. W systemie do rozliczania grantów te błędy mają dosłownie konsekwencje finansowe i audytowe.
Dlatego do zeszłego tygodnia bot patrzył przez szybę. Wiedział wszystko, co się dzieje, mówił o tym sensownie, ale nie miał klamki. Klamka pojawiła się 25 maja, gdy zintegrowałem go z drugim produktem przez MCP — to taki mostek, którym AI komunikuje się z konkretnym systemem (w tym wypadku z API drugiego produktu).
Trzy bugi w dwa dni
Pierwsza próba: „bot, pokaż wszystkie projekty grantowe w firmie X”.
Odpowiedź: Connection refused. Okazało się, że konfiguracja domyślna
wskazywała na port bez prefiksu /api. Zwykły literówkowy błąd, ale jak
w wielu pierwszych integracjach — odkryty dopiero, gdy ktoś pierwszy raz
realnie próbuje czegoś dotknąć.
Druga próba: „zaloguj 1h na projekt X”. Odpowiedź: undefined. Bot poszedł
przez API, ale w nagłówku autoryzacji wysłał pole identyfikujące go po
stronie serwera, którego w tym konkretnym endpoincie nie obsłużono. Niby
zaprojektowane, niby przetestowane — tylko że nikt jeszcze nigdy nie
przyszedł do tego endpointu spoza przeglądarki.
Trzecia próba: „pokaż zadania w projekcie X”. Odpowiedź: 403 Forbidden.
Bot ma uprawnienie do czytania projektów, ale brakowało osobnego uprawnienia
do czytania zadań w nich. Drobiazg w konfiguracji, ale do odkrycia tylko
w jeden sposób: spróbować.
Każdy z tych trzech bugów został naprawiony w jednym małym commicie tego samego dnia. Łącznie — kilka godzin pracy nad rzeczą, która w zamiarze miała „po prostu zadziałać”.
Czemu te bugi to dobry znak
Najtrudniejsze błędy w produkcie to nie te, które wybuchają hałaśliwie. To te, które nigdy się nie objawiają, bo nikt nigdy nie próbuje. Endpoint, który teoretycznie obsługuje wszystkie sensowne scenariusze użycia, ale realnie żaden z nich nie został przebiegnięty od początku do końca przez realnego klienta.
Bot wszedł i przeszedł trzy z nich na raz. Każdy bug, który złapał, istniał wcześniej cicho. Bot nie wprowadził ich. Bot odkrył, że tam są. To jest dokładnie ta sama rola, którą w zwykłym zespole pełni junior inżynier dochodzący do projektu — próbuje rzeczy „normalne” i znajduje miejsca, gdzie zespół na co dzień omija problem.
Po dwóch dniach bot ma pełen dostęp do odczytu w drugim produkcie. Pełny zapis przyjdzie z czasem i nie cały naraz.
Bramki, które musiały być pierwsze
Powód, dla którego teraz a nie pół roku temu: trzeba było najpierw zbudować w drugim produkcie dwie rzeczy, których nie da się dorobić po fakcie.
Pierwszą jest audit log — niezmienny zapis każdej operacji wykonanej przez kogokolwiek na danych finansowych. Bez tego nie wiadomo, kto co zmienił i kiedy. Z botem to jest podwójnie ważne — bo nikt nie pamięta, co powiedział botowi w środę o trzeciej po południu. Audit log to jedyna warstwa, na której można odpowiedzialnie powiedzieć „to była komenda bota, nie moja ręka”.
Drugą jest rozróżnienie tożsamości człowieka od tożsamości bota. To brzmi banalnie, ale wbrew pozorom system, w którym bot ma „te same uprawnienia co founder”, jest bardzo łatwo zbudować — a potem trudno nadrobić, gdy pojawia się drugi człowiek albo drugi bot. W drugim produkcie od kilku tygodni istnieje osobna klasa ServicePrincipal — bot ma swoje konto, swoje uprawnienia, swój zapis w audit logu. Niezależnie ode mnie.
Co to znaczy „mieć zespół”
Próbowałem tę zmianę opisać przez tydzień i ciągle wracała mi jedna myśl. Linia, na której „AI” staje się „członkiem zespołu”, nie przebiega tam, gdzie pisze ładnym językiem. Nie przebiega też tam, gdzie ma swoją personę, ton, sposób mówienia. Przebiega tam, gdzie jego decyzja zostawia ślad w bazie.
Bot, który tylko odpowiada na pytania, jest mądrym asystentem. Bot, który w mojej nieobecności wpisuje na fakturę grantową dwie godziny mojej pracy i poprawnie ją kataloguje — jest kimś, kto coś zrobił. Nie ja. On.
Dla jednoosobowej firmy to jest jedna z większych zmian, jakie się dzieją w 2026 roku. Pierwsza godzina, która została mi zwrócona przez to, że nie musiałem ręcznie kliknąć w drugim produkcie „dodaj wpis”, jest dokładnie tym, co mi pozwoli zachować energię na rzeczy, których nie da się zautomatyzować — rozmowę z prawdziwym sąsiadem, który po raz pierwszy otwiera aplikację i się zastanawia, czy to wszystko nie jest jakąś ściemą.