Ho costruito un AI website builder per Webround. Poi l'ho eliminato.
Fin dai primi giorni di sviluppo di Webround, ho sempre immaginato che prima o poi avrei integrato un assistente AI capace di costruire un intero sito da zero, a partire da un singolo prompt. Molte aziende oggi fanno marketing specificamente attorno a questo tipo di funzionalità nativa, quindi il desiderio di introdurre qualcosa di simile in Webround continuava a crescere.
Ho approfittato delle settimane più tranquille dell'estate per costruire un AI builder che, alla fine, non ho rilasciato e ho deciso di mettere in pausa.
Non c'era nessun problema insormontabile dietro questa decisione. Ma, man mano che usavo il builder, continuavano a emergere alcune questioni fondamentali che mi facevano mettere in dubbio l'intera integrazione. Webround è una piattaforma headless con API pubbliche e un ambiente React completo, quindi chiunque può aprire Claude o ChatGPT, descrivere quello che vuole e ottenere codice funzionante senza che io aggiunga nulla.
E dato che l'integrazione era costruita sugli stessi LLM mainstream che tutti già usano, la domanda è diventata ovvia: perché usare un'integrazione proprietaria che costa di più quando puoi semplicemente usare la tua chat?
Come funzionava
Webround supporta sia un editor visuale no-code per chi non scrive codice sia un ambiente React completo con Tailwind v4 e supporto NPM.
L'idea alla base del builder era semplice ma ambiziosa: costruire un servizio AI che analizzasse la richiesta dell'utente e decidesse autonomamente cosa fare, come combinare no-code e React e come usare la prop wr dei componenti React in Webround.
Preoccupato di costruire un'integrazione con un contesto enorme, ho deciso di separare la fase di pianificazione dalla fase di esecuzione.
Un primo prompt raccoglieva tutti i dati e i requisiti (copy, struttura, palette colori, cosa modificare, cosa aggiungere) e generava un flusso multi-step da eseguire. Un secondo prompt riceveva ogni step separatamente con le operazioni chiaramente definite. Con una tipizzazione forte e i giusti file di contesto, l'AI sapeva esattamente cosa fare per applicare ogni modifica nell'editor di Webround.
Questo approccio mi dava, in teoria, due vantaggi: l'utente approva le modifiche prima che l'AI inizi a lavorare, e ogni step era isolato e legato a un singolo prompt alla volta, quindi l'AI non si trovava mai con un contesto enorme cercando di fare tutto in una volta. I risultati, però, non erano quelli che mi aspettavo.
La generazione no-code con l'AI produce risultati mediocri
I componenti no-code di Webround sono strutture semplici, tipizzate, rigide. Un componente immagine prende un URL, un testo alternativo e alcune proprietà di stile. In pratica, un componente è codice React generico che sa come interpretare il JSON legato alla sua configurazione. Pur non essendo niente di estremamente complesso, non è comunque generazione HTML libera: il modello deve produrre output che rispetta la struttura, altrimenti ogni errore si traduce in uno stile mancante o in un componente che non si carica.
Tramite l'interfaccia questo non succede mai perché l'utente è vincolato a interfacce di editing che prevengono gli errori: non puoi inserire un numero dove è attesa una stringa perché l'interfaccia semplicemente non te lo permette.
Per far capire tutto questo all'AI, devi iniettare nell'intero sistema di tipi dei componenti nel contesto, altrimenti il modello avrebbe solo indovinato. Nella maggior parte dei casi l'AI non produceva output non valido, e non era un problema grave quando lo faceva perché avevo costruito un sistema di validazione che scartava l'output se il modello non rispettava lo schema JSON atteso.
Il vero problema era la qualità visiva di quello che veniva costruito. Era raramente accettabile perché continuavo a ritrovarmi con layout che avevano poco senso, configurazioni multi-device mancanti e stili visivamente inefficaci. Era come se l'AI perdesse pezzi lungo la strada. Quindi ho iniziato a fare affidamento sempre più sulla generazione di sezioni interamente in codice React custom.
Una storia completamente diversa con React
Quando ho detto all'AI di scrivere codice React, mi sono reso conto di quanto siano capaci i modelli attuali nello sviluppo frontend. Alcuni degli output mi hanno genuinamente sorpreso: landing page bellissime, colori equilibrati, font e copy coerenti con l'obiettivo del sito. Sappiamo tutti che c'è una differenza tra generare una bella landing page e costruire un frontend solido, ma era chiaro che la generazione di siti con codice React funzionava bene.
È un compito su cui l'AI è stata ampiamente addestrata, e ho ottenuto esattamente quello che mi aspettavo: componenti corretti, buon output visivo, configurazioni corrette. Ho avuto qualche problema occasionale con caratteri inaspettati che rompevano la formattazione JSON nel validatore di output, ma erano problemi identificabili e risolvibili.
A quel punto pensavo che il modello stesse limitando la generazione della sezione no-code.
I modelli che ho usato e il problema dei costi
Per questa integrazione ho usato due modelli: Gemini 3.5 Flash e Gemini 3.1 Pro Preview. Avrei voluto integrare Claude, ma avevo già un'integrazione Gemini completa pronta e ho deciso di riutilizzarla. Onestamente, la differenza di qualità era appena percettibile: Gemini 3.5 Flash costava meno di Gemini 3.1 Pro e si comportava altrettanto bene.
Ma, continuando a usare il builder, due problemi sono diventati difficili da ignorare. Prima di tutto, i costi di output erano elevati e non riuscivo a semplificarli: la fase di pianificazione era economica, ma la generazione effettiva del codice era un problema reale. Nella maggior parte dei casi avevo a che fare con costi che rendevano il tutto estremamente inefficiente. Generare un intero sito, che produceva comunque un output che richiedeva una quantità significativa di pulizia manuale, consumava facilmente uno o due euro in crediti Gemini 3.5 Flash, a seconda del livello di dettaglio nel prompt.
Considerando le rielaborazioni che un utente avrebbe bisogno di fare per ottenere esattamente quello che vuole, quei costi potevano facilmente raddoppiare.
In secondo luogo, la generazione no-code era insoddisfacente e altamente inconsistente. A volte le sezioni no-code venivano bene, altre volte no. La strategia più affidabile era affidarsi a React, che è anche più flessibile e potente.
Ma allora la domanda diventa ovvia: perché qualcuno dovrebbe usare uno strumento integrato in Webround, a un costo superiore, per generare codice React che Claude può generare perfettamente con un po' di contesto su Webround fornito dall'utente?
Più andavo avanti, più diventava chiaro che stavo costruendo un sistema che, usando gli stessi modelli, sarebbe costato di più e prodotto risultati più o meno equivalenti a quelli che l'utente può già ottenere da solo. Chiunque usi un website builder, anche se non sa programmare, probabilmente ha già accesso a Claude, Gemini o ChatGPT. Se il no-code è inaffidabile e React è il percorso sensato, perché non dare loro i giusti file di contesto e togliersi di mezzo?
Stavo costruendo un AI website builder integrato in Webround che costava di più per produrre risultati uguali o peggiori di quelli che gli utenti potevano ottenere da soli. Non solo è indifendibile come posizionamento di prodotto, ma significava anche mantenere un'integrazione che aggiunge debito tecnico senza aggiungere valore reale.
Non volevo però restare a mani vuote.
Cosa ho fatto invece
Senza pensarci troppo, mi sono posto domande dalle risposte chiare:
- Costa di più? Sì.
- È meglio? Non necessariamente.
- È essenziale? No.
- Può essere costruito dopo, o in modo diverso, dall'esterno? Sì.
Quindi la decisione era immediata: sospendere l'AI builder, ma fare un test con Claude. Ho creato un progetto, caricato alcuni file di contesto, dato istruzioni chiare e provato a costruire qualcosa.
È andato esattamente come previsto. Claude genera codice React pulito, bello, corretto e funzionante a una frazione di quello che costerebbe fare singole chiamate API a Gemini, Claude o OpenAI.
Quindi, ho scritto tre file Markdown progettati esattamente per questo scopo. Contengono le informazioni necessarie per orientare un'AI nella giusta direzione, prevenire errori comuni, indirizzarla verso la documentazione ufficiale e spiegare i piccoli dettagli dell'ecosistema Webround.
- webround.md copre i concetti fondamentali della piattaforma: la differenza tra draft e store, l'architettura runtime e tutti gli strumenti di estensibilità, Checkout Hooks, Edge Hooks, Webhook e App Extensions, con una descrizione chiara di cosa fa ognuno e quando usarlo.
- webround-apis.md copre i quattro sistemi API di Webround, Core, Commerce, Catalog e Checkout, con i metodi di autenticazione supportati da ciascuno, le differenze tra autenticazione JWT e API key, casi d'uso specifici e le differenze tra i vari sistemi API. Include anche il dettaglio che
draftIdestoreIdsono sempre lo stesso valore: ovvio per chi conosce la piattaforma, ma esattamente il tipo di cosa che fa inciampare un modello che non conosce l'intera piattaforma. - webround-frontend.md copre tutto il necessario per scrivere componenti React custom: come strutturare un componente con la prop
wr, come gestire la navigazione interna nel shadow DOM, come usare Tailwind v4 e come gestire alcune funzioni di base.
Stavo iniziando a capire una cosa semplice: non hai bisogno di un sistema editor AI proprietario. Hai solo bisogno del contesto giusto per far funzionare l'AI correttamente.
Cosa ho portato via da questa esperienza
Il fascino di un AI website builder è reale, specialmente quando vedi altri costruirli e il marketing attorno a queste funzionalità diventa sempre più rumoroso. Ma quando una funzionalità non aggiunge valore reale oltre alla comodità, a scapito del controllo e della qualità, diventa chiaro che investirci, almeno in questo momento, non ha senso.
La piattaforma è già abbastanza aperta da non aver bisogno di un intermediario AI proprietario: stavo aggiungendo complessità non essenziale in cambio di un sistema di crediti o un costo premium che non era sempre giustificabile.
Al momento, ho messo lo sviluppo in pausa senza archiviare l'idea. Ci saranno probabilmente iterazioni su questo nei prossimi mesi con dettagli più specifici, più mirati e integrazioni più granulari. Una parte di me sente che questa funzionalità è importante, ma forse è solo FOMO. Un'altra parte sa che non avrei guadagnato quasi nulla se non un workflow leggermente più comodo.
Per ora, i file di contesto sono sufficienti.
Scarica i file di contesto per Webround
Se stai costruendo su Webround con un assistente AI, questi file sono pronti all'uso:
Se hai bisogno delle specifiche API complete o delle definizioni di tipo frontend complete, questi file sono disponibili anche loro. Non li consiglio da incollare direttamente in un messaggio di chat perché si consumerebbero un numero enorme di token. Io li uso come knowledge base all'interno di un progetto Claude, che recupera informazioni specifiche senza consumare troppi token grazie al tool use e al RAG che costruisce automaticamente sui file del progetto.