Automating Android Build Repair: Bridging the Reasoning-Execution Gap in LLM Agents with Domain-Specific Tools

1. Il Problema

Nonostante Android sia la piattaforma mobile più grande al mondo, la capacità di costruire (buildare) automaticamente le applicazioni rimane una sfida pratica significativa. Studi precedenti indicano che solo il 31,3% delle app può essere compilata con successo "out-of-the-box". Sebbene le pipeline CI/CD (Continuous Integration/Continuous Deployment) aiutino, la manutenzione degli script di build richiede uno sforzo enorme, con oltre il 74% delle modifiche alla configurazione CI/CD dedicate alla risoluzione di errori di build.

L'uso dei Modelli Linguistici di Grande Dimensione (LLM) per la riparazione automatica del codice (Automated Program Repair - APR) è promettente, ma la loro applicazione agli errori di build di Android è poco esplorata. I benchmark esistenti (come SWE-bench) si concentrano su bug logici o issue di GitHub, non sui fallimenti di compilazione transitori e specifici dell'ambiente tipici dello sviluppo Android. Inoltre, i dataset esistenti spesso catturano stati "rotti" senza fornire la soluzione corretta (ground truth), rendendo difficile la verifica.

2. Metodologia e Contributi Chiave

Gli autori propongono due contributi principali per colmare il divario tra la conoscenza di alto livello degli LLM e la loro esecuzione a basso livello:

A. AndroidBuildBench: Un Nuovo Benchmark

È stato creato un benchmark di 1.019 fallimenti di build riproducibili, curati dai commit history di 43 progetti open-source Android popolari.

• Verificabilità: Ogni fallimento è accoppiato con una soluzione verificata dal commit successivo, garantendo che il problema sia risolvibile.
• Categorizzazione degli errori: Il dataset include tre fonti di errori:
  1. Errori commessi da umani: Fallimenti transitori durante lo sviluppo (es. PR che non compilano prima di essere uniti).
  2. Errori di dipendenza aumentati: Simulazione di conflitti di configurazione revertando file di build (es. build.gradle).
  3. Errori generati da LLM: Codice generato da un LLM che fallisce la compilazione, con la soluzione umana come ground truth.
• Tipologie di errori: I fallimenti sono classificati in: Errori di Sintassi, File di Risorse Mancanti, Errori di Configurazione, Librerie Non Disponibili ed Errori NDK (quest'ultimi assenti nel dataset a causa del metodo di curazione basato su build di successo).

B. GradleFixer e la Strategia "Tool Bridging"

È stato sviluppato GradleFixer, un agente basato su LLM che utilizza strumenti specifici di dominio invece di un generico shell.

• Il Concetto di Tool Bridging: Gli autori ipotizzano che gli LLM possiedano la conoscenza di alto livello per risolvere gli errori, ma falliscano nel tradurla in una sequenza corretta di comandi shell complessi.
• Implementazione: Invece di dare all'agente un accesso completo al terminale (shell generico), sono stati forniti wrapper specifici per l'ambiente Gradle:
  • run_build: Esegue ./gradlew assembleDebug.
  • run_gradle: Esegue comandi Gradle generici.
  • change_java_version: Gestisce le variabili d'ambiente per le versioni JDK.
• Obiettivo: Questi strumenti agiscono come un'API, riducendo lo spazio delle azioni (action space) e fornendo un formato che gli LLM possono utilizzare in modo più affidabile, colmando il divario tra ragionamento ed esecuzione.

3. Risultati Sperimentali

Gli esperimenti sono stati condotti su un set di test di 184 istanze, utilizzando modelli come Gemini-2.5-Pro e GPT-5-Mini.

• Prestazioni Superiori: GradleFixer ha raggiunto un tasso di risoluzione (Pass@1) dell'81,4%, superando significativamente tutte le baseline, inclusi agenti di codifica avanzati e versioni di Gemini-CLI che utilizzano uno shell generico (che ha ottenuto un 65,1% o meno).
• Impatto degli Strumenti Specifici:
  • L'uso di strumenti specifici di dominio ha portato a miglioramenti drastici rispetto all'uso dello shell puro.
  • È stato osservato che strumenti più specifici (es. run_build) funzionano meglio di strumenti più generici (es. run_gradle), che a loro volta sono migliori dello shell completo. Questo suggerisce che la constrizione dello spazio delle azioni è fondamentale per il successo.
  • La strategia "Tool Bridging" ha funzionato meglio anche rispetto a prompting avanzati che istruivano l'agente su come usare lo shell.
• Efficienza dei Modelli e Costi:
  • Un modello più piccolo ed economico (Gemini-2.5-Flash) dotato degli strumenti specifici di GradleFixer ha superato un modello più grande e costoso (Gemini-2.5-Pro) che utilizzava lo shell generico.
  • Gli agenti che falliscono meno spesso consumano meno token (poiché evitano cicli di tentativi falliti), rendendo la soluzione più economica.
• Analisi dei Fallimenti: I fallimenti residui sono correlati principalmente alla magnitudine delle modifiche al codice (numero di righe/file cambiati) piuttosto che alla categoria dell'errore. Modifiche molto grandi tendono a introdurre errori composti che sono difficili da risolvere iterativamente.

4. Significato e Conclusioni

Il paper dimostra empiricamente che per compiti complessi e specifici di dominio come la riparazione di build Android, l'architettura degli strumenti è più critica della sola capacità del modello.

• Superamento del divario Ragionamento-Esecuzione: La strategia "Tool Bridging" risolve il problema per cui gli LLM sanno cosa fare ma non riescono a eseguirlo correttamente con comandi shell grezzi.
• Generalizzabilità: Sebbene testato su Android, il principio di sostituire shell generici con astrazioni API-like specifiche di dominio sembra essere un pattern di design generale per costruire agenti LLM più capaci.
• Implicazioni Future: Questo approccio apre la strada a modelli più piccoli e specializzati che, se combinati con strumenti di dominio appropriati, possono superare modelli generalisti più grandi in termini di efficacia e costo. Inoltre, l'automazione della riparazione delle build potrebbe abbassare le barriere all'ingresso per lo sviluppo Android, permettendo stili di programmazione più fluidi e sperimentali.

In sintesi, il lavoro sottolinea che per gli agenti AI, fornire il "set di strumenti giusto" (specifico per il dominio) è essenziale quanto fornire il "cervello giusto" (il modello linguistico).