Wróć do bloga
Case Study

Automatyzacje AI w praktyce: 23 projekty zbudowane przez kursantów

Audytor monitoruje transakcje insiderów na GPW w 8 sekund dziennie. Automatyzacja dla obiektów noclegowych wysyła gościom spersonalizowane listy atrakcji, zanim zdążą zapytać. Prawniczka bez doświadczenia w kodzie zbudowała RAG na 10 GB polskich ustaw. Sześć różnych branż, jeden kurs – i sześć projektów, które ich autorzy zbudowali sami.

11 min czytania
case study, n8n, Claude Code, automatyzacja, agenci AI
Automatyzacje AI w praktyce: 23 projekty zbudowane przez kursantów

Najłatwiej mówić o automatyzacji na przykładach, które brzmią efektownie: agent AI, workflow w n8n, własny system w Claude Code. Tyle że dopóki nie wiadomo, jaki konkretny problem taki system rozwiązuje, trudno ocenić, czy naprawdę ma sens.

Dlatego w tym artykule nie pokazujemy przykładowych projektów zrobionych „pod kurs”. Zebraliśmy sześć rozwiązań, które uczestnicy naszych programów stworzyli dla siebie i swojej pracy. Każde powstało w innej branży, bo każda z tych osób zaczynała od innego problemu.

Kamil chciał przestać ręcznie śledzić transakcje insiderów na giełdzie. Katarzyna stworzyła automatyzację, która wyszukuje atrakcje dla gości obiektów noclegowych, zamiast robić to ręcznie za każdym razem. Jan zna od podszewki pracę w supporcie i wiedział, ile czasu pochłania samo czytanie, porządkowanie i ocenianie zgłoszeń. Jarek zbudował własny system do organizowania wiedzy, zadań i decyzji. W firmie fotowoltaicznej powstał kalkulator wycen i system selekcji przetargów. Z kolei prawniczka bez wcześniejszego doświadczenia w programowaniu stworzyła system do pracy na 10 GB polskich ustaw.

6
różnych branż – od giełdy po prawo
8 sek
codzienny monitoring insiderów na GPW
10 GB
polskich ustaw w systemie RAG
0
doświadczenia w kodzie przed kursem (dwie osoby)

To sześć zupełnie różnych projektów, ale warto przyjrzeć się im razem. Dobrze pokazują, jak wygląda automatyzacja wtedy, gdy nie zaczynasz od narzędzia, tylko od konkretnej pracy, której chcesz robić mniej, szybciej albo po prostu lepiej.

Giełda: z 15–20 minut dziennie do 8 sekund

„Osiem sekund. Tyle dziś trwa coś, co wcześniej zabierało mi piętnaście-dwadzieścia minut dziennie.”

Tak Kamil opisał na LinkedInie system, który zbudował dla siebie. Nie prosiliśmy go o opinię ani o przygotowanie case study. Po prostu uznał, że warto pokazać efekt swojej pracy, i podał konkretne liczby.

Post na LinkedIn o systemie do monitorowania transakcji insiderów na GPW i NewConnect

Kamil od dziesięciu lat zajmuje się audytem i zarządzaniem ryzykiem. Jednym z procesów, które wcześniej wykonywał ręcznie, było śledzenie transakcji insiderów, czyli m.in. zakupów i sprzedaży akcji dokonywanych przez prezesów oraz członków zarządów spółek.

Dla niego te informacje są istotne z prostego powodu:

„Prezes kupujący akcje za własne pieniądze wie o spółce więcej niż jakikolwiek analityk z zewnątrz.”

Same dane nie są ukryte. Spółki mają obowiązek publikować informacje o takich transakcjach zgodnie z art. 19 MAR. Problem pojawia się gdzie indziej: komunikaty o transakcjach trafiają do tego samego strumienia co wiele innych informacji giełdowych i są publikowane o różnych porach. Jeśli ktoś chce je regularnie śledzić, musi codziennie przeglądać komunikaty i wyłapywać z nich te, które rzeczywiście go interesują.

Kamil wcześniej poświęcał na to około 15–20 minut dziennie. Zamiast dalej robić to ręcznie, zbudował workflow w n8n składający się z 15 node'ów. Po zakończeniu sesji giełdowej system sam sprawdza, czy na GPW i NewConnect pojawiły się nowe transakcje osób zarządzających spółkami.

Przy projektowaniu automatyzacji Kamil wykorzystał zasady, które zna z audytu i zarządzania ryzykiem. Pierwsza dotyczy liczb.

„Model językowy odpowiada za język, nie za liczby. Parser jest w całości deterministyczny. Zero ryzyka, że AI zmyśli liczbę, na której ktoś oprze decyzję inwestycyjną.”

To oznacza, że model AI nie dostaje zadania obliczania ani interpretowania wartości liczbowych tam, gdzie pomyłka mogłaby mieć realne konsekwencje. Liczby obsługuje przewidywalny parser, a AI zajmuje się tym, do czego nadaje się lepiej, czyli pracą z językiem.

Druga zasada dotyczy raportowania.

„Cisza to zła forma raportowania. System wysyła maila nawet wtedy, gdy nie ma nowych transakcji, bo brak wiadomości i awaria wyglądają z zewnątrz identycznie.”

Gdyby system wysyłał wiadomość tylko po wykryciu transakcji, Kamil nie wiedziałby, czy brak maila oznacza spokojny dzień na rynku, czy awarię workflow. Dlatego raport przychodzi zawsze.

28 lipca system wykrył dziewięć nowych transakcji: osiem na GPW i jedną na NewConnect. Największa miała wartość 8,13 mln zł. Cały proces zajął osiem sekund, a utrzymanie automatyzacji kosztuje grosze miesięcznie.

15
node'ów w workflow n8n
8 sek
czas wykonania całego raportu
8,13 mln zł
wartość największej transakcji 28 lipca
grosze/mies.
koszt utrzymania automatyzacji

Noclegi: gość dostaje podpowiedzi jeszcze przed przyjazdem

Katarzyna stworzyła automatyzację, która jest nieocenioną pomocą dla obiektów noclegowych. Już nie muszą wyszukiwać informacji, żeby odpowiadać na dziesiątki małych zapytań tygodniowo.

Goście chcą wiedzieć, co warto zobaczyć w okolicy, gdzie pojechać przy dobrej pogodzie, co można zrobić, kiedy pada, jakie wydarzenia odbywają się podczas ich pobytu albo jakie atrakcje będą odpowiednie dla konkretnego typu wyjazdu.

Każde z tych pytań jest rozsądne. Kłopot zaczyna się wtedy, gdy właściciel obiektu po raz kolejny wyszukuje podobne informacje, sprawdza pogodę, przekleja linki i układa z nich wiadomość dla następnej osoby.

Katarzyna postanowiła przenieść dużą część tej pracy do automatyzacji.

„Zero researchu. Zero kopiowania tych samych informacji. System działa w tle, zanim jeszcze wypijesz kawę.”

Zbudowany przez nią agent codziennie o 9:00 sprawdza kalendarz rezerwacji. Obecnie korzysta z danych z Hotresu, ale sama integracja została przygotowana tak, żeby można ją było podłączyć również do innego systemu rezerwacyjnego.

1

Rezerwacja za 3 dni

Agent codziennie o 9:00 sprawdza kalendarz i wyłapuje gości przyjeżdżających w ciągu 3 dni.

2

Pogoda i wydarzenia

Pobiera prognozę z Open-Meteo i sprawdza aktualne wydarzenia turystyczne w okolicy.

3

Język gościa

Rozpoznaje, w jakim języku napisać wiadomość – po polsku, czesku albo angielsku.

4

Draft do akceptacji

Przygotowuje wersję roboczą w Gmailu i wysyła powiadomienie na Telegramie – nic nie idzie bez kliknięcia.

Kalendarz rezerwacji Hotres podłączony do agenta AI – system wie, kto i na jak długo przyjeżdża

Jeżeli agent znajdzie rezerwację rozpoczynającą się za trzy dni, uruchamia kolejne kroki. Pobiera prognozę pogody z Open-Meteo, sprawdza aktualne wydarzenia turystyczne w okolicy i wybiera informacje pasujące do terminu pobytu. Rozpoznaje też język, w którym powinna powstać wiadomość, dzięki czemu może przygotować ją na przykład po polsku, czesku albo angielsku.

W jednym z przykładów system przygotował mail dla Anny, która planowała czterodniowy pobyt w połowie sierpnia. Wiadomość zawierała prognozę na konkretne dni oraz propozycje dla pary, która lubi spokojne zwiedzanie i chce unikać tłumów.

Ten sam draft wygenerowany po polsku i po czesku – agent sam wykrywa język gościa

Do takiej wiadomości można również dołączyć ofertę samego obiektu, na przykład masaż, spa czy saunę. Dzięki temu automatyzacja nie tylko oszczędza czas potrzebny na przygotowanie rekomendacji, ale może też pomóc w sprzedaży dodatkowych usług.

Katarzyna celowo nie oddała jednak agentowi całego procesu. System przygotowuje wersję roboczą wiadomości w Gmailu, a następnie wysyła jej powiadomienie na Telegramie. To ona sprawdza treść i decyduje, czy mail może zostać wysłany.

Podobnie rozwiązano kwestię danych osobowych. Imiona i adresy e-mail są zamieniane na tokeny, zanim treść trafi do modelu AI. Dzięki temu agent może przygotować wiadomość na podstawie potrzebnych informacji, ale nie musi przetwarzać oryginalnych danych gościa.

Imiona i adresy e-mail gości zamieniane na tokeny, zanim tekst trafi do modelu AI

Obsługa klienta: agent, który potrafi przekazać sprawę człowiekowi

Jan przez wiele lat pracował w zespołach supportu, więc dobrze zna proces obsługi zgłoszeń od środka.

„W obsłudze klienta duża część zgłoszeń jest powtarzalna, ale każde z nich nadal musi zostać przeczytane, sklasyfikowane i obsłużone przez człowieka. Przy większej liczbie zgłoszeń oznacza to dużo ręcznej pracy, dłuższy czas odpowiedzi i ryzyko, że pilne problemy nie zostaną odpowiednio szybko zauważone.”

Właśnie z tego problemu powstał Support Pilot.

System analizuje nowe zgłoszenie, rozpoznaje jego kategorię, określa priorytet, ocenia sentyment klienta i przygotowuje propozycję odpowiedzi. To jednak nie generowanie tekstu jest w tym projekcie najważniejsze.

Jan chciał przede wszystkim rozwiązać problem selekcji: które sprawy rzeczywiście mogą przejść dalej automatycznie, a które powinien zobaczyć człowiek?

Dlatego oddzielił generowanie odpowiedzi od warstwy decyzyjnej. Model nie dostaje po prostu polecenia „odpowiedz klientowi”. Najpierw ma ocenić konkretne elementy zgłoszenia i zwrócić wynik w ustalonym formacie. Dopiero na podstawie tych danych system decyduje, co zrobić dalej.

1

Zgłoszenie klienta

Trafia do modelu z instrukcją oceny konkretnych wymiarów sprawy – nie prośbą o dowolną odpowiedź.

2

Analiza AI

Kategoria, priorytet, sentyment i sugerowana odpowiedź w wymuszonym, ustalonym formacie.

3

Warstwa decyzyjna

Osobny krok ocenia, czy sprawa jest krytyczna albo niepewna.

4

Automatycznie albo do człowieka

Rutynowe sprawy idą dalej same. Krytyczne i niepewne trafiają do statusu „human review”.

Jeśli sprawa jest krytyczna albo sam model ocenia swoją odpowiedź jako niepewną, zgłoszenie trafia do statusu „human review”. Wtedy automatyzacja nie próbuje na siłę doprowadzić procesu do końca, tylko przekazuje go człowiekowi.

W wersji demonstracyjnej Jan pokazał zgłoszenie dotyczące zawieszającej się aplikacji. Agent zaklasyfikował problem, nadał mu priorytet, określił sentyment klienta, streścił zgłoszenie i przygotował proponowaną odpowiedź. Podał również poziom pewności swojej oceny i rekomendację dotyczącą kolejnego kroku.

W tym przypadku uznał, że sprawę powinien przejąć pracownik supportu, ponieważ trzeba było dopytać klienta o dodatkowe szczegóły.

„Support Pilot nie zastępuje supportu. Pozwala supportowi skupić się na tym, co naprawdę wymaga człowieka.”

To dobrze pokazuje założenie całego projektu. Celem nie było usunięcie człowieka z obsługi klienta, tylko ograniczenie czasu, który zespół traci na czynności możliwe do wykonania wcześniej przez system.

Drugi mózg: własny system zamiast kolejnej aplikacji do notatek

Jarek na co dzień jest elektrykiem. Swój wpis na LinkedInie zaczął od zdania:

„Jestem elektrykiem. Przez ostatnie miesiące zbudowałem własny drugi mózg w Claude Code.”

Post na LinkedIn o własnym systemie drugiego mózgu zbudowanym w Claude Code

Chodzi o system, który pomaga mu przechowywać informacje, porządkować projekty, wracać do wcześniejszych decyzji i regularnie podsumowywać własną pracę. Jarek nie zbudował go jednak w Notion ani Obsidianie. Oparł całość na plikach Markdown i Claude Code.

Jednym z głównych problemów przy zwykłej rozmowie z AI jest to, że kontekst łatwo się rozprasza między kolejnymi sesjami. Jarek chciał mieć środowisko, które będzie przechowywało najważniejsze informacje w uporządkowany sposób i pozwoli mu do nich regularnie wracać.

Dlatego folder core/ pełni w jego systemie funkcję długoterminowej pamięci. Znajdują się tam informacje o jego celach, projektach, kontaktach i innych obszarach, które powinny być dostępne również podczas kolejnych sesji.

Do tego stworzył 16 własnych komend uruchamiających retrospektywy tygodniowe, miesięczne, kwartalne i roczne. Nie musi za każdym razem przygotowywać pytań i zbierać materiałów od początku. Uruchamia odpowiednią komendę, a system korzysta z informacji, które zostały zapisane wcześniej.

W jego rozwiązaniu działa również sześciu wirtualnych mentorów AI. Każdy analizuje decyzje z nieco innej perspektywy, dzięki czemu Jarek może skonfrontować kilka sposobów patrzenia na ten sam problem, zanim sam zdecyduje, co zrobić.

16
komend uruchamiających retrospektywy
6
wirtualnych mentorów AI
5
ekranów aplikacji zbudowanej w jednej sesji

Kolejna automatyzacja łączy wiadomość głosową na Telegramie, n8n i Asanę. Jarek może nagrać wiadomość głosową, n8n ją transkrybuje, a na podstawie treści w Asanie powstaje odpowiednie zadanie. Dzięki temu nie musi po rozmowie ze sobą samym jeszcze raz otwierać systemu zadań i przepisywać do niego tego, co właśnie powiedział.

Podczas jednej z sesji wykorzystał również to środowisko do zbudowania aplikacji mobilnej w React Native. Powstała aplikacja z pięcioma ekranami, która umożliwia m.in. śledzenie nawodnienia i nawyków, prowadzenie dziennika oraz obsługę powiadomień push.

„Kurs StormIT zmienił sposób, w jaki myślę o narzędziach. To nie jest projekt do portfolio. To moje codzienne środowisko pracy.”

W jego przypadku najważniejszy okazał się właśnie ten ostatni element. Nie chodziło o stworzenie projektu tylko po to, żeby przećwiczyć Claude Code. Jarek zbudował system pod własny sposób pracy, a później zaczął z niego normalnie korzystać.

Fotowoltaika: dane z formularza zamieniają się w gotową ofertę

Kolejny projekt powstał w firmie zajmującej się m.in. fotowoltaiką, magazynami energii i klimatyzacją.

Jej współwłaściciel skończył technikum informatyczne 25 lat wcześniej, ale od tamtego czasu nie programował. Nie zaczynał więc kursu z zamiarem powrotu do kodowania ani przebranżowienia się na programistę.

Chciał przede wszystkim rozumieć, jak działają nowe narzędzia, żeby móc świadomie wykorzystywać je w swojej firmie.

„Zastanawiałem się nad tym, rozmawiałem z prowadzącym. Chciałbym trochę wiedzieć, o co chodzi. Chciałbym to kontrolować i myślę, że jak poznam strukturę i mechanizmy, to znajdę też mnóstwo nowych opcji.”

Jednym z procesów, które nadawały się do usprawnienia, było przygotowywanie wycen instalacji PV.

W firmie powstał więc kalkulator, w którym handlowiec podaje potrzebne informacje, m.in. rodzaj falownika, typ instalacji i lokalizację. Te dane trafiają następnie do n8n, gdzie rozpoczyna się dalsza część procesu.

1

Formularz handlowca

Rodzaj falownika, typ instalacji, lokalizacja – dane trafiają do n8n.

2

Logika cennikowa

System liczy ofertę według kategorii produktu: PV, magazyn energii, klimatyzacja.

3

Cztery wyjścia naraz

PDF z ofertą, e-mail do klienta, powiadomienie na Telegramie do właściciela, wpis do arkusza.

Na podstawie formularza system przygotowuje PDF z ofertą, wysyła wiadomość do klienta, przesyła właścicielowi firmy powiadomienie na Telegramie i zapisuje dane w arkuszu. Logika kalkulatora uwzględnia różne kategorie produktów, m.in. instalacje fotowoltaiczne, magazyny energii i klimatyzację.

Ważne jest też to, że nie pozostał to projekt szkoleniowy. Kalkulator działa obecnie w firmie i korzystają z niego handlowcy.

Później powstał jeszcze agregator przetargów. Tutaj problem był inny: nie każdemu ogłoszeniu warto poświęcać tyle samo czasu, ale ktoś musi je najpierw przejrzeć, żeby dojść do takiego wniosku.

System wykonuje więc wstępną selekcję. AI ocenia przetargi w skali od 1 do 5, biorąc pod uwagę wartość kontraktu, wymagania techniczne oraz odległość od siedziby firmy. Dzięki temu handlowcy mogą zacząć od tych ofert, które mają większą szansę być dla firmy interesujące, zamiast po kolei analizować wszystkie.

„Generalnie to ja zmierzam do tego, żeby jak najwięcej swojej pracy zautomatyzować, dojść do tego, że w sumie jest to tylko rozmowa, a reszta dzieje się już w tle sama.”

Co ważne, odzyskanego czasu nie chce przeznaczać na dokładanie sobie kolejnej pracy.

„Chciałbym mieć czas dla siebie, nie szukam tu kolejnych zleceń i jakiejś pracy dodatkowej.”

W tym przypadku automatyzacja ma więc bardzo konkretny cel: firma ma działać sprawniej, ale właściciel nie chce dzięki temu tylko zwiększać liczby zadań, które jest w stanie zmieścić w ciągu dnia. Chce po prostu mniej czasu poświęcać na pracę, którą może wykonać system.

Prawo: od braku doświadczenia z kodem do RAG-u na 10 GB ustaw

Ostatni projekt stworzyła prawniczka z wykształcenia, która zawodowo pracuje jako analityczka finansowa. Przed rozpoczęciem kursu nie miała doświadczenia programistycznego.

Nie zaczęła więc od rozbudowanego doświadczenia technicznego. W trakcie nauki po raz pierwszy napisała kod w Pythonie, a później wykorzystała go przy kolejnych projektach.

Jednym z nich był RAG oparty na około 10 GB polskich ustaw z Dziennika Ustaw. System korzysta z Bielika, czyli polskiego modelu językowego uruchamianego lokalnie. Dzięki temu dokumenty nie muszą być wysyłane do zewnętrznej chmury.

10 GB
polskich ustaw z Dziennika Ustaw
0
doświadczenia programistycznego przed kursem
lokalnie
Bielik – żadne dane nie trafiają do chmury

Największym problemem technicznym okazało się nie samo uruchomienie modelu, ale przygotowanie dokumentów w taki sposób, żeby system potrafił je później sensownie przeszukiwać. Długich aktów prawnych nie można po prostu wrzucić do jednego zbioru i liczyć na to, że model zawsze znajdzie właściwy fragment.

Dlatego potrzebny był odpowiedni chunking, czyli podział dokumentów na mniejsze części. Trzeba było zdecydować, gdzie taki fragment powinien się zaczynać i kończyć, żeby z jednej strony nie był zbyt duży, a z drugiej nie tracił potrzebnego kontekstu.

Poza systemem RAG powstała także analiza tonu dokumentów napisana w Pythonie oraz workflow, który przenosi notatki z Telegrama do Kalendarza Google.

Swoje podejście do nauki i kolejnych problemów podsumowała prostym zdaniem:

„Jak mamy powiesić firanki, to trzeba umyć okno.”

W praktyce oznaczało to, że kiedy po drodze pojawiała się rzecz, której jeszcze nie potrafiła zrobić, traktowała ją jako kolejny element potrzebny do osiągnięcia właściwego celu, a nie jako powód, żeby projekt odłożyć.

Sam cel również nie polegał na tym, żeby zostać programistką.

„Docelowo wolałabym być kimś, kto na wzór tego, co robiłam dotychczas, czyli analizy, bardziej doradzać, co można wdrożyć i współpracować z zespołem.”

Chodziło więc o połączenie tego, co już potrafiła zawodowo, z możliwością lepszego rozumienia narzędzi AI i automatyzacji. Dzięki temu może nie tylko analizować problem biznesowy, ale też lepiej oceniać, jakie rozwiązanie techniczne da się zastosować i jak powinno ono działać.

Co łączy te projekty?

Na poziomie technicznym niewiele. System do monitorowania GPW działa inaczej niż agent dla pensjonatu, ten z kolei rozwiązuje zupełnie inny problem niż RAG na ustawach czy kalkulator wycen dla firmy fotowoltaicznej.

Wspólny jest natomiast punkt wyjścia.

Każda z tych osób zaczęła od problemu, który naprawdę występował w jej pracy albo codziennym sposobie działania. Nie budowała automatyzacji tylko dlatego, że akurat nauczyła się nowego narzędzia i chciała znaleźć dla niego jakieś zastosowanie.

Kamil wiedział, że codziennie traci kilkanaście minut na przeglądanie danych giełdowych, które da się zebrać automatycznie. Katarzyna wiedziała, ile czasu obiekty noclegowe tracą na przygotowywanie podobnych informacji dla kolejnych gości. Jan znał skalę ręcznej pracy potrzebnej do wstępnej obsługi zgłoszeń. W firmie fotowoltaicznej czas zabierało przygotowywanie ofert i selekcja przetargów.

Najpierw był konkretny proces. Dopiero później pojawiało się pytanie, które jego elementy warto oddać automatyzacji.

Powtarza się jeszcze jedna rzecz: w kilku projektach ich autorzy świadomie zdecydowali, czego AI nie powinno robić samodzielnie.

ProjektCo robi AIKto albo co decyduje
GiełdaRozpoznaje język komunikatówDeterministyczny parser liczy wartości
NoclegiPisze draft maila do gościaKatarzyna klika „wyślij”
Obsługa klientaKlasyfikuje zgłoszenie, proponuje odpowiedźWarstwa decyzyjna kieruje niepewne sprawy do człowieka
Drugi mózgSześciu mentorów debatuje nad decyzjąJarek, w cotygodniowej retrospektywie

AI proponuje. Człowiek albo kod decyduje.

U Kamila model językowy nie odpowiada za liczby, bo w tym miejscu potrzebny jest deterministyczny mechanizm. W automatyzacji Katarzyny agent przygotowuje mail, ale nie wysyła go bez akceptacji. U Jana system automatycznie przekazuje niepewne lub krytyczne zgłoszenia człowiekowi. Nawet Jarek, który wykorzystuje kilku mentorów AI do analizowania swoich decyzji, sam podejmuje ostateczną decyzję i określa kolejne działania.

To ważne, bo dobra automatyzacja nie musi oznaczać przekazania całego procesu AI. Czasem największą oszczędność daje przejęcie przez system tych etapów, które są powtarzalne, czasochłonne albo polegają głównie na zbieraniu i porządkowaniu informacji, podczas gdy człowiek zostaje tam, gdzie potrzebna jest odpowiedzialność, ocena sytuacji albo ostateczna decyzja.

I właśnie od tego najlepiej zacząć myślenie o własnym projekcie.

Nie od pytania, czy nauczyć się najpierw n8n, Claude Code czy agentów AI. Najpierw warto sprawdzić, co w Twojej pracy regularnie zabiera czas, mimo że za każdym razem przebiega podobnie. Dopiero wtedy można zdecydować, które narzędzie rzeczywiście pomoże ten problem rozwiązać.

Więcej projektów kursantów

Lista rośnie. Każdy kolejny projekt ma teraz własny, osobny wpis – tu tylko zajawka, a szczegóły (kod, decyzje projektowe, przykłady działania) czekają pod linkiem.

Strażnik Paliwa

Cennik hurtowy Orlenu jest jawny i publiczny na dobę przed tym, zanim trafi na pylon stacji – tylko prawie nikt go nie czyta. Strażnik Paliwa to automat w Pythonie bez zewnętrznych zależności, który co godzinę sprawdza ten cennik razem z kursem dolara i notowaniami ropy Brent, a gdy hurt drgnie o więcej niż 2 grosze na litrze, wysyła alert na Discorda i Telegrama – zanim nowa cena pojawi się na dystrybutorze.

Repozytorium Strażnika Paliwa na GitHubie

Zobacz, jak działa Strażnik Paliwa →

Strażnik mapasmogu.pl

mapasmogu.pl pokazuje dane ze stacji pomiaru jakości powietrza – przydatne zwłaszcza zimą. Autor, kolejny kursant, zbudował dla własnego serwisu codzienny cron, który sprawdza dwie rzeczy: czy API serwisu w ogóle odpowiada sensowną liczbą stacji, i czy dane nie są przestarzałe względem źródła rządowego. Gdy coś zawiedzie, dostaje maila z konkretnym opisem problemu – zanim zauważy to użytkownik mapy.

Wpis na Mastodonie o Strażniku danych smogowych dla mapasmogu.pl, z mapą SmogOFF pokazującą stacje pomiaru smogu

Zobacz, jak działa Strażnik mapasmogu.pl →

Latarnik

Certyfikat SSL wygasa po cichu, backup nikt nie sprawdza, dopóki nie trzeba go odtworzyć, a gdy strona przestaje odpowiadać, zwykle pierwszy dzwoni klient. Piotrek zbudował Latarnika – automat, który co godzinę pilnuje uptime'u, co dobę robi pełny audyt UX/SEO/a11y (Playwright + axe-core), a surowe dane zamienia w priorytety za pomocą AI spiętego w LangChainie. Wynik trafia na maila, zanim zadzwoni klient.

Zobacz, jak działa Latarnik →

HA Battery Monitor

Bateria w czujniku Zigbee potrafi rozładować się po cichu, zanim ktokolwiek to zauważy. Tomasz połączył lokalne API swojego Home Assistant z Gemini: aplikacja zbiera stan baterii i jakość sygnału wszystkich czujników, a AI zamienia to w diagnozę – nie samą liczbę procent, tylko wniosek w stylu „ten czujnik padnie za dwa tygodnie, bo słaby zasięg wymusza retransmisje” razem z konkretną rekomendacją naprawy sieci.

Raport AI: analiza drenażu baterii termometru w sypialni przez słaby sygnał sieci Zigbee, z rekomendacjami rozbudowy sieci mesh

Zobacz, jak działa HA Battery Monitor →

Guardian

Portal ogłoszeniowy sprzedawczyk.shop deklaruje, że podejrzane ogłoszenia mają być wykrywane możliwie wcześnie. Guardian to panel, który skanuje ogłoszenia pod kątem ryzyka, spamu, duplikatów i błędnych kategorii – naruszenia regulaminu blokuje sam, a pytania, na które nie ma jednej odpowiedzi, przesyła administratorowi na Telegrama razem z gotowym mechanizmem odesłania odpowiedzi.

Panel administratora Guardiana z zestawieniem wyników analizy ogłoszeń: ryzyko, spam, duplikaty, czytelność, zdjęcia, kategorie

Zobacz, jak działa Guardian →

Bugster

Strona może odpowiadać kodem 200 i mimo to być martwa w środku – baza leży, a treść się nie ładuje. Bugster to trójpoziomowy strażnik złożony w całości w n8n: codziennie o 7:00 sprawdza uptime i strukturę strony, raz w tygodniu audytuje certyfikat SSL, a autorski trzeci moduł liczy obrazki bez tekstu alternatywnego, żeby strona zostawała dostępna dla osób korzystających z czytników ekranu. Wszystko self-hosted na Windows, w kontenerach Docker.

Workflow Bugstera w n8n – trzy równoległe ścieżki: codzienny uptime, cotygodniowy audyt SSL i sprawdzanie dostępności cyfrowej

Zobacz, jak działa Bugster →

Strażnik dostępności bloga

„Nie jestem programistką” – zaczęła Adrianna, autorka bloga Na Wysokim Obcasie, opisując swój pierwszy automat. Na blogu łatwo przeoczyć brak opisu ALT przy zdjęciu, a to właśnie ALT pozwala osobom korzystającym z czytników ekranu zrozumieć, co jest na obrazku. Jej Strażnik codziennie sprawdza najnowszy wpis na WordPressie, wykrywa zdjęcia bez ALT i wysyła raport mailem – przy pierwszym teście znalazł od razu trzy.

Post na Instagramie Adrianny o jej pierwszym automacie – Strażniku dostępności bloga

Zobacz, jak działa Strażnik dostępności bloga →

Strażnik warsztatów artystycznych

Nie każdy automat rodzi się z problemu w pracy. Agata interesuje się sztuką i chodzi na warsztaty artystyczne w okolicznym ośrodku – ale ten organizuje je nieregularnie, a ona zawsze dowiadywała się za późno, żeby złapać miejsce. Jej skrypt w Pythonie pilnuje strony ośrodka za nią i w chwili nowego ogłoszenia wysyła alert na Telegrama, z linkiem do zapisów w komplecie.

Post Agaty na Facebooku o automatyzacji, która pilnuje ogłoszeń o warsztatach artystycznych

Zobacz, jak działa Strażnik warsztatów artystycznych →

Strażnik cen perfum

Bartek ręcznie odświeżał strony sklepów, żeby złapać dobrą cenę na konkretny flakon perfum. Jego Strażnik cen perfum to w pełni bezserwerowy automat na AWS Lambda i DynamoDB – co godzinę sprawdza ceny z pliku konfiguracyjnego YAML, trzyma pełną historię i pisze na Telegrama tylko wtedy, gdy cena spadnie o co najmniej 5 zł i dotknie minimum z ostatnich 30, 90 lub 365 dni. Żadnego spamu, tylko sygnał, na który naprawdę warto zareagować.

Zgłoszenie Strażnika cen perfum na X: Lambda AWS z cronem co godzinę, DynamoDB z historią cen, alert na Telegrama przy zmianie od 5 zł

Zobacz, jak działa Strażnik cen perfum →

Strażnik Witryn

Kod HTTP 200 nie znaczy, że strona działa poprawnie – baza może akurat leżeć, a monitoring patrzący tylko na kod odpowiedzi niczego nie zauważy. Strażnik Witryn to zgłoszenie Piotra na konkurs StormIT z okazji Dnia Programisty: automatyzacja w n8n, która oprócz dostępności pilnuje integralności treści przez hash SHA-256, bezpieczeństwa zależności przez OSV API i sygnatur prompt injection – bez użycia modelu AI do tej ostatniej kontroli.

Schemat przepływu pracy Strażnika Witryn – dwa workflow n8n: demo do testów oraz właściwy monitoring z kontrolą każdej witryny, oceną bezpieczeństwa zależności i alertami

Zobacz, jak działa Strażnik Witryn →

Strażnik Kamery

Kamera pilnująca działki potrafi zniknąć z sieci z dwóch różnych powodów – padł prąd albo padł internet – a z zewnątrz wygląda to identycznie. Karol wyciągnął z szuflady starą płytkę ESP8266, dopisał do niej kod przy pomocy Gemini 3.1 Pro i w 3 godziny miał urządzenie, które loguje awarie do EEPROM, a po powrocie sieci wysyła status wprost na Telegram – z dodatkowym healthcheckiem na wypadek gdyby padł sam serwer VPS.

Post Karola na Facebooku o Strażniku Kamery – automacie na ESP8266 monitorującym internet i zasilanie na działce

Zobacz, jak działa Strażnik Kamery →

Sentinel-ECOM

Klasyczny pinger odpowiada tylko na pytanie „czy strona działa?”. Sentinel-ECOM Martyny pyta o coś innego: „czy nie tracisz na tej stronie pieniędzy?”. System skrapuje ceny konkurencji, wykrywa zmiany ofert w czasie rzeczywistym, a LLM ocenia, na ile nowa cena zagraża założonej marży – i od razu proponuje konkretny krok, zamiast zostawiać interpretację danych właścicielowi sklepu.

Sentinel-ECOM – Inteligentny Strażnik Marży w E-commerce, zgłoszenie na konkurs Dzień Programisty 2026 (Helion x StormIT x inkBOOK)

Zobacz, jak działa Sentinel-ECOM →

RepoGuard

W kodzie często zostają rozwiązania, które miały obowiązywać tylko do jakiegoś terminu – i dalej działają poprawnie, mimo że termin dawno minął, bo żaden kompilator ani test tego nie sprawdza. RepoGuard Artura szuka takich miejsc w projektach .NET: TODO z datami, wygasające certyfikaty, przestarzałe API, zaniedbane pakiety NuGet. Zamiast grepować pliki, analizuje drzewo składni Roslyna, dzięki czemu odróżnia realny termin w komentarzu od zwykłego tekstu w cudzysłowie.

Struktura repozytorium RepoGuard na GitHubie – foldery workflows, docs, sample, src, testy oraz pliki konfiguracyjne

Zobacz, jak działa RepoGuard →

Strażnik Konfiguracji

Im więcej automatyzacji ktoś ma uruchomionych, tym łatwiej, żeby jedna z nich po cichu przestała działać. Strażnik Konfiguracji Anety to nadstrażnik w n8n: cyklicznie sprawdza pozostałe workflow, weryfikuje, czy ich logi trzymają ustalony kontrakt (komplet pól, włączone maskowanie danych), a wykryte naruszenie od razu zgłasza na Slacka – zamiast czekać, aż ktoś zauważy problem ręcznie.

Workflow Strażnika Konfiguracji w n8n – Schedule Trigger, pobranie listy workflow, pętla, reguły integralności, filtr FAIL/WARN i uruchomienie subworkflow z alertem

Zobacz, jak działa Strażnik Konfiguracji →

Strażnik Kursalio

Gdy w Kursalio wygasał klucz do wysyłki maili, zadanie przypominające o kończącym się dostępie i tak odpowiadało „ok: true” – i nie wysyłało nic. Z zewnątrz „dziś nikt nie miał terminu” wyglądało identycznie jak „nie działa od dwóch tygodni”. Strażnik Kasi mieszka w osobnym repozytorium, sprawdza sześć rzeczy naraz – od SSL po realność wysyłki – i codziennie testuje całą drogę end-to-end na koncie-kanarku, żeby cisza po awarii nigdy nie wyglądała jak zwyczajny dzień.

Codzienny raport Strażnika Kursalio – zielony status, strona żyje, przypomnienia wychodzą, kanarek dostał swoje przypomnienie

Zobacz, jak działa Strażnik Kursalio →

Strażnik AI

Bot brzmi pewnie nawet wtedy, gdy zmyśla. Klaudia zbudowała sobie na studiach „Repetytora” – asystenta AI odpowiadającego wyłącznie na podstawie materiału zajęciowego – a potem Strażnika AI, który codziennie rano sam go atakuje: sprawdza zgodność odpowiedzi z prawdą źródłową i odpiera 12 znanych technik red-teamu (jailbreak, wyciągnięcie system promptu, wymuszenie fałszywego cytatu). W obu przypadkach werdykt wydaje niezależny model w roli sędziego, nie sam bot.

Raport kontroli Strażnika AI – niezgodność w warstwie halucynacji, 0/12 udanych ataków w warstwie guardrails, z przykładem odpowiedzi bota i werdyktem sędziego

Zobacz, jak działa Strażnik AI →

PROMETEUSZ

Operator energetyczny ogłasza planowane wyłączenia prądu w formie spisu dla całej gminy, w którym trzeba samemu odnaleźć swoją ulicę i numer budynku – czasem ukryty w zagadce w stylu „nieparzyste od 37 do 61 oraz 67, bez 53”. PROMETEUSZ, pierwszy projekt n8n Kamili, czyta takie biuletyny za nią: wyławia wzmianki o firmowym adresie, rozstrzyga, czy wyłączenie go dotyczy, i liczy, ile z niego nakłada się na godziny pracy – melduje mailem i Telegramem, zanim ktokolwiek zdąży zostać zaskoczony.

Żartobliwa ilustracja Prometeusza w stylu renesansowym, obwieszczającego godziny jutrzejszego wyłączenia prądu zebranym pracownikom

Zobacz, jak działa PROMETEUSZ →

Zobacz, jak zacząć swój projekt

Chcesz wdrożyć to u siebie?

Praktyczne kursy i wdrożenia AI oraz automatyzacji. Albo zapisz się na newsletter, żeby nie przegapić nowych treści.