O czym jest ten film
- Matt Pocock od dawna uważa zautomatyzowaną recenzję kodu za jeden z najskuteczniejszych sposobów podnoszenia jakości kodu produkowanego przez agentów, ale jego własny skill recenzencki wciąż jest „w toku” i nie satysfakcjonuje go w pełni.
- Pretekstem do filmu jest skill zespołu Cursora: „termonuklearna recenzja jakości kodu” – pojedynczy plik
skill.mdwymuszający wyjątkowo surową ocenę implementacji, abstrakcji, łatwości utrzymania i kondycji całej bazy. - Wyróżnikiem skilla jest ambicja: prompt każe recenzentowi wychodzić poza przesłany diff i szukać w całej bazie „ruchów judo” – zmian, które drastycznie upraszczają kod.
- Wśród twardych reguł: żaden PR nie powinien przepychać pliku ponad tysiąc linii bez mocnego uzasadnienia, a instrukcje warunkowe wtrącone w losowe miejsca to problem projektowy, nie stylistyczny.
- Osobny nacisk pada na typy: podważaj zbędną opcjonalność, typy
any/unknowni nadmiar rzutowań zawsze, gdy możliwa jest czystsza granica typów. - Pocock przetestował skill na ostatnich pięciu PR-ach do głównej gałęzi swojego projektu Sandcastle – spośród siedmiu głównych uwag pięć ocenił jako trafne (5/7).
- Najciekawszy werdykt: zgodnie z poprzeczką skilla część PR-ów w ogóle nie powinna była zostać wcielona – zachowanie było poprawne, ale baza zrobiła się wyraźnie mniej schludna niż tydzień wcześniej.
- Główna lekcja: ambitna recenzja generuje więcej fałszywych trafień, ale te łatwo się odrzuca; prawdziwym zagrożeniem są okazje do poprawy, których nigdy nie zobaczymy.
- Największa luka skilla: ani słowa o testach, szwach i pętlach zwrotnych, czyli o tym, co zdaniem Pococka stanowi dziś sens posiadania modularnej bazy kodu.
- Mimo zastrzeżeń (mnóstwo powtórzeń, dziwna sekcja o tonie wypowiedzi) skill jest wart pobrania i eksperymentów – sam Pocock planuje podkrasc z niego pomysły do własnego rozwiązania.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Recenzja od agenta to najtańsza dźwignia jakości kodu
Na czym polega: Dodatkowy przebieg agenta nad kodem, z krytycznym promptem, wyłapuje znacznie więcej problemów niż człowiek nadążający z codziennym tempem zmian. Dlatego Pocock traktuje automatyczną recenzję jako fundament jakości.
Jak stosować: Wprowadź recenzję jako obowiązkowy etap przed wcieleniem każdego PR-a. Wystarczy gotowy skill (Cursora albo Pococka) dopasowany do konwencji zespołu.
Na co uważać: Recenzja ma sens tylko wtedy, gdy jej uwagi realnie wpływają na los zmiany – inaczej zamieni się w maszynę do generowania szumu, którą wszyscy przestaną czytać.
2.Ambicją recenzenta steruje prompt
Na czym polega: Agent, który dostaje sam diff, zwykle traktuje go jako ogrodzony obszar swoich rozważań. Skill Cursora wprost każe „być ambitnym”: przeszukiwać całą bazę (startując od zmian w gałęzi) i proponować restrukturyzacje, a nie kosmetykę.
Jak stosować: We własnym prompcie jasno określ zasięg recenzji – sam diff czy cała baza – i dopisz zachętę do dużych zmian strukturalnych, gdy istnieje wyraźna ścieżka poprawy.
Na co uważać: Im ambitniejszy prompt, tym więcej fałszywych trafień. Zaplanuj czas na ich ręczne odrzucanie.
3.Pytaj o „ruchy judo” w kodzie
Na czym polega: Kluczowe pytanie skilla: czy istnieje zmiana, która uczyni ten fragment dramatycznie prostszym – na przykład skasowanie całej warstwy pośredniości zamiast jej szlifowania albo przeformułowanie zmniejszające liczbę pojęć, które czytelnik musi trzymać w głowie.
Jak stosować: Wpleć takie pytania do własnego promptu i wymagaj od agenta konkretnej propozycji uproszczenia przy każdej odpowiedzi twierdzącej.
Na co uważać: Propozycje bywają zbyt radykalne. Przed refaktorem zważ koszt zmiany wobec zysku – nie każde uproszczenie jest warte rozdrabniania działającego kodu.
4.Tysiąc linii na plik – z myślą o kontekście agenta
Na czym polega: Duży plik agent musi wchłonąć w całości do okna kontekstowego, żeby znaleźć interesujący fragment. Po podziale nazwa pliku staje się wskaźnikiem zawartości, co dużo oszczędniej zużywa kontekst. Stąd reguła: żaden PR nie przepycha pliku ponad tysiąc linii bez mocnego powodu.
Jak stosować: Ustal własny próg (Pocock dzieli pliki powyżej około 5 tysięcy tokenów) i pilnuj go w recenzji. Nazywaj pliki tak, by sama nazwa mówiła, co jest w środku.
Na co uważać: Liczby są umowne – źle pocięty plik szkodzi czytelności tak samo jak zbyt duży. Liczy się sensowna granica odpowiedzialności, nie sama statystyka.
5.Warunki w dziwnych miejscach to problem projektowy
Na czym polega: Skill każe traktować instrukcje warunkowe wtrącone w losowe miejsca jako sygnał złego projektu, a nie drobiazg stylistyczny. Zamiast plątać istniejącej ścieżki, logika powinna trafić do dedykowanego miejsca: helpera, maszyny stanów, obiektu reguł albo osobnego modułu.
Jak stosować: Gdy agent znajdzie takie „wtrącenia”, każ mu zaproponować wyniesienie tej logiki w jedno miejsce zamiast łatać stary kod.
Na co uważać: Nie każda gałązka zasługuje na abstrakcję – czasem zwykły, czytelny warunek jest lepszy. Sam Pocock podchodzi do tej reguły z rezerwą.
6.Kwestionuj zbędną opcjonalność i rozmyte typy
Na czym polega: Agenty masowo dodają propsy jako opcjonalne nawet wtedy, gdy są zawsze wymagane – rzekomo dla zgodności wstecznej albo żeby ograniczyć zasięg zmiany. Typy any/unknown i nadmiar rzutowań rozmywają granice, które powinny być ostre.
Jak stosować: Zapisz w prompcie recenzenckim wprost: podważaj pola opcjonalne bez uzasadnienia oraz rzutowania zawsze, gdy możliwa jest czystsza granica typów.
Na co uważać: Ta sekcja jest typescriptowa. W innych językach przetłumacz ją na lokalne odpowiedniki – na przykład niejawne wartości null czy nieprzechwycone wyjątki.
7.Wymuszaj hierarchię uwag i jednoznaczny werdykt
Na czym polega: Skill porządkuje raport: regresje strukturalne na samej górze, kwestie czytelności i utrzymania na dole, a na końcu werdykt – zatwierdź albo odrzuć PR.
Jak stosować: Każ recenzentowi szeregować uwagi według wagi i kończyć raport jednoznacznym wnioskiem o losie zmiany.
Na co uważać: Bez narzuconej hierarchii agent zaleje cię drobiazgami, a najważniejsze problemy utoną w liście.
8.Fałszywe trafienia są tanie, przeoczone okazje – drogie
Na czym polega: W teście Pococka dwie z siedmiu głównych uwag były chybione, ale ich odrzucenie kosztowało sekundy. Niewykryte możliwości poprawy to straty, o których nigdy się nie dowiemy – i to one realnie bolą.
Jak stosować: Strojąc prompt, celuj raczej w nadmierną czujność niż w eliminację szumu. Każdą uwagę traktuj jak hipotezę do szybkiej weryfikacji, nie jak wyrok.
Na co uważać: Przy dużej liczbie PR-ów fałszywe alarmy jednak kosztują czas i osłabiają zaufanie do recenzji – mierz trafność na własnej bazie.
9.Recenzja bez testów ogląda tylko połowę kodu
Na czym polega: Skill Cursora nie wspomina o testach, szwach ani pętlach zwrotnych, a zdaniem Pococka właśnie łatwość zmian i szybka informacja zwrotna to dziś główny sens modulnej bazy kodu.
Jak stosować: Rozbuduj prompt o pytania o pokrycie testami, szwy umożliwiające izolację fragmentów oraz o to, czy zmiana skraca drogę do wykrycia błędu.
Na co uważać: Ocena samych testów bez kontekstu architektury bywa płytka – łącz oba wymiary w jednej recenzji.
10.Skill to też kod: skracaj i deduplikuj
Na czym polega: Skill Cursora ma mnóstwo powtórzeń i zbędną sekcję o tonie wypowiedzi. Wielka kula instrukcji utrudnia agentowi ustalenie priorytetów.
Jak stosować: Iteruj nad promptem jak nad kodem: usuwaj powtórzenia, testuj na rzeczywistych PR-ach i mierz, ile uwag okazało się trafnych (u Pococka: 5/7).
Na co uważać: Zbyt agresywne skracanie może zgubić istotne niuanse. Zmieniaj jedno miejsce na raz i porównuj wyniki.
Redakcyjne tłumaczenie
Dlaczego automatyczna recenzja kodu robi różnicę
Zautomatyzowana recenzja kodu to jeden z najskuteczniejszych sposobów na podniesienie jakości tego, co produkują agenty. Wiedziałem o tym od dawna, ale sporo czasu zajęło mi wdrożenie tego w życie i ułożenie skillu, który mógłbym komuś przekazać do przeglądania własnego kodu. Taki skilla mam w swoim repozytorium – ma już 109 tysięcy gwiazdek – i wciąż oznaczony jest jako „w toku”. Jakoś się z tym godzę, ale szczęśliwy nie jestem. Dlatego rozglądam się za inspiracją w cudzych rozwiązaniach, z których można podkradać pomysły. Jeden z nich właśnie wpadł mi w oko i chcę go pokazać.
(Informacja dodatkowa: skill to rozpowszechniona w narzędziach takich jak Cursor czy Claude Code forma instrukcji dla agenta – zazwyczaj jeden plik skill.md opisujący, jak model ma wykonać konkretne zadanie.)
„Termonuklearna recenzja jakości kodu” od zespołu Cursora
Skill pochodzi od zespołu Cursora i nazywa się „termonuklearna recenzja jakości kodu”. Wstęp brzmi: „Użyj tego skillu do wyjątkowo surowej recenzji, skupionej na jakości implementacji, łatwości utrzymania, jakości abstrakcji i kondycji całej bazy”. Najbardziej rzuca się w oczy, jak ambitnego recenzenta ten prompt buduje: każe mu przez cały czas rozglądać się za „ruchami judo” w kodzie.
Całość to dosłownie jeden plik. Postanowiłem skopiować go na dysk, przegonić na własnym kodzie i zobaczyć, co z tego wyjdzie. Wczoraj sporo pracowałem nad Sandcastle – moim open source’owym projektem typu „fabryka oprogramowania” – więc naturalnym wyborem było poddanie recenzji ostatnich zmian wcielonych do głównej gałęzi. Nie kombinowałem z poleceniem: „Termonuklearna recenzja jakości kodu – przejrzyj ostatnie pięć PR-ów wcielonych do maina”. Włączyłem tryb automatyczny i, póki agent pracuje, czytajmy razem ten skill – sam w sobie dużo wyjaśni.
Punkt startu: ambitny audyt, a nie tylko diff
Skill wychodzi od takiego fundamentu: przeprowadź głęboki audyt jakości zmian w bieżącej gałęzi. Przemyśl od zera ich strukturę i implementację tak, żeby realnie poprawić jakość kodu, nie ruszając zachowania. Poprawiaj abstrakcje i modułowość, rozbieraj spaghetti, dbaj o zwięzłość i czytelność. Bądź ambitny: jeśli istnieje wyraźna ścieżka do lepszej implementacji, choćby wymagała restrukturyzacji fragmentu bazy – idź w nią. I pracuj bardzo skrupulatnie: najpierw sprawdź, potem tnij.
Z mojego doświadczenia z takimi promptami wynika, że agent po prostu nie jest dość ambitny. Przekażesz mu diff – czyli zestaw zmian – a on potraktuje go jako ogrodzony plac, po którym wolno mu się poruszać. Ten prompt celowo łamie tę konwencję. Mówi w gruncie: „Przeszukaj całą bazę w poszukiwaniu okazji do poprawy, ale zacznij od zmian w tej gałęzi”.
Tysiąc linii na plik – dla dobra agenta
Dalej przychodzi pakiet niepodlegających negocjacji zasad. Bądź ambitny w upraszczaniu struktury – znowu ta ambicja. Nie pozwól, by PR przeprowadzał plik spod granicy tysiąca linii ponad tę granicę bez bardzo mocnego uzasadnienia. To ciekawe, bo sam kiedyś doszedłem do tego samego wniosku. Duże pliki są po prostu trudne do nawigacji dla agentów: żeby znaleźć w pliku to, co go interesuje, musi połknąć całość do okna kontekstowego. Znacznie lepszy układ to rozbicie na kilka plików, gdzie nazwa każdego z nich pełni rolę wskaźnika – mówi, co jest w środku i czy warto go otwierać. To znacznie oszczędniej zarządza kontekstem. Ja zwykle dzielę pliki powyżej 5 tysięcy tokenów, więc próg tysiąca linii to w istocie zbliżona reguła.
Spaghetti i warunki w dziwnych miejscach
Nie pozwalaj na niekontrolowany rozrast plątaniu istniejącego kodu. Chodzi między innymi o zagnieżdżanie: jeśli jakaś zmiana wtrąca dziwne instrukcje warunkowe w losowe miejsca, traktuj to jako problem projektowy, a nie drobiazg stylistyczny. Zamiast plątać istniejącej ścieżki, wypchnij logikę do dedykowanej abstrakcji, helpera, maszyny stanów, obiektu reguł albo osobnego modułu. Ciekawe – to kolejny sposób na powiedzenie agentowi: jeśli widzisz stos zagnieżdżonych warunków i pokrętne zależności, może warto wynieść je do czystszego miejsca. Czy sam zawsze to preferuję? Bywa różnie, czasem tak, czasem nie – ale na potrzeby tej rozmowy przyjmijmy, że to dobra rada.
Dąż do porządkowania projektu, nie zadowalaj się kodem, który po prostu działa – znowu pchnięcie w stronę ambicji. Wolaj kod bezpośredni, nudny i łatwy w utrzymaniu niż sprytny i magiczny. Klasyk tego gatunku; podobna myśl siedzi w „simplify” z Claude Code. Bardzo mi się to podoba.
Typy, granice i zbędna opcjonalność
Naciskaj mocno na czystość typów i granic między modułami zawsze, gdy wpływa to na łatwość utrzymania. Podważaj zbędną opcjonalność oraz typy unknown i any, gdy mogłaby istnieć wyraźniejsza granica; kwestionuj kod oparty na rzutowaniach. To sekcja wyraźnie z typescriptowego świata – unknown i any to pojęcia właśnie stamtąd. A „zbędna opcjonalność” to rzecz, która zawsze mnie doprowadza do białości. Gdy agent dodaje prop do komponentu Reacta, niemal zawsze zrobi go opcjonalnym. Nie wiem czemu. To bez sensu. Nawet gdy prop jest zawsze wymagany, agent doda go jako opcjonalny – rzekomo dla zgodności wstecznej albo żeby ograniczyć zasięg zmiany. Dlatego „kwestionuj zbędną opcjonalność” to dla mnie złoty punkt całego skillu.
Istniejące helpery i kwestia równoległości
Trzymaj logikę w warstwie kanonicznej i korzystaj z istniejących narzędzi. Wolaj sprawdzone helpery niż wyszukane twory pisane od zera. Rozsądnie: to przypomnienie, że problem może być już rozwiązany w bazie i nie trzeba wymyślać koła na nowo.
Traktuj zbędną sekwencyjną orkiestrację i nieatomowe aktualizacje jako zapach projektowy, gdy oczywista jest czystsza struktura. Jeśli niezależne prace są szeregowane bez powodu, zapytaj, czy przepływ nie powinien biec równolegle. W gruncie rzeczy to kwestia wydajności: dwie niezależne rzeczy wykonają się szybciej równolegle niż jedna po drugiej. W tym samym akapicie pada też przestroga przed przesadną dbałością o mikrooptymalizacje – czyli: nie odjeżdżaj. Gdyby to był mój skilla, przepisałbym ten fragment dużo prościej. „Zbędna sekwencyjna orkiestracja i nieatomowe aktualizacje jako zapach projektowy” – dla mnie to zlepek słów bez treści.
Trzy pytania, które warto zadać przy każdej zmianie
Najciekawsza część: pytania przewodnie recenzji. Po pierwsze: czy istnieje ruch judo, który uczyniłby ten fragment dramatycznie prostszym? Uwielbiam. Po drugie: czy da się to przeformułować tak, żeby potrzeba było mniej pojęć, mniej rozgałęzień, mniej warstw helperów? Świetnie. Po trzecie: czy zmiana poprawia, czy psuje lokalną architekturę? – tego już nie lubię. Żeby „poprawia albo psuje” cokolwiek znaczyło dla agenta, musisz mu najpierw pokazać palcem, jak wygląda dobro, a jak zło. Mimo to cała lista pytań, razem z regułami powyżej, daje agentowi sposób wejścia w rozmowę o kodzie – a dokładnie tego potrzeba.
Kiedy podnosić alarm
Dalej skill opisuje sytuacje wymagające eskalacji: skomplikowana implementacja, którą czystsze przeformułowanie mogłoby wykasować całe kategorie złożoności; refaktoryzacje, które przenoszą kod z miejsca na miejsce, ale nie zmniejszają liczby pojęć, które czytelnik musi trzymać w głowie; zbędne rzutowania, typy any i unknown, parametry opcjonalne.
I tu dochodzimy do rzeczy, która mnie w takich wielkich promptach recenzenckich lekko przeraża: to dla agenta jedna wielka kula błota. Instrukcji jest mnóstwo i trudno przewidzieć, które uzna za priorytetowe. Trochę mnie to niepokoi.
Podoba mi się natomiast lista śmiałych sugestii: gdy znajdziesz problem jakości, proponuj radykalne ruchy – skasuj całą warstwę pośredniości zamiast ją szlifować. Znowu ta ambicja. Rozbij duży plik na mniejsze, skupione moduły – znowu ułatwianie nawigacji agentowi. Usuwaj duplikację. Zaostrzaj granice typów, żeby upraszczać przepływ sterowania. Powtórzeń jest tu jednak bardzo dużo; spokojnie można by to skrócić o połowę.
Ton wypowiedzi
Osobna sekcja o tonie: bądź bezpośredni, poważny i wymagający wobec jakości, ale nie nieuprzejmy. Nie bardzo rozumiem, co to robi w skillu. Z drugiej strony widać, że autorzy dopracowali język, którym agent ma mówić o kodzie: „ruch judo”, „rozłóż”, „przepycha plik ponad próg”, „otaczający kod coraz bardziej splątany”. To mi się podoba.
Kolejność uwag i werdykt
Na koniec: oczekiwania wobec raportu. Uwagi mają być uszeregowane według wagi – najważniejsze na górze, kwestie czytelności i utrzymania na dole, regresje strukturalne na samym szczycie. Recenzent ma też wydać werdykt: zatwierdzić albo odrzucić PR. I znowu – powtórzeń co niemiara; ten skilla mógłby być znacznie krótszy.
Podsumowując: dostajemy wielki blok tekstu, który mówi: „Bądź ambitny. Oto konkretne rzeczy, na których się skup. Proponuj mnóstwo zmian strukturalnych. Porządkuj wyniki według wagi, żebyś nie zalał człowieka drobiazgami. I na końcu zatwierdź albo odrzuć wedle tych warunków”.
Czego w tym skillu brakuje
Nie ma tu ani słowa o testach. Ani słowa o szwach w kodzie, ani o poprawianiu pętli zwrotnych, dzięki którym przyszłe przebiegi agenta będą lepsze – a moim zdaniem właśnie w tym dziś leży cały sens posiadania dobrej, modularnej, łatwej do nawigacji bazy kodu. Cała konstrukcja celuje w kod źródłowy, żadną częścią w testy. Intrygujące.
(Informacja dodatkowa: „szwy” (ang. seams) to miejsca w kodzie, w których da się go rozpieścić – podmienić implementację lub przetestować fragment w izolacji; kluczowe pojęcie w dyskusji o testowalności architektury.)
Wyniki na żywo: pięć PR-ów w Sandcastle
Czas na to, co agent wypracował na ostatnich pięciu PR-ach do maina. Zacznijmy od problemów strukturalnych rangi blokera.
Po pierwsze: serwis inicjalizacji urósł do ponad tysiąca linii i miesza w sobie kilka odpowiedzialności – zmiana powinna była zostać poprzedzona podziałem pliku, a agent właśnie taki podział zaproponował. Do tego dorzucił abstrakcję w rodzaju generycznej funkcji tworzącej rejestr, która skasowałaby dwadzieścia linii powtórzonego kodu. Dobre.
Druga uwaga: rozsiana na trzech warstwach instrukcja warunkowa, która odróżnia „własnego” trackera zagadnień. Zamiast specjalnego przypadku w kodzie agent zaproponował ruch judo: wynieść warianty własnego trackera do typu, który da się później po prostu odczytać. Znam ten kod całkiem dobrze – to druga bardzo dobra sugestja na dwie.
Trzecia: niespójny kontrakt – argumenty szablonu mieszają polecenia powłoki z markerami tekstu; część jest wykonywalna, część nie. Agent zaproponował rozszerzenie typu do unii dyskryminowanej (polecenie albo marker „do wypełnienia”) albo osobne pole dla niewypełnionych markerów. W zamyśle to wzmocnienie granicy typów, żeby nie podać później markera tam, gdzie czeka polecenie. Ciekawe – ale widać, że agent źle zrozumiał system. Fałszywe trafienia zdarzą się przy każdym prompcie recenzenckim; gdyby to wyszło w prawdziwym PR, machnąłbym ręką. Mamy więc dwa trafienia na trzy. Nieźle.
Wśród mocnych uwag o jakości agent wyłapał dziwaczny fragment projektu: szablony w Sandcastle deklarują własne zależności – najczęściej bibliotekę Zod do walidacji danych – a gdzieś w kodzie siedzi ścieżka, która na sztywno zakłada Zoda. Trudno to streścić jednym zdaniem, ale agent faktycznie wygrzebał coś podejrzanego. Trzy na cztery.
Potem połykane błędy: wywołanie execSync wewnątrz Effect.sync z cichą obsługą niepowodzenia – próba, a w razie porażki po prostu zwrócenie false. Zdecydowanie coś, po czym recenzent powinien sięgnąć. (Informacja dodatkowa: Effect to framework TypeScriptowy do zarządzania efektami, m.in. błędami i asynchronicznością.)
Dalej: „wygląda, jakbyśmy zaczęli rozbierać duży plik na mniejsze, ale skończyli w połowie” – kolejna trafna uwaga, pięć na sześć. Na koniec duplikacja w promptach: zmiana identyczna co do bajtu w dwóch różnych promptach, a agent proponuje wynieść ją do wspólnego wstępu. Tym razem się nie zgadzam – te prompty powinny dać się zmieniać niezależnie. Pięć na siedem. Nieźle.
Jest też lista mniejszych rzeczy do poprawienia; po szybkim przejrzeniu większość wygląda sensownie.
Poprzeczka skillu: część PR-ów nie powinna była wylądować
I rzecz, która mnie najbardziej intryguje: według poprzeczki przyjętej w skillu kilka z tych PR-ów nie powinno było trafić do bazy w obecnym kształcie. Zachowanie we wszystkich trzech merytorycznych PR-ach jest poprawne, ale baza kodu jest wyraźnie mniej schludna niż tydzień temu. No tak.
Wnioski: fałszywe alarmy są tanie, przeoczenia drogie
Dostaliśmy z tego skillu naprawdę wartościowe uwagi. I najważniejsza lekcja jest taka: gdy kaążemy recenzji być bardzo ambitną i wskazywać dużo różnych opcji, dostaniemy więcej fałszywych trafień – ale te łatwo się odrzuca. Niebezpieczne jest to drugie: okazje do poprawy, których nigdy nie zobaczysz. To one są prawdziwym zagrożeniem.
Gdybym ten skilla poprawiał, najpierw ogoliłbym powtórzenia, żeby był bardziej zwięzły, a potem mocno dołożył o testach i szwach – w duchu mojego skillu o ulepszonej architekturze bazy. Ale ogólnie: warto go pobrać, poeksperymentować i zobaczyć, co z niego wypłynie.
Na koniec
Jeśli to twoja bajka, to od 1 czerwca startuje kohorta mojego kursu „AI coding for real engineers”. To kurs, na który zapisało się najwięcej osób w mojej historii – będzie nas chyba około czterech, czterech i pół tysiąca. Kompletnie szalone. A jeśli znasz skilla, który mógłbym zrecenzować – daj znać. Bardzo lubię robić takie materiały, bo pozwalają mi podkradać pomysły z cudzych świetnych rozwiązań. Dobra robota, do zobaczenia wkrótce.