--- title: "Kontroluj harness, zmieniaj model. Co naprawdę musisz mieć pod kontrolą" url: "https://simonebova.com/pl/writing/possiedi-l-harness" lang: "pl" updated: "2026-10-21" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/possiedi-l-harness" en: "https://simonebova.com/md/en/writing/possiedi-l-harness" pl: "https://simonebova.com/md/pl/writing/possiedi-l-harness" --- # Kontroluj harness, zmieniaj model. Co naprawdę musisz mieć pod kontrolą 2026-10-21 · Frontier Kontrola nad harness to kontrola nad stanem, uprawnieniami, regułami i weryfikacją, z gotowymi narzędziami pod spodem. Czego nauczyły mnie DeepSWE, CVing i Company Brain od Yempik. [DeepSWE](https://deepswe.datacurve.ai/blog/deepswe), benchmark kodowania z agentami, z zadaniami napisanymi od zera i ręcznie napisanymi verifierami, nadał liczbę temu, co ludzie pracujący z agentami czują od dawna. Na SWE-Bench Pro modele frontier mieszczą się w przedziale około 30 punktów. Na DeepSWE, z zadaniami, których nikt wcześniej nie widział, te same modele dzieli około 70 punktów. Gdy to komentowałem, mój wniosek był taki: > A score that doesn't look like your work tells you nothing about your work. Oceniaj na własnej pracy. Kontroluj infrastrukturę, główną logikę i weryfikację. Traktuj modele i harnessy jako wymienne części. Pracując nad tym, lepiej zrozumiałem, co znaczy mieć kontrolę. Własny harness nie oznacza budowania go od zera. Oznacza kontrolę nad rzeczami, które pozwalają zmienić model lub narzędzie bez utraty panowania nad systemem: stanem, uprawnieniami, zasadami działania i weryfikacją. ## Warstwa, którą kontrolujesz, leży nad gotowymi narzędziami Na początku zastanawiałem się, kiedy własny harness przestaje się opłacać. Kiedy gotowy produkt zna już wystarczająco dobrze twoje środowisko? Dla agentów kodujących odpowiedź brzmi: teraz. Claude Code i Codex lepiej ode mnie zmieniają kod, izolują wykonanie i podpinają checki. Odtwarzanie tego byłoby zmarnowaną pracą. Dlatego warstwa, którą kontroluję, przesunęła się poziom wyżej. To moje własne, wersjonowane reguły: który model robi jaką pracę, gdzie trafia każdy wynik, co wolno workerowi, co sam sprawdzam przed odbiorem. Narzędzia pod spodem można wymieniać. To samo dotyczy produktów: ustal reguły, które musisz kontrolować sam, a pod spodem użyj tego, co już istnieje. ## Weryfikator jest częścią produktu Autorzy DeepSWE sprawdzili verifiery odziedziczone po wcześniejszych benchmarkach. Znaleźli sporo testów, które odrzucają poprawne implementacje albo akceptują niedokończoną pracę. „Zaliczone” wygląda obiektywnie, a zależy w całości od tego, kto napisał check. Wynik dotyczy też pary model plus harness. Gotowy produkt każdego dostawcy to inny system. W swoich evalach oceniaj zachowanie, które da się zobaczyć. Przejrzyj ręcznie próbkę rozbieżnych ocen. Sprawdź, czy verifier akceptuje różne sposoby poprawnego wykonania zadania. Jeśli judge'em jest model, podaj niepewność jego oceny. ## Ważne reguły działają tam, gdzie wykonywana jest akcja W agencie WhatsApp, którego zbudowałem dla platformy rekrutacyjnej CVing, agent może powiązać numer telefonu z kontem i wysyłać aplikacje na oferty pracy. Dwie akcje z prawdziwymi skutkami dla prawdziwych ludzi. Zdecydowałem się przenieść security checki z promptu do kodu wykonującego każdą akcję. Model może prosić o powiązanie konta do woli, nawet najbardziej przekonującym tonem na świecie. Jeśli w tej rozmowie nie ma weryfikacji, akcja nie rusza. Prompt wyjaśnia oczekiwane zachowanie. Kod rozstrzyga, czy wolno wywołać skutek. Świetnie napisany prompt nadal jest instrukcją, a instrukcję można obejść. Tej samej kolejności trzymam się, gdy agent powtarza błąd w codebase: najpierw fixuję kod, potem dodaję check, a instrukcje piszę na końcu ([dlaczego](https://simonebova.com/pl/writing/cambia-il-codice-prima-del-prompt)). Tak samo jest z tożsamością. To kanał mówi, kto pisze na WhatsApp. Jeśli model próbuje użyć innego numeru, kanał ma ostatnie słowo. W Company Brain od Yempik o tym, dla której firmy działa asystent, decyduje logowanie danej osoby. To, co przychodzi od modelu, jest prośbą wymagającą autoryzacji. Zapisane dane nadal są niezaufane, gdy ponownie trafiają do modelu. W CVing nawet nazwy plików przesłanych przez kandydatów sprawdzamy ponownie przy odczycie. Zapisanie danych nie czyni ich bardziej wiarygodnymi. Żaden z tych kroków nie daje odporności na prompt injection. Zmniejszają powierzchnię ataku, tyle. ## Stan biznesowy żyje poza rozmową W CVing aplikowanie zaczyna się od linku do konkretnej oferty pracy. W długich rozmowach, z wieloma danymi do zebrania, model w pewnym momencie tracił z oczu pierwszą wiadomość i wymyślał ofertę. Powiększyłem pamięć rozmowy. Prawdziwą poprawką było jednak zapisanie aktywnej oferty jako faktu w systemie. Akcje korzystają z niego zamiast z tego, co model pamięta. Dłuższa pamięć pomaga interpretować rozmowę. Prawda biznesowa musi być zapisana gdzie indziej. Innym razem kandydat utknął. Jego weryfikacja wygasła w trakcie rozmowy. Agent nadal uważał ją za ważną, nie prosił o nowy kod i powtarzał, żeby sprawdzić pocztę, do której nic nie przychodziło. Od tego czasu weryfikacja obowiązuje przez określony czas. Traci ważność od razu, gdy odrzuci ją system, który ją wystawia. W ramach tej samej pracy sklasyfikowałem każdy zapis jednym pytaniem: czy powtórzenie go wyrządzi szkodę? Jeśli nie, po błędzie robimy retry. Jeśli ważna akcja już się udała, a zawodzi tylko zapis tego faktu, kandydat idzie dalej, a system odnotowuje problem. „Zatrzymaj wszystko przy każdym błędzie” i „zawsze retry” brzmią rygorystycznie. Obie zasady psują ścieżkę użytkownika. ## Ta sama pamięć, inne instrukcje, inny wynik Przydarzyło mi się to z własnym agentem. W moim second brain dogłębnie przetwarza źródła: czyta je w całości, zachowuje liczby, autorstwo twierdzeń i sprzeczności. Na platformie używanej przez całą firmę, zapisując do podobnej pamięci inną drogą, tworzył ubogie wpisy. Ten sam model, ta sama pamięć pod spodem. Zmieniały się instrukcje, które dostawał. Z jednej strony głębia, uzasadnienia, pochodzenie i jasne kryterium ukończenia pracy. Z drugiej zachęta do rozbijania wszystkiego na małe fakty. Poprawka polegała na wprowadzeniu tych samych merytorycznych zasad przy każdym wejściu, z końcowym checkiem. Nadal trzeba zmierzyć, ile znaczenia rzeczywiście zostaje. Jeśli udostępniasz tę samą pamięć z kilku miejsc, porównaj instrukcje i definicję „gotowe” dla każdego z nich. ## Wyszukiwanie musi umieć powiedzieć, że nic nie ma Ranking zawsze wyłania zwycięzcę, nawet gdy wszyscy kandydaci są błędni. W Company Brain keyword search był tak ścisły, że pytania zadane naturalnym językiem prawie nic nie znajdowały. Bez tego potwierdzenia nawet pytania zupełnie niezwiązane z Brain zwracały zatwierdzone decyzje na szczycie wyników. Tylko dlatego, że były najmniej odległe. Złagodziliśmy keyword search i ustaliliśmy, że pierwsze miejsce nie wystarczy. Wynik musi przekroczyć próg trafności zmierzony na prawdziwych danych. „Nic nie mam” jest poprawną odpowiedzią. Próg trzeba ustalać ponownie za każdym razem, gdy zmienia się sposób mierzenia podobieństwa. Odmowę trzeba oceniać równie starannie jak samo wyszukiwanie. ## Kontrargument: za chwilę model zrobi wszystko sam Najmocniejszy kontrargument wobec inwestowania w warstwę wokół modelu: modele poprawiają się tak szybko, że ta warstwa stanie się zbędna. Ale model, którego używasz dziś, jest zamrożony. W sesji może dojść do prawdziwego odkrycia, które potem nigdzie nie zostaje. Na callu z innym builderem powiedziałem: «una volta che hai avuto una sorta di epifania, non esiste un modo per metterlo in qualche maniera nei suoi pesi», czyli kiedy już doznasz czegoś w rodzaju olśnienia, nie ma jak zapisać go w wagach modelu. Dlatego inwestuję w kontekst i nazywam rzeczy po imieniu. Gdy mówię, że company brain staje się bardziej użyteczny, chodzi mi o gromadzenie zatwierdzonej wiedzy, procedur, przykładów i evali. Model zostaje ten sam. Nawet dziś zmiana modelu nie jest pracą na jedno popołudnie. Wszystko wokół trzeba sprawdzić ponownie. ## Od poniedziałku - Wypisz reguły, które musisz kontrolować sam. Pod spodem użyj gotowych narzędzi. - Kontrole każdej akcji z konsekwencjami umieść w kodzie, który ją wykonuje. - Tożsamość i firmę ustalaj na podstawie logowania. To, o co prosi model, wymaga autoryzacji. - Zapisuj fakty biznesowe poza rozmową. Każdej weryfikacji nadaj termin ważności. - Sprawdź, czy wyszukiwanie umie odpowiedzieć „nic”. - Buduj evale na własnej pracy i sprawdzaj verifier ręcznie. *// dwa pytania nie na temat, które teraz nie zwracają wyników: zakup przekąsek i karmy dla chomików.* [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)