--- title: "Model może kupić każdy. Mało kto wie, którą pracę usunąć." url: "https://simonebova.com/pl/writing/il-modello-e-una-commodity" lang: "pl" updated: "2026-09-29" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/il-modello-e-una-commodity" en: "https://simonebova.com/md/en/writing/il-modello-e-una-commodity" pl: "https://simonebova.com/md/pl/writing/il-modello-e-una-commodity" --- # Model może kupić każdy. Mało kto wie, którą pracę usunąć. 2026-09-29 · Metoda Każdy może użyć modelu frontier. Przewaga to wiedzieć, którą pracę usunąć, które decyzje zostawić ekspertowi i jak udowodnić wynik. Przypadki z Lia i CVing. W pierwszej wersji tego tekstu napisałem, że jakość modelu nie jest problemem i że jeśli agent zawodzi, błąd zawsze leży w projekcie. Poszedłem za daleko. Spędzam dni na decydowaniu, który model robi co, więc nie mogę tego bronić. Wersja, której bronię teraz, jest węższa: dostęp do modelu frontier jest łatwy dla każdego. Rzadką umiejętnością jest wiedzieć, którą pracę zdjąć z człowieka, które decyzje mu zostawić i jak udowodnić, że wynik wytrzyma próbę czasu. Nauczyłem się tego w rozmowach z zarządcami nieruchomości przy Lia, produkcie Yempik dla biur zarządzania nieruchomościami, i przy budowaniu agenta WhatsApp dla CVing. ## Kto prosi o komplet funkcji, często chce pozbyć się innej pracy Lia powstała bez księgowości, celowo. Zarzut wracał często. Raz zapisaliśmy go słowo w słowo: «se io uso un gestionale senza la parte contabile, lo uso a metà», czyli jeśli używam systemu do zarządzania bez części księgowej, używam go tylko w połowie. Czytane w ten sposób wyglądało to na jasną wskazówkę do planu rozwoju. Zadaliśmy więc pytanie inaczej dwóm zarządcom, którzy się nie znają i pracują w różnych miastach: co sprawia, że rano przeklinasz? Obaj postawili księgowość na końcu. Obaj sami wyjaśnili dlaczego. Pierwszy: «Non è la parte contabile. Il problema è la parte pratica, quindi tutti gli interventi.» Czyli nie księgowość, tylko praktyczna strona, wszystkie prace i interwencje. Drugi: kiedy faktury są dobrze zapisane, księgowość zrobi dowolny program. Zarzut dotyczył funkcji. Dobrze przewiduje, co klient mówi, gdy porównuje dwa produkty na papierze. Słabo przewiduje, za rozwiązanie czego zapłaci. Zdecydowaliśmy: obsługa codziennej pracy przed księgowością. Sprawy i wykonawcy, poczta, WhatsApp oraz wykrywanie właścicieli zalegających z płatnościami i zatwierdzane przypomnienia. Najbardziej potrzebna wartość leżała obok ogromnego podsystemu. Żeby ją dać, nie trzeba było go odtwarzać. Dwie rozmowy nie tworzą prawa rynku. Wystarczą, żeby nie zacząć od budowania złej części. ## Najbardziej użyteczne pytanie dotyczy niemożliwego Eksperci proszą o funkcje, które uważają za osiągalne. Największa wartość zwykle kryje się w tym, czego nie mówią. Tak przywykli do starego systemu, że pewnych rzeczy już nie kwestionują. Dlatego na każdym pierwszym spotkaniu zadaję to samo pytanie, zapisane tak w moich notatkach: > what's the one thing that would be so cool to have/that would change your life but that we did not even mention because it is impossible? Zadaję je, zanim pokażę, co potrafi mój stack. Po demo odpowiedzi zawężają się do tego, co właśnie pokazałeś. Potem spokojnie badam odpowiedź. Przy stole niczego nie obiecuję. ## Zanim poszukasz lepszego modelu, poszukaj danych wejściowych z własnym kontekstem Podczas rozmowy o Lia mówiliśmy o wykonawcach, którzy wysyłają zdjęcia prac przez WhatsApp. Pomysł na stole stawiał w pełni na AI: AI patrzy na zdjęcie i rozpoznaje budynek oraz pracę. Zaproponowałem odwrotną drogę, dużo mniej sexy. Wysyłamy wykonawcy link powiązany z konkretną pracą. Tam dodaje zdjęcia, które trafiają prosto do właściwej sprawy. «Senza che il fornitore debba imparare a utilizzare il gestionale», czyli bez uczenia wykonawcy obsługi systemu do zarządzania. Link usuwa problem, zamiast prosić model o jego rozwiązanie. To nadal propozycja. Otwarte pozostają szczegóły wygasania i ochrony linku. Zasada działa wszędzie: zanim poprawisz wyciąganie informacji czy rozumowanie, sprawdź, czy zgłoszenie może od początku być powiązane z właściwym rekordem. ## Niektóre gate'y z decyzją człowieka zostają nawet wtedy, gdy model ma rację Gdy opisaliśmy automatyczne przypomnienia o płatnościach, jeden zarządca nas zatrzymał. Z niektórymi właścicielami ma niepisane ustalenia dotyczące terminu i sposobu zapłaty. Automatyczne przypomnienie, poprawne i wysłane na czas, może zakończyć relację wartą znacznie więcej niż samo przypomnienie. W notatkach z tego calla zapisałem: «fare solleciti alla gente giusta, non sbagliata», czyli wysyłać przypomnienia właściwym ludziom, nie tym, którym nie należy. Drugi zarządca chciał tego samego ekranu potwierdzenia z odwrotnego powodu: jego system rozliczania wpłat czasem gubi płatności, więc dane mogą być błędne. Jego gate zależy od jakości danych. Można go złagodzić, gdy dane się poprawią. Pierwszy zależy od relacji i zostaje, bo tamta umowa nigdy nie trafi do pola w bazie. Gate'y chroniące relację muszą być szybkie: gotowa lista i jedno potwierdzenie na wiersz. ## Zachowaj standard eksperta i zmień kroki Utrwalone praktyki eksperta są dwiema rzeczami naraz: nawykami i sposobem, w jaki dziś zapewnia jakość. Jeśli zautomatyzujesz je bez zmian, skopiujesz strukturę organizacji. Jeśli je wyrzucisz, stracisz jakość. Projektuję od zera w tym, co nazywam «modo ignorante», czyli trybem ignoranta. Ignoruję istniejący proces i zaczynam od jednego ograniczenia: “this must be done by a single person with these AI tools”. Standard eksperta pozostaje kryterium odbioru wyniku. Ekspert liczy się wtedy bardziej niż wcześniej, ale w innej roli. Zatwierdza standardy, dostarcza akceptowane przykłady i niedopuszczalne błędy. Aktualizuje je, gdy zmienia się dziedzina. To jego akceptacja odróżnia powtarzalny wynik od wygranej na loterii tokenów. Jeśli twój human in the loop to osoba poprawiająca każdy wynik, masz review queue przebraną za system. Zbieraj przykłady i kryteria, buduj evale i mierz, jak często wynik się powtarza. Z kodem jest tak samo: człowiek czytający każdy diff to też review queue ([tutaj](https://simonebova.com/pl/writing/nessuno-legge-ogni-riga)). ## Minimalny produkt to zamknięty cykl, także poza twoim produktem Pierwszą jednostkę wartości Lia określiliśmy krok po kroku: zaimportować prawdziwy budynek, odebrać email, ustalić, kto pisze i o który budynek chodzi, otworzyć lub zaktualizować sprawę, przygotować odpowiedź, poprosić o zatwierdzenie, zapisać wynik. Test przyjęcia produktu jest jeden: czy biuro chce przenieść do Lia także pozostałe zarządzane budynki? Biuro pracujące z Lia na swoich prawdziwych danych wskazało problem, którego żadne demo by nie pokazało. Email obsłużony w Lia nadal czekał jako nieprzeczytany w Gmail. Powiedzieli: «o lavoriamo su CRM o lavoriamo su Gmail. Non puoi lavorare su entrambi», czyli albo pracujemy w CRM, albo w Gmail, nie można pracować w obu. Odpowiedzi były dobre, ale produkt stworzył drugą skrzynkę do pilnowania. Więcej pracy, odwrotność obietnicy. „Gotowe” trzeba zdefiniować w systemie, na którym użytkownik nadal polega, i sprawdzić na całej ścieżce. Ten sam cykl musi przetrwać migrację. Kto zmienia system, przenosi budynki pojedynczo, szkoli ponownie kolegów i pracuje z częściowymi eksportami. Rozpisz sposób przejścia klienta, zanim założysz, że wszystko zmieni się w jeden dzień. ## Kontrargument: czyli model nie ma znaczenia Najmocniejszy kontrargument trafia w moją starą wersję: jeśli model jest powszechnie dostępnym towarem, weź najtańszy i zamknij temat. Możliwości modelu nadal są ograniczeniem do sprawdzenia. Agent WhatsApp dla CVing zaczął na małym, tanim modelu. Miesiąc później działał na modelu o większych możliwościach. Można go zmienić bez ruszania kodu. Ta wymienność jest trafną częścią tezy o powszechnej dostępności modeli. Nie zmierzyłem osobno wyniku przed i po zmianie, więc nie przypisuję jej żadnej poprawy. Moja kolejność: najpierw sprawdzam dane, narzędzia, stan i instrukcje. Potem sprawdzam, czy model daje radę z zadaniem. Zachowuję możliwość zmiany dostawcy i żądam dowodów przed zaakceptowaniem zamiany. ## Od poniedziałku - Poproś klientów o uporządkowanie konkretnych frustracji. Oddziel „spodziewam się, że to będzie” od „potrzebuję, żeby to zostało rozwiązane”. - Zadaj pytanie o niemożliwe przed demo. - Zanim poprawisz wyciąganie informacji, spróbuj powiązać dane wejściowe z rekordem. - Dla każdego gate'u z decyzją człowieka zapisz powód: niepewne dane czy relacja. Ograniczaj pierwszy rodzaj, przyspieszaj drugi. - Zdefiniuj „gotowe” w systemie, którego użytkownik nadal używa, i sprawdź to na całej ścieżce. - Zachowaj możliwość zmiany modelu i testuj każdą zmianę na prawdziwym zadaniu. [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)