--- title: "Komunikat jest na dziś: czego jazda poza trasą uczy o wdrażaniu AI na produkcję" url: "https://simonebova.com/pl/writing/cosa-insegna-il-fuoripista" lang: "pl" updated: "2026-11-04" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/cosa-insegna-il-fuoripista" en: "https://simonebova.com/md/en/writing/cosa-insegna-il-fuoripista" pl: "https://simonebova.com/md/pl/writing/cosa-insegna-il-fuoripista" --- # Komunikat jest na dziś: czego jazda poza trasą uczy o wdrażaniu AI na produkcję 2026-11-04 · Fuoripista Kontrola mówi coś o konkretnym momencie, potem wygasa. Lekcje z agenta WhatsApp i naszego company brain o tym, kiedy dowód przestaje się liczyć. Komunikat lawinowy opisuje obszar na jeden dzień, na określonych wysokościach i wystawach stoków. Kto jeździ poza trasą, czyta go jak informację z terminem ważności. To, że stok był stabilny wczoraj, niewiele mówi o dzisiaj. Jeżdżę na nartach. To porównanie pomaga mi wyjaśnić błąd, który często widzę w systemach AI na produkcji. Ma swoje granice: eval nie ma ani zakresu, ani autorytetu, ani stawki komunikatu lawinowego. Historie poniżej są za to prawdziwe i pochodzą z moich projektów. Teza: check ustala coś o konkretnym stanie. W oprogramowaniu zaliczony test, udana weryfikacja czy zielony health check łatwo zamieniają się w trwałe prawdy. Praca na produkcji polega na ustaleniu, kiedy taki dowód wygasa, jak zauważyć zmianę stanu i co dzieje się potem. ## Zaliczony check traci ważność, gdy zmieniają się warunki, które go uzasadniały. Dla CVing, firmy HR tech z Mediolanu, zbudowałem agenta WhatsApp, który pozwala aplikować na ofertę pracy w rozmowie. Przy wrażliwych akcjach kandydat potwierdza email kodem. Na produkcji jeden kandydat utknął. Kod wygasł w trakcie rozmowy, a system, który nim zarządza, odrzucał go. Agent nadal pamiętał „zweryfikowano” i nie prosił o nowy kod. Ciągle kazał sprawdzać skrzynkę. Żaden email nie wychodził. Każda część poprawnie raportowała to, co wiedziała. Razem uwięziły człowieka. Ustaliłem, że zapamiętana weryfikacja ma termin ważności. Gdy system rozstrzygający mówi „nie”, lokalna pamięć jest od razu kasowana. Weryfikację wykorzystujemy w tym samym kroku co akcję, którą chroni, żeby nie leżała i się nie starzała. Jedna reguła była zapisana w instrukcjach modelu: rozpoznawanie kodu po jego formie. Stała się checkiem w kodzie. To, co musi obowiązywać zawsze, zapisz tam, gdzie model nie może tego interpretować. ## Zanim zrobisz retry, sprawdź, co mogło już się wydarzyć. W tej samej analizie przejrzałem każdy zapis. Pytałem, co system nadrzędny gwarantuje, gdy zawiedzie. Jeśli nie udaje się poprosić o nowy kod, zatrzymaj się i zrób retry. Jeśli zawodzi zapis już udanej weryfikacji, pozostaje ona ważna, a problem trafia do audit logu z uczciwym opisem. Jeśli baza nie odpowiada, retry. Jeśli odpowiada, że nic tam nie ma, to jest odpowiedź. Bez retry. „Retry on error” zgniata trzy różne sytuacje w jedną: nic się nie wydarzyło, wydarzyło się wszystko, nie wiadomo. Przypisz każdej operacji jedną z tych etykiet. Gdy jest niepewność, zachowaj ją w stanie i w audycie. ## Rozmowa uporządkowana dla człowieka może dotrzeć do serwera w nieporządku. Kandydat prowadzi jedną rozmowę. Serwer dostaje wiadomości pojedynczo, ale może obsługiwać dwie naraz. Dwie wiadomości wysłane szybko z tego samego numeru walczyły więc o te same dane. Ustawiłem wiadomości jednej osoby w kolejce. Pozostali kandydaci na nikogo nie czekają. Była też druga, mniej oczywista część. Gdy kilka szybkich wiadomości łączymy w jedną turę, model mógł zobaczyć je jako jeden tekst i zgubić informację, co było w której wiadomości. Teraz każda trafia do modelu ze swoją pozycją i czasem. Znajdź rzecz, której stan musi zmieniać się po kolei. Tam ustaw pracę w kolejce. Gdy łączysz dane z kilku wejść, zachowaj granice między nimi. ## Nowa reguła musi obejmować także stare dane. W tym samym agencie nazwy przesłanych plików CV trafiają do modelu. Trzeba je więc traktować jako niezaufany tekst. Dodałem filtr na wejściu i wyraźnie oddzieliłem nazwę od reszty instrukcji. Potem zastosowałem ten sam filtr do już zapisanych nazw, przy każdym ponownym odczycie. O ostatnim kroku łatwo zapomnieć. Dane zapisane przed regułą nadal istnieją. Poprawienie wejścia ich nie dotyka. Przy każdej nowej regule sprawdź, gdzie odczytujesz stare dane. Zdecyduj, czy je migrować, sprawdzić ponownie, odizolować czy odrzucić. ## Udany pierwszy krok nie dowodzi, że drugi się odbył. W company brain Yempik zatwierdzanie wpisu działało. Kolejny krok, który pozwala go znaleźć, zawodził po cichu. Wyszukiwanie zwracało pustkę bez błędu. Sukces pierwszego kroku udawał dowód wykonania drugiego. Dodaliśmy check, który stale porównuje wpisy zatwierdzone z możliwymi do znalezienia. Wyszukiwanie mówi, kiedy ma zaległości. Test przechodzi całą drogę od zapisu do wyszukania. Jedna z reguł, według których pracuję, mówi właśnie o tym: każdy skrót ma ścieżkę naprawy. Zapisz trwale, co ma się wydarzyć. Niech coś stale sprawdza, czy się wydarzyło. ## Testuj ze środowiska, które będzie wykonywać pracę. Jedna z rutyn sprzedażowych Yempik opierała się na plikach z mojego laptopa. W lokalnej sesji te pliki są. Zaplanowane uruchomienia w chmurze ich nie widzą. Każdy test z niewłaściwej sesji zwiększał pewność, nie dotykając słabego punktu. Klasyczne „u mnie działa”. Teraz każda automatyzacja określa, co czyta, co zapisuje i gdzie. Test działa z uprawnieniami i w środowisku tego, kto będzie wykonywał pracę. Tak samo jest z health checkami. Odpowiadająca strona główna mówi, że strona główna odpowiada. Jeśli praca użytkownika przechodzi przez bazę albo zewnętrznego dostawcę, health check musi przejść tę drogę. Usługa, która nie może wykonać swojej pracy, powinna przestać zgłaszać, że jest dostępna. ## Najwygodniejszy kontrargument: następny model usunie te problemy. Modele naprawdę się poprawiają. Ale spójrz na listę: weryfikacja pamiętana zbyt długo, puste wyszukiwanie, dwie ścigające się wiadomości, stare dane nigdy niesprawdzone ponownie, uruchomienie w chmurze bez właściwych plików. Spoiler: żadna z tych rzeczy nie zależy od inteligencji modelu. Lepszy model grzeczniej poprosiłby kandydata o sprawdzenie skrzynki. Ważne pytania leżą poza modelem: kiedy wygasa dowód, kto zauważa niedokończoną pracę, kto ją wykonuje i z jakimi uprawnieniami. ## Od poniedziałku - Nadaj każdemu ważnemu checkowi scope i czas ważności. Gdy system rozstrzygający mówi „nie”, zapomnij „tak” zapisane w pamięci. - Wykorzystuj weryfikację w tym samym kroku co akcję, którą chroni. - Przenieś do kodu reguły, które muszą obowiązywać zawsze. - Zanim zrobisz retry operacji, ustal, czy mogła już się wydarzyć. - Ustaw pracę w kolejce dla osoby lub rzeczy, której stan musi zmieniać się po kolei. Zachowuj granice, gdy łączysz wiadomości. - Przy każdej nowej regule sprawdź też miejsca, w których odczytujesz stare dane. - Zapisz trwale, co ma się wydarzyć, i stale sprawdzaj, czy się wydarzyło. - Uruchamiaj testy z tożsamością, uprawnieniami i w środowisku, które naprawdę wykona pracę. [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)