Chrome DevTools per agenti: quando è l'agente a controllare il proprio CSS

Con il vibe coding il collo di bottiglia si è spostato. Scrivere codice costa sempre meno, controllarlo costa ancora tempo e attenzione. Chi lavora con un agente lo vede ogni giorno: il layout si rompe, l'agente propone una correzione, la correzione sistema un punto e ne sposta un altro.

Le novità di DevTools di novembre 2026, pubblicate sul blog Chrome for Developers il 20 ottobre insieme ai rilasci stabili di Chrome 155 e 156, partono proprio da qui. La prima sezione si intitola DevTools per gli agenti. Prima del selettore colori, prima dei pannelli Rete e Prestazioni, Google mette gli strumenti pensati per chi non guarda lo schermo.

Tra il codice e lo schermo c'è la cascata

Un agente che scrive CSS sa cosa ha scritto. Non sempre sa cosa ne ha fatto il browser.

Tra la regola nel file e il pixel sullo schermo intervengono la specificità dei selettori, l'ordine dei fogli di stile, l'ereditarietà, i pseudo-elementi, le media query, le @-rules. Una proprietà dichiarata correttamente può essere sovrascritta tre file più in là. Un margine che sembra sbagliato può arrivare da un ::before che nessuno ricordava.

Uno sviluppatore questo lo scopre aprendo il pannello Elementi e guardando la scheda Stili. Un agente che lavora solo sul codice sorgente deve invece ricostruirlo per deduzione, ed è qui che nascono i cicli di correzioni a tentativi.

Il problema non è nuovo. Quello che cambia è la quantità: più codice viene generato, più conta avere un modo rapido e affidabile per verificarlo. Ed è ragionevole che una parte di questa verifica la faccia l'agente stesso, prima di passare la palla a una persona.

Cosa c'è di nuovo in Chrome DevTools per agenti

Chrome DevTools per agenti è lo strumento che collega un agente di programmazione a una sessione di Chrome, così che possa ispezionare la pagina, leggere la console, registrare tracce di performance. Con questo aggiornamento guadagna cinque novità.

• Ispezione degli stili CSS. Il nuovo strumento get_css_styles restituisce gli stili calcolati e le regole corrispondenti, con impaginazione dei risultati (pageSize e pageIdx). Include le regole ereditate, i pseudo-elementi, i @keyframes e le @-rules come @position-try, @property e @function.
• File di configurazione e percorsi. I flag del server si possono gestire da un file di configurazione dedicato, con root del file system personalizzate e il flag --allow-unrestricted-paths che da riga di comando è attivo di default.
• Tracce di performance a blocchi. Le registrazioni molto grandi vengono analizzate a blocchi, con un buffer predefinito di 1,2 GB. Inoltre ogni analisi usa un'istanza separata del motore, per evitare perdite di memoria.
• Finestre di dialogo e console. Le finestre di dialogo JavaScript aperte durante le azioni dell'agente vengono gestite in automatico, e la cronologia della console resta disponibile durante le navigazioni nello stesso documento.
• Installazione dal menu. Nel menu principale di DevTools c'è ora la voce Scarica Chrome DevTools per agenti, che porta alle istruzioni di configurazione.

Presi uno per uno sono miglioramenti tecnici. Messi insieme puntano nella stessa direzione: togliere gli ostacoli pratici che interrompevano il lavoro dell'agente a metà strada, dal popup che bloccava tutto alla traccia troppo pesante da leggere.

Perché get_css_styles cambia il ciclo di lavoro

La differenza sta nel tipo di informazione che l'agente riceve. Uno screenshot gli dice che qualcosa è fuori posto. La cascata gli dice perché.

Prendiamo un caso comune. Un componente generato dall'agente ha un pulsante con il padding sbagliato:

/* components/card.css: la regola scritta dall'agente */
.btn { padding: 12px 24px; }

/* legacy/theme.css: più specifica, vince lei */
.card .btn-primary { padding: 8px; }

Leggendo solo il proprio file, l'agente vede una regola corretta e non capisce dove sia il problema. Con gli stili calcolati e le regole corrispondenti ha davanti il quadro completo: quale dichiarazione vince, da quale file arriva, quali sono state scartate. A quel punto la correzione smette di essere un tentativo.

C'è poi un dettaglio meno evidente. Tra le regole che get_css_styles sa leggere c'è @position-try, parte del CSS anchor positioning, una delle funzioni più recenti della piattaforma. Lo stesso aggiornamento dedica al tema anche un editor visivo di position-area nel pannello Elementi, pensato per le persone. Sono API che molti modelli conoscono poco, perché nei dati su cui sono stati addestrati compaiono raramente. Per questo Google segnala nello stesso articolo Modern Web Guidance, una raccolta di guide pensata per aiutare gli agenti a usare le funzionalità recenti invece dei pattern di qualche anno fa.

Cosa l'agente continua a non vedere

Un agente vede quello che DevTools gli espone. È molto, ma non è tutto.

La cascata spiega perché un elemento è largo 240 pixel. Non dice se quell'elemento è nel punto giusto della pagina, se la gerarchia visiva guida l'occhio dove serve, se un'interazione risulta naturale o scomoda. Sono giudizi che dipendono da chi usa l'interfaccia, dal contesto, dagli obiettivi del progetto. Una pagina può avere un CSS impeccabile ed essere difficile da usare.

Vale lo stesso per l'accessibilità. Un agente può controllare un rapporto di contrasto o la presenza di un attributo. Capire se la pagina è davvero percorribile con la tastiera, o comprensibile con uno screen reader, richiede ancora di provarla.

Il resto dell'aggiornamento, intanto, è pensato per le persone: l'editor visivo di position-area, i suggerimenti di contrasto APCA nel selettore colori, la diagnostica dei manifest per Web Install, il rilevamento della memoria trattenuta dalle closure. Strumenti che servono a chi deve capire cosa è successo, soprattutto quando il codice non l'ha scritto lui.

Per chi progetta e sviluppa cambia il punto in cui si spende l'attenzione. Capire quale regola sovrascrive quale diventa sempre più un lavoro che l'agente può fare da solo. Decidere se la pagina funziona per chi la userà resta un lavoro nostro.

Come iniziare

Il punto di partenza è dentro DevTools stesso. Procediamo per gradi.

1. Apri il menu principale di DevTools e scegli Scarica Chrome DevTools per agenti: porta alle istruzioni di configurazione per collegarlo al tuo agente.
2. Usa un profilo Chrome dedicato. L'agente lavora sulla sessione del browser, quindi è meglio che non trovi aperti account aziendali, gestionali o caselle di posta.
3. Limita i permessi sul file system. Da riga di comando --allow-unrestricted-paths è attivo di default e lascia all'agente un accesso ampio al file system: ha senso in un ambiente di sviluppo isolato, molto meno sulla macchina di tutti i giorni. Fuori da un ambiente isolato, definisci nel file di configurazione root del file system circoscritte.
4. Parti da un problema circoscritto, per esempio un singolo bug di layout in ambiente di staging, e chiedi all'agente di spiegarti cosa ha trovato nella cascata prima di correggere.
5. Se il progetto usa API CSS recenti, affianca all'agente le guide di Modern Web Guidance.

Il quarto punto è quello che fa la differenza. Un agente che motiva la correzione con la regola che ha letto è verificabile. Uno che corregge e basta va controllato ogni volta da capo.

Il browser entra nel ciclo

Per anni gli strumenti per sviluppatori sono stati progettati per occhi umani. Questo aggiornamento mette gli agenti in cima alla lista e difficilmente sarà l'ultimo a farlo. La domanda interessante, per chi sviluppa, è quanta parte della verifica si è disposti ad affidare all'agente e con quali garanzie.

Se stai valutando come introdurre agenti e AI nei processi di sviluppo della tua azienda, prenota un appuntamento gratuito con il nostro team: partiamo dai vostri flussi di lavoro reali.