O czym jest ten film
- Agent kodujący to nie sam model — to model plus harness, czyli środowisko, które narzuca reguły, przydziela narzędzia, wymusza kontrole, udostępnia pamięć i izoluje agenta od reszty systemu.
- Autor wyróżnia trzy poziomy inżynierii harnessów: konfigurację gotowych narzędzi, budowę własnych środowisk i orkiestrację wielu harnessów naraz.
- Pierwszy poziom opiera się na pliku AGENTS.md — otwartym standardzie, który respektuje każdy porządny harness. Praktyczna zasada: każde niechciane zachowanie agenta zamieniamy w nową regułę.
- Reguły warto dzielić na mniejsze pliki w katalogu docs, a przy pełnym oknie kontekstu sięgać po dokumenty przekazania (handoff), by nowa sesja przejęła bieżącą pracę.
- Zachowania krytyczne dla procesu — aktualizacja dziennika zmian, pull requesty, testy — można egzekwować hookami (np. hookiem zatrzymania), zamiast liczyć na pamięć agenta.
- Drugi poziom to budowa własnych harnessów: umiejętność bardzo poszukiwana, bo organizacje potrzebują polityk, kontroli narzędzi i spójnego doświadczenia zespołów.
- Eksperymenty pokazują, że ten sam model w lepszym harnessie daje skokowo lepsze wyniki: LangChain poprawiło wynik GPT-5.2 z 53 do ok. 66 proc., a Can Bölük — Grok Code Fast 1 z 6,7 do niemal 70 proc.
- Autor prezentuje SMOL coder — harness dla modeli lokalnych, w którym cała otoczka (prompt systemowy, definicje narzędzi) zajmuje 1400 tokenów zamiast ponad 30 tysięcy w Claude Code.
- Własny harness daje firmom niezależność od chmur i dostawców: można podmieniać modele i providerów, nie zmieniając sposobu pracy deweloperów.
- Trzeci poziom to orkiestracja: długotrwałe pule zadań (AutoForge), fabryki oprogramowania z rojem agentów oraz autorski rój 3D z tablicą Kanban podpiętą pod GitHuba.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Agent to model plus harness — i to rozróżnienie jest fundamentem
Na czym polega: Agent kodujący składa się z dwóch części: modelu językowego („mózgu” operacji) i harnessu — środowiska, które dostarcza instrukcji, narzędzi, kontroli jakości i pamięci. Wynik pracy agenta zależy od obu elementów.
Jak stosować: Gdy agent działa słabo, zanim zmienisz model na droższy, przejrzyj reguły, narzędzia i limity narzucone przez środowisko. Często wąskim gardłem jest otoczka, nie model.
Na co uważać: Porównując modele testowane w różnych harnessach, możesz przypisać przewagę modelowi, choć naprawdę dała ją infrastruktura. Testuj warunki jak najbardziej zbliżone.
2.AGENTS.md: każde niechciane zachowanie zamieniaj w regułę
Na czym polega: AGENTS.md to otwarty standard pliku pamięci — reguły zapisane w nim obowiązują agenta w każdej nowej sesji, niezależnie od narzędzia (Claude Code, Codex, OpenCode).
Jak stosować: Prowadź plik na bieżąco jak dziennik lekcji: agent zrobił coś niepożądanego — dopisujesz regułę zakazu albo opis właściwego zachowania. Przy następnym uruchomieniu sesji reguła już działa.
Na co uważać: Reguły muszą być jednoznaczne i wzajemnie niesprzeczne. Plik rosnący latami bez porządku przestaje być pomocą, a zaczyna szumieć w kontekście.
3.Reguły buduj z klocków, nie w jednym gigancie
Na czym polega: Plik AGENTS.md jest komponowalny: zamiast jednego wielkiego markdowna tworzysz katalog docs z małymi plikami, a w pliku głównym zostawiasz indeks z linkami.
Jak stosować: Jeden mały plik na jeden obszar aplikacji lub aspekt pracy (testy, styl kodu, workflow). Dzięki temu reguły da się utrzymywać i aktualizować niezależnie.
Na co uważać: Przy dużej liczbie plików łatwo o dublowanie się instrukcji — warto co jakiś czas robić przegląd całości.
4.Przy pełnym oknie kontekstu sięgaj po dokument przekazania
Na czym polega: Gdy sesja robi się zbyt długa i zbliża się do limitu okna kontekstu, można poprosić agenta o zapisanie postępu i listy zadań do osobnego pliku, a następnie przekazać go nowej sesji.
Jak stosować: Przed zamknięciem sesji każ agentowi przygotować dokument: co zostało zrobione, co pozostało, jak kontynuować. Nowy agent z takim dokumentem od razu wie, na czym stoi projekt.
Na co uważać: Dokument musi być na tyle szczegółowy, by zastąpić żywą historię rozmowy — po zamknięciu sesji ten kontekst przepada bezpowrotnie.
5.Krytyczne zachowania egzekwuj hookami, nie pamięcią agenta
Na czym polega: Hooki pozwalają zaczepić własny skrypt o zdarzenia w cyklu życia agenta. Na przykład hook zatrzymania po zakończeniu pracy sprawdza, czy agent zaktualizował changelog — a jeśli nie, odsyła go do poprawki.
Jak stosować: Wszystko, co w twoim procesie jest obowiązkowe (dziennik zmian, uruchomienie testów, utworzenie pull requesta), wyegzekwuj skryptem w hooku. Możesz też przechwytywać wychodzące prompty i maskować dane wrażliwe.
Na co uważać: Kontrola uruchamiana po fakcie wydłuża każdą iterację — stosuj ją tam, gdzie pominięcie kroku naprawdę boli. Hooki nie zastąpią też dobrze napisanych reguł, raczej je zabezpieczają.
6.Ten sam model w innym harnessie potrafi dać skokowo lepsze wyniki
Na czym polega: LangChain przeprowadziło eksperyment: dokładnie ten sam model (GPT-5.2) i ten sam prompt, ale własne środowisko Deep Agents CLI — wynik wzrósł z 53 do około 66 procent. Can Bölük na X doszedł z 6,7 do niemal 70 procent na Grok Code Fast 1, zmieniając wyłącznie działanie narzędzi. W obu przypadkach wąskim gardłem był harness.
Jak stosować: Zanim wydasz pieniądze na mocniejszy model, audytuj otoczkę: definicje narzędzi, prompt systemowy, ilość wstrzykiwanego kontekstu. To często tańszy i większy zysk.
Na co uważać: Cudze wyniki pochodzą z konkretnych zadań i benchmarków — u siebie zweryfikuj na własnym zestawie zadań, bo różnice w charakterze projektu mogą odwrócić wnioski.
7.Modele lokalne wymagają środowiska szytego na miarę
Na czym polega: Gotowe harnessy wstrzykują ogromny kontekst — Claude Code zajmuje ponad 30 tysięcy tokenów, zanim wyślesz pierwszą wiadomość. Modele uruchamiane lokalnie mają często okna rzędu 32–64 tysięcy tokenów, więc taka otoczka zjada im pół budżetu. Autorski SMOL coder upakował całość (prompt systemowy, narzędzia) w 1400 tokenów.
Jak stosować: Przy pracy na własnym sprzęcie licz budżet kontekstu od góry i tnij bezlitośnie: prompt systemowy, liczbę narzędzi, zbędne mechanizmy typu MCP czy podagenty.
Na co uważać: Okrojony harness to okrojone możliwości — każde ucięcie musi być świadomą decyzją, że dana funkcja naprawdę nie jest ci potrzebna w tym zastosowaniu.
8.Własny harness daje organizacji kontrolę i niezależność
Na czym polega: Firmy potrzebują spójnego doświadczenia deweloperów przy wielu dostawcach modeli, egzekwowania polityk, ograniczania narzędzi i praw administracyjnych. Własne środowisko spełnia te potrzeby, gotowe — zazwyczaj nie.
Jak stosować: Zbuduj harness jako warstwę pośrednią między zespołem a dostawcami: podmieniasz providera czy model, a sposób pracy zespołu pozostaje bez zmian. Polityki bezpieczeństwa wdrażasz w jednym miejscu.
Na co uważać: Własna otoczka to również własny kod do utrzymania i odpowiedzialność za błędy. Opłaca się wtedy, gdy wymagania faktycznie wykraczają poza to, co dają gotowe narzędzia.
9.Trzeci poziom to orkiestracja: fabryki agentów i długotrwałe zadania
Na czym polega: Harness orkiestracyjny zarządza wieloma harnessami kodującymi. AutoForge prowadzi długotrwałe pule zadań z tablicy, a fabryka oprogramowania trzyma rój kilkunastu agentów (Codex, Claude Code, własne środowiska) i przydziela każde zadanie pierwszemu wolnemu.
Jak stosować: Zaplanuj zadania, wrzuć je na tablicę powiązaną z GitHubem i pozwól agentom pracować w tle — scalanie, testy i weryfikacja biegną bez twojego udziału. Dla setek zadań to jedyna sensowna skala.
Na co uważać: Autonomiczne roje generują dużo pull requestów i kosztów tokenów — bez mechanismów weryfikacji i limitów jakość szybko się rozjedzie.
10.Podejście do inżynierii harnessów jest niższe, niż się wydaje
Na czym polega: Według autora każdy — także bez głębokiego doświadczenia technicznego — jest w stanie zbudować własny harness, a umiejętność ta jest obecnie bardzo poszukiwana. Ścieżka jest trójstopniowa: konfiguracja, własne środowiska, orkiestracja.
Jak stosować: Najpierw opanuj poziom pierwszy: porządny AGENTS.md, hooki, dokumenty przekazania. Potem zbuduj minimalny własny harness pod jeden konkretny przypadek — na przykład pod modele lokalne.
Na co uważać: Nie przeskakuj poziomów. Bez opanowanej konfiguracji łatwo odtworzyć w własnym środowisku te same problemy, od których chciało się uciec.
Redakcyjne tłumaczenie
Wszystko, co instalujesz, to dopiero pierwszy poziom
Większość ludzi i firm sądzi, że harness kodujący, który instalują, to jedyne, co dostają. Instalujesz Claude Code, Codex albo OpenCode, konfigurujesz model, dodajesz kilka plików pamięci, może parę hooków, parę narzędzi — i uznajesz, że to koniec. Tymczasem to dopiero pierwszy poziom inżynierii harnessów. I większość osób budujących z AI nigdy go nie przekracza.
Inżynieria harnessów to temat, który mnie naprawdę pociąga. Pracowałem z wieloma ludźmi i zespołami, pokazując im, jak skutecznie korzystać z harnessów kodujących, a nawet budować własne. Jeśli chcesz robić karierę jako inżynier AI albo pracować z prawdziwymi klientami, musisz rozumieć trzy poziomy inżynierii harnessów — i o nich będzie ten materiał. Będzie naprawdę fajnie, więc nie przedłużajmy.
A jeśli te tematy są Ci bliskie, rozważ dołączenie do mojej społeczności Agentic Labs. Mamy kilka klas poświęconych budowaniu ciekawych rzeczy z agentami kodującymi, a w każdy czwartek odbywają się pogłębione sesje — ostatnio półtorej godziny rozmawialiśmy właśnie o inżynierii harnessów; całe nagranie znajdziesz w klasie. W czwartek startuje też zupełnie nowa seria, w której uczę pracy z agentami kodującymi od podstaw. Obecnie trwa promocja: 100 dolarów zniżki na plan roczny. Chętnie Cię tam zobaczę.
Czym jest agent, a czym harness
Jeśli używasz AI od dłuższego czasu, słowo „agent” słyszałeś pewnie bez liku. Ale co to właściwie jest agent? Agent to po prostu model — duży model językowy — plus harness. Modelem jest na przykład Opus, Fable czy GPT-6: to one stanowią mózg całej operacji. Harness natomiast to środowisko, w którym model działa.
To właśnie harness ustala reguły, których agent musi przestrzegać. Przydziela narzędzia, do których agent ma dostęp: zapisywanie plików, przeszukiwanie ich, przeglądanie internetu, otwieranie przeglądarki i tak dalej. Harness wymusza również kontrole, które muszą zostać wykonane — suite’y testowe, linter, sprawdzanie typów; pewnie dobrze to znasz. Może też udostępniać hooki, czyli punkty zaczepienia na zdarzenia zachodzące w cyklu życia agenta. Na przykład w chwili, gdy wysyłasz prompt, można najpierw uruchomić własny skrypt, który sprawdzi, czy prompt nie zawiera danych wrażliwych, i zamaskuje je, zanim dotrą do agenta. Hooki mają mnóstwo zastosowań. Niedawno premierę miały Claude Mods — mechanizm pozwalający dopasować Claude Code do własnych potrzeb — a pod spodem to w gruncie rzeczy właśnie hooki.
(Informacja dodatkowa: hooki to skrypty uruchamiane automatycznie przy określonych zdarzeniach — np. przed wysłaniem promptu albo po zakończeniu pracy agenta.)
Harness daje agentowi dostęp do plików pamięci: AGENTS.md, design.md, SOUL.md, a także plików w katalogu docs. Kontroluje ponadto izolację agenta od reszty systemu — na przykład agent ma pracować w ściśle określonym katalogu roboczym albo wolno mu tworzyć wyłącznie nowe drzewa robocze (worktree) i gałęzie feature, natomiast gałąź main zawsze pozostaje poza jego zasięgiem.
Mam nadzieję, że już to widzisz: harness to element, który nadaje agentowi możliwości i wyznacza środowisko oraz zasady gry. Najkrócej mówiąc: agent to model plus harness. Harness udostępnia instrukcje, narzędzia, kontrole i pamięć, z których agent korzysta. Można to rozbudowywać o kolejne zdolności — podagenty, workflow — ale wszystko to i tak przychodzi z harnessu.
Poziom pierwszy: konfiguracja gotowego środowiska
Skoro wiemy już, czym jest harness, a czym agent, czas na sedno: trzy poziomy inżynierii harnessów. Pierwszy z nich to konfiguracja — i tu właśnie znajduje się zdecydowana większość z was. Korzystasz ze środowiska zbudowanego przez dostawcę lub kogoś trzeciego; jeśli używasz Claude Code, jesteś na tym poziomie. Twoje zadanie polega na skonfigurowaniu go tak, by działał po Twojemu. Chcesz, żeby agent trzymał się konkretnych reguł? Wpisujesz je do AGENTS.md.
Reguły w AGENTS.md — pliku pamięci każdego projektu
W większości projektów reguły ustawia się właśnie w AGENTS.md. To tak zwany plik pamięci: wszystkie zasady, których agent ma przestrzegać w każdej nowej sesji, wrzucasz do tego jednego pliku — a gdy następnym razem uruchomisz sesję Claude, będzie się ich trzymał. I wcale nie dotyczy to wyłącznie Claude: AGENTS.md to otwarty standard i każdy harness, który ma się na coś przydać, będzie go respektował.
Praktyczna zasada jest prosta: jeżeli agent zrobi w rozmowie coś, co bardzo Ci się nie podoba, dopisz do tego pliku regułę zakazującą takiego zachowania albo opisz, jak ma się zachowywać w przyszłości.
Plik jest przy tym komponowalny — nie musisz wrzucać wszystkiego do jednego markdowna, bo szybko urośnie do nieprzyzwoitych rozmiarów. Zamiast tego podziel reguły na osobne pliki. Popularna konwencja: tworzysz katalog docs, rozbijasz markdowny na mniejsze i układasz je tam w uporządkowany sposób, a w głównym AGENTS.md zostawiasz indeks z linkami do tych pojedynczych plików. Każdy z nich to nic innego jak krótki dokument z bardzo konkretnymi instrukcjami dla konkretnej części aplikacji.
Dokument przekazania zamiast przepełnionego okna kontekstu
Jeszcze jedna rada dotycząca plików pamięci. Gdy sesje robią się zbyt długie i zbliżasz się do limitu okna kontekstu, po prostu poproś agenta, żeby zapisał postęp oraz listę tego, co zostało do zrobienia, do osobnych plików. Sam musiałem niedawno kazać agentowi przygotować taki dokument przekazania: uruchomiłem nową sesję i wręczyłem nowemu agentowi ów dokument. Dzięki kontekstowi w nim zapisanemu agent dokładnie wiedział, co się dotąd wydarzyło, na czym polega projekt i jak kontynuować pracę.
Hooki: egzekwowanie zamiast przypominania
Harness można konfigurować na wiele innych sposobów — na przykład dodając hooki. Przełączę się na chwilę do VS Code, mam tam bardzo prosty przykład. W tej aplikacji za każdym razem, gdy wprowadzamy zmianę, agent powinien dopisać wpis do dziennika zmian. Nie mam tu żadnego AGENTS.md — idealnie byłoby mieć plik z instrukcją aktualizowania changeloga, ale to zachowanie da się również wymusić hookami.
Większość harnessów pozwala zaczepić się o różne zdarzenia. Gdy wysyłamy prompt, możemy się wtrącić, przechwycić go, coś z nim zrobić i dopiero wtedy przekazać agentowi. Dostępnych hooków jest mnóstwo, a jednym z najcenniejszych jest hook zatrzymania: gdy agent kończy pracę, odpalamy skrypt, który robi coś z rozmową. W moim przykładzie sprawdza on, czy changelog został zaktualizowany — a jeśli nie, zwraca się do agenta: „wróć i dopisz wpis do dziennika zmian”, wymuszając pożądane zachowanie. Dokładnie tak samo można sprawdzać, czy powstał pull request albo czy odpalony został suite testów. Rzeczy do wyegzekwowania w ramach harnessu jest naprawdę dużo. Dzięki temu nie liczysz na to, że agent sam sobie przypomni o czymś ważnym.
Poziom drugi: budowa własnego harnessu
Konfiguracja to jednak dopiero poziom pierwszy. Poziom drugi to budowa własnych środowisk — i uwierz mi, ta umiejętność jest teraz bardzo poszukiwana. Niektóre organizacje potrzebują kontroli nad tym, co wolno deweloperom: wymuszania polityk, dawania agentom dostępu wyłącznie do konkretnych narzędzi albo wręcz ograniczania niektórych możliwości. Pracowałem z wieloma markami i widziałem mnóstwo customowych harnessów.
Po co w ogóle budować własny, zamiast skorzystać z gotowych? Czy to trudne? Czy da radę ktoś bez doświadczenia technicznego? Od razu uspokajam: każdy może zbudować harness. W mojej darmowej społeczności jest bezpłatny kurs uczący, jak stworzyć własne środowisko kodujące, a efekty, które przysyłają uczestnicy, robią wrażenie. Widziałem kilka znakomitych przykładów, gdzie sama zmiana harnessu — przy tym samym modelu — istotnie poprawiała wyniki.
Ten sam model, skokowo lepszy wynik
LangChain zrobił kiedyś taki eksperyment: wzięli GPT-5.2, dokładnie ten sam model i ten sam prompt, i wyłącznie dzięki własnemu narzędziu Deep Agents CLI — czyli własnemu harnessowi — wycisnęli z modelu lepsze rezultaty: z 53 do około 66 procent.
A to bardzo popularny post na X od Cana Bölüka — przepraszam, jeśli kaleczę nazwisko — który również osiągnął świetne wyniki, zmieniając wyłącznie otoczkę. Jak sam pisze, to harness był wąskim gardłem. Udało mu się podnieść wynik Grok Code Fast 1 z zaledwie 6,7 procent do niemal 70 — tylko przez zmianę działania narzędzi, na których model polega.
SMOL coder, czyli harness szyty na miarę modeli lokalnych
Mam w tym spore doświadczenie. Jeśli obserwujesz mój kanał dłużej, wiesz, że chętnie pokazuję modele o otwartych wagach — takie, które uruchamiasz na własnym sprzęcie. Wprawiałem je w OpenCode, w Claude Code, w harnessie DeepSeek — wymieniasz, jest. Omawiałem też Pi agent SDK. Żadne z tych środowisk nie było jednak zoptymalizowane pod modele lokalne. Szanując Twój czas, nie będę teraz rozdrabniał się na szczegóły — znajdziesz je w moim filmie o SMOL coder — ale sedno jest takie: te harnessy, czyli elementy wstrzykujące prompt systemowy, pliki pamięci i udostępniające narzędzia, pompują do kontekstu zdecydowanie za dużo, zwłaszcza dla małych modeli. Modele lokalne mają zwykle bardzo wąskie okno kontekstu, szczególnie na sprzęcie konsumenckim. Jeśli całe okno to 32 albo 64 tysiące tokenów, nie możesz pozwolić sobie na wtłoczenie do niego 30 tysięcy tokenów samej otoczki Claude Code — rzeczy czysto harnessowych.
Dlatego stworzyłem SMOL coder: harness, który obcina wszystko, czego model o otwartych wagach nigdy nie będzie potrzebował. Takie modele nie skorzystają z narzędzi MCP ani podagentów, powinny mieć ograniczony zestaw narzędzi, a cały system powinien być maleńki i dopasowany do jednej konkretnej funkcji. (Informacja dodatkowa: MCP to otwarty protokół podłączania zewnętrznych narzędzi do modeli językowych.)
Szybki pokaz: to zwykłe narzędzie w terminalu, jest oczywiście wersja webowa. Wciągnięcie dowolnego modelu jest banalnie proste — środowisko automatycznie wykrywa modele z LM Studio i Ollama. (Informacja dodatkowa: LM Studio i Ollama to popularne programy do uruchamiania modeli językowych lokalnie, na własnym komputerze.) Jeśli próbowałeś kiedyś używać modeli otwartowagowych z Pi agent SDK, OpenCode czy Claude Code, wiesz, ile konfiguracji trzeba zrobić na starcie. Tu, bo harness jest mój i mogę zrobić, co chcę, wykrywanie modeli na własnym sprzęcie jest głupio proste, a całość jest pod nie zoptymalizowana. Definicje narzędzi, prompt systemowy — wszystko, czego model potrzebuje — zajmuje 1400 tokenów. Gdy zaś uruchomię teraz Claude Code i zajrzę do podsumowania kontekstu: zanim wyślę choć jedną wiadomość, harness zajmuje już ponad 30 tysięcy tokenów mojego okna. Praca modelu otwartowagowego w takim środowisku po prostu nie miałaby sensu.
Własne środowisko jako odpowiedź na potrzeby organizacji
Widziałem też sporo przypadków, gdy firmie potrzebny jest własny harness, żeby ukształtować doświadczenie deweloperów. Na przykład organizacja nie chce wiązać się z żadną chmurą i zamierza dawać zespołom dostęp do różnych dostawców, także OpenAI — a przy tym narzędzia i samo doświadczenie mają być spójne. Z własnym harnessem to proste: zmieniasz dostawców, zmieniasz modele, a wszystko to kontrolujesz w obrębie jednego środowiska. Możesz wdrożyć polityki firmowe, decydować, jakie narzędzia wolno przypisywać, jakie prawa administracyjne obowiązują. Z customowymi harnessami da się robić naprawdę fajne rzeczy.
Poziom trzeci: orkiestracja wielu harnessów
Gdy nauczysz się budować własne środowisko, warto wejść poziom wyżej: harnessy orkiestracyjne. W takim harnessie zarządzasz wieloma harnessami kodującymi. Możesz mieć na przykład otoczkę prowadzącą długotrwałe zadania, gdzie każde z nich wykonuje konkretny agent lub środowisko.
Długotrwałe zadania: AutoForge
AutoForge to przykład harnessu długotrwałego. Planujesz wszystkie funkcje, trafiają one na swego rodzaju tablicę zadań, a agent realizuje zmiany jedną po drugiej. Funkji mogą być setki, i przejście przez całość może zająć agentowi nie godziny, nie dni, lecz tygodnie. Ale najważniejsze: nie musisz przy tym siedzieć i doglądać go przy pracy — wszystko wykonuje i testuje na autopilocie.
Fabryka oprogramowania: rój agentów czekających na zlecenie
Innym przykładem harnessu orkiestracyjnego jest fabryka oprogramowania. Nie wygląda to może okazale — zaraz pokażę zabawniejszy wariant — ale mechanizm jest taki: masz rój agentów, powiedzmy dziesięciu albo dwudziestu agentów kodujących czekających w tle. Mogą być różnorodni: agenty Codex, agenty Claude Code, może nawet twój własny harness. Po prostu czekają na pracę. Gdy pojawia się projekt, fabryka przydziela zadanie jednemu z dostępnych agentów. A jeśli wszyscy w roju są zajęci, fabryka radzi sobie i z tym: czeka, aż któryś się zwolni, i dopiero wtedy przydziela kolejne zadanie. Mam osobny film o budowaniu fabryk oprogrammowania — link znajdziesz w opisie.
Rój w 3D: harness nie musi być nudny
Na koniec — nikt nie powiedział, że harness agenta ma być nudny. To mój rój kodujący odwzorowany w przestrzeni 3D i ci agenci naprawdę pracują nad projektem. Każdy z nich uruchamia jakiś harness kodujący: Claude Code, Codex. Gdy podchodzę do dowolnego monitora, widzę na przykład, że ten tutaj pracuje na Claude Opus, czyli w Claude Code; niektórzy używają innych środowisk — wszystko rozstawione w przestrzeni trójwymiarowej. Dochodzi do tego tablica Kanban podpięta pod prawdziwe zgłoszenia na GitHubie: klikam w zadanie i przeskakuję do faktycznego pull requesta. I podobnie jak w harnessie długotrwałym, mogę przypisać tyle zadań, ile zechcę — nawet setki — a agenci będą pracować dalej w tle, dopóki całość nie zostanie scalona, przetestowana i zweryfikowana. A przy okazji: ten projekt, jak wszystkie moje projekty, jest open source — możesz z niego korzystać już dziś.
Zakończenie
Jeśli ten materiał był dla Ciebie choć trochę pomocny, zostaw łapkę w górę i zasubskrybuj kanał, jeśli chcesz więcej o kodowaniu agentowym. Mam też nadzieję, że dołączysz do Agentic Labs — do zobaczenia na żywo. Dziękuję za oglądanie i do następnego!