Co potrafimy zrobić: pięć projektów i pięć zasad

Kiedy ktoś odzywa się do mnie w sprawie nowego zlecenia, nie zaczynam od tego, czym się chwalimy. Zaczynam od tego, co realnie zbudowałem i co z tego wynika dla niego. Tutaj jest pięć projektów. Każdy pokazuje inną umiejętność i z każdego wynika jedna zasada, według której pracuję dalej.

Enterprise wydajność: wąskie gardło nie jest tam, gdzie się po nie sięga w pierwszej kolejności

W ČSOB pracowałem przy generowaniu umów. Zajmowało to dwie godziny. Po mojej pracy zajmuje trzy minuty. To czterdziestokrotne przyspieszenie i nie powstało przez przepisanie na nowszy framework ani przez dodanie serwerów.

Podobna historia jest z Atlas Copco. Pipeline danych SAP napisany jako jeden skrypt SQL o piętnastu tysiącach wierszy. Po refaktorze trzy tysiące wierszy, czyli o osiemdziesiąt procent mniej, i przeniesienie na event-driven na Azure Functions. Runtime z kilku dni wrócił do około czterech godzin z Europy i sześciu z Azji. Globalnie wdrożone loadery SAP do hurtowni danych, które wcześniej goniły same siebie.

Zasada jest w obu przypadkach taka sama. Najpierw znaleźć rzeczywiste wąskie gardło, nie to pierwsze, które widać. Zazwyczaj to nie są „wolne serwery", ale struktury danych, brakujący caching, SQL napisany wbrew temu, jak działa baza danych, albo synchroniczny krok, który powinien być zdarzeniem. Gdy trafia się w odpowiednie miejsce, liczba nie poprawia się o procenty, ale o rzędy wielkości. Gdy nie — kupuje się większą maszynę i problem zostaje.

Solidna integracja pod obciążeniem: państwo nie wybacza fire-and-forget

TrafinOil potrzebował wysyłać faktury do KSeF, czyli do polskiego państwowego systemu e-fakturowania. Taki system jest asynchroniczny, limitowany, czasem niedostępny i ma własny stan. To nie jest endpoint, do którego wysyła się request i zakłada, że przeszło. To długotrwały stanowy workflow.

Zbudowałem go jako durable pipeline. Idempotentny submit, żeby powtórzenie nie zduplikowało dokumentu. Retry z exponential backoff, gdy system jest przeciążony. Rate limiting, żeby państwo nas nie odcięło. Reconciliation, która cyklicznie sprawdza, czy rzeczywistość się zgadza. Potwierdzenie UPO jako dowód dostarczenia i audit log przy każdym przejściu stanu. Zweryfikowane na produkcji na ponad czterdziestu tysiącach dokumentów, sto procent dostarczonych. Do tego migracja danych na Dynamics 365 Business Central.

Że tak to musi wyglądać, mam potwierdzone dość boleśnie. Poprzedni pipeline był fire-and-forget i po cichu tracił dokumenty. Forensicznie odtworzyłem piętnaście tysięcy sto czterdzieści jeden brakujących dokumentów, o których nikt nie wiedział, że brakuje. To jest ta różnica. Fire-and-forget wygląda w demo dokładnie tak samo jak durable workflow. Różnią się dopiero wtedy, gdy państwo nie odpowiada — i w tym momencie albo masz audit log i reconciliation, albo szukasz piętnastu tysięcy faktur wstecz.

Nawiasem mówiąc, wydajność i solidność nie są ze sobą sprzeczne. Nocny dataloader w tym samym projekcie skróciłem z dwudziestu godzin do trzydziestu minut. Solidność nie oznacza wolności.

Zasada: przy zewnętrznym systemie, który jest asynchroniczny, limitowany i ma własny stan, od razu planuję pełną maszynerię, nie incident po incidentie. Durable stan, idempotencja, reconciliation, obserwowalność każdego przejścia. Nie dlatego, że to eleganckie, ale dlatego że tańsza wersja zapłaci się później i drożej.

Kompletny produkt od zera: cztery miesiące, nie cztery lata

Carivio, czyli TaxiLight, to kompletna platforma do dyspozycji taksówek. Trzy platformy — backend, web i mobile. Jako SolutionBox dostarczyliśmy to w cztery miesiące i działa. Około pięćdziesięciu żywych samochodów jeździ w ruchu, można to zobaczyć na transportprague.com.

Kilka liczb, żeby było jasne, co oznacza „kompletny". Backend około stu dwudziestu ośmiu tysięcy linii kodu. Czterdzieści osiem modułów feature. Sto siedem migracji EF. Sześć ról. Cztery endpointy SignalR hub do real-time. Aukcyjny model przejazdów, gdzie oferta rozsyłana jest do kierowców przez SignalR, zapytania geoprzestrzenne na GPS, background-location na mobile, który musi przeżyć realne telefony Samsung, OnePlus, Huawei i ich agresywne zabijanie aplikacji w tle. Do tego offline queue i recovery, gdy system zabije aplikację.

Zasada tutaj nie brzmi „potrafimy szybko". Zasada jest taka, że kompletny produkt od zera ma mnóstwo rzeczy, których nie widać w demo, a które decydują o tym, czy to w ruchu wytrzyma. Background location na realnych telefonach OEM, recovery po zabiciu aplikacji, real-time, który nie zalewa sieci zduplikowanymi eventami. Tego nie da się zrobić „potem". Albo to należy do projektu od początku, albo aplikacja zachowuje się jak zepsuta i nikt nie wie dlaczego.

AI wewnątrz realnych systemów: najpierw podstawa, potem model

A teraz AI, bo to jest dzisiaj pytanie numer jeden. Od razu powiem jedną rzecz wprost: nie jestem badaczem ML. Nie robię fine-tuningu ani MLOps i nie trenuję modeli. Robię aplikacyjne i integracyjne AI wewnątrz systemów produkcyjnych. To inna dyscyplina i dobrze to powiedzieć z góry.

Dla miasta Zlín zbudowaliśmy z Continerem chatbot RAG dla mieszkańców z dokładnością około dziewięćdziesięciu procent na żywych danych. Pod spodem jest silnik multi-agentowy z hybrydowym retrievalem, który łączy wyszukiwanie w dokumentach z zapytaniami nad strukturalnymi danymi miejskimi i sam się poprawia, gdy zapytanie zawodzi. Wygrało to regionalny hackathon, Innovation Day.

Ta logika ciągnie się przez pozostałe rzeczy, które robimy. Agent AI do ekstrakcji danych z faktur, który czyta dokumenty i zapisuje je do istniejącego ERP, ale z human-in-the-loop i audit logiem, nie jako czarna skrzynka. Własna produkcyjna usługa code-review AI, która komentuje pull requesty z deduplikacją i kontekstem brancha. Automatyzacja e-maili i zamówień publicznych, gdzie ekstrakcja encji przez embeddings i RAG szuka relewantnych okazji. Z Continera pochodzi też Artima.ai — narzędzie all-in-one do marketingu w social mediach, które generuje zdjęcia i wideo przez AI i planuje publikację — albo HDTS, system computer vision, który z wideo rozpoznaje kąty łyżwiarskie i koachuje hokeistę w czasie rzeczywistym.

Zasada: najpierw buduję czystą, gotową na produkcję podstawę, a dopiero na niej umieszczam LLM lub RAG. Większość zespołów robi to odwrotnie — wypuszcza PoC bez podstaw i potem rok go dogania. Ja idę od podstaw w górę, bo wywołanie LLM bez cost-trackingu, guardrailów i obserwowalności jest w systemie enterprise zobowiązaniem, nie feature'em. Audit tokenów, budget gate, guardrails przeciwko prompt injection i halucynacjom, log przy każdym wywołaniu. To jest to, co odróżnia demo AI od AI w produkcji.

AI wewnątrz systemu fintech: model, który handluje własnym stanem

Piąty projekt idzie o krok dalej. Robootec, który buduję z Continerem jako architekt, to algorytmiczna platforma handlowa AI. To nie jest chatbot, do którego coś piszesz i on ci odpowiada. To system, który pobiera dane, ocenia je i handluje — każda decyzja ma konsekwencje i własny stan, który musi gdzieś żyć.

Wejściem nie są tylko ceny. Łączy AI news-sentiment — czytanie wiadomości przez model — dane makro i wskaźniki techniczne, i na tej podstawie generuje sygnały. Stack to .NET 10 na backendzie i Next.js na frontendzie, CQRS wewnątrz, multi-provider orchestracja LLM, real-time przez SignalR i SSE oraz obserwowalność przez OpenTelemetry.

Kilka rzeczy warto wyróżnić, bo to ta nudniejsza, ale decydująca część AI w produkcji. Multi-provider orchestracja LLM z prompt cachingiem, żebym nie był zależny od jednego dostawcy. Lokalna inferencja sentymentu, więc oblicza się u nas i nie każde wywołanie idzie na zewnątrz. Budget gate przed każdym requestem, który pilnuje, ile tokenów i pieniędzy idzie do modelu, zanim zostanie wysłany. I bezstanowy silnik sygnałów, gdzie dodanie nowej strategii nie psuje istniejących.

Gdzie to teraz jest, powiem wprost. PoC działa na żywo. Autonomiczne AI, które nazywamy „vibe trading" — żeby system handlował sam — jest w trakcie tworzenia, nie gotowe. Buduję to z tego samego powodu co wszystko inne: przy systemie, który sięga po pieniądze, cost-tracking, durable stan i obserwowalność to warunek, nie nadbudowa.

Zasada: AI ma sens, gdy jest zintegrowane w realny system z danymi i stanem, nie jako izolowany chatbot obok. Dopiero gdy model czyta żywe dane, coś z nimi robi i ta decyzja ma konsekwencję, którą trzeba prześledzić i zapłacić, okazuje się, czy masz wokół niego zbudowany system, czy tylko demo. Dlatego w Robootec rozwiązuję cost gate i stanowy silnik wcześniej niż autonomiczny handel.

Tę samą logikę stosujemy też wewnętrznie. ModularPlatform to nasza modularna podstawa dla aplikacji read-heavy, nadal w trakcie tworzenia. .NET modularny monolit z granicami architektonicznymi wymuszonymi mechanicznie przez ArchUnitNET, durable messaging przez Wolverine z outboxem, inboxem i sagami, Postgres row-level security do izolacji tenantów, crypto-shred usuwanie dla GDPR, Stripe do płatności i Next.js 15 z React 19 na frontendzie. Istnieje po to, żebyśmy nie zaczynali każdego produktu od zera i mieli sprawdzoną podstawę zamiast wielokrotnie budować tę samą infrastrukturę. Kod źródłowy pozostaje u klienta, żadnego vendor lock-in.

Jak tak myślimy o nowym zleceniu

Te pięć projektów ma wspólny wzorzec. Najpierw pytam, gdzie jest rzeczywisty problem, nie gdzie boli najbardziej na pierwszy rzut oka. Potem decyduję, ile solidności zlecenie naprawdę potrzebuje, bo durable workflow i fire-and-forget różnią się dopiero pod obciążeniem, nie w demo. Potem buduję podstawę tak, żeby wytrzymała w ruchu, łącznie z rzeczami, których nie widać w demo. I dopiero na końcu, gdy ma to sens, dodaję AI — z cost-trackingiem i obserowalnością od początku, niezależnie od tego, czy chodzi o chatbota nad danymi miejskimi, czy o model, który handluje własnym stanem.

Dlatego gdy pojawia się nowe zlecenie, nie obiecuję frameworku ani buzzwordu. Pytam, co realnie się liczy, co trzeba zaadresować zanim to trafi do produkcji, i gdzie jest ta jedna zmiana, która przesunie liczbę o rząd wielkości zamiast o procenty. To jest praca, za którą się nie wstydzę.