O czym jest ten film
- Zapis dwugodzinnego warsztatu „AI Native Engineering Org”, pokazującego przejście od tradycyjnego cyklu wytwarzania oprogramowania (SDLC) do takiego, w którym agent kodujący jest wpięty w każdy etap.
- Diagnoza problemu: „miraż produktywności” — inżynierowie czują się o 20% szybsi z asystentami AI, a w rzeczywistości są o 19% wolniejsi, bo naprawiają błędy modelu.
- Kluczowa teza: nie wdrażaj gotowych, opiniotwórczych frameworków — wprowadzaj AI do procesu, który już masz, na bazie lekkiego szablonu.
- Pojęcie „warstwy AI” (AI layer): reguły globalne, skille, subagenci, serwery MCP, hooki i LSP — wszystko wersjonowane razem z kodem.
- Demonstracja na żywo na realnym, „brownfieldowym” repozytorium aplikacji do umawiania spotkań, które startuje bez jakiejkolwiek konfiguracji AI.
- Rola product managera: skill
/spec, który czyta PRD z Confluence i tworzy tickety w Jirze przez serwer MCP Atlassiana. - Rola developera: pętla R-PIV — research (
/prime), plan (/plan-feature), implement (/execute), validate — z bramkami kontroli człowieka między krokami. - Poziomy dojrzałości pracy z agentami (1–5) i argument, dlaczego poziom trzeci jest właściwym celem, a „dark factory” — nie na start.
- Rola QA i przeglądu kodu: automatyczna recenzja pull requestów przez Claude Code w GitHub Actions jako uzupełnienie, nie zamiennik człowieka.
- „Ewolucja systemu”: każdy błąd agenta traktuj jako powód do poprawy reguł lub skilli, a nie tylko do naprawy kodu.
Redakcyjne tłumaczenie
Wstęp — po co ten warsztat
Kilka tygodni temu poprowadziłem warsztat „AI Native Engineering Org”, na którym pokazywałem, jak przestawić cały cykl wytwarzania oprogramowania na pracę z AI i jak wypracować zespołowy standard korzystania z agentów kodujących, żeby wszyscy grali do jednej bramki. Jeśli prowadzisz organizację inżynierską albo zespół i chcesz podnieść produktywność wszystkich dzięki AI — albo po prostu chcesz zobaczyć, jak agenty kodujące skalują się do poziomu przedsiębiorstwa — to jest materiał dla ciebie. Publikuję to nagranie na kanale, bo dawno nie miałem sesji tak gęstej od konkretów.
Witam wszystkich na warsztacie. Mamy dwie godziny, sporo czasu na pytania i chcę, żeby to było naprawdę interaktywne. Mój cel: pokazać, jak przejść od tradycyjnego SDLC w waszej organizacji do takiego, który jest w pełni „AI native”. Dwie godziny to zaskakująco mało, więc nie wejdę bardzo głęboko w każdy fragment cyklu, ale wejdę wystarczająco głęboko, by dać wam cały proces — punkt startowy do przekształcenia organizacji. Dotkniemy spraw product managerów, developerów i QA. Naprawdę wszystkiego, od pomysłu aż po wdrożenie i walidację na produkcji.
Kim jestem i skąd te lekcje
Jestem inżynierem oprogramowania właściwie całe życie — dosłownie od ósmego roku życia. Jeśli znacie język Scratch opracowany na MIT, to od niego zacząłem, budując jako dziecko gry. Potem gimnazjum, liceum, studia, licencjat z informatyki. Zawsze byłem człowiekiem od wszystkiego: web developer, administrator systemów, inżynier chmury.
Zawsze wiedziałem, że chcę się w czymś wyspecjalizować. Kiedy generatywna AI stała się wielkim tematem, zwłaszcza w 2023 roku, bardzo szybko zrozumiałem, że to jest to. Zacząłem budować agentów dla startupów znajomych, a w pracy — w Ameriprise Financial, firmie z listy Fortune 200, gdzie byłem inżynierem chmury — rzuciłem się na dodatkowe zadania przy pierwszych firmowych proof of conceptach z generatywną AI. AI było moim hobby i moją pracą jednocześnie.
To doprowadziło mnie do odejścia z etatu i założenia kanału na YouTube. Zacząłem w lipcu 2024 roku, hobbystycznie, a po trzech miesiącach kanał zastąpił mój dochód inżynierski. Odszedłem z pracy i dziś robię to, co zawsze chciałem, bo w głębi duszy jestem nauczycielem.
Ostatnio przeszedłem jeszcze jedną zmianę. Na początku większość przychodów mojego biznesu pochodziła z kontraktów — miałem coś w rodzaju agencji automatyzacji AI, budowałem agentów dla firm. Teraz przesunąłem się z modelu „zrobię to za ciebie” do szkoleń. Uczę organizacje, jak samodzielnie budować agentów i skutecznie korzystać z asystentów kodowania. Uczę łowić ryby, zamiast łowić je za kogoś. I dokładnie o tym jest dzisiejszy warsztat — przynoszę lekcje z pracy z dziesiątkami organizacji i pakuję je w jeden proces.
(Informacja dodatkowa: SDLC to Software Development Life Cycle — cykl życia wytwarzania oprogramowania, od zebrania wymagań, przez implementację, po testy i wdrożenie.)
Szablon, nie framework
Wszystko, co dziś pokażę, opiera się na szablonie, a nie na frameworku. Istnieje sporo otwartoźródłowych systemów na GitHubie — Claude Flow, GitHub Spec Kit i podobne. Te frameworki są dobre, ale bardzo opiniotwórcze. Znam mnóstwo organizacji, którym nie udało się ich wdrożyć, bo wymagały zmiany całego procesu. To, że chcesz iść w AI, nie znaczy, że przepisanie całego playbooka jest realistyczne.
Wolę wnosić AI do sposobu, w jaki już pracujecie — wzmacniać obecny SDLC, zamiast wyrzucać go do kosza. Zresztą wiele organizacji, z którymi pracuję, najpierw próbowało wdrożyć któryś z tych rozdmuchanych frameworków, a potem przychodzili do mnie ze słowami: „podoba nam się twoje minimalistyczne i systematyczne podejście, zacznijmy stąd, przeszkol moich inżynierów”.
Dlatego to, co pokażę, będzie miejscami wyglądać dość prosto. Nie próbuję was zwalić z nóg tym, jak bardzo zmieniamy sposób budowania oprogramowania. Największa zmiana to delegowanie agentowi tyle kodowania, ile się tylko da. Ale cały przepływ od PM-a przez developera do QA zachowa bardzo znajomy kształt. I robię to celowo.
Miraż produktywności
Wiele organizacji już próbuje wdrażać asystentów kodowania — i robi to źle. Tego chcę wam pomóc uniknąć.
Kilka badań z ostatnich lat pokazuje, że przeciętnie inżynierowie czują się o 20% szybsi, gdy używają asystentów AI, a w rzeczywistości są o 19% wolniejsi. Te statystyki cytuje się bez przerwy na YouTube i LinkedInie. To trochę szalone: ludzie myślą, że są szybsi, bo AI pisze część albo całość kodu, ale faktycznie są wolniejsi, bo poprawiają mnóstwo błędów i mierzą się ze „slopem” — kodem, który po prostu nie działa.
To jest właśnie miraż produktywności: myślisz, że jest lepiej, a jest wolniej. Druga niewesoła statystyka: 84% inżynierów na świecie już w jakiejś formie korzysta z AI przy kodowaniu, ale spośród nich tylko 46% naprawdę ufa asystentom kodowania. Mamy więc dziwny rozjazd — prawie wszyscy używają narzędzia, któremu mniej niż połowa ufa. Pytanie brzmi: dlaczego i co z tym zrobić?
Jak wygląda praca bez systemu
Pokażę wam, co dziś robi wielu inżynierów — widziałem to w organizacjach, także dużych, kiedy przychodziłem im pomóc.
Wejściem dla inżyniera jest zwykle coś od product managera: epik w postaci dokumentu w Confluence, PRD. Potem PM ręcznie rozbija to na tickety w Jirze czy Linearze, przypisuje story pointy, odbywa spotkania, żeby ustalić szczegóły techniczne z developerem. Jeśli pracowaliście w jakiejkolwiek organizacji, znacie ten proces.
Następnie developer bierze jeden ticket i wysyła do agenta bardzo prosty prompt: „oto opis z ticketa, zbuduj to”. Dla części z was to brzmi naiwnie, ale bylibyście zdziwieni, jak często to widuję. Ludzie w ogóle nie zastanawiają się, jaki mają workflow, jakie reguły i konwencje chcą przekazać agentowi. Po prostu rzucają się do implementacji.
I stąd bierze się brak zaufania. Jeśli nie dajesz agentowi barierek ochronnych i wytycznych, wróci ci bałagan. Miraż produktywności bierze się z tego, że kod powstaje szybko, ale kiedy zaczynasz go przeglądać, znajdujesz masę błędów i tracisz na poprawki więcej czasu, niż zaoszczędziłeś na pisaniu. Powtórzę: kiedy nie masz systemu, tracisz na naprawianie błędów AI więcej czasu, niż zyskujesz na tym, że AI pisze kod.
Inżynier w końcu to zauważa, miraż pryska i stwierdza: „nie ufam już agentom kodującym”. A prawda jest taka, że nigdy nie dał agentowi uczciwej szansy — nie miał systemu. Reszta warsztatu jest o budowaniu tego systemu.
Punkt wyjścia: prawdziwe repozytorium bez AI
Obiecałem, że będziemy pracować na prawdziwym, brownfieldowym repozytorium, które nie ma nic wspólnego z AI, i uczynimy je AI native.
(Informacja dodatkowa: „brownfield” to istniejąca, rozwijana od lat baza kodu — w odróżnieniu od „greenfield”, czyli projektu pisanego od zera.)
Aplikacja nie jest wdrożona na produkcję, ale to uproszczona wersja czegoś, co realnie pomagałem budować — nie jest to głupiutkie demo. To narzędzie do umawiania spotkań: tworzysz spotkania, zarządzasz kalendarzem, widzisz osoby, które się z tobą umawiają.
Kod trzymamy w repozytorium GitHuba, zadania w Jirze, dokumentację w Confluence. Ta baza kodu nie ma dziś nic z AI: żadnych reguł globalnych, żadnych skilli, żadnych hooków. Wyobraźcie sobie, że wasza organizacja rozwija ten kod od lat i dopiero teraz próbujecie zastosować do niego AI.
Na wejściu mamy PRD na inicjatywę trzeciego kwartału. Product manager odbył spotkania z interesariuszami i spisał: to są nasze cele na ten kwartał, a tego nie robimy. To jest wejście do naszej pracy.
Bez procesu AI native PM tworzy tickety ręcznie: mamy epik w Jirze i pojedyncze zadania, na przykład dodanie eksportu do CSV na stronie spotkań. Developer bierze opis ticketa, może też jakiś tech spec, wkleja to wszystko do agenta i pisze „zaimplementuj ten ticket”. To jest właśnie vibe coding. Wpadają w to nawet doświadczeni inżynierowie, kiedy zrobią się leniwi i wysyłają żądanie bez zastanowienia, jak zaplanują pracę z agentem, jak zbudują aparat walidacyjny, jak podłączą go do Jiry, żeby na przykład dodał komentarz po utworzeniu pull requesta.
Ta prośba może zadziałać, zwłaszcza przy prostym tickecie. Ale chodzi o to, że agent nawet jeśli wykona zadanie poprawnie, nie będzie trzymał się waszych konwencji — nic nie zostało udokumentowane. Nie jest podłączony do waszych platform, więc nie doda komentarza w Jirze. To będzie bardzo odłączony fragment procesu. Owszem, używamy asystenta AI wewnątrz SDLC, bo developer nim buduje, ale nie wplataliśmy go w to, jak wasi inżynierowie już pracują. Agent kodujący powinien być przedłużeniem developera, a tu wygląda jak jednorazowe narzędzie do napisania kodu.
Czym jest warstwa AI
Kiedy sprawiasz, że baza kodu jest AI native, wbudowujesz w nią sześć rzeczy:
- Reguły globalne — jak agent ma pracować, jakie są nasze wzorce i konwencje nazewnicze.
- Skille — nasze workflowy, czyli powtarzalne prompty. To główna zawartość szablonu startowego.
- Subagenci — pracownicy, którym można delegować zadania.
- Serwery MCP — połączenia agenta z platformami: Jirą, Confluence, bazą danych.
- Hooki — sposób na wbudowanie gwarancji: coś zawsze się wydarzy, gdy agent ma wywołać narzędzie albo gdy sesja się kończy. Dobre miejsce na bezpieczeństwo i barierki ochronne.
- LSP — lepsze wyszukiwanie w kodzie, szczególnie istotne przy dużych bazach z tysiącami plików.
Hooki i LSP wykraczają dziś poza zakres. Skupimy się na czterech: regułach globalnych, skillach, subagentach i serwerach MCP.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard łączenia modeli i agentów z zewnętrznymi systemami. LSP — Language Server Protocol — to standard, dzięki któremu edytory rozumieją strukturę kodu, np. gdzie zdefiniowano dany symbol.)
I najważniejsze: to wszystko wrzucamy do repozytorium. Przed generatywną AI baza kodu miała dwie części: kod i testy. Ta para trafiała do GitHuba, GitLaba czy Bitbucketa. Teraz mamy trzecią część i nazywam ją warstwą AI. Konfiguracja MCP, reguły globalne, skille — to jest warstwa AI. Zachęcam, byście wersjonowali ją tak samo jak testy, bo wtedy cały zespół pracuje na dokładnie tych samych workflowach, ograniczeniach, konwencjach i połączeniach.
Znam zespoły, które są zwolennikami „czystej” bazy kodu i wolą trzymać warstwę AI w osobnym repozytorium albo w magazynie artefaktów, jak Artifactory czy bucket S3. Możecie tak zrobić, ale dla prostoty naprawdę zachęcam, by umieszczać ją bezpośrednio w tej bazie kodu, której dotyczy. Robicie tak przecież z testami.
I to jest chyba najważniejsza rzecz z całego warsztatu. Jeżeli chcecie, by wszyscy używali agentów w ten sam sposób, doprowadźcie do sytuacji, w której ktokolwiek — PM, inżynier, osoba z QA — otwiera repozytorium, uruchamia agenta i od razu ma wszystkie reguły i skille, których używają pozostali. Zero konfiguracji. Nie trzeba nikogo prosić o instalowanie reguł ani pobieranie workflowów. Wtedy próg wejścia jest praktycznie zerowy.
To był największy przełom w organizacjach, którym pomagałem. Wszyscy u was już eksperymentują z AI, ale — jak mówiłem — vibe kodują, każdy po swojemu. Zanim osiągniecie najlepsze wyniki, trzeba doprowadzić do tego, żeby wszyscy byli na tej samej stronie co do sposobu używania tych narzędzi. To dwuetapowy proces: zrozumieć warstwę AI i system, a potem zbudować ją bezpośrednio w repozytorium.
Instalacja szablonu i pierwsze reguły
Zaczynamy od zainstalowania szablonu startowego (AI layer starter pack) na bazie kodu, która nie ma nic. To kilka prostych poleceń: kopiujemy katalog .claude ze skillami, konfigurację MCP, która wepnie nas w Confluence i Jirę, oraz katalog .github z workflowem przeglądu pull requestów, do którego wrócimy na końcu.
Ale nie możemy od razu zacząć korzystać. Najbardziej fundamentalna część warstwy AI to reguły. Otwieram więc świeżą sesję Claude Code i uruchamiam skill /create-rules.
Jeśli zajrzycie do katalogu skilli w szablonie, znajdziecie tam workflowy na praktycznie każdy etap cyklu wytwarzania. Dla product managerów jest skill do tworzenia PRD — sesja burzy mózgów z agentem, z której powstaje ustrukturyzowany dokument do zapisania w Confluence. Jest skill do planowania funkcji. Jest skill spec, którym z PRD zrobimy pojedyncze tickety dla developerów. Chodzi o to, żeby każdy element SDLC miał odpowiadający mu workflow w postaci skilla.
Dla tych, którzy nie znają skilli: to po prostu wielokrotnego użytku prompty. Bierzesz swój workflow — „tak lubię planować”, „tak lubię walidować” — i pakujesz go w prompt. Kiedy wywołuję skill, podaję agentowi zestaw instrukcji do wykonania. Zysk jest podwójny: nie muszę w kółko przepisywać tego samego promptu, a gdy skill działa dobrze, mogę go dać innym. Powstaje standard tego, jak zespół realizuje każdy etap SDLC z agentem.
W Claude Code wywołanie to po prostu ukośnik i nazwa skilla: /create-rules. Instrukcje z pliku SKILL.md trafiają wprost do kontekstu agenta i agent przechodzi przez workflow. Ten skill zadziała niezależnie od tego, jakiego agenta używacie — może trzeba będzie tylko zmienić lokalizację pliku, zależnie od narzędzia. W Claude Code to >/SKILL.md, część narzędzi obsługuje ten sam katalog. A jak nie, wystarczy poprosić agenta, żeby przeniósł skill pod wasze narzędzie — to jeden prompt.
W tym momencie agent przechodzi po bazie kodu, czyta ją i buduje zrozumienie, żeby udokumentować, jak kod działa oraz jakie mamy ograniczenia i konwencje. Przy większej bazie kodu to miejsce, gdzie można użyć subagentów, by zrównoleglić dokumentowanie. Płacimy tokenami i wysiłkiem raz, z góry, żeby już nigdy nie powtarzać głębokiego researchu — a każda kolejna sesja agenta ma to samo rozumienie kodu.
Reguły globalne mają być chude
Powstał nam plik CLAUDE.md. I ważna rzecz: pilnujcie, żeby nie było w nim za dużo. Kontekst z tego pliku ładuje się do każdej sesji agenta. Nie chcemy go zalać informacjami.
Może słyszeliście o zjawisku context rot, zwanym też „strefą głupoty” dużych modeli językowych. Idea jest taka: to, że model może pomieścić określoną ilość informacji, nie znaczy, że powinieneś wypełniać całe okno. Modele gubią się w nadmiarze informacji dokładnie tak jak ludzie.
Zarządzanie tokenami jest dziś w branży wielką sprawą. Agent ma mieć dostęp do kontekstu, którego potrzebuje — i do niczego więcej. Zwykle rekomenduję poniżej 300 linii w pliku reguł globalnych. Zasada w głowie brzmi tak: przy każdej linii zapytaj się, czy agent musi to wiedzieć niezależnie od tego, nad czym pracuje. Jeśli odpowiedź brzmi „to ważne, ale nie zawsze”, to prawdopodobnie nie należy do reguł globalnych. Możesz mieć inną dokumentację — pliki markdown w katalogu docs albo strony w Confluence — i wskazać je agentowi wtedy, gdy są potrzebne do bieżącego zadania.
Wszystko, czego was teraz nauczyłem, jest zapisane w samym skillu create-rules: sporządź chudy CLAUDE.md, każda reguła musi wynikać z czegoś realnego w kodzie, zostawiamy tylko to, co obowiązuje zawsze. Na tym polega piękno skilla — pakujemy nasze dobre praktyki tak, żeby nie tłumaczyć ich za każdym razem od nowa.
Ewolucja systemu
Skoro warstwa AI jest w kontroli wersji, to za każdym razem, gdy praca z agentem nie idzie po myśli, zamiast po prostu przejąć stery i naprawić problem samemu, zachęcam was i waszych inżynierów, żeby wspólnie z agentem ustalić, dlaczego ten problem w ogóle się pojawił. Co możemy poprawić w regułach albo skillach, żeby się nie powtórzył?
Traktujcie każdy błąd jako okazję do ulepszenia warstwy AI. A „ulepszenie” może dosłownie znaczyć pull request: inżynier proponuje zmianę w skillu, bo napotkał problem, a agent podpowiedział mu, że lepszy opis workflow by go uniknął. Przechodzicie przez normalny przegląd kodu — tyle że przedmiotem przeglądu jest to, jak wasze agenty pracują.
Rola PM-a: z PRD do ticketów
Wracamy do PRD. Pokazałem, jak PM tworzy tickety ręcznie. Teraz pokażę, jak może w tym pomóc agent.
Otwieram nową sesję i uruchamiam /spec. Skille przyjmują argumenty, trochę jak polecenia CLI. Podaję identyfikator strony PRD w Confluence i klucz epiku w Jirze, pod którym mają powstać zadania podrzędne. Identyfikator PRD kopiuję wprost z URL-a. Klucz epiku, powiedzmy SCHED-22, to epik planistyczny dla inicjatywy raportowo-analitycznej z trzeciego kwartału.
Warto ten workflow dostosować do siebie. Może chcecie, żeby agent przeprowadził z PM-em bardzo konkretny wywiad: jak dzielimy zakres, jak przypisujemy story pointy. Powtórzę: te skille to punkt startowy.
Sam skill mówi agentowi: wejściem jest identyfikator PRD w Confluence i klucz epiku w Jirze; krok pierwszy to wczytanie PRD przez serwer MCP Atlassiana, dla którego uwierzytelnienie mam skonfigurowane wcześniej. Zrobiłem też opcję, w której zamiast strony Confluence można wskazać dokument markdown — sporo osób woli trzymać wszystko w markdownie. Choć większość organizacji pracuje w Confluence, Notionie czy podobnym narzędziu chmurowym i dlatego zwykle warto zrobić to połączenie.
Żeby podłączyć agenta do Atlassiana, wystarczyło skonfigurować jeden serwer MCP. Praktycznie każde połączenie ze światem zewnętrznym robi się dziś przez MCP, bo większość platform — Atlassian, Notion, GitLab — ma oficjalnie wspierany serwer. Platformy analityczne, jak Sentry czy PostHog, też je mają. To już standard. Powiedziałbym nawet więcej: jeśli wasza platforma nie ma serwera MCP, to prawdopodobnie warto jej unikać, bo to znaczy, że nie nadąża za czasami.
Te serwery mają zwykle bardzo prostą stronę dokumentacji z instrukcją instalacji dla poszczególnych agentów — rozwijana lista, gdzie wybieracie Claude Code albo Codex i kopiujecie polecenie. Przy pierwszym użyciu trzeba się uwierzytelnić. W Claude Code wpisuję /mcp, widzę podłączony serwer Atlassiana, wciskam enter i uruchamia się przepływ OAuth w przeglądarce. Prościej się nie da.
Agent wywołał serwer, pobrał PRD i epik, a potem przeszedł przez resztę procesu: najpierw wypisał markdown, potem znów wywołał MCP, żeby utworzyć strony w Confluence i tickety w Jirze. Po odświeżeniu Jiry widzę wszystkie utworzone zadania podrzędne pod epikiem 22.
To akurat jest bardziej autonomiczne, niż byście prawdopodobnie chcieli. Normalnie agent powinien porozmawiać z product managerem i pomóc mu przemyśleć podział na tickety. Ze wszystkiego, co dziś pokazuję, to najlepszy przykład na to, że skill jest punktem wyjścia, a nie gotowcem — PM raczej nie uruchomi /spec i nie uzna sprawy za zamkniętą. Chodziło mi o pokazanie, że agent, mając wskazówki z warstwy AI, potrafi wziąć PRD, wywnioskować, jaka praca jest do zrobienia, i podzielić ją na kęsy, które developerzy wezmą pojedynczo. Ten workflow można rozbudować dowolnie: analiza story pointów, mapowanie zależności, wskazanie, że trzy tickety nie mają zależności, więc jeden developer może puścić na nich trzy agenty równolegle.
Poziomy dojrzałości pracy z agentami
Padło pytanie o różnicę między „AI assisted” a „AI native”. Warto tu użyć skali poziomów.
Poziom pierwszy i drugi to mniej więcej vibe coding, który pokazałem na początku: wysyłasz żądanie, agent robi trochę roboty, ale i tak musisz mocno trzymać stery.
Poziom trzeci to miejsce, w którym powinna być większość ludzi i o którym w zasadzie jest ten warsztat. Budujesz warstwę AI, masz ograniczenia i konwencje udokumentowane w regułach, workflowy w skillach. Celem jest, żeby agent pisał dosłownie cały kod. My robimy planowanie i walidację, więc to nie jest vibe coding — ale budujemy system, w którym agent ma cały kontekst i wszystkie workflowy potrzebne, żeby napisać każdy wiersz. Sam nie napisałem osobiście linijki kodu od ponad roku. Brzmi to szalenie, bo od ósmego roku życia do zeszłego roku pisałem setki linii dziennie. Teraz nie piszę ani jednej, bo żyję na poziomie trzecim.
Poziom czwarty i piąty to prawdziwa autonomia: agent realizuje cały epik od początku do końca, a ty wysiadasz z fotela kierowcy coraz bardziej. Żeby zaufać agentowi na tym poziomie, musisz mieć naprawdę dobry system — dlatego zwykle rekomenduję zostanie na poziomie trzecim. To złoty środek: nie jesteś już tylko wspomagany AI, jesteś AI native, ale nie budujesz jeszcze wymyślnej „ciemnej fabryki”.
(Informacja dodatkowa: „dark factory” to metafora z przemysłu — zakład tak zautomatyzowany, że może pracować przy zgaszonym świetle, bo nie ma w nim ludzi. W kontekście oprogramowania: wysyłasz specyfikację, dostajesz gotowy kod, bez człowieka pośrodku.)
Niektóre organizacje zaczynają tam docierać, ale nie można od tego zacząć. Przejście na AI native nie polega na skoku z zerowej warstwy AI wprost do „spec na wejściu, wdrożony kod na wyjściu”. Człowiek musi być w pętli, kiedy budujesz system — po to, żebyś to ty prowadził agenta, a nie puszczał go samopas przez cały epik. To po prostu nie będzie niezawodne.
Dlaczego Jira, a nie issues w GitHubie
Padło pytanie: po co Jira, skoro tickety mogą być issues w GitHubie? Można używać issues, to kwestia wyboru. Problem z issues jest taki, że są bardzo developerocentryczne. W większej organizacji, gdzie na to, co robimy dalej, patrzą PM-owie i interesariusze, ci ludzie nie chcą mieszkać w GitHub Issues. Jira ma dużo funkcji potrzebnych rolom nietechnicznym i linkowanie do Confluence. Issues świetnie sprawdzają się w projektach open source albo w zespołach złożonych z samych inżynierów, ale słabo skalują się na wiele ról.
Nie pamiętam dokładnej liczby, ale chyba 60–70% średnich i dużych firm używa Jiry i Confluence. Dlatego wybrałem je do przykładu — większość firm, z którymi pracuję, i większość z was ich używa.
Analogicznie z narzędziem do kodowania: wszystko, co omawiam, jest niezależne od modelu i narzędzia. Nie ma znaczenia, czy używacie Claude Code, GitHub Copilota czy Codeksa. Musiałem wybrać jedno do demonstracji i wybrałem Claude Code, bo z niego faktycznie korzystam codziennie. Około 90% organizacji korzystających z asystentów kodowania ma umowę korporacyjną z Anthropikiem, a Claude Code jest zdecydowanie najpopularniejszym narzędziem. To narzędzie, które polecam, ale inne — jak Codex — nie są daleko w tyle. Pracowałem też z wieloma firmami używającymi Cursora.
Pętla R-PIV: research, plan, implement, validate
Mamy tickety, więc jako developer wybieram jeden. Weźmy numer trzy: dodanie eksportu do CSV na stronie spotkań. Wyobraźmy sobie, że PM z pomocą agenta stworzył do tego stronę ze specyfikacją techniczną — to ten sam dokument, który wcześniej wkleiłem do agenta w przykładzie z vibe codingiem.
Ale tym razem nie kopiujemy ticketa i nie prosimy o implementację. Zaczynamy od skilla prime.
Kiedy zaczynasz jako developer nowy kawałek pracy, zawsze polecam zacząć czymś takim. Prime przeprowadza agenta przez workflow: pobiera ticket z Jiry, a potem eksploruje bazę kodu, żeby ustalić przynajmniej na wysokim poziomie, jak podeszlibyśmy do implementacji. Wywołuję /prime z dwoma parametrami: identyfikatorem ticketa w Jirze i — opcjonalnie — identyfikatorem towarzyszącego dokumentu w Confluence. Jeśli opis ticketa i tak do niego linkuje, agent zwykle sam się domyśli, żeby go przeczytać. Agenty są elastyczne, nie musicie być drobiazgowi.
Ten rdzeń nazywam pętlą PIV — od plan, implement, validate. Ostatnio dodaję do tego R, więc mówię o pętli R-PIV, bo priming to w gruncie rzeczy research. Zbadaj pomysł, zaplanuj implementację, przekaż agentowi do wykonania, dopilnuj walidacji. Tyle. Jeśli każdy inżynier przechodzi przez research, plan, implementację i walidację, jesteście ustawieni. A mamy skille na każdy z tych kroków, żeby proces był powtarzalny między ludźmi.
Rozmowa przed planem: zbijanie założeń
Zanim przejdziemy do planowania, jest miejsce na rozmowę z agentem. Choć używamy skilli do prowadzenia agenta przez workflow, nie wywołujemy ich jeden po drugim jak automat — musimy być częścią procesu.
Włączam narzędzie zamiany mowy na tekst — używam AquaVoice, ale są też Whisper, Epicenter Whispering i inne, część open source i darmowa. Bardzo zachęcam, żeby dać każdemu w zespole narzędzie speech-to-text, bo pozwala wrzucić myśli do agenta znacznie szybciej niż pisanie. W części agentów, w tym w Claude Code, jest już wbudowany tryb głosowy.
Mówię więc do agenta: „Skoro masz już cały kontekst tego ticketa, pomóż mi przemyśleć, jak to zbudujemy. Upewnij się, że rozumiesz kod w zakresie związanym z ticketem, a potem mnie przemaglituj — przeprowadź ze mną wywiad, zadaj mnóstwo pytań, żebyśmy byli zgodni co do wszystkiego w tej implementacji”.
Powód, dla którego każę mu zadawać pytania, jest kluczowy: twoim zadaniem numer jeden przy planowaniu z agentem jest zmniejszenie liczby założeń, które agent przyjmuje. Powtórzę: twoim zadaniem numer jeden jest redukcja jego założeń. Bo to, co wykłada vibe coding, to zwykle nie jest zły kod, tylko kod niezgodny z tym, czego chciałeś. Agent nie rozumie dokładnie, o co ci chodzi.
Dlatego nie można wysłać żądania bez kontekstu. Poświęcamy na planowanie dużo czasu — mija sporo, zanim napiszemy pierwszą linijkę kodu — i to jest w pełni celowe. Najpierw ustawiamy warstwę AI, czyli reguły i konwencje najwyższego poziomu, a potem konwencje specyficzne dla zadania. Mamy więc dwie warstwy planowania: warstwę AI dla wszystkiego i bieżącą rozmowę dla tej konkretnej roboty.
Ciekawe jest to, że choć agenty potrafią przyjmować fatalne założenia i mówić o nich z pełną pewnością siebie, to jednocześnie są całkiem dobre w rozpoznawaniu, jakie założenia właśnie przyjmują. Kiedy poprosisz je o wskazanie miejsc, w których możecie się nie rozumieć, robią to naprawdę nieźle.
W demonstracji agent wygenerował listę 28 pytań, co było nawet dla mnie zaskakujące — zwykle jest ich mniej niż dwadzieścia. Ze względu na czas poprosiłem, żeby zadał mi cztery, korzystając z narzędzia pytań do użytkownika. Ale naprawdę warto poświęcić na to czas: każde dobrze odpowiedziane pytanie to jedno założenie mniej po stronie agenta. Wszystkie te decyzje przejdą potem do ustrukturyzowanego planu, więc agent będzie osadzony w tym, jak faktycznie chcemy to zrobić.
Im bardziej jesteś techniczny, tym lepiej odpowiesz. Ale nawet jeśli jesteś PM-em, możesz porozmawiać z agentem i poprosić: pomóż mi zrozumieć opcje, jakie są plusy i minusy. Możesz drążyć planowanie tak głęboko, jak potrzebujesz, bo i ty, i agent musicie być pewni tego, co budujecie, zanim zaufacie mu z pisaniem kodu. Jedynym powodem, dla którego w ogóle możemy z czystym sumieniem oddać kodowanie agentowi, jest to, ile wkładamy w planowanie z góry.
Mały samorodek: większość agentów ma dziś narzędzie do zadawania pytań użytkownikowi w formacie wielokrotnego wyboru. Można dodać notatki, podyskutować, jeśli żadna opcja nie pasuje, albo po prostu przyjąć rekomendację. Rekomendacje często są dobre, więc nawet 28 pytań da się przeklikać w kilka minut — chyba że agent naprawdę idzie w złą stronę. To najlepszy sposób, żeby zrobić to szybko bez utraty jakości.
Plan jako artefakt
Wywołuję /plan-feature. Można podać opis tego, co chcemy zbudować, ale ja opieram się na bieżącej rozmowie, więc nie muszę nic doprecyzowywać.
Pomyślcie o tym tak: bierzemy naszą nieustrukturyzowaną, swobodną rozmowę — może dwudziesto-, trzydziestominutową — i zamieniamy ją w ustrukturyzowany plan działania. Zwykle przy jakimkolwiek tickecie większym niż jeden story point warto poświęcić dobre 20–30 minut na rozmowę z agentem, zanim uruchomicie ten skill. Bo od tego momentu deklarujemy: to jest to, co zbudujemy, gdy przekażemy plan kolejnemu agentowi.
Skill opisuje krok po kroku proces planowania i — co najważniejsze — strukturę dokumentu. Każdy plan ma mieć: opis funkcji, historyjkę użytkownika, sformułowanie problemu, referencje do kontekstu, który agent wykonawczy ma przeczytać (pliki zidentyfikowane podczas primingu), listę nowych plików, które prawdopodobnie trzeba utworzyć, odnośniki do zewnętrznej dokumentacji, no i sam plan implementacji z listą zadań, aż do poziomu konkretnych plików do edycji i utworzenia. Nie piszemy kodu, ale podchodzimy do niego tak blisko, jak się da.
Piękno struktury w skillu polega na tym, że każdy developer, wywołując plan-feature, tworzy plan dokładnie w ten sam sposób. To znaczy, że innym inżynierom łatwo go zrecenzować. Plan sam w sobie jest artefaktem, który może przejść przegląd — zanim spalimy tokeny i czas na implementację, upewnijmy się, że jest solidny.
Zwykle nie czyta się planu linijka po linijce, bo takie dokumenty potrafią mieć i tysiąc wierszy, ale trzeba przejść sekcja po sekcji i sprawdzić, czy wszystko się zgadza: czy historyjka użytkownika opisuje to, co naprawdę chcemy zbudować, i czy strategia walidacji jest dobra.
To ważna rzecz, o której jeszcze nie mówiłem: planując implementację, planujemy również sposób walidacji. „Uruchom testy jednostkowe i integracyjne. Może trzeba dopisać nowe testy. Może chcemy testów end-to-end z automatyzacją przeglądarki, żeby przejść przez aplikację tak, jak zrobiłby to użytkownik.” Może użyjemy do tego innego skilla albo serwera MCP. Komponujemy tu różne części warstwy AI: ten plan użyje tego serwera MCP do testów, a potem utworzy pull request przez CLI GitHuba.
W wygenerowanym planie widać dokładnie strukturę z skilla: historyjka użytkownika, sformułowanie problemu, cały kontekst do zreferowania, lista zadań, a na dole strategia walidacji — testy jednostkowe i integracyjne, testy end-to-end (klikamy przycisk, sprawdzamy, czy pobiera się CSV i czy jest poprawnie sformatowany), plus poziom pierwszy: składnia i styl, czyli lintowanie i sprawdzanie typów. Wszystko, co chcielibyście, żeby inżynier sprawdził przed otwarciem pull requesta, albo co normalnie robi CI, oddajemy tu agentowi. Dzięki temu może iterować, jeśli coś nie przechodzi — także testy regresyjne, które mogą się wywalić po jego zmianach. Nie ufamy agentowi na pierwszym podejściu; dajemy mu aparat do sprawdzania własnej pracy.
Najważniejsze nie jest to, żeby agent trafił implementację za pierwszym strzałem. Najważniejsze jest to, co dostajemy z powrotem, kiedy agent mówi „skończone” — nawet jeśli po drodze iterował długo. Ja nigdy nie optymalizuję swoich workflowów pod czas. Optymalizuję pod poprawność.
Plan można też wysłać do Jiry — spróbowałem dodać go jako załącznik do ticketa, ale okazało się, że serwer MCP Atlassiana tego nie obsługuje, więc alternatywa jest prosta: utworzyć stronę w Confluence i dodać do niej link w komentarzu.
Implementacja w świeżej sesji
Mając ustrukturyzowany plan, przechodzimy do skilla execute. Podajemy mu ścieżkę do dokumentu planu — albo stronę Confluence, jeśli tam go wrzuciliśmy.
Robię to w zupełnie nowej sesji agenta i główny powód to kontekst. Pamiętacie „strefę głupoty” dużych modeli? Nasza rozmowa jest już bardzo długa. Nie chcemy kontynuować w niej implementacji, bo dojście do tego jednego planu mogło kosztować setki tysięcy tokenów.
Ten plan jest w istocie dokumentem przekazania. To sposób na spakowanie całej pracy z tej sesji, żeby podać ją jako kontekst następnej. Chcemy, żeby agent zaczął od zera i nie był obciążony całym kontekstem researchu i planowania. A skoro plan zawiera wszystko, czego agent potrzebuje, to nic nie tracimy, odchodząc od tej rozmowy.
Agent od razu rusza: zweryfikował plan względem kodu, wziął zadania od pierwszego do trzeciego i pisze implementację. Na końcu zrobi walidację. Możemy kazać mu dodać komentarz w Jirze i otworzyć pull requesta, który uruchomi automatyczny przegląd.
Uwaga: nadal sami wywołujemy każdy z tych skilli, bo po drodze sprawdzamy rzeczy. Mamy bramkę przeglądu przez człowieka na etapie planu — może nawet inni inżynierowie z zespołu na niego popatrzą. A przy wykonaniu mamy bramki walidacyjne: to, co agent uruchamia sam, i to, co sprawdzamy my. Zwykle, zanim otworzycie pull requesta, przejdziecie przez aplikację i przetestujecie ją ręcznie. A jeśli jesteście technicznie mocni, warto zajrzeć w kod i zrobić szybki przegląd u siebie na maszynie. Nie pozwalamy agentowi jechać autonomicznie aż do pull requesta, bo chcemy tam kolejnej bramki człowieka.
Można oczywiście inaczej. Jeśli zbudujecie system, któremu ufacie na poziomie czwartym czy piątym, możecie zrezygnować z przeglądu planu i z ręcznej walidacji przed PR-em. Możecie połączyć te skille w łańcuch, żeby wykonywały się autonomicznie od prime prosto do pull requesta. Ja po prostu nie jestem tego fanem — przynajmniej na początku, dopóki naprawdę nie zaufacie systemowi.
Jak zachować rozumienie kodu, nie pisząc kodu
Padło pytanie: jeśli na poziomie trzecim nie piszesz już kodu, jak utrzymujesz jego rozumienie?
Po zakończeniu implementacji, kiedy waliduję i sam robię przegląd kodu — a to samo w sobie jest jednym ze sposobów na utrzymanie rozumienia — przy okazji zadaję agentowi pytania uzupełniające. „Dlaczego zdecydowałeś się na tę bibliotekę? Dlaczego zbudowałeś tę funkcję właśnie tak?” Traktuję agenta tak samo jako nauczyciela, jak i jako konia pociągowego. Agenty są naprawdę dobre w roli edukatora. Zwłaszcza jeśli jesteś mniej techniczny, zasypywanie ich pytaniami — w trakcie planowania i po implementacji — to bardzo silna strategia.
Kolejny samorodek: w Claude Code jest funkcja /by the way. Pozwala zadać szybkie pytanie z boku, bez przerywania głównej rozmowy. Mogę napisać „streść testy”, główny agent nadal pracuje nad testami, a ja mam boczną konwersację z pełnym kontekstem bieżącej sesji. Dostaję ładne streszczenie, mogę je rozgałęzić albo wyjść klawiszem Escape i wrócić tam, gdzie byłem. Korzystajcie z tego, żeby wyrzucać z siebie pytania, kiedy tylko się pojawią. Nie każdy agent ma coś takiego, ale większość nad tym pracuje — kiedy Claude Code robi coś nowego i ciekawego, reszta szybko nadąża. Wszyscy zbiegają się do tego samego zestawu funkcji i dlatego prymitywy warstwy AI — reguły, skille, subagenci, MCP, hooki — obsługuje praktycznie każdy agent.
Wiele repozytoriów, jedna warstwa AI
Ktoś zauważył, że przy dużej liczbie repozytoriów skończyli z jednym centralnym repo na skille i komendy. To dobry punkt.
Zachęcam, żeby warstwa AI była powiązana z każdą bazą kodu, ale świetnie sprawdza się też centralne repozytorium z bardziej generyczną wersją: szablon reguł globalnych, generyczne wersje skilli — na przykład skill walidacyjny, który nie jest przypisany do żadnego stosu technologicznego. Bierzesz go jako punkt wyjścia do dowolnego nowego lub brownfieldowego projektu i dostosowujesz do stosu. Dokładnie na tej zasadzie działa mój szablon startowy: to wersja generyczna, z definicji słabsza, bo najlepszą wersję dostaje się dopiero po dopasowaniu do własnego procesu, stosu i architektury. Padła też propozycja trzymania tego w dedykowanym repo i podpinania jako submoduł Gita — dobry pomysł, sam nigdy tego tak nie robiłem, ale chętnie się przyjrzę.
Pytanie o /init
Ktoś zapytał, czy create-rules to nie to samo co wbudowana komenda /init. Bardzo podobne — /init inicjalizuje CLAUDE.md z dokumentacją bazy kodu i macie ją od ręki, bez żadnych dodatkowych skilli. Wolę własny skill, bo pozwala dostroić proces do tego, jak lubię tworzyć reguły i dokumentować kod. Cokolwiek dostajecie z pudełka jest wygodne, ale nigdy nie będzie tak mocne jak coś zbudowanego samodzielnie pod wasz proces i wasz SDLC. Dlatego jestem zwolennikiem zaczynania prosto i nadbudowywania z czasem.
Pytanie o automatyczną dokumentację
Ktoś opisał system z warstwą automatycznie aktualizowanej dokumentacji wszystkich funkcji, ograniczeń i przypadków brzegowych, przeszukiwanej skryptem przy researchu każdego ticketa, i spytał, czy to przesada. Nie sądzę, brzmi świetnie. Jedyne, przed czym bym przestrzegał: jeśli „automatycznie” znaczy, że agent sam wnioskuje, co udokumentować, i po prostu to robi — to niebezpieczne. Chcielibyście bramki człowieka, żeby agent najprzód zaproponował zmiany. Wadą jest oczywiście czas potrzebny na przegląd. Kiedy każę agentowi automatycznie dokumentować albo automatycznie ulepszać warstwę AI, nigdy nie jestem zadowolony z wyniku, bo modele mają skłonność do wysypywania kontekstu — zrobią setki linii zmian tam, gdzie powinno być dwadzieścia, nawet jeśli każesz im być zwięzłymi.
Archon: automatyzacja aparatu
Padło pytanie, co daje Archon ponad zwykłe podłączenie agenta do Jiry, Confluence, GitHuba i źródeł dokumentacji.
W procesie, który pokazuję, wywołuję kolejne skille, mamy różne role, a więc i wiele sesji agenta, które sam muszę uruchamiać. Robię planowanie, potem otwieram Claude Code od nowa, muszę znaleźć dokument planu, skopiować ścieżkę, podać jako parametr. Ręcznie zestawiam każdą z tych sesji.
Archon pozwala to zautomatyzować. Budujesz aparat, w którym masz jeden workflow do uruchomienia, a ten workflow spina wszystkie sesje agentów, więc nie musisz orkiestrować na tym poziomie. Nadal możesz wbudować siebie w pętlę tam, gdzie chcesz — zaplanuj, człowiek przegląda i iteruje, potem implementuj. Łatwiej też przechodzić między modelami i dostawcami; wiele osób lubi robić implementację w Claude Code, a przegląd w Codeksie.
Trzecia rzecz to kroki deterministyczne. Czasem chcesz gwarancji, że pewien kontekst zostanie wczytany z Confluence albo że po implementacji uruchomią się konkretne testy. To, że każesz agentowi coś zrobić, nie znaczy, że to zrobi — modele są probabilistyczne i czasem ignorują instrukcje. Workflowy Archona pozwalają wbudować takie gwarancje.
Sedno pomysłu: zamiast czynić z agenta cały system, wbudowujesz agenta w system tam, gdzie to naprawdę uzasadnione. Bo nie chcesz oddawać agentowi pełnej odpowiedzialności — chcesz mieć determinizm tam, gdzie faktycznie możesz. Archon jest w pełni otwartoźródłowy i darmowy.
QA i automatyczny przegląd pull requestów
Ostatni element to automatyczne przeglądy kodu.
Gdy praca jest skończona, wysyłam do agenta prompt w stylu: „Dodaj komentarz do ticketa w Jirze, żeby zaktualizować PM-a, i otwórz pull requesta. Sam przeszedłem przez kod, przetestowałem aplikację, wygląda dobrze”.
Kiedy PR jest otwarty, uruchamia się mój workflow w GitHub Actions, który odpala Claude Code bezpośrednio w repozytorium. Na podstawie podsumowania i diffa wykonuje automatyczny przegląd. Żeby to mieć, wystarczy dodać plik workflow w katalogu .github/workflows i wgrać poświadczenia Claude Code do repozytorium. Wyzwalaczem jest otwarcie pull requesta albo komentarz @claude review. Prompt wywołuje pełny skill przeglądu kodu, bardzo dopasowany do tego, jak ja lubię recenzować: przejrzyj cały diff względem gałęzi bazowej, sprawdź poprawność, bezpieczeństwo i tak dalej, a wynik opublikuj jako jeden komentarz w PR-ze.
Robię to przy każdym pull requeście we wszystkich swoich projektach. Sens nie polega na zastąpieniu inżyniera QA czy recenzenta — nie zastępujemy, tylko wzmacniamy. Dodatkowy przelot agenta po pull requeście jest bardzo użyteczny, bo daje wszystkim recenzentom punkt startowy: na co zwrócić uwagę, jaki przepływ trzeba przetestować ręcznie. Nie mam dokładnego pomiaru, ale subiektywnie recenzuję PR-y dwa–trzy razy szybciej, bo pierwsze, co robię przy cudzym pull requeście, to czytam wynik od Claude Code. Nie ufam mu ślepo i nie merguję tylko dlatego, że napisał „wygląda dobrze” — ale to ustawia mi scenę: na co patrzę i ile czasu naprawdę muszę na to poświęcić.
Wracając do naszej implementacji: skończyła się, a agent zrobił nawet zrzuty ekranu. Dzięki skillowi obsługi przeglądarki, który wbudowałem w szablon startowy, przeszedł po stronie we własnej przeglądarce i sfotografował działającą funkcję. Przycisk „Export CSV”, którego wcześniej nie było, jest na miejscu. Można pójść dalej i kazać mu pobrać CSV i sprawdzić jego zawartość — tego akurat nie ująłem w planie, ale walidację po stronie agenta da się poprowadzić bardzo daleko.
Kiedy plan trzeba wywrócić
Ktoś opisał częstą sytuację: z PRD i architektury powstają epiki, historyjki, specyfikacje, potem PR-y, a następnie recenzent-tech lead każe zmienić coś, co fundamentalnie odbiega od pierwotnego dokumentu architektury. Trzeba więc skorygować kurs, zmienić architekturę, a za tym idą zmiany w epikach i historyjkach. Czy to część pętli PIV?
Nazwałbym to osobnym fragmentem procesu. Pętla PIV operuje na jednej wersji planu. Jeśli musisz wrócić i zmienić specyfikacje, architekturę albo PRD, to nie jesteś już w tej samej pętli — najprawdopodobniej wchodzisz w zupełnie nową pętlę R-PIV. Zależy od skali odchylenia. Ale jeśli zmiana jest na tyle duża, że trzeba zmienić dokument architektury lub PRD, to zwykle znaczy nową pętlę: primujesz na nowym PRD, planujesz zmianę i tak dalej. Ta druga pętla może być mniejsza, bo wiele pracy już wykonałeś, i możesz zostać na tej samej gałęzi, nie wyrzucając niczego. Ale to nowa pętla. Staram się utrzymać PIV jako prosty prymityw: operujesz na tickecie raz, a każda przebudowa architektury to kolejna pętla.
Jak oceniać, czy system działa
Ostatnie pytanie dotyczyło ewaluacji: jakich testów czy procesów użyć, żeby wiedzieć, czy pierwsza wersja naszego systemu AI daje dobre wyniki?
Rzecz w tym, że przechodząc na AI native, nie wyrzucamy dotychczasowego playbooka. Macie już pewnie jakiś system przeglądu pull requestów, w którym ludzie oceniają zmiany, zanim trafią na produkcję albo do gałęzi wydaniowej. To zostaje. Ludzie oceniają pull requesty dokładnie tak jak wtedy, gdy cały kod pisali ludzie. To wasz pierwszy poziom ewaluacji — ręczny. Nie musimy od razu kazać modelowi oceniać wyjścia innego modelu; możecie, jeśli chcecie iść dalej, ale na początek pytanie brzmi po prostu: czy te pull requesty są dobrej jakości, kiedy przechodzą przez końcowy przegląd?
A jeśli okazuje się, że dużo więcej PR-ów jest odrzucanych, niż przed przejściem na AI native, to jasny sygnał, że system nie działa i trzeba go dostroić.
Nie komplikowałbym tego procesu na siłę. Macie już proces ewaluacji — to wasze przeglądy kodu — po prostu prowadzicie go dalej. Jeśli naprawdę chcecie iść głębiej, robiłem coś takiego, żeby porównywać modele między sobą: system typu „model jako sędzia”, w którym recenzja ocenia pull request, ale też sprawdza, czy agent faktycznie przestrzegał reguł zapisanych w skillach i w CLAUDE.md, i przypisuje ocenę punktową. Używałem tego głównie do sprawdzania, jak różne modele trzymają się naszych konwencji, ale można to potraktować jako ogólną ocenę tego, jak działa cały system.
Podsumowanie
Przeszliśmy przez całość: od PM-a aż po przegląd na końcu. Kilka rzeczy na początku i na końcu musiałem pominąć, bo dwie godziny mijają błyskawicznie. Ale to jest pełny obraz cyklu AI native: wprowadź warstwę AI, dostosuj ją, zbuduj reguły, podziel epiki na tickety, a potem przejdź przez pętlę R-PIV — badaj, planuj, wdrażaj, waliduj. I dołóż do tego przegląd, kiedy dochodzisz do pull requesta i strony QA.
Oferuję prywatne warsztaty dla zespołów, na których prowadzę szkolenie albo pomagam zbudować warstwę AI. Przyjmuję ograniczoną liczbę firm miesięcznie. Zwrot z inwestycji przy zespołach, z którymi pracuję, przychodzi w tygodnie albo nawet dni, bo dziesiątki czy setki inżynierów zaczynają natychmiast oszczędzać godziny tygodniowo. Bierzecie na siebie tygodniowo-dwutygodniową inwestycję w zbudowanie warstwy AI, a potem zbieracie plony bez końca. Nie twierdzę, że wszystko będzie sto razy szybsze, ale poprawa będzie zauważalna dla każdego inżyniera — jeśli wszyscy pracują według jednego standardu w ramach istniejącego SDLC, wszystko pozostaje maksymalnie znajome, a jednocześnie zoptymalizowane pod AI.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Miraż produktywności jest realny — mierz go, zanim uwierzysz we własne odczucia
Na czym polega: Badania cytowane w materiale pokazują, że inżynierowie czują się o 20% szybsi z asystentami AI, a faktycznie są o 19% wolniejsi, bo naprawiają błędy. 84% inżynierów używa AI, ale tylko 46% z nich jej ufa. Odczucie prędkości i faktyczna prędkość to dwie różne rzeczy.
Jak stosować: Zanim ogłosisz w zespole sukces wdrożenia AI, sprawdź twarde sygnały: czy odsetek odrzucanych pull requestów wzrósł, czy czas od ticketa do mergea faktycznie spadł, czy liczba poprawek po review rośnie. Porównaj z okresem sprzed wdrożenia.
Na co uważać: Nie traktuj statystyk z filmu jako pomiaru swojej organizacji — u ciebie liczby mogą być inne, a autor nie podaje źródeł badań. Uważaj też, żeby sam pomiar nie stał się narzędziem oceny ludzi, bo wtedy dane zaczną kłamać.
2.Wybieraj szablon, nie framework
Na czym polega: Gotowe, mocno opiniotwórcze frameworki wymuszają zmianę całego procesu i dlatego organizacje odbijają się od nich. Autor rekomenduje lekki szablon startowy, który wnosi AI do procesu, który już masz.
Jak stosować: Zacznij od minimalnego zestawu — reguły globalne plus 3–5 skilli odpowiadających etapom, które faktycznie masz w swoim SDLC. Dopiero potem dokładaj kolejne elementy, kiedy zespół zgłosi konkretną potrzebę.
Na co uważać: „Minimalizm” nie zwalnia z jakości — źle napisany własny skill jest gorszy niż dobry framework. Zwróć też uwagę, że autor sprzedaje szkolenia i własny szablon, więc jego preferencja nie jest bezstronna; frameworki typu Spec Kit czy Superpowers sam ocenia jako dobrze działające.
3.Warstwa AI należy do repozytorium, tak jak testy
Na czym polega: Trzecia część bazy kodu — obok kodu i testów — to reguły, skille, subagenci, konfiguracja MCP i hooki. Wersjonowana razem z kodem sprawia, że każdy, kto otworzy repo, ma od razu ten sam zestaw narzędzi.
Jak stosować: Wrzuć .claude/ (albo odpowiednik) do repo i objęć go normalnym procesem przeglądu kodu. Cel: próg wejścia dla nowej osoby ma być zerowy — otwiera repo, uruchamia agenta, wszystko już działa.
Na co uważać: Nie wrzucaj tam sekretów ani poświadczeń MCP — konfiguracja tak, tokeny nie. Przy wielu repozytoriach rozważ centralne repo z wersją generyczną i submoduł lub skrypt kopiujący, ale pamiętaj, że generyczna warstwa jest zawsze słabsza od dostrojonej do stosu.
4.Plik reguł globalnych trzymaj poniżej ~300 linii
Na czym polega: Kontekst z pliku reguł ładuje się do każdej sesji. Nadmiar informacji dezorientuje model — to zjawisko context rot, zwane „strefą głupoty”.
Jak stosować: Test dla każdej linii: czy agent musi to wiedzieć niezależnie od tego, nad czym pracuje? Jeśli nie — przenieś do docs/ albo Confluence i wskaż agentowi punktowo, gdy zadanie tego wymaga. W regułach zostaw konwencje nazewnicze, wzorce kodowania, twarde ograniczenia.
Na co uważać: 300 linii to heurystyka autora, a nie stała fizyczna — przy dużym monorepo sensowniejsza może być hierarchia plików reguł per moduł. Uważaj też na rozrost przez dopisywanie: bez okresowego przeglądu ten plik puchnie sam z siebie.
5.Twoim zadaniem numer jeden przy planowaniu jest redukcja założeń agenta
Na czym polega: Vibe coding zawodzi zwykle nie dlatego, że model pisze zły kod, tylko dlatego, że pisze nie ten kod, o który ci chodziło. Modele przyjmują założenia pewnym siebie tonem, ale poproszone wprost — całkiem dobrze potrafią te założenia zidentyfikować.
Jak stosować: Po wczytaniu kontekstu ticketa poproś agenta, żeby przeprowadził z tobą wywiad i wypisał wszystko, w czym możecie się nie rozumieć. Korzystaj z narzędzia pytań wielokrotnego wyboru — przy dobrych rekomendacjach 20–30 pytań da się przejść w kilka minut. Przy tickecie większym niż jeden story point zaplanuj na rozmowę 20–30 minut.
Na co uważać: Klikanie „zgadzam się z rekomendacją” bez czytania zamienia ten krok w teatr — wtedy założenia zostają, tylko z twoim podpisem. Jeśli agent generuje absurdalnie dużo pytań (autorowi wyszło 28), ogranicz liczbę, ale wybierz te dotyczące decyzji nieodwracalnych.
6.Pętla R-PIV: research, plan, implement, validate — w osobnych sesjach
Na czym polega: Cztery kroki z odrębnymi skillami: prime (pobranie ticketa i rozpoznanie kodu), plan-feature (ustrukturyzowany plan), execute (implementacja) i walidacja. Implementacja startuje w świeżej sesji, bo plan jest dokumentem przekazania zawierającym cały potrzebny kontekst.
Jak stosować: Wdroż to jako cztery skille i egzekwuj rozdzielenie sesji: po zatwierdzeniu planu zamykasz rozmowę i otwierasz nową z samą ścieżką do planu. Sam wywołuj każdy krok, żeby zachować bramki kontroli.
Na co uważać: Handoff działa tylko wtedy, gdy plan naprawdę zawiera wszystko — jeśli kluczowa decyzja padła w rozmowie, a nie trafiła do dokumentu, świeża sesja jej nie zna. Przejrzyj plan sekcja po sekcji przed przekazaniem.
7.Plan to artefakt podlegający przeglądowi
Na czym polega: Sztywna struktura planu (opis, historyjka użytkownika, problem, referencje kontekstu, nowe pliki, lista zadań, strategia walidacji) sprawia, że każdy developer produkuje ten sam kształt dokumentu — łatwy do recenzji przez kolegę przed spaleniem tokenów na implementację.
Jak stosować: Wpisz strukturę wprost do skilla planowania. Wprowadź lekką normę: przy większych ticketach ktoś drugi patrzy na plan, zanim ruszy execute. Plan można też wysłać do Jiry lub Confluence i podpiąć jako komentarz do ticketa.
Na co uważać: Plany potrafią mieć nawet tysiąc linii — nie udawajcie, że czytacie je linia po linii. Przejdźcie sekcjami i skupcie się na historyjce użytkownika oraz strategii walidacji, bo tam kryją się najkosztowniejsze pomyłki. Uwaga techniczna: serwer MCP Atlassiana nie pozwalał dodać planu jako załącznika do ticketa — obejście to strona w Confluence plus link w komentarzu.
8.Zaplanuj walidację razem z implementacją i optymalizuj pod poprawność, nie pod czas
Na czym polega: Plan zawiera aparat walidacyjny: lint i sprawdzanie typów, testy jednostkowe i integracyjne, testy end-to-end w przeglądarce. Agent uruchamia je sam i iteruje, dopóki nie przejdą. Ważne nie jest trafienie za pierwszym razem, tylko to, co dostajesz, gdy agent mówi „gotowe”.
Jak stosować: W skillu planowania wymuś sekcję strategii walidacji z konkretnymi poleceniami i kryteriami akceptacji funkcji. Dołóż skill lub MCP do automatyzacji przeglądarki, żeby agent przeszedł ścieżkę użytkownika i zrobił zrzuty ekranu.
Na co uważać: Agent zweryfikuje tylko to, co mu wpiszesz — w demo powstał przycisk eksportu i zrzut ekranu, ale nikt nie kazał pobrać i sprawdzić zawartości pliku CSV. Pisz kryteria na poziomie efektu dla użytkownika, nie na poziomie „przycisk istnieje”. I licz się z tym, że iteracja na testach potrafi trwać długo.
9.Automatyczny przegląd PR w CI wzmacnia recenzenta, nie zastępuje go
Na czym polega: Workflow w GitHub Actions uruchamia agenta przy otwarciu pull requesta (albo na komendę w komentarzu) i publikuje jeden komentarz z wynikami przeglądu według własnego skilla — poprawność, bezpieczeństwo i inne kryteria.
Jak stosować: Dodaj plik workflow w .github/workflows, wgraj poświadczenia jako sekret repozytorium, wskaż swój skill przeglądu jako prompt. Traktuj komentarz agenta jako mapę: gdzie patrzeć uważnie i co przetestować ręcznie.
Na co uważać: Nie merguj dlatego, że agent napisał „wygląda dobrze” — autor wprost mówi, że sam mu w pełni nie ufa. Sekret z poświadczeniami w CI to realna powierzchnia ataku, więc ogranicz uprawnienia workflow i uważaj przy pull requestach z forków.
10.Każdy błąd agenta to materiał na poprawkę warstwy AI
Na czym polega: Ewolucja systemu: gdy agent zrobi coś nie tak, zamiast po cichu naprawiać kod, zapytaj go, co powinno się zmienić w regułach lub skillach, żeby ten problem się nie powtórzył — i zgłoś to jako pull request do warstwy AI.
Jak stosować: Zrób z tego nawyk zespołowy: przy każdym poważniejszym potknięciu agenta powstaje osobny, mały PR do warstwy AI z linkiem do ticketa, w którym problem wystąpił. Rozmowę o przyczynie prowadź w tym samym oknie kontekstu, w którym powstał błąd.
Na co uważać: Nie oddawaj tego procesu w pełni agentowi. Autor przestrzega, że przy automatycznym „ulepszaniu” warstwy AI modele generują setki linii zmian tam, gdzie wystarczyłoby dwadzieścia — nawet gdy każesz im być zwięzłymi. Zawsze bramka człowieka na propozycji zmiany.