Narzędzia są wtórne. Cztery moje wpadki, które to udowodniły

Ten tekst powstał na podstawie fragmentu mojego wywiadu dla podcastu CMSConf, w którym rozmawiała ze mną Magdalena Magdziarz z CMS.com. To nie jest zapis całej rozmowy, tylko wątek z jej końcówki - rozbudowany o własne przemyślenia i przykłady, na które w podcaście nie było miejsca.

Magda zadała mi na koniec pytanie, na które większość ludzi odpowiada listą narzędzi: czego uczyć się dziś, żeby za 3-5 lat nie wypaść z obiegu.

Odpowiedziałem jednym słowem. Myślenie.

Brzmi jak coś, co się mówi, gdy nie ma się nic do powiedzenia. Więc zamiast to rozwijać w teorii, pokażę cztery sytuacje z ostatnich miesięcy, w których narzędzie działało bez zarzutu, a wysypałem się ja.

Z tego artykułu dowiesz się:

• dlaczego dobre narzędzie użyte do złego zadania kosztuje więcej niż złe narzędzie,
• czym różni się wynik poprawny od wyniku dobrego,
• co robić, gdy narzędzie, na którym stoisz, przestaje być rozwijane,
• dlaczego proces da się przenieść w godzinę, a przyzwyczajenia nie.

Wpadka 1: karuzela poprawna i całkowicie martwa

Mam skilla, który robi komiksy i memy z Wolnisiem. Postacie, kolory, styl rysowania - wszystko rozpisane w plikach tekstowych, budowane przez miesiące.

Ta sama Magda, która prowadziła ten wywiad, powiedziała mi wcześniej wprost: karuzele działają na socjalach lepiej niż komiksy. Rozbudowałem skilla o karuzele w 5-10 minut, bo 80% roboty było już zrobione.

Pierwszy test wyszedł poprawnie. Wolniś wyglądał jak Wolniś, kolorystyka się zgadzała, slajdy szły w logicznej kolejności.

I był kompletnie martwy. Każdy slajd to informacja podana bez zarzutu, bez cienia dramaturgii. Dokładnie to samo, co robi połowa Instagrama.

AI wykonała dokładnie to, o co poprosiłem. Problem był w tym, o co poprosiłem - nigdzie nie zaprojektowałem napięcia między pierwszym a ostatnim kadrem. Cały cykl iteracji opisałem tutaj.

To jest różnica, której żadne narzędzie za ciebie nie wypełni: poprawnie i dobrze to dwie różne rzeczy, a modelowi trzeba powiedzieć, o którą ci chodzi.

Wpadka 2: postawiłem kilka stron na Gatsbym

Gatsby był wtedy oczywistym wyborem. Generator stron statycznych z ekosystemem wtyczek, o którym mówiło się na każdej konferencji frontendowej. Postawiłem na nim kilka serwisów.

Dziś z tego nie zostało nic.

Liczby są bezlitosne. Ostatnie duże wydanie, Gatsby 5, wyszło w listopadzie 2022. W lutym 2023 projekt kupił Netlify i w ciągu kilku miesięcy rozeszła się większość zespołu. We wrześniu 2023 zamknęli Gatsby Cloud, czyli ich własny hosting. Pobrania z npm spadły z około 450 tysięcy tygodniowo na początku 2023 do jakichś 120 tysięcy pod koniec 2025. Astro w tym samym czasie przebiło 400 tysięcy.

Framework formalnie żyje, dokumentacja stoi, repozytorium dostaje sporadyczne commity. Tylko ekosystem wtyczek - czyli dokładnie to, po co się Gatsby'ego brało - jest w większości nieutrzymywany od lat.

Nie popełniłem błędu technicznego. Wybrałem narzędzie, które w tamtym momencie było najlepsze w swojej klasie. Popełniłem błąd w rachunku ryzyka: nie zapytałem, co się stanie z moimi stronami, jeśli za dwa lata ktoś kupi ten projekt i straci nim zainteresowanie.

Klienci nie chcą słuchać, że framework przestał być rozwijany. Chcą działającą stronę.

Przesiadka na Astro, czyli to samo zadanie innym silnikiem

Gatsby i Astro robią w gruncie rzeczy to samo: biorą twoje treści i wypluwają gotowe pliki HTML, które wrzucasz na serwer. Nie ma bazy danych, nie ma PHP, nie ma czego zhakować. Różnica siedzi w wykonaniu.

Gatsby wszystko przepuszczał przez React i własną warstwę zapytań GraphQL. Nawet żeby wyciągnąć listę wpisów z plików markdown na dysku, pisałeś zapytanie. Do tego każda strona ładowała w przeglądarce Reacta, nawet jeśli była zwykłym tekstem.

Astro odwraca kolejność: domyślnie wysyła czysty HTML i zero JavaScriptu, a interaktywność dokładasz tylko tam, gdzie jest potrzebna. Treść czyta wprost z plików markdown, bez pośredników.

I tu jest cała pointa tego akapitu: przesiadka nie bolała tak, jak powinna. Treść siedziała w plikach markdown na dysku, a nie w bazie danych ani w formacie zamkniętym przez dostawcę. Do wymiany był silnik i szablony, nie materiał.

Gdybym te same teksty trzymał wewnątrz jakiegoś panelu w chmurze, którego twórcy też stracili zainteresowanie, rozmawialibyśmy o zupełnie innym rachunku. Dlaczego przy okazji wyrzuciłem też WordPressa, opisałem osobno.

Wpadka 3: postawiłem na cudze API

Marzec 2023. Twitter zamyka darmowe API i wchodzi z cennikiem od stu dolarów miesięcznie.

Moje automatyzacje, które monitorowały, co się dzieje w branży, padły w jeden dzień. Nie było w nich żadnego błędu. Zmienił się cudzy model biznesowy.

Nie zawiodła jakość roboty. Zawiodło założenie, że skoro coś jest darmowe od lat, to będzie darmowe dalej.

Dzisiaj te same dane zbieram przez Apify, gdzie pozyskanie porcji informacji kosztuje jednego, dwa centy. Rozwiązanie działa, ale nie o to chodzi - chodzi o to, że gdyby proces był opisany tylko wewnątrz workflow n8n, przepisywałbym go od zera. Był opisany osobno, więc podmieniłem źródło danych i pojechałem dalej.

Wniosek na przyszłość jest brutalnie prosty: jeśli twój proces stoi na cudzym API, to nie jest twój proces. Masz go w dzierżawie.

Wpadka 4: siedzę na przeglądarce, którą twórcy porzucili

Tu muszę przyznać się do niekonsekwencji, bo łatwo się głosi zasady, których się samemu nie trzyma.

Na co dzień pracuję na przeglądarce ARC. Ma system profili, dzięki któremu jednym przełącznikiem zmieniam cały kontekst - uczelnia, jeden klient, drugi klient, rzeczy prywatne. Osobne zakładki, osobne konta, osobna konfiguracja.

ARC nie jest już rozwijany.

I wiesz co? Nie przesiadam się. Utrzymuję to, co mam, bo działa i nikt w tym momencie nie daje mi nic więcej. Zen Browser idzie w tę stronę i być może kiedyś dojdzie do poziomu ARC - wtedy się przeniosę. Dziś przesiadka byłaby czystym kosztem bez zysku.

To nie jest wymówka, tylko decyzja z otwartymi oczami. Wiem, że rachunek przyjdzie: kiedyś nowa wersja systemu coś rozwali albo pojawi się dziura, której nikt nie załata. Różnica polega na tym, że mam to policzone, a nie że o tym nie myślę.

Świadome siedzenie na porzuconym narzędziu i nieświadome siedzenie na nim to dwie zupełnie inne sytuacje. Pierwsza to wybór. Druga to bomba z opóźnionym zapłonem w projekcie klienta.

Co zostaje, kiedy narzędzie znika

Skoro cztery razy się wyłożyłem, to teraz część praktyczna: co realnie chroni robotę, gdy narzędzie się kończy.

Sklep, 30 tysięcy produktów, aktualizacja cen. W n8n leciało to pętlą, produkt po produkcie, każdy obrót z narzutem całego silnika. Wziąłem JSON tego workflow, wrzuciłem do Claude Code, wyszedł skrypt w Pythonie. Zweryfikowałem, zmienne wyciągnąłem do osobnego pliku konfiguracyjnego, wrzuciłem w cron.

Przeniesienie zajęło chwilę. Nie dlatego, że jestem szybki, tylko dlatego, że proces był zaprojektowany osobno od silnika. Zmienił się wykonawca, nie logika.

Dokładnie to samo mówiłem Magdzie o CMS-ach. WordPress może dziś być, a za rok wejdzie coś, co go zaorze. Jeśli umiesz tylko WordPressa, zostajesz z umiejętnością obsługi czegoś, czego nikt nie używa. Jeśli rozumiesz przebieg informacji - kto dodaje treść, gdzie ona leży, jak trafia do odbiorcy, kto to zatwierdza - to czy pod spodem stoi WordPress, Astro, czy cokolwiek innego, przestaje mieć znaczenie. Sam wymieniłem WordPressa na Astro i proces publikacji przeżył tę zmianę bez zadrapania.

Myślenie, które da się zapisać jako zasada

Największy zarzut wobec „ucz się myśleć" jest taki, że tego nie da się wykonać. Zgoda - dopóki zostaje hasłem.

Da się, jeśli zamienisz je w regułę, którą stosujesz przed wyborem narzędzia. Moja, wypracowana na agentach AI, brzmi tak: agent tylko tam, gdzie logiki nie da się napisać ifami, i zawsze z outputem, który da się zweryfikować.

To jedno zdanie odsiewa większość pomysłów, zanim wydam na nie tydzień. Nie mówi mi, którego dostawcy użyć. Mówi mi, czy problem w ogóle nadaje się do tego typu rozwiązania.

Testowałem to wielokrotnie: reguła przeżywa narzędzia, do których powstała.

Podsumowanie

• narzędzie użyte do złego typu zadania kosztuje więcej niż słabsze narzędzie użyte właściwie,
• poprawny wynik i dobry wynik to dwie różne rzeczy - modelowi trzeba powiedzieć, o którą chodzi,
• proces opisany osobno od silnika przenosisz w godzinę, proces zaszyty w narzędziu przepisujesz od zera,
• jeśli stoisz na cudzym API albo na porzuconym programie, miej to policzone, a nie przemilczane,
• za 5 lat nie wypadniesz z obiegu przez to, że nie znałeś nowego narzędzia. Wypadniesz, jeśli nie umiałeś zaprojektować i zweryfikować tego, co ono wypluło.

W listopadzie prowadzę na CMSConf warsztat o tworzeniu treści do internetu z AI. Będzie dokładnie o tym: nie o klikaniu w konkretny program, tylko o poukładaniu procesu tak, żeby przeżył kolejną modę.

P.S. Najzabawniejsze w tej całej historii jest to, że dwie z czterech wpadek zawdzięczam rozmowie z Magdą. Raz podpowiedziała mi format, o którym nie miałem pojęcia, a raz zadała pytanie, przez które musiałem policzyć własne błędy. To jest ten argument za konferencjami, którego nie znajdziesz w agendzie - najwięcej wynoszę z rozmów przy kawie, nie z sali.

Damian Ślimak. Twój Nawigator w chaosie AI.