Agentic coding po keynote DHH — kod tanieje, weryfikacja nie

David Heinemeier Hansson, twórca frameworka Ruby on Rails, otworzył Rails World 2026 zdaniem, które jeszcze kwartał temu — jak sam przyznał — brzmiałoby jak szaleństwo: w 37signals pisanie kodu ręcznie jest teraz stanem wyjątkowym. Jak błąd w Sentry. Coś poszło nie tak, trzeba naprawić maszynę, która kod produkuje.

DHH programowanie lubi. Przez ponad dwadzieścia lat pisał w Ruby z przyjemnością i zbudował na nim Rails. I właśnie on mówi, że przeszedł na emeryturę jako programista piszący kod — i że cieszy się z tego, a nie żałuje.

Obejrzałem cały keynote. Zgadzam się z główną tezą. Nie zgadzam się z tym, jak DHH ocenia wynik — i widać to w dwóch miejscach keynote’u. Po kolei.

Agentic coding według DHH — co właściwie ogłosił

Keynote ma kilka warstw. Te, które przenoszą się poza świat Rails:

Punkt zwrotny ma datę. Dla DHH to 24 listopada 2025 i premiera Opus 4.5 — technologia, którą po raz pierwszy mogło sprawdzić w praktyce wielu ludzi. Porównuje to do Kodaka Brownie z 1900 roku, aparatu, który zrobił z fotografii rzecz dostępną dla każdego.
Skala zmiany. Przez 21 lat pisał około 30 tys. linii produkcyjnego Ruby rocznie. W sierpniu 2026 — 150 tys. linii w miesiąc, około 60 razy więcej niż jego wieloletnia średnia. Sam zastrzega, że sporo z tego to rozwlekły Rust.
Język dobiera się do zadania, nie do programisty. Nową wersję HEY 37signals przepisuje na sześć natywnych aplikacji i backend w Rust — projekt ruszył tydzień przed keynote. DHH Rusta nie znosi, nie zna i — jak mówi — uważa to za zaletę. Według jego wyliczeń backend zużyje 99% mniej CPU i 95% mniej pamięci.
Aplikacja ma mieć CLI, nie wbudowanego czatbota. Użytkownik przychodzi z własnym agentem, który obsługuje wiele aplikacji naraz. Czat doklejony do produktu to według DHH strata tokenów.
Architektura do przemyślenia od nowa. Abstrakcje powstały po to, żeby nie powtarzać kodu i łatwo go synchronizować. Gdy powtórzenie i synchronizacja kosztują prawie zero, część reguł, których uczyliśmy się latami, traci uzasadnienie. Nikt nie ma jeszcze nowego podręcznika.

Całość domyka optymizmem na granicy manifestu: przewidywania o końcu zawodów zwykle się nie sprawdzają, a przykład bankomatów i kasjerów bankowych pokazuje, że tańsza usługa potrafi zwiększyć zatrudnienie, nie je zmniejszyć.

Kod przestał być wąskim gardłem

Z tą częścią się zgadzam i widzę ją u siebie. Ta strona, cyfrowy bliźniak z guardrailami, hooki pilnujące SEO artykułów — wszystko to powstało w Claude Code. SQL piszę od lat, ale TypeScript, Astro czy konfiguracja funkcji Netlify to języki i narzędzia, których sam nie wybrałbym, gdybym miał każdą linię pisać ręcznie. Z agentem wybieram to, co pasuje do zadania, a nie to, co znam najlepiej.

Jedna różnica wobec DHH: kodu, który trafia do danych, nie traktuję jak czarnej skrzynki. SQL i modele dbt czytam linia po linii. Tam, gdzie język znam słabiej, zanim coś oddam, sprawdzają to build, testy i hooki — o tym niżej.

DHH mówi to wprost: znajomość konkretnego języka przestaje być barierą wejścia. Liczy się to, czy wiesz, co ma powstać i jak sprawdzić, że powstało dobrze. Integracja z API, którą odkładało się, bo „nie ma kto napisać”, jest teraz w zasięgu. Wąskim gardłem przestaje być pisanie. Zostaje nim wiedza, co zbudować.

Czarna skrzynka widzi tylko błędy, które widać

I tu się rozchodzimy. DHH mówi, że kodu w Rust nie czyta i ocenia go jak czarną skrzynkę — z zewnątrz, po zachowaniu. Jak każdy właściciel firmy, który kiedykolwiek zlecał pracę programistom. Zmieniło się tylko to, kto trzyma odpowiedzialność.

Test z zewnątrz łapie błędy, które wychodzą w działaniu. Kalkulator liczy źle, edytor wideo się wysypuje, strona się nie ładuje. Nie łapie tych, które w działaniu nie wychodzą — a takie ma każda aplikacja. Luka bezpieczeństwa nie psuje ekranu. DHH sam podaje przykład: niedawny CVE w Rails, przez bibliotekę do obrazów napisaną w C, przez którą coś „przeciekło”. I nie odpowiada na to „oceniam z zewnątrz”. Odpowiada kwarantanną — projektem HotCell. Tam, gdzie błąd jest cichy, nawet on buduje bramkę.

Aplikacja i dane nie różnią się więc tym, że jedna ma ciche błędy, a druga nie. Różnią się proporcją. W aplikacji cichy błąd to osobna klasa ryzyka, z własnymi narzędziami: skanerem zależności, audytem, sandboxem. W danych cichy błąd to stan domyślny, bo produktem jest liczba. A liczba zawsze wygląda wiarygodnie — raport z zawyżonym przychodem renderuje się tak samo jak poprawny.

Model w dbt przechodzi zielony dbt parse i gubi kolumny. Test na kluczu joina łapie problem, ale ma severity: warn, więc niczego nie zatrzymuje. Tracking wysyła purchase przed potwierdzeniem płatności i przychód w raporcie rośnie, choć w kasie nie. Każdy z tych przypadków przechodzi test „z zewnątrz wygląda dobrze”. Opisywałem to szerzej przy governance w dbt — zielony build, który nic nie sprawdza, to w danych codzienność, nie wyjątek.

Dlatego w pracy z danymi z agentem to minimum:

Architektura i definicje zostają po mojej stronie. Taksonomia zdarzeń, klucze, kontrakty modeli, to, co ma zatrzymać pipeline — tych decyzji nie oddaję. Agent pisze kod w ramach, które wyznaczam.
Weryfikacja ma być bramką, nie dobrą intencją. Testy, które przerywają build, kontrakty schematu, porównanie liczb ze źródłem. Agent nie powinien móc powiedzieć „gotowe”, dopóki bramka nie przejdzie. Ten sam mechanizm pilnuje u mnie artykułów na tym blogu — opisałem go przy self-review loop w Claude Code.

Agentic coding działa. Pytanie brzmi, gdzie kończy się czarna skrzynka. W aplikacji granicą jest zachowanie widoczne dla użytkownika, a ciche błędy łapią osobne mechanizmy, jak kwarantanna u DHH. W danych takim błędem jest prawie wszystko — liczba, na której ktoś podejmuje decyzję i której nikt nie sprawdzi, jeśli nie zbudujesz tego sprawdzenia.

Basecamp 5 i ser szwajcarski

Jest w keynote moment, który czytam inaczej niż DHH. Wiosną 37signals kończyło Basecamp 5. Projektanci dopisywali ostatnie funkcje z agentami. Każdy pojedynczy PR wyglądał rozsądnie. Dwadzieścia czy trzydzieści razem zostawiło architekturę „jak ser szwajcarski”.

Zespół wrócił wtedy do ręcznego review i programistów. DHH ocenia to dziś jako zły wniosek: wystarczyło „dać temu pięć minut” i poczekać na następny model, z którym całość „pewnie by zadziałała”.

Mój wniosek jest inny. Lepszy model zmniejsza problem, ale go nie usuwa. Trzydzieści poprawnych lokalnie zmian bez kogoś, kto trzyma całość, daje dziurawą całość — z agentem czy bez.

W trackingu widać to najwyraźniej. Agent podpięty przez MCP do kontenera GTM przejrzy zdarzenia i obsługujące je tagi w kilka minut — tak wyglądał mój audyt GTM przez MCP. Znajdzie trzy nazwy tego samego zdarzenia i tag, który nie wysyła parametru. Nie rozstrzygnie, która wersja jest poprawna, bo to wynika z taksonomii, a taksonomię ktoś musi ustalić. A wykrycie po fakcie ma w trackingu cenę: danych zebranych źle w GA4 wstecz nie przeliczysz. Agent przyspiesza i wykonanie, i kontrolę. Spójność nadal wymaga właściciela.

Zresztą 37signals w praktyce wyciągnęło ten wniosek — Basecamp 5 wyszedł po review programistów i z dużą porcją ręcznie pisanego kodu. A gdy DHH w tym samym keynote proponuje mniej abstrakcji, bo powtórzenie nic nie kosztuje, ser szwajcarski robi się regułą, nie wypadkiem.

„Każda aplikacja potrzebuje CLI” — dla analityka to już się dzieje

Najbardziej praktyczna rada z keynote: nie doklejaj czatbota do produktu, daj agentom interfejs, przez który mogą z produktu korzystać. DHH mówi o CLI. W świecie danych ten sam kierunek ma inne nazwy — serwery MCP, API do narzędzi analitycznych, agenci w n8n.

Przykład z mojej pracy: bot w Slacku, który odpowiada na pytania o dane GA4. Zamiast otwierać interfejs GA4, pytasz w Slacku. Agent odpytuje API, odpowiedź przychodzi w kilka sekund. To dokładnie model „przynieś własnego agenta” — tyle że zamiast CLI jest API i workflow.

Wniosek dla każdego, kto buduje narzędzia danych w firmie: pytanie „czy dodać AI do naszego dashboardu” jest źle postawione. Lepsze brzmi: czy agent, którego ludzie już używają, dostanie się do naszych danych w kontrolowany sposób.

Co z tego zabieram

DHH ma rację co do ekonomii agentic coding: ręczne pisanie kodu przestaje się opłacać, a język programowania przestaje być barierą. Ma też rację, że nikt nie zna jeszcze nowych reguł architektury ani metodyki pracy — i że to dobry moment, żeby przy tym być.

Nie zgadzam się z tym, że czarna skrzynka wystarcza. Wystarcza tam, gdzie błąd widać w działaniu. Przy bezpieczeństwie DHH sam sięga po mechanizm. W danych prawie każdy błąd jest cichy, więc mechanizm jest regułą, nie wyjątkiem. Im mniej kodu piszę ręcznie, tym więcej czasu idzie w to, czego agent za mnie nie zrobi — w decyzje, co jest poprawne, i w mechanizmy, które tę poprawność sprawdzają.

Keynote warto obejrzeć w całości, także dla historii o prapradziadku DHH, malarzu portretów, który po pojawieniu się aparatu Kodaka zmienił styl — i sam dał sobie zrobić zdjęcie.