Cześć! 👋
Ostatnie tygodnie na LinkedInie i w podcastach wyglądają tak, że co druga osoba budująca coś z AI mówi jakiś wariant zdania: „budujemy teraz harness dla naszego AI / agenta”.
Brzmi jak kolejne słowo-wytrych. Ale akurat to może być przydatne, bo nazywa rzecz, o którą w produktach AI toczy się teraz cała gra. Rozłóżmy je na części.
📆 W środę robimy spotkanie LIVE z dwójką senior product leaderów z absolutnie topowych firm produktowych na świecie → Ravi Mehta (Tinder, Facebook, Reforge) oraz Michelle Parsons (Spotify, Netflix). 👉 Można się jeszcze zapisać.
Po więcej produktowych treści → sprawdź najnowsze wpisy, najpopularniejsze wśród czytelników, posłuchaj podcastu Dodane do Backlogu, albo skorzystaj z moich szkoleń.
W dzisiejszym wydaniu:
Skąd się wzięło całe to “harness”?
Z czego składa się harness?
Czyli mój agent w Cursorze to już harness?
Budowanie na cudzym harness: analiza zachowania użytkowników w Cursorze
Własny harness: agent konwersacyjny w produkcie
Model się zmienia, harness zostaje
Pułapka w budowaniu harnessu
1. Skąd się wzięło całe to “harness”?
Harness to po angielsku uprząż/rusztowanie. W tworzeniu software’u słowo funkcjonuje od dekad w zbitce test harness - rusztowanie, które uruchamia Twój kod, podaje mu dane wejściowe i sprawdza, co wyszło. Sam kod nic nie robi, dopóki ktoś go nie odpali w odpowiednim otoczeniu.
Przy modelach AI słowo pojawiło się najpierw przy testowaniu:
Żeby sprawdzić, ile model potrafi, ktoś musi mu podać zadania, dać dostęp do narzędzi, pozwolić popracować przez kilka kroków i policzyć wyniki. Cała ta obudowa wokół testu to właśnie harness.
Szybko wyszło, że ten sam model w lepszej obudowie rozwiązuje wyraźnie więcej zadań. Firmy zaczęły więc przy wynikach dopisywać, w jakim harnessie testowały - bo bez tego liczba nic nie znaczy. I stąd słowo przeszło z testów do prawdziwych produktów.
Bo mechanizm jest ten sam. Model sam w sobie to funkcja: wchodzi tekst, wychodzi tekst. Nie ma pamięci, nie ma dostępu do Twojego CRM-a, nie wie, czy zadanie zostało skończine
Harness to wszystko, co dokładasz wokół modelu, żeby z tej funkcji zrobić coś, co wykonuje pracę.
2. Z czego składa się harness?
W praktyce modele AI zwykle opakowujemy w podobne warstwy:
Pętla - model wybiera narzędzie, narzędzie się wykonuje, wynik wraca do kontekstu, model decyduje co dalej. Powtórz, aż zadanie jest zrobione. To pętla, a nie model, sprawia, że coś zachowuje się jak agent.
Instrukcje - kim agent jest, jaki proces ma wykonać, jakie zna reguły Twojego biznesu i czego nie robi nigdy. Piszesz je Ty / Zespół, świadomie, i możesz je przejrzeć jak zwykły dokument. Z całej listy to warstwa, którą product manager najczęściej robi własnymi rękami.
Kontekst - wszystko, co agent dostaje do jednego konkretnego zadania: treść zgłoszenia, dane klienta, wyniki wyszukiwania, efekty własnych kroków sprzed chwili.
Gdy kontekst się zapełni, harness musi część sprzątnąć i zostawić streszczenie zamiast oryginałów, a agent od tego momentu pracuje na tym streszczeniu.
Co trafia do kontekstu i co przetrwa sprzątanie - to dziś główny problem inżynierski w agentach i powód, dla którego mówi się o „context engineering” zamiast o promptach.
Narzędzia - czytanie plików, wywołanie API, zapytanie do bazy, wysłanie maila.
Środowisko i uprawnienia - gdzie ta pętla się w ogóle wykonuje. Na czyimś laptopie, w kontenerze, na osobnej maszynie w chmurze. Czy agent ma dostęp do internetu, do jakich plików, i co zostaje po zakończeniu zadania. Co agent może zrobić sam, co wymaga kliknięcia człowieka, co jest zablokowane, i jak to cofnąć. To decyduje o tym, jakie akcje są fizycznie możliwe, i o tym, co się stanie, gdy agent zrobi coś głupiego.
Weryfikacja - skąd agent (i Ty) wiecie, że zadanie zostało wykonane dobrze. Testy, walidacja, drugi model jako recenzent, sprawdzenie stanu w systemie.
Limity i obsługa błędów - limit kroków, limit tokenów, timeout, retry, co się dzieje, gdy narzędzie zwróci błąd.
3. „Czyli mój agent w Cursorze to już harness?”
W sumie Tak.
Cursor, Claude Code i Claude Cowork to gotowe harnessy, w dodatku jedne z najlepszych, jakie w tej chwili można dostać.
Wszystkie wspomniane warstwy już tam siedzą: pętla, która kręci się tak długo, aż zadanie jest zrobione, pliki z instrukcjami i regułami, zarządzanie kontekstem, narzędzia (terminal, edycja plików, wyszukiwanie, MCP), środowisko wykonania, pytanie o zgodę przed groźniejszymi akcjami, uruchamianie testów jako weryfikacja i limity, po których agent się zatrzymuje. Cześć z tych rzeczy sam dorzucasz do Cursora (np. pliki kontekstu, podłączasz narzędzia)
Ale warto rozdzielić dwie rzeczy, bo w rozmowach ciągle się mieszają.
Rozbudowa cudzego harnessu - odpalasz Cursora, dopisujesz plik z instrukcjami, ustawiasz reguły, podpinasz MCP, dajesz dostęp do folderu z danymi. To jest praca nad harnessem - realna i sensowna - tylko na cudzym fundamencie. Ktoś zbudował pętlę, narzędzia, środowisko i uprawnienia, a Ty konfigurujesz to pod siebie.
Budowanie własnego harnessu - Twój produkt, Twoi użytkownicy, Twoje narzędzia, Twoje reguły tego, co agent może zrobić bez pytania. Tutaj wszystkie osiem warstw jest na Twojej głowie.
Najłatwiej będzie to zobaczyć na przykładach, wiec dwa przykłady z mojej praktyki w pracy fractional PMa nad indem z produktów Conversational AI:
3.1. Budowanie na cudzym harness: analiza zachowania użytkowników w Cursorze
Harnessem, które używam na codzień jest np. mój zwykły projekt w Cursorze, który służy mi do rozumienia, co użytkownicy robią w moim produkcie oraz ilościowa ewaluacji zmian / problemów użytkowników:
Moje instrukcje to pliki z opisem produktu i znaczeniem konkretnych metryk + skille odnośnie tego jak pracować z bazą danych.
Narzędzia to dostęp do kodu oraz do bazy z możliwością puszczania zapytań SQL.
Kontekst to pliki z poprzednimi analizami, więc agent nie startuje za każdym razem od zera.
Guardrails - do weryfikacji procesu oraz wyników
Finalną weryfikatorem jestem ja - czytam zapytanie, patrzę na wynik, mówię „nie tak” i lecimy dalej.
Zero linijek kodu. Cała robota to pliki tekstowe i przyznanie dostępów. A różnica wobec wklejenia pytania do zwykłego czatu jest gigantyczna, bo model w czacie nie wie, co w tym produkcie znaczy „aktywny użytkownik” ani w której tabeli tego szukać.
3.2. Własny harness: agent konwersacyjny w produkcie
Drugi przykład to już właśnie agent rozmawiający z użytkownikami produktu, którym zajmuję się jako PM. Tu trzeba było zbudować harness od zera. Jest tam m. in.:
Agent, który pisze odpowiedzi do użytkowników
Agent, który sprawdza odpowiedź zanim pójdzie do użytkownika
Instrukcje nie są jednym wielkim promptem: jest baza plus skille, które doładowują się razem z potrzebnymi narzędziami dopiero wtedy, gdy sytuacja tego wymaga.
Guardrails które opisują co bot może, a czego nie może robić
Środowisko odpalające modele - część na lokalnych naszych, część przez dostęp po API
Do tego automatyczne testy i narzędzie wyłapujące zakazane słowa oraz próby prompt injection - rozwiązany kodem zamiast nadzieją, że model sam się połapie.
…
3.3. Model się zmienia, harness zostaje
Oba harnessy przeżyły już wiele zmian modelu:
W moim harnessie do analiz w Cursorze - za każdym razem mogę wybrać inny model. W zależności od tego jak trudne jest zadanie to wybieram tańsze/droższe modele.
W produkcie też finalnie sprowadza się do zmiany jednej linijki konfiguracji - reszta zostaje nietknięta i właśnie o to chodzi w całym tym rozróżnieniu.
Tylko że wyniki po takiej zamianie potrafią się zmienić i nie zawsze na plus. I w przypadku produktu może mieć mieć to kolosalne znaczenie - nowy model bywa lepszy w jednych rzeczach, a w innych nagle zaczyna ignorować instrukcję, którą poprzedni respektował, albo inaczej korzysta z narzędzi. Nie ma tu żadnej gwarancji, że „nowsze” znaczy „lepsze dla mojego zastosowania”.
I to jest moment, w którym AI evals do twojego produktu stają się krytycznym elementem. Bez zestawu zadań, na którym mierzysz jakość, po podmianie modelu masz dokładnie jedno źródło wiedzy o tym, czy było warto: własne wrażenie.
Praktyczny wniosek: Cursor czy Claude Code to najtańszy symulator, jaki masz. Zbuduj tam prototyp procesu, który chcesz zautomatyzować w produkcie, i policz, ile razy musiałeś ręcznie wejść i poprawić. Każde takie wejście to element, który w Twoim produkcie ktoś będzie musiał zaprogramować.
4. “Harness” to to czym wyróżnia się Twój produkt
Najciekawsza obserwacja z ostatniego roku: ten sam model w dwóch różnych harnessach daje radykalnie różne wyniki. Laby raportują na benchmarkach agentowych różnice liczone w kilkunastu punktach procentowych, przy dokładnie tej samej wadze modelu. Narzędzia, których codziennie używasz, siedzą na tych samych modelach od Anthropic czy OpenAI - a różnią się jakością bardzo mocno.
Dla PM-a wynikają z tego cztery rzeczy.
Wartość przesunęła się z wyboru modelu na projekt otoczenia - „Który model wybieramy” jest ważne, ale z czasem ta decyzja będzie mniej więcej tej wagi decyzją co wybór dostawcy hostingu. Ważna, odwracalna, nie różnicująca. Różnicujące jest to, jakie narzędzia dajesz agentowi, do jakich danych ma dostęp i jak sprawdzasz jego pracę. Tego konkurencja nie kupi w API.
Backlog wygląda inaczej - zamiast „dodajmy AI do modułu X” pytania brzmią: jakie narzędzia dostaje agent, jaki kontekst wchodzi do pętli, co robi sam, w którym momencie pyta człowieka, po czym poznajemy sukces. To są pytania produktowe, nie techniczne - i nikt ich za Ciebie nie zada.
AI Evals i metryki produktowe są krytycznie ważne - nie da się iterować po harnessie bez zestawu zadań, na których mierzysz, czy zmiana pomogła. Bez patrzenia jak to wpłynęło na zachowanie użytkowników.
Model biznesowy liczy się per zadanie, nie per użytkownik - pętla, która kręci się czterdzieści kroków, kosztuje czterdzieści razy więcej niż jedno zapytanie. Koszt i czas wykonania zadania stają się metrykami produktowymi, bo bezpośrednio decydują, czy model biznesowy się spina.
Konkretny prosty harness, który sam zbudowałem, opisuję w Jak zbudowałem sobie AI Research Partnera.
4. Pułapka w budowaniu harnessu
Część harnessu, którą budujesz dziś, za pół roku wchłonie model. Widać to za każdą generacją: rozbudowane systemy do planowania czy dekompozycji zadań dla agentów stają się mniej potrzebne, bo nowe modele robią to same coraz lepiej.
Prosta zasada podziału: buduj to, co specyficzne dla Twojej domeny - dostęp do danych, reguły biznesowe, uprawnienia, definicję sukcesu. Nie buduj protez do ogólnej inteligencji.
Jeśli Twój harness w większości łata to, czego model nie umie, następny release może go zaorać. Jeśli koduje wiedzę o Twoim biznesie - wiedzę dziedzinową, będzie żył dalej i przy okazji stanie się lepszy razem z modelem.
„Buduj to, co specyficzne dla domeny, a nie protezy do ogólnej inteligencji” zapisuję sobie na kartce. Sporo moich promptowych obejść przestało mieć sens po kolejnej aktualizacji modelu, a reguły biznesowe zostały.
Bardzo fajny wpis :)