Od zera do systemu AI w kwartał. Część 16: Własne skrypty.

W części 13 zastąpiliśmy abonamenty, których nie chcemy. W części 14 zbudowaliśmy pierwsze automatyzacje. W części 15 podłączyliśmy AI do narzędzi.

Masz infrastrukturę, masz integracje, masz automatyzacje. Ale czasem trafiasz na coś, czego żadne gotowe narzędzie ani workflow nie rozwiązuje.

Chcesz, żeby raz w tygodniu Twoje dane sprzedażowe z arkusza trafiały automatycznie do raportu PDF w firmowym stylu. Nie ma gotowego narzędzia. Każde, które się zbliża, pomija jakiś kluczowy szczegół.

Chcesz, żeby jeden skrypt zebrał o firmach informacje z pięciu źródeł naraz, sprawdził ich spójność i złożył z tego notatkę w formacie, który lubisz. Zero narzędzi robi dokładnie to.

To są momenty, w których potrzebujesz własnego skryptu. Kilka lat temu oznaczało to: albo uczysz się programować, albo płacisz programiście dwa tysiące za zadanie, które robiłeś ręcznie w godzinę dziennie.

Teraz jest inaczej. Opisujesz, co chcesz, AI pisze kod. Po jednym weekendzie masz narzędzie, które rozwiązuje Twój problem. Kilka pętli iteracji, bez linijki kodu napisanej własnoręcznie.

Ten artykuł o tym, jak taki proces wygląda w praktyce i gdzie są jego granice.

Zastrzeżenie: to co opisuję w tym cyklu bazuje na moim stacku technologicznym, czyli macOS i Claude jako główny model językowy. Zasady i podejście działają na każdym systemie operacyjnym i z każdym modelem AI, ale konkretne kroki i skróty klawiszowe opisuję pod Maca. Jeśli pracujesz na Windows lub Linux, większość rzeczy zrobisz tak samo, ale powyższe systemy mogą się różnić detalami, które musisz dostosować.

Ważne: opisuję tu model uproszczony, czyli idealny obraz tego, jak działa ten fragment systemu. W praktyce mój obecny system ma więcej warstw, wyjątków i automatyzacji. Na potrzeby tego cyklu pokazuję wersję, którą najłatwiej zrozumieć i odtworzyć u siebie.

Zasada: nie ucz się programować, ucz się rozmawiać z AI o kodzie

Dla wielu osób to mentalna bariera. “Nie potrafię programować, więc nie zbuduję skryptów.”

Punkt startu jest inny. Ty nie musisz umieć pisać kodu. Musisz umieć opisać, co kod ma robić. A to już robisz codziennie, nawet nie wiedząc.

Kiedy wypełniasz brief dla grafika, opisujesz efekt, nie sposób rysowania. Kiedy dyktujesz maila do asystenta, mówisz, co ma być w środku, nie jak ma wyglądać linia po linii. Praca z AI na kodzie działa tak samo.

Umiejętność, której się uczysz, to precyzyjny opis problemu. Im wyraźniej określisz, co chcesz osiągnąć, co na wejściu, co na wyjściu, tym lepszy skrypt dostaniesz od modelu.

To jest praktyczna zmiana paradygmatu. Programowanie dotąd wymagało znajomości składni. Teraz wymaga jasnego myślenia. Składnię zna AI.

Kiedy warto budować własny skrypt

Nie każda rzecz nadaje się na skrypt. Warto mieć prostą zasadę.

Skrypt ma sens, gdy spełnione są trzy warunki:

Raz: robisz to regularnie. Co tydzień, co miesiąc, przy każdym nowym kliencie. Jednorazowe zadania lepiej zrobić ręcznie.

Dwa: zadanie jest deterministyczne. To znaczy, że za każdym razem kroki są takie same. Pobierz dane z A, przetwórz według reguły B, zapisz do C. Jeśli za każdym razem potrzebujesz podejmować nowe decyzje, prosty skrypt nie pomoże.

Trzy: ręczne zrobienie tego zajmuje więcej niż pół godziny. Poniżej tego progu budowanie skryptu się nie opłaca, nawet jeśli AI pisze kod szybko. Testowanie, dokumentowanie, poprawki — to też czas.

Z mojej praktyki: mam własnych skryptów kilkaset i wszystkie wywołuję z jednego centralnego menu — jeden wpis w terminalu, lista pogrupowana, wybór numeru. Każdy rozwiązuje konkretny problem, z którym się spotykałem regularnie. Budowanie każdego zajmowało od godziny do dnia. Każdy oszczędza co najmniej godzinę tygodniowo.

To menu jest ważniejsze, niż wygląda, i długo tego nie doceniałem. Bez niego skrypt, którego nie użyjesz przez pół roku, przestaje istnieć — leży w katalogu, ale nie pamiętasz ani nazwy, ani tego, że go napisałeś. Wtedy piszesz go drugi raz. Jedno miejsce, z którego startuje wszystko, jest tanie do zrobienia i decyduje, czy Twoja biblioteka narzędzi rośnie, czy tylko puchnie.

Matematyka jest prosta: jeden godzinny skrypt, który oszczędza godzinę tygodniowo, zwraca się w pierwszym tygodniu. Potem to czysty zysk.

Typy skryptów, które najczęściej buduję

Z obserwacji własnego menu, kilka kategorii wraca regularnie.

Raportowanie. Pobierz dane z kilku narzędzi (Analytics, Search Console, arkusz finansowy), zsyntetyzuj w jeden dokument, opublikuj jako PDF lub mail. Raz w tygodniu albo raz w miesiąc.

Przetwarzanie plików. Mam kilkaset plików audio, chcę dostać transkrypcje z metadanymi. Mam arkusz w dziwnym formacie, chcę go zamienić na strukturę, która pasuje do mojego systemu. Konwersja z formatu A na format B.

Wzbogacanie danych. Mam listę firm (nazwa, NIP), chcę dla każdej pobrać z oficjalnych źródeł dane rejestracyjne, sprawdzić stronę firmową, zobaczyć w jakie kategorie wchodzą. Każde pojedynczo trwa pięć minut ręcznie. Skrypt robi setkę w dziesięć.

Synchronizacja między narzędziami. Dane w arkuszu → produkty w sklepie → stany magazynowe w systemie ERP. Zmiana w jednym miejscu propagowana do innych.

Analiza i klasyfikacja. Mam bazę tysiąca opisów produktów, chcę każdy sklasyfikować według konkretnych kryteriów. AI zamiast ręcznej pracy.

Każdy z tych przykładów to kilkadziesiąt do kilkuset linijek kodu. Dla programisty: kilka godzin. Dla mnie z AI: w zasadzie tyle, ile trwa ich testowanie.

Proces: od opisu do działającego skryptu

Pokażę, jak wygląda cykl iteracyjny, którym buduję skrypty.

Krok 1: opisz problem precyzyjnie. Przed otwarciem czatu z AI siadam i piszę w pliku, czego chcę. Nie do modelu. Dla siebie. Odpowiadam na pięć pytań:

Co robię teraz ręcznie?
Jakie dane mam na wejściu (pliki, formaty, źródła)?
Co chcę mieć na wyjściu (format, lokalizacja, struktura)?
Jakie są przypadki brzegowe (pusty plik, błędne dane, ograniczenia API)?
Jak będę testować, że skrypt działa poprawnie?

Pięć zdań, maksymalnie dziesięć. Bez tego skrypty wychodzą rozlazłe. Model radzi sobie z niedomówieniami, ale im mniej ich jest, tym lepiej.

Krok 2: daj modelowi pełny kontekst. Otwieram sesję z AI i wklejam mój opis. Dodaję: język, którego używam (u mnie najczęściej Node.js, rzadziej Python), lokalizację (skrypt trafi do DOKUMENTACJA/scripts/), jak uruchamiam (terminal, cron, menu). Im więcej kontekstu, tym mniej iteracji.

Krok 3: zgódz się na plan. Nie proszę od razu o kod. Proszę o plan:

Zanim napiszesz kod, opisz plan: z jakich modułów/bibliotek skorzystasz, jaka będzie struktura skryptu (funkcje, ich rola), jak obsłużysz błędy, jak zwalidujesz dane wejściowe. Poczekaj na moją akceptację, zanim zaczniesz pisać.

Na planie wyłapuję niezgodności. “Użyj modułu X” — w moim systemie używam Y. “Zapisz do pliku CSV” — chcę JSON. Poprawiam od razu, zanim AI napisze trzysta linii kodu, który trzeba wyrzucić.

Krok 4: przyjmij kod. Gdy plan jest OK, model pisze kod. Zwykle kilkaset linii. Kopiuję do pliku. Nie czytam wszystkiego. Patrzę tylko na strukturę: czy są funkcje, czy są komentarze, czy są testy.

Krok 5: uruchom i obserwuj. Testuję na małych danych. Jeden plik zamiast stu. Jedno zapytanie zamiast pętli. Jeśli działa, skaluję do pełnej próby. Jeśli nie, kopiuję błąd do sesji AI.

Krok 6: iteruj na błędach. Błąd → AI poprawia → uruchamiam ponownie. Zwykle dwa do pięciu cykli. Przy każdym skrypt staje się stabilniejszy.

Krok 7: udokumentuj. Gdy skrypt działa, proszę AI o prostą dokumentację. Co robi, jak uruchomić, jakie są parametry, jakie są typowe problemy. Trafia do komentarza na górze pliku i do dokumentacji systemu.

Cały cykl dla typowego skryptu: dwie godziny aktywnej pracy. Rozłożone na dzień lub dwa, bo testy często wymagają czasu (czekasz na API, na przetworzenie danych).

Wzorzec: jeden skrypt, wielu klientów

Pierwsza pułapka, której łatwo nie zauważyć: budujesz skrypt do konkretnego problemu konkretnego klienta. Wpisujesz na sztywno nazwy, identyfikatory, ścieżki. Działa. Pół roku później pojawia się drugi klient z podobnym zadaniem. Kopiujesz skrypt, podmieniasz piętnaście miejsc, modlisz się, że nic nie ominąłeś. Trzeci klient — ten sam ból. Po pięciu klientach masz pięć kopii podobnego kodu, wszystkie lekko różne, każda z drobnymi błędami w innym miejscu.

Lepsza strategia, którą wdrożyłem po kilku takich kopiach: każdy skrypt od pierwszego dnia pisany jako parametryzowalny. W praktyce wygląda to tak: jeden plik kodu, uruchamiany komendą z parametrem identyfikującym klienta. Wszystko, co specyficzne (klucze API, ścieżki, listy nazw, mapowania), wyciągnięte do osobnych plików konfiguracyjnych — po jednym dla każdego klienta. Skrypt wczytuje plik klienta na starcie i wie, co robić.

Efekt: nowy klient z podobnym zadaniem to nie nowy skrypt, tylko nowy plik konfiguracyjny. Kilka minut zamiast kilku godzin. Plus poprawka błędu trafia do jednego miejsca, działa od razu dla wszystkich klientów, nie pamiętasz o trzech kopiach.

Reguła: zanim zaczniesz pisać skrypt, zapytaj siebie “czy zrobię to drugi raz dla kogoś innego?”. Jeśli odpowiedź to “tak” albo “może”, od razu projektuj parametryzowalnie. Koszt inwestycji: jakieś 20% więcej czasu przy pierwszym skrypcie. Zwrot: setki godzin nieoszczędzonych przy dziesiątym wdrożeniu.

To samo dotyczy lokalizacji wyników. Outputy każdego skryptu trafiają do struktury per-klient w vault albo do osobnego folderu w Documents (jeśli to duże zrzuty danych). Nigdy do /tmp/ ani ~/Downloads/. Tam pliki znikają po restarcie albo gubią się w bałaganie. Zrzut danych, którego za tydzień nie znajdziesz, jest gorszy od nieistniejącego.

Co zyskujesz nad gotowymi narzędziami

Kilka rzeczy, które są trudne do zauważenia, dopóki sam nie przejdziesz tej drogi.

Dostosowanie do Twojego świata. Gotowe narzędzie obsługuje ogólny przypadek. Twój skrypt obsługuje dokładnie Twój. Nie walczysz z niepotrzebnymi polami, nie ignorujesz funkcji, których nie używasz. Jest dokładnie to, czego potrzebujesz, i tylko to.

Koszt. Gotowe narzędzie kosztuje miesięcznie. Skrypt kosztuje raz, w momencie budowy. Potem nic.

Brak uzależnienia od dostawcy. Gdy narzędzie zmienia cennik, wycofuje funkcję, jest kupowane przez większego gracza, masz problem. Twój skrypt trwa, dopóki działa API, z których korzysta. Jeśli jedno API znika, podmieniasz tę część.

Wiedza o własnym systemie. Każdy skrypt, który zbudujesz, zostawia Cię z głębszym rozumieniem, jak działają Twoje procesy. Nie tylko używasz narzędzi. Wiesz, co robią pod spodem.

Co tracisz

Uczciwie też trzeba powiedzieć, co odchodzi.

Świetny interfejs. Gotowe narzędzia mają często bardzo dopracowany design, animacje, pomocne podpowiedzi. Twój skrypt uruchamia się w terminalu. Brzydziej, mniej intuicyjnie dla nowego użytkownika.

Wsparcie. Gdy coś nie działa w gotowym narzędziu, piszesz do wsparcia technicznego. Gdy nie działa Twój skrypt, radzisz sobie sam (albo z pomocą AI).

Bezpieczeństwo. Gotowe narzędzia mają całe zespoły, które pilnują bezpieczeństwa danych. Ty masz siebie. Większość skryptów robi coś prostego, więc ryzyko jest niskie, ale świadomość tego warta.

Wniosek: nie buduj wszystkiego samodzielnie. Buduj to, gdzie zysk z dostosowania jest większy niż koszt utraty wsparcia.

Przykład konkretny: skrypt do raportu miesięcznego

Pokażę na jednym przykładzie, żeby oderwać to od teorii.

Problem: Raz w miesiącu siadam i składam raport dla każdego z moich projektów. Dane z Google Analytics, Search Console, reklam, arkusza finansowego. Przepisuję do jednego dokumentu. Zajmuje to cały dzień.

Cel: Skrypt, który uruchamiam komendą, dostaje numer miesiąca, pobiera dane z wszystkich źródeł dla wszystkich projektów, generuje jeden plik Markdown na każdy projekt, wysyła podsumowanie przez Slack.

Opis problemu (to co przygotowałem przed rozmową z AI):

Wejście: numer miesiąca (np. 04 dla kwietnia), rok (2026)
Dane: GA4 (ruch, konwersje), GSC (pozycje, kliknięcia), Google Ads (wydatki, wyniki), finanse z arkusza (przychód, koszty)
Wyjście: “n” plików Markdown w CONTENT/[projekt]/raporty/[rok]-[miesiąc].md
Powiadomienie: Slack z linkami do “n” raportów
Błędy: jeśli jedno ze źródeł nie odpowiada, pokaż co pobrało się udało, oznacz jako brakujące
Test: uruchom dla ostatniego miesiąca, sprawdź czy dane są spójne z panelami

Czas budowy z AI: cztery godziny rozłożone na dwa dni.

Czas uruchomienia miesięcznie: dwie minuty.

Oszczędność: cały dzień raz w miesiącu.

Zwrot inwestycji: w pierwszym miesiącu. Potem czysty zysk.

Taki sam proces zastosujesz do dowolnego innego zadania. Różni się tylko rodzaj danych i formatu wyjścia. Szkielet: “robię to regularnie”, “dane deterministyczne”, “ręczne zajmuje więcej niż pół godziny”. Reszta to iteracja z AI.

Czego unikać

Budowania skryptu przed zrozumieniem problemu. Najczęstszy błąd: idziesz do AI z ogólnym “pomóż mi zautomatyzować raporty”. Model pisze coś ogólnego. Ty próbujesz użyć, nie działa, frustracja. Najpierw dziesięć minut samemu z kartką, spisać dokładnie co i jak. Potem dopiero sesja z AI.

Ignorowania testów. AI pisze kod, który wygląda dobrze, ale może mieć subtelne błędy. Źle sformatowana data, literówka w nazwie pola API, przypadek brzegowy, o którym nie pomyślałeś. Zawsze uruchamiasz na małej próbie i weryfikujesz wynik ręcznie. Dopiero potem pełna skala.

Ufania skryptowi, który sprawdza. To jest podstęp, na który sam wpadłem kilka razy. Jeśli piszesz skrypt, który ma coś wykryć albo zablokować (walidator danych, sprawdzenie przed wysłaniem, alarm o błędzie), to jego dobry wynik nic nie znaczy, dopóki nie zobaczysz, że umie też dać zły. Uruchom go na danych celowo zepsutych. Jeśli nie “krzyknął”, nie masz zabezpieczenia, masz zabezpieczenie na niby. Potem uruchom go na danych poprawnych i sprawdź, czy milczy, bo strażnik, który krzyczy zawsze, zostanie wyłączony po trzecim fałszywym alarmie. Dwie minuty roboty. Bez nich „zero błędów” i „test nic nie mierzył” wyglądają identycznie.

Dopisywania funkcji “przy okazji”. Skrypt raportuje. Skrypt wysyła podsumowanie. “Przy okazji zrób jeszcze X i Y.” Każde dopisywanie zwiększa złożoność i ryzyko błędów. Lepiej drugi skrypt niż jeden wielki.

Nie dokumentowania. Za trzy miesiące nie pamiętasz, po co ten skrypt, jak go uruchomić, co robi krok po kroku. Dziesięć linii dokumentacji na górze pliku ratuje godziny rekonstrukcji.

Ignorowania pytania “czy to warto zbudować”. Nie każda rzecz, którą można zautomatyzować, powinna być zautomatyzowana. Jeśli koszt budowy jest większy od planowanej oszczędności, zostaw ręczne.

Pisania skryptów, które bez ostrzeżenia kasują dane. Pewne operacje wyglądają niewinnie, a robią szkody trudne do cofnięcia. Skrypt “konfiguracyjny”, który przy uruchomieniu zeruje pola w arkuszu. Skrypt synchronizujący, który “tylko aktualizuje”, a przy okazji nadpisuje brakujące dane pustkami. Funkcja “rotacja tokena”, która unieważnia stary używany w trzech innych miejscach. Reguła, którą wprowadziłem po jednym takim incydencie: każdy skrypt, który modyfikuje dane (własne lub klientów), w pierwszym kroku robi backup do osobnego folderu z datą. Bez tego nie wolno mu wykonać operacji. Backup jest tańszy niż utracona praca.

Czego nauczyłeś się na tym etapie?

Nie musisz umieć programować, żeby budować skrypty. Musisz umieć precyzyjnie opisać problem: wejście, wyjście, przypadki brzegowe.

Skrypt warto zbudować, gdy spełnione są trzy warunki: robisz to regularnie, zadanie jest deterministyczne, ręczne zrobienie zajmuje więcej niż pół godziny.

Proces iteracyjny ma siedem kroków: opisz problem, daj kontekst AI, zgódź się na plan przed kodem, przyjmij kod, uruchom i obserwuj, iteruj na błędach, udokumentuj. Dwie godziny aktywnej pracy.

Typy skryptów, które najczęściej wracają: raportowanie, przetwarzanie plików, wzbogacanie danych, synchronizacja między narzędziami, analiza i klasyfikacja.

Zyskujesz: dostosowanie do Twojego świata, oszczędność kosztów abonamentów, brak uzależnienia od dostawców, głębsze rozumienie własnego systemu.

Tracisz: ładny interfejs, wsparcie techniczne, część bezpieczeństwa. Buduj tam, gdzie zysk z dostosowania przewyższa koszt utraty wsparcia.

Skrypt, który ma coś wykryć albo zablokować, sprawdzasz z dwóch stron: na danych celowo zepsutych musi “krzyknąć”, na poprawnych musi milczeć. Bez tego „zero błędów” i „test nic nie mierzył” wyglądają identycznie.

W następnej części otwieramy blok piąty: bezpieczeństwo. Gdy masz dziesiątki automatyzacji, skryptów i integracji z narzędziami, pojawia się nowa odpowiedzialność. Jak chronić dane, które przez ten system przechodzą. Jak nie stracić wszystkiego w jedną noc.

Twój następny krok: zadanie na dzisiaj

Dwie rzeczy.

1. Wypisz pięć rzeczy, które robisz ręcznie regularnie. Zadania, które wracają co tydzień, co miesiąc, przy każdym kliencie. Przy każdym zapisz: jak często, ile czasu zajmuje, jakie dane na wejściu, jaki efekt na wyjściu. To Twoja lista kandydatów na skrypty.

2. Wybierz jednego kandydata i opisz problem precyzyjnie. Otwórz plik w vault i napisz opis według struktury: co robię teraz, dane na wejściu, dane na wyjściu, przypadki brzegowe, jak testować. Zostań na tym. Nie zaczynaj jeszcze sesji z AI. Plik z opisem leży w vault, otwierasz go jutro ze świeżą głową. To co wygląda na kompletny opis dziś, często ma luki, które widzisz dopiero po nocy.

Jutro wysyłasz opis do AI i prosisz o plan. Pojutrze masz skrypt.

Zasoby

Dokumentacja języków skryptowych — Node.js i Python mają doskonałe oficjalne tutoriale. Nie musisz się tego uczyć, żeby pracować z AI nad kodem. Ale sto linii dokumentacji wystarczy, żeby zrozumieć, co AI Ci pisze, i lepiej iterować.
Dokumentacja API narzędzi, których chcesz używać w skryptach — zacznij od sekcji “Authentication” (jak zalogować) i “Common endpoints” (co najczęściej się robi). Nie musisz czytać całości. Kieruj się konkretnym zadaniem.
Twoja własna lista pięciu rzeczy powtarzalnych — najcenniejszy dokument na tym etapie. Bez niej będziesz budować skrypty, bo “można”, zamiast dlatego że “potrzebuję”. Lista wydeptuje ścieżkę.

Ten artykuł jest częścią cyklu “Od zera do kompletnego systemu AI w kwartał”. Krok po kroku opisuję jak zbudowałem system AI do zarządzania firmą i rozwojem osobistym, żebyś mógł wdrożyć podobny u siebie. W następnej części: bezpieczeństwo systemu. Masz pytania? Napisz. Odpowiadam osobiście.

Żeby nie przegapić kolejnych części, zaobserwuj mój profil. Nowe artykuły publikuję regularnie.

Marcin Atamańczuk, Technologia w służbie życia, nie odwrotnie.