O czym jest ten film
- Autor prezentuje pięć świeżych repozytoriów GitHub przydatnych przy budowaniu aplikacji z AI — połowa z nich nie ma nawet dziesięciu tysięcy gwiazdek.
- Skill draw.io generuje na podstawie kodu edytowalne diagramy architektury — wystarczy prośba sformułowana zwykłym językiem.
- Znajomość własnej architektury oszczędza tokeny: zamiast puszczać model na całe repozytorium, wskazujesz warstwę, w której problem najpewniej leży.
- Główna teza: z modelu wyciśniesz tylko tyle, na ile pozwala twoja wiedza — narzędzia AI trzeba traktować jako pętlę nieustannej nauki.
- Ponytail zwalcza przeinżynierowanie: polecenie audytu wskazuje kod do skasowania, zredukowania oraz rzeczy z kategorii YAGNI.
- Handy to darmowy, otwartoźródłowy zamiennik płatnego WhisperFlow — dyktowanie promptów zamiast klepania; do wyboru modele, np. Parakeet (szybki) i Whisper large (dokładny).
- Improve od Shadcna to audytor bazy kodu: znajduje pominięte przypadki brzegowe i zwraca plan poprawek, a nie gotową łatkę.
- Proponowany obieg pracy: plany trafiają do GitHub Issues z etykietami, a agenci w tle realizują je i tworzą pull requesty.
- Skill Specter od NVIDII skanuje biblioteki skilli pod kątem bezpieczeństwa — bez klucza API zasypuje fałszywymi alarmami.
- Przykład skanu: popularne chińskie repo z krytycznymi problemami — wymóg wklejania ciasteczek sesyjnych i zdalne uruchamianie obcego kodu przez skrypty instalacyjne.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rysuj architekturę, zamiast zgadywać, co zbudowałeś
Na czym polega: Osoby kodujące „na vibesach”, zwłaszcza bez inżynierskiego tła, często nie wiedzą, jak poszczególne elementy aplikacji łączą się w całość. Skill draw.io czyta kod i rysuje edytowalny diagram warstw.
Jak stosować: Zainstaluj interfejs draw.io, potem skill w Claude Code, i poproś naturalnym językiem, np. „pokaż warstwy usług w moim repozytorium”. Diagram traktuj jak mapę, po której poruszasz się przy każdej poprawce.
Na co uważać: Sam diagram nic nie zmieni — trzeba go czytać i próbować rozumieć. Przeszukanie kodu kosztuje tokeny (niewiele, ale przy dużych repozytoriach warto to liczyć).
2.Wskaż modelowi miejsce błędu — oszczędzisz tokeny i czas
Na czym polega: Rzut modelu na całe repozytorium w poszukiwaniu usterki marnuje kontekst. Ktoś, kto zna architekturę, od razu kieruje poszukiwania we właściwe miejsce.
Jak stosować: Gdy coś nie działa, najpierw spójrz na diagram i ustal, która warstwa jest głównym podejrzanym (np. parsowanie wiadomości to najpewniej resolver), i dopiero wtedy każ modelowi działać.
Na co uważać: Błędne wskazanie (np. wysłanie modelu do plików telemetrii, gdy problem siedzi w parserze) pogarsza wynik i podwaja koszt.
3.Twoja wiedza jest sufitem — traktuj AI jak pętlę uczenia się
Na czym polega: Model pchniesz dokładnie tak daleko, jak sięga twoja wiedza. Początkujący zbudują prostą apkę, ale nie wyjdą dalej, bo nie wiedzą, o co pytać.
Jak stosować: Przy każdej poprawce zatrzymaj się na moment i spróbuj zrozumieć, co model właściwie zrobił — z pomocą diagramów i specyfikacji. Przy każdym skoku jakości modeli wykorzystaj ten moment na ulepszanie tego, co już masz.
Na co uważać: Odruch „Claude, napraw” działa krótkoterminowo, ale twoje umiejętności stoją w miejscu — a to najgorszy możliwy scenariusz.
4.Regularnie audytuj kod pod kątem „usuń / zredukuj / YAGNI”
Na czym polega: Modele językowe z upodobaniem przeinżynierowują rozwiązania — budują abstrakcje, których projekt na danym etapie wcale nie potrzebuje. Ponytail wskazuje, co skasować, co uprościć i co jest przewidywaniem problemów, które nigdy nie nadejdą.
Jak stosować: Uruchamiaj audyt po większych fazach budowania albo jako element przeglądu kodu; wyniki omawiaj z modelem przed wprowadzeniem zmian.
Na co uważać: Nie kasuj niczego automatycznie — czasem „nadmiar” to świadomie zaplanowana elastyczność, a decyzja powinna należeć do ciebie.
5.Komponenty różniące się tylko treścią scal w jeden
Na czym polega: W przykładzie z filmu trzy osobne komponenty paska błędu różniły się wyłącznie kolorem, tekstem i handlerem — wystarczyłby jeden, parametryzowany.
Jak stosować: Przy przeglądach szukaj rodzin komponentów o identycznej strukturze i przenoś różnice do właściwości (propsów).
Na co uważać: Zbyt agresywne uogólnienie potrafi utrudnić rozwój, gdy różnice zaczynają realnie rosnąć.
6.Dyktuj prompty — wypowiedziany kontekst jest bogatszy
Na czym polega: Mówimy około trzy razy szybciej, niż piszemy, a klepiąc tekst, naturalnie go skracamy i ucinamy kontekst, który inaczej wypadłby nam z głowy.
Jak stosować: Jeśli nie chcesz płacić za WhisperFlow, sięgnij po darmowy Handy; wybierz model pod swoją maszynę — Parakeet dla szybkości, Whisper large dla dokładności.
Na co uważać: Handy nie wycina wypełniaczy („yyy”, „no więc”). Przy promptach dla modelu to bez znaczenia, ale do notatek przeznaczonych ludziom lepiej dobrać narzędzie z filtrowaniem.
7.Precyzyjny prompt plus znajomość architektury równa się lepszy audyt
Na czym polega: Zamiast „zoptymalizuj mój kod” autor dyktuje audytorowi dokładny zakres (funkcje resolverów), cel (oszczędność tokenów) i ograniczenie (nie można stracić trafności).
Jak stosować: Przed audytem sformułuj, co dokładnie badać i jakie warunki musi spełniać wynik; możesz nagrać kilka „zrzutów myśli” do pliku i wkleić całość jako jeden prompt.
Na co uważać: Zbyt ogólne zapytanie da zbyt ogólną odpowiedź. Pamiętaj też, że dobry audytor zwraca plan, a nie samowolnie wprowadza zmiany.
8.Szukaj logiki, którą da się rozstrzygnąć bez modelu
Na czym polega: W przykładzie z filmu duża część zapytań użytkownika leciała prosto do modelu językowego, choć spokojnie wystarczyłoby zwykłe, deterministyczne wyszukiwanie — a optymalizacja istniała tylko w jednym miejscu w kodzie.
Jak stosować: Przeglądaj ścieżki przetwarzania pod kątem kosztu i pytaj audytora, gdzie wywołanie modelu jest zbędne.
Na co uważać: Nie poświęcaj trafności dla oszczędności — błędne kierowanie zapytań psuje działanie aplikacji tam, gdzie model naprawdę jest potrzebny.
9.Backlog w GitHub Issues zasilany przez pętlę agentów
Na czym polega: Plany poprawek zamieniane są w issues z etykietami; agent w tle pobiera otwarte zadania, implementuje je i tworzy pull requesty, a człowiek wchodzi tylko na przegląd przed scaleniem.
Jak stosować: Każde issue z jasnym konceptem (błąd, funkcja, optymalizacja) opatrz etykietą; oznaczenie typu „backlog” blokuje zadanie przed automatycznym przebiegiem, dopóki nie zatwierdzisz planu.
Na co uważać: Nigdy nie scalaj bez własnego przeglądu — pętla agentowa jest tak dobra, jak jakość zatwierdzonych planów.
10.Skanuj obce biblioteki skilli, zanim je zainstalujesz
Na czym polega: Skill to wykonywalny kod z dostępem do twojej maszyny — realna powierzchnia ataku. Skaner NVIDII wykrył w popularnym repo m.in. wymóg wklejania ciasteczek sesyjnych i zewnętrzny skrypt instalacyjny odpalany wprost na komputerze.
Jak stosować: Przed instalacją obcej biblioteki (zwłaszcza z nieznajomego języka lub źródła) przepuść ją przez Skill Specter z podpiętym kluczem API; wyniki podaj modelowi i poproś o opisanie realnych scenariuszy ataku.
Na co uważać: Bez klucza API dostaniesz lawinę fałszywych alarmów. Skan dużego repo kosztował autora około 5 dolarów, mniejszych — 20–30 centów. Wklejanie sesji i uruchamianie obcych skryptów instalacyjnych to czerwone flagi same w sobie — nawet jeśli autorowi nie chodziło o nic złego.
Redakcyjne tłumaczenie
Pięć narzędzi, o których mało kto wie
Trafiłem ostatnio na pięć nowych repozytoriów na GitHubie, które robią robotę — i połowa z nich nie ma nawet dziesięciu tysięcy gwiazdek. Dziwi mnie to, bo rozwiązują spore problemy, z którymi borykam się codziennie, budując aplikacje z pomocą AI. Przejdziemy przez każde po kolei, zobaczymy je w akcji, a przy okazji zastanowimy się, gdzie wpisać dane narzędzie w swój proces — bo niektóre z nich świetnie się uzupełniają.
Zaczynam od mojego faworyta, za który pewnie się ze mnie nabawicie: draw.io.
draw.io: narysuj, co właściwie zbudowałeś
W kodowaniu „na vibesach” — zwłaszcza bez inżynierskiego wykształcenia — bolą dwie rzeczy. Po pierwsze, często nie wiadomo, co realnie się zbudowało. Po drugie — jak te elementy łączą się ze sobą. To poważny kłopot, bo gdy przychodzi czas na poprawki albo trzeba zrozumieć, skąd bierze się błąd, opieramy się w całości na modelu językowym. A naprawdę potrzebne jest własne rozeznanie w tym, jak aplikacja działa.
Ten skill korzysta z interfejsu wiersza poleceń draw.io i służy do rysowania rzeczywistych diagramów architektury aplikacji. (Informacja dodatkowa: draw.io to popularne, darmowe narzędzie do tworzenia diagramów; „skill” to rozszerzenie Claude Code — instrukcja, którą model wykonuje jak przepis.) Na przykładowym diagramie widać powierzchnię mobilną, webową i panel administracyjny — wszystko trafia do wspólnego API, które rozdziela żądania między poszczególne usługi, a każda z nich ma własną bazę danych.
Taki obraz jest bezcenny, bo pokazuje, co dzieje się wewnątrz aplikacji i gdzie co mieszka. Moim zdaniem najlepsze podejście do vibe codingu to traktowanie go jako nieustannej nauki — właśnie po to, żeby budować coraz lepsze rzeczy. Najgorsze, co może się zdarzyć, to zatrzymanie się na obecnym poziomie. I w tym pomagają tego typu narzędzia.
Instalacja i użycie. Najpierw instalujemy interfejs draw.io — odpowiednim poleceniem zależnie od systemu: macOS, Windows, a jeśli ktoś jest prawdziwym twardzielem, to Linux. To na tyle proste, że nie będę opisywał. Potem dodajemy samego skilla: bez Claude Code wystarczy ogólne polecenie dodawania skilli, a w Claude Code można pójść drogą wtyczki — poleceniem /plugin dołączamy marketplace i stamtąd instalujemy.
Następnie wywołujemy skilla i zadajemy mu polecenie. Piękno polega na tym, że wystarczy opisać po ludzku, co chcemy zobaczyć. W pierwszym przykładzie poprosiłem: „Chcę zobaczyć różne warstwy usług w moim repozytorium”. Skill przemierzył kod — co, nawiasem mówiąc, nie pochłonęło wielu tokenów — i na tej podstawie narysował edytowalny diagram architektury. Po otwarciu w draw.io widać dokładnie to.
W tym wypadku to architektura MVP, nad którym pracujemy i który wdrażamy w mojej płatnej społeczności. Na samej górze jest warstwa prezentacji — odpowiedzialna wyłącznie za to, co widzi użytkownik: powierzchnię mobilną, nawigację i cały interfejs, różne stany, ikony, plakietki i nakładki. Niżej warstwa prezentacji rozmawia bezpośrednio z zarządzaniem stanem front-endu, czyli miejscem, w którym „żyją” dane, kiedy interfejs ich potrzebuje. Ten front-end załatwia wszystko przez warstwę usług — dostęp do danych i całą logikę biznesową. Aplikacja służy do logowania jedzenia naturalnym językiem, więc jest sporo interpretowania tego, co użytkownik wpisuje w czacie. Kiedy ktoś pisze „zapisz mi miskę kurczaka z ryżem”, system musi zrozumieć to zdanie i wyszukać odpowiednie produkty. W tej warstwie mieszka cały zestaw funkcji: resolver, funkcja przepisów i sporo innych.
Po co to wszystko? Większość ludzi, gdy coś się zepsuje, po prostu rzuca: „Claude, napraw to”. Model zwykle sobie poradzi, ale jeśli zmuszamy go do przeszukiwania całego projektu, a mogliśmy od razu wskazać miejsce, gdzie problem najpewniej leży — na dłuższą metę płacimy tokenami. I nie budujemy własnego rozumienia. Przykład: mam kłopoty z parsowaniem wiadomości użytkownika i z tym, czy agent jest wywoływany poprawnie. Wiem, że pierwszym podejrzanym będzie warstwa resolvera. Wysyłanie modelu do plików analityki czy telemetrii byłoby czystą stratą czasu.
Dalej na diagramie widać, że warstwa usług rozmawia z bazą danych: produkty, wpisy żywieniowe, przepisy, cele makroskładników — wszystko to leży w warstwie bazy. Ostatni element to funkcje edge, przez które łączymy się z usługami zewnętrznymi: PostHog zbiera zdarzenia produktowe, OpenAI obsługuje czat, a resztę załatwiają właśnie te funkcje. To oczywiście tylko jeden przykład — gdybyśmy chcieli zobaczyć, jak konkretne usługi podpinają się pod konkretne bazy i jak wygląda ta logika, wystarczy poprosić skilla o dopisanie tego do diagramu.
Na koniec tego wątku: niedawno na X pojawił się wpis szefa Microsoftu. W skrócie chodziło o to, że jesteśmy zafiksowani na punkcie „najlepszego modelu” i robienia wszystkiego jednym strzałem, w stylu efektownych pokazów. Ale jeśli zależy ci na długim terminie, traktuj te narzędzia jak pętlę uczenia się — bo model pchniesz dokładnie tak daleko, jak sięga twoja wiedza. Dlatego znakomici inżynierowie budują z ich pomocą naprawdę złożone systemy, a początkujący — choć super, że w ogóle potrafią złożyć apkę typu „przypomnij mi o wyprowadzeniu psa” — nie wykrócą poza ten poziom. Brakuje im słownika i rozumienia, by wiedzieć, dokąd można pójść dalej. Wydaje się to banalne, ale narzędzie, które systematycznie pokazuje ci, co siedzi w twoim projekcie, jest moim zdaniem bezcenne — i każdy powinien z czegoś takiego korzystać.
Ponytail: weteran, który tnie kod
Nawet z takim diagramem możesz w końcu odkryć, że to, co zbudowałeś, jest niepotrzebnie zakręcone. Technicznie działa — ale modele językowe uwodzą to, co lubią najbardziej: przeinżynierowywać rozwiązania. I dokładnie przed tym chroni następne narzędzie.
Ponytail ma, nawiasem mówiąc, jeden z najlepszych avatarów, jakie widziałem na GitHubie. Ale do rzeczy: modele w stuprocentach przypadków będą przeinżynierowywać. Możesz próbować je okiełznać, możesz mieć to gdzieś — i tak dostarczą abstrakcje, których projekt na obecnym etapie nie potrzebuje. Ta biblioteka ma to powstrzymać. Można o niej myśleć jak o wtyczkach „jaskiniowca”, które krążą ostatnio po sieci i każą modelowi odzywać się krócej i prościej — z tą różnicą, że tu działa to na poziomie samej implementacji: czy to, co robisz, da się w ogóle pominąć albo zrobić dużo prościej?
Jeśli pracowałeś w firmie SaaS, na pewno znałeś kogoś takiego: długi kucyk, owalne okulary, w firmie od czasów starszych niż kontrola wersji. Pokazujesz mu pięćdziesiąt linii. Patrzy, kręci głową, nie mówi nic — i zastępuje je jedną. Właśnie to próbuje robić ta biblioteka.
Instalujemy jak każdą wtyczkę: dodajemy marketplace i instalujemy. W środku jest kilka poleceń. Samo ponytail przydaje się, kiedy coś właśnie implementujesz. Z kolei audit przegląda cały projekt i wskazuje: gdzie trzymasz zbędne rzeczy, co da się uprościć, a co można skasować w całości. Audit świetnie sprawdza się też przy przeglądach kodu.
W naszym projekcie audit skończył pracę z listą rzeczy do poprawienia. Trzy elementy poleca usunąć całkowicie, bo realnie nie są używane — to projekt Expo (Informacja dodatkowa: Expo — popularny framework do budowy aplikacji mobilnych w React Native) i zaimportowaliśmy domyślne moduły, z których nic nie korzysta. Największy łup to siedem rzeczy do zredukowania. Przykład z naszej aplikacji: w procesie planowania zakładam, że wszystkie stany błędów projektuje się zawczasu, jeszcze przed budowaniem. Mamy więc trzy osobne komponenty paska błędu: zwykły, korekcyjny i „bezpieczny”. Różnią się wyłącznie treścią, kolorem i handlerem. Powinien istnieć jeden komponent, który przyjmuje te różnice jako właściwości — i o to chodzi w trybie „shrink”. No i wreszcie kategoria YAGNI, czyli „you ain’t gonna need it” — „nigdy tego nie wykorzystasz”. To sytuacje, w których przygotowujemy się na coś bardzo odległego, co nigdy nie nastąpi. Po co budować złożoność, skoro można prościej? Cała biblioteka jest o tym jednym.
Za chwilę pokażę inne podejście do tego samego problemu, bo narzędzie tego typu jest niesamowicie cenne — zwłaszcza dla osób bez inżynierskiego tła, ale szczerze mówiąc również dla inżynierów, którzy chcą pchnąć projekt w konkretnym kierunku. Trzeba tylko znaleźć — przy swoim poziomie doświadczenia, swoich umiejętnościach i swoim zestawie narzędzi — właściwe miejsce w procesie.
Handy: mów szybciej, niż piszesz — i to za darmo
Zanim jednak przejdziemy do tamtej alternatywy, pokażę narzędzie open source, które niedawno odkryłem, a które jest ogromnym udogodnieniem, jeśli jeszcze z czegoś takiego nie korzystasz. I jest darmowe.
Pewnie znasz statystykę: mówimy mniej więcej trzy razy szybciej, niż piszemy. Dlatego tylu ludzi wchodzi na całego w narzędzia typu WhisperFlow i po prostu wypowiada do modelu to, co ma się stać, zamiast siedzieć i klepać tekst. Pisząc, naturalnie skracamy — ucinamy kontekst, który wypadłby nam z głowy, gdybyśmy mogli go wyrzucić z ust szybciej. Płatnych narzędzi próbowałem wielu; teraz używam WhisperFlow, którego widać u mnie na dole ekranu. Ale kosztuje. Handy to w praktyce darmowa, otwartoźródłowa wersja czegoś takiego — z technicznego punktu widzenia odrobinę skromniejsza. Nie ma chyba funkcji przepisywania przez AI, którą oferuje WhisperFlow. Ale jeśli ci na tym nie zależy, a chcesz po prostu szybko wylewać myśli, to świetne narzędzie.
Instalacja na dwa sposoby: przez Homebrew albo ze strony — pobierasz wersję dla swojej platformy, pobiera się błyskawicznie, a na macOS przeciągasz ikonę do folderu aplikacji; na innych systemach robisz, co trzeba. Otwierasz, akceptujesz uprawnienia. Co ciekawe, można wybrać model zależnie od maszyny — zależy ci bardziej na trafności czy na szybkości? Parakeet zdobywa ostatnio sporą popularność; jest też Whisper large, który wolniej przetwarza, ale jest bardzo dokładny. Wybieram Parakeet.
Bez żadnej dodatkowej konfiguracji wystarczy Command+spacja — i mówimy. Może to być feedback do specyfikacji, nad którą siedzimy w projekcie: nie podoba nam się kierunek, chcemy się cofnąć i wytłumaczyć coś inaczej — cokolwiek. Cała wypowiedź pojawiła się na ekranie i była zaskakująco trafna. Można dyktować dosłownie wszystko, byle co — znowu dobrze. Różnica względem WhisperFlow polega na tym, że tamten wycina wypełniacze: gdy bredzisz albo co chwilę mówisz „yyy”, czyści tekst. Ale przy pracy z modelem językowym nie ma to według mnie większego znaczenia. Jeśli więc kusiło cię coś w stylu WhisperFlow, a nie potrafiłbyś przełknąć tych dwudziestu dolarów miesięcznie — Handy jest naprawdę fajną, darmową opcją.
Improve od Shadcna: audyt, który zwraca plan, nie łatkę
Warto jednak przetestować dyktowanie na czymś pożytecznym. Jak połączyć Handy z kolejnym skillem z listy, żeby realnie podnieść wydajność?
Skill nazywa się improve i wyszedł od Shadcna — Shad CN czy Shade CN, wciąż nie wiem, jak to wymówić; napiszcie w komentarzach, żebym wreszcie przestał to kaleczyć w filmach. Narzędziem jest audytor bazy kodu. Kiedy — całkiem niedawno — mieliśmy dostęp do Fable 5 przez jakieś dwa i pół dnia (Informacja dodatkowa: Fable 5 — model językowy wspomniany jako dostępny tylko przez kilka dni; autor korzystał z niego intensywnie w tamtym oknie czasowym), był to jeden ze skilli, których używałem bez przerwy, żeby podnosić jakość projektów. Z mojego doświadczenia Fable 5 sam w sobie świetnie radził sobie z ulepszaniem tego, co już istnieje — tam, gdzie w projekcie były jakieś wzorce. Ludzie pokazywali głównie efektowne dema nowych rzeczy zrobionych jednym promptem — fajnie, ale jego mocą było naprawianie istniejących projektów. I tak w ogóle: moim zdaniem przy każdym skoku jakości modeli powinniśmy wykorzystywać tę okazję na ulepszanie tego, co już zbudowaliśmy. Dopóki nie oddadzą nam tamtego modelu, ten skill dalej robi robotę.
W praktyce wywołujemy improve, a prompt dyktujemy właśnie przez Handy: „Zrób audyt naszej aplikacji, ale konkretnie przyjrzyj się skuteczności funkcji resolverów. Jak parsujemy to, co przychodzi na front-end od użytkownika przez czat, i jak decydujemy, czy to musi pójść przez model językowy do agenta, czy da się to rozwiązać zwykłym wyszukiwaniem? To będzie przede wszystkim ćwiczenie z optymalizacji tokenów, ale w rekomendacjach zadbaj o to, by nie spadać z trafnością — właściwe akcje musimy podejmować wtedy, kiedy trzeba”.
Gdybym musiał to wszystko wystukać, pewnie napisałbym: „zoptymalizuj mój kod pod kątem wywołań modelu”. A tak mogłem włożyć znacznie więcej kontekstu i porządnie rozwinąć myśl. Gdyby nie kamera, zrobiłbym kilka takich „zrzutów myśli” do pliku tekstowego i wkleił całość naraz.
Wszystko się tu spina. Wróćmy na chwilę do skilla draw.io: to właśnie dzięki diagramowi architektury — i temu, że śledziłem, co się buduje, czytałem specyfikacje i starałem się rozumieć, co i po co robi — wiedziałem, gdzie szukać nieefektywności. Cała ta logika siedzi w resolverze. Skoro mogę modelowi wskazać to miejsce, analiza od razu wychodzi lepsza.
Jedno z powodów, dla których lubię narzędzia tego typu — niekoniecznie to konkretne, byle o podobnym działaniu — to wyłapywanie przypadków brzegowych. W tej aplikacji prosiłem już wcześniej Opusa o naprawę. I co się okazało: naprawił w jednym miejscu. Optymalizacja, o którą teraz pytam, już istnieje w kodzie — ale siedzi wyłącznie w funkcji komponowania przepisu. Gdy ktoś mówi przez telefon naturalnym językiem: „Miska z kurczakiem i ryżem — 100 gramów kurczaka, 50 gramów ryżu i mój domowy sos buffalo” — tylko tam to działa. A miejsc w aplikacji, w których taka optymalizacja powinna działać, jest mnóstwo. W praktyce większość tego leci prosto do modelu językowego, choć sporo dałoby się rozstrzygnąć deterministycznie — czyli bez udziału modelu w ogóle. Dokładnie to narzędzie znalazło i teraz wylicza kolejne znaleziska: co najmniej cztery problemy, w których jest dość pewne, poprawka wymaga niewiele wysiłku, a ryzyko refaktoryzacji jest niskie.
I co bardzo lubię: to narzędzie nie wprowadza zmian w tym samym oddechu, jak to lubi wiele innych. Buduje plan — który potem możesz zrealizować czymkolwiek zechcesz.
Backlog w GitHub Issues i pętla agentów
Jak wyglądają moje konkretne następne kroki w tym workflow? Zamieniam takie plany na issues w GitHubie. Dlaczego właśnie tak? Bo — wracając do filmu sprzed tygodnia o pętlach agentów — jeden z najbardziej wartościowych moich nawyków wygląda tak: ilekroć mam jasny koncept — błąd, prośbę o funkcję, optymalizację, cokolwiek — tworzę z tego issue i upewniam się, że podoba mi się plan realizacji. W ten sposób buduję duży backlog. Potem w ciągu tygodnia w tle pracuje agent: pobiera otwarte issues, implementuje je, tworzy pull requesty, a ja wchodzę tylko na przegląd przed scaleniem do głównego projektu. Ta pętla zaczyna się właśnie od narzędzia typu improve. Nie widzę powodu, żeby nie używać GitHuba — są inne narzędzia, jak Linear i pozostałe menedżery projektów, ale skoro moje repozytorium stoi na GitHubie, nie potrzebuję nadskomplikowanego rozwiązania. Po nagraniu tego filmu odpalam właśnie agentów do realizacji tych zadań. Jeśli chcecie film o takich pętlach agentowych — dajcie znać w komentarzach, chętnie coś skleję.
W repozytorium widać wszystkie cztery issues. Dorzucam do nich etykiety zależnie od tego, co dokładnie trzeba zrobić — wszystko z etykietą backlog nie zostanie ruszone przez automatyczne przebiegi. Zbudujcie własny system zarządzania, ale sam proces jest naprawdę solidny. W samym issue widać, gdzie leży plan i dlaczego wprowadzamy zmianę; można też dalej rozmawiać — otagować Claude i kazać mu coś doczytać. Dużo możliwości, a całość po prostu działa.
Skill Specter od NVIDII: przeskanuj, zanim zainstalujesz
Ostatnia rzecz jest luźniej związana z resztą, ale to narzędzie, którego każdy powinien używać w określonych sytuacjach. Nie jest to nawet skill, tylko — że tak powiem — skaner skilli, wydany przez NVIDIĘ. Zestaw do audytu bezpieczeństwa, wyspecjalizowany w przesiewaniu bibliotek skilli.
Konkretny przykład użycia. Trafiłem niedawno na repozytorium, które mocno goni na licznikach trendów. Jedyny mój problem: całość jest po chińsku. A ja z natury, zanim zacznę używać nowej biblioteki, najpierw próbuję zrozumieć, jak działa. Teoretycznie można by przełączyć repo na angielski i czytać, ale… to podręcznikowy przypadek na skan. Nie mam pojęcia, co może siedzieć w tej bibliotece skryptów. Dałoby się coś tam przeczytać, ale realnie — jeśli tekst jest w języku, którego nie znasz, potencjalnych pułapek może być bez liku.
Kopiujemy adres repozytorium, wchodzimy w terminalu do katalogu projektu Skill Specter… Zanim jednak cokolwiek odpalisz, jedno zastrzeżenie: trzeba sklonować to repozytorium, mieć na maszynie Pythona, postawić środowisko wirtualne i doinstalować zależności (jeśli nie czujesz się w tym pewnie, możesz poprosić o pomoc model). Samo narzędzie da się odpalić za darmo, ale zaleje cię taką lawiną fałszywych alarmów, że będzie to bezużyteczne. Ja do tego skanu podpiąłem klucz API OpenAI.
Polecenie brzmi: skan Skill Specter plus wklejony adres — i rusza. Szczególnie jeśli jesteś z tych, którzy „automatyzują sobie całe życie” na OpenClaw (Informacja dodatkowa: OpenClaw — głośny ostatnio otwartoźródłowy asystent AI do automatyzacji zadań, chętnie (i często przesadnie) promowany w sieci) i podobno zarabiają milion dziennie, nie kiwnąwszy palcem, bo bot sprzedaje za nich produkty… A nawet jeśli po prostu lubisz eksperymentować: skill to ogromna powierzchnia ataku. I nie mówię tylko o script kiddies siedzących w piwnicy u rodziców przy chrupkach — także o utalentowanych hakerach, którzy chcą po prostu skorzystać z tego, co zbudowałeś. Umiejętność przesiewania takich rzeczy jest bezcenna.
Wynik mnie szczerze zaskoczył: krytyczny problem, „nie instalować”. Ciekawe — sprawdźmy dlaczego, bo może to coś, co mimo wszystko zdecydowałbyś się zignorować. Największy problem to liczba funkcji wykonywalnych: te skrypty potrafią korzystać z wyszukiwania XSS, wyszukiwania na GitHubie i całej masy podobnych rzeczy. Dajesz obcym skryptom możliwość wykonywania kodu na swojej maszynie. W sumie skaner znalazł 63 problemy — dałoby się je przejrzeć ręcznie, ale to kupa roboty, więc wkleiłem całość do Claude’a i poprosiłem o opisanie realnych scenariuszy ataku, wynikających z konstrukcji tego projektu. Po pierwsze: w kilku miejscach trzeba wkleić własne ciasteczka. To bardzo, bardzo ryzykowne — każdy, kto przejmie te dane, przejmuje pełną kontrolę nad wszystkim, co wkleiłeś: sesjami na Twitterze, Reddicie, czymkolwiek. Po drugie — moim zdaniem jeszcze poważniejsze: zdalne wykonanie kodu przez nieweryfikowane skrypty instalacyjne i aktualizacyjne. W pliku projektu jest zewnętrzny skrypt instalacyjny, który pobierasz i puścisz wprost na swoją maszynę. Poważny, poważny problem. Widzieliśmy ostatnio wystarczająco wiele ataków na łańcuch dostaw oprogramowania, żeby wiedzieć: nawet jeśli autor nie ma złych zamiarów, to wygodny sposób, żeby stracić kontrolę nad wszystkim, co masz.
Koszt całości? Kilka takich skanów już zrobiłem i ten, na stosunkowo dużym projekcie, kosztował mnie jakieś 5 dolarów; mniejsze repozytoria wychodziły po 20–30 centów. Tyle dla pełnego obrazu — tyle kosztuje skan bezpieczeństwa takiego projektu.
Na koniec
To pięć całkiem nowych repozytoriów — żądna z nich wcześniej nie znałem — i moim zdaniem robią robotę. Jeśli film był pomocny, zasubskrybuj kanał. Na tym dziś kończymy — do zobaczenia w następnym.