AI per programmare: Cursor, Copilot e i loro limiti
Cosa fanno gli assistenti
Gli assistenti AI per il codice completano righe, propongono funzioni intere, spiegano errori e refactorano file aperti nel contesto del progetto. Leggono (in base alle impostazioni) repository locale, terminale e documentazione. Accelerano task ripetitivi: CSS responsive, test unitari boilerplate, migrazione API deprecate, commenti JSDoc. Non capiscono automaticamente tutte le convenzioni del tuo codebase se non gliele indichi e non eseguono test da soli salvo che tu configuri agenti con comandi espliciti.
Da ricordare
Ogni patch suggerita va letta come codice di un junior veloce: utile, ma possibile con bug, API inventate o buchi di sicurezza.
Cursor, Copilot e simili
GitHub Copilot si integra in IDE diffusi e completa in linea. Cursor è un editor con chat multi-file, agenti e regole progetto (.cursor/rules) utili su monorepo come un sito con builder PHP+JS. Esistono alternative (Windsurf, Codeium, assistenti in JetBrains). Scegli in base a policy aziendale su invio codice al cloud: vedi GDPR e AI se il repository contiene dati sensibili o segreti (che non dovrebbero mai essere nel repo).
Casi sul sito web
Adeguati: componenti UI isolati con test visivo; fix lint; estrarre funzione duplicata; aggiornare snippet GA4 documentato; scrivere script one-off per audit link rotti. Sconsigliati senza senior review: autenticazione, pagamenti, query SQL dinamiche, upload file, sanitizzazione HTML utente, permessi admin. Su Martini builder rispetta moduli ES in public/js/builder/ e contratti snapshot: non lasciare che l’AI inventi attributi data-component-id.
Limiti e rischi
Allucinazione di package npm inesistenti, versioni API sbagliate, pattern XSS (innerHTML con input utente), segreti hardcoded copiati da esempi online. Il modello può «sistemare» un bug introducendone due altrove. Per PHP legacy verifica la compatibilità con la versione del server. Combina con verifica risposte e fatti anche sul codice: esegui test, lint e prova manuale su staging prima di considerare chiuso il task.
Prompt per snippet sicuro
Stack: PHP 8.2, nessun framework. Scrivi una funzione che valida email
per form contatti: filter_var FILTER_VALIDATE_EMAIL, ritorna bool.
Nessun echo, nessun accesso DB, nessuna dipendenza esterna.
Aggiungi 3 casi PHPUnit in commento (valido, vuoto, dominio senza TLD).
Non usare eval o include dinamici.
Workflow consigliato
Usa un branch dedicato, diff piccoli, CI o script locale e code review umana su autenticazione e dati personali. Regole progetto che ripetono stack e cartelle vietate. Non incollare password o dump di database nella chat. Dopo il merge, fai smoke test su pagine account e API pubbliche.
Impara a rifiutare il completamento automatico su file che non hai aperto di proposito: accettare suggerimenti inline su codice non letto introduce diff silenziosi. Preferisci la chat con diff esplicito da approvare riga per riga sulle aree critiche. Quando l’assistente propone refactor ampi, chiedi di limitarsi al file aperto o al diff minimo: patch piccole sono più facili da revisionare e da annullare.
Regole progetto e contesto
In Cursor, file .cursor/rules o istruzioni workspace possono ripetere: versione PHP, cartelle modificabili, pattern di sicurezza (prepared statements, escape output). Più contesto pertinente fornisci, meno il modello propone framework alieni al repo. Apri i file correlati prima di chiedere un refactor: l’assistente legge ciò che è in editor o indicato con @file.
Per CSS del sito pubblico, chiedi modifiche localizzate con selettori esistenti invece di «riscrivi tutto il foglio». Per JavaScript builder, richiedi moduli ES e niente globali nuovi senza motivo. Quando il vendor dell’assistente propone refactor ampi, chiedi esplicitamente il diff minimo sul file che stai modificando: è più facile da revisionare e da annullare se qualcosa sfugge in produzione.
Documenta nel README interno quali cartelle sono off-limits per gli agenti automatici (config di produzione, chiavi, migrazioni DB non testate).
Staging e rollback
Ogni modifica suggerita dall’AI va provata su un clone di staging con dati anonimizzati. Dopo il deploy in produzione, tieni tag git o snapshot hosting per un rollback rapido se un completamento automatico ha rotto checkout o form. Non applicare patch da chat sul server live via FTP senza controllo di versione.
Per siti Martini o WordPress con plugin, disattiva temporaneamente la cache full-page mentre testi fix JS: altrimenti credi che il bug persista quando è solo HTML vecchio in CDN.
Errori comuni
- Accettare refactor massivi senza test.
- Fidarsi di librerie citate senza verificarle su packagist/npm.
- Inviare codice proprietario a servizi non approvati dal datore.
- Usare AI per «fix sicurezza» senza pentest o review mirata.
In breve
- Cursor e Copilot accelerano boilerplate e piccoli fix, non la responsabilità.
- Review obbligatoria su auth, pagamenti, SQL e input utente.
- Policy privacy sul codice inviato al cloud.
- Diff piccoli, test, staging prima della produzione.
- Rispetta convenzioni del progetto (builder, snapshot, moduli).
Questa pagina ti è stata utile?