Tre settimane, un'app: Cosa l'intelligenza artificiale può costruire per lei e cosa non può assolutamente fare

Tre settimane fa avevo un backend .NET con forse il 40% dei servizi collegati, un frontend Vue semilavorato e un piano vago. Oggi Rasepi ha un motore di traduzione a livello di blocco con gestione del glossario e regole di stile, un sistema di punteggio di freschezza con modelli di scadenza e flussi di lavoro di revisione, una ricerca semantica alimentata dall'intelligenza artificiale con RAG, un SDK completo per i plugin con guardie d'azione e pipeline di eventi, un editing collaborativo in tempo reale, un sito web di marketing completo con pagine di prezzi, un portale di documentazione per gli sviluppatori, un blog con 14 post, traduzioni automatizzate in 7 lingue e un modulo di lista d'attesa che invia effettivamente delle e-mail.

Non ho fatto tutto questo da solo. Avevo Claude in esecuzione in VS Code ogni sera per ore e a volte anche tutto il giorno, ed è stato veramente trasformativo per le parti che poteva aiutare. Ma c'è un abisso tra "costruire un'applicazione" e "avere qualcosa che si possa effettivamente vendere ad un altro essere umano", e questo abisso è pieno di tonnellate di pagine di configurazione, di configurazione manuale, di impostazioni di recapito e-mail e di record DNS. Claude non può ancora parlare con tutti questi servizi.

Le persone parlano raramente di questa parte.

Avrei potuto farlo senza l'AI?

Guardi, ho oltre 30 anni di esperienza nella costruzione di software. Avrei potuto costruire tutto questo senza Claude? Probabilmente sì. Ma non in tre settimane. Neanche lontanamente. L'AI ha accelerato tutto ciò che comporta la digitazione di codice nei file, e questa è una parte importante di qualsiasi progetto.

Ma ecco cosa sfugge alle persone quando parlano di "vibe coding" e di costruire intere applicazioni con l'AI: **Claude può indicarle ogni singolo passaggio necessario per implementare un Cloudflare Worker con un database D1. Può guidarla nella configurazione di OpenIddict. Può spiegare i record DNS e la configurazione SPF. Il problema è che le sue conoscenze sono spesso obsolete. Le piattaforme aggiornano i loro dashboard, spostano le impostazioni, deprecano le funzioni, rinominano le cose. E Claude non lo sa.

Non ho nemmeno utilizzato una sola AI. ChatGPT a volte sapeva di più su servizi specifici, soprattutto quando i dati di formazione di Claude erano in ritardo di qualche mese sulla documentazione di una particolare piattaforma. Alcuni giorni ho avuto entrambe le AI aperte fianco a fianco, incrociando i loro suggerimenti con ciò che vedevo effettivamente nel dashboard.

Ma il punto più profondo è questo: per avere un'app vendibile, deve assolutamente sapere come funziona l'hosting. Come funzionano i domini. Come funzionano i certificati di firma del codice. Come funzionano i database. Come funziona la consegna delle e-mail. Come funzionano i flussi OAuth2, non solo il codice che li implementa. Può costruire un'applicazione senza queste conoscenze? Certo. Ma la porterà da qualche parte? Probabilmente no. Avrà qualcosa che funziona su localhost e non impressiona nessuno al di fuori della sua macchina.

L'80% che sembrava magico

Vorrei essere chiaro su ciò che ha funzionato, perché ha funzionato davvero bene. Per creare interfacce di servizio, implementare controllori CRUD, scrivere configurazioni EF Core e costruire componenti Vue, Claude è assurdamente veloce.

Ecco un esempio. Quando ho avuto bisogno di aggiungere il sistema di gestione dei glossari, ho descritto i requisiti: glossari con copertura degli inquilini, importazione/esportazione CSV, CRUD dei singoli termini e un meccanismo di sincronizzazione con l'API dei glossari di DeepL. Claude ha prodotto i modelli di entità, l'interfaccia e l'implementazione del servizio, il controller con gli attributi di autorizzazione appropriati e il negozio Pinia. Tutto in circa 20 minuti. Avrei impiegato quasi un giorno per scrivere tutto questo a mano.

Il motore di traduzione è stato simile. L'architettura a livello di blocco con l'hashing SHA256 dei contenuti, il rilevamento dello stallo, l'orchestratore che coordina i servizi. Claude ha capito il modello dopo che l'ho spiegato una volta e poi l'ha replicato in modo coerente su decine di file. Il sistema di punteggio di freschezza, i flussi di lavoro di revisione, la pipeline di notifica di scadenza. Servizio dopo servizio, collegato e funzionante.

Per il sito di marketing, Claude ha costruito intere pagine HTML a partire dalle descrizioni. "Una pagina di prezzi con un livello gratuito, un livello team e un livello enterprise. Sfondo scuro. Utilizzi l'accento verde". E ha semplicemente... prodotto una pagina. Compresi i breakpoint responsive e gli stati hover.

Questa è la parte magica. È reale.

Domare la macchina

Ma non è che ho digitato "costruiscimi un'applicazione" e me ne sono andata. Lavorare con Claude è un'abilità a sé stante, e i primi giorni li ho trascorsi male.

Il risultato iniziale è sempre... buono. Tecnicamente corretto, ragionevolmente strutturato, ma generico. Claude scrive il codice come scrive la prosa: competente, prevedibile e profondamente mediocre. Lasciato a se stesso, produrrà la stessa struttura di controller che ogni tutorial di framework utilizza. Lo stesso modello di servizio. Lo stesso layout dei componenti. Funziona, ma non è il suo.

Quindi inizia ad addestrarlo. Non in modo formale, non con la messa a punto, ma attraverso la ripetizione e la correzione. "No, voglio che l'interfaccia del servizio sia separata dall'implementazione". "Utilizzi sempre questo modello di attributo di autorizzazione". "Il contesto dell'inquilino proviene dal middleware, non dal corpo della richiesta". Giro dopo giro, giro dopo giro. Alcuni giorni mi sembrava di essere in coppia con un giovane molto entusiasta che continuava a dimenticare ciò che avevamo deciso ieri.

E poi qualcosa scatta. Dopo un numero sufficiente di correzioni, dopo un numero sufficiente di esempi nella base di codice da leggere, Claude inizia ad azzeccare le cose al primo tentativo. Capisce le convenzioni di denominazione. Sa dove mettere i DTO. Segue il suo modello di gestione degli errori senza che gli venga chiesto. La transizione da "fastidioso" a "produttivo" ha richiesto forse quattro o cinque giorni di lavoro costante.

I post del blog sono stati una storia simile. La voce di scrittura predefinita di Claude è immediatamente riconoscibile. Quello stile lucido, un po' distante, perfettamente strutturato, che si legge come ogni post di blog generato dall'AI che abbia mai visto. Ho fatto diversi cicli di costruzione di una guida di stile, alimentando esempi di come scrivo realmente, sottolineando ogni "vale la pena di notare" e ogni trattino (seriamente, la dipendenza da trattino è reale). Alla fine ho creato un intero file di competenze, una serie di istruzioni che Claude carica prima di scrivere qualsiasi cosa per il blog Rasepi.

Questo post, per la cronaca, è di Claude. Con il mio contributo, le mie correzioni, la mia direzione. Ho descritto ciò che volevo dire, l'ho indirizzato verso la guida di stile e poi ho trascorso del tempo ad andare avanti e indietro fino a quando la voce non è sembrata giusta. Questo è il vero flusso di lavoro. Non "lo scrive l'AI" e non "lo scrivo io". È una conversazione che produce qualcosa che nessuno dei due avrebbe scritto da solo.

Ho anche creato istruzioni personalizzate per la base di codice stessa. Un file di istruzioni per il copilota che spiega l'architettura, il sistema di traduzione, le regole di isolamento degli inquilini, le convenzioni di codifica. Claude lo legge all'inizio di ogni sessione, e la differenza è notte e giorno. Senza, Claude tira a indovinare. Con esso, Claude sa.

Il punto è che i guadagni di produttività sono reali, ma non sono gratuiti. Si investe tempo in anticipo per insegnare all'IA come si lavora, e questo investimento si ripaga nel corso delle settimane. Se salta questo passaggio, passerà più tempo a correggere i risultati di Claude di quanto ne avrebbe speso a scrivere il codice da solo.

Poi è necessario distribuire effettivamente la cosa

Qui la storia cambia.

Ha un'applicazione funzionante su localhost. Bellissima. Ora la metta su Internet. Faccia in modo che invii delle e-mail. Permettere alle persone di iscriversi. Accettare eventualmente dei pagamenti. La protegga dai bot. Le dia un nome di dominio che si risolva correttamente.

Claude non può aiutarla in tutto questo. Non proprio.

Non intendo dire che produce suggerimenti sbagliati. Intendo dire che fondamentalmente non può interagire con i sistemi che deve configurare. E la configurazione è l'ambito in cui lei passa il suo tempo, non la scrittura di codice.

Cloudflare: Un caso di studio di "Risolvi da solo".

Il sito di marketing di Rasepi funziona su Cloudflare Pages. L'API della lista d'attesa è un Cloudflare Worker con un database D1. Sembra semplice, fino a quando non deve effettivamente configurarlo.

Claude non ha mai visto il suo dashboard Cloudflare. Può dirle "aggiungi un record CNAME", ma non può dirle quale delle 14 schede contiene le impostazioni DNS per il suo dominio specifico. I binding del database D1 necessitano di un ID di database specifico nel suo wrangler.toml. I segreti dell'ambiente passano attraverso wrangler secret put. CORS deve corrispondere alle sue origini effettive, non a localhost. Turnstile ha bisogno di chiavi da un'altra sezione del dashboard.

Ho trascorso quasi un'intera giornata per far sì che il Worker verificasse correttamente i token Turnstile, accettasse gli invii di moduli, li memorizzasse in D1 e inviasse e-mail di conferma. Claude mi ha aiutato a scrivere il codice del Worker stesso. Ma la distribuzione, la configurazione del wrangler, la gestione dei segreti, il debug della propagazione DNS? Tutto questo l'ho fatto io.

OAuth2: Il labirinto della configurazione

L'autenticazione è il miglior esempio del divario tra "codice" e "prodotto".

Claude può assolutamente scrivere un'integrazione OAuth2. Conosce le specifiche OIDC, può produrre middleware, capisce le richieste JWT. Per il nostro ambiente di sviluppo ho un DevAuthHandler che conia token con rivendicazioni tenant_id e sub da un semplice modello di stringa portante. Claude l'ha scritto in pochi minuti.

Ma l'autenticazione di produzione significa OpenIddict, e OpenIddict significa capire le rivendicazioni sub, le rivendicazioni tenant_id, gli URL di callback, le origini JavaScript, gli URI di logout e tutte le altre stranezze che derivano dalla configurazione di una vera identità. E questo prima ancora di arrivare ai provider esterni.

Perché i suoi utenti vogliono accedere a Google, Microsoft o GitHub. E Claude non può accedere a nessuna di queste console per sviluppatori. Non può:

• Creare un'applicazione OAuth nella Google Cloud Console e generare un ID cliente e un segreto
• Registrare un'applicazione nel portale Microsoft Entra e configurare gli URI di reindirizzamento.
• Configurare un'applicazione GitHub OAuth e acquisire le credenziali.
• Configuri gli URL di callback di ciascun provider per ogni ambiente che gestisce
• Configurare gli ambiti corretti, le schermate di consenso e gli endpoint dei token

Ogni fornitore ha il proprio portale per gli sviluppatori, la propria terminologia, il proprio flusso per generare le credenziali. Google la chiama "schermata di consenso". Microsoft la chiama "registrazione di app". GitHub le chiama "App OAuth" (da non confondere con le "App GitHub", che sono una cosa completamente diversa). E ognuno di essi richiede di copiare manualmente un ID cliente e un segreto nella configurazione.

Claude può scrivere la configurazione del server OpenIddict, il middleware del provider esterno, la logica di trasformazione delle richieste. Ma la generazione effettiva delle credenziali, la navigazione nel portale, la configurazione dell'URL specifico dell'ambiente? Questo è tutto suo, in un browser, cliccando sui dashboard.

Email: Non si tratta mai solo di "inviare un'e-mail".

Il codice per inviare un'e-mail tramite l'API Resend è di circa 15 righe. Claude l'ha scritto senza problemi. Ma per far sì che le e-mail arrivino effettivamente nella casella di posta di qualcuno? Questo richiede un dominio di invio verificato, record DNS per SPF, DKIM e DMARC, l'attesa della propagazione e poi il test di deliverability, perché Gmail e Outlook hanno le loro opinioni sull'affidabilità del dominio.

E progettare un modello di e-mail che non abbia un aspetto terribile in ogni client di posta elettronica. Outlook su Windows utilizza ancora il motore di rendering di Word nel 2026. Lasci che questo sia chiaro.

L'elenco completo delle cose che ho fatto senza AI

Guardando indietro a tre settimane di lavoro, ho iniziato a tenere un conto mentale approssimativo di ciò che Claude ha costruito rispetto a ciò che ho configurato a mano. L'elenco "a mano" è più lungo di quanto mi aspettassi:

Infrastruttura cloud:

• Configurazione del progetto Cloudflare Pages e configurazione del dominio personalizzato
• Distribuzione di Cloudflare Worker e provisioning del database D1
• Registri DNS per il sito di marketing, l'API e l'invio di e-mail
• Configurazione del certificato SSL/TLS (per lo più automatica, ma il debug quando non lo è è doloroso)
• Configurazione della pipeline di costruzione per il blog (Eleventy + traduzione + generazione di immagini OG)

Autenticazione e sicurezza:

• Registrazione delle app Google, Microsoft e GitHub OAuth e generazione delle credenziali
• Configurazione di OpenIddict con rivendicazioni corrette, URL di callback, origini JS e URI di logout
• Configurazione della protezione bot Turnstile (chiavi del sito, chiavi segrete, configurazione della dashboard)
• Configurazione della politica CORS tra frontend, API e origini del lavoratore

Email:

• Configurazione dell'account di reinvio e della chiave API
• Registri DNS SPF, DKIM, DMARC
• Test di deliverability delle e-mail e risoluzione dei problemi
• Test dei modelli sui client di posta elettronica

Integrazioni con terze parti:

• DeepL Gestione dell'account e della chiave API
• Impostazione di Google Analytics con integrazione del consenso dei cookie

Hosting Azure:

• Impostazione e configurazione di Azure App Service per il backend .NET
• Provisioning del database Azure SQL, regole firewall e stringhe di connessione
• Configurazione di Azure Cache per Redis e configurazione della connessione
• Fornitura di risorse Azure OpenAI per embeddings e RAG

Distribuzione:

• Configurazione Docker per il backend .NET
• Gestione delle variabili d'ambiente su tre diversi target di distribuzione
• Stringhe di connessione al database per diversi ambienti

E onestamente sto probabilmente dimenticando alcune cose. Ogni servizio di terze parti ha il proprio dashboard, il proprio modello di credenziali, la propria qualità della documentazione (che varia in modo selvaggio) e le proprie stranezze.

Perché questo è più importante di quanto si pensi

Ecco la dimensione che si perde in ogni conversazione sullo sviluppo assistito dall'AI: **Gli strumenti di IA non hanno alcun contesto sulla sua infrastruttura.

La sua base di codice vive in file che un'AI può leggere. La sua configurazione Cloudflare no. Le impostazioni della sua app Google OAuth non lo fanno. I suoi record DNS non lo fanno. Lo stato di verifica del suo dominio Resend non lo fa. L'intera superficie operativa di un prodotto reale è invisibile agli strumenti di AI, e questa superficie è enorme.

Scrivere codice è la parte facile dell'ingegneria del software, e sta diventando sempre più facile. Le parti difficili sono ciò che si fa con quel codice. Farlo funzionare, capirlo quando si rompe qualcosa alle 2 del mattino, estenderlo quando cambiano i requisiti e governarlo per tutto il suo ciclo di vita. L'AI rende più veloce la parte facile. Non fa nulla per la parte difficile.

Il sito di marketing merita una sezione a sé stante

Ho costruito l'intero sito di marketing di Rasepi in circa quattro giorni. Homepage, pagina dei prezzi, moduli di iscrizione e di contatto con protezione bot, informativa sulla privacy, quattro pagine di approfondimento delle caratteristiche. Claude ha realizzato probabilmente il 70% dell'HTML/CSS.

Ma poi avevo bisogno che esistesse davvero su Internet. Il blog funziona su Eleventy con una pipeline di creazione in 8 fasi: tradurre i post tramite DeepL, costruire il sito, tradurre le pagine HTML statiche, copiare le risorse condivise, generare immagini OG da SVG, generare versioni audio, gestire i manifesti audio, produrre una mappa del sito multilingue. Claude ha contribuito alla stesura di parti di questa pipeline, ma per far funzionare tutto insieme con i giusti percorsi dei file e le giuste impostazioni di distribuzione di Cloudflare Pages è stata necessaria un'intera giornata di tentativi ed errori.

E il sito di documentazione per gli sviluppatori? Si tratta di un progetto Cloudflare Pages separato, con il proprio dominio, la propria configurazione di compilazione e i propri trigger di distribuzione. Un'altra dashboard, un'altra serie di variabili d'ambiente, un altro giro di DNS.

Lo schema che continuo a vedere

Per qualsiasi funzione, Claude gestisce circa l'80 per cento del lavoro in termini di volume**. Linee di codice, file creati, problemi risolti. Ma il restante 20% è costituito da un lavoro di configurazione interamente manuale: clic su dashboard web, copia di chiavi tra servizi, debug di problemi di integrazione che si manifestano solo negli ambienti distribuiti.

E questo 20% richiede almeno lo stesso tempo dell'altro 80%. A volte più a lungo.

Ma ecco cosa è cambiato rispetto a come funzionava lo sviluppo in solitaria: in passato, o scriveva il codice o si occupava della configurazione. Mai entrambe le cose. Se passava una giornata a configurare i webhook di Stripe e a testare i flussi di pagamento nel loro dashboard, era una giornata in cui scriveva zero codice applicativo. Il suo progetto smetteva di avanzare su un fronte, mentre lei lavorava sull'altro.

Con Claude, questo non è più vero. Mentre io ero immerso nella dashboard di Stripe per capire gli endpoint dei webhook e i tipi di eventi, Claude stava costruendo la prossima interfaccia del servizio. Mentre io cliccavo per la terza volta sulla schermata di consenso OAuth di Google perché avevo sbagliato gli ambiti, Claude scriveva componenti Vue. La mia testa era nella terra della configurazione, ma la base di codice continuava a crescere. Questa è una vera novità. Uno sviluppatore solitario può ora muoversi su due fronti contemporaneamente, e questa potrebbe essere la più grande differenza pratica che l'AI fa per i piccoli team.

Detto questo, quando si scrive codice con l'aiuto dell'AI, si è in un ciclo di feedback stretto. Scrivere, testare, correggere, iterare. Quando sta cercando di capire perché il suo Cloudflare Worker restituisce errori CORS solo in produzione, sta fissando gli screenshot della dashboard, leggendo i post dei forum della comunità e provando modifiche di configurazione casuali sperando che una di queste funzioni.

Cosa deve cambiare

Non credo che questa sia una limitazione permanente. Il pezzo mancante è ovvio: gli strumenti di AI devono essere in grado di interagire con le API di servizi e dashboard di terze parti. Non solo scrivere codice che li richiami, ma anche configurarli.

Alcuni di questi aspetti stanno iniziando a verificarsi. Stanno nascendo server MCP (Model Context Protocol) per vari servizi. Anthropic sta chiaramente pensando all'uso degli strumenti come concetto di prima classe. Ma non siamo ancora vicini al punto in cui posso dire "configura il mio Cloudflare Worker con un database D1, configura il dominio personalizzato e aggiungi la protezione Turnstile" e farlo accadere davvero.

Fino ad allora, la storia onesta della costruzione di un prodotto con l'AI è questa: L'AI è un acceleratore incredibile per la scrittura del codice dell'applicazione. Ma un prodotto vendibile è solo per metà codice applicativo. L'altra metà è costituita dall'infrastruttura, dalle integrazioni di terze parti, dalle pipeline di distribuzione, dalla deliverability delle e-mail, dalla configurazione del dominio e dalla configurazione della sicurezza. E per tutto questo, lei è da solo.

(Questo è, tra l'altro, uno dei motivi per cui stiamo costruendo Rasepi come una piattaforma ospitata e non solo come un codice open-source. Far funzionare un software di documentazione non è così difficile. Farlo funzionare in modo affidabile, con l'autenticazione, l'e-mail e l'hosting adeguati? Questo è il prodotto).

Se sta per provarlo

Alcune cose pratiche che ho imparato e che potrebbero farle risparmiare tempo:

• Iniziare con l'infrastruttura, non con il codice.** Configurare prima il suo hosting, il suo provider di autenticazione, il suo servizio e-mail e i suoi domini personalizzati. Faccia un "hello world" distribuito in produzione prima di scrivere una sola riga di codice applicativo reale. Il numero di problemi che emergono solo negli ambienti distribuiti è deprimente.

• Conservi un documento sulle credenziali.** Avrà chiavi API, ID client, URL di callback, ID database e chiavi segrete sparse in 8 dashboard diversi. Io utilizzo un file locale crittografato. Può utilizzare 1Password o altro. Basta avere un unico posto.

• Se Claude l'aiuta a creare la funzione in 2 ore, metta in conto almeno altre 2 ore per la distribuzione, la configurazione delle integrazioni e il test in produzione.

• Ci sono stati giorni interi in cui ho scritto essenzialmente zero codice, ma ho fatto progressi critici: registrazione di app OAuth su tre provider, impostazione di e-mail, debug di DNS. Questi giorni sembrano meno produttivi, ma non lo sono.

Tre settimane sono ancora molto veloci per quello che ho costruito. Non mi sto lamentando di Claude. Ha permesso a un singolo sviluppatore di costruire qualcosa che normalmente avrebbe richiesto a un piccolo team la maggior parte di un anno. Ma la storia che viene raccontata nel ciclo dell'hype dell'AI (prompt, code, ship, done) manca dell'intera sezione centrale, in cui la si rende reale.

L'app è la parte facile. Renderla reale è il lavoro.