O czym jest ten film
- Autor, inżynier o blisko 20-letnim stażu, doradza programistom pracującym z agentami kodującymi — i tym, którzy wciąż wahają się, czy w ogóle ich używać.
- Programiści dzielą się na dwa obozy: seniorów piszących cały kod ręcznie i nieufnych wobec agentów oraz uczniów i studentów, którzy wątpią, czy nauka programowania jeszcze się opłaca.
- Przyszłość branży: będziemy pisać znacznie mniej kodu, ale czytanie kodu pozostaje umiejętnością kluczową — nawet flagowe modele Anthropic i OpenAI popełniają rażące błędy (zdublowane funkcje i API, pętle zagnieżdżone w pętlach).
- Odpowiedzialność za aplikację nigdy nie przechodzi na agenta: w praktyce „wynajmujesz” Claude jako programistę, ale to twoje nazwisko stoi za produktem.
- Autor udostępnia dwa darmowe skille: start-an-app (reguły budowy aplikacji: m.in. baner cookies, opcja usunięcia konta, preferowany stack technologiczny) oraz review-an-app (audyt bezpieczeństwa m.in. wg OWASP Top 10, a także SEO i dryw funkcjonalności).
- Nauka z agentem: sklonowane projekty open source (przykład: system pamięci w Hermes Agent) plus własne notatki budują „skrzynkę narzędziową” sprawdzonych decyzji technologicznych.
- Pracuj małymi fragmentami: jedno logiczne zadanie na sesję, potem przegląd zmian, wyjaśnienie od agenta, commit i nowa sesja — m.in. dlatego, że powyżej ok. 70% zapełnienia okna kontekstowego (ok. miliona tokenów) jakość rezultatów spada.
- Profesjonalny warsztat: ucz się pojęć, nie narzędzi — hooki, reguły, pliki pamięci, skille czy MCP są wspólne dla wszystkich harnessów, a firmy często budują własne.
- Pliki pamięci CLAUDE.md/AGENTS.md (globalne albo projektowe, komponowalne przez @-odwołania) oraz twarda definicja „gotowe”: testy, lint, typecheck i build muszą przejść.
- Docelowa pętla pracy: issue → implementacja przez agenta → pull request z dowodami testów → audyt bezpieczeństwa zgłaszany jako kolejne issue; dla sceptyków rada: barierki zamiast unikania, start od zadań niskiego ryzyka.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Czytanie kodu to dziś umiejętność pierwszorzędna
Na czym polega: Będziemy pisać coraz mniej kodu, ale nawet najlepsze modele Anthropic i OpenAI popełniają rażące błędy: zdublowane funkcje, zduplikowane API, pętle zagnieżdżone w pętlach. Wartość programisty przesuwa się z pisania na rozumienie i weryfikowanie kodu wygenerowanego przez maszynę.
Jak stosować: Po każdym zakończonym zadaniu agenta przejrzyj zmiany w plikach i wypatruj typowych wpadek. Jednolinijkową poprawkę nanieś samodzielnie — szybciej i bez marnowania tokenów na kolejną turę promptowania.
Na co uważać: Pewny ton modelu nie jest dowodem poprawności. Bez umiejętności czytania kodu nie zauważysz problemu, dopóki nie wypłynie na produkcji.
2.Odpowiedzialność nie przechodzi na agenta
Na czym polega: Relacja z agentem przypomina kontrakt z podwykonawcą: Claude „wykonał pracę w twoim imieniu”, ale ty pozostajesz właścicielem biznesu. Awaria albo włamanie to twoje zmartwienie — i właśnie to rozróżnienie oddziela „vibe codera” od inżyniera AI.
Jak stosować: Zanim wdrożysz, sprawdź skalowalność i bezpieczeństwo; okresowo zlecaj audyty w osobnej sesji agenta (np. według listy OWASP Top 10).
Na co uważać: Iluzja „to zbudował agent, nie ja” — prawnie, biznesowo i zawodowo odpowiadasz ty.
3.Zamień doświadczenie w reguły — skill dla agenta
Na czym polega: Lekcje wyniesione z lat pracy (baner cookies i opcja usunięcia konta wymagane w większości krajów, strony prawne, preferowany stack — np. Drizzle ORM, SQLite na prototypy, Postgres na produkcję) można zapisać jako skill: zestaw plików, które agent wczytuje na starcie. Bez tego agent te elementy pomija i trzeba je dopominać się promptami.
Jak stosować: Stwórz główny plik SKILL.md z zasadami oraz folder references z decyzjami technologicznymi. Stack definiuj sam, zamiast zdawać się na wybór modelu.
Na co uważać: Reguły to nie gwarancja — agent może od nich odbiegać, zwłaszcza w długich sesjach. Skill uzupełnia przegląd kodu, nie zastępuje go.
4.Ucz się na cudzym kodzie i zbieraj skrzynkę narzędziową
Na czym polega: Programistyczne tutoriale zanikają, a agent jest „najcierpliwszym korepetytorem”: sklonowany projekt open source (np. Hermes Agent ze swoim systemem pamięci) omówi na dowolnym poziomie szczegółu i w języku, który rozumiesz.
Jak stosować: Każ agentowi rozbierać projekt na warstwy (frontend, backend, autoryzacja, baza danych, ORM) i wyjaśniać elementy, które cię ciekawią. Wnioski od razu notuj w Notion czy Obsidian — np. „do aplikacji SaaS bierze się Postgresa” albo „tej biblioteki unikam, bo porzucona”.
Na co uważać: Wiedza bez notatek wyparowuje. Analizuj także własny kod — pytaj agenta, jakie decyzje bezpieczeństwa i optymalizacje podjął przy nowej funkcji.
5.Jedna sesja — jeden fragment pracy
Na czym polega: Budowanie całego rozwiązania w jednym promptsie uniemożliwia sensowny przegląd, a do tego degraduje jakość: okno kontekstowe topowych modeli to około miliona tokenów i po przekroczeniu mniej więcej 70% zapełnienia rezultaty się pogarszają.
Jak stosować: Zleć coś konkretnego (szkielet projektu albo pojedynczą funkcję) → przejrzyj zmiany → poproś agenta o oprowadzenie („jakie powstały endpointy API i jak działają?”) → commit → nowa sesja na kolejny kawałek. I tak w kółko.
Na co uważać: Nie ruszaj dalej, dopóki nie rozumiesz zmian — inaczej zbudujesz system, którego nie umiesz utrzymać.
6.Ucz się pojęć, nie narzędzi
Na czym polega: Popularność konkretnego harnessa (Claude Code, Codex) może się odwrócić w miesiąc, ale pojęcia — hooki, reguły, pliki pamięci, skille, MCP — przenoszą się między narzędziami. Firmy i tak często budują własne harnessy z politykami i ograniczeniami.
Jak stosować: Certyfikaty traktuj jako dodatek, nie cel. Inwestuj w rozumienie mechanizmów wspólnych dla wszystkich platform.
Na co uważać: Presja „muszę opanować narzędzie X” to gonienie własnego ogona — narzędzie może się zestarzeć, zanim skończysz kurs.
7.Opanuj pliki pamięci: CLAUDE.md i AGENTS.md
Na czym polega: To pliki reguł działające między sesjami — globalne albo przypisane do projektu. Ich treść trafia do kontekstu tuż po prompcie systemowym. Są komponowalne: setki linii można rozbić na małe pliki i podpiąć odwołaniami przez symbol @.
Jak stosować: Trzymaj w nich preferencje, barierki „czyń i nie czyń”, standardy kodowania i design system. Ja (autor) te mniejsze pliki trzymam w folderze docs, a w głównym pliku pamięci wstawiam tylko @-odwołania.
Na co uważać: Agent z czasem odbiega od reguł, zwłaszcza gdy sesja się wydłuży — weryfikuj rezultaty i resetuj kontekst.
8.Zdefiniuj na twardo, co znaczy „gotowe”
Na czym polega: Domyślnie agent ogłasza koniec pracy w chwili, gdy skończy pisać kod. Z inżynierskiego punktu widzenia to za mało.
Jak stosować: Dodaj regułę do pliku pamięci: zadanie jest skończone dopiero, gdy przejdzie zestaw testów, lint, typecheck i build. Szczegóły dopasuj do stacka — testy i sprawdzanie typów ma niemal każdy framework.
Na co uważać: Kryteria muszą być automatyczne. „Agent oświadczył, że przetestował” nie jest dowodem.
9.Pętla issue → pull request z dowodami
Na czym polega: Zamiast promptować wprost, wystawiaj issues (np. na GitHubie) i każ agentowi je pobierać, implementować, komentować i zamykać pull requestem z dowodami z testów: zrzutami ekranu, raportami. W praktyce traktujesz agenta jak członka zespołu.
Jak stosować: Pull request przeglądasz wygodnie nawet z telefonu, a dołączone dowody zwiększają pewność przed scaleniem. Ten nawyk świetnie skaluje się do „fabryk oprogramowania” i rojów agentów, gdzie kilka maszyn czeka na gotowości do pracy.
Na co uważać: Schemat nie wymaga GitHuba, ale wymaga dyscypliny „gotowe = przetestowane” — inaczej dowody w PR staną się formalnością.
10.Dla sceptyków: barierki zamiast unikania
Na czym polega: Ręczne pisanie wszystkiego nie obroni się ekonomicznie — dziś oczekuje się, że kod jest tani, a agent potrafi równolegle (przez worktree, czyli równoległe kopie robocze repozytorium) tworzyć warianty rozwiązania. Doświadczenie seniora najlepiej wykorzystać na budowanie reguł i ograniczeń, bo agentom brakuje zmysłu architektonicznego, gustu i wyczucia, co wywali się na produkcji.
Jak stosować: Wchodź stopniowo: zacznij od zadań niskiego ryzyka, najlepiej takich, których i tak nie lubisz — aktualizacja testów jednostkowych, dokumentacji, ogarnianie ticketów w Jirze, refaktoryzacja, triage błędów.
Na co uważać: Postawa „nie ufam, więc nie używam” oddaje przewagę innym; pełne zaufanie bez barierków zaprasza katastrofę.
Redakcyjne tłumaczenie
Wprowadzenie: dwadzieścia lat w branży, jedno pytanie
Od niemal dwudziestu lat pracuję jako inżynier oprogramowania. Poniżej przemyślenia, które chętnie przekazałbym każdemu programiście sięgającemu po agenty kodujące. Jeśli jesteś studentem, który zastanawia się, czy nauka programowania w ogóle jeszcze się opłaca, albo seniorem piszącym do dziś każdą linijkę ręcznie — ten materiał jest dla was. Pokażę umiejętność, która obecnie znaczy więcej niż samo pisanie kodu, wyjaśnię, jak z pomocą agentów uczyć się szybciej, i opiszę sposób pracy, dzięki któremu wdrażam kod, na którym mogę polegać.
Co tydzień któryś z guru AI ogłasza, że właśnie zbudował w Claude Code aplikację „wypuszczoną na milion dolarów” albo kolejną automatyzację. Czego te zapowiedzi przemilczają? Tego, że gdy taką aplikację ktoś zhackuje, winy nie przeniesiesz na Claude Code. Zostańcie więc ze mną — opowiem, jak budować aplikacje odpowiedzialnie i tak, żeby wytrzymały skalowanie. Wrzucę też dwa darmowe narzędzia, dzięki którym łatwiej taką aplikację zbudować i zabezpieczyć.
(Informacja dodatkowa: Claude Code to działające w terminalu narzędzie Anthropic, które na podstawie poleceń w języku naturalnym samodzielnie tworzy i modyfikuje pliki w projekcie programistycznym.)
Czy pisanie kodu ma jeszcze sens?
Żeby odpowiedzieć na to pytanie — i od razu ustawić ramy całego wywodu — podzielę programistów na dwa obozy. Z jednej strony seniorzy, którzy nadal piszą cały kod i wszystkie testy jednostkowe ręcznie. Może raz spróbowali ChatGPT albo Claude Code, efekt ich nie przekonał i agenci nigdy nie dostali realnej szansy. Z drugiej strony uczniowie i studenci, którzy zastanawiają się, czy uczyć się programowania w ogóle.
Moim zdaniem rzeczywistość wygląda tak: odtąd będziemy pisać znacznie mniej kodu niż pisaliśmy dotąd. To jednak nie znaczy, że nie powinieneś umieć kodu czytać, a nawet pisać. Wręcz przeciwnie — umiejętność czytania kodu jest dziś najważniejsza.
Dlaczego? Bo agenty, zupełnie jak doświadczeni ludzie, potrafią nawyrabiać błędów — i to również najmocniejsze modele. Widziałem, jak flagowe modele Anthropic i OpenAI popełniały rażące wpadki: tworzyły zdublowane funkcje, pisały kod o fatalnej wydajności, wpakowując pętle w pętle, a nawet powielały całe API. Dlatego po skończonej pracy agenta zawsze przejrzyj zmiany w plikach i poszukaj właśnie takich oczywistych potknięć. A jeśli poprawka jest trywialna — jedna linijka — zrób ją sam, zamiast spalać tokeny i czas na kolejną rundę promptów.
A, seniorzy — nie wyłączajcie: sekcja o profesjonalnym warsztacie jest dokładnie dla was.
Wtrącenie sponsorskie: TripleTen
(Poniższy fragment to płatna sekcja sponsorska z oryginalnego materiału; zachowujemy ją w skrócie ze względu na kompletność.)
Agenty kodujące piszą już dziś sporą część kodu i firmy to zauważyły. W pierwszej połowie 2026 roku niemal co czwarta ogłoszona w USA fala zwolnień wskazywała AI jako przyczynę. Logika jest prosta: najpierw znika praca rutynowa. Płaci się dziś za budowanie i utrzymywanie systemów AI na produkcji. Narzędzie nauczysz się z tutorialu — doświadczenia się nie nauczysz. Sponsor tego odcinka, TripleTen (część grupy Nebius), prowadzi dwa programy dla inżynierów z co najmniej dwuletnim doświadczeniem produkcyjnym: AI systems engineering oraz AI i machine learning. Prowadzą je praktycy, których można sobie sprawdzić — tacy jak dr Gönen Eren czy Mohamed Cherif. Instruktorzy publikują też na GitHubie przykładowe projekty, na przykład system reagowania na incydenty, który odnajduje odpowiedni runbook (instrukcję postępowania przy awarii), planuje poprawkę i czeka na ludzką akceptację — dokładnie takie systemy budują uczestnicy. Program obejmuje również samo szukanie pracy: próbne rozmowy techniczne i z HR, CV, LinkedIn. Obie ścieżki da się pogodzić z etatem. W opisie filmu znajdziecie trójminutowy audyt umiejętności oraz szczegóły programów.
Od „vibe codera” do inżyniera AI
Czego nieustannie uczę na kanale i we wspólnotie, którą prowadzę: w chwili, gdy zaczynasz brać odpowiedzialność, przestajesz być vibe coderem i stajesz się inżynierem AI. (Informacja dodatkowa: „vibe coder” — potoczne określenie osoby generującej kod promptami, bez rozumienia, co właściwie powstaje.)
Agent mógł zbudować aplikację, dodać logowanie użytkowników, podpiąć płatności i wdrożyć ją do sieci. To, że zrobił to agent, nie umniejsza twojej odpowiedzialności ani o promil. Jeśli aplikacja padnie albo ktoś się przez nią włamie, nie zrzucisz winy na Claude. W gruncie rzeczy wynająłeś Claude jako programistę do pracy w twoim imieniu — ale to ty pozostajesz właścicielem biznesu i to twoje nazwisko stoi za aplikacją. Musisz zagwarantować, że będzie skalowalna i bezpieczna.
Dobrze rozumiane fundamenty inżynierii oprogramowania zyskują na znaczeniu z miesiąca na miesiąc. Nie napiszesz dobrego promptu, jeśli nie wiesz, o co prosić. Nie zrecenzujesz kodu. Nie dostrzeżesz nadchodzących problemów. Sporo z tego przychodzi z doświadczeniem, ale zaraz pokażę, jak można agentów używać również do podnoszenia własnych kwalifikacji. Gdy rozumiesz fundamenty, wiesz dokładnie, jak formułować polecenia, żeby dostać to, czego chcesz.
Zamień doświadczenie w reguły: skill „start-an-app”
Fundamenty możesz wynieść ze studiów albo z lat pracy w branży. Niezależnie od źródła całą tę wiedzę — wszystkie lekcje nauczone na własnej skórze — możesz przenieść do pliku zwanego skillem. (Informacja dodatkowa: skill to w narzędziach takich jak Claude Code zestaw plików z regułami i wytycznymi, które agent automatycznie wczytuje przed rozpoczęciem pracy.)
Przez lata zbudowałem mnóstwo aplikacji internetowych i przy okazji poznałem zarówno pułapki, jak i sprawdzalne schematy: jakie stacki się bronią i czego każda aplikacja zwykle potrzebuje. Owocem tego jest skill start-an-app, który udostępniam bezpłatnie. W jego folderze znajduje się główny plik SKILL.md — zwięzły opis tego, czym skill jest. W praktyce mówi agentowi: skoro budujesz aplikację webową, oto zasady, których się trzymasz.
Wiem z doświadczenia, że w większości krajów aplikacja internetowa potrzebuje banera cookies z wyborem preferencji, a użytkownik zakładający konto powinien mieć możliwość usunięcia go z serwisu. Domyślnie żaden agent, z jakim pracowałem, tego nie wdraża — za każdym razem musiałem dopominać się o to promptami. To samo dotyczy stron prawnych, polityki prywatności i tym podobnych. Skill mówi agentowi od samego początku: te strony i funkcje wchodzą w zakres pracy.
Zdefiniowałem w nim także stack technologiczny, którego używam. Zamiast pozwalać Claude wybierać, wolę rozstrzygnąć wszystko sam. W folderze references jest na przykład dokument poświęcony bazom danych: do ORM używam Drizzle, do prototypów i pracy lokalnej SQLite, a na produkcję Postgresa. U ciebie może to być dowolna inna baza — zasada pozostaje ta sama. I nie kończy się na bazach: skill obejmuje możliwości AI, systemy designu, maile transakcyjne, kolejki zadań, serwery MCP, operations, płatności, SEO i co tam jeszcze przyjdzie na myśl.
Agent jako najcierpliwszy korepetytor
Dobrze — więc trzeba rozumieć czytanie kodu, pisanie kodu i architekturę oprogramowania. Jak do tego dojść? Ta część dotyczy i studentów, i seniorów, bo w tym zawodzie nie przestaje się uczyć nigdy.
Do mniej więcej trzech lat temu przerabiałem masy kursów na Udemy i filmów na YouTube o Reactcie, Next.js i każdym kolejnym frameworku JavaScriptu. Może zauważyliście, że tutoriale programistyczne stają się ostatnio bardzo trudne do zdobycia — sam się od nich odwróciłem, bo po prostu nie mają już wyświetleń. To nie znaczy, że fundamenty przestały być ważne; proponuję jedynie inną drogę.
Do nauki nowych języków, bibliotek i frameworków agent kodujący jest najcierpliwszym korepetytorem, jakiego będziesz mieć w życiu. Członkom mojej wspólnoty radzę: znajdźcie na GitHubie projekt open source, który naprawdę wam się podoba. Gdy wyszedł Hermes Agent, jego system pamięci zrobił na mnie ogromne wrażenie. Schemat postępowania jest prosty: sklonuj taki projekt na dysk, otwórz w Claude Code i każ agentowi oprowadzić cię po kodzie takim językiem i w takim tempie, jakie rozumiesz.
Konkretne pytania? Po pierwsze: niech rozbije stack na części — komponenty frontendowe, serwer backendowy, warstwę pośrednią, autoryzację, bazę danych, ORM. Jeśli coś cię zaciekawi — jakiś komponent interfejsu czy animacja — dopytaj, jak to działa i jakiej biblioteki użyto. Poza stackiem możesz wypytać o działanie konkretnej funkcji. W Hermes Agencie olśnił mnie mechanizm pamięci: agent stale uczy się o tobie i sam się usprawnia. Kazałem więc Claude Code przeanalizować kod i wyjaśnić mi, jak ten system działa — i wyjaśnił, tak szczegółowo, jak tylko potrzebowałem.
I najważniejsze: nie pozwól, żeby ta wiedza uciekła. Notuj. W Notion, Obsidianie, czymkolwiek się posługujesz, choćby „drugim mózgiem”. W praktyce budujesz skrzynkę narzędziową — zbiór komponentów, z których później składasz własne aplikacje. Może zauważysz, że niemal wszystkie analizowane projekty używają Postgresa. Zapisujesz: do aplikacji SaaS bierze się Postgresa. Przy kolejnym projekcie wiesz już, jakiej bazy użyć. Analogicznie z bibliotekami AI, komponentami UI i tak dalej.
To nie ogranicza się do cudzego kodu. Nie szczędź pytań agentowi także nad własnym. Gdy zbuduje ci projekt albo doda funkcję, zapytaj, jakie kwestie bezpieczeństwa wziął pod uwagę i jakie optymalizacje wydajności wprowadził. Nic nie zastąpi doświadczenia — a także seniorowie muszą zdobyć doświadczenie w pracy z agentami. Budujcie jak najwięcej projektów. Rzuć sobie wyzwanie: weź aplikację, z której korzystasz codziennie — jakiś płatny SaaS albo coś, co robi na tobie wrażenie — i spróbuj zbudować „własnego TikToka” albo Booking.com. Sięgnij do swojej skrzynki narzędzi i każ agentowi to zbudować, maksymalnie konkretnie określając stack. Żądaj przy tym wyjaśnień na każdym kroku: to również twoja lekcja.
Uwierzcie, ile razy Claude z pełnym przekonaniem doradzał jakąś bibliotekę, żeby po czasie okazało się, że pakiet jest przestarzały, porzucony albo po prostu nie działa. Zawsze wtedy robię notatkę — w głowie albo w skrzynce narzędziowej — żeby już nigdy z niego nie korzystać. Gdy przy kolejnym projekcie Claude zaproponuje to samo, po prostu go prostuję.
Jedna sesja — jeden fragment pracy
Kolejna rada: nie każ Claude budować całego rozwiązania w jednej sesji. Pracuj małymi kawałkami, jedna logiczna cząstka naraz. I nie chodzi tu tylko o ochronę okna kontekstowego — choć to także. Dla jasności: agent ma ograniczone okno kontekstowe; w modelach flagowych to około miliona tokenów. Im więcej pracy agent wykona w ramach jednego okna, tym bardziej je zapełnia, a po przekroczeniu mniej więcej siedemdziesięciu procent jakość zaczyna się sypać. To po części powód. Prawdziwy powód jest jednak inny: musisz umieć przejrzeć kod i zrozumieć, co zostało zrobione, zanim ruszysz dalej.
Jak to wygląda w praktyce? Zleć agentowi coś bardzo konkretnego: przygotowanie szkieletu projektu albo dodanie określonej funkcji. Gdy skończy, przejrzyj zmiany — obejrzyj kod, zobacz, co dokładnie doszło do folderu projektu, poproś o krótkie oprowadzenie po poprawkach. Powiedzmy, że dodałeś funkcję, którą chcesz udostępnić światu przez endpointy API. Zapytaj agenta, jakie to endpointy i jak właściwie działają. Kiedy przejrzałeś ten kawałek pracy i rozumiesz go, każ zrobić commit i otwórz nową sesję Claude na kolejny element. I tak w kółko.
Dokańczaj projekty: portfolio zamiast półproduktów
Na koniec tej części — zwłaszcza dla początkujących: zacząłeś projekt, to go dokończ. Kusi nas skakanie na kolejny świeży pomysł, a w efekcie zostaje sterta niedokończonych rzeczy. Tymczasem jest cała masa radości w doprowadzeniu czegoś od początku do końca, wdrożeniu online i oddaniu choćby znajomym i rodzinie. Ukończony projekt wrzuć na GitHuba — budujesz w ten sposób portfolio do pokazania przyszłym pracodawcom. Przeprowadziłem w karierze mnóstwo rozmów rekrutacyjnych i zawsze cieszyłem się, gdy kandydat przynosił własne projekty: mogłem sprawdzić jego wiedzę o konkretnej aplikacji i jednocześnie zobaczyć, że po prostu lubi budować.
Profesjonalny warsztat: pojęcia ważniejsze niż narzędzia
Często dostaję pytania, czy warto robić certyfikaty technologii konkretnego dostawcy. Jako osoba, która sama uwielbia się uczyć, nie powiem, że to zły pomysł — ale daleko mu do sprawy najważniejszej. Moja wskazówka brzmi: ucz się pojęć, nie narzędzi. Ludzie wpadają w obsesję i stres na punkcie „muszę opanować Codexa”. Nie musisz skupiać się na jednym narzędziu. Tempo zmian jest szalone: Codex może być dziś najpopularniejszym harness, ale kto wie, co będzie za tydzień albo za miesiąc. Pojęcia zostają. Wszystkie harnessy obsługują hooki, reguły, pliki pamięci agenta, konteksty, skille, MCP i tak dalej.
(Informacja dodatkowa: harness to program „opakowujący” model językowy — np. Claude Code czy Codex — który daje mu dostęp do narzędzi, plików i terminala. MCP, czyli Model Context Protocol, to standard podłączania do modeli zewnętrznych narzędzi i danych.)
Jest jeszcze jedna rzecz do uwzględnienia: wiele firm w ogóle nie używa harnessów od dostawców. Budują własne. Bo właśnie harness wymusza polityki, ogranicza dostęp do narzędzi, daje programistom wielu dostawców i modeli oraz zapewnia spójne środowisko różnym zespołom.
Pliki pamięci: CLAUDE.md i AGENTS.md
Następny krok to pliki pamięci — u Claude plik CLAUDE.md, ogólnie AGENTS.md. Obowiązują między sesjami i można je ustawić globalnie albo na poziomie projektu. Globalnie: reguły z pliku dotyczą wszystkich twoich projektów. Projektowo: reguły z AGENTS.md dotyczą tylko tego jednego projektu. Przy każdym nowym uruchomieniu sesji zawartość pliku trafia do okna kontekstowego, zwykle tuż po prompcie systemowym.
Co do nich pisać? Przede wszystkim preferencje projektowe, wszelkie barierki — czyli listę „czyń i nie czyń” — standardy kodowania, systemy designu i wiele więcej. Te pliki są komponowalne: nie musisz upychać setek linii w jednym miejscu. Wystarczy w projekcie odwoływać się do innych plików przez symbol @. Ja trzymam małe pliki z regułami w folderze docs, a w głównym pliku pamięci wstawiam @-odwołania: potrzebujesz design systemu — sięgnij do tego pliku; standardy kodowania — do tamtego.
Przestroga: agenty nie zawsze trzymają się reguł co do joty, zwłaszcza gdy sesja zrobi się zbyt długa — spodziewaj się od czasu do czasu drobnego dryfu. Przykład reguły, którą lubię dodawać: precyzyjnie definiuję, kiedy praca jest uznana za skończoną. Domyślnie agent napisze kod i oznajmi: gotowe. Z inżynierskiej perspektywy to niedokładne. Moja reguła mówi: praca jest gotowa dopiero, gdy przejdzie zestaw testów, lint, typecheck i build. Zależnie od stacka wygląda to różnie, ale niemal każdy framework i język ma jakieś sprawdzanie typów, testy automatyczne czy kompilację. Dopiero po przejściu wszystkich bramek agent oddaje mi pracę.
Zamiast promptów: pętla issue → pull request
Ostatnio bardzo często pracuję inaczej — i jest ku temu dobry powód, zwłaszcza jeśli myślisz o skalowaniu do rojów agentów i fabryk oprogramowania. Zamiast promptować agenta wprost, twórz issues na GitHubie. Wdroż projekt na GitHuba i za każdym razem, gdy chcesz coś poprawić albo dodać, załóż issue. Tak od lat pracują zespoły programistyczne — a my w gruncie rzeczy traktujemy Claude jak kolejnego członka zespołu.
Chcesz nową funkcję, aktualizację dokumentacji albo łatkę na błąd? Załóż issue. W sesji Claude każ agentowi pobrać to issue i wprowadzić zmianę. Możesz mu zlecić dodawanie komentarzy w issue. A gdy zmiana jest gotowa — pamiętaj, co znaczy „gotowa”: testy, w tym jednostkowe i end-to-end, lint, typecheck i cała reszta — agent zakłada pull request. Pull request ma być uzupełniony o dowody z testów: zrzuty ekranu, raporty, cokolwiek. I taki PR trafia do ciebie.
Piękno tego rozwiązania: możesz przeglądać pull requesty w ruchu, choćby z telefonu — przejrzeć zmiany, zobaczyć, co się różni. A ponieważ agent dołączył dowody, masz znacznie większą pewność, że poprawka faktycznie działa.
Audyty bezpieczeństwa: skill „review-an-app” i OWASP Top 10
Pamiętasz, co mówiłem na początku? Jeśli aplikacja padnie albo zostanie zhakowana, odpowiadasz ty. Dlatego co jakiś czas zlecaj audyty bezpieczeństwa. Wystarczy otworzyć nową sesję w Claude Code i poprosić agenta o przeprowadzenie audytu. Przygotowałem do tego kolejny darmowy skill — review-an-app (linki w opisie filmu). Znów: rzeczy, których nauczyłem się przez lata, zamknięte w bardzo szczegółowym prompcie. Ten skill nie tylko robi audyt bezpieczeństwa; sprawdza też np. SEO i dryf — czyli czy nie odjeżdżamy od tego, czym aplikacja miała w ogóle być.
W promptach bezpieczeństwa odwołujemy się do OWASP Top 10, powszechnie stosowanej listy luk. Czy idealnej? Nie. Ale to branżowy standard kontroli aplikacji internetowych.
(Informacja dodatkowa: OWASP Top 10 to publikowana przez organizację Open Worldwide Application Security Project lista dziesięciu najpowszechniejszych kategorii luk bezpieczeństwa aplikacji webowych.)
Poproś agenta, żeby użył skilla do przeglądu aplikacji pod kątem luk, a każdą znalezioną słabość zgłosił jako issue na GitHubie — z raportem z audytu i propozycją poprawek. I cykl rusza od nowa: inna sesja Claude pobiera issue, wprowadza poprawkę, zakłada pull request z dowodami, a ty akceptujesz i scalasz. Ta pętla działa znakomicie zwłaszcza przy skalowaniu do fabryk oprogramowania i rojów agentów — tam kilka agentów czeka na gotowości, żeby zbierać issues i tworzyć PR-y. Warto wbudować sobie ten nawycz. Nie musi to przy tym być GitHub: wiele organizacji używa innych repozytoriów, ale schemat zadziała wszędzie tak samo.
Dla sceptyków: barierki zamiast unikania
Wiem, że wśród was jest wielu niedowiarków. Pracowałem z genialnymi programistami, którzy wciąż nie potrafią przejść na pracę z agentami. Nie ufają rezultatom i wolą pisać wszystko sami. Jeśli to ty — albo znasz kogoś takiego — moja rada brzmi: zamiast unikać, stawiaj barierki. Agenty to przyszłość, a ręczne pisanie kodu po prostu się nie obroni — jest zbyt wolne. Dziś obowiązuje oczekiwanie, że kod jest w zasadzie tani: agent wyprodukuje go błyskawicznie i za grosze. Do tego można użyć wielu worktree, czyli równoległych kopii roboczych repozytorium, żeby tworzyć warianty rozwiązania jednocześnie — czego ludzki programista w tym samym czasie po prostu nie zdąży.
Za to z twoim doświadczeniem możesz zrobić coś innego: ustawić reguły i harness z barierkami, które chronią agenta i prowadzą go właściwą ścieżką. Doświadczenie to twoja przewaga. Agenty piszą naprawdę dobry kod, ale są słabe w projektowaniu porządnej architektury, w guście i w przewidywaniu, co wywali się na produkcji. Więc wchodź w to stopniowo. Zacznij od zadań niskiego ryzyka, najlepiej takich, których i tak nie lubisz: aktualizacja testów jednostkowych, dokumentacji, ogarnianie ticketów w Jirze, refaktoryzacja, triage błędów.
Wszystkie wspomniane skille znajdziecie w opisie filmu. Jeśli ten materiał was porwał i chcecie więcej poradników o kodowaniu z agentami — polubcie film i zasubskrybujcie kanał. Do zobaczenia w następnym.