In che modo P2ER ha creato un ambiente di massima fiducia per la programmazione con agenti con Chrome DevTools per gli agenti

Data di pubblicazione: 22 giugno 2026

P2ER, un'agenzia di soluzioni digitali, utilizza Chrome DevTools per gli agenti per garantire che solo il software verificato e funzionante venga inviato agli esseri umani per la revisione finale. Trasformando il proprio flusso di lavoro in un'infrastruttura basata su agenti, hanno consentito agli agenti AI di eseguire la verifica empirica dell'interfaccia utente, aumentando la frequenza di implementazione da una volta alla settimana a più volte al giorno.

La sfida: scalare la qualità nelle applicazioni esistenti

P2ER offre esperienze digitali di fascia alta per brand globali, tra cui case automobilistiche, brand di orologi e aziende del settore alberghiero. La loro sfida principale, come per molte aziende, era lavorare all'interno di applicazioni complesse ed esistenti. Il team che ha adottato la programmazione con agenti ha dovuto superare tre ostacoli principali:

  • Test dell'interfaccia utente fragile. Le suite di test standard hanno avuto difficoltà con i dati dinamici, come i prezzi degli hotel variabili o le offerte stagionali in alcuni progetti di P2ER. I dati simulati spesso nascondevano difetti di integrazione che un tester umano avrebbe trovato immediatamente.
  • Problemi di affidabilità dell'agente. Senza istruzioni esplicite, gli agenti AI a volte dichiaravano che un'attività era completata senza verificarla.
  • Perdita di contesto. Timeout di attività e modelli ampi hanno fatto perdere agli agenti traccia degli obiettivi della sessione. Ciò ha reso difficile per gli sviluppatori tracciare e continuare il lavoro iniziato da un agente.

La soluzione: creare un'infrastruttura per l'artigianato

P2ER ha creato un'infrastruttura che tratta l'AI come un "partner di sparring" in grado di gestire anche gli aspetti ripetitivi dello sviluppo. Questo approccio consente al team di scalare l'artigianato concentrandosi sull'architettura e sulla risoluzione creativa dei problemi.

Applica la verifica empirica con DevTools per il server MCP degli agenti

Per garantire l'affidabilità, P2ER ha stabilito una regola di verifica empirica obbligatoria. Questo mandato di ingegneria, codificato nel file AGENTS.md del progetto, afferma:

All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.

Anziché fidarsi della parola dell'agente, il team utilizza Chrome DevTools per fornire agli agenti un ambiente sicuro per navigare nell'applicazione in modo visivo e interattivo.

Questi "agenti di test" eseguono diverse attività chiave che i test statici standard non rilevano:

  • Test dinamici dei dati:anche in un ambiente di staging, gli agenti eseguono test su dati reali e fluttuanti (come i prezzi degli hotel che cambiano in base alle stagioni) per sperimentare l'applicazione esattamente come farebbe un utente. Ciò è reso possibile da DevTools per gli strumenti di interazione degli agenti come new_page, navigate_page, fill, click e hover, indicati nella loro skill github-issue-test, che consente all'agente di autenticarsi dinamicamente e simulare un percorso di clic realistico dell'utente.
  • Audit visivi:gli agenti identificano le discrepanze visive tra i layout di Figma e l'implementazione effettiva. Utilizzando lo strumento take_screenshot di DevTools per gli agenti, la loro skill figma-validate acquisisce screenshot ad alta risoluzione dei rendering live di Storybook per eseguire un confronto fianco a fianco con le esportazioni di Figma.
  • Controlli di usabilità:gli agenti rilevano traduzioni mancanti o errori di usabilità che spesso gli script automatici non notano. Interagendo direttamente con l'albero dell'accessibilità ed esaminando gli snapshot visivi recuperati tramite take_snapshot e take_screenshot, gli agenti cercano attivamente anomalie dell'interfaccia utente come le stringhe MISSING_MESSAGE, come indicato esplicitamente nei loro flussi di lavoro di verifica automatizzati.

Decomporre e rendere persistenti le attività secondarie

Per combattere i timeout delle sessioni e la perdita di contesto, P2ER compartimenta rigorosamente il lavoro tramite gli agenti secondari. Poi danno istruzioni ai loro agenti di agire come orchestratori in questo modo:

Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.

Per tenere informati i proprietari dei prodotti umani in questo processo, il team ha integrato un'abilità personalizzata per gli agenti per monitorare il proprio lavoro nei problemi di GitHub. In questo modo, ogni attività dell'agente secondario e i relativi risultati vengono salvati e documentati come problema secondario utilizzando l'API GitHub, creando una traccia di controllo chiara e un contesto persistente che altri sviluppatori possono riprendere.

Isola gli ambienti per l'esecuzione parallela

Per scalare il processo di sviluppo in modo che più agenti eseguano il codice in parallelo, P2ER richiede ambienti isolati per attività per i suoi agenti. In questo modo si evitano conflitti di stato e problemi di rete durante la verifica dell'interfaccia utente.

La configurazione tecnica per questo isolamento include:

  • Worktree Git isolati:per evitare conflitti di file e l'inquinamento dello spazio di lavoro quando più agenti operano in parallelo, le attività vengono eseguite all'interno di worktree Git isolati. Ogni agente dispone di uno spazio dedicato nel file system in cui vengono copiate le variabili di ambiente e vengono creati collegamenti simbolici alle dipendenze, garantendo che le modifiche ai file non si sovrascrivano mai a vicenda.
  • Ambienti unici:ogni agente e attività esegue il server di sviluppo Next.js su una porta isolata univoca. In base alle regole del progetto, i server vengono avviati dinamicamente con npx next dev -p <custom_port> --turbopack per garantire l'esecuzione parallela senza conflitti di rete.
  • Cloni del database:per evitare conflitti di dati durante i test paralleli, P2ER duplica in modo programmatico il database principale in uno schema specifico per l'attività all'avvio dell'agente. Una volta completata la verifica dell'agente e approvata l'attività, una procedura di pulizia automatica elimina il database isolato. Questo ciclo di vita garantisce che ogni agente operi in uno spazio di lavoro incontaminato e non lasci dati orfani.
  • Test mirati:tutti i test del browser tramite Chrome DevTools per gli agenti devono avere come target la porta personalizzata esatta allocata a quella specifica istanza dell'agente. Il loro mandato di test vieta di codificare le porte predefinite, richiedendo URL di destinazione del test come http://localhost:<custom_port>.

Impatto: un aumento di 10 volte della velocità di sviluppo mantenendo la qualità

Il passaggio alla codifica agentica con protezioni di massima affidabilità ha trasformato l'output di P2ER. Queste modifiche erano originariamente necessarie per garantire il funzionamento affidabile dell'agente, ma hanno anche avvantaggiato l'intero ciclo di vita dello sviluppo:

  • Cicli di lavoro 10 volte più veloci: la maggior parte dei problemi viene ora risolta in un solo giorno, rispetto alla media precedente di 1-3 giorni. La frequenza di implementazione è passata da una volta alla settimana a più volte al giorno.
  • Focus strategico per i team QA: poiché gli agenti ora rilevano le regressioni di base e i "frutti a portata di mano", il team di test umano può concentrarsi su scenari di test più approfonditi e complessi.
  • Implementazioni solide per gli stakeholder: le implementazioni sono ora più resilienti perché i test vanno oltre il "percorso felice" standard del programmatore.
  • Comunicazione e tracciabilità più chiare:applicando una regola "problema umano sottoproblema di implementazione", le parti interessate ricevono istruzioni chiare su quali miglioramenti logici sono stati apportati anziché leggere i ticket pieni di dettagli tecnici di implementazione e su come testarli.

Come esempio di come ciò influisce sulla velocità di sviluppo, P2ER ha creato una nuova piattaforma in sei mesi, mentre con i metodi consolidati avrebbe impiegato molti anni. L'essere umano rimane il gate di qualità finale, rivedendo le richieste pull che sono già state convalidate dagli agenti.

Approfondimenti tecnici per i team

Durante la creazione di questo flusso di lavoro, P2ER ha identificato diverse strategie che l'hanno aiutata a passare dalla sperimentazione a un modello di sviluppo maturo e assistito da agenti.

Queste strategie possono aiutare altri team a perfezionare le proprie implementazioni di agenti:

Ottimizzare l'utilizzo dei token con l'inserimento di script e il batching della CLI

I server MCP possono diventare intensivi in termini di token durante lunghe sessioni di sviluppo se gli agenti si basano esclusivamente sulla navigazione passo passo (ad esempio, scattare un'istantanea, trovare un ID, compilare un input e attendere). Per ridurre al minimo questo overhead, P2ER utilizza un approccio duplice:

  • Inserimento di script incorporati:per interazioni mirate, ad esempio l'autenticazione tramite moduli React complessi, gli agenti utilizzano lo strumento evaluate_script per inserire JavaScript nativo direttamente nel browser. In questo modo vengono ignorate le sostituzioni del setter integrate e vengono eseguite più azioni contemporaneamente, risparmiando numerosi turni di conversazione.
  • Batch di script CLI:quando gli agenti incontrano un "ostacolo" o un flusso del browser eccessivamente lungo e ripetitivo, passano a un fallback di batch CLI. Anziché spendere token per strumenti MCP individuali e ripetuti o scrivere script di automazione personalizzati da zero, P2ER richiede alla CLI di Chrome DevTools di rendere persistenti e raggruppare le azioni del browser. In questo modo gli agenti possono eseguire in modo programmatico interi flussi in più passaggi in una sola volta, riducendo drasticamente il sovraccarico della comunicazione costante tra modello e strumento.

Automatizzare il monitoraggio del rendimento con l'analisi delle tracce

Anziché basarsi esclusivamente sulla percezione umana, P2ER ha creato un'review-performanceabilità che utilizza DevTools per gli agenti per eseguire audit Lighthouse automatizzati e tracce delle prestazioni.

Gli agenti utilizzano lo strumento performance_start_trace e performance_analyze_insight per acquisire e analizzare le metriche Core Web Vitals (LCP, INP, CLS) e identificare i colli di bottiglia del thread principale o gli spostamenti del layout. Per completare il controllo di qualità, gli agenti possono eseguire un lighthouse_audit completo per proteggersi in modo specifico dalle regressioni in accessibilità, SEO e best practice web generali, garantendo che venga inviato solo codice di alta qualità per una richiesta pull.

Migliorare la verifica con Chrome DevTools per gli agenti

Oltre alle proprie competenze personalizzate, P2ER utilizza le funzionalità di base del server MCP di Chrome DevTools per gli agenti per eseguire la verifica funzionale. Ciò include l'utilizzo del server per emulare diversi dispositivi e testare la reattività, assicurandosi che l'interfaccia utente funzioni su diversi dispositivi e dimensioni dello schermo.

Utilizzando il server MCP per navigare nell'applicazione, gli agenti possono identificare le discrepanze visive tra i layout e l'implementazione effettiva, identificando gli errori che i test statici spesso trascurano.

Risorse

Per esplorare ulteriormente il caso d'uso di P2ER, esamina tutte le competenze menzionate nel repository GitHub correlato.

Per iniziare e scoprire di più sull'implementazione di flussi di lavoro simili con DevTools per gli agenti, consulta queste risorse: