Mentionsy Mentionsy
Patoarchitekci
Patoarchitekci

Good enough definiujesz ty, nie agent - SDLC z AI

02.10.2026 ·46 min 48 s · 12 rozdziałów

"Jeżeli chodzi o architekturę, nie pozwalam mu podejmować żadnych decyzji." 🎯 Łukasz stawia granicę, a Szymon kontruje: "pozwólmy tym agentom robić ten kod, który jest krótkowzroczny" - i raz na pięć iteracji każmy zrobić refactor. Przechodzimy SDLC z AI fazę po fazie, od zbierania wymagań do życia po deployu. Na wejściu AI tylko wspomaga - "nie pójdzie do legala, do procurementu" i nie odsiedzi dupogodzin na spotkaniach. Dalej: linki do chatów od biznesu zamiast przepakowanych wymagań, powrót Enterprise Architecta i YAML jako formalny output specyfikacji. Plus prototypy klikane przez biznes, których nie negujesz - ale kod i tak idzie do kosza. ⚠️ Potem twarda część: harness to nie pliki MD, tylko hooki, lintery i SonarQube, których agent nie ominie. Frontend przechodzi testy - OK, skasujesz i wygenerujesz na nowo. Logika biznesowa - review. Agent SRE na read only halucynuje, a z pełnymi uprawnieniami stwierdzi, że "buga nie będzie jak będzie baza pusta". 🤖 Na deser koszty tokenów (150-300 dolarów na DevOpsa, od 300 na developera), mBankowe 3-4% wpływu AI na cały proces i złośliwa puenta: "Jakbyś miał dobry proces, to byłeś już gotowy." Kto definiuje good enough - Ty czy agent?     A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami.     Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech   - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia     00:00:00 Intro 00:01:44 Zbieranie wymagań: kontekst, chaty od biznesu i formalny output 00:10:47 PoC i MVP budowane przez biznes — jak na to reagować 00:12:33 Faza projektu: krótkowzroczny kod agenta i long term maintainable code 00:15:11 Przygotowanie środowiska pracy, harness i workflow zespołu 00:18:30 Dekompozycja na zadania, architektura, granice i good enough 00:23:44 Wytwarzanie: skala szarości, frontend, logika biznesowa i frameworki 00:31:05 Ownership kodu, odpowiedzialność za outcome i myślenie holistyczne 00:34:24 Dostarczanie i życie po deployu: release'y, agenci SRE, halucynacje 00:40:32 Utrzymanie i ewolucja: aktualizacje, martwy kod i decommissioning 00:42:30 Mity, koszty tokenów i dobry proces jako gotowość na agentów 00:45:34 Podsumowanie i zakończenie

0:00 · Wprowadzenie i tematyka odcinka 1

Prowadzą Łukasz Kołużny i Szymon Warda. No dobrze, Szymuś, to co dzisiaj w odcinku? Bo wymyśliłeś strukturę i wywróciłeś wszystko do góry nogami. Dobrze, Łukaszu, mój misiupysiu. O czym będzie? Przychodzimy trochę, idziemy w dół właściwie. Mieliśmy odcinek o tym, jak ubrać, powiedzmy, jaja w software developmencie, to teraz sobie powiemy o temacie, którego ty trochę mnie lubisz, a ja trochę bardziej wierzę, choć dalej nie jest to vibe coding. Włożenie I realne spojrzenie, jak obecnie wygląda nasz cały proces SDLC, jeżeli chodzi z punktu widzenia powiedzmy takiego seniora, powiedzmy. Seniora i też dzisiaj nie technikalia. Powiedzmy sobie, zarezerwowaliśmy sobie na oddzielny odcinek Spec-Driven Development, czym on jest, dzisiaj też to poruszymy jeszcze raz.

10:27 · Rola agentów w procesie 1

Agent myśli tutaj bardzo krótkofalowo, myśli tylko w tym kontekście i tak dalej. A moja myśl często jest taka. Przez te dziesiątki lat naszego kombinowania, a co będzie, jeżeli będziemy chcieli usunąć bazę danych, co będzie, jeżeli będziemy chcieli, to nagle te nasze proste krudy, które mogłyby być naprawdę krudami, mają więcej abstrakcji, interfejsów i innych rzeczy niż pól na formularzu. I wiesz co, tutaj wrzucimy na ekran komentarz Dominika na Spotify. Czytaliście, why software factories fail? Obecnie modele nie są w ogóle trenowane do tworzenia long-term maintainable code i nie potrafią też tego ocenić. I wiecie co, Dominik, ja się z tym na przykład bardzo nie zgodzę z jednej prostej przyczyny.

15:12 · Przygotowanie środowiska pracy 1

Byłem na przykład w tym, w moim eksperymencie z różnymi eksperymentami z Dirk Software Factories, sorry, ale zawsze IADS, te Thule, to zawsze wychodziło bezbłędnie. Nawet infra, jeżeli powiedziałem, jakie chcę mieć technologie i Thule, w sensie nie można było pozwolić, żeby sam wybierał Thule. To jest duże ten... Zawsze trzeba było to zaakceptować. Wiesz co, tu wychodzi mi jedna rzecz, którą chciałem zaznaczyć w tym odcinku. Ocinek nagrywamy na tu i teraz, na ten konkretny dzień. To, że agent czegoś nie umie, albo że musimy dawać mu hernezę dalej, się zmienia za pół roku całkowicie. To jest nieaktualny fragment. To widzimy, co się zmieniło. Kiedyś musiałem mówić, że odpalił krytyków. I w sensie, jakie kryteria sprawdzenia, co mają zrobić, jak mają być, jak ma szacować ich wynik itd.

21:19 · Architektura i granice 1

Moje pierwsze podejście do REM-u w 2010, linku kiedy wychodziło na poważnie, linku to do SQL. Nie mam pojęcia. Dawno, ale to początki naszej kariery. To jest taki stan, powiedzmy, nie powiedział, że to jest ORM dzisiaj, tylko ORM z początków naszej kariery. Dobra, idziemy do wytwarzania. Tu jest, możemy powiedzieć, może nie tylko, że dark factory, ale takie naprawdę przyciemnione bardzo mocno. Dobra, jeżeli popatrzymy sobie tak, implementacja, testy, code review, integracja i merge, build i CI. Teraz tak, od roboty DevOpsowej Zostaje nam w tym momencie opisz, co chcę, jakie mam wymagania i review tego.

27:33 · Implementacja i testy 1

I wiesz co, i tak, czyli wytworzenie... To nie jest znowu Dark Factories, tak jakby wszyscy chcieli, że zadzieje się automatycznie. To jest człowiek na wejściu, który potrafi albo z projektu potrafi zrobić specyfikację i ją zreviewować i potrafi odebrać wyniki. O, ale teraz dochodzimy do tematu, który jest dla mnie bardzo ważny. Największy problem jaki jest, to jest ownership tego wszystkiego. Większość ludzi po prostu wklepie prompt i odpowiedź przykleja dalej. To samo się dzieje u deweloperów, a już ownership tego kodu, który się wytworzył, czy on jest dobry, a czy miał robić to, co powinien robić, jest prawie zerowy. Ale dobra Szymon, to powiedzmy sobie wprost,

35:38 · Access Control and Testing 1

Niektórzy traktują już pisanie kodu, że to jest jak zwierzęca praca, że mu każą ręcznie pisać kod. Znaczy, no, myślimy, tym takim opcji jak najbardziej dark, to to są naprawdę duże koszty. I moim zdaniem nie ma to Zależy gdzie. Wydaje mi się, że teraz... Czekaj, czekaj. Trzeba tam powoli dążyć, ale to nie... Nie, raczej nie, to nie ma... Wiesz co, dla mnie to się... Jak ja widzę te wys... ten... jest te... Ile przynoszą produkty z Dersoft Factories? Minus 1000 dolarów miesięcznie. Tak, zgadza się. Ale mój warunek... warunek...

Pokazano wszystkie 6 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.