Pattern di prompt per ottenere app migliori con Coderblock

Un buon prompt per Coderblock non deve sembrare una specifica tecnica. Non serve parlare di framework, database, API o architettura. Puoi semplicemente descrivere ciò che vuoi costruire e lasciare che gli agenti AI trasformino l’idea in una vera app fullstack, usando React, TypeScript, Tailwind CSS, autenticazione e, quando necessario, un database Postgres.

Questo non significa, però, che un prompt valga l’altro.

Più è chiaro il contesto che fornisci, più facilmente l’agente può prendere decisioni utili al posto tuo. Un buon prompt non descrive ogni dettaglio dell’implementazione: chiarisce che cosa stai costruendo, per chi, come dovrebbe funzionare e quali sono le regole da rispettare.

Da lì, puoi lasciare che Coderblock faccia il resto. Ecco alcuni pattern che puoi utilizzare per ottenere risultati migliori e rendere le iterazioni più efficaci.

Parti dal prodotto, dall'utente e dal risultato

Un prompt come “Crea una dashboard” o “Realizza un’app per le prenotazioni” può essere sufficiente per iniziare, ma lascia aperte molte domande. Chi utilizzerà l’app? Che cosa deve poter fare? Qual è il risultato più importante che vuoi ottenere?

Un modo semplice per dare all’agente il contesto giusto è partire da tre elementi:

• Prodotto: che tipo di app stai costruendo?
• Utente: chi la utilizzerà?
• Risultato: che cosa deve riuscire a fare?

Per esempio:

Crea una piattaforma di prenotazione per personal trainer indipendenti. I trainer devono poter pubblicare le sessioni disponibili, mentre i clienti devono poter consultare gli orari, creare un account e prenotare una fascia oraria. Includi una dashboard per consentire ai trainer di gestire le prenotazioni future.

Con queste informazioni, l’agente ha già un modello concreto del prodotto. Può dedurre le schermate principali, i ruoli, le entità del database e la navigazione senza che tu debba specificare route o schema.

Se parti da uno dei template di Coderblock, puoi usare lo stesso approccio per spiegare cosa vuoi cambiare o aggiungere. Il template è il punto di partenza: la tua idea viene costruita sopra quella struttura.

Descrivi i flussi, non funzionalità isolate

Un elenco di funzionalità dice cosa deve esserci. Un flusso spiega come tutto dovrebbe funzionare insieme. Invece di scrivere “aggiungi autenticazione, profili, prenotazioni ed email”, descrivi cosa succede quando una persona utilizza il prodotto.

Prova così:

Un nuovo visitatore deve poter consultare i profili dei trainer senza effettuare l'accesso. Quando sceglie una sessione, chiedigli di registrarsi o accedere, confermare la prenotazione e poi mostrala nella sezione Le mie prenotazioni. I trainer devono vedere soltanto le prenotazioni relative alle proprie sessioni.

Ora l’agente conosce il percorso dell’utente: cosa è pubblico, quando serve autenticarsi, cosa succede dopo la prenotazione e quali dati sono visibili a ciascun ruolo.

Da queste indicazioni può configurare Supabase Auth, route protette, sessioni, tabelle e Row Level Security in base al comportamento che hai descritto. Non serve quindi chiedere una logica JWT personalizzata, l’hashing delle password o una tabella separata per le password. È più utile dire chi deve poter accedere a cosa e lasciare che Coderblock scelga l’implementazione necessaria.

Separa ciò che è essenziale da ciò che è una preferenza

Non tutte le decisioni hanno lo stesso peso. Un buon prompt può distinguere chiaramente ciò che l’app deve assolutamente fare da ciò che può essere interpretato dall’agente.

Per esempio:

Requisiti essenziali: accesso clienti, profili dei trainer, disponibilità, prenotazioni e viste separate per clienti e trainer. Preferenze visive: design editoriale e rilassante, colori neutri e caldi, spaziatura generosa e animazioni ridotte al minimo. L’agente UX può decidere il layout esatto delle schede.

In questo modo, le funzionalità fondamentali rimangono vincolanti mentre lasci agli agenti dell’Agent Team la libertà di prendere decisioni sul design e sulla UX.

Anche i vincoli possono essere molto utili. Per esempio:

• Approccio mobile-first o desktop-first
• Pagine pubbliche o accessibili solo dopo l’autenticazione
• Ruoli utente necessari
• Valuta e intervallo di fatturazione
• Dati che devono rimanere privati per ogni utente
• Azioni riservate agli amministratori

La regola è semplice: specifica il comportamento, non necessariamente il modo in cui deve essere implementato.

Descrivi i dati attraverso le relazioni

Quando costruisci un’app, non devi pensare necessariamente in termini di tabelle e migrazioni.

È molto più naturale descrivere le relazioni che esistono nel mondo reale.

Coderblock assegna alle app web standard un progetto Supabase dedicato, con Postgres e Row Level Security. Puoi quindi spiegare come devono essere organizzati i dati senza scrivere manualmente lo schema del database.

Per esempio:

Ogni trainer può creare più tipi di sessione. Un tipo di sessione include durata, prezzo e descrizione. Le fasce orarie disponibili appartengono a un trainer e possono avere al massimo una prenotazione confermata. I clienti devono vedere soltanto le proprie prenotazioni, mentre i trainer devono vedere quelle relative alle proprie fasce orarie.

Rispetto a un semplice “aggiungi una tabella delle prenotazioni”, questa descrizione dà all’agente molte più informazioni: quali entità esistono, come sono collegate, quali vincoli devono rispettare e chi può accedere ai dati.

Se il prodotto evolve, continua a descrivere i cambiamenti dal punto di vista del comportamento:

Aggiungi alle prenotazioni il motivo e la data e ora della cancellazione. I clienti possono annullare fino a 24 ore prima di una sessione, ma soltanto i trainer possono contrassegnare una prenotazione come completata.

L’agente può quindi aggiornare la struttura esistente senza dover ricostruire l’app da zero.

Una modifica alla volta. E sempre osservabile.

Una delle caratteristiche più utili dell’anteprima live di Coderblock è la possibilità di vedere rapidamente l’effetto di ogni modifica. Per questo, dopo la prima generazione, conviene procedere con richieste successive e mirate invece di riscrivere ogni volta l’intero brief.

Per esempio:

Rendi fissa la barra di navigazione su desktop, ma mantieni compatto l'header su mobile.

Nella dashboard del trainer, mostra le sessioni di oggi prima del calendario settimanale.

Aggiungi uno stato vuoto alla sezione Le mie prenotazioni, con un pulsante per tornare alla ricerca dei trainer.

Ogni richiesta produce un risultato concreto che puoi verificare subito nell’anteprima. Questo rende più semplice capire cosa ha funzionato, cosa va corretto e quale dovrebbe essere il prossimo step.

Per modifiche più ampie, puoi anche chiedere all’agente di procedere per fasi:

Prima aggiungi i ruoli dei trainer e le route protette per i trainer. Poi crea l’editor delle disponibilità. Infine collega le fasce orarie disponibili al flusso di prenotazione dei clienti.

In questo modo, anche una funzionalità complessa diventa una sequenza di passaggi facili da verificare.

Non dimenticare gli stati e i casi limite

Un’app non vive soltanto nel suo happy path. Cosa vede un utente che non ha ancora prenotazioni? Cosa succede se un pagamento fallisce? E se una fascia oraria non è più disponibile? Cosa vede un utente che prova ad accedere a una sezione riservata?

Puoi descrivere direttamente questi scenari nei prompt:

• “Mostra uno stato vuoto utile quando l'utente non ha prenotazioni.”
• “Disabilita le fasce orarie non disponibili e spiega perché non possono essere selezionate.”
• “Mostra un indicatore di caricamento durante l'invio della prenotazione.”
• “Se un utente non amministratore apre la route di amministrazione, reindirizzalo in modo sicuro.”
• “Rendi specifici i messaggi di validazione e posizionali accanto ai campi pertinenti.”

Sono piccoli dettagli, ma fanno una grande differenza tra un prototipo che funziona e un prodotto che sembra davvero pronto per essere utilizzato. Puoi inoltre chiedere agli agenti dedicati alla UX o alla sicurezza di analizzare un flusso esistente e suggerire o applicare miglioramenti.

Quando aggiungi i pagamenti, descrivi la regola commerciale

Per integrare i pagamenti, non devi spiegare come funziona Stripe. Devi spiegare che cosa stai vendendo e cosa succede dopo il pagamento. Indica almeno:

• prodotto o servizio
• prezzo
• valuta
• modello di fatturazione
• funzionalità disponibili dopo l’acquisto

Per esempio:

Consenti ai clienti di abbonarsi a €9,99 al mese. Gli abbonati possono prenotare sessioni premium, gestire l'abbonamento dal proprio account e vedere lo stato corrente della fatturazione. Inizia in modalità di test Stripe.

Nella modalità gestita predefinita, l’agente può creare un account Stripe gestito dopo averti chiesto alcune informazioni di base, come Paese e nome dell’attività. Può quindi configurare prodotti, prezzi, checkout e webhook, mentre la configurazione per ricevere i pagamenti può essere completata in seguito tramite il link di onboarding ospitato da Stripe.

Se preferisci utilizzare il tuo account Stripe, puoi richiedere la modalità BYOK. L’agente chiederà STRIPE_SECRET_KEY attraverso un prompt sicuro per le variabili d’ambiente e configurerà automaticamente il webhook.

I segreti rimangono sul server e non vengono inseriti né nella chat né nel codice generato.

Concludi con un prompt di revisione

Prima di pubblicare, puoi chiedere agli agenti di fare un ultimo passaggio sull’intera esperienza. Per esempio:

Esamina l'app come un cliente al primo utilizzo, un trainer e un amministratore. Controlla la navigazione, l'usabilità su mobile, le autorizzazioni, gli stati vuoti e l'intero flusso di prenotazione. Correggi i problemi evidenti senza cambiare la direzione visiva.

Questo tipo di prompt funziona perché definisce chi deve essere simulato, cosa deve essere controllato e quali limiti rispettare. Dopo aver verificato l’anteprima, puoi usare Pubblica per distribuire l’app sul relativo indirizzo coderblock.app oppure collegare un dominio personalizzato da Impostazioni → Domini.

Il prompt migliore è quello che lascia spazio all’AI

Non serve scrivere prompt lunghissimi per ottenere buoni risultati con Coderblock. Serve dare all’agente le informazioni che contano davvero: chi utilizzerà il prodotto, cosa deve poter fare, come devono funzionare i flussi, quali dati devono essere collegati, quali regole non possono essere violate e cosa deve succedere nei diversi scenari.

Il resto può essere costruito attraverso l’iterazione. Parti da un brief chiaro. Guarda cosa viene generato. Testa l’app. Poi continua con richieste piccole, concrete e verificabili.

È questo il vero vantaggio di lavorare con un AI coding agent: non devi sapere in anticipo come costruire il prodotto. Devi sapere cosa vuoi costruire.