Better Dev Club

Anthropic opisuje Scion: system kontroli wersji przygotowany dla pracy agentów AI w swoim monorepo. Przy deklarowanych ponad 30 tysiącach scalonych zmian dziennie operacje Gita stały się kosztownym wąskim gardłem. Piotrek Stapp i Kajetan Duszyński przyglądają się raportowanym przyspieszeniom i pytają, czego z tego przykładu może nauczyć się zwykły zespół: czy potrzebuje nowego narzędzia, czy najpierw lepszego procesu? W drugiej części rozmawiamy o Reverse Engineer Anything i granicach przepisywania gotowych produktów z AI. Piotrek opowiada o próbach zbudowania wyszukiwarki lotów uwzględniającej dojazd z lotniska, a Kajetan wyjaśnia, dlaczego zamiast pisać własny system mailingowy wybrał open source i AWS SES. Rozdzielamy aplikację dla siebie od produktu dla klientów oraz koszt napisania kodu od późniejszego utrzymania.00:00 - [30 tys. commitów] Anthropic, Scion i pytanie o wartość zmian02:50 - [Monorepo i agenci] Ograniczenia narzędzia czy problem procesu?04:47 - [Git a praca agentów] Kontrola wersji przy ciągłej pracy online07:20 - [Liczby Anthropic] Raportowane czasy operacji w środowiskach ludzi i agentów10:38 - [Nie kopiuj cudzej skali] Dlaczego rozwiązanie Anthropic nie jest receptą dla wszystkich13:37 - [Co trafia do repozytorium?] Historia zmian, dane i pytania o proces16:59 - [Kod pisany przez AI] Spekulacje o źródłach skali i kosztach utrzymania17:52 - [Reverse Engineer Anything] Odtwarzanie produktów i pierwsze próby Kajetana19:42 - [Wyszukiwarka lotów] Próby Piotrka i koszt dojazdu z lotniska22:48 - [Czy potrzebujesz historii Gita?] Commitowanie, cofanie zmian i praca agentów24:14 - [Pokażcie proces] Czego prowadzący chcieliby dowiedzieć się od Anthropic25:56 - [Własny produkt czy klon?] Hype wokół AI a rzeczywiste zapotrzebowanie na pracę28:44 - [Mailing Marca Lou] Własne narzędzie a cena gotowej usługi31:09 - [Kod to nie cały produkt] Sprzedaż, potrzeby użytkowników i różnice skali32:55 - [Wybór Kajetana] Open source zamiast pisania mailingu od zera33:33 - [AWS SES] Płatność za wysłane maile zamiast liczby subskrybentów33:59 - [Koszt utrzymania] Dlaczego nie wszystko warto pisać samemu36:12 - [Podsumowanie] Pytania o proces Anthropic i własne produkty słuchaczy

Modele decyzyjne mają wybierać odpowiedź, a nie prowadzić rozmowę. Czym różnią się od LLM-ów i dlaczego poprawny JSON jeszcze nie oznacza dobrej decyzji? W odcinku #42 rozmawiamy o Jev od TypeSafe AI, Microsoft-Decision-1 opartym na Qwenie oraz o tym, co w modelach decyzyjnych jest nowe, a co znamy od lat z machine learningu. Sprawdzamy, gdzie takie modele mogą się przydać: w wyborze narzędzi i modeli dla agentów AI, paper tradingu oraz wspomaganiu decyzji medycznych. Jest też historia lekarzy pytających ChatGPT, MedDecider i wyniki na egzaminie LEK. Dlaczego dobry wynik benchmarku nie zastępuje rozmowy z pacjentem? I kiedy wyspecjalizowany model ma więcej sensu niż kolejny prompt do ogólnego LLM-a?00:00 Model decyzyjny kontra szef00:45 Microsoft-Decision-1 kontra Jev04:45 Czym jest model decyzyjny?07:07 Qwen pod spodem i structured output09:28 To samo pytanie, ta sama decyzja?10:40 Sekundy kontra milisekundy12:12 MedDecider, medycyna i paper trading16:28 Qwen, Drex i modele bazowe18:07 Microsoft kontra startup — Dawid i Goliat21:07 Routing agentów: model, narzędzie czy człowiek?23:55 Microsoft Foundry kontra gotowe aplikacje AI28:00 Lekarz pyta ChatGPT31:58 Wyniki LEK to nie wszystko33:43 Pomysł na startup i zakończenie#AI #ModeleDecyzyjne #BetterDevClub #Qwen #Jev #AgenciAI

Głośny keynote DHH (Davida Heinemeiera Hanssona) na Rails World wstrząsnął całym światem IT. Twórca Ruby on Rails ogłosił, że po 20 latach przestaje pisać kod ręcznie i w zasadzie przechodzi na „emeryturę programistyczną”, oddając pisanie w ręce modeli AI. W 41. odcinku Better Dev Club Piotrek Stapp i Kajetan Duszyński rozkładają to wystąpienie na czynniki pierwsze. Czy Software Craftsmanship i dyskusje o czystości kodu to już przeszłość? Co z pasjonatami programowania, którzy weszli do branży z miłości do klepania linijek — czy czeka ich los dawnych malarzy po wynalezieniu aparatu fotograficznego? Panowie bez owijania w bawełnę analizują swoje codzienne nawyki: czy w ogóle jeszcze czytają wygenerowany kod, dlaczego testy stały się jedyną uprzężą trzymającą projekt w ryzach i czy tester z LLM-em w ręku może wkrótce zastąpić klasycznego programistę. Dyskutują także o zmianie struktury zespołów — od pełnej specjalizacji ku „dyrektorom kreatywnym” — pułapce traktowania kodu jak czarnej skrzynki oraz o tym, dlaczego paradoksalnie zrozumienie architektury komputera i fundamentów systemowych staje się ważniejsze niż kiedykolwiek.00:00 Wstęp — suchar o DHH i echa keynote’a na Rails World 03:02 DHH i Ruby on Rails — języki programowania tracą znaczenie na rzecz modeli AI 04:45 Koniec Software Craftsmanship? Rzemiosło jako ukłon w stronę zespołu 06:01 Co z pasjonatami kodu? Malarstwo po wynalezieniu fotografii 08:51 Nowa warstwa abstrakcji — czy kochaliśmy klepać każdą linijkę? 12:03 Czytasz jeszcze kod? Testy jako „harness” projektu 13:31 LLM pisze lepsze testy — przypadki brzegowe, E2E i code review 15:52 Co zostało z rzemiosła? Czy wystarczy dać LLM-a testerom? 18:22 Rewolucja w zespołach — od specjalizacji do dyrektora kreatywnego 21:10 Stolarz a fabryka mebli — ręcznie strugany kod jako nisza23:06 Kod jako czarna skrzynka — Uncle Bob, agenci i architektura 25:53 Powrót do fundamentów — rozumienie komputera zamiast „fix it” 26:22 Rok utrzymywania kodu z AI — czy stajesz się inżynierem? 27:40 90% pracy to CRUD-y — kraftowy kod kontra biznesowa rzeczywistość 29:19 Spełniony sen o IT i biznesie — optymistyczne spojrzenie w przyszłość #BetterDevClub #DHH #AI #CleanCode #SoftwareCraftsmanship #Programowanie #LLM #Testowanie #ArchitekturaOprogramowania #SDLC #RailsWorld #RubyOnRails

Czy rewolucja generatywnego AI jest w stanie obalić fundamentalne prawa inżynierii oprogramowania, które rządzą branżą od kilkudziesięciu lat? W 40. odcinku Better Dev Club Piotrek Stapp i Kajetan Duszyński biorą na warsztat klasyczne zasady wytwarzania software'u i sprawdzają, czy dorzucenie tokenów i armii agentów AI pozwala obejść ograniczenia, z którymi mierzymy się od dekad. Od dowcipu o 9 kobietach rodzących dziecko w miesiąc (Prawo Brooksa), przez architekturę odzwierciedlającą strukturę zespołów (Prawo Conwaya), po ewolucję systemów od prostych do złożonych (Prawo Galla).W dalszej części rozmowy panowie dyskutują o pułapkach metryk efektywności w dobie AI (Prawo Goodharta i "token maxing"), wyjaśniają, dlaczego dyskusje w internecie stały się zbyt grzeczne przez LLM-y, oraz analizują Prawo Amdahla na autentycznym przykładzie 3-tygodniowego debugowania błędu klawiatury w aplikacji terminalowej na iOS. Czy AI to faktycznie rewolucja wywracająca zasady gry, czy raczej ewolucja, która tylko uwypukla i wzmacnia klasyczne problemy inżynierii oprogramowania?Rozdziały:00:00 - Wprowadzenie do praw fizycznych i inżynieryjnych01:21 - Prawo Brooksa i jego współczesne zastosowanie w dobie agentów AI04:14 - Prawo Conwaya a nowa struktura organizacyjna i komunikacyjna07:29 - Ewolucja zespołów w kontekście agentów AI i monolitów10:19 - Prawo Galla: Dlaczego skomplikowany system musi wyrosnąć z prostego13:10 - Pułapki jednego prompta i zbieranie wymagań pod agentów16:28 - Problemy z wymaganiami w oprogramowaniu i iteracyjna krytyka20:22 - Prawa informatyki: Prawo Goodharta, mierzenie KPI i token maxing26:31 - Prawo Amdahla i wąskie gardła w automatyzacji (case study debugowania iOS)31:31 - Ewolucja czy rewolucja w kontekście AI oraz polecajka (Thinking in Systems)Linki i materiały:- Thinking in Systems (Donella H. Meadows): https://www.chelseagreen.com/product/thinking-in-systems/- Nasza strona z transkrypcjami: https://betterdevclub.pl#betterdevclub #programowanie #ai #softwaredevelopment #sdlc

Czy generowanie kodu z pomocą sztucznej inteligencji faktycznie sprawiło, że zespoły dostarczają oprogramowanie 10x albo 100x szybciej? W tym odcinku bierzemy pod lupę cały cykl wytwarzania oprogramowania (SDLC) i sprawdzamy, co tak naprawdę uległo zmianie. Choć pisanie samego kodu skróciło się niemal do zera, wąskie gardła wcale nie zniknęły – przeniosły się na fazę zbierania wymagań, code review, weryfikację PR-ów, testy akceptacyjne (UAT) oraz rozmowy z klientem. Zamiast armii programistów zmagających się ze sztywnym podziałem na frontend i backend, deweloperzy wreszcie wychodzą ze swoich baniek, zaczynają przeklikiwać własne aplikacje na środowiskach deweloperskich i wyłapują błędy znacznie wcześniej. W drugiej części dyskutujemy o paradoksie Maerska (gdzie wdrożenie pojedynczej zmiany trwało 42 tygodnie, z czego samo kodowanie zaledwie 5 dni) oraz o tym, jak mierzyć efektywność zespołów, by nie wpaść w pułapkę metryk typu liczba linii kodu czy story pointy. Zastanawiamy się również nad prowokacyjną tezą: czy w epoce błyskawicznej generacji kodu hejtowany przez lata Waterfall i precyzyjne zbieranie wymagań z pomocą narzędzi takich jak Figma nie wrócą do łask, a mikroserwisy nie ustąpią miejsca dobrze zaprojektowanym monolitom? Rozdziały: 00:00 Wstęp: Suchar na start i czy jesteś już 100x deweloperem? 01:05 4 filary szybszego dostarczania: Output, Time to Market, mniej błędów i koszty 04:05 Czy da się to zmierzyć? Story pointy, kartki w backlogu i problem mierzalności 06:50 Realny deployment: Software medyczny vs specyfika e-commerce i Allegro 10:54 Jakość a nie jakość: Deweloperzy wreszcie klikają we własny soft i łapią błędy 13:20 Koniec silosów: Front vs Back – deweloperzy wychodzą poza swoje bańki 16:05 Paradoks Maerska: 42 tygodnie na zmianę, z czego tylko 5 dni kodowania 19:10 Prawdziwe wąskie gardła: Zrozumienie raportu, testy z użytkownikami i UX 22:22 Projektowanie od zera: Weryfikacja tożsamości gestem, bezpieczeństwo i on-prem 24:15 Produkt vs Konsulting: Ładowanie na taczkę i presja dowożenia sprintów 25:52 Przesunięcie wąskiego gardła: UAT-y, weryfikacja kodu i czy agent ma sprawdzać agenta? 27:18 Nowy podział ról: Mniej devów, więcej QA i analityków? 28:18 Mierzenie efektywności: Jak mierzyć postęp i pułapki metryk (Dostajesz to, co mierzysz) 31:57 Czy Waterfall wraca? Tydzień zamiast roku – renesans dokładnej analizy wymagań 34:39 Figma i nowoczesne narzędzia: Mockupy zamiast Painta i czy jeden prompt wystarczy dla banku? 38:10 Zmierzch mikroserwisów? Powrót do monolitu, gdy jeden zespół i agenci ogarniają całość 40:54 Nowa rola inżyniera: Nie bądź zombie patrzącym w licznik tokenów 42:14 Metafora taczki: Czas na myślenie i rozwiązywanie realnych problemów biznesowych 44:06 Zakończenie: Poszukiwany designer na kolejny odcinek i podsumowanie#betterdevclub #sdlc #programowanie #ai #coding #agile #waterfall #qa #codereview #figma #mikroserwisy #monolit #dora #developer