Su React Native non basta generare codice: serve un ciclo di verifica automatico su simulatori e device, con evidenze riproducibili.
Negli ultimi anni la scrittura di codice è diventata, di fatto, una commodity: gli agenti AI generano feature, refactor e fix con una velocità che fino a poco fa era impensabile. Il problema è che la produttività end-to-end non cresce allo stesso ritmo, perché il collo di bottiglia si è spostato altrove: verifica e debugging.
Su mobile questa frizione è particolarmente evidente: il codice può anche “sembrare” corretto in diff, ma poi bisogna aprire la build, navigare schermate, gestire permission dialog, tastiere, gesture, log nativi, edge case di device reali. Se quel passaggio rimane manuale, l’umano diventa il componente più lento (e costoso) del sistema.
La soluzione non è “promptare meglio”. È dare all’agente un feedback loop reale, cioè la capacità di osservare e misurare cosa succede davvero sull’app in esecuzione e correggersi di conseguenza.
Ogni workflow di sviluppo è un feedback loop
La Developer Experience, in fondo, è sempre stata questo:
- cambi qualcosa
- esegui
- osservi
- correggi
Tutti gli strumenti che consideriamo “DX” accorciano quel ciclo:
- sul web: DevTools, network panel, console, inspector
- su mobile: profiler e strumenti di piattaforma (Xcode Instruments, Android Studio Profiler)
- nel mondo React Native: devtools e plugin/estensioni per capire bundle, performance, rendering
Con gli agenti AI, però, cambiano due cose:
- il throughput di codice cresce (spesso più agenti in parallelo)
- la capacità di verifica umana non scala
Risultato: puoi aumentare all’infinito la velocità di generazione, ma il “done” resta vincolato al tempo necessario per verificare sul device.
Perché “dare all’agente un browser” non basta su mobile
Sul web, automatizzare la verifica è relativamente lineare: browser a portata di mano, strumenti maturi, interazioni basate su click e DOM.
Su mobile invece hai un set di complessità inevitabili:
- differenze tra simulatori/emulatori e device reali
- gesture (tap, swipe, scroll) invece di click
- dialog di permessi, alert, tastiere che cambiano layout e focus
- log distribuiti tra JavaScript e layer nativo
- vincoli di infrastruttura (iOS richiede macOS; CI macOS è più costosa e spesso più lenta)
Quindi il punto non è solo “controllare la UI”: è mettere l’agente nelle condizioni di operare in un ambiente mobile reale e raccogliere evidenza diagnostica.
Un approccio pragmatico: una CLI che dà accesso al device
L’idea più efficace è sorprendentemente semplice: invece di introdurre un framework pesante o un SDK da integrare, si può fornire agli agenti un set di comandi.
Questo è un dettaglio cruciale perché:
- gli agenti già vivono nel terminale
- una CLI è immediatamente scriptabile
- riduce drasticamente l’attrito di adozione (installi e inizi a usare)
Il feedback loop “hands-on” per un agente, in pratica, è fatto di pochi mattoni:
- Aprire l’app (iOS/Android, simulatore o device)
- Leggere lo stato della schermata (snapshot)
- Interagire con gesture reali (tap/scroll/swipe)
- Raccogliere evidenza (screenshot, log, video, trace)
- Replayare la sessione come script (utile anche come base per test E2E)
Quando questi passi sono automatizzabili, l’agente non “indovina” se qualcosa funziona: lo verifica.
Snapshot: perché la accessibility tree batte lo screenshot
Una decisione architetturale che fa la differenza è cosa far “vedere” all’agente.
L’opzione immediata è lo screenshot (computer vision). Funziona, ma porta con sé problemi noti:
- è più costoso (token/compute)
- è più lento
- è ambiguo: coordinate, overlay, elementi sovrapposti, interpretazioni
Un’alternativa migliore è una snapshot semantica basata su accessibility tree:
- descrive elementi interattivi e il loro significato (non la view hierarchy)
- permette azioni precise tramite riferimenti stabili agli elementi
- migliora l’affidabilità dell’automazione
C’è anche un effetto collaterale virtuoso: se la tua app è navigabile con screen reader, allora è anche più “operabile” dagli agenti. In pratica, l’automazione spinge verso una migliore accessibilità.
E c’è un altro punto spesso sottovalutato: il costo per singolo run può sembrare irrilevante, ma nel momento in cui vuoi moltiplicare il feedback loop per decine/centinaia di iterazioni (e magari in parallelo), efficienza e latenza diventano centrali.
Verifica autonoma: quando il “sembra ok” non basta
Un esempio tipico su React Native è la navigazione.
È facile ottenere una modifica che “compila”, non crasha e produce UI apparentemente coerente, ma che rompe il flusso reale: tap che non portano alla schermata attesa, stack non presente, gerarchie di navigator incomplete.
Il punto non è il bug specifico: è la dinamica.
- senza feedback loop sul device, l’agente tende a dichiarare concluso
- con un feedback loop, l’agente prova l’interazione, nota che il tap non produce l’effetto atteso, raccoglie evidenza e corregge
Questa è la differenza tra generazione di codice e lavoro software completo.
Quando la UI non basta: stato, React tree, log nativi e rete
Non tutti i problemi si vedono “da fuori”. A volte la schermata è corretta ma:
- lo stato è incoerente
- una prop non è quella attesa
- una richiesta di rete è lenta o fallisce
- una regressione di performance appare solo in condizioni reali
Per questo un feedback loop serio deve includere strumenti “under the hood”:
- ispezione della React tree (componenti, props, state)
- raccolta log lato device (anche nativi)
- osservazione traffico HTTP
- profiling di startup/memoria/CPU
- render profiling per individuare componenti lenti
Qui l’agente smette di essere un generatore di patch e diventa un debugger che lavora per evidenze.
QA che scala: dall’esecuzione locale alla CI
Se l’output di codice cresce verticalmente, l’unica verifica che può tenergli testa è quella che:
- gira senza l’umano in mezzo
- produce report e evidenze
- si aggancia al flusso PR/CI
Il modello naturale è un QA agent che:
- prende una diff
- lancia l’app
- esegue scenari
- registra video/screenshot/log
- commenta sul PR con risultati e prove
Dal punto di vista tecnico non serve “magia”: spesso basta un loop agente+tooling con accesso alla CLI che controlla device/simulatori.
Il nodo infrastrutturale: macOS
La parte spinosa è nota: iOS richiede macOS. Se la tua CI supporta runner macOS (o usi soluzioni dedicate), sei a posto.
Se invece i tuoi agenti girano in sandbox Linux (tipico per ambienti cloud leggeri), avviare macOS on-demand può essere troppo lento o troppo costoso.
Una via pratica è introdurre un proxy: l’agente resta nella sandbox Linux, ma i comandi vengono inoltrati a una macchina macOS “target” che esegue davvero le operazioni sul simulatore/device e rimanda indietro snapshot ed evidenze.
Sintesi: il vero salto è rendere verificabile ciò che l’agente produce
Se stai usando agenti AI per React Native, oggi il tuo limite non è quanto codice riesci a generare: è quanto rapidamente e con quanta fiducia riesci a validarlo su mobile.
Mettere in mano agli agenti un feedback loop completo — aprire l’app, capire cosa c’è a schermo in modo semantico, eseguire gesture, raccogliere log e profili, riprodurre sessioni — cambia la natura del lavoro:
- meno “manual QA” ripetitivo
- meno bug che arrivano tardi perché “in diff sembrava tutto ok”
- più iterazioni rapide, misurabili e automatizzabili
L’implicazione pratica è semplice: se vuoi che gli agenti facciano davvero lavoro mobile, devi trattare la verifica come una capability di prima classe, non come un passaggio che “tanto faccio io sul simulatore dopo”.
Articolo originale: https://frontendfacile.it/blog/dare-mani-agli-agenti-ai-feedback-loop-reali-su-mobile-con-una-cli