Bywają dni, gdy w głowie pojawia się prosta myśl: „To tylko drobny kawałek. Godzina, może dwie.” Mija jednak dzień, potem kolejny, aż nagle łapiesz się na tym, że ślęczysz nad poprawkami czegoś, co wydawało się banalne, a logi zaczynają przypominać powieść.
Ja się denerwuję. AI – z taktem – robi sobie przerwy w kontekście. Napięcie wisi w powietrzu, jakbyśmy nie poprawiali kodu, tylko prowadzili negocjacje pokojowe.
I właśnie wtedy na własnej skórze przekonujesz się o czymś mało poetyckim, lecz niezwykle prawdziwym: im więcej projektów i im większy ich stopień skomplikowania, tym szybciej pojawia się ryzyko błędu, którego nie da się „przepchnąć” samą determinacją. Nawet jeśli po drugiej stronie masz model, który potrafi napisać esej, kod, plan prezentacji i jeszcze poprosić o wodę z cytryną.
Powrót do starej metody sprzed dwóch dekad
Szukając wyjścia z tej ślepej uliczki, przypomniałem sobie Marcina Kosewskiego i lekcję sprzed… no, nazwijmy to „ponad dwudziestu lat”. Metoda Kepner-Tregoe. Klasyczne podejście do rozwiązywania problemów: logicznie, krok po kroku, bez czarów.
I poczułem ulgę. Nie dlatego, że błąd zniknął. Po prostu przestałem kręcić się w kółko.
Ta metoda narzuca porządek w myśleniu. Zamiast „napraw, bo nie działa”, pojawia się pytanie: „gdzie dokładnie nie działa, kiedy działa, a kiedy nie – i co to mówi o przyczynie”.
Brzmi nieco nudno? Może i tak. Ale działa zaskakująco często.
Prompt zamiast kolejnej apki
Oczywiście, pierwsza reakcja była typowa: „to napiszę aplikację”. A potem druga: „Bartek, nie rób tego.” Więc powstrzymałem się. Przynajmniej na razie.
Zamiast tego stworzyłem coś prostszego: prompt. Taki, który po dwóch nieudanych próbach naprawy tego samego błędu przełącza się w tryb „przestań zgadywać”. W skrócie:
najpierw solidna diagnoza, potem porównania w stylu „jest / nie jest”, następnie hipotezy i testy, które mają je potwierdzić lub obalić. A gdy pojawiają się sprzeczności („to musi być tak, a jednocześnie nie może być”), zamiast walczyć z rzeczywistością – szukasz obejścia na wzór TRIZ.
To był mój eksperyment z GPT-5.2 Thinking. I tak, dało się wyczuć zaskoczenie. Bo AI też docenia, gdy człowiek zamiast mówić „napraw to”, zaczyna mówić „sprawdźmy fakty”.
Co z tego wynikło (i dlaczego to ważne nie tylko dla informatyków)
Czy prompt rozwiązał mój problem bezpośrednio? Nie.
I w tym tkwi sedno: umożliwił mi (i AI) podjęcie jedynej rozsądnej decyzji – wycofać się ze ślepego zaułka i poszukać innego sposobu realizacji jednej z funkcji, zamiast bezsensownie przerabiać kod.
To nie tylko lekcja z programowania. To lekcja z komunikacji, zarządzania projektami, życia. Czasem „cisnąć” to tylko zwiększać tarcie. Niekiedy trzeba się cofnąć, by móc ruszyć naprzód.
Labs – narzędzia dla tych, którzy chcą po prostu wykonać zadanie
I tu pojawia się moje „przy okazji”: labs.trustedone.pl. To moje miejsce eksperymentów, gdzie tworzę narzędzia z myślą o ludziach zajmujących się PR i komunikacją. Nie po to, by każdy musiał zostać prompt-inżynierem. Chodzi o to, by szybciej i pewniej dostarczyć tekst, brief, odpowiedź czy analizę.
Znajdziesz tam aplikacje, które robią rzeczy zwyczajne, ale potrzebne: sprawdzają czytelność i gęstość treści, wskazują fragmenty, gdzie tekst staje się „ładny”, lecz traci konkret, pomagają tłumaczyć bez utraty sensu, porządkują materiały do publikacji. Bez korporacyjnego zadęcia. Z kontrolowanym chaosem, ale tylko w strukturze zdań, nie w logice.
A te dwie nowe aplikacje? Już kiełkują w mojej głowie i nie mogę się doczekać, by je napisać. Jedna ma pomóc „odczarować” tekst, by odbiorca zrozumiał go od razu. Druga ma skrócić drogę od „mam mnóstwo materiału” do „mam sensowną wersję do publikacji”. Szczegóły zostawiam za kulisami – najważniejsze, że to narzędzia do realnej pracy, nie do prezentacji technologii.
Beta-testy już trwają. Poprosiłem kilka osób, by sprawdziły je w praktyce: czy działają, czy nie irytują, czy rzeczywiście oszczędzają czas.
A ja wracam do mojego „prostego fragmentu”. Tyle że teraz z inną decyzją na stole. I z AI, które – mam wrażenie – też odetchnęło z ulgą.