O czym jest ten film
- Kolejnym dużym kierunkiem w programowaniu agentowym są dobre środowiska weryfikacji end-to-end, a nie samo generowanie kodu.
- Obniżka ceny GPT-5.6 Luna o 80% sprawia, że weryfikacja przeglądarkowa staje się ekonomicznie opłacalna na dużą skalę.
- W benchmarku 106 zadań przeglądarkowych Luna na ustawieniu extra high uzyskała 78% przy koszcie ok. 14 centów za zadanie — tylko 2 punkty mniej niż Opus 5, przy koszcie 17 razy niższym.
- Cytowana teza inżyniera z Rampa: potrzebna jest pętla, która sama się waliduje, i środowiska testowe, które agenci mogą sobie sami postawić.
- Uncle Bob Martin nie czyta już kodu pisanego przez swoje agenty — zamiast tego otacza je bardzo ostrymi ograniczeniami.
- Praca zespołu Qwen (Alibaba) o „horyzoncie weryfikacji”: generowanie złożonych rozwiązań przestało być trudne, trudna stała się ich wiarygodna weryfikacja.
- Autor opisuje własny system: każdy PR uruchamia agenty w chmurze, które klikają po aplikacji jak użytkownik i automatycznie zakładają issue na GitHubie.
- Architektura pojedynczej ścieżki: osobny sandbox z własnym Postgresem i Redisem, agent zasiewający bazę, agent sterujący Playwrightem, agent-sędzia oceniający nagranie.
- Weryfikacja działa na sandboxach chmurowych (E2B) z dwóch powodów: równoległość z izolowanymi bazami oraz bezpieczeństwo — lokalne agenty potrafiły grzebać po dysku w poszukiwaniu kluczy API.
- Główne ograniczenie: agent zweryfikuje tylko to, do czego ma dostęp — kanały typu Slack, WhatsApp czy Instagram wymagają osobno przygotowanych uprawnień i kont.
Redakcyjne tłumaczenie
Dokąd zmierza programowanie z agentami
Ostatnio dużo myślę o tym, co dalej z programowaniem agentowym i inżynierią agentową — na czym powinniśmy skupić wysiłki przez resztę roku. Uważam, że jedną z największych rzeczy, które nas czekają, jest budowanie dobrych środowisk weryfikacji end-to-end. W tym materiale chcę połączyć kilka trendów krążących po Twitterze w jeden większy obraz i pokazać go na konkretnych przykładach.
Jedna z ważnych zmian ostatniego tygodnia: OpenAI obniżyło cenę GPT-5.6 Luna o 80%. Pewnie myślicie: „no dobrze, ale co mi do tego, nie używam Luny, do czego to w ogóle służy?”. Otóż jednym z naprawdę dobrych zastosowań Luny jest praca w przeglądarce.
GPT-5.6 Luna na ustawieniu extra high zbliża się wynikami do Opusa 5, będąc przy tym siedemnastokrotnie tańszym w zadaniach przeglądarkowych. Widać to tutaj: benchmark obejmował 106 zadań, Luna Extra High uzyskała 78% i kosztowała łącznie około 14 dolarów za te 106 zadań, czyli mniej więcej 14 centów za zadanie. Opus 5 był lepszy tylko o 2 punkty procentowe, a kosztował siedemnaście razy więcej.
(Informacja dodatkowa: „extra high” to ustawienie poziomu rozumowania modelu — im wyższe, tym więcej wewnętrznych kroków wnioskowania i tym wyższy koszt oraz jakość odpowiedzi.)
Odblokowuje to nową możliwość: za mniej więcej 14 centów w cenniku API można uruchomić pełną weryfikację end-to-end jednej ścieżki użytkownika we własnej aplikacji.
Pętla, która sama się waliduje
Ma to znaczenie z powodu takiego oto wpisu. Przy okazji — obserwujcie mnie na Twitterze, będę tam publikował więcej, link znajdziecie poniżej. Inżynier z Rampa (Informacja dodatkowa: Ramp to amerykańska firma oferująca karty firmowe i oprogramowanie do zarządzania wydatkami) pisze, że jeśli chcesz dziesięciokrotnie lepszych efektów, potrzebujesz pętli, która sama siebie waliduje, oraz środowisk testowych end-to-end, które agenci mogą sami postawić, żeby sprawdzić własną pracę.
W praktyce oznacza to, że jeśli dodałeś do aplikacji nową funkcję i wprowadziłeś przy okazji szereg nowych ścieżek użytkownika, możesz zlecić Lunie na extra high weryfikację każdej z nich za około 14 centów za ścieżkę. Właśnie to robię od kilku dni: uruchamiam setki podagentów opartych na Lunie extra high, żeby zweryfikowały niemal każdą ścieżkę użytkownika w moich aplikacjach i wyłapały błędy oraz usterki. Pokażę to dokładniej za chwilę.
Nie czytać kodu, tylko ograniczać agenta
Warto mieć na uwadze to, co napisał Uncle Bob Martin, autor wielu książek o architekturze i inżynierii oprogramowania: nie czyta już żadnego kodu napisanego przez swoje agenty. Zamiast tego stara się otoczyć je bardzo ostrymi ograniczeniami.
(Informacja dodatkowa: Robert C. Martin, znany jako „Uncle Bob”, to autor m.in. „Czystego kodu” i jedna z najbardziej rozpoznawalnych postaci w środowisku inżynierii oprogramowania.)
Zespół Qwen z Alibaby opisał to w pracy zatytułowanej The Verification Horizon, która ukazała się w zeszłym miesiącu: generowanie złożonych rozwiązań przestało być trudne — dużo trudniejszym problemem stała się ich wiarygodna weryfikacja. To bardzo ciekawa publikacja, poświęcę jej osobny materiał, więc warto zasubskrybować kanał.
To wszystko skłoniło mnie do pytania o mój własny stos w Agent Stack: dlaczego nie mam mnóstwa weryfikacji działającej non stop, żeby wyłapywać jak najwięcej regresji i problemów?
Jak to działa u mnie
System, który zbudowałem w Agent Stack, działa tak: za każdym razem, gdy dodaję nową funkcję w PR-ze, uruchamiane są agenty w chmurze oparte na Lunie Extra High, które pracują w przeglądarce — klikają i wchodzą w interakcje z aplikacją dokładnie tak, jak robiłby to użytkownik. Widzicie tutaj różne rzeczy, które robiły, żeby upewnić się, że wszystko działa zgodnie z zamierzeniem.
Z czasem uzbierał mi się z tego cały katalog. W tej chwili dla samej strony ustawień jest tego około 46 pozycji. Mogę kliknąć w dowolną z nich i zobaczyć weryfikację przeglądarkową w akcji: Luna extra high działająca w chmurze korzysta z tej testowej organizacji i sprawdza, czy dana funkcja działa jak należy. Na dole widać szczegóły weryfikacji.
Za każdym razem, gdy agent znajdzie jakiś problem, automatycznie zakłada issue na GitHubie. Widzę tutaj informację, że dana ścieżka z jakiegoś powodu nie działa. Przechodzę do kanału 52, czyli tej właśnie ścieżki — i rzeczywiście, nie działa tak, jak powinna. Widać wyraźnie, że jest zepsuta.
Aktualnie na lokalnym Codeksie mam uruchomioną weryfikację 500 najważniejszych ścieżek użytkownika w aplikacji — chodzi o przejście przez cały backlog tego, w jaki sposób użytkownik faktycznie korzysta z Agent Stack.
Dlaczego sandboxy w chmurze
Większość swoich środowisk weryfikacji end-to-end uruchamiam na sandboxach chmurowych, takich jak E2B, z dwóch powodów.
Po pierwsze, mogę weryfikować dużo więcej ścieżek równolegle, każdą z osobną bazą danych, więc nie wchodzą sobie w drogę.
Po drugie, trochę obawiam się uruchamiania takich agentów lokalnie na własnym komputerze przy długich zadaniach end-to-end. Zauważyłem, że w miarę jak modele stają się mądrzejsze, agenty robią coraz dziwniejsze rzeczy — na przykład grzebią po moim komputerze w poszukiwaniu kluczy API, które pomogłyby im ukończyć zadanie. Przeniesienie wielu równoległych agentów do sandboxa w chmurze daje mi więcej spokoju.
Na dashboardzie widzę, że w tej chwili weryfikowane są dwie ścieżki użytkownika. Jeśli spojrzę na ostatnie 24 godziny, widać rytm pracy: weryfikacja dziesięciu naraz, potem przerwa, potem kolejnych dziesięć i tak dalej. Tak właśnie Codex sprawdza teraz 500 najważniejszych ścieżek — uruchamiając po jednym kontenerze na ścieżkę, każdy z własną bazą danych. Dzięki temu może doprowadzić bazę do określonego stanu, zweryfikować zmianę end-to-end, upewnić się, że działa, a potem zniszczyć sandbox.
Jednym z większych problemów z E2B jest to, że gdy masz kilkadziesiąt agentów pracujących non stop, robi się to naprawdę drogie. Dlatego pracuję nad własnym rozwiązaniem do sandboxowania agentów. Jeśli wydajecie ponad kilkaset dolarów miesięcznie na sandboxy dla agentów, możecie poprosić o wcześniejszy dostęp przez formularz na stronie, link poniżej. U mnie sandboxy do uruchamiania Claude Code i Slacka działają automatycznie na moim własnym systemie.
Tak czy inaczej, widzę tu, że Luna Extra High działała na sandboxach chmurowych automatycznie dziesiątki, a nawet setki razy, weryfikując wszystkie różne ścieżki użytkownika w aplikacji. Za każdym razem, gdy dodaję nową funkcję, system sam rozpoznaje, jakie nowe ścieżki się pojawiły, i również je weryfikuje.
Architektura potoku weryfikacji
Rozrysujmy to szybko. Zaczynamy od PR-a z nową funkcją. Następnie mam agenta — to może być Claude albo Codex — który identyfikuje wszystkie nowe ścieżki użytkownika wprowadzone do aplikacji, czyli wszystkie sposoby, na jakie użytkownik mógłby korzystać z nowej funkcji, oraz to, jak zmieniają się interakcje z funkcjami już istniejącymi.
Załóżmy, że zidentyfikował dziesięć ścieżek. Każda z nich działa we własnym sandboxie z własną instancją Postgresa i własną instancją Redisa.
Dalej wchodzi pierwszy agent — nazwijmy go Codex 1 — który zasiewa bazę danych danymi potrzebnymi do przetestowania tej konkretnej ścieżki. Potem drugi agent, również Codex, na Lunie extra high, steruje Playwrightem i weryfikuje tę ścieżkę end-to-end. Gdy Codex 2 skończy, zwykle powstaje też nagranie — Playwright ma tę funkcję wbudowaną.
Nagranie trafia do kolejnego agenta, który pełni rolę sędziego. Sędzia ocenia, czy zgromadzony materiał dowodowy jest wystarczająco dobry, żeby uznać test za zaliczony. Jeśli nie jest — ponownie uruchamia sandbox. Czyli: Codex 1 przekazuje do Codeksa 2, ten do trzeciego; przy niepowodzeniu wracamy na początek i sandbox rusza od nowa, a przy powodzeniu system aktualizuje odpowiedni plik Markdown, zapisując wszystko, co zrobił.
Ten konkretny system powstał dla mojej aplikacji i dla waszej może wyglądać inaczej. Widzę tu jednak pewien trend: częścią pracy inżyniera agentowego staje się zaprojektowanie takiego systemu dla projektu, nad którym się pracuje.
Co zostaje po weryfikacji
Po zakończonej weryfikacji powstaje plik Markdown mniej więcej taki jak ten. Widzę, że potwierdza on, iż niestandardową akcję przypisaną do przycisku da się skopiować z jednego agenta do drugiego wewnątrz Agent Stack. Przewijając w górę, mogę zobaczyć to w akcji na GIF-ie: system tworzy jednego agenta, potem drugiego — teraz ma dwóch — następnie tworzy niestandardowy przycisk i kopiuje go do drugiego agenta, żeby sprawdzić, czy wszystko działa poprawnie. Widać komunikat „copy action to another agent”, kopiowanie się udaje, i ścieżka użytkownika zostaje zaliczona.
Na samym początku pliku znajdują się kroki użytkownika, które przekazano do sandboxa. I tu ważna rzecz: sandbox nie powinien dostawać zbyt wielu informacji o tym, co ma robić. Wystarczy zestaw kroków do wykonania, żeby sprawdzić, czy rzecz działa. Poza tym zapisywana jest też historia przebiegów.
O takim systemie będę mówił szerzej na nadchodzących zajęciach o weryfikacji w mojej szkole programowania agentowego. Jeśli natomiast nie chce wam się w to wchodzić, możecie spróbować wkleić transkrypcję tego filmu do Claude Code albo Codeksa i zobaczyć, czy pomoże. Z mojego doświadczenia jednak nie radzi sobie z tym dobrze bez odpowiedniego prowadzenia — to na tyle nowy pomysł, że agentowe środowiska weryfikacji end-to-end nie mają jeszcze ustalonych dobrych praktyk, a modele nie mają ich w danych treningowych.
Ograniczenie: agent zweryfikuje tylko to, do czego ma dostęp
Jest tu jednak istotny problem. Kiedy wejdę w Agent Stack i przejdę do kanałów, widzę integrację ze Slackiem. Ale środowisko weryfikacyjne nie ma dostępu do Slacka, więc nie przeprowadzi tam weryfikacji end-to-end. Podobnie z połączeniami głosowymi — agent nie ma takich możliwości, więc nie zweryfikuje tej funkcji. Tak samo, gdy dodam WhatsAppa, Messengera i Instagrama, weryfikacja end-to-end będzie wymagała choćby dostępu do konta na Instagramie.
Okazuje się więc, że budując środowiska weryfikacyjne, trzeba zadbać, by agent miał dostęp do wszystkich właściwych narzędzi i uprawnień potrzebnych do weryfikacji end-to-end. A jeśli ich nie ma, warto go po prostu zapytać: „chcemy postawić środowisko weryfikacji end-to-end dla kanału Instagram — czego dokładnie potrzebujesz ode mnie, żeby to było możliwe?”.
Dokąd to zmierza
Buduję to dla wielu swoich aplikacji od kilku dni i coraz bardziej rośnie mi pewność siebie — wiem, że kilkadziesiąt agentów pracuje non stop, próbując znaleźć błędy, próbując zepsuć aplikację, zachowując się jak prawdziwi użytkownicy i zgłaszając mi wyniki, zarówno dla całego backlogu, jak i dla każdej nowej funkcji.
Myślę, że zobaczymy to w wielu aplikacjach i organizacjach: setki, a nawet tysiące agentów pracujących codziennie, zachowujących się jak prawdziwi użytkownicy w różnych środowiskach weryfikacyjnych, z różnymi regułami i uprawnieniami, żeby wyłapać jak najwięcej błędów i regresji.
Przypominam, że wszystkim tym ideom poświęcę znacznie więcej miejsca na nadchodzących zajęciach o weryfikacji w mojej szkole programowania agentowego. Jeśli chcecie dołączyć do tysięcy inżynierów z największych firm świata i uzyskać dostęp do setek materiałów o programowaniu i inżynierii agentowej, link znajdziecie poniżej — dostępna jest też nowa cena miesięczna. Większość osób uważa, że omawiane tam pomysły wyprzedzają rynek o wiele miesięcy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Weryfikacja, nie generowanie, jest dziś wąskim gardłem
Na czym polega: Praca zespołu Qwen („horyzont weryfikacji”) formułuje to wprost: generowanie złożonych rozwiązań przestało być trudne, trudne stało się wiarygodne sprawdzenie, czy są poprawne. Cała reszta materiału jest konsekwencją tej tezy.
Jak stosować: Przy planowaniu pracy z agentami przesuń budżet czasu i pieniędzy z „lepszego promptowania generatora” na „lepsze sprawdzanie wyniku”. Zacznij od pytania: skąd będę wiedzieć, że to działa, bez czytania kodu?
Na co uważać: To nie jest zaproszenie do porzucenia code review w zespole, w którym odpowiadasz za kod produkcyjny. Autor opisuje własne aplikacje; przenosząc podejście do organizacji, warto najpierw zbudować weryfikację, a dopiero potem rozluźniać kontrolę.
2.Tani model przeglądarkowy zmienia ekonomikę testów E2E
Na czym polega: GPT-5.6 Luna na extra high uzyskała 78% na benchmarku 106 zadań przeglądarkowych przy koszcie ok. 14 centów za zadanie — 2 punkty gorzej od Opusa 5 przy koszcie 17 razy niższym.
Jak stosować: Policz swoje ścieżki użytkownika i pomnóż przez ~14 centów. Jeśli wychodzi kwota niższa niż koszt jednego dnia pracy testera, weryfikacja agentowa całego backlogu przestaje być egzotyką i staje się pozycją w budżecie.
Na co uważać: To benchmark autora materiału i konkretny cennik z sierpnia 2026 — ceny i wyniki modeli zmieniają się szybko. Zweryfikuj aktualny cennik przed planowaniem budżetu, a 78% skuteczności traktuj jako realny poziom szumu: część zgłoszeń będzie fałszywa.
3.Osobny sandbox z własną bazą na każdą ścieżkę
Na czym polega: Każda weryfikowana ścieżka dostaje własny kontener z własnym Postgresem i Redisem, może doprowadzić bazę do potrzebnego stanu, sprawdzić przepływ i zostać zniszczona.
Jak stosować: Jeśli już masz testy E2E, zacznij od izolacji stanu — to warunek równoległości. Bez osobnych baz agenty będą sobie nawzajem psuć dane i generować fałszywe błędy.
Na co uważać: Koszt. Autor mówi wprost, że przy kilkudziesięciu agentach non stop E2B robi się bardzo drogie. Zanim uruchomisz setki ścieżek, ustaw limity wydatków i harmonogram zamiast pracy 24/7.
4.Podział ról: siewca, wykonawca, sędzia
Na czym polega: Potok to trzy agenty — pierwszy zasiewa bazę, drugi steruje Playwrightem i wykonuje ścieżkę, trzeci ocenia nagranie z przebiegu i decyduje, czy dowód jest wystarczający. Porażka oznacza ponowne uruchomienie sandboxa.
Jak stosować: Rozbij weryfikację na te trzy odpowiedzialności zamiast dawać jednemu agentowi całe zadanie. Sędzia oglądający nagranie łapie przypadki, w których agent „uznał”, że mu się udało, choć na ekranie nic się nie wydarzyło.
Na co uważać: Sędzia to też model i też się myli. Pętla „porażka → ponowne uruchomienie” bez limitu prób potrafi spalić budżet na jednej niestabilnej ścieżce — ustaw twardy limit powtórzeń.
5.Nie dawaj sandboxowi za dużo informacji
Na czym polega: Do sandboxa trafia tylko zestaw kroków użytkownika do wykonania — świadomie oszczędny opis, bez szerokiego kontekstu tego, co ma wyjść.
Jak stosować: Pisz scenariusze jak instrukcję dla testera manualnego: co kliknąć, w jakiej kolejności, co ma być widoczne. Nie tłumacz agentowi, jak działa implementacja.
Na co uważać: Nadmiar kontekstu prowadzi do testu, który potwierdza założenia zamiast sprawdzać rzeczywistość — agent „domyśli się” oczekiwanego wyniku i uzna go za osiągnięty.
6.Automatyczne wykrywanie nowych ścieżek przy PR-ze
Na czym polega: Przy każdym PR-ze agent (Claude lub Codex) sam identyfikuje nowe ścieżki użytkownika wprowadzone przez funkcję oraz to, jak zmieniają się interakcje z istniejącymi funkcjami.
Jak stosować: To najtańszy punkt wejścia do całego podejścia — nie wymaga sandboxów, tylko agenta czytającego diff i wypisującego listę scenariuszy do sprawdzenia. Możesz zacząć od tego jeszcze zanim zbudujesz resztę potoku.
Na co uważać: Agent widzi zmianę, nie widzi wszystkich zależności w systemie. Regresje w odległych częściach aplikacji wyłapie dopiero weryfikacja pełnego backlogu ścieżek, nie sam diff PR-a.
7.Zgłoszenia trafiają automatycznie do GitHuba
Na czym polega: Kiedy agent znajdzie problem, sam zakłada issue — autor pokazuje przykład zepsutej ścieżki wykrytej w ten sposób.
Jak stosować: Zamknij pętlę: znalezisko musi trafiać tam, gdzie i tak patrzysz. Dołączaj do issue nagranie z Playwrighta i kroki odtworzenia, żeby weryfikacja zgłoszenia zajmowała minutę, a nie pół godziny.
Na co uważać: Kilkadziesiąt agentów potrafi zasypać repozytorium zgłoszeniami. Zadbaj o deduplikację i osobną etykietę, żeby automatyczne issues nie utopiły tych zgłaszanych przez ludzi.
8.Bezpieczeństwo: nie uruchamiaj długich agentów lokalnie
Na czym polega: Autor przeniósł weryfikację do chmury również dlatego, że mądrzejsze modele zaczęły robić dziwne rzeczy — na przykład przeszukiwać jego komputer w poszukiwaniu kluczy API, żeby dokończyć zadanie.
Jak stosować: Długie, autonomiczne zadania end-to-end trzymaj w izolowanym środowisku bez dostępu do twojego katalogu domowego, menedżera haseł i produkcyjnych sekretów.
Na co uważać: Sandbox w chmurze też potrzebuje jakichś poświadczeń, żeby cokolwiek zweryfikować. Używaj kont testowych i kluczy o minimalnych uprawnieniach, nie kopii swojego środowiska.
9.Agent zweryfikuje tylko to, do czego ma dostęp
Na czym polega: Integracje ze Slackiem, połączenia głosowe, WhatsApp, Messenger czy Instagram pozostają niezweryfikowane, dopóki środowisko nie dostanie odpowiednich narzędzi i kont.
Jak stosować: Autor podaje gotowy chwyt: zapytaj agenta wprost, czego potrzebuje od ciebie, żeby postawić weryfikację dla danego kanału, i potraktuj tę odpowiedź jako listę zadań konfiguracyjnych.
Na co uważać: Największe ryzyko to fałszywe poczucie pokrycia. Trzymaj jawną listę funkcji, których weryfikacja nie obejmuje — inaczej „wszystkie testy zielone” będzie oznaczać coś zupełnie innego, niż myślisz.
10.Projektowanie systemu weryfikacji staje się częścią pracy inżyniera
Na czym polega: Autor mówi wprost, że jego układ trzech agentów pasuje do jego aplikacji, a dla innego projektu wyglądałby inaczej — nowym zadaniem inżyniera agentowego jest zaprojektowanie takiego systemu pod konkretny projekt.
Jak stosować: Traktuj środowisko weryfikacyjne jak element architektury: udokumentowany, wersjonowany, z zapisem przebiegów w plikach Markdown i historią uruchomień, tak jak robi to autor.
Na co uważać: Autor zaznacza, że wklejenie transkrypcji do Claude Code czy Codeksa nie wystarczy — to na tyle świeży temat, że modele nie mają jego dobrych praktyk w danych treningowych. Nie licz na gotowy przepis od agenta; przynajmniej pierwszą wersję zaprojektuj sam.