Cotygodniowa dawka linków, czyli archiwum newslettera Dane i Analizy
Ten numer ma wyraźny środek ciężkości: agenci AI i to, co z nimi robić, kiedy wychodzisz poza pierwsze eksperymenty. Teksty o LangGraph – od „jak zbudować pierwszego agenta” po „co psuje się po kilku miesiącach” – tworzą razem coś w rodzaju mini-ścieżki, którą można przejść od razu albo wracać do poszczególnych etapów w miarę potrzeb. Uzupełnia je tekst o tym, jak zmienia się rola programisty, kiedy AI przejmuje pisanie kodu – i dlaczego to jest trudniejsze niż się wydaje.
Kilka tekstów wprost pyta: czy to co zbudowaliśmy do tej pory nadal wystarczy? Klasyczny podział danych na medalionowe warstwy zaczyna nie nadążać za systemami AI. Warstwa semantyczna, przez lata traktowana jako opcja w BI, staje się kluczowym elementem każdej rozmowy o text-to-SQL. A jeśli szukasz czegoś między Kafką a Redisem do obsługi zadań w tle – jest tu też coś dla Ciebie:
gdzie zaczyna się sypać architektura medalionowa i co z tym zrobić, dlaczego warstwa semantyczna to nie feature BI, a fundament AI, jak wygląda system wykrywający fraud w 27 ms od środka, lekka kolejka zadań, która nie wymaga Kafki ani ZooKeepera.
Power BI dostaje w tym numerze solidną porcję uwagi – trzy teksty, każdy z innego kąta: jak połączyć dbt z Power BI żeby skończyć z niespójnymi KPI, jak przyspieszyć raport (siedmiokrotnie!) krok po kroku, i co tak naprawdę się dzieje kiedy każesz agentowi AI zbudować dashboard za Ciebie. Plus Spec-Driven Data Modeling – ciekawy pomysł na to, żeby AI generujące kod danych nie wymyślało reguł biznesowych, których nie zna.
Na koniec kilka tematów, które nie tracą na aktualności: zarządzanie pamięcią w Sparku wyjaśnione bez żargonu, maskowanie danych w SQL pod RODO bez tworzenia osobnych kopii, MLflow do ogarniania chaosu eksperymentów ML i porównanie ClickHouse vs TimescaleDB z 10 tygodniami testów produkcyjnych w tle.
ai_agent
Building Agentic Workflows in Python with LangGraph
Chcesz zbudować agenta AI w Pythonie, który nie tylko odpowiada na pytania, ale też używa narzędzi, pamięta kontekst rozmowy i działa krok po kroku? LangGraph jest do tego narzędziem, a ten tekst to najlepszy punkt startowy jaki znalazłem do nauki od zera. Wyjaśnia jak agent „zapamiętuje” przebieg rozmowy, jak podłączyć zewnętrzne narzędzia (np. wyszukiwarki, API), jak agent decyduje kiedy skończyć działać – i jak zapisać stan sesji, żeby można było wrócić do rozmowy po przerwie. Bez zbędnego skomplikowania – dokładnie tyle, ile potrzeba do zbudowania pierwszego działającego agenta.
The Human-in-the-Loop is Tired
Kiedy AI pisze kod za Ciebie, Twoja praca nie znika – zmienia się. Zamiast tworzyć, zaczynasz sprawdzać, recenzować i zatwierdzać. I po jakimś czasie okazuje się, że to jest wyczerpujące inaczej niż zwykłe kodowanie. Tekst opisuje, jak zmienia się rola programisty w środowisku z agentami AI: co zyskujesz, z czego rezygnujesz i jak dostosować się do tego, żeby nie skończyć z poczuciem, że tylko klikasz „approve” bez rozumienia co zatwierdzasz. Czytać obowiązkowo, szczególnie jeśli właśnie zaczynasz intensywnie korzystać z agentów.
Learning LangGraph : A Journey Through Agents, Blackboards, and Bottlenecks
LangGraph robi wrażenie w pierwszych tygodniach – i potrafi irytować, kiedy zaczynasz go używać w bardziej złożonych scenariuszach. Ten tekst opisuje oba etapy. Jak wybrać między elastyczną orkiestracją przez model AI a przewidywalnym, z góry określonym przepływem kroków? Kiedy agent „myślący w pętli” jest właściwym wyborem, a kiedy zwykłe sekwencyjne uruchamianie zadań jest po prostu szybsze? Tekst odpowiada na te pytania i pokazuje jak uruchamiać agentów równolegle, jak zapisywać stan między rozmowami i jak nie przepalać budżetu na powtarzające się fragmenty promptów. Dla tych, którzy wyszli poza „hello world” z agentami.
Architecting Multi-Agent Systems with LangGraph & NestJS: State Machines in Action
Co jeśli zamiast jednego agenta AI użyć kilku, z których każdy robi jedną rzecz i może poprosić o ponowne wykonanie poprzedniego kroku, jeśli coś poszło nie tak? Tekst pokazuje jak zbudować taki system w LangGraph.js i NestJS: cztery wyspecjalizowane agenty (planowanie, research, pisanie kodu, ocena jakości), które wspólnie realizują zadanie i mogą cofnąć się i poprawić wynik zamiast go tylko przepuścić. Opisane są też kwestie produkcyjne: jak zabezpieczyć system przed nieskończonymi pętlami, jak obserwować co robią agenty i jak zapisać stan, żeby można było włączyć człowieka w odpowiednim momencie. Dobry wzorzec dla zespołów wchodzących w wieloagentowe systemy z JavaScriptem.
I Helped 50,000 People Set Up Claude Code. Here’s What I Didn’t Tell Them
Pierwsze tygodnie z Claude Code wyglądają świetnie – agent rozumie projekt, generuje dobry kod, wszystko działa. Ale po kilku miesiącach zaczynają się dziwne rzeczy: agent robi coś, co wygląda na sukces, ale wynik jest błędny. Połączenia pokazują „aktywne”, choć faktycznie nie działają. Sub-agenty raportują wykonanie zadania, które tylko częściowo skończyły. Ten tekst opisuje te wzorce – i co zrobić, żeby im zapobiec. Nie ma tu prostych odpowiedzi, ale jest uczciwy opis jak utrzymać środowisko agentów w dobrej kondycji po dłuższym czasie.
ai_ml
Lessons Learned After 8.5 Years of ML
Osiem i pół roku pracy z modelami ML to wystarczająco długo, żeby zebrać lekcje, których żaden kurs nie uczy. Tekst skupia się na tym, jak wybrać problem, którym warto się zajmować – taki, który nie stanie się nieaktualny zanim skończy się projekt – oraz jak nie tracić głowy, kiedy projekt trwa miesiącami bez widocznego efektu. Nie ma tu listy trików ani „10 rzeczy, których żałuję” – są obserwacje, które seniorzy rozpoznają, a juniorzy powinni przeczytać znacznie wcześniej niż po ośmiu latach.
analiza_danych_koncepcje
Introducing Spec-Driven Data Modeling
Prosisz AI o wygenerowanie schematu bazy danych albo kodu SQL i dostajesz coś technicznie poprawnego, ale niespójnego z tym, jak firma naprawdę liczy sprzedaż, definiuje klienta czy rozumie „zamówienie zrealizowane”. Skąd ten problem? AI nie zna Twojego biznesu. Spec-Driven Data Modeling to podejście, w którym najpierw zapisujesz te reguły w formalnym dokumencie-specyfikacji, a potem wszystko – schemat, kod, dokumentacja, API – jest generowane na jej podstawie. Dzięki temu AI implementuje, ale nie wymyśla logiki, której nie zna. Ciekawy kierunek dla każdego, kto zaczyna używać AI do pracy z danymi i zauważa, że wyniki są poprawne, ale nie do końca mają sens.
architektura
The Medallion Architecture Reconsidered: What It Solved, and Where It’s Cracking
Bronze, Silver, Gold – trójwarstwowy podział danych stał się przez lata czymś w rodzaju domyślnej odpowiedzi na pytanie „jak zorganizować platformę danych”. I ten podział nadal ma sens, ale w kilku miejscach zaczyna nie nadążać. Tekst pokazuje, gdzie ten model się sypie: dane bez struktury, potrzeba błyskawicznych odpowiedzi i specyfika systemów AI, które działają inaczej niż tradycyjne analizy. Nie jest to tekst „wyrzućcie medallion” – raczej „sprawdźcie, co powinniście zmienić, zanim te problemy Was dopadną”. Dobre czytanie przed projektowaniem nowej platformy danych.
The Semantic Layer is the Ultimate Battlefield in the Era of Agentic AI
Wyobraź sobie, że pytasz AI o przychód firmy i dostajesz odpowiedź – ale zbudowaną na podstawie surowych tabel, które nie uwzględniają wyjątków i reguł biznesowych. Wynik jest spójny technicznie, ale błędny. To właśnie problem, który rozwiązuje warstwa semantyczna: jedno miejsce, gdzie zdefiniowane jest co znaczy „przychód”, „aktywny klient” czy „konwersja”. Tekst tłumaczy, dlaczego ta warstwa – przez lata traktowana jako opcja – staje się dziś kluczowym elementem każdego systemu BI i AI. Dobry punkt wyjścia do rozmowy o tym, czego brakuje w większości wdrożeń text-to-SQL.
When Kafka Is Too Much, and Redis Isn’t Enough: Building a Simpler Distributed Job Queue
Chcesz wysyłać zadania do kolejki i przetwarzać je w tle – ale Kafka to za dużo konfiguracji i utrzymania, a Redis nie zapewnia gwarancji, że zadanie się wykona nawet jeśli serwer padnie. Tekst opisuje Cue – narzędzie zbudowane właśnie dla tej niszy: kolejka zadań działająca w pamięci, bez zewnętrznych zależności, z mechanizmem chroniącym dane przed utratą po restarcie i automatycznym ponawianiem zadań, które się nie powiodły. Ciekawy projekt do obserwowania, szczególnie jeśli szukasz „middle ground” między prostotą Redisa a niezawodnością Kafki.
What Happens in the Milliseconds After You Tap Pay
Od momentu przykładania karty do terminalu do informacji „płatność zatwierdzona” mija ułamek sekundy. W tym czasie system musi sprawdzić czy transakcja nie wygląda podejrzanie – i zrobić to szybciej niż zdążysz odwrócić wzrok. Tekst opisuje jak wygląda taka architektura od środka: co sprawia że jest szybka, skąd bierze dane historyczne, jak działa model wykrywający anomalie i jak system skaluje się w zależności od obciążenia. Wyniki są konkretne: mediana całego procesu to 27 milisekund. Dobre studium przypadku dla każdego projektującego systemy, w których czas odpowiedzi ma realne znaczenie.
bazy_danych
DuckDB Persistent DB File Versus Parquet
Masz kilka gigabajtów danych zapisanych w wielu plikach i chcesz je szybko przeszukiwać lokalnie. Zostać przy plikach Parquet czy wrzucić wszystko do jednego pliku bazy DuckDB? Tekst analizuje obie opcje na realnym przykładzie: dziesiątki partycji z logami AWS, codzienne zasilanie nowymi danymi i zapytania analityczne. Autor sprawdza, co jest szybsze, prostsze w utrzymaniu i gdzie każde podejście zaczyna zgrzytać. Jeśli używasz DuckDB lub planujesz – to dobre studium przypadku przed podjęciem decyzji.
Liquibase Explained: Database Version Control for Professionals in 2026
Zmiany w strukturze bazy danych – nowa kolumna, zmiana indeksu, przebudowa tabeli – zazwyczaj żyją w głowie kogoś z zespołu albo w pliku SQL „do uruchomienia ręcznie na produkcji”. To przepis na problemy, szczególnie kiedy coś pójdzie nie tak i trzeba cofnąć zmianę. Liquibase rozwiązuje to tak, jak Git rozwiązuje zarządzanie kodem: każda zmiana w bazie jest opisana w pliku, wersjonowana, testowana i może być wycofana. Tekst pokazuje jak to działa w praktyce dla PostgreSQL i MySQL, z przykładami gotowymi do użycia. Dobry punkt startowy dla zespołów, które właśnie zdecydowały się porzucić „migracje przez SSH”.
ClickHouse vs TimescaleDB: The Faster Database Wasn’t the Hard Decision
Masz dużo danych o zdarzeniach – kliknięcia, sesje, transakcje – i szukasz bazy, która szybko odpowie na pytania w stylu „ile osób zrobiło X, a potem Y?”. Tekst porównuje dwie popularne opcje: ClickHouse i TimescaleDB, na podstawie 10 tygodni testów produkcyjnych z prawdziwym ruchem. Okazuje się, że szybsza baza nie zawsze jest lepszym wyborem – TimescaleDB był tańszy, ale jeden nieoczekiwany problem doprowadził do 38-minutowego przestoju i sporego zaległości w danych. Artykuł nie daje jednej odpowiedzi – daje porównanie, które pomaga podjąć decyzję dopasowaną do konkretnego przypadku.
data_engineering
Apache Arrow: The Movie Your Bronze Layer Deserves
Wczytujesz duży plik CSV i Python zgłasza błąd braku pamięci – mimo że komputer nie jest przeciążony. Skąd ten problem? pandas przy wczytywaniu danych używa znacznie więcej pamięci niż sam plik zajmuje na dysku. Apache Arrow to inny sposób trzymania danych w pamięci: kolumnowy, wydajny i kompatybilny z narzędziami takimi jak DuckDB, Polars czy PySpark – bez kopiowania danych między nimi. Tekst pokazuje gotowy wzorzec dla etapu wczytywania danych: jak wymusić schemat na wejściu, przetworzyć dane wielowątkowo i zapisać je w formacie Parquet. Warto przeczytać zanim znowu przyjdzie debugować błąd pamięci na klastrze.
Learn dbt for Analytics Engineering
dbt to narzędzie, które wielu analityków i inżynierów danych używa do prostych transformacji SQL – ale oferuje znacznie więcej. Tekst przechodzi przez pełny zakres możliwości: jak organizować modele tak, żeby wiedziały o sobie i uruchamiały się w odpowiedniej kolejności, jak parametryzować zapytania przez szablony, jak automatycznie testować dane pod kątem duplikatów i pustych wartości, jak zarządzać powoli zmieniającymi się danymi i jak wszystko spinać w jednym poleceniu. Materiał przydatny zarówno jako pierwsze zapoznanie, jak i checklista dla tych, którzy już używają dbt, ale podejrzewają że nie korzystają z połowy jego możliwości.
kafka
Real-Time Anomaly Detection With Kafka and Faust: From Stream to Slack Alert in Under 2 Seconds
System, który wykrywa anomalie w transakcjach i metrykach serwerowych w czasie krótszym niż sekunda od ich pojawienia się – i wysyła alert na Slacka. Tekst opisuje jak to zbudować z Kafki i Faust (biblioteka strumieniowania w Pythonie), ale nie ogranicza się do happy path: autor opisuje dwa poważne błędy przy wdrażaniu modelu do wykrywania anomalii, które zepchnęły skuteczność systemu z dobrej na bardzo słabą – i jak je naprawił. Wąskie gardło okazało się nie w samych modelach, a w tym jak zapisywano wyniki do bazy danych. Dobry materiał, jeśli planujesz systemy działające na strumieniu danych i chcesz uniknąć tych samych pułapek.
llm_&_chatgpt
How RAG Really Works in Spring AI (From User Query to LLM Response)
Modele językowe takie jak ChatGPT nie znają danych Twojej firmy – a jeśli je zapytasz o coś specyficznego, po prostu zmyślą coś przekonująco brzmiącego. RAG to sposób na rozwiązanie tego problemu: zamiast „uczyć” modelu Twoich danych, dostarczasz mu odpowiednie fragmenty w momencie zadawania pytania. Tekst pokazuje jak to działa w praktyce w ekosystemie Java i Spring AI – krok po kroku, od pytania użytkownika do gotowej odpowiedzi, z wyjaśnieniem gdzie mogą pojawiać się opóźnienia i jak je minimalizować. Dobry materiał dla zespołów pracujących w Javie, które chcą dodać AI do swoich aplikacji bez przepisywania wszystkiego w Pythonie.
management
4 Ways Slack is Killing Your Business Productivity
40 wiadomości rano, ustalenia rozsiane po trzech kanałach i DM-ie od kogoś na urlopie – i wszystko zaczyna się od szukania kontekstu zamiast pracy. Film pokazuje, jak reorganizować komunikację w Slacku tak, żeby informacje były łatwe do znalezienia – i nie tylko dla ludzi. Agenci AI też potrzebują kontekstu, a nie całej historii czatu do przeszukiwania. Lżejszy materiał, ale warty 10 minut, zwłaszcza gdy właśnie zaczynasz używać narzędzi automatyzacji, które „muszą się domyślić” co projekt robi.[YT, 10 minut, po angielsku]
mlops
Are Your ML Experiments a Mess?
Uruchamiasz model, dostajesz wynik, ale za trzy miesiące nie pamiętasz jakich danych użyłeś ani jakie ustawienia dały ten konkretny rezultat. To klasyczny problem przy rozwijaniu modeli ML. MLflow pozwala to rozwiązać: zapisuje parametry, wyniki, wykresy i dane wejściowe dla każdego eksperymentu, żeby można było wrócić do dowolnego momentu i wiedzieć dokładnie co wtedy działało. Tekst pokazuje też elementy, które wychodzą poza podstawowe logowanie – jak śledzić skąd pochodzą dane i jak automatycznie porównywać różne wersje modelu. Dla tych, którzy wiedzą czym jest MLflow, ale nie wycisnęli z niego tyle ile powinni.
powerbi
dbt + Power BI: Best Practices
Kiedy każdy raport liczy KPI po swojemu, wcześniej czy później pojawiają się spotkania, na których dwie osoby mają różne liczby i nikt nie wie, czyje są poprawne. Jednym ze sposobów na uniknięcie tego jest przeniesienie logiki liczenia wskaźników z raportów do warstwy danych – i właśnie tu przydaje się dbt. Tekst pokazuje, jak zorganizować współpracę dbt z Power BI: co zostaje po stronie dbt (transformacje, testy, dokumentacja), a co zostaje po stronie Power BI (wyłącznie wizualizacja). Przy okazji raporty działają szybciej, bo ciężka praca odbywa się wcześniej. Obszerny materiał – warto mieć pod ręką przy projektowaniu stosu BI.
My Power BI Report Took 14 Seconds to Load. Here’s Everything I Did to Get It Under 2
Raport, który ładuje się 14 sekund, to raport, którego nikt nie używa. Autor opisuje, co zrobił, żeby zejść do 1,8 sekundy – i co konkretnie powodowało opóźnienie. Okazuje się, że Power BI działa zupełnie inaczej niż baza danych: liczy się nie liczba wierszy, ale ile różnych wartości ma dana kolumna, i to wpływa na zużycie pamięci bardziej niż rozmiar tabeli. Tekst pokazuje narzędzia do diagnozowania problemu i konkretne zmiany: co usunąć z modelu, co przenieść do warstwy danych zanim dane trafią do Power BI, i co wyłączyć w domyślnych ustawieniach. Dla każdego, kto ma wolny raport i zastanawia się od czego zacząć.
I Let an AI Agent Build My Power BI Dashboard. Here’s What Actually Happened
Co się dzieje, kiedy zamiast samemu klikać w Power BI, każesz agentowi AI zbudować cały dashboard od zera? Autor to sprawdził – i opisuje szczerze co zadziałało, a co nie. AI potrafiło wygenerować strukturę raportu, relacje między tabelami i podstawowe miary, ale przy próbie dalszego rozwijania projektu nadpisało jeden parametr konfiguracyjny złą wartością, przez co plik przestał się w ogóle otwierać. Naprawa wymagała ręcznej edycji pliku i znajomości rzeczy, którą AI miało zastąpić. Wniosek: automatyzacja działa, ale nie zwalnia z rozumienia tego co pod spodem. Uczciwy i praktyczny materiał.
python
I Wrote 100+ Automation Scripts – These 11 Changed Everything
Zamiast klikać to samo po raz setny – napisz skrypt, który zrobi to za Ciebie. Brzmi prosto, ale większość z nas albo nie wie od czego zacząć, albo kończy na połowicznych rozwiązaniach. Tekst opisuje 11 skryptów Pythona, które faktycznie weszły do codziennej pracy: od porządkowania plików i przeszukiwania logów, przez pilnowanie zużycia zasobów komputera, po prosty timer pomodoro, który pomaga skupić się na jednym zadaniu. Warto przejrzeć – nie żeby kopiować jeden do jednego, ale żeby zobaczyć, co można zautomatyzować i od czego zacząć.
3 Python + Data Warehouse Patterns I Use in Every Production Pipeline
Są błędy w pipelinach danych, które pojawiają się w prawie każdym projekcie – i zazwyczaj wychodzą dopiero w produkcji, kiedy coś po cichu przestaje działać. Ten tekst opisuje trzy z nich: jak budować zapytania SQL, żeby nie dało się przypadkowo nadpisać lub wstrzyknąć złośliwego kodu, jak kontrolować to, czy dane w hurtowni są dopisywane czy nadpisywane i jak to weryfikować po każdym uruchomieniu, oraz dlaczego warto używać gotowych operatorów Airflow zamiast pisać logikę samemu. Dobre przypomnienie dla każdego, kto właśnie przejmuje cudzy pipeline i zastanawia się, skąd biorą się ciche błędy.
I Made the Same Dataset Talk Five Different Ways
Matplotlib, Seaborn, Plotly, Altair i plotnine – pięć różnych bibliotek Pythona do wizualizacji danych, jeden zbiór danych, pięć różnych wyników i filozofii pracy. Tekst nie mówi „użyj tej bo jest lepsza” – pokazuje kiedy każda z nich ma sens: kiedy potrzebujesz pełnej kontroli nad każdym elementem wykresu, kiedy zależy Ci na szybkim wykresie z automatyczną statystyką, kiedy chcesz interaktywną wizualizację bez pisania JavaScriptu i kiedy po prostu migrujesz kod z R. Wybór biblioteki to decyzja, którą warto podjąć świadomie – ten tekst daje do tego solidną podstawę.
spark
Mastering Memory Management in Apache Spark: A Practical Guide
Spark wyrzuca błąd braku pamięci – i nie wiadomo dlaczego, bo danych nie ma aż tak dużo. Albo działa, ale wolno, bo zapisuje tymczasowe dane na dysk zamiast trzymać je w pamięci. Tekst wyjaśnia jak Spark naprawdę zarządza pamięcią: jakie obszary istnieją wewnętrznie, czym się różnią, kiedy i dlaczego Spark zaczyna korzystać z dysku, i jak uniknąć sytuacji, w której jeden niebalansujący fragment danych powoduje problemy dla całego zadania. Materiał dla tych, którzy chcą przestać zgadywać konfigurację Sparka i zacząć ją rozumieć – niezależnie od tego, czy dopiero zaczynają, czy już od jakiegoś czasu zmagają się z wydajnością.
sql
Essential Data Masking Techniques for GDPR Compliance in SQL
Jeśli w Twojej bazie są wrażliwe dane – numery dokumentów, karty płatnicze, adresy – prędzej czy później pojawi się pytanie: kto powinien to widzieć i w jakiej formie? Tekst pokazuje jak rozwiązać to bezpośrednio w SQL, bez tworzenia osobnych kopii danych dla różnych użytkowników. Chodzi o widoki, które automatycznie ukrywają lub zamazują część danych w zależności od tego, kto pyta – zgodnie z wymaganiami RODO. Krótki i konkretny materiał z gotowymi przykładami do zaadaptowania.
wizualizacja_danych
Bad data visualization: how to notice and fix it (27 examples)
Zły wykres to nie tylko kwestia estetyki – to błędne wnioski i złe decyzje. Ten tekst kataloguje 27 typowych błędów: od niefiltrowanych metryk i maskowania braków danych, przez zły dobór typów wykresów (np. kołowy tam gdzie powinien być słupkowy), po triki wizualne, które przekłamują perspektywę. Każdy błąd ma konkretną naprawę – i przykład jak wygląda przed i po. Przydatny zarówno jako checklista przy tworzeniu dashboardów, jak i argument w rozmowie z kimś, kto właśnie zamówił „tylko jedną dodatkową serię na wykresie”.