Repo del giorno: dev-browser, il browser che fa verificare all'agente il proprio lavoro

🔍 Cos'è dev-browser

dev-browser è, testualmente, «una Claude Skill che dà al tuo agente la capacità di usare un browser web». In pratica è un piccolo runtime a riga di comando: l'agente scrive uno script JavaScript che pilota una pagina con l'API di Playwright — vai a un URL, clicca, compila, valuta, fai uno screenshot — e dev-browser lo esegue. La differenza rispetto a un semplice script Playwright sta in tre scelte di design: l'esecuzione è sandboxata, le pagine sono persistenti, e la connessione al browser è automatica.

Sandboxato vuol dire che lo script non gira in Node.js ma dentro una sandbox QuickJS compilata in WebAssembly, senza accesso al filesystem o alla rete dell'host: può guidare il browser, non il tuo computer. Persistente vuol dire che una pagina aperta in uno script resta viva per il successivo, quindi l'agente naviga una volta e poi interagisce in più passi senza ripartire da capo ogni volta. Automatico vuol dire che si aggancia al Chrome che hai già aperto — utile per lavorare sulla tua sessione, con i tuoi login — oppure lancia un Chromium pulito e headless quando serve un ambiente vergine.

repo       SawyerHood/dev-browser
cosa       un browser pilotabile dall'agente via script Playwright
sandbox    QuickJS in WebAssembly, senza accesso a disco e rete dell'host
pagine     persistenti: naviga una volta, interagisci in più script
connetti   al Chrome già aperto (--connect) o a un Chromium nuovo
licenza    MIT · TypeScript + Rust · dietro c'è l'azienda Do Browser

⚙️ Come si installa e il primo script

L'installazione è quella di un pacchetto npm globale: si installa dev-browser e poi si lancia il comando che scarica Playwright e Chromium. Da lì l'uso più semplice è passare uno script sullo standard input: apri una pagina, vai a un indirizzo, leggi il titolo. Chi vuole lavorare sulla propria sessione — cookie e login inclusi — abilita il debug remoto di Chrome e lancia con la modalità di connessione, così l'agente usa il browser che sta già usando la persona.

Il modo consigliato di darlo in mano a un agente è disarmante: dopo l'installazione basta dirgli di eseguire il comando di aiuto. L'output non è la solita lista di flag, ma una guida d'uso pensata per un LLM, con esempi e riferimento dell'API — così l'agente impara da solo come usarlo, senza installare né plugin né skill. Resta comunque disponibile la via classica come plugin di Claude Code o come skill copiata nella cartella di Amp o Codex, per chi la preferisce.

# Installazione globale + browser
npm install -g dev-browser
dev-browser install     # scarica Playwright + Chromium

# Un primo script: apri una pagina e leggi il titolo
dev-browser --headless <<'EOF'
const page = await browser.getPage("main");
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
EOF

# Oppure aggancia il Chrome che hai gia' aperto
dev-browser --connect

🧩 Come lo usa un agente: l'API in sandbox

Dentro lo script l'agente ha pochi oggetti globali e chiari. C'è un oggetto browser per ottenere una pagina per nome, crearne una temporanea, elencare le schede aperte o chiuderne una. C'è un piccolo insieme di funzioni per salvare uno screenshot o leggere e scrivere file, ma confinate in una cartella temporanea dedicata: di nuovo la sandbox, che ti protegge il resto del disco. E ogni pagina è un oggetto Page completo di Playwright, con tutti i metodi che ci si aspetta.

La parte pensata apposta per gli agenti sono i due «livelli» di controllo che ogni pagina espone, più uno snapshot fatto per gli LLM. Il livello a pixel scatta uno screenshot i cui punti mappano uno a uno sulle coordinate della pagina e permette di cliccare, trascinare, scorrere e digitare a quelle coordinate — il modo «visione» di operare. Il livello per id del DOM, invece, produce un elenco degli elementi interattivi visibili con un identificatore ciascuno, e l'agente agisce citando l'id: più robusto quando la pagina è strutturata. Avere entrambi significa che l'agente sceglie l'approccio giusto per la situazione, invece di forzarne uno solo.

// Controllo del browser
browser.getPage(nome)      // pagina per nome, o si connette a una scheda
browser.newPage()          // pagina temporanea, ripulita a fine script
browser.listPages()        // elenco schede: id, url, titolo, nome

// Ogni pagina e' un Playwright Page completo
await page.goto(url); await page.click(sel); await page.fill(sel, val);
await page.snapshotForAI();   // snapshot della pagina, formato per LLM

// Due livelli di azione pensati per gli agenti
page.cua.*      // a pixel: screenshot + click/scroll/type a coordinate
page.domCua.*   // per id del DOM: elementi visibili numerati, agisci per id

📊 Perché è veloce: i numeri dell'autore

La domanda ovvia è: perché non usare direttamente Playwright MCP, o l'estensione di Claude per il browser? L'autore ha pubblicato un piccolo benchmark, con la metodologia in un repo dedicato, che confronta quattro modi di dare un browser all'agente sullo stesso compito. dev-browser lo chiude in circa quattro minuti, con 29 turni e meno di un dollaro di costo, al 100% di successo. Playwright MCP arriva anch'esso al 100%, ma con 51 turni e un costo quasi doppio; la skill Playwright e l'estensione Chrome sono più lente e, nel caso della skill, meno affidabile.

Il motivo di fondo è l'architettura: un server Playwright che resta acceso mantiene le pagine vive, e gli script agentici fanno più cose per turno invece di un lento giro «osserva–pensa–agisci» a ogni micro-passo. Meno turni significano meno token spesi e meno tempo perso, che su un agente che paghi a consumo è esattamente ciò che conta. Vanno letti per quello che sono — misure dell'autore su un compito, non un benchmark indipendente — ma la direzione è coerente con il design.

🏢 Perché è interessante, per sviluppatori e PMI

Per chi sviluppa, dev-browser chiude un anello che di solito resta aperto: l'agente che scrive interfacce può finalmente provarle. Costruisce una schermata, la apre, clicca il pulsante, compila il form, verifica che il messaggio giusto compaia — e se non compare, se ne accorge lui, non io il giorno dopo. È lo stesso spirito degli hook come quality gate o della disciplina «think, act, prove» di cui ho scritto altrove: spostare la verifica dentro il ciclo dell'agente, non dopo. Ed è anche un buon collaudatore end-to-end guidato dal linguaggio naturale, utile in fase di sviluppo.

Per una PMI il valore è indiretto ma concreto: alza la fiducia in ciò che l'AI produce. Un software costruito con l'aiuto di un agente che si è verificato da solo su un browser vero è più credibile di uno «dichiarato funzionante». E la scelta della sandbox è importante da capire in ottica di governance: gli script non toccano disco e rete dell'host, quindi il rischio operativo è contenuto e circoscritto al browser. Resta un punto di attenzione — un agente con un browser può comunque navigare e agire su siti reali — ma è un rischio gestibile, e molto più leggibile di un accesso pieno al sistema.

⚠️ Limiti e cautele prima di adottarlo

Vale la pena essere onesti. dev-browser è un progetto giovane e in evoluzione: l'ultima release al momento in cui scrivo è ancora una 0.2.x, quindi l'API può cambiare fra una versione e l'altra. Ha trazione reale — diverse migliaia di stelle e adozione nella comunità di Claude Code — ma resta pre-1.0, con quel che ne consegue in termini di stabilità. Dietro c'è un'azienda, Do Browser: il codice è open source con licenza MIT, ma è giusto saperlo per inquadrare il progetto.

Sul piano pratico, la sandbox è una protezione dell'host, non del web: lo script non tocca i tuoi file, ma il browser può navigare e agire su pagine e servizi reali, con i tuoi login se ti connetti al Chrome aperto. Pre-approvare il comando in Claude Code toglie i prompt di conferma ma toglie anche un controllo umano, quindi conviene capire bene cosa l'agente può fare prima di renderlo automatico. Infine i benchmark sono dell'autore: indicativi, non una verifica terza.

• Pre-1.0: ancora versioni 0.2.x, l'API può cambiare tra le release.
• Sandbox = host protetto, non il web: il browser agisce su siti reali, coi tuoi login se ti connetti.
• Dietro c'è un'azienda (Do Browser): progetto open MIT, ma è bene saperlo.
• Pre-approvare il comando toglie i prompt: comodo, ma rimuove un controllo umano.
• Benchmark dell'autore: numeri indicativi su un compito, non un test indipendente.

✅ Da dove partire

Il percorso che suggerisco è a basso rischio. Prima si installa e si lancia uno script minimo in modalità headless, giusto per vedere il giro: apri una pagina, leggi un titolo, fai uno screenshot. Poi si chiede all'agente di eseguire il comando di aiuto e lo si lascia leggere la guida da solo, così impara l'API senza che tu gliela spieghi. A quel punto il test più istruttivo è dargli una piccola pagina da costruire e chiedergli esplicitamente di aprirla e verificarne il comportamento con dev-browser prima di dichiararla finita.

Allargando lo sguardo, il segnale interessante non è il singolo strumento ma la direzione: dare agli agenti gli stessi strumenti che usiamo noi — un browser, un terminale, un editor — dentro confini chiari. dev-browser lo fa bene su un pezzo che mancava, la verifica visiva, e con un'attenzione alla sicurezza che è la parte da imitare. Per chi mette l'AI dentro processi reali, la lezione è quella di sempre, resa un po' più concreta: un agente vale quanto la sua capacità di controllare da solo il proprio lavoro.

Altri articoli del blog