Ho descritto a un'intelligenza artificiale quello che volevo e in mezz'ora avevo il sito pronto. Perché dovrei pagare qualcuno per farlo?
È una domanda che ci sentiamo rivolgere sempre più spesso, e non è una domanda ingenua perché parte da un'osservazione vera: oggi una persona senza competenze di programmazione può descrivere ciò che desidera e vedere comparire un sito, una landing page, in certi casi perfino un'applicazione funzionante.
Se dicessimo che «con l'AI non puoi farti il sito da solo» sarebbe falso.
Noi di IKIweb usiamo quotidianamente strumenti di intelligenza artificiale nello sviluppo: funzionano, e molto bene. Il punto è più sottile. Ottenere qualcosa che sembra funzionare non equivale ad aver realizzato un prodotto affidabile, sicuro, performante e adatto a un uso professionale.
Quindi la domanda giusta non è «l'AI può creare un sito?». Le domande giuste sono altre. Che cosa dobbiamo realizzare, e per quale scopo? Quali dati dovrà gestire? Quanto è importante per l'attività? Che cosa succede se si rompe, o se qualcuno accede a informazioni che non dovrebbe vedere? E soprattutto: chi verifica che ciò che è stato generato sia davvero pronto per essere usato?
Fino a ieri servivano decine di competenze, oggi basta formulare una frase
Fino a pochi anni fa realizzare da soli un'applicazione web significava conoscere un linguaggio di programmazione, capire come funziona un database, configurare un server o almeno un hosting, gestire domini e certificati, strutturare una pagina HTML, mettere in sicurezza un modulo di contatto. Per chi non veniva dal settore era una barriera altissima.
Oggi la stessa persona può scrivere a uno strumento di AI generativa: «Realizza un sito per la mia azienda con un'area clienti in cui ogni utente possa fare login e scaricare le proprie fatture». In poco tempo ottiene delle pagine, una schermata di accesso, una tabella di documenti, magari uno stile grafico gradevole.
È una trasformazione reale e in larga parte positiva: ha permesso a moltissime persone di costruire cose che prima non avrebbero mai potuto costruire e ha reso molto più rapido il lavoro di chi programma da anni.
C'è però un effetto collaterale di cui vale la pena essere consapevoli. La facilità con cui si ottiene un risultato trasmette una sensazione precisa: che la cosa richiesta fosse, in fondo, semplice.
Ma quella sensazione riguarda lo sforzo che abbiamo fatto noi, non la complessità di ciò che abbiamo ottenuto. La complessità è rimasta identica: è solo diventata invisibile.
Da qui la questione centrale: quel risultato che sembra completo e che, provandolo, sembra funzionare, è già un software da mettere in produzione? Spesso no, ma la parte difficile è rendersene conto.
Che cos'è il Vibe Coding (e che cosa non è)
Il termine Vibe Coding descrive un modo di sviluppare che fino a poco tempo fa non esisteva: si descrive all'AI il risultato voluto, l'AI produce o modifica il codice, si prova, si segnala ciò che non va, l'AI interviene di nuovo, e si prosegue finché il risultato sembra soddisfacente.
La parola chiave è "sembra". Il criterio di accettazione è la sensazione che il risultato vada bene: si guarda, si prova, e se il comportamento corrisponde a quello atteso si passa oltre. Da qui il nome.
È un metodo potente, perché sposta il baricentro dalla scrittura del codice alla descrizione dell'obiettivo: chi ha un'idea non deve più tradurla in istruzioni tecniche, può esprimerla nel proprio linguaggio e vederla prendere forma.
Conviene però fissare subito una distinzione che nel dibattito pubblico viene confusa continuamente: Vibe Coding non è sinonimo di "usare l'AI per programmare".
Uno sviluppatore professionista può usare l'intelligenza artificiale in modo massiccio — e molti la usano per la maggior parte del codice che scrivono — senza fare Vibe Coding. Chi realizza siti web in modo professionale non lo fa con il Vibe Coding.
La differenza non sta nella quantità di AI impiegata, ma nel fatto che quello sviluppatore di professione legge il codice generato, capisce che cosa fa, sa perché una soluzione è stata scelta al posto di un'altra e ha gli strumenti per accorgersi quando la risposta dell'AI è sbagliata pur sembrando convincente.
Il Vibe Coding in senso stretto è invece l'approccio in cui il codice non viene compreso, ma solo accettato in base al comportamento osservato. Non è una critica: è un dato di fatto che cambia radicalmente il tipo di garanzie che si possono avere sul risultato.
Perché il Vibe Coding è una cosa buona
Prima dei limiti, i vantaggi: concreti e notevoli.
La velocità di prototipazione è il più evidente. Un'idea che prima richiedeva settimane di lavoro solo per essere mostrata a qualcuno oggi diventa cliccabile in poche ore. Invece di discutere un progetto in astratto, lo si prova.
Da qui il secondo vantaggio, forse più importante per un imprenditore: verificare un'idea prima di investirci sopra. Costruire una versione grezza di un servizio, mostrarla a cinque clienti e scoprire che non interessa a nessuno è un risultato prezioso, ottenuto a costo bassissimo. Sono le logiche del proof of concept e dell'MVP — la prima versione minima di un prodotto, fatta per capire se ha senso proseguire — rese accessibili a chiunque.
C'è poi lo sviluppo di strumenti personali o a esclusivo uso interno: il piccolo gestionale per tenere traccia di qualcosa, lo script che riordina dei file, l'automazione che risparmia mezz'ora al giorno. Cose che nessuno avrebbe mai commissionato a un fornitore esterno, perché non ne valeva il costo, e che oggi si possono semplicemente fare.
E infine l'aumento di produttività di chi sviluppa per mestiere: il tempo dedicato alla scrittura materiale di codice ripetitivo si è ridotto in modo sostanziale, e quel tempo si può reinvestire su analisi, architettura e verifica.
Il Vibe Coding, quindi, non è un problema. Il problema nasce quando lo si usa nel contesto sbagliato, o quando si attribuisce al risultato un'affidabilità che non ha.
«Funziona» e «è fatto bene» sono cose diverse
Ecco il nodo centrale, con un esempio che useremo come filo conduttore: un'azienda decide di creare da sola un'area clienti online in cui ogni cliente possa accedere e scaricare le proprie fatture. Chi l'ha generata la prova, come è naturale. Apre la pagina: funziona. Fa il login: funziona. Inserisce un cliente: funziona. Scarica un PDF: funziona. La conclusione è ovvia e ragionevole: è pronta per andare online.
Conclusione sbagliata.
Quella prova ha verificato solo il percorso previsto: l'utente giusto, con i dati giusti, che fa le cose nell'ordine giusto. In gergo si chiama happy path, il "percorso felice". È il percorso che l'AI ha costruito con precisione, perché è esattamente quello che le è stato descritto.
Un professionista, davanti allo stesso software, si pone altre domande. Che cosa succede se un campo obbligatorio arriva vuoto, o contiene un testo lunghissimo, o caratteri strani? Se l'utente clicca due volte su "conferma" e la richiesta parte due volte, si creano due ordini identici? Se il database non risponde per qualche secondo, o un servizio esterno va offline, l'applicazione mostra un errore comprensibile, resta bloccata su una pagina bianca o stampa a video informazioni sensibili sul codice? Che cosa succede quando gli utenti collegati non sono uno ma trecento? E soprattutto: che cosa succede se qualcuno prova deliberatamente a usare il sistema in un modo diverso da quello previsto?
Sono gli edge case: casi limite, ma tutt'altro che teorici. Capitano continuamente, perché gli utenti sbagliano, le connessioni cadono, i servizi esterni hanno disservizi e qualcuno, prima o poi, prova a curiosare.
In una frase: l'AI è molto brava a costruire il percorso che le abbiamo descritto, ma i problemi si annidano nei percorsi che non abbiamo pensato di descriverle.
Non puoi evitare un problema se nemmeno sai che esiste
Il problema non è che l'intelligenza artificiale scriva codice scadente: gli strumenti attuali producono spesso codice di buona qualità, in molti casi migliore di quello che scriverebbe uno sviluppatore poco esperto.
Il problema è un altro: chi non ha competenze tecniche non ha modo di stabilire se l'AI abbia programmato bene.
La conseguenza è pratica. Si può imparare a scrivere prompt eccellenti — è una competenza reale e utile — ma non si può chiedere all'AI qualcosa di cui si ignora completamente l'esistenza. Se non so che un problema esiste, non chiederò mai che venga verificato e risolto, e nella maggior parte dei casi non mi verrà segnalato spontaneamente.
Torniamo all'area clienti. La richiesta iniziale era una riga: «ogni utente fa il login e scarica le proprie fatture». Ma proviamo a srotolare cosa contiene davvero questa frase.
Contiene l'autenticazione, cioè verificare che chi entra sia chi dice di essere. Le autorizzazioni, che sono una cosa diversa: stabilito che sei entrato, che cosa hai il diritto di vedere? La gestione delle sessioni: per quanto tempo resti collegato, che cosa succede quando chiudi il browser, che cosa succede se qualcuno riesce a impossessarsi della tua sessione. Il recupero della password, una delle funzionalità apparentemente più banali e concretamente più delicate di qualunque applicazione.
E contiene la protezione dei documenti, l'esempio che rende tutto tangibile: le fatture in PDF vengono caricate da qualche parte sul server. Se quel "da qualche parte" è una cartella pubblica e il nome del file è prevedibile — poniamo fattura-2026-0042.pdf — chiunque conosca l'indirizzo può scaricarlo senza aver mai fatto login. L'applicazione continua a funzionare perfettamente: nessun messaggio di errore, nessun malfunzionamento visibile. Semplicemente, i documenti di tutti sono accessibili a tutti. È tra i problemi più comuni in assoluto, e non emerge in alcun modo dalla prova «faccio login e scarico la mia fattura».
E ancora: la gestione degli errori; il logging, cioè la registrazione di ciò che accade, indispensabile quando qualcosa va storto e bisogna capire perché; i backup e — cosa che si scopre sempre troppo tardi — la prova che si riescano davvero a ripristinare; gli obblighi in materia di dati personali; il comportamento su smartphone; l'accessibilità; la gestione degli account bloccati o cancellati; la sicurezza delle API usate per collegarsi al gestionale.
Nessuno di questi aspetti compare nella frase iniziale. Perché per scriverli bisogna sapere che esistono. Il tema, quindi, non è ottenere una buona risposta dall'AI. È sapere quali domande porre e quali aspetti verificare.
La sicurezza è il difetto che non si vede quasi mai
Vale la pena renderlo esplicito, perché è controintuitivo per chi non lavora nel settore.
Quasi tutti i difetti di un software si manifestano: qualcosa non si carica, un pulsante non risponde, un calcolo restituisce un numero sbagliato. Sono fastidiosi, ma almeno si vedono, e chi li vede può correggerli.
I problemi di sicurezza, invece, quasi sempre, non si vedono.
Un'applicazione vulnerabile funziona benissimo. Anzi, spesso funziona meglio di una scritta con attenzione, perché i controlli che rendono un sistema robusto sono anche piccoli attriti che rallentano il percorso normale. Un'applicazione che non verifica nulla è più veloce e più immediata da usare. Fino al giorno in cui qualcuno se ne accorge.
Gli ambiti sono sempre gli stessi. L'autenticazione, quando si possono provare migliaia di password una dopo l'altra senza che il sistema rallenti o se ne accorga. Le autorizzazioni, quando l'applicazione controlla che tu sia entrato ma non che quel dato specifico sia tuo. Le password, quando sono conservate in modo inadeguato (in un database ben fatto non sono leggibili nemmeno da chi ha accesso al database). Le sessioni, quando restano valide troppo a lungo o non vengono invalidate al logout.
Poi ci sono gli ingressi da cui arrivano i dati. Tutto ciò che un utente scrive in un modulo può contenere qualcosa di diverso da quello che ci si aspetta, e se quel contenuto arriva al database o torna in pagina senza le dovute precauzioni può produrre effetti che nessuno aveva previsto. Il caricamento di file è particolarmente delicato: consentire un allegato significa consentire a un estraneo di depositare un file sul proprio server, e occorre stabilire con precisione che cosa può essere caricato, dove finisce e chi potrà leggerlo. Le API, i canali attraverso cui due sistemi si parlano, sono porte a tutti gli effetti: se restano aperte senza controllo, chiunque le trovi può usarle.
Infine le credenziali e le chiavi dei servizi esterni — database, invio email, gateway di pagamento. Finiscono con sorprendente frequenza scritte direttamente dentro il codice, e da lì magari in un repository accessibile, dove restano finché qualcuno non le trova.
Tutto questo solo per rimarcare un concetto fondamentale: «l'ho provato e funziona» non è sufficiente per considerare un prodotto digitale sicuro e pronto all'uso.
Un software deve funzionare oggi e anche domani
C'è un'altra dimensione che sfugge a chi non programma di mestiere: il software non è un oggetto finito, è qualcosa che vive nel tempo.
Le librerie e i componenti su cui si appoggia vengono aggiornati, e alcuni di quegli aggiornamenti servono proprio a chiudere falle di sicurezza scoperte nel frattempo. I browser cambiano. I servizi esterni modificano le loro interfacce. Le normative si evolvono. Le esigenze dell'azienda anche più in fretta.
Un software professionale mette in conto tutto questo. Prevede che i dati vengano salvati con regolarità e che qualcuno abbia verificato almeno una volta di saperli ripristinare davvero. Prevede un minimo di monitoraggio, perché se qualcosa si ferma alle tre di notte non deve essere il cliente a scoprirlo la mattina dopo. Prevede che gli eventi importanti lascino una traccia, senza la quale le anomalie diventano quasi impossibili da ricostruire. E prevede un codice leggibile e ordinato, perché tra un anno qualcuno — magari l'AI stessa, magari un'altra persona — dovrà metterci mano.
Il castello di modifiche
C'è un fenomeno tipico di chi lavora esclusivamente per prompt, e chiunque abbia provato lo riconoscerà.
Si chiede una funzionalità e arriva. Provandola emerge un problema. Si chiede all'AI di correggerlo, e viene corretto. Ma la correzione ne fa emergere un altro, magari in un punto apparentemente scollegato. Si chiede una nuova modifica. Poi un'altra. Ogni passaggio ha una sua logica, e a ogni passaggio l'applicazione continua a sembrare funzionante.
Nel frattempo la struttura interna si è stratificata: pezzi di codice che fanno la stessa cosa in punti diversi, controlli aggiunti per tamponare, logiche che si sovrappongono. Il sistema regge, ma è diventato fragile in modo invisibile dall'esterno. Arriva il momento in cui una richiesta minima — «aggiungiamo un campo alla scheda cliente» — ne rompe altre tre, e nessuno riesce più a capire perché.
Non è un difetto dell'AI: è ciò che accade a qualsiasi software che cresce per aggiunte successive senza che nessuno si occupi della struttura complessiva. La differenza è che uno sviluppatore se ne accorge, e a un certo punto si ferma e riordina. Chi non legge il codice non può accorgersene, perché dall'esterno tutto continua a sembrare a posto.
Venti record in prova, cinquantamila in produzione
Anche sulle prestazioni la prova sul campo inganna, per un motivo molto semplice: la fa una persona sola, su pochissimi dati.
Un'applicazione con venti clienti di prova nel database è velocissima: qualunque cosa faccia, la fa istantaneamente. È il momento in cui si conclude, in buona fede, che sia veloce.
La stessa identica applicazione può comportarsi in modo molto diverso con cinquantamila prodotti a catalogo, con migliaia di clienti che hanno ciascuno anni di documenti alle spalle, con centinaia di persone collegate contemporaneamente il giorno del lancio della promozione, con migliaia di immagini ad alta risoluzione da caricare, o quando dipende da un servizio esterno che risponde in un secondo anziché in un decimo.
La ragione è che molte soluzioni perfettamente corrette su piccoli numeri diventano inefficienti su grandi numeri. Una richiesta al database ripetuta per ogni elemento della lista è irrilevante su venti elementi e diventa un problema serio su cinquantamila. Un'immagine da otto megabyte non si nota su una connessione in fibra e rende il sito inutilizzabile su uno smartphone con copertura mediocre.
Progettare per le condizioni reali significa sapere in anticipo quanti dati ci saranno, quanti utenti, quando si concentreranno i picchi, e fare scelte tecniche coerenti. Sono domande a cui rispondere prima, perché intervenire dopo, quando la struttura è già impostata, costa molto di più.
Bello non vuol dire facile da usare
Gli strumenti di AI generano interfacce visivamente gradevoli, spesso più curate di quanto ci si aspetterebbe. Ed è inutile sostenere che l'AI "non veda" il risultato: gli strumenti attuali possono aprire il browser, produrre screenshot e valutare visivamente ciò che hanno costruito.
Il punto è diverso: generare un'interfaccia non equivale a progettare un'esperienza d'uso efficace.
Una buona esperienza utente nasce da informazioni che stanno fuori dallo schermo. Chi userà questo sito? Che cosa sta cercando di ottenere, concretamente? Quali informazioni gli servono subito e quali può trovare dopo? Da quale dispositivo arriva, e in quale contesto — seduto alla scrivania o in piedi in magazzino con una mano occupata? In quale punto rischia di bloccarsi o di rinunciare? Quali azioni contano davvero per il business, e sono abbastanza visibili? E quando sbaglia, il sistema gli spiega che cosa è successo e come rimediare, o gli mostra un messaggio che non significa nulla per lui?
Un modulo di richiesta preventivo con quattordici campi è graficamente ineccepibile e commercialmente disastroso. Un'area clienti con le fatture ordinate per codice interno anziché per data è perfettamente funzionante e irritante da usare tutti i mesi. Nessuno dei due è un errore tecnico: sono decisioni progettuali, e dipendono da una conoscenza del contesto che l'AI ha solo se qualcuno gliela fornisce.
Essere online non significa essere trovati
Un sito generato con l'AI può essere tecnicamente corretto e restare, di fatto, invisibile sui motori di ricerca.
Il posizionamento sui motori di ricerca dipende infatti da scelte che iniziano prima ancora di scrivere il codice. Conta la struttura del sito: quali pagine esistono, come sono organizzate e collegate tra loro, quali argomenti affrontano e con quale gerarchia. Contano poi aspetti tecnici come la corretta struttura HTML, i title, i collegamenti interni, la gestione dell'indicizzazione e le prestazioni.
Ma la parte più difficile della SEO viene ancora prima: capire che cosa cercano davvero le persone che potrebbero diventare clienti, quali parole utilizzano, quali domande si pongono e che cosa offre già chi occupa le prime posizioni. Significa comprendere il mercato e tradurlo nella struttura e nei contenuti del sito.
L'AI può essere un ottimo strumento anche per questo lavoro, ma deve ricevere il contesto e le indicazioni corrette. Se le chiediamo semplicemente di «creare il sito della mia azienda», non possiamo dare per scontato che progetti anche una strategia SEO coerente con gli obiettivi commerciali dell'impresa.
Accessibilità: funziona anche per chi non naviga come te?
Un sito perfettamente utilizzabile per chi lo ha realizzato può risultare difficile, o addirittura inutilizzabile, per una parte dei visitatori.
Gli esempi sono molto concreti. Un testo con poco contrasto può diventare illeggibile per chi ha difficoltà visive. Un'interfaccia che richiede necessariamente l'uso del mouse può creare problemi a chi naviga con la tastiera. Immagini prive di testo alternativo, moduli costruiti senza etichette corrette o una struttura confusa dei titoli possono rendere molto più difficile la navigazione per chi utilizza tecnologie assistive come i lettori di schermo.
Sono aspetti relativamente semplici da considerare durante la progettazione, ma che possono richiedere interventi molto più importanti se vengono affrontati soltanto a sito terminato. Ed è un altro esempio di qualcosa che può non emergere semplicemente guardando il sito e provandolo come siamo abituati a fare noi.
C'è poi un aspetto normativo. L'accessibilità è una buona pratica per qualsiasi sito, ma in determinati casi è anche un obbligo di legge. L'applicabilità dipende dal tipo di soggetto, dai servizi offerti e dalle caratteristiche dell'impresa: in Italia esistono obblighi per la pubblica amministrazione e per determinati soggetti privati, mentre il quadro europeo ha esteso i requisiti ad alcune categorie di servizi rivolti ai consumatori, prevedendo anche specifiche esenzioni.
Anche in questo caso, quindi, il punto non è pretendere che chi costruisce un sito conosca ogni norma o ogni criterio tecnico: è sapere che il problema esiste e capire quando deve essere affrontato.
Privacy e conformità: l'AI non conosce i tuoi obblighi
Un sito o un'applicazione che raccoglie dati personali porta con sé questioni che non riguardano soltanto il codice, ma anche come quei dati vengono raccolti, utilizzati, conservati e condivisi.
Anche situazioni apparentemente semplici possono avere conseguenze. Un modulo di contatto raccoglie dati personali. Pixel pubblicitari e strumenti di profilazione possono richiedere il consenso prima di essere attivati. Servizi esterni — piattaforme di newsletter, mappe, video, sistemi di analytics o strumenti di intelligenza artificiale — possono coinvolgere altri soggetti nel trattamento dei dati.
L'AI può scrivere perfettamente il codice di un modulo, integrare un servizio esterno o generare un banner per la gestione dei cookie. Ma non può dedurre automaticamente quali obblighi si applichino a quella specifica azienda, in quel settore, con quei fornitori e con quel particolare utilizzo dei dati, se queste informazioni non fanno parte del contesto che le è stato fornito.
Questo non significa che una web agency debba sostituirsi a un consulente legale. Il suo ruolo è innanzitutto tecnico: progettare e implementare correttamente le soluzioni, conoscere le implicazioni delle proprie scelte e segnalare quando un determinato aspetto richiede una valutazione specialistica.
Ancora una volta il problema non è che l'AI non sappia fare qualcosa. È sapere che cosa deve essere valutato, prima ancora di chiederle di farlo.
Qual è il rischio che puoi permetterti di correre?
Un esempio volutamente estremo: saliresti su un aereo progettato interamente da un'intelligenza artificiale, senza che nessun ingegnere ne abbia verificato il progetto?
La questione non è stabilire se l’AI sia o meno capace di contribuire alla progettazione. Il punto è che, quando le conseguenze di un errore sono elevate, nessuno considererebbe sufficiente un risultato non verificato da persone competenti.
Il paragone è esagerato di proposito: un sito vetrina non è un aereo. Ma mette a fuoco il criterio con cui vale la pena giudicare qualunque progetto. Non "quanto è bravo lo strumento", ma: che cosa succede se sbaglia, e chi se ne accorgerebbe?
Tra il volantino e l'aereo c'è una scala intera, e ogni progetto sta da qualche parte lungo quella scala. La complessità tecnica conta, ma conta molto di più il rischio derivante da un eventuale problema.
Un sito personale o un blog amatoriale sta all'estremità bassa della scala: se si rompe, dispiace, ma non succede nulla di grave. Una landing page aziendale alza già l'asticella, perché è la faccia pubblica dell'azienda ed è spesso il primo contatto di un potenziale cliente. Un sito di lead generation la alza ancora: raccoglie dati personali e produce contatti commerciali, quindi un malfunzionamento silenzioso — il modulo che smette di inviare le email senza che nessuno se ne accorga — significa opportunità perse senza nemmeno saperlo.
Un e-commerce introduce ordini, pagamenti e fatturato: qui gli errori si misurano direttamente in denaro e in reputazione. Un'area riservata aggiunge autenticazione e informazioni che i clienti si aspettano restino private. Un gestionale entra dentro i processi aziendali, e se si ferma si ferma il lavoro delle persone. Un sistema che movimenta dati economici, fatture o informazioni critiche porta con sé conseguenze contabili e legali. All'estremità opposta ci sono le applicazioni mission critical, quelle senza le quali l'azienda semplicemente non opera.
Il principio è lineare: più sono importanti i dati, i processi o i risultati che dipendono da un sito web o un applicativo, meno ha senso accontentarsi del fatto che "sembri funzionare".
Quando ha senso fare da soli
Detto tutto questo, sarebbe scorretto concludere che serva sempre un professionista. Ci sono molte situazioni in cui usare direttamente l'AI è la scelta giusta.
Una landing page semplice con qualche informazione e un modulo di contatto è alla portata, soprattutto se il modulo si appoggia a un servizio esterno affidabile invece di gestire i dati in proprio. Un sito personale, un portfolio, il sito di un'associazione o di un progetto amatoriale rientrano nella stessa categoria. Prototipi, demo e proof of concept sono anzi il terreno ideale: servono proprio a capire se un'idea sta in piedi, e caricarli di garanzie che non serviranno sarebbe uno spreco.
Lo stesso vale per gli strumenti interni non critici e per le automazioni personali: se lo strumento lo usi tu, non tratta dati di terzi e il peggio che può capitare è rifare a mano mezz'ora di lavoro, il rapporto tra rischio e beneficio è tutto a favore del fare da sé. E infine c'è l'ambito didattico e sperimentale, dove costruire cose è il modo migliore per imparare.
Quando conviene farsi affiancare da una web agency
All'estremo opposto ci sono i progetti in cui la supervisione professionale dovrebbe crescere in modo netto: siti aziendali strategici, campagne di lead generation su cui si investe in pubblicità, e-commerce, aree riservate, qualsiasi cosa tratti dati personali in modo non banale, pagamenti, fatturazione, integrazioni con ERP o CRM, gestionali, applicazioni usate ogni giorno da dipendenti o clienti, e in generale tutto ciò da cui dipende direttamente il fatturato.
Ma le web agency non usano l'AI?
Certo che sì. L'intelligenza artificiale è ormai uno strumento ordinario nello sviluppo professionale, e l'aumento di produttività che porta è reale.
Uno sviluppatore la usa per generare porzioni di codice, per il refactoring — riorganizzare codice esistente senza cambiarne il comportamento — per cercare la causa di un errore, scrivere test automatici, produrre documentazione, costruire query SQL complesse, risolvere in due minuti un problema di CSS che ne avrebbe richiesti quaranta, analizzare codice altrui e individuare anomalie. E soprattutto per tutto ciò che è ripetitivo, che in questo mestiere è parecchio.
La contrapposizione, quindi, non è "AI contro sviluppatore umano" ma un'altra: AI usata senza competenze né controllo, contro AI usata da qualcuno che sa progettare, verificare e valutare il risultato.
Il professionista fa cose che restano sue anche quando la maggior parte del codice la scrive un modello. Definisce l'architettura, cioè decide come il sistema è organizzato prima che esista. Fornisce all'AI il contesto giusto, che è la parte in cui si vince o si perde. Formula richieste precise. Legge il codice che riceve. Lo prova, anche fuori dal percorso previsto. Corregge. Monitora ciò che accade dopo la messa online.
Ma la competenza che conta di più è saper riconoscere quando l'AI propone una soluzione apparentemente convincente ma tecnicamente sbagliata. Capita, capita spesso e capita nel modo peggiore: il codice è ordinato, ben commentato, sembra perfettamente ragionevole e fa esattamente quello che è stato chiesto. È sbagliato in un punto che non si vede provandolo. Chi conosce la materia se ne accorge; chi non la conosce non ha nessuno strumento per farlo. Non è una questione di intelligenza o di attenzione, ma di sapere che cosa guardare.
L'AI non cancella le competenze: ne sposta il valore
Per decenni una parte importante del lavoro di uno sviluppatore è consistita nella scrittura materiale del codice: trasformare una soluzione già pensata in istruzioni comprensibili a una macchina. Era un’attività che richiedeva tempo, precisione e competenza e, inevitabilmente, rappresentava una parte significativa del valore del lavoro.
L’intelligenza artificiale sta progressivamente riducendo il peso di questa componente. Non la sta eliminando, e certamente non lo sta facendo allo stesso modo in ogni ambito, ma la direzione è evidente. Chi ha costruito il proprio valore professionale quasi esclusivamente sulla capacità di produrre codice ha quindi buone ragioni per interrogarsi su come stia cambiando il proprio ruolo.
Allo stesso tempo, però, altre competenze stanno acquistando ancora più valore.
L’analisi, innanzitutto: comprendere davvero un problema e le esigenze di un’azienda prima ancora di pensare a come risolverlo. La progettazione e l’architettura del software, che diventano paradossalmente ancora più importanti proprio perché oggi produrre codice è molto più facile — e, di conseguenza, è altrettanto facile produrne tanto, rapidamente e male.
Poi ci sono la sicurezza, la capacità di definire correttamente un problema e di tradurre requisiti spesso vaghi in indicazioni precise. E infine il testing e la valutazione critica del risultato: saper verificare non soltanto che il software funzioni, ma che funzioni bene, sia affidabile, sicuro, manutenibile e capace di gestire anche ciò che non era stato previsto nel caso ideale.
L’AI ha reso il codice molto più facile da produrre. Non ha reso più facile progettare software affidabile.
Quindi, posso davvero farmi il sito da solo?
Sì. In molti casi puoi, e sarebbe disonesto sostenere il contrario.
Oggi una persona senza una formazione tecnica può realizzare autonomamente cose che fino a pochi anni fa avrebbero richiesto l’intervento di uno sviluppatore, con tempi e costi anche notevoli. È un cambiamento profondo, e chi lavora in questo settore farebbe bene a prenderne atto, anziché cercare di difendersene.
La domanda davvero utile, però, non è «riesco a farlo?». È un’altra: che cosa succede se qualcosa va storto?
Hai un progetto web da realizzare oppure hai già costruito qualcosa con l’AI e vuoi capire se è pronto per essere utilizzato davvero dalla tua azienda?
In IKIweb lavoriamo su entrambi i fronti: realizziamo nuovi progetti utilizzando anche l’intelligenza artificiale nei nostri processi di sviluppo, ma possiamo anche partire da prototipi e applicazioni già realizzati con l’AI, analizzarli, metterli in sicurezza e trasformarli in strumenti solidi e affidabili.
Se vuoi capire a che punto è il tuo progetto e che cosa manca per poterlo utilizzare davvero, parliamone.
FAQ
Posso davvero creare un sito web con l'intelligenza artificiale senza saper programmare? Sì. Per una landing page, un sito personale o un prototipo, gli strumenti di AI generativa permettono di ottenere un risultato funzionante anche senza competenze tecniche. La complessità cresce con il progetto: un e-commerce, un'area riservata o un'applicazione collegata al gestionale richiedono scelte tecniche che vanno oltre la generazione del codice.
Che cos'è esattamente il Vibe Coding? È l'approccio in cui si descrive all'AI il risultato desiderato, si prova ciò che viene generato, si segnala quello che non va e si itera finché il comportamento sembra corretto. Il criterio di accettazione è la prova pratica, non la comprensione del codice. È diverso dall'uso professionale dell'AI, in cui lo sviluppatore legge, verifica e valuta ciò che riceve.
Il codice generato dall'intelligenza artificiale è insicuro? Non necessariamente: l'AI produce spesso codice di buona qualità. Il problema è un altro: chi non ha competenze tecniche non ha modo di stabilire se il risultato sia corretto, perché molti difetti — soprattutto quelli di sicurezza — non producono errori visibili. Un'applicazione vulnerabile può funzionare perfettamente durante le prove.
Quando conviene rivolgersi a uno sviluppatore o a una web agency? Quando cresce il rischio, più che la complessità. Se il progetto tratta dati personali, gestisce pagamenti o ordini, prevede un'area riservata, si integra con ERP o CRM, o sostiene un processo aziendale, il livello di verifica richiesto è diverso da quello di un sito ad uso personale. Vale anche per gli MVP: se sono usati da clienti reali, alcune garanzie servono già dalla prima versione.
Le web agency usano l'intelligenza artificiale? Sì, ormai è uno strumento ordinario nello sviluppo professionale: generazione di codice, refactoring, debugging, test, documentazione, analisi. La differenza non è tra AI e sviluppatore, ma tra AI usata senza controllo e AI usata da chi sa progettare, verificare e riconoscere quando una soluzione proposta è sbagliata pur sembrando funzionante.