---
title: "deploy to prod. make no mistakes. Błędy, których deploy nie widzi"
url: "https://simonebova.com/pl/writing/deploy-to-prod-make-no-mistakes"
lang: "pl"
updated: "2026-09-04"
author: Simone Bova
alternates:
  it: "https://simonebova.com/md/it/writing/deploy-to-prod-make-no-mistakes"
  en: "https://simonebova.com/md/en/writing/deploy-to-prod-make-no-mistakes"
  pl: "https://simonebova.com/md/pl/writing/deploy-to-prod-make-no-mistakes"
---

# deploy to prod. make no mistakes. Błędy, których deploy nie widzi

2026-09-04 · Notatki z terenu

Company Brain od Yempik działał na produkcji, a wyszukiwanie zwracało pustkę. Czego naprawdę wymaga „make no mistakes”: pełnych ścieżek, długich sesji i zgód, które coś znaczą.

„deploy to prod. make no mistakes.” to prompt, który napisałem do Claude pewnego wieczoru pod koniec lipca z [Italian Founders House](https://www.linkedin.com/company/italian-founders-house/), na kampusie H-FARM. Obok mój twin [Raffaele](https://www.linkedin.com/in/raffaele-zarrelli/) promptował jak szalony. To był tydzień premiery Company Brain od Yempik: company brain z zasadami kontroli, który ludzie i agenci czytają i uzupełniają ze swoich asystentów AI.

Deploy był łatwą częścią. Prawdziwych błędów żaden deploy nie widział. Znalazło je realne użycie i testy na właściwych granicach. Prawie wszystkie miały ten sam kształt: każda część działała, a cała ścieżka nie.

## Zatwierdzone dane mogą istnieć i nadal być niewidoczne

W pierwszych dniach agent pracował z Brain przez cały prawdziwy dzień: propozycje, poprawki, odczyty między sesjami. Zatwierdzanie działało. Wyszukiwanie nie. Naturalne pytania, które powinny znaleźć świeżo zatwierdzoną wiedzę, zwracały pustkę. Dane były. Krok, który pozwala wyszukać zatwierdzone dane, zawodził bez śladu. W logach nie było ani jednego błędu.

Zapis się udał, zatwierdzenie się udało, dane zachowane: wyglądało to na pełny przepływ. Wykryłby to jeden test, który przechodzi całą drogę tak jak użytkownik: utwórz, zatwierdź, wyszukaj, znajdź. Odzyskanie pominiętych danych zamykało incydent, ale zostawiało założenie, które go wywołało: że każdy krok w tle zawsze dociera do celu. Dlatego tego samego dnia dodałem okresowy check, który sam naprawia zaległości. Produkt zaczął rozróżniać „nic nie ma” od „jeszcze nadrabiam”. Dodałem też ten test end to end na prawdziwym środowisku.

Te same pytania, zadane ponownie z tego samego asystenta, znalazły poprawną odpowiedź na pierwszym miejscu. Kilka dni później zbudowaliśmy review repo GitHub według tego samego schematu od początku: każde zdarzenie zapisane przed przetworzeniem i uzgadnianie stanu dla tych, które się zgubią.

## Funkcji naprawdę brakuje, jeśli najczęściej używane wejście nie może dać jej danych

Niedługo potem ten sam błąd wrócił w innej formie. Brain umiał łączyć wiedzę z osobami, firmami i projektami. Graf istniał od dawna, był zapisany i można było po nim przechodzić. Ale narzędzie, przez które asystenci proponowali wiedzę, nie pozwalało podać tych powiązań. Wszystko, co wchodziło tą drogą, powstawało więc bez nich. Każdą część sprawdzono osobno. Nikt nie prześledził prawdziwego obiektu od wejścia do funkcji, która go używała.

Tak samo jest z CI. Uczciwy audyt pokazał nam, że pipeline sprawdzał typy, lint, podstawową logikę i uprawnienia w bazie. Build produkcyjny, testy aplikacji i testy na zdalnym środowisku uruchamialiśmy ręcznie w sesji. Jeden z evali sam się wyłączał bez ostrzeżenia. Zielony badge mówił tylko, że przeszły checki, które faktycznie uruchomiono. Reszta to było trust me bro. Od tego czasu każdy release podaje, co sprawdzono, co skipnięto i co zostało do zrobienia. Tego samego wymagam od każdego PR: szablon tej strony chce Testing, Risk i How to revert ([więcej tutaj](https://simonebova.com/pl/writing/nessuno-legge-ogni-riga)).

Test powinien też trafić na najgłębszą prawdziwą granicę, którą możesz sprawdzić bez udawania. Przy niektórych akcjach testowanie ścieżki od interfejsu wymagałoby symulowania połowy frameworka. Testowalibyśmy symulację. Umieściliśmy test na prawdziwej operacji w bazie, a interfejs oglądamy na środowisku preview.

## Pierwsze udane wywołanie nic nie mówi o sesji

Konektor łączący asystentów z Brain przechodził pierwszy check: tożsamość potwierdzona, pierwsze wywołanie udane. Po kilku minutach znów prosił o zalogowanie. Wyglądało to na zbyt wcześnie wygasający dostęp. Przyczyną był sposób, w jaki równoległe połączenia jednego asystenta odnawiały dostęp. Wchodziły sobie w drogę, a system uwierzytelniania z ostrożności zamykał je wszystkie.

Ponowne połączenie i kolejne udane wywołanie niczego by nie dowiodło. Za dowód uznałem tylko prawdziwą, długą sesję, w której dostęp odnowił się pomiędzy dwoma udanymi wywołaniami. Dla każdego konektora właściwy check to długa sesja, kilka połączeń otwartych jednocześnie i odzyskanie połączenia, gdy jedno padnie.

## Najpierw pokaż użyteczną wiedzę, potem poproś o podłączenie asystenta

Podłączenie własnego asystenta do Brain było tym, co nas wyróżniało. Naturalnie chciało się dać je jako pierwszy krok onboardingu. Wybraliśmy odwrotną kolejność: najpierw podłącz pocztę i zatwierdź pierwszą propozycję, potem podłącz asystenta, potem zaproś zespół. Asystent połączony z pustym Brain nie ma nic do powiedzenia. Zużywa najlepszy moment uwagi, jaki dostaniesz.

Przy tej samej decyzji usunęliśmy pytania przy rejestracji i kreator z wieloma ekranami. Zamiast nich jest lista na stronie głównej, z jedną główną akcją naraz. Kreator ukrywa dokładne miejsce, w którym ludzie się gubią. Patrzymy na to, ile czasu zajmuje dotarcie do pierwszej zatwierdzonej wiedzy w tej samej sesji.

## Zatwierdzenie przez człowieka jest zależnością na produkcji

Brain ma jedną podstawową regułę: wszystko z czatu, plików, poczty, rutyn czy asystentów wchodzi jako propozycja. Staje się prawdą dopiero po decyzji człowieka. Nasz zespół czytał jednak Brain prosto z asystentów, bez otwierania aplikacji. Propozycje się piętrzyły, a zatwierdzona część starzała się z każdym dniem.

Ekran zatwierdzania pokrywa połowę governance. Druga połowa to dotarcie z decyzją do osoby, która ma ją podjąć, tam, gdzie już pracuje. Zaprojektowaliśmy remindery dla ownerów poza platformą: zbiorcze, bez duplikatów, z bezpośrednim linkiem do queue. Same ustają, gdy queue jest pusta. Approval queue zasługuje na taką samą uwagę jak każdy inny backlog na produkcji. Jeśli nikt nie zatwierdza, nowa wiedza nigdy nie dociera do ludzi, którzy z niej korzystają.

## Zgoda obowiązuje dla akcji, którą widziałeś

Zgoda udzielona w Brain może najwyżej przygotować draft emaila, nigdy go wysłać. Mimo to musieliśmy ustalić, co robić, gdy nie wiadomo, czy akcja się udała. Retry jest standardową odpowiedzią na chwilowy błąd. Tu tworzyłby zduplikowane drafty. Przy wysyłce: podwójne emaile do klienta. Gdy wynik jest nieznany, system mówi o tym i czeka na człowieka.

Zgoda dotyczy dokładnie tej akcji, którą osoba zobaczyła: treści, źródeł, odbiorców, warunków. Jeśli cokolwiek później się zmieni, zgoda wygasa. Tuż przed działaniem system ponownie sprawdza, czy zatwierdzająca osoba nadal ma do tego prawo. „Zatwierdzone”, które zostaje w interfejsie, gdy pod spodem zmienia się akcja, pozwala na coś, czego nikt nie widział.

## Kontrargument: za dużo governance jak na świeży produkt

Najmocniejszy kontrargument wobec tego wszystkiego: świeżo uruchomiony produkt musi dostarczać i się uczyć, a tyle governance go spowalnia. Nie zmieniłem zdania. Z tych zasad korzystamy codziennie. To one pozwalają agentom czytać i proponować, bez samodzielnego zapisywania prawdy.

## Od poniedziałku

- Napisz test, który przechodzi całą ścieżkę od strony użytkownika: utwórz, zatwierdź, wyszukaj, znajdź.
- Obok każdego kroku w tle, który może zawieść po cichu, dodaj check, który go naprawi.
- Prześledź prawdziwy obiekt od najczęściej używanego wejścia do ostatniej funkcji, która od niego zależy.
- Testuj konektory w długiej sesji z kilkoma otwartymi połączeniami.
- Zapewnij zatwierdzeniom kanał dotarcia do osoby, która ma zdecydować.
- Przy każdym działaniu zewnętrznym ustal z góry, co zrobisz, gdy nie wiesz, czy się udało.
- Przy każdym release podaj checki wykonane, skipnięte i pozostałe do zrobienia.

*// wpis w Brain opisujący błąd powiązań jest też pierwszym, który przyszedł od asystenta z podanymi powiązaniami.*

[simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)