Il paradosso del coding agentico: spedisci in fretta, scali malissimo. Come salvare le performance della tua app.

L’era del coding agentico ha risolto il problema della pagina bianca, ma ne ha creato uno molto più insidioso: il codice “che funziona”.

Se usi tool come Cursor, GitHub Copilot Workspace o agenti autonomi come Devin per scrivere la tua web app, conosci già la sensazione. La velocità di delivery è decuplicata. Chiedi una feature, l’AI la sputa fuori, la compili, i test (forse) passano, fai commit.

Ma c’è un dettaglio fondamentale che gli LLM ignorano sistematicamente: le performance su scala e l’allocazione della memoria.

Gli agenti AI sono macchine statistiche addestrate per trovare la strada più breve verso un output che soddisfi il tuo prompt immediato. Questo significa che usano la forza bruta. Non possiedono un modello mentale dell’intera architettura. Non si curano della complessità ciclomatica (il famigerato Big O), non capiscono se un componente React sta renderizzando 40 volte di troppo, e non gli interessa se stanno fetchando mezzo database in memoria per filtrare un array di 10 elementi.

Se lasci il volante all’AI senza imporre filtri architetturali ferrei, la tua app diventerà lenta, il bundle size esploderà e i costi cloud andranno fuori controllo alla prima ondata di vero traffico.

Ecco cosa sbaglia l’AI e come evitare che il coding agentico uccida il tuo prodotto.

Perché gli LLM odiano l’efficienza

Prima di correggere l’AI, devi capire come ragiona. Un LLM scrive codice in modo autoregressivo: prevede il token successivo in base al contesto. Se gli chiedi “crea una dashboard utente”, cercherà il pattern più comune nei suoi dati di training per mostrare quei dati a schermo.

Il pattern più comune è raramente quello più ottimizzato. Ottimizzare richiede context awareness globale: sapere come il database è indicizzato, conoscere la latenza di rete e capire lo state management del frontend. L’AI vede solo il file attivo. Il risultato? Soluzioni miopi.

I 3 Killer Silenziosi del Codice Generato

Quando fai code review al lavoro di un agente o di un copilot, smetti di guardare se la feature fa quello che deve fare. Inizia a guardare come gestisce le risorse. Cerca e distruggi questi tre pattern.

1. Il massacro dei Re-render e lo Stato Globale (Frontend) In ecosistemi come React o Vue, gli LLM sono pessimi a gestire lo stato. La soluzione pigra dell’AI è quasi sempre infilare lo stato nel componente genitore più alto possibile e passarlo giù come prop-drilling. Peggio ancora, l’AI ama dichiarare funzioni anonime direttamente dentro il render, invalidando la cache dei componenti figli a ogni ciclo.

• Il disastro: Un utente digita in un input di ricerca e l’intera applicazione, header e footer compresi, si re-renderizza a ogni keystroke.
• Il fix: Imponi regole di state management a monte. Costringi l’AI nei prompt a usare state manager atomici (es. Jotai, Zustand) o a sfruttare i React Server Components (RSC) delegando il fetching al server. Esigi l’uso di useMemo per i calcoli pesanti sui dati derivati. Non fidarti mai dell’albero dei componenti generato al primo colpo.

2. Le Query N+1 e il Data Fetching pigro (Backend) Chiedi a un LLM di recuperare una lista di utenti e i loro post recenti. Nove volte su dieci, invece di scrivere una JOIN SQL efficiente o usare le relazioni corrette in un ORM come Prisma o Drizzle, l’AI farà una query per ottenere gli utenti, aprirà un loop (.map o for...of), e farà un’altra query al DB per ogni singolo utente per prendere i post.

• Il disastro: Funziona perfettamente in localhost con 5 utenti. In produzione, 100 utenti si traducono in 101 query simultanee al database. Il server si siede e i costi di I/O esplodono.
• Il fix: Definisci i pattern di accesso ai dati. Costringi l’AI a usare i Dataloader (per accorpare le richieste) o imponi nei prompt la scrittura di query relazionali esplicite. Un buon trucco è far generare all’AI l’SQL grezzo ottimizzato prima, e solo dopo chiedergli di tradurlo per l’ORM scelto.

3. L’obesità del Bundle Size e le Dipendenze Gli LLM amano importare librerie pesantissime per risolvere problemi banali che potresti risolvere con tre righe di JavaScript nativo. Ti serve formattare una data? L’AI è addestrata su miliardi di righe di codice legacy e ti importerà moment.js (pesantissimo e deprecato) invece di usare le API native Intl del browser. Ti serve un’icona? Importerà tutto framer-motion o una libreria UI intera per un singolo spinner.

• Il disastro: Il Time to Interactive (TTI) della tua web app schizza a 6 secondi su connessioni mobile. L’esperienza utente crolla.
• Il fix: Tolleranza zero. Vieta all’AI di aggiungere dipendenze al package.json senza permesso esplicito. Se suggerisce un pacchetto, il tuo primo prompt di risposta deve essere: “Puoi farlo usando solo le Web API native?”.

Da “Code Monkey” a “Performance Architect”

Il coding agentico non ti ruba il lavoro, lo evolve. Non sei più la persona che batte sui tasti; sei diventato un Performance Architect e un revisore inflessibile.

Per gestire questa transizione e scalare un software scritto a quattro mani con l’AI, devi spostare le barriere architettoniche dalla tua mente a regole hard-coded nel tuo ambiente di lavoro:

• Linting paranoico: ESLint e TypeScript base non bastano più. Configura regole estreme per le performance (es. eslint-plugin-react-compiler, warning rigidi sulle dipendenze inutilizzate, divieto di nested ternaries complessi). L’AI correggerà automaticamente i propri errori di performance se l’editor le urla contro.
• Automatizza i guardrail in CI/CD: Non affidare la memoria a una review umana distratta. Configura un bundle analyzer (come Bundlephobia o simili in GitHub Actions) che faccia fallire la build se il peso dell’app supera una certa soglia. Usa tool come Lighthouse CI per bloccare le merge request che degradano le performance frontend.
• L’architettura è un lavoro umano: Lascia all’AI la stesura della UI, le funzioni di utilità, i test unitari e il boilerplate. Ma la progettazione dello schema del database, l’infrastruttura di rete e il flusso globale dei dati devono essere decisi e blindati dalla tua testa.

L’AI è un motore potentissimo, capace di farti viaggiare a 300 all’ora. Ma se non costruisci tu i freni, le sospensioni e il telaio, ti schianterai semplicemente molto più veloce di prima. E il debito tecnico che raccoglierai col cucchiaino sarà interamente colpa tua