Human in the loop
/ 3 min read
Updated:Table of Contents
Volevo monitorare l’evoluzione delle tariffe del mio gestore elettrico. In una situazione normale, avrei scritto un semplice script di scraping; questa volta, però, ho deciso di testare un approccio diverso: delegare il grosso del lavoro a un agente AI, limitando il mio intervento manuale al minimo indispensabile.
Il Framework: Human in the Loop
Spesso si pensa che basti un prompt ben scritto per ottenere un risultato perfetto. La realtà è che, sebbene l’AI sia eccellente nell’estrarre dati (come nel JSON d’esempio qui sotto), le criticità emergono quando il progetto deve evolvere, scalare o essere manutenuto.
Extract the data from the provided URL/HTML.Locate all [Items] and return a JSON array with [Title, Price, Description].Per evitare che il codice diventasse ingestibile, ho adottato un flusso Human in the Loop, dove l’essere umano agisce come architetto e supervisore, e l’AI come esecutore tecnico.
| Fase di sviluppo | Il ruolo dell’essere umano (Input/Direzione) | Il ruolo dell’AI (Esecutore/Supporto) |
|---|---|---|
| 1. Architecting | Definire gli obiettivi dell’app, selezionare lo stack tecnologico e delineare il flusso utente. | --- |
| 2. Prompting | Descrive la logica specifica della funzionalità da implementare. | Tradurre l’intento in blocchi di codice funzionali, rispettando le regole di sintassi e mantenendo la coerenza. |
| 3. Reviewing | Verifica la presenza di errori logici, falle di sicurezza o allucinazioni | Spiegazione dettagliata del funzionamento del codice e proposta di metodi alternativi per implementare la stessa logica. |
| 4. Testing | Eseguire il codice in un ambiente locale e identificare bug o casi limite mancanti. | Scrivere test unitari o test di integrazione basati sul codice esistente per garantire che tutto rimanga stabile. |
| 5. Debugging | Copiare e incollare i log degli errori del terminale o descrivere comportamenti “anomali” all’IA. | Analizzare i log, individuare la causa dell’arresto anomalo e scrivere una “patch” o una correzione per risolverlo. |
| 6. Refinement | Richiedere ottimizzazioni, come ad esempio “rendi questo più veloce” o “ripulisci questo codice per renderlo più leggibile”. | Ristrutturazione del codice per renderlo più efficiente, aggiunta di commenti e miglioramento delle prestazioni complessive. |
La vera chiave del successo sono stati due file strategici creati ancor prima di scrivere la prima riga di codice:
- AGENTS.md: Contiene le regole di stile e i tool permessi all’agente nella generazione del codice.
- ARCHITECTURE.md]: Esplicita la struttura del progetto e lo scopo di ogni cartella.
Il vantaggio? Questi file agiscono come dei “guardrail”. L’agente ha dei confini ben delineati e non cerca di prendere scorciatoie che potrebbero passare inosservate alla review umana.
Processo Iterativo: Dai prompt al risultato
Il progetto si è evoluto attraverso step incrementali, documentati nei branch del repository:
-
Bootstrap first-prompt: Ho ottenuto l’impalcatura iniziale. È stato necessario un intervento manuale quando l’agente si è incastrato in loop di test infiniti, producendo codice inefficiente.
-
Evoluzione add-query-filters: Ho sottomesso un secondo prompt per aggiungere filtri specifici agli endpoint. Grazie all’architettura chiara, l’integrazione è stata fluida.
-
Ottimizzazione add-cache: L’ultimo step ha riguardato l’implementazione del pattern Cache-Aside, delegando all’AI la logica di gestione della memoria cache.
Riflessioni Finali
L’efficienza è stata indiscutibile: le righe di codice scritte manualmente sono state esigue. Tuttavia, per convivere con gli agenti AI, servono regole ferree:
- L’AI come copilota, non pilota: Le allucinazioni sono sempre in agguato e l’agente non ha problemi a cambiare idea radicalmente se non guidato.
- L’importanza dei confini: Senza AGENTS.md e ARCHITECTURE.md, l’agente tende a deviare verso soluzioni meno eleganti.
La gestione dei test è stata la nota dolente. Pur essendo funzionanti, non sono organizzati in modo ottimale. Questo suggerisce la necessità di un terzo file di controllo TESTING.md che potrebbe essere aggiunto per delineare la struttura dei tests.