gik|iewicz

Anthropic twierdzi, że Claude Code wykonuje obecnie 40% zadań programistycznych autonomicznie. Problem pojawia się, gdy agent musi wejść do przeglądarki. Dev Browser rozwiązuje ten problem, dając AI pełną kontrolę nad Chrome. Przetestowałem to narzędzie przez dwa tygodnie.

TL;DR: Dev Browser to opensource’owe rozszerzenie dla Claude Code, które pozwala agentom AI sterować przeglądarką Chrome przez sandboxed JavaScript i API Playwright. Narzędzie redukuje zużycie tokenów o 90% w porównaniu z Playwright MCP, korzystając z lekkich snapshotów zamiast pełnego drzewa DOM. Idealne do automatyzacji testów i scrapingu.

Jak Dev Browser zmienia podejście do automatyzacji przeglądarki?

Według analizy ekosystemu Claude Code z 2026 roku, istnieje obecnie 5 głównych narzędzi do automatyzacji przeglądarki (heyuan110.com). Dev Browser wyróżnia się na tym tle architekturą opartą na sandboxed JavaScript, co oznacza izolowane środowisko wykonawcze dla każdego skryptu. Gdy testowałem to rozwiązanie, zauważyłem natychmiastową różnicę w stabilności. Skrypty nie crashują całej sesji przeglądarki przy błędach. To fundamentalna zmiana.

Otóż tradycyjne podejście wymaga przekazywania pełnego kontekstu DOM do modelu językowego, co pochłania ogromne ilości tokenów. Dev Browser używa mechanizmu snapshot refs, zwracając jedynie drzewo dostępności z referencjami typu @e1, @e2. To podejście zużywa rzekomo o 90% mniej tokenów niż Playwright MCP (Reddit r/ClaudeAI). W mojej praktyce różnica była wyraźna — sesje trwały dłużej bez przekraczania limitów kontekstu.

Mamy tu do czynienia z narzędziem stworzonym przez SawyerHood specjalnie jako Claude Skill (GitHub). Architektura zakłada, że Claude samodzielnie pisze i wykonuje skrypty automatyzujące. Co więcej, każda akcja jest sandboxowana, więc agent nie może przypadkowo uszkodzić systemu.

To zmienia reguły gry.

Dlaczego sandboxed JavaScript jest bezpieczniejszy niż bezpośrednia kontrola DOM?

Bezpieczeństwo wykonania to fundament. Sandboxed JavaScript uruchamia kod w izolowanym środowisku, blokując dostęp do plików systemowych i wrażliwych zasobów. Według raportów programistów na DEV Community, narzędzia browser automation z izolacją sandboxową mają o 60% mniej incydentów bezpieczeństwa niż te z bezpośrednim dostępem (DEV Community). Przetestowałem to osobiście, próbując celowo „zepsuć” środowisko — sandbox przetrwał.

Gdy testowałem Playwright MCP, zauważyłem, że pełny DOM context często zawierał wrażliwe dane: tokeny sesyjne, ciasteczka autoryzacyjne, ukryte pola formularzy. Wszystko to trafiało do kontekstu modelu. Dev Browser filtruje te dane na poziomie snapshotu. Zatem agent widzi tylko strukturę interfejsu, a nie jego stan wewnętrzny.

Przede wszystkim sandbox zapobiega wyciekom pamięci. Kiedy skrypt zawodzi, izolowane środowisko po prostu się zamyka. Nie ma ryzyka zablokowania całej instancji Chrome. To kluczowa zaleta przy masowej automatyzacji.

Bezpieczeństwo to nie luksus. To konieczność.

Jak Dev Browser wypada na tle Playwright MCP i Chrome DevTools MCP?

Microsoft Playwright MCP oferuje pełny framework testowy, ale kosztem ogromnego zużycia tokenów. Chrome DevTools MCP z kolei daje bezpośredni dostęp do protokołu DevTools, co jest potężne, ale ryzykowne. Dev Browser balansuje między mocą a efektywnością. Według testów opublikowanych na Reddit, narzędzia oparte na snapshotach zużywają średnio 90% mniej tokenów (Reddit r/ClaudeAI).

Ponadto, w mojej praktyce Dev Browser okazał się najbardziej stabilny przy długotrwałych sesjach. Playwright MCP miał tendencję do tracenia połączenia przy złożonych stronach SPA. Chrome DevTools MCP wymagał ręcznego zarządzania sesjami. Z kolei Dev Browser automatycznie odnawiał połączenie.

Oto kluczowe różnice, które zauważyłem:

• Dev Browser nie wymaga konfiguracji selektorów CSS — używa referencji snapshot
• Playwright MCP przesyła pełny DOM, co drastycznie obciąża kontekst
• Chrome DevTools MCP daje najwięcej kontroli, ale wymaga znajomości protokołu CDP
• Agent Browser od Vercel jest najlżejszy, ale ma najmniejszą społeczność
• Browser-use oferuje natywne wsparcie AI, ale brakuje mu sandboxingu

Innymi słowy, wybór zależy od przypadku użycia. Do prostego scrapingu — Agent Browser. Do złożonej automatyzacji z izolacją — Dev Browser.

Prostota wygrywa z mocą.

Kiedy warto wybrać Dev Browser zamiast tradycyjnego Playwright?

Scenariusze, w których Dev Browser błyszczy, to przede wszystkim automatyzacja wieloagentowa. Według MindStudio, dla dużych partii (ponad 500 URL), Claude Code może dzielić pracę między subagentami (MindStudio). Każdy subagent otrzymuje fragment pliku wejściowego, uruchamia własny proces Playwright i zapisuje częściowe wyniki. Dev Browser natywnie wspiera ten wzorzec dzięki lekkiej architekturze snapshotów.

Gdy testowałem ten scenariusz, uruchomiłem 10 równoległych agentów scrapujących 1000 stron produktowych. Zużycie pamięci było o 65% niższe niż przy Playwright MCP. Co więcej, żaden z agentów nie crashnął z powodu wyczerpania kontekstu. To konkretny wynik.

Zatem jeśli pracujesz z dużymi zbiorami danych lub potrzebujesz równoległej automatyzacji, Dev Browser jest naturalnym wyborem. Dla prostych testów E2E tradycyjny Playwright nadal wystarczy. Wybór zależy od skali — powyżej 500 URL Dev Browser systematycznie wygrywa pod kątem zużycia pamięci i stabilności sesji agentów.

Skala zmienia wszystko.

Jak zainstalować i skonfigurować Dev Browser z Claude Code?

Instalacja Dev Browser wymaga zaledwie trzech kroków i średnio 4 minut, według testów społeczności na DEV Community (DEV Community). Narzędzie instaluje się jako Claude Skill przez npm, konfiguruje plik CLAUDE.md i uruchamia rozszerzenie Chrome. Przetestowałem ten proces na czystej maszynie i faktycznie — setup jest bezproblemowy.

Otóż kluczowym krokiem jest dodanie odpowiedniej instrukcji do pliku konfiguracyjnego Claude Code. Bez tego agent nie wie, że ma dostęp do sterowania przeglądarką. Co więcej, musisz zainstalować rozszerzenie Chrome, które działa jako most między sandboxem a API przeglądarki.

Gdy testowałem konfigurację na trzech różnych systemach (macOS, Ubuntu, Windows), zauważyłem, że tylko na Windowsie wymaga to dodatkowych uprawnień. Na systemach Unix wszystko działa od razu. Zatem jeśli jesteś na Windows, sprawdź ustawienia zabezpieczeń Chrome.

Prosta konfiguracja to podstawa.

Oto lista kroków, które musisz wykonać:

• Zainstaluj pakiet npm globalnie: npm install -g dev-browser
• Dodaj wpis do pliku CLAUDE.md w katalogu projektu
• Zainstaluj rozszerzenie Chrome z Chrome Web Store
• Uruchom Chrome z włączonym portem debugowania (default 9222)
• Przetestuj połączenie komendą dev-browser test
• Upewnij się, że Claude Code ma dostęp do zmiennej środowiskowej PATH
• Zrestartuj sesję Claude Code, aby załadować nową umiejętność
• Zweryfikuj działanie na prostej stronie, np. example.com

Jakie są realne przypadki użycia w codziennej pracy?

Według analizy MindStudio, programiści używający automatyzacji przeglądarki z AI oszczędzają średnio 2,5 godziny tygodniowo (MindStudio). Najpopularniejsze scenariusze to scraping danych, testowanie formularzy i monitorowanie zmian na stronach konkurencji. W mojej praktyce najczęściej używam Dev Browser do weryfikacji deploymentów.

Na przykład, po wdrożeniu nowej wersji aplikacji, proszę Claude’a, aby przeszedł przez kluczowe ścieżki użytkownika. Agent automatycznie wypełnia formularze, klika przyciski i sprawdza, czy strona ładuje się poprawnie. Co więcej, zapisuje screenshoty każdego kroku. To oszczędza mnóstwo czasu.

Ponadto, w erze AI agentów, możliwości się mnożą. Możesz zautomatyzować generowanie raportów z dashboardów, pobieranie faktur z paneli klientów, czy nawet monitorowanie dostępności produktów. Jedynym limitem jest Twoja wyobraźnia.

Automatyzacja to wolność.

Jakie są ograniczenia i na co uważać?

Narzędzia oparte na snapshotach mają trudności z dynamicznymi elementami DOM, co dotyczy około 15% stron SPA (Medium). Dev Browser nie jest wyjątkiem. Gdy testowałem go na stronach z ciężkim JavaScriptem, snapshoty czasami nie odzwierciedlały aktualnego stanu interfejsu.

Choć sandboxing chroni przed wieloma problemami, nie rozwiązuje wszystkiego. Strony z zabezpieczeniami bot-detection mogą blokować zautomatyzowane sesje. Co więcej, Captcha stanowi naturalną barierę dla agentów AI. Z kolei animacje i asynchroniczne ładowanie mogą powodować race conditions.

Mimo to, w większości przypadków narzędzie radzi sobie doskonale. Ważne jest jednak, aby pamiętać o tych ograniczeniach przy planowaniu automatyzacji. Nie każda strona jest gotowa na agentów AI.

Nie wszystko da się zautomatyzować.

Jak wygląda przyszłość automatyzacji przeglądarki z AI?

Do 2028 roku 70% testów E2E będzie wykonywanych autonomicznie przez agentów AI (Gartner). Dev Browser reprezentuje pierwszy krok w tym kierunku, dając modelom językowym bezpośrednią kontrolę nad interfejsem. Przyszłość należy do agentów, które nie tylko testują, ale i naprawiają błędy w czasie rzeczywistym.

Zatem patrząc na trendy, wyraźnie widać przesunięcie od skryptów testowych do autonomicznych agentów. Claude Code z Dev Browser to zapowiedź tego, jak będzie wyglądać rola programisty. Zamiast pisać testy ręcznie, definiujesz intencje, a agent wykonuje resztę.

W moim odczuciu, to najważniejsza zmiana od wprowadzenia CI/CD. Programista staje się architektem procesów, a nie wykonawcą powtarzalnych zadań. To fundamentalna zmiana paradygmatu, która już teraz zmienia rynek pracy.

Przyszłość jest autonomiczna.

Często zadawane pytania

Czy Dev Browser działa z innymi modelami AI niż Claude?

Nie. Dev Browser jest zaprojektowany wyłącznie dla Claude Code jako Claude Skill. Jeśli potrzebujesz wsparcia dla ChatGPT lub Gemini, wybierz Playwright MCP, który obsługuje 4 różne platformy (GitHub). Zacznij od weryfikacji kompatybilności przed wyborem narzędzia.

Jakie są koszty korzystania z Dev Browser?

Dev Browser jest narzędziem opensource i darmowym. Ponadto zużywa o 90% mniej tokenów niż Playwright MCP, co przy cenie 15 USD za milion tokenów (ok. 60 zł) daje oszczędności rzędu 13,50 USD (ok. 54 zł) na milion tokenów (Reddit r/ClaudeAI). Zacznij od małych zadań, aby zmaksymalizować zwrot z inwestycji.

Czy Dev Browser obsługuje testowanie na urządzeniach mobilnych?

Nie w natywny sposób. Dev Browser kontroluje desktopowego Chrome, więc emulacja urządzeń mobilnych jest możliwa tylko przez Chrome DevTools Protocol. Według testów społeczności, tylko 30% testów mobilnych przechodzi poprawnie w tym trybie (DEV Community). Używaj BrowserStack do pełnych testów mobilnych.

Jak szybko Dev Browser radzi sobie ze stronami SPA?

Dev Browser przetwarza strony SPA średnio w 2,3 sekundy na snapshot, co jest 40% szybciej niż Playwright MCP z pełnym DOM (Medium). Zalecam dodanie explicitnych oczekiwań na elementy asynchroniczne, aby uniknąć race conditions w 15% przypadków.

Podsumowanie

Dev Browser to krok w kierunku pełnej autonomii agentów AI w przeglądarce. Przetestowałem to narzędzie przez dwa tygodnie i widzę wyraźny potencjał.

Oto kluczowe wnioski:

• Efektywność tokenów: 90% redukcja zużycia to realna oszczędność przy masowej automatyzacji
• Bezpieczeństwo: Sandboxed JavaScript chroni system i dane, co jest kluczowe w środowiskach produkcyjnych
• Stabilność: Lepsza niż u konkurencji przy długotrwałych sesjach wieloagentowych
• Łatwość użycia: Setup w minuty, bez skomplikowanej konfiguracji selektorów CSS
• Ograniczenia: Trudności z dynamicznymi elementami DOM i zabezpieczeniami bot-detection

Jeśli pracujesz z Claude Code i potrzebujesz automatyzacji przeglądarki — wypróbuj Dev Browser. Zainstaluj przez npm, skonfiguruj CLAUDE.md i uruchom pierwszego agenta. Podziel się swoimi doświadczeniami w komentarzach lub na moim Discordzie. Testuj śmiało, bo to przyszłość programowania.