Tekst powstał z materiału, który spisałem 9 sierpnia 2026, dzień po spotkaniu o metodach pracy ze sztuczną inteligencją. Liczby i opisy podaję według stanu z tego dnia.
Nie jestem „pro”
Zostałem tak zaklasyfikowany przez znajomych i nie zamierzam się z tym zgadzać, bo to myli trop. Owszem, czasem piszę kod, zbudowałem sporo integracji i utrzymuję małą serwerownię: VPS, hosting dla programistów i NAS, który stroję ręcznie. Ale nie o to chodzi. System, który tu opisuję, nie stoi na żadnej z tych rzeczy. Działa w zwykłym oknie czatu – na instrukcjach, plikach i standardowych łącznikach.
To, co realnie robię, mieści się w jednym zdaniu: traktuję model jak wykonawcę, którego trzeba wyszkolić, a nie jak wyrocznię, której się zadaje pytania. Szkolenie polega na poprawianiu metody, nie odpowiedzi. Cała reszta to konsekwencje tej jednej decyzji.
Jeśli ktoś szuka w tym tekście sprytnych promptów – nie ma ich tu. Są korekty, porażki i mechanizmy, które z nich wyrosły.
Punkt wyjścia
Różnica między „pytaniem czatowi” a tym, co robię, jest jedna: model ma skończyć robotę, a nie opisać, jak ją wykonać.
Z tego wynika wszystko inne. Skoro ma skończyć robotę, to:
– musi wiedzieć, jak pracuję – więc potrzebuje instrukcji stałej, nie powtarzanej w każdej rozmowie;
– musi dobierać metodę sam – bo jeśli ja muszę wskazać metodę, to znaczy, że sam wykonałem najtrudniejszą część;
– musi przyznać się, kiedy czegoś nie może – bo inaczej dostanę pewną siebie odpowiedź opartą na pliku, którego nigdy nie otworzył;
– musi mieć bramkę jakości – bo ja tej odpowiedzi nie sprawdzę linijka po linijce, tylko na niej zbuduję decyzję.
Dziewięć zasad, które wyszły z praktyki
Żadna nie pochodzi z artykułu o promptowaniu. Każda z sytuacji, w której coś poszło nie tak.
1. Odpowiedź najpierw. Teza albo decyzja na początku, uzasadnienie potem. Bez wstępów. Jeśli po trzech zdaniach nie wiem, co model rekomenduje, to nie jest odpowiedź, tylko wypracowanie.
2. Liczby i daty zamiast przymiotników. „Znacząco tańsze” nic nie znaczy. „+3–4,5 tys. zł, założenia cenowe z lipca 2026” znaczy.
3. Oddzielaj fakt, założenie, wniosek i interpretację. To jest jedyna reguła, która chroni przed mieszaniem tego, co wiadomo, z tym, co model dopowiedział.
4. Zero zmyślonego dostępu. Nie wolno twierdzić, że przeczytał plik, projekt albo historię, do których nie ma dostępu. Brak danych trzeba nazwać brakiem danych.
5. Rekomendacja, nie „to zależy”. Zależności można pokazać – ale na końcu ma paść, co wybrać i ile kosztuje ten wybór.
6. Minimalizuj błąd nieodwracalny, maksymalizuj opcje. Tania rezerwa dziś bije drogą przebudowę jutro. Ta zasada przyszła z remontu, nie z technologii.
7. Red team obowiązkowy. Model ma kwestionować moje założenia, nie potakiwać. Komora echa jest gorsza niż brak asystenta, bo daje fałszywą pewność.
8. Wynik = artefakt. Dokument, tabela, plan, kod albo konkretny następny krok. Nie refleksja.
9. Proste pytania rozwiązuj prosto. System, który każde pytanie traktuje ciężko, przestaje być używany. To jest warunek przeżycia, nie ozdoba.
Architektura w trzech zdaniach
Konstytucja – kilkanaście zasad obowiązujących zawsze, wklejonych raz w ustawienia konta.
Metody (24 sztuki) – spisane procedury: analiza decyzji, analiza prawna, badanie źródeł, kontrola obliczeń, redakcja, negocjacje, bramka nieodwracalności. Model dobiera je sam, według rodzaju problemu, nie według nazwy projektu. Sprawa prawna zostaje sprawą prawną, nawet jeśli wypłynęła w projekcie o SEO.
Stan – długie sprawy mają jeden plik z faktami, decyzjami i następnym krokiem. Pamięć rozmowy nie jest pamięcią; plik jest.
Do tego dwie rzeczy, które nie są warstwami, tylko nawykami: log regresyjny (każda porażka staje się wpisem z testem) i wersjonowanie z rollbackiem.
Sześć momentów, w których system się zmienił
Chronologia korekt jest ciekawsza niż opis architektury, bo pokazuje, skąd się ona wzięła.
Lipiec – remont uczy technologii
Pracowaliśmy nad pionem instalacyjnym w kamienicy. Model policzył warianty chłodzenia. Poprawiłem kierunek: skropliny mają być rozwiązane wariantowo, bo sucha rura rezerwowa kosztuje dziś kilkaset złotych, a pompki i nowe trasy będą kosztować kilka tysięcy.
To nie była korekta liczby. To była korekta kryterium: nie wybieraj rozwiązania docelowego, kup tanią opcję na przyszłość.
Weszło do metody analizy decyzji i obowiązuje odtąd wszędzie, także poza budowlanką.
25 lipca – odwrócenie procesu produkcji treści
Plan automatyzacji zakładał: model generuje szkic, człowiek redaguje. Odwróciłem to: człowiek pisze, model redaguje – i ma zostać lekko „brudno, ale na plus”.
Powód: model generuje to, co statystycznie najbardziej oczekiwane, czyli mniej więcej to, co wszyscy już napisali. Redaktor poprawi zdania, ale nie doda tezy, bo tezy nie było.
To jest moim zdaniem najważniejsza pojedyncza reguła w całym systemie. Model wnosi rzemiosło. Tezę wnosi człowiek.
25 lipca – test, który system oblał
Zdefiniowałem test obowiązkowy: wybór kancelarii w sprawie rodzinno-spadkowej nie może zostać sprowadzony do ceny, stylu kontaktu i ogólnego doświadczenia. Najpierw diagnoza, czego sprawa wymaga – potem porównanie ofert.
System go oblał. Potraktował to jak zwykłe porównanie ofert.
Naprawa objęła cztery opisy metod, nie przebudowę architektury. Retest przeszedł. Wniosek: test wart jest tyle, ile kosztuje jego napisanie, i nic więcej – dopóki go nie uruchomisz.
1 sierpnia – najdroższa lekcja
Analizowaliśmy plany pewnego dostawcy AI. Analiza objęła cenę, limity, warunki przetwarzania danych, lock-in cenowy. Pominęła jedno: w wybranym planie nie ma eksportu danych.
Wykonałem nieodwracalny merge czterech lat historii do przestrzeni, z której nie ma oficjalnego wyjścia.
Diagnoza po fakcie: „odwracalność” figurowała w procedurze jako jedno słowo na liście atrybutów. Zabrakło rozróżnienia dwóch różnych pytań:
– czy mogę zmienić zdanie?
– czy zabiorę ze sobą dorobek?
Można móc zmienić zdanie i jednocześnie stracić wszystko. Te dwa ryzyka nie mają ze sobą nic wspólnego, a w większości porównań ofert traktuje się je jako jedno.
Powstała osobna bramka: przy migracji, zmianie planu, scalaniu kont, usuwaniu i przy każdym porównaniu planów sprawdzany jest eksport danych po stronie docelowej – nawet jeśli o niego nie pytałem.
8 sierpnia – wymiana metod ze znajomymi
Spotkanie z dwoma osobami budującymi swoje systemy inaczej niż ja. Jeden zbudował rozbudowany warsztat: własna baza wiedzy, kilkadziesiąt integracji, agent robiący księgowość i faktury. Drugi trzyma się klasycznej, ręcznej metody porządkowania wiedzy i podłącza AI dopiero, gdy jest potrzebne.
Najcenniejsze zdanie padło od pierwszego z nich: reguła musi żyć tam, gdzie jest wykonywana. Notatka „ustaliliśmy, że X” w dokumentacji nie działa. Miał na to twardy dowód: reguła figurowała u niego w rejestrze korekt od kilku tygodni, ale nigdy nie trafiła do pliku, który faktycznie się wykonuje. Przegląd wykazał dziesiątki naruszeń w materiałach, które poszły do klientów – mimo że reguła „istniała”.
Drugi wniósł zastrzeżenie, którego nie miałem: delegując budowę bazy wiedzy do AI, tracisz uczenie się. Przetwarzanie myśli własnymi słowami jest tym, co tworzy zrozumienie. Repozytorium można mieć bez wiedzy.
8 sierpnia – sprawdzenie, które zabolało
Po tym spotkaniu poprosiłem o weryfikację, czy zmiany z mojego logu regresyjnego rzeczywiście są w systemie.
Nie były. Bramka nieodwracalności – ta z najdroższej lekcji – nie istniała. Log deklarował ją jako wdrożoną. Gdyby jutro pojawił się drugi taki pop-up, system zachowałby się dokładnie tak samo jak 1 sierpnia.
Dokładnie ten sam mechanizm, o którym godzinę wcześniej opowiadał znajomy. Tyle że u mnie i na najcięższej sprawie.
Katalog porażek
To jest najważniejsza część tego tekstu. Pokazy narzędzi AI zwykle ją pomijają.
| Porażka | Co się stało | Co z tego zostało |
|---|---|---|
| Lock-in danych | Cztery lata historii przeniesione tam, skąd nie ma eksportu | Bramka: odwracalność rozbita na cofnięcie, przenoszalność i koszt wyjścia |
| Fałszywy alarm | Ostrzeżenie o wysokiej wadze postawione na niesprawdzonym założeniu o statusie osoby. Założenie było fałszywe, alarm trzeba było wycofać | Symetria dowodowa: ostrzeżenie podlega temu samemu progowi dowodowemu co rekomendacja. „Ostrożnie” nie znaczy „bezpiecznie” |
| Log kłamał | Zmiana zadeklarowana jako wdrożona, nieobecna w systemie | Weryfikacja poprzedza wpis do logu, nigdy odwrotnie |
| Trigger nie łapał | Metoda działała bezbłędnie, ale nigdy sama się nie uruchamiała, bo opis nie pokrywał przypadku | Testuj osobno, czy metoda się włącza i czy poprawia wynik. Jedno nie zastępuje drugiego |
| Dwa źródła prawdy | Zbudowana dokumentacja nazwała samą siebie źródłem nadrzędnym, choć kanon był gdzie indziej | Podział po roli, nie po platformie: jeden kanon, reszta to implementacja |
| Wniosek z wczoraj nieaktualny dziś | Ustaliliśmy, że narzędzie nie ma funkcji zapisu. Dziś ją ma | Fakty o narzędziach mają datę ważności. Sprawdzaj, nie pamiętaj |
Wzorzec, który się z tego wyłania: prawie żadna porażka nie polegała na tym, że model nie umiał czegoś policzyć. Wszystkie polegały na tym, że coś było zadeklarowane, a nie wykonane – albo sprawdzone raz i uznane za sprawdzone na zawsze.
Co bym przekazał komuś, kto zaczyna
Buduj wiedzę o sobie, nie kolekcję promptów. Modele zmieniają się co kwartał i są wymienne. Plik opisujący, jak podejmujesz decyzje, czego nie znosisz w tekstach i jakie masz ograniczenia – nie jest wymienny.
Reguła musi żyć tam, gdzie jest wykonywana. Ustalenie zapisane w notatce o systemie nie istnieje. Musi trafić do pliku, który model wczytuje przed pracą. A jeśli mimo to błąd wraca – przestań powtarzać instrukcję głośniej i zamień ją na mechanizm, który blokuje błąd, zanim się wydarzy.
Zapisuj porażki, nie sukcesy. Każda metoda w moim systemie, która realnie działa, powstała po konkretnej wpadce. Te napisane „na zapas”, z wyobrażenia o procesie, są martwe – ładnie wyglądają i nic nie łapią.
Nie ufaj deklaracji wykonania. Ani swojej, ani modelu. Sprawdź artefakt.
Sprawdzaj eksport, zanim wejdziesz. Przy każdym narzędziu, które będzie gromadzić Twoją pracę. To pięć minut przed decyzją albo kilka lat po niej.
Prostych pytań nie obudowuj procedurą. Automatyzacja ma zwiększać trafność, a nie produkować rytuał.
Czego ten system nie robi
Uczciwe granice, żeby nie sprzedawać czegoś, czego nie ma.
– Nie zastępuje specjalisty. Przy gazie, konstrukcji, prawie i podatkach zadaniem systemu jest skrócić i potanić wizytę u fachowca, nie ją odwołać.
– Samokontrola ma sufit. Bramka jakości wykonywana jest przez ten sam model, który napisał odpowiedź. Wyłapie brakującą sekcję. Nie wyłapie błędu, do którego jest przekonany – bo przekonanie i uzasadnienie pochodzą z tego samego źródła. PASS znaczy „przeszło listę kontrolną”, nie „to prawda”.
– Dobór metody nie jest deterministyczny. Opiera się na opisach, nie na twardej regule. Da się to zmierzyć i poprawić, ale nie da się obiecać.
– Nie wiem jeszcze, czy wszystkie metody poprawiają wynik. Zmierzyłem, że się uruchamiają trafnie. Czy dają lepsze odpowiedzi niż ich brak – sprawdziłem dopiero dla kilku. Z 24 metod dziewięć powstało z realnego zdarzenia. Pozostałe piętnaście to na razie hipotezy o tym, jak pracuję.
Liczby (stan na 9 sierpnia 2026)
| Metody w systemie | 24 |
| W tym zrodzonych z realnej porażki | 9 |
| Wpisy w logu regresyjnym | 5 |
| Przypadki testowe | 53 |
| Fałszywe uruchomienia na prostych pytaniach (w testach) | 0% |
| Od pierwszej wersji do dnia spisania | 15 dni |
| Wersje | V2.0 → V2.2.0 |
| Lata historii zamknięte bez eksportu | 4 |
Pięć tez na koniec
1. Nie używam czatu do zadawania pytań. Używam wykonawcy, który ma skończyć robotę.
2. Poprawiam metodę, nie odpowiedź. Jedna korekta procesu jest warta stu poprawionych tekstów.
3. Tezę wnosi człowiek, rzemiosło wnosi model. Odwrotna kolejność produkuje treść, która już istnieje.
4. Zamknąłem cztery lata historii tam, skąd nie ma wyjścia, bo analiza porównała ceny i limity, a nie sprawdziła, czy da się wyjść. Teraz to obowiązkowy punkt kontroli.
5. Reguła zapisana w dokumentacji nie istnieje. Sprawdziłem – i tej najdroższej rzeczywiście nie było w systemie, choć wszystkie papiery mówiły, że jest.
Dokument opisuje stan na 9 sierpnia 2026. Wszystkie liczby są weryfikowalne w logu regresyjnym i dokumentacji architektury.