O czym jest ten film
- Wyszła wersja 1.3 repozytorium skilli Matta Pococka dla agentów kodujących; trzy nowości — /implement-spec, /pr i /retro — na dobre weszły do jego codziennej pracy.
- Fundamentem metody Pococka jest duet: specyfikacja (cel podróży) oraz tickety, które rozbijają ten cel na sesje wykonalne przez pojedynczego agenta — wdrażanie wszystkiego w jednym kontekście kończy się spadkiem jakości i auto-compact.
- Trzy drogi orkiestracji ticketów: ręczna pętla (uciążliwa), deterministyczny skrypt (najpewniejszy i najtańszy, ale trudny w konfiguracji) oraz podagenty jako „opiekunowie” pętli — kompromis dla początkujących, możliwy od czasu, gdy podagenty potrafią uruchamiać kolejne podagenty.
- /implement-spec czyta specyfikację i tickety, eksploruje kod, prowadzi gałąź integracyjną, wdraża zadania przez podagenty (TDD, worktree), składa całość w jeden pull request i poddaje go code review.
- /pr to szablon opisu pull requesta zainspirowany skillą „Show Me” Dexa Hiesa: podsumowanie z diagramami, dowody „przed/po” oraz ocena ryzyka scalenia.
- Kluczowa metafora oceny ryzyka: drzwi dwukierunkowe (łatwy powrót, revert) kontra jednokierunkowe (trudne lub niemożliwe do cofnięcia), do tego „zasięg rażenia” zmian — to porządkuje priorytety recenzenta.
- Zmiana porządkowa w repo: skilla domain modeling zapisuje słownik pojęć do glossary.md zamiast context.md; wiele skill sprawdza obecność tego pliku, więc u użytkowników aktualizacja jest konieczna.
- /retro to retrospektywa sesji agenta: analizuje rzeczywiste przebiegi i wyłapuje to, czego agent sam nie zgłasza — brakujące zabezpieczenia, utratę kontekstu po kompakcjach, marnowanie tokenów.
- Retro jest zaprojektowane z człowiekiem w pętli: automatyczne wdrażanie wszystkich wniosków prowadziłoby do lawiny fałszywych trafień i wyprowadzenia repo na manowce.
- Regularne uruchamianie retro wyraźnie podniosło Pocockowi oszczędność tokenów i jakość pracy; nowa lekcja o implement-spec trafia na jego kurs na aihero.dev.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Duża robota to spec plus tickety — nigdy jedna wielka sesja
Na czym polega: metoda dowożenia dużych porcji pracy naraz opiera się na dwóch elementach: specyfikacji, która jest celem, i ticketach, które rozbijają ten cel na sesje wykonalne w pojedynczym kontekście agenta.
Jak stosować: zanim uruchomisz agenta, napisz specyfikację i podziel ją na tickety; traktuj je jak graf zadań spięty zależnościami, nie jak listę kroków — dzięki temu zawsze istnieje „front” zadań gotowych do podjęcia.
Na co uważać: wdrażanie całej specyfikacji w jednym kontekście spycha agenta w strefę gorszej sprawności i auto-compact; czasem ujdzie, ale rozbicie na tickety wychodzi po prostu czystiej.
2.Deterministyczna pętla to standard, do którego warto dążyć
Na czym polega: zamiast człowieka ani agenta pilnującego kolejności, zwykły skrypt odczytuje kolejne tickety i sam uruchamia wdrażanie; raz ustawiony przebiega identycznie przy każdym podejściu, działa niezawodnie i nie kosztuje tokenów.
Jak stosować: traktuj budowę takiego skryptu jako inwestycję — wymaga cierpliwości i kolejnych iteracji, ale potem odciąża cię na stałe.
Na co uważać: konfiguracja jest na tyle złożona, że dla początkujących pozostaje poza zasięgiem; nie zaczynaj od budowy „fabryki”, zacznij od prostszych mechanizmów.
3.Podagenty jako opiekunowie pętli — przystępny złoty środek
Na czym polega: /implement-spec oddaje prowadzenie pętli agentowi-orkiestratorowi, który rozdziela tickety między podagenty; stało się to możliwe, bo podagenty potrafią już tworzyć kolejne podagenty i mają moc porównywalną z orkiestratorem.
Jak stosować: sięgaj po to w projektach, w których nie masz jeszcze deterministycznych skryptów; możesz odejść od klawiatury i wrócić do gotowego PR-a z całej specyfikacji.
Na co uważać: to rozwiązanie niedeterministyczne, więc z definicji słabsze od skryptu; traktuj je jako bramę do pracy typu AFK, a nie stan docelowy.
4.Przeczytaj skillę w całości, zanim ją uruchomisz
Na czym polega: skilla to dokument opisujący proces — implement-spec ma dziewięć kroków plus materiał referencyjny; znajomość procesu chroni przed niespodziankami, takimi jak gałąź integracyjna, TDD czy code review na końcu.
Jak stosować: przed pierwszym uruchomieniem przejrzyj kroki i sekcję referencyjną; łatwiej wtedy ocenić, czy wynik — pojedynczy pull request z całej specyfikacji — jest tym, czego chcesz.
Na co uważać: ten szablon to dopiero punkt wyjścia; możesz zbudować własny wariant, na przykład pracę w pull requestach kładzionych na sobie (tzw. stacked PRs).
5.W pull requeście żądaj dowodów, nie deklaracji
Na czym polega: sekcja z dowodami wymusza pokazanie stanu przed i po; już sama prośba o dowód często skłania agenta do odpalenia dodatkowego testu czy zrzutu ekranu i do podania danych z czasu działania.
Jak stosować: włącz do szablonu PR-a wymóg twardego dowodu na realnym przykładzie — to fundament budowania zaufania do wyników agenta.
Na co uważać: bez dowodu agent łatwo „stwierdzi”, że coś pewnie działa, bo przeczytał kod; weryfikacja to obsesja, którą warto od niego przejąć.
6.Oceniaj scalanie: drzwi dwukierunkowe czy jednokierunkowe?
Na czym polega: PR-drzwi dwukierunkowe da się łatwo wycofać; jednokierunkowy robi coś nieodwracalnego — kasuje dane albo jego odwrócenie jest kosztowne. Do tego dochodzi zasięg rażenia zmian.
Jak stosować: umieść ocenę ryzyka i zasięgu na samym początku opisu PR-a — recenzent od razu wie, jak głęboko wgryzać się w kod.
Na co uważać: mała strefa oddziaływania i łatwy powrót pozwalają odchudzić recenzję, ale nie zwalniają z niej; PR-y jednokierunkowe traktuj ze zwiększoną czujnością.
7.Nazwa pliku ma znaczenie: glossary.md zamiast context.md
Na czym polega: skilla domain modeling zapisuje teraz słownik pojęć do glossary.md; stara nazwa brzmiała tak ogólnikowo, że agent nie sięgał po plik we właściwych momentach, a użytkownicy się w nim gubili.
Jak stosować: jeśli korzystasz ze skill Pococka, zmień nazwę pliku — wiele z nich sprawdza obecność glossary.md, żeby konsekwentnie posługiwać się językiem domenowym.
Na co uważać: to wyłącznie zmiana nazwy, bez modyfikacji zachowania; wniosek ogólniejszy: pliki-umowy z agentem nazywaj jednoznacznie i precyzyjnie.
8.Retrospektywa wyłapuje to, co agent przemilcza
Na czym polega: /retro czyta rzeczywiste przebiegi sesji (bieżącą, poprzednią, dowolną z otwartych) i proponuje ulepszenia; widzi nieefektywności, o których agent sam milczy, bo narzeczy mniej, niż powinien, i nie naprawia własnych pomyłek.
Jak stosować: przepuszczaj przez retrospektywę próbkę sesji, zwłaszcza te dziwne lub nieudane — na koniec zwykle masz w ręku konkretną poprawkę: CI, przeniesienie powtarzalnych instrukcji do skille, naprawę CLI marnującego tokeny.
Na co uważać: wnioski wymagają ludzkiego osądu — pozycja wskazana jako „najpoważniejsza” może być dla ciebie błahą (np. pominięty release).
9.Nie automatyzuj retro — człowiek zostaje w pętli
Na czym polega: pokusa, by agent sam wdrażał wszystkie wnioski z retrospektywy, prowadzi do pętli fałszywych trafień: agent nieustannie coś „poprawia” i krok po kroku wyprowadza repo oraz siebie tam, gdzie nie powinny trafić.
Jak stosować: przeglądaj raport po ludzku, wdrażaj wybrane wnioski, resztę odrzucaj — odrzucenie szumu jest częścią procesu, nie porażką.
Na co uważać: niemal każdy, kto zobaczy retro, chce je od razu zautomatyzować; skutki tej pokusy — lawina fałszywych trafień — odstręczają szybciej, niż się wydaje.
10.Regularna retrospektywa przekłada się na realne tokeny i jakość
Na czym polega: retro przegląda repozytorium w kilku kategoriach: nawigacja po kodzie, możliwe automatyczne kontrole, standardy dla automatycznego recenzenta, kondycja globalnego agents.md, gospodarka narzędziami, martwe instrukcje w plikach sterujących, dostęp agenta do informacji.
Jak stosować: zrób z tego rytuał — gdy masz chwilę i przypominasz sobie, że dawno nie było retro, przepuść przez skilla najświeższe sesje i wdroż jedną-dwie poprawki.
Na co uważać: efekt bierze się z rytmu, nie z jednorazowego audytu; i bez przerwy filtruj wyniki ludzkim okiem.
Redakcyjne tłumaczenie
Trzy nowości, które weszły mi w krew
Cześć! Wychodzi wersja 1.3 mojego repozytorium skilli, a razem z nią trzy narzędzia, które stały się centrum mojego przepływu pracy. Pokażę dziś każde z nich: implement-spec, PR i retro. Swoją drogą to właśnie retro wywołało — sądząc po mediach społecznościowych — największy rozgardiasz; ludzie dostali szału zachwytu, a i mnie szybko zrobiło się jasne, że mamy do czynienia z narzędziem o prawdziwej sile. Ale po kolei — zaczynamy od implement-spec.
(Informacja dodatkowa: „skille” to rozpowszechniane w plikach instrukcje i szablony procedur dla agentów kodujących, takich jak Claude Code; wywołuje się je komendami w stylu /pr. Repozytorium Matta Pococka to publicznie dostępny zbiór takich instrukcji, do którego odnosi się cały film.)
Specyfikacja i tickety: jak dowozić duże porcje pracy
Mój sposób na dowożenie dużych kawałków pracy za jednym razem opiera się na dwóch elementach: specyfikacji oraz ticketach, które tę specyfikację realizują. Specyfikacja pełni funkcję celu — miejsca, do którego zmierzamy — a tickety rozbijają ten cel na sesje, które da się przeprowadzić w pojedynczym agencie kodującym. Gdyby spróbować wdrożyć całą specyfikację w jednym kontekście, agent wpadłby w swoją strefę gorszej sprawności i pewnie skończyłoby się automatyczną kompresją kontekstu (tzw. auto-compact). Zdarza się, że to wystarcza, i z każdą wersją jest coraz lepiej, ale wciąż uważam, że rozłożenie pracy na pojedyncze tickety wychodzi po prostu czystiej.
Trzy sposoby rozprowadzania ticketów
Sam sposób orkiestrowania ticketów — przekazywania ich po jednym agentowi — zawsze był dla użytkowników trochę mylący. I sam krążyłem między różnymi rekomendacjami. Najbardziej irytujący, najbardziej ręczny wariant to zarządzanie wszystkim osobiście: mówicie agentowi „wdrażamy pierwszy ticket”, czekacie na koniec, czyścicie kontekst, mówicie „drugi”, znowu czekacie, znowu czyścicie, trzeci… W praktyce sami odgrywacie wtedy rolę pętli „for”. Da się, ale przyjemności tu żadnej — to właśnie ręczna pętla.
Można ją zastąpić pętlą deterministyczną: skrypt odczytuje kolejne tickety i sam uruchamia ich wdrażanie. Tak radzę robić większości osób, bo raz ustawiona pętla deterministyczna przebiega identycznie przy każdym podejściu. Jest niezawodna i tania — do jej kręcenia nie zużywacie ani agenta, ani własnego czasu; po prostu robi to za was skrypt. Schody zaczynają się przy konfiguracji: to dość złożone i wymaga sporo cierpliwości, dopóki pętla nie zostanie doszlifowana. Dlatego uznaję to rozwiązanie za poza zasięgiem osób dopiero zaczynających.
A że początkujący nie powinni wchodzić w ręczną pętlę, postanowiłem poszukać złotego środka: niech pętlą pokierują podagenty. Innymi słowy — zamiast człowieka opiekunem zostaje agent, a wszystkie tickety wdrażają podagenty. To właśnie stało się realne, bo podagenty potrafią już same uruchamiać podagenty. Kiedyś były mocno okrojone; dziś są równie potężne jak agenty-orkiestratorzy. I dokładnie to robi implement-spec: agent czuwa nad zestawem ticketów, nimi zarządza i wdraża je w podagentach. Podkreślę — to słabsza opcja niż pętla deterministyczna, bo ta druga działa zawsze tak samo. Ale implement-spec świetnie sprawdza się jako wstęp do przepływów AFK (away from keyboard): odchodzicie od biurka, a specyfikacja wdraża się sama.
Jak działa implement-spec: dziewięć kroków i jeden pull request
Zanim użyjecie jakiejkolwiek skille, przeczytajcie ją w całości. Ta nie jest długa: dziewięć kroków procesu i odrobina materiału referencyjnego u góry. Jedna rzecz jest kluczowa: implement-spec uruchamia pracę równolegle tam, gdzie się da. Tickety nie są listą kroków — to graf zadań spięty zależnościami (jedne blokują drugie), co oznacza, że zawsze istnieje „front” zadań gotowych do podjęcia.
Jak to wygląda krok po kroku? Skilla czyta specyfikację i tickety, robi trochę eksploracji kodu w osobnym podagencie i tworzy gałąź integracyjną. Następnie podagenty implementują kolejne tickety — metodą TDD, w osobnych worktree — po czym podagent scala wynik z gałęzią integracyjną, a orkiestrator wysyła kolejne, dopóki cała robota nie dojdzie do końca. Na koniec na gałęzi integracyjnej uruchamiany jest code review, implement-spec sprząta po sobie i przygotowuje pull request do recenzji. Efekt: z całej sporej specyfikacji dostajecie jeden PR.
(Informacja dodatkowa: „worktree” to funkcja gita pozwalająca mieć kilka gałęzi wyewidencjonowanych równocześnie w osobnych katalogach — dzięki temu podagenty pracują nad ticketami równolegle, nie skacząc sobie po głowie.)
Sięgam po tę skillę znacznie częściej, niż zakładałem — zwłaszcza w systemach, w których nie mam jeszcze deterministycznych skryptów, gdzie moja „fabryka oprogramowania” nie jest dopięta na ostatni guzik. Powstawała już od dłuższego czasu i uznałem, że nadszedł moment: wypuszczam ją, żeby ludzie mogli jej używać, majsterkować przy niej i budować własne wersje. To podstawowy wariant — można zrobić coś zupełnie innego, na przykład ułożyć pracę w pull requestach kładzionych na sobie (tzw. stacked PRs). A skólnieśmy przy PR-ach…
/pr: pull request, który sam się wytłumaczy
Jedną z moich najczęściej używanych ostatnio skill jest pr.md. Od dłużnego czasu jestem wielkim fanem Dexa Hiesa; niedawno udało mi się z nim spotkać osobiście. Ma on przepiękną skillę Show Me, która pomaga zrozumieć omawiany temat wizualnie — zwięzłymi diagramami i naprawdę eleganckim pseudokodem. W izolacji wygląda to niepozornie, ale osadzone w pull requeście wyraźnie ułatwia jego czytanie i recenzowanie.
Pull requesty wciąż są głównym wąskim gardłem na drodze kodu do gałęzi głównej. Celem tej skille — wzorowanej na Show Me — jest maksymalne ułatwienie ludzkiej recenzji. W praktyce skilla to szablon treści PR-a. Najpierw podsumowanie oparte na wzorcu z Show Me (dołączonym w skilli), potem żądanie dowodów — stanu przed i po.
Te dowody to istotny element uczenia się ufania agentowi i jego wynikom. Już sama prośba o dowód często sprawia, że agent odpala dodatkowy test albo — jeśli potrafi — robi dodatkowy zrzut ekranu i przedstawia dane z czasu działania potwierdzające, że zmiana faktycznie robi to, co on sądzi, że robi. Bez żądania twardego dowodu agentom przychodzi z łatwością powiedzieć: „pewnie działa, przeczytałem kod”. Weryfikacja to temat, w którym ostatnio popadam w obsesję — szczególnie po moim wywiadzie z Lauren.
Trzeci nagłówek szablonu to merge danger, czyli ryzyko scalenia. Bardzo podoba mi się metafora: czy to drzwi jednokierunkowe, czy dwukierunkowe? Drzwi dwukierunkowe to takie, przez które można zawrócić — PR łatwo wycofać. Jednokierunkowe to PR, który zrobi coś w świecie: skasuje dane albo jego odwrócenie będzie z jakiegoś powodu kosztowne. Ostatni element to blast radius — zasięg rażenia, czyli potencjalne skutki zmian. Skoro ryzyko i zasięg lądują w opisie jako pierwsza lub druga rzecz, którą recenzent zobaczy, od razu wiadomo, czy trzeba wgryzać się głęboko: mała strefa oddziaływania i dwukierunkowe drzwi pozwalają na lekką recenzję.
Przykład z mojego repozytorium: PR wygenerowany przez tę skillę, scalający dwa w gruncie rzeczy identyczne algorytmy. Widać pliki skasowane i dodane w odpowiednim kontekście, rozumiemy funkcje i powstającą strukturę wywołań, ale najważniejsze — mamy dowód: „przed” i „po” na realnej encji. Przed: intra nie ma. Po: intro zostaje dodane — czyli dokładnie zachowanie, o które nam chodziło. Na końcu ryzyko scalenia: dwukierunkowe, czysty refactor plus jedna zamierzona zmiana zachowania; zasięg rażenia: mały.
Ta skilla stała się dla mojego przepływu nieodzowna. Zauważyłem też, że jest jedną z najbardziej konsekwentnie samoczynnie wywoływanych skilli, jakie widziałem: użytkownik nie musi robić nic, model odpala ją przy każdym PR-ie — przynajmniej na Opusie 5.5. Wystarczy ją pobrać i patrzeć, jak opisy waszych pull requestów robią się lepsze. A jeśli macie już własną skillę do treści PR-ów? Podkradnijcie, co się da.
Zmiana porządkowa: glossary.md zamiast context.md
Zanim przejdziemy do retro, trzeba wspomnieć o istotnej zmianie w tym, jak moje skille pracują z dokumentacją — na przykładzie domain modeling. Skilla pisze teraz do glossary.md, nie do context.md. Inspiracją było DDD — Domain-Driven Design Erica Evansa, czyli projektowanie sterowane domeną — i stąd właśnie plik kiedyś nazwany context.md, z nawiązaniem do ddd-owskiego „bounded context” (ograniczonego kontekstu). Tyle że odszedłem od tej konwencji. DDD stosuję nadal w pełni, tylko bez szyldu; potrzebowałem terminu mniej obciążonego. „context.md” brzmiało po prostu za ogólnikowo: agent nie dostawał sygnału, kiedy po plik sięgnąć, a użytkownikom wprowadzał zamęt. Po drodze i tak ograniczyłem zawartość tego pliku do samego słownika pojęć, więc sensowność starej nazwy i tak wygasła. Teraz jest glossary.md — zaktualizowałem to wszędzie. Mnóstwo moich skilli sprawdza, czy widzą glossary.md, żeby w ogóle operować językiem domenowym, więc tę zmianę koniecznie musicie przenieść do siebie. W zachowaniu skille nic się nie zmienia — dosłownie tylko nazwa pliku. Sądząc po sygnałach, ludzie czekali na to od dawna; miło ją wreszcie wydać.
/retro: retrospektywa, która nie zna litości
A teraz retro — i najlepiej po prostu je uruchommy. Zdałem sobie sprawę, że mój zestaw skilli sporo wymaga od użytkownika. W gruncie rzeczy obarczałem was odpowiedzialnością za stopniowe ulepszanie repozytorium: pilnowanie agents.md, dbanie o skille, o to, żeby repo zużywało jak najmniej tokenów, żeby środowisko było dobre i bezpieczne dla agenta piszącego kod, żeby reguły lintu były porządne, a nawigacja wygodna. A przecież sam robię mnóstwo takich rzeczy we własnych repozytoriach i przy własnych agentach — żeby praca szła sprawniej i wszystko było wydajniejsze. W końcu pomyślałem: czemu nie spakować tego w skillę? Tym właśnie jest retro — skrót od retrospective, czyli retrospektywa.
Uruchamiacie ją na sesji agenta kodującego — bieżącej, poprzedniej albo jednej z tych dziesięciu, które mam akurat otwarte — a ona proponuje ulepszenia na przyszłość. Piękno tkwi w tym, że czyta prawdziwe sesje: widzi, co się działo, i dostrzega nieefektywności, które agent przed wami skrywa. Bardzo podoba mi się wpis Andre o retro: „Zmienia zasady gry. Moje agenty potykały się o rozmaite problemy, których nikt nie wykrył — ale dzięki uporowi funkcje i tak jakoś powstały”. Właśnie o to chodzi: agent, moim zdaniem, narzeczy mniej, niż powinien, i nie próbuje naprawiać własnych pomyłek. Potrzebny jest inny agent, który spojrzy na te sesje z boku, zobaczy, gdzie poszło nie tak, i podpowie, jak pomóc.
Popatrzcie, co retro znalazło u mnie. Agent wykonał nieodwracalną, publiczną akcję, zanim wybrano poprawkę: ustalił, dlaczego nie ma release’a 1.3.0, a potem po prostu wydał release — bez pytania. Dlatego, nawiasem mówiąc, w moich release’ach nie znajdziecie 1.3.0, jest tylko 1.3.1. Claude się na tym wyłożył; szczerze mówiąc, niewiele mnie to obchodzi, więc w moim kontekście ten wpis nie boli. Dalej: repozytorium nie ma żadnych realnych zabezpieczeń — skrypt pnpm check istnieje, ale nic go nie uruchamia, więc sugestia brzmi: dodaj pipeline CI. Gdzie indziej: utrata kontekstu między kompakcjami w długich sesjach. Tworzę animatyki — wstępne szkice filmów — i widać, że przy kompresji część kontekstu ginie; sugestia: wynieś powtarzalne instrukcje do osobnej skille animatycznej. Bardzo dobra uwaga, z pewnością ją wdrożę. A tu proszę: mój autorski CLI do zarządzania filmami na kurs marnuje tokeny — retro patrzy więc także na gospodarkę tokenową. Wiki, kolejny własny CLI, nie jest lokalnie na PATH, a wiki AI Hero ma dziury. Retro jest bezlitosne: czyta wasze sesje, patrzy, co się w nich dzieje, i praktycznie zawsze znajdzie coś do poprawy.
Przy retro potrzebny jest ludzki osąd. Na przykład pozycja uznana za najpoważniejszą wcale taka nie jest — to tylko release, a release’y mogę wydawać bez końca. Retro jest zaprojektowane jako narzędzie z człowiekiem w pętli — nie po to, żeby samo bez końca generować poprawki. Niemal każdy, komu je pokazuję, reaguje: „o, to trzeba zautomatyzować”. Nie, nie trzeba. Automatyzacja oznacza, że agent wejdzie w pętlę ciągłych fałszywych trafień: będzie bez przerwy próbował coś naprawiać, a repozytorium i agent krok po kroku zajdzą tam, gdzie nie powinny trafić.
Moja rada: uruchamiajcie retro na próbce sesji. W wolnej chwili, gdy tylko uświadomicie sobie, że dawno go nie było, przepuśćcie przez skilla najnowsze sesje — może tę, która poszła źle, albo taką, w której agent zrobił coś dziwnego. Retro zwykle znajdzie poprawkę. W krokach skille jest kilka kategorii, których wypatruje: czy kod daje się łatwo nawigować; czy można dorzucić automatyczne kontrole; czy warto dodać standardy kodowania egzekwowane przez automatycznego recenzenta; w jakiej kondycji jest globalny agents.md; czy zestaw narzędzi jest dobry; czy w plikach sterujących nie siedzą instrukcje, które nic nie robią; czy agent ma dostęp do wszystkich informacji, których potrzebuje.
Od kiedy regularnie uruchamiam retro, oszczędność tokenów — i po prostu jakość pracy, jaką jestem w stanie wyprodukować — poszła mocno w górę. Jeśli chcecie podnieść jakość swojej pracy, sięgnijcie po mój kurs AI coding na aihero.dev; jeszcze dziś dodaję do niego lekcję o implement-spec. Jeśli chcecie przejąć kontrolę nad agentem kodującym i lepiej wykorzystywać moje skille — to właściwe miejsce. Dzięki, że jesteście ze mną. Udanej zabawy z wersją 1.3 — i z odkrywania niewygodnej prawdy o tym, jak słabo wyglądają wasze sesje z agentem. Dokładnie na to pozwala retro.