Dalla prompt “chiedi e incolla” all’agente che modifica file, esegue test e itera: tecniche pratiche per qualità, sicurezza e manutenzione del codice.
Negli ultimi anni siamo passati da “cerco una risposta” a “mi faccio generare uno snippet”. Il passo successivo è più radicale: l’agentic coding. Qui l’AI non si limita a suggerire righe di codice, ma lavora dentro il workflow di sviluppo: legge la codebase, modifica più file, esegue comandi e test, e soprattutto itera finché il risultato non torna.
Questa autonomia è potente, ma non “magica”: senza una guida precisa rischi di ottenere codice fragile, duplicato, difficile da mantenere o—peggio—comportamenti insicuri (segreti esposti, dati sensibili finiti dove non devono, permessi troppo larghi). L’obiettivo quindi non è delegare tutto, ma chiudere il loop tra scrittura e verifica mantenendo l’umano al centro.
Di seguito trovi un set di pratiche concrete per usare agenti tipo Codex (e strumenti equivalenti) in modo affidabile, soprattutto in contesti frontend.
Cos’è davvero l’agentic coding
Un agente “agentic” è un sistema che:
- prende decisioni durante l’esecuzione (non solo risponde a una domanda);
- agisce: apre file, scrive patch, lancia comandi, installa dipendenze, aggiorna configurazioni;
- valuta l’esito (test, lint, build, output runtime);
- ripete il ciclo finché non raggiunge un risultato accettabile.
È il passaggio da “generazione” a “sviluppo assistito end-to-end”: non chiedi un pezzo di codice, chiedi un task completato.
Questo non rende lo sviluppatore superfluo. Al contrario: più autonomia dai a un agente, più diventano fondamentali criteri, vincoli e verifiche.
Formati di agenti: CLI, IDE, desktop/web
Oggi gli agenti di coding si presentano tipicamente in tre modalità (spesso lo stesso agente è disponibile in più forme):
- CLI (terminal-based): ottima per chi vive in shell, script e pipeline.
- IDE-based (es. estensioni): ideale per frontend perché resta tutto “vicino al codice”, con feedback visivo.
- Desktop/Web-based: abbassa la barriera d’ingresso, ma può nascondere dettagli importanti del workflow.
Per molti team frontend, la combinazione migliore è: agente nell’editor + Git + test come guardrail.
Primo guardrail: controlla sempre i diff
Una delle abilità più importanti quando lavori con un agente non è “scrivere prompt perfetti”: è revisionare cambiamenti.
Ogni volta che l’agente modifica file, guarda i diff (le differenze):
- cosa è stato aggiunto;
- cosa è stato rimosso;
- dove è intervenuto (file giusto? punto giusto?);
- se ha introdotto duplicazioni, workaround o hack.
Anche quando l’output “funziona”, il diff ti dice se stai accumulando debito tecnico.
Il problema più comune: l’agente preferisce aggiungere codice invece di rifattorizzare
Un classico: chiedi “aggiungi un secondo pulsante che fa X”, e l’agente spesso:
- copia e incolla la logica esistente;
- crea due handler quasi identici;
- moltiplica variabili e condizioni.
Risultato: UI ok, ma codice non DRY, difficile da estendere e facile da rompere.
La soluzione non è solo “chiedere meglio”, ma chiedere qualità, non solo outcome.
Prompting che scala: Task → Contesto → Output
Quando i risultati sono mediocri, quasi sempre c’è un denominatore comune: ambiguità.
Riducila esplicitando tre elementi:
1) Task (cosa deve fare)
Esempio: “Aggiungi un secondo pulsante per loggare i pacchi persi.”
2) Contesto (dove deve guardare e quali vincoli deve rispettare)
Esempi utili:
- “Usa la logica condivisa esistente invece di duplicarla.”
- “Evita di duplicare event listener e handler.”
- “Modifica solo
index.htmlescript.js.”
3) Output (come deve apparire il risultato, anche in termini di qualità)
Esempi:
- “Mantieni il codice DRY.”
- “Struttura in modo estendibile per aggiungere altri tipi di log in futuro.”
- “Niente dipendenze aggiuntive.”
Questa struttura sembra banale, ma cambia il tipo di soluzione che l’agente “ritiene accettabile”.
Promptare per qualità del codice (non solo per UI)
Nel frontend è facile cadere nella trappola:
“Voglio vedere la sezione sotto l’hero”
Funziona, certo. Ma se non specifichi anche obiettivi di manutenzione, potresti ritrovarti:
- CSS duplicato;
- classi incoerenti;
- markup non semantico;
- logica JS ripetuta;
- naming casuale.
Inserire nel prompt frasi come “mantieni coerente lo stile esistente”, “riusa componenti/classi”, “evita duplicazioni” è spesso la differenza tra “va” e “sta in piedi tra 3 mesi”.
“Mostra, non raccontare”: usa funzioni modello e comment prompt
Un’altra leva potente: gli agenti tendono a essere ottimi nell’imitazione.
Se tieni a stile e pattern (async/await, naming, gestione errori, struttura dei moduli), spesso è più veloce:
- indicare una funzione modello già presente nel codice;
- chiedere di rifattorizzare una funzione simile “seguendo lo stesso stile”.
Esempio pratico
Hai due funzioni che fanno fetch:
- una usa
async/await(stile desiderato); - l’altra usa
.then()(stile legacy).
Invece di spiegare nel prompt differenze e dettagli, puoi:
- mettere un commento vicino alla funzione modello:
// Model function - sopra la funzione da cambiare inserire un commento tipo:
// TODO(AI): rifattorizza questa funzione per seguire lo stesso stile della Model function (async/await, gestione errori coerente)
Questo approccio riduce ambiguità e “negoziazione”: il codice desiderato è già lì.
Il ruolo del developer: autonomia sì, delega cieca no
Un agente può:
- implementare feature;
- rifattorizzare;
- aggiornare test;
- far girare comandi;
- iterare.
Ma il developer deve restare responsabile di:
- definire i vincoli (qualità, performance, sicurezza, stile);
- verificare (diff, test, lint, behavior);
- decidere trade-off (architettura, debito, tempi).
Gli agenti sono strumenti complessi: possono produrre codice eccellente o codebase ingestibili. La differenza la fa quasi sempre la tua capacità di guidarli con contesto, criteri e verifica.
Sintesi operativa
Se vuoi integrare seriamente l’agentic coding nel workflow frontend:
- Revisione prima di tutto: leggi i diff di ogni modifica.
- Prompt strutturati: Task → Contesto → Output.
- Chiedi qualità: DRY, estendibilità, coerenza stilistica, niente duplicazioni.
- Usa modelli: quando lo stile conta, “mostra” una funzione buona e fai imitare quella.
- Chiudi il loop con verifica: test, lint e build come guardrail.
Usati così, gli agenti diventano un moltiplicatore: riducono lavoro meccanico e accelerano iterazione, ma senza trasformare la codebase in un collage di patch scollegate. La promessa dell’agentic coding non è scrivere codice al posto tuo: è aiutarti a consegnare software migliore, più velocemente, con controlli più stretti.
Articolo originale: https://frontendfacile.it/blog/agentic-coding-con-codex-e-simili-come-ottenere-risultati-affidabili-senza-perde
Top comments (0)