Il vero valore di un professionista del codice

01Perché pagare chi scrive codice, se il codice lo scrive anche una macchina?

È la domanda che oggi si fa chiunque debba commissionare un sito, un portale o un gestionale, ed è una domanda legittima. Gli strumenti di intelligenza artificiale scrivono in pochi secondi pagine di codice ordinato e commentato. I page builder promettono un sito professionale trascinando blocchi con il mouse. I marketplace offrono temi già pronti a poche decine di euro. Tutto vero.

Eppure i siti lenti, i portali bucati e i gestionali che nessuno riesce più a modificare non sono diminuiti: sono aumentati. Il motivo è semplice da dire e meno semplice da accettare. Scrivere codice non è mai stata la parte difficile del mestiere. La parte difficile è decidere quale codice serve, capire quello che c'è già, prevedere cosa succederà quando gli utenti saranno mille invece di dieci, e rispondere di quello che va online.

In questo capitolo smonto il confronto pezzo per pezzo: cosa fa davvero bene l'intelligenza artificiale, dove sbaglia senza avvisare, perché un sito assemblato con page builder e plugin costa più di quanto sembri, e come si riconosce un lavoro fatto a regola d'arte. Non per difendere una categoria, ma per darti gli strumenti per scegliere.

02L'intelligenza artificiale: un assistente formidabile

Partiamo da quello che va detto con onestà: gli assistenti di programmazione basati su intelligenza artificiale sono strumenti straordinari, e chi scrive software di mestiere oggi li usa. Fanno risparmiare ore su lavori ripetitivi, propongono soluzioni a cui non avevi pensato, spiegano in parole semplici un pezzo di codice scritto da altri dieci anni fa.

Ecco dove rendono di più:

• il lavoro di fatica: strutture ripetitive, conversioni di formato, elenchi di campi, test di base;
• la prima bozza: un punto di partenza da cui chi sa programmare toglie, corregge e completa;
• la spiegazione: «cosa fa questa funzione?», «perché questo errore?», domande a cui risponde spesso bene;
• la ricerca: trovare il nome di un concetto, una funzione di libreria, un'alternativa;
• la revisione: un secondo paio d'occhi che segnala qualcosa da ricontrollare.

In tutti questi casi c'è un elemento comune: qualcuno che sa giudicare il risultato. L'assistente propone; chi conosce il mestiere sceglie, scarta, verifica. Togli quella persona e lo strumento resta lo stesso, ma il risultato cambia natura.

03Dove l'IA sbaglia senza dirlo

Un modello linguistico genera il testo più probabile dato quello che gli hai chiesto. Non sa se il codice che scrive è sicuro: sa che somiglia a codice che ha visto. Per questo il suo errore più pericoloso non è il codice che non funziona, che si nota subito, ma il codice che funziona e fa anche altro.

L'OWASP, la fondazione internazionale che da vent'anni pubblica gli standard di riferimento sulla sicurezza delle applicazioni web, elenca fra i rischi dei modelli linguistici proprio la generazione di codice non sicuro e l'eccesso di fiducia: chi si affida al contenuto generato senza verificarlo. Ecco come si presentano, in concreto.

Prova a immaginarla così: un nipote volenteroso ti prepara in un pomeriggio, con l'aiuto dell'intelligenza artificiale, il modulo per le prenotazioni. Si apre, invia, arrivano le mail. Tutto perfetto, per mesi. Poi un giorno qualcuno scrive nel campo «cognome» qualcosa che cognome non è, e l'elenco dei tuoi clienti finisce dove non dovrebbe. Il modulo funzionava: faceva anche altro.

1. La query che apre il database a chiunque

Chiedi «una pagina che cerca i clienti per cognome» e ricevi qualcosa che funziona. Ma se il cognome scritto dall'utente viene incollato direttamente dentro la domanda al database, chiunque può scrivere al posto del cognome un pezzo di comando e farsi restituire l'intera tabella, o cancellarla. È la SQL injection, uno degli attacchi più antichi e ancora fra i più diffusi.

La prima difesa raccomandata dall'OWASP sono proprio le query parametrizzate (prepared statement). Un assistente le usa spesso, ma non sempre; e chi non sa riconoscere la differenza non se ne accorge finché qualcuno non ne approfitta.

2. Le chiavi segrete scritte nel codice

Per collegarsi a un servizio di pagamento, alla posta o al database servono password e chiavi. Il codice generato tende a scriverle direttamente nel file, perché così l'esempio funziona subito. Ma un file finisce in un archivio, in una copia di backup, in un repository condiviso: e la chiave con lui. Le linee guida dell'OWASP sulla gestione dei segreti dicono il contrario: le chiavi stanno fuori dal codice, in file di configurazione protetti o in servizi dedicati, e si possono cambiare senza toccare il programma.

3. Le librerie che non esistono

Succede anche questo: l'assistente suggerisce di installare un pacchetto con un nome plausibile che non è mai esistito. L'OWASP descrive lo scenario in cui qualcuno osserva quali nomi inventati vengono suggeriti più spesso, pubblica pacchetti malevoli con quei nomi e aspetta che vengano installati. Chi non controlla da dove arriva ogni libreria porta in casa, con un comando, codice scritto da sconosciuti.

4. Il caso felice e tutti gli altri

Il codice generato copre bene il percorso previsto: l'utente compila tutto, la rete funziona, il pagamento va a buon fine. Il software vero vive negli altri casi: il doppio clic sul pulsante «Paga», la connessione che cade a metà, due persone che prenotano lo stesso tavolo nello stesso secondo, il campo lasciato vuoto, il nome con l'apostrofo. Gestire le eccezioni è metà del lavoro, e l'assistente non lo fa se non glielo chiedi, e non sai chiederglielo se non lo sai.

5. Il contesto che nessuno gli ha dato

L'assistente non conosce il tuo database, il traffico che avrai, le regole del tuo settore, le norme sulla privacy, il gestionale con cui il sito deve parlare. Produce una soluzione generica per un problema che generico non è. Chi conosce il progetto sa cosa chiedere, cosa scartare e cosa manca.

04Page builder e plugin: il sito che pesa più di quanto mostra

Un page builder è un programma che permette di costruire le pagine trascinando blocchi: titoli, colonne, gallerie, pulsanti. È comodo e dà risultati immediati. Il prezzo si paga dopo, e lo paga chi visita il sito.

Il peso nascosto di ogni blocco

Per permetterti di trascinare qualsiasi cosa ovunque, il page builder deve prevedere tutto. Ogni elemento viene avvolto in più contenitori, ognuno con le sue classi e i suoi stili. Il risultato è una pagina con un numero enorme di elementi HTML (il cosiddetto DOM) e grandi fogli di stile e script caricati per intero anche quando la pagina ne usa una piccola parte.

Lighthouse, lo strumento di analisi di Google integrato in Chrome, segnala un avviso quando il corpo della pagina supera circa 800 elementi e un errore oltre circa 1.400. Più elementi significano più memoria, più calcoli di stile e impaginazione, risposte più lente ai tocchi: tutto quello che il browser deve fare prima di mostrarti la pagina e mentre la usi.

Il codice che si carica e non si usa

Oltre agli elementi, c'è il peso dei file. Un page builder carica i suoi fogli di stile e i suoi script per tutti i blocchi che offre, anche quelli che la pagina non usa: lo slider che non c'è, il carosello, l'animazione. Chrome stesso, nelle sue analisi, indica il CSS e il JavaScript inutilizzati come una delle prime cose da togliere per velocizzare una pagina. Più file e più grandi significano più attesa prima che la pagina sia leggibile, soprattutto su un telefono con una connessione normale. Come si misurano queste attese lo spiego nel capitolo sui Core Web Vitals.

Il plugin per ogni cosa

Il secondo problema arriva con i plugin: un modulo per il modulo contatti, uno per la cache, uno per la sicurezza, uno per il SEO, uno per i cookie, uno per la galleria, uno per le traduzioni. Venti, trenta, a volte di più. Ognuno è:

• codice scritto da altri, che gira sul tuo server con gli stessi permessi del sito;
• una cosa da aggiornare, spesso con un abbonamento annuale per le versioni commerciali;
• una possibile incompatibilità con gli altri, che si manifesta il giorno in cui uno si aggiorna e l'altro no;
• una porta in più: ogni vulnerabilità scoperta in un plugin diffuso riguarda tutti i siti che lo usano, finché non vengono aggiornati.

I numeri lo confermano. Secondo il rapporto annuale di Patchstack, società specializzata nella sicurezza di WordPress, nel 2025 sono state scoperte 11.334 nuove vulnerabilità nell'ecosistema WordPress: il 91% nei plugin, il 9% nei temi, e appena 6 nel core, tutte di bassa gravità. Il nucleo del sistema, curato da una comunità molto grande, è solido; il rischio sta in quello che gli si aggiunge. Ogni plugin installato «perché è comodo» è una scommessa sulla diligenza di chi lo mantiene.

05WordPress fatto bene: il core non si tocca

WordPress non è il problema. È un sistema solido, usato da una parte enorme del web, con una comunità che lo aggiorna con regolarità. Il problema è come viene usato. E qui c'è una regola che separa il professionista dal dilettante più di qualsiasi altra.

Il core di WordPress, cioè i file del sistema, non si modifica mai. La documentazione ufficiale lo dice esplicitamente: non è consigliato cambiare i file del core, a parte il file di configurazione. Il motivo è pratico: a ogni aggiornamento i file del sistema vengono sostituiti, e qualunque modifica fatta lì sparisce, oppure, peggio, impedisce di aggiornare e lascia il sito esposto alle falle che l'aggiornamento avrebbe chiuso.

Dove lavora allora un professionista

WordPress è progettato per essere esteso senza essere toccato, a strati:

• Il tema figlio eredita tutto dal tema principale e contiene solo le differenze. La documentazione di WordPress lo dice chiaramente: permette di aggiornare il tema genitore senza perdere le modifiche.
• I plugin su misura contengono le funzioni specifiche dell'attività, scritte per quel progetto, senza le mille opzioni di un prodotto commerciale pensato per tutti.
• Gli hook (azioni e filtri) sono i punti di aggancio previsti dal sistema: permettono di cambiare un comportamento senza riscrivere il file che lo contiene.

Così il sito si aggiorna con un clic, resta sicuro, e le personalizzazioni restano. Chi ti propone di «sistemare direttamente nel core» ti sta proponendo, senza dirtelo, un sito che non potrà più essere aggiornato.

Quando WordPress è la scelta giusta, e quando no

WordPress va benissimo quando serve pubblicare contenuti spesso, con più persone che scrivono, e le funzioni sono quelle tipiche di un sito editoriale. Diventa una forzatura quando lo si usa come base per un gestionale, un sistema di prenotazioni complesso o un portale con logiche proprie: lì si finisce a combattere contro lo strumento, aggiungendo plugin su plugin. In quei casi un'applicazione scritta su misura costa meno nel tempo.

06Cosa compra davvero un codice pulito

«Codice pulito» sembra un'espressione da addetti ai lavori. In realtà indica tre vantaggi molto concreti per chi possiede il sito o il software: sicurezza, capacità di crescere e visibilità su Google.

Sicurezza: meno codice, meno falle

Ogni riga di codice è un posto dove può nascondersi un errore. Un progetto essenziale, che contiene solo quello che serve, ha meno punti deboli di uno gonfiato da componenti generici. Un codice ordinato è anche un codice che si può controllare: se nessuno riesce a leggerlo, nessuno può dire se è sicuro.

Crescita: aggiungere senza riscrivere

Un'attività cambia: un servizio nuovo, una seconda sede, una lingua in più, un collegamento con il gestionale o con il commercialista. Con un software progettato bene, aggiungere una cosa non obbliga a riscriverne un'altra: c'è un punto previsto dove agganciarla. Con un software cresciuto per strati di toppe, ogni modifica ne rompe un'altra, e a un certo punto conviene ripartire da zero. È lì che il risparmio iniziale si trasforma nel costo più alto.

SEO tecnica: farsi leggere bene da Google

Google legge il codice della pagina prima di leggere i tuoi testi. Un codice pulito lo aiuta a capire:

• la struttura: un solo titolo principale, titoli di sezione in ordine, elenchi veri invece di righe formattate a mano;
• il significato: dati strutturati che dicono «questo è un articolo», «queste sono domande frequenti», «questo è l'indirizzo dell'attività»;
• la velocità: pagine leggere che rispondono in fretta, sul server e nel browser (ne parlo nel capitolo sull'infrastruttura e in quello sulla velocità);
• le lingue: le pagine tradotte dichiarate nel modo giusto, perché chi cerca in un'altra lingua trovi la pagina giusta. Ne parlo nel capitolo sul sito multilingue.

07Il costo vero: il conto a tre anni

Il confronto fra un professionista e il fai da te si fa quasi sempre sul prezzo iniziale. È il confronto sbagliato. Il costo di un sito o di un software si misura sugli anni in cui lo usi, sommando cose che all'inizio non si vedono.

08Come si riconosce un professionista del codice

Non serve saper programmare per capire se chi hai davanti lavora bene. Bastano alcune domande e l'attenzione alle risposte: un professionista risponde in modo concreto, ammette i limiti degli strumenti e parla prima del tuo problema che della sua tecnologia preferita.

1. «Cosa succede quando dovrò aggiungere una funzione?» La risposta buona indica dove si aggancerà, senza riscrivere il resto.
2. «Come proteggi i dati dei miei clienti?» Devono arrivare parole precise: connessione cifrata, query parametrizzate, password mai salvate in chiaro, backup fuori dal server.
3. «Quanti componenti di terzi userai, e chi li aggiorna?» Meglio pochi, scelti e con un responsabile.
4. «Il codice e il dominio di chi sono?» Tuoi, scritto nero su bianco.
5. «Usi l'intelligenza artificiale?» Non c'è niente di male se la risposta è sì: conta che dica chi controlla quello che produce.
6. «Mi fai vedere un lavoro e come è fatto dentro?» Chi lavora bene non ha paura di mostrare il codice.

Il valore di un codice scritto su misura si vede soprattutto quando il sito deve fare più che mostrare pagine: quando deve far prenotare, far entrare i clienti nella loro area, sincronizzarsi con un gestionale, funzionare anche sul telefono come un'app. È lì che un codice su misura consente di integrare in sicurezza un portale di prenotazione e una PWA, senza appoggiarsi a una pila di plugin che si contendono gli stessi dati. È l'argomento del prossimo capitolo: portali integrati, prenotazioni dirette e PWA.

Domande frequenti

Fonti

1. OWASP GenAI Security Project, «LLM09:2025 Misinformation»: generazione di codice non sicuro, librerie inesistenti suggerite dai modelli, eccesso di fiducia.
2. OWASP, «SQL Injection Prevention Cheat Sheet»: le query parametrizzate come prima difesa.
3. OWASP, «Secrets Management Cheat Sheet»: perché chiavi e password non stanno nel codice.
4. Chrome for Developers, «Avoid an excessive DOM size»: le soglie di circa 800 e 1.400 elementi usate da Lighthouse.
5. Chrome for Developers, «Remove unused CSS»: il costo dei fogli di stile caricati e non usati.
6. Patchstack, «State of WordPress Security in 2026»: le vulnerabilità scoperte nel 2025, divise fra plugin, temi e core.
7. WordPress Developer Resources, «Child Themes»: aggiornare il tema genitore senza perdere le modifiche.
8. WordPress Developer Resources, «Editing Files»: non è consigliato modificare i file del core oltre a wp-config.php.

Capitolo aggiornato a ottobre 2026. Gli esempi di codice e di struttura delle tavole sono semplificati per mostrare il principio; le soglie e le raccomandazioni citate vengono dalla documentazione ufficiale indicata.