O czym jest ten film
- „Fabryka oprogramowania AI”, zwana też „ciemną fabryką”, to system, do którego trafia dokument wymagań (PRD), a z którego wychodzi wdrożony na produkcję kod — bez ludzkiego przeglądu.
- Autor twierdzi, że coraz więcej firm naprawdę wdraża takie systemy przynajmniej w części developmentu, a sam pomógł kilku biznesom je zbudować. Powód: agenci kodujący, modele językowe i przepływy pracy poprawiają się równolegle.
- Ramą koncepcyjną jest podział Dana Shapiro na pięć poziomów autonomii kodowania z AI (analogia do jazdy samochodem): autor uczy poziomu 3 (agent pisze kod, człowiek planuje i weryfikuje), a fabryka to poziom 5 — „brak kierownicy”.
- Eksperyment z początku roku: aplikacja Dino Chat (tutor AI oparty na treściach z kanału) powstała od początku do końca w ciemnej fabryce — autor ani razu nie napisał ani nie obejrzał linijki jej kodu.
- Eksperyment uznaje za udany, ale aplikacja była prosta i niekrytyczna, więc prawdziwy test niezawodności dopiero przed nim.
- Ogłasza zmianę filozofii kanału: obok „nauczę was budować samemu” powstaje narzędzie do pobrania i natychmiastowego użycia.
- Nowy otwarty projekt: fabryka oprogramowania napędzana workflowami Archona, instalowana jednym promptem; wersja alfa dostępna już teraz.
- Najbliższy cel: repozytoria z prawdziwymi aplikacjami budowanymi fabryką — autor stawia na gry komputerowe jako najbardziej wymagający poligon złożoności.
- Już dziś uzasadnione zastosowania to prototypy i szybkie weryfikacje pomysłów produktowych, bo tanie modele czynią generowanie całych aplikacji „na próbę” opłacalnym.
- Fragment sponsorowany poświęcony proxy do scrapingu (Data Impulse) — z praktyczną przestrogą, że pierwszy mur agentów scrapujących to limitowanie zapytań z jednego adresu IP.
Redakcyjne tłumaczenie
Od dokumentu wymagań do wdrożenia, bez człowieka
Fabryka oprogramowania z AI — to, co od początku roku nazywam na kanale „ciemną fabryką” — to moim zdaniem ostatni etap ewolucji kodowania wspomaganego sztuczną inteligencją. Do systemu wrzucacie dokument wymagań, a wychodzi z niego wdrożony kod. Tworzycie ogólny dokument planistyczny, oddajecie go maszynie, ta rozbija go na pojedyncze zadania, wykonuje je po kolei, przegląda pull requesty, scala zmiany i wypuszcza wszystko prosto na produkcję — tak, że ani jedna osoba nie zagląda przy tym w kod.
(Informacja dodatkowa: PRD, z ang. Product Requirements Document — dokument opisujący wymagania wobec produktu, klasyczny punkt wyjścia dla zespołów rozwojowych.)
(Informacja dodatkowa: pull request — propozycja zmiany w kodzie, którą w serwisach typu GitHub recenzuje się przed połączeniem z główną gałęzią projektu.)
Możecie teraz pomyśleć: to nigdy nie będzie na tyle niezawodne — zwłaszcza jeśli do agentów kodujących podchodzicie sceptycznie. Rozumiem. Tyle że ostatnio praktycznie co chwilę słyszę o firmach, które realnie wdrażają takie systemy przynajmniej w części swojego developmentu, a kilku biznesom pomogłem zbudować fabrykę AI na własne oczy. Rzecz w tym, że trzy rzeczy poprawiają się jednocześnie: sami agenci kodujący, modele językowe, które nimi sterują, oraz rozbudowane przepływy pracy, w których je osadzamy. W takim układzie taki system przestaje być fantastyką.
Wiem, że dla części widzów to mocna teza, ale uważam, że już dziś każdej firmie opłaca się mieć jakąś formę takiej fabryki — choćby do szybkiego prototypowania i sprawdzania pomysłów produktowych. I mówię wprost: mocno na to stawiam. To będzie następna wielka rzecz, w którą włożę masę czasu i wokół której zbuduję cały kanał — otwarta fabryka oprogramowania AI, którą pobieracie i zaraz zaczynacie budować cokolwiek zechcecie. Cel jest ambitny, dopiero raczkuję, ale wierzę, że przyszłość wytwarzania oprogramowania w ogóle zmierza właśnie ku takiemu poziomowi autonomii. W tym filmie chcę więc wyjaśnić, czym fabryka właściwie jest, jak do niej doszedłem, co przetestowałem w tym roku i co będzie dalej. A jeśli znacie mnie zaledwie z paru filmów, może to dobry moment, żeby wskoczyć na pokład — zapowiada się ciekawa podróż.
I jeszcze dwie uwagi na rozgrzewkę. Po pierwsze: nie jestem oderwanym od rzeczywistości entuzjastą, który twierdzi, że AI zastąpi całą inżynierię w ciągu roku. Po prostu zakładam, że w kilka najbliższych lat fabryka oprogramowania trafi do warsztatu większości firm jako jedno z podstawowych narzędzi — i możemy poprowadzić ten marsz razem. Po drugie, rzecz warta przemyślenia: budowa fabryki zmusza mnie do doprowadzenia niezawodności asystentów kodujących do maksimum. Kiedy usuwam siebie z procesu, nie mam już szansy wyłapywać drobnych błędów agenta — muszę więc tak zbudować system, żeby ich w ogóle nie popełniał. Popychanie spraw do granic robi ze mnie po prostu lepszego inżyniera od agentów. Pójdziecie ze mną — wszystkie te lekcje wpadną i do was.
Pięć poziomów autonomii kodowania
Fabrykę oprogramowania AI nazywa się też ciemną fabryką — to w praktyce synonimy. Nazwa przywarła do mnie za sprawą wpisu Dana Shapiro opublikowanego na początku roku; to właśnie on zaraził mnie pomysłem. (Informacja dodatkowa: Dan Shapiro — amerykański przedsiębiorca technologiczny; jego podział kodowania z AI na pięć poziomów autonomii stał się w tej społeczności często przywoływanym punktem odniesienia. Sam termin „ciemna fabryka” pochodzi z przemysłu, gdzie oznacza zakład pracujący bez udziału ludzi, przy zgaszonym świetle.)
Shapiro wylicza pięć poziomów, czyli kolejne szczeble swobody, jaką oddajemy agentowi. Omawiałem je na kanale już parę razy i będę wracał — można z tego zrobić grę towarzyską: kieliszek za każdym razem, gdy Cole znowu pokazuje wpis Shapiro. Uwielbiam ten podział, bo posługuje się analogią do prowadzenia samochodu. Na samym początku piszecie praktycznie cały kod sami, a AI podaje pomocną dłoń tylko od czasu do czasu. Zjeżdżamy niżej, do poziomu trzeciego — tego, którego głównie uczę, bo tam da się wycisnąć najwięcej pewności: agent pisze już cały kod, ale wy mocno uczestniczycie w planowaniu i sprawdzaniu każdego pojedynczego zgłoszenia. A na końcu jest poziom piąty. Kokpit został — wciąż prowadzicie pojazd, wydając ogólne polecenia — ale kierownicy już nie ma. Wszystkie drobne decyzje zapada teraz agent. Wysyłacie dokument z planem, a z powrotem dostajecie wdrożony kod. I o to chodzi: marzenie każdego, dopóki jest wystarczająco niezawodne.
Eksperyment roku: Dino Chat
Czy ciemna fabryka jest już aż tak niezawodna? Zacząłem to sprawdzać na początku roku. Zbudowałem pełnowymiarową ciemną fabrykę — proces stawiania dokumentowałem na kanale w streamach i kolejnych filmach — i stworzyłem z jej pomocą całą aplikację. Nazywa się Dino Chat, mój tutor AI: agentowa aplikacja czatu z pełnym dostępem do mojego kanału na YouTube, a członkowie społeczności Dynamis mogą dodatkowo przeszukiwać moje kursy i warsztaty. Zadajecie pytanie, a odpowiedź opiera się na wszystkim, czego uczę w internecie. Całkiem niezłe.
To nie jest najbardziej złożona aplikacja świata, ale sedno w czym innym: powstała od deski do deski w mojej ciemnej fabryce. Ani jednej linijki kodu nie napisałem — nawet w nie nie zajrzałem. Link jest w opisie: możecie wejść i wypróbować ją już dziś, to żywa aplikacja produkcyjna, do której nie przyłożyłem ręki.
Uznaję więc, że eksperyment się udał. Tylko że aplikacja ani nie jest krytyczna, ani szczególnie skomplikowana — prawdziwej próby niezawodności ciemnych fabryk więc nie przeprowadziłem. I właśnie to jest następny krok. Do pierwszego eksperymentu dorzuciłem nawet gotowy skill, dzięki któremu zbudujecie własną wersję takiego systemu: odsyłam do filmu oraz do głównego repozytorium skilli na GitHubie, gdzie krok po kroku stawiacie dokładnie to, na czym sam pracowałem. Dobre miejsce na start.
Fragment sponsorowany: proxy do scrapingu
Sponsorem dzisiejszego filmu jest Data Impulse — platforma proxy rozliczana według zużycia, do wszelkiego scrapingu, jakiego wymagają wasze agenty. Tych ze scrapingiem buduję nieustannie; jeden, związany z e-commerce, mam właśnie w toku. W uproszczonej wersji mój scraper pobiera dane produktów, ale działa z jednego adresu IP — i to jest pierwszy mur, o który rozbijecie się przy każdym scrapingu wykraczającym poza garstkę zapytań: serwer zaczyna was limitować albo po prostu blokuje. Data Impulse rozwiązuje ten problem własną siecią rezydencjalną: ponad 90 milionów adresów IP w 195 krajach, bez odsprzedaży, więc adresy są szybkie i stabilne. W praktyce wystarczy w istniejącym kodzie podstawić adres proxy platformy — nic więcej się nie zmienia — i każde zapytanie wychodzi z innego „domowego” IP, jak gdyby to były różne osoby. Cały ruch widać w panelu, z podziałem na pojedyncze zapytania i metrykami w czasie. Rozliczenie: dolar za gigabajt transferu, płaci się za to, czego się użyje, nic nie przepada, a w razie potrzeby utrzymacie sesję na stałym adresie. Sprawdzi się przy agentach RAG, aplikacjach śledzących ceny i wszystkim podobnym. Link w opisie.
Wędką albo rybą — zmiana filozofii kanału
A teraz muszę być z wami szczery, bo czeka pewna zmiana w mojej filozofii nauczania i dostarczania narzędzi. Przez cały czas istnienia kanału kierowałem się zasadą: lepiej nauczyć was, jak coś zbudować samemu, niż wręczyć gotowca — dajcie człowiekowi wędkę, nie rybę. Wiem, że właśnie za to cenicie moje treści, i z tego nie rezygnuję. Ale zaczynam patrzeć na sprawę inaczej: przynajmniej część materiałów chcę po prostu oddawać jako narzędzie do uruchomienia zaraz po instalacji. Kiedyś było „oto skill, który pomoże ci postawić ciemną fabrykę” albo „nauczę cię budować drugi mózg od zera”. Teraz do tego dochodzi: „pobierz i używaj”.
Powiem szczerze: zawsze marzyło mi się mieć otwarty projekt klasy OpenClaw z prawie 400 tysiącami gwiazdek na GitHubie, Hermes Agent — 240 tysięcy — czy Deep Sea Carnis, który już ma 209 tysięcy. (Informacja dodatkowa: gwiazdki to na GitHubie najpopularniejszy miernik rozpoznawalności projektu.) Nic mojego nigdy w ten sposób nie wystrzeliło. Najbliżej byłem z Archonem — wspaniałe narzędzie, wciąż w niego dużo inwestuję — ale to nie jest projekt za dwieście, trzysta tysięcy gwiazdek. I chyba wiem dlaczego: moje projekty nigdy nie zachwycały od razu po instalacji. Wymagały zbudowania własnego procesu, stworzenia czegoś od zera — bo taka właśnie była moja filozofia. Tym razem uznałem, że przyszła moja kolej na coś, co po prostu pobieracie, uruchamiacie bez skomplikowanej konfiguracji i od razu czerpiecie z tego wartość.
Spokojnie: Archon nigdzie się nie wybiera, a stara filozofia w większości dalej obowiązuje. Po prostu rozumiem, że czasem chce się coś, co działa niemal bez ustawiania.
Fabryka do pobrania: instalacja jednym promptem
I dokładnie to robię z nową fabryką oprogramowania AI. Zbieram wszystko, czego nauczyłem się, pomagając firmom wdrażać takie systemy, wszystko z publicznego eksperymentu pokazywanego na kanale i wszystkie lekcje okupione własnymi błędami — i składam w jedno rozwiązanie do pobrania i uruchomienia od ręki. Oczywiście projekt nosi mocne piętno moich poglądów na budowę oprogramowania, a pod maską napędzają go workflowy Archona: przy instalacji system dociąga go i to on prowadzi wszystkie procesy — od waszych planów, przez napisany kod, aż po wdrożenie. (Informacja dodatkowa: Archon — otwarte narzędzie do tworzenia agentów AI, rozwijane przez autora kanału.) Będą też pokrętła do dostrojenia, żebyście mogli wszystko dopasować do siebie, jeśli podzielacie moją dotychczasową filozofię. Sedno jednak jest takie: bierzecie prompt z początku pliku README, wysyłacie go do swojego agenta kodującego, ten zadaje kilka pytań, instaluje całość — i system jest od razu gotowy przyjmować dowolny dokument wymagań i budować rzeczy od początku do końca. Od razu po instalacji. Nie w moim stylu — ale jest.
Jak podkreślałem, budowa dopiero się rozkręca. Ten film nie jest tutorialem — projekt niekoniecznie jest już na to gotowy. Jeśli jednak chcecie zaryzykować, wersja alfa czeka: wyślijcie prompt do swojego agenta już dziś. Naprawdę jednak nagrałem to przede wszystkim po to, żeby pokazać, nad czym pracuję, i zaprosić was w podróż. Budujcie to ze mną, a razem przekonamy się, jak daleko da się z niezawodnością takiej maszyny. Sam oceniam z umiarkowanym sceptycyzmem, czy fabryką da się budować cokolwiek — nie wiem, może wy jesteście sceptyczniejsi, może mniej. Chodzi o to, żeby wyznaczyć ten próg. I wierzę, że się uda. Jeśli zależy wam na konkretnym poziomie pewności, nadal będziecie chcieli być blisko procesu. Ale pewne zadania można już dziś oddać fabryce — pod warunkiem, że włożymy wystarczająco dużo pracy w harness, czyli cały szkielet procesów i narzędzi zbudowany wokół modelu. I dokładnie tym się zajmę.
Jak mówiłem na początku, są już zastosowania oczywiste: proof-of-concepty i szybkie weryfikacje pomysłów produktowych — tzw. spike, czyli krótkie zderzenie pomysłu z rzeczywistością techniczną. Dosłownie: pozwolić agentowi zbudować całość tylko po to, by zobaczyć, czy pomysł ma sens. To dziś jest realne, zwłaszcza że niektóre duże modele językowe są bardzo tanie. Generowanie mnóstwa kodu wyłącznie na próbę weszło w stadium „opłacalne”.
Testy do granic: gry komputerowe jako poligon
Uwierzcie, testowanie tej fabryki w trakcie budowy pożera mi potwornie dużo czasu. Stawiam od zera dziesiątki różnych fabryk — tak jak tę, którą widzicie na ekranie — i robię to w kółko, iterując i doszlifowując główny, otwarty projekt, którym się z wami dzielę. Dużo kosztowało przełożenie lekcji z pierwszego eksperymentu i ze współpracy z firmami na jeden spójny projekt; przepaliłem przy tym morze tokenów — a to dopiero początek. Na razie nie mam jeszcze repozytorium testowego do pokazania, ale to jeden z najbliższych dużych kroków: rozwijając fabrykę jako główne repo, muszę równolegle tworzyć prawdziwe aplikacje, które udowodnią, że całość działa.
Dużo myślę też o tym, co budować. Tutor AI z poprzedniego eksperymentu jest świetny — praktyczny, wdrożony, przydatny dla was — ale skoro zamierzam pchnąć fabryki do granic, potrzebuję czegoś dużo bardziej złożonego. I pewnie brzmi to trochę śmiesznie, ale postawiłem na gry komputerowe. Gry to znakomity poligon: w zwykłych aplikacjach, jak ta czatowa, da się pójść tylko do pewnego momentu, a potem całość robi się rozdęta od nawyrzucanych na siłę funkcji. W grach natomiast zawsze można dorzucić kolejny mechanizm, coś bardziej wystawnego i zabawniejszego. Nie robię nic webowego — wiem, że dla zasobów kanału web byłby praktyczniejszy, ale gry po prostu sprawiają mi radość. Wyrastałem na grach, gram do dziś i uważam, że to będzie świetny sposób, żeby wystawić fabryki na próbę.
Po co wam ta podróż
Krótko mówiąc: czeka was cała seria materiałów. Będę rozwijał fabrykę i czynił ją coraz lepszą, pokazywał projekty budowane jej pomocą i przekazywał wszystkie lekcje oraz dobre praktyki zebrane przy doskonaleniu szkieletu pod spodem — jak używam Archona i jego workflowów do napędzania całości i co robić, by wszystko działało pewniej. Na kanale jest już materiał o stawianiu ciemnej fabryki od podstaw — linkuję film, w którym omawiam wszystkie pojęcia z diagramu. Sporo złotych myśli już tam jest, ale będę wracał do nich, im głębiej wchodzę w projekt.
A najważniejsze jest chyba to: wszystko, co składa się na tę fabrykę, nauczy mnie i was po prostu lepszego obchodzenia się z agentami kodującymi w ogóle. Skoro podnosimy autonomię na taki poziom, wypada, żeby to działało niezawodnie — a te same nawyki procentują nawet wtedy, gdy trzymacie rękę na pulse. Z tej podróży da się wynieść naprawdę dużo. Jeśli doceniacie ten film i chcecie iść ze mną dalej — za fabryką i wszystkimi lekcjami o kodowaniu z AI — będę wdzięczny za łapkę w górę i subskrypcję. Do zobaczenia w następnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Fabrykę AI wdrażaj najpierw tam, gdzie stawka jest niska
Na czym polega: Pełną autonomię (poziom 5) autor rekomenduje dziś do prototypów, proof-of-conceptów i sprawdzania pomysłów produktowych — tam błąd nic nie kosztuje, a tani model obniża próg wejścia.
Jak stosować: Wydziel obszar „na próbę”: nowy pomysł funkcji albo narzędzie wewnętrzne oddaj fabryce od planu po wdrożenie i oceniaj działający produkt, a nie jakość kodu.
Na co uważać: Prototyp zbudowany bez przeglądu kodu nie nadaje się z automatu na produkcję — traktuj go jako materiał do decyzji, nie jako fundament systemu.
2.Poznaj pięć poziomów autonomii i świadomie wybieraj swój
Na czym polega: Podział Dana Shapiro porządkuje myślenie o AI w kodowaniu: od samodzielnego pisania z drobną pomocą, przez poziom 3 (agent pisze, człowiek planuje i weryfikuje każde zgłoszenie), po poziom 5 — plan wchodzi, wdrożony kod wychodzi.
Jak stosować: Przypisz każdemu rodzajowi prac odpowiedni poziom: systemy krytyczne — niżej, z człowiekiem mocno w procesie; eksploracyjne spike’y — wyżej, z pełną automatyką.
Na co uważać: Nie przeskakuj na piątkę tam, gdzie błąd dużo kosztuje; wyższy poziom autonomii wymaga proporcjonalnie dojrzalszych procesów wokół modelu.
3.Niezawodność bierze się z harnessu, nie z samego modelu
Na czym polega: Gdy człowiek znika z procesu, cała odpowiedzialność przechodzi na szkielet narzędzi wokół modelu: dzielenie planu na zadania, przeglądy, scalanie, wdrożenia. Model to tylko jeden element układanki.
Jak stosować: Projektuj fabrykę jako pipeline z jasnymi bramkami jakości — każdy etap powinien mieć własne kryteria akceptacji, zanim kod pójdzie dalej.
Na co uważać: Zbudowanie takiego szkieletu jest kosztowne w tokeny i czas; zakładaj iteracje, a nie sukces za pierwszym podejściem.
4.Usuń się z procesu, żeby zobaczyć jego słabe punkty
Na czym polega: Motywacja autora jest także treningowa: skoro nie może łapać błędów agenta, musi tak zaprojektować system, żeby błędów nie było. Presja autonomii wymusza jakość.
Jak stosować: Uruchom bezpieczny, sandboxowy projekt całkowicie „bez zaglądania w kod” i notuj każde miejsce, w którym system się wywalił — dostaniesz listę dziur w procesie do naprawienia.
Na co uważać: Rób to wyłącznie na projektach niekrytycznych, a wnioski przenoś do codziennej pracy z agentami jako zasady, nie gotowe przepisy.
5.Tanie modele zmieniają ekonomikę eksperymentów
Na czym polega: Część dużych modeli językowych jest na tyle tania, że wygenerowanie całej aplikacji tylko po to, by sprawdzić pomysł, stało się racjonalne finansowo.
Jak stosować: Do spike’ów i prototypów używaj tańszych modeli, droższe zostawiając zadaniom o wysokiej stawce; licz koszt całego prototypu, nie pojedynczego zapytania.
Na co uważać: Tańszy model częściej gubi się w złożonej logice — jeśli prototyp ma być podstawą dalszej budowy, policz także koszt przeróbek.
6.Na poligon złożoności wybierz dziedzinę bez sufitu
Na czym polega: Zwykła aplikacja szybko robi się „rozdęta” od funkcji, więc nie wystawia fabryki na prawdziwą próbę; gry komputerowe pozwalają eskalować złożoność niemal bez końca — dlatego autor wybrał je na test.
Jak stosować: Poszukaj dziedziny, do której da się stale dokładwać kolejne warstwy (gry, symulacje, narzędzia z rosnącą liczbą integracji), by nacisk na system rósł z każdym krokiem.
Na co uważać: Bardziej złożony poligon wydłuża pętlę zwrotną — ustawiaj małe kamienie milowe, żeby wiedzieć, co konkretnie się posypało.
7.Łącz dwie filozofie: uczyć budować i dawać gotowca
Na czym polega: Autor zmienia podejście do dzielenia się wiedzą: obok materiałów „zbuduj sam od zera” powstaje narzędzie instalowane jednym promptem, z opcjami konfiguracji dla chcących wejść głębiej.
Jak stosować: Do nauki fundamentów sięgaj po materiały pokazujące budowę od zera; do szybkiego uzyskania wartości — po gotowy projekt, który skonfigurujesz pod siebie.
Na co uważać: Gotowiec narzuca autorowskie decyzje architektoniczne — zanim zaufasz, sprawdź, co dokładnie dzieje się pod maską (u autora: workflowy Archona).
8.Firmom opłaca się fabryka „na wydzielonym odcinku”
Na czym polega: Firmy, o których wspomina autor, nie automatyzują wszystkiego naraz — wdrażają pełną autonomię w wybranej części developmentu i to już działa.
Jak stosować: Zacznij od jednego niekrytycznego obszaru (narzędzia wewnętrzne, prototypy), zmierz czas i koszt przed oraz po, a dopiero potem rozszerzaj zakres.
Na co uważać: Łatwo popaść w samozłudzenie pełnej autonomii — utrzymuj metryki jakości, np. odsetek odrzuconych zmian czy błędy po wdrożeniu.
9.Lekcje z pełnej autonomii poprawiają pracę na każdym poziomie
Na czym polega: Nawet jeśli nigdy nie wypuścisz kodu bez przeglądu, zmuszenie się do poziomu 5 uczy pisania lepszych planów i twardszych kryteriów akceptacji — a to procentuje wszędzie.
Jak stosować: Uruchom ograniczony w czasie eksperyment na bocznej repozytorium (np. „tydzień na poziomie 5”) i wypisz nawyki — jak precyzyjny PRD — które przeniesiesz do codzienności.
Na co uważać: Nie przenoś ślepo reguł z trybu automatycznego do pracy z człowiekiem — w pętli człowiek wyłapie błąd, automat nie.
10.Agenci, którzy scrapują, potrzebują proxy
Na czym polega: Pierwszą barierą każdego scrapingu jest limitowanie i blokada ruchu z jednego adresu IP; rozwiązaniem z fragmentu sponsorskiego jest rezydencjalna sieć proxy rozliczana za transfer (Data Impulse).
Jak stosować: Skieruj ruch agenta przez proxy już na starcie projektu, zanim limity zablokują rozwój; do operacji wymagających tej samej tożsamości używaj sesji na stałym adresie IP.
Na co uważać: Koszt rośnie wraz z ruchem (dolar za gigabajt), więc ograniczaj zbierane dane do niezbędnego minimum — i pilnuj zgodności scrapingu z regulaminami serwisów.