Metodo PRP:dai a Claude il brief giusto per costruire bene

Un Product Requirement Prompt — un PRP — è un breve documento che scrivi prima di chiedere a Claude di costruire una funzione. Il metodo PRP: quattro sezioni, circa trecento parole, venti minuti per scriverlo — e trasforma due giorni di debugging in una-tre ore di implementazione pulita. È l'abitudine a più alta leva nello sviluppo assistito dall'AI, e quasi nessuno che inizia la usa.

"Claude, costruiscimi un flusso di registrazione" sembra un progresso. Non lo è. Questo articolo ti dà il metodo, le quattro sezioni e un vero PRP del mio prodotto — parola per parola — così stasera puoi copiarne la struttura.

Cos'è il metodo PRP?

L'AI non sostituisce il pensiero. L'AI sostituisce la digitazione. La digitazione non è mai stata il vincolo — lo era la progettazione di ciò che digiti. Quando dai a Claude un'istruzione vaga, riempie ogni vuoto con ipotesi: quale tabella del database usare, com'è strutturata la tua app, cosa significa "finito". Alcune di quelle ipotesi saranno sbagliate, e le pagherai in ore di debugging che non puoi permetterti tra sere e weekend.

Un PRP chiude i vuoti prima che inizi la costruzione. Non è opzionale. La differenza tra "Claude, costruiscimi un flusso di registrazione" e un PRP ben strutturato è la differenza tra due giorni a correggere spazzatura e venti minuti di implementazione pulita.

Le quattro sezioni di un PRP

Obiettivo. Cosa stai costruendo, in una frase. "Costruisci un flusso di registrazione che crea un utente, crea un'azienda, li collega e invia un'email di benvenuto."

Contesto. Tutto ciò che Claude deve sapere e non può dedurre: lo schema del tuo database, il tuo provider di autenticazione, il tuo servizio email, il tuo framework frontend, i pattern esistenti nel tuo codice, i link alla documentazione rilevante. Più contesto fornisci, meno Claude allucina e più l'output si avvicina a un livello da produzione.

Piano di implementazione. Uno schema passo per passo di ciò che la funzione deve fare. Non codice vero e proprio — quello è compito di Claude — ma abbastanza struttura perché Claude non si perda. Ti costringe a pensare la funzione prima di delegarla e dà a Claude dei binari su cui costruire.

Ciclo di validazione. Come saprai che la funzione funziona: i casi di test che eseguirai, i casi limite che devono essere gestiti. Anche i test può scriverli Claude — ma devi specificare cosa testare prima che Claude li scriva, altrimenti testerà le cose sbagliate.

Un vero PRP, parola per parola

Ecco com'era uno per una funzione che ho costruito in FIKR Space — una semplice pagina di preferenze per le notifiche email:

Obiettivo: Costruire una pagina di preferenze delle notifiche in cui gli utenti loggati possono scegliere quali tipi di notifiche email ricevere: riepilogo settimanale, aggiornamenti di prodotto, avvisi di sicurezza. Salvare le preferenze nel record dell'utente. Per impostazione predefinita, tutto attivo.

Contesto:

• Stack: React, TypeScript, Supabase, Tailwind.
• La tabella users esistente ha le colonne id, email, created_at. Serve aggiungere una colonna JSON notification_preferences con la forma { digest: bool, updates: bool, security: bool }.
• Il contesto di autenticazione fornisce già l'utente corrente tramite l'hook useAuth() in /hooks/useAuth.ts.
• La pagina sta in /settings/notifications. Il routing è già configurato.
• Seguire il pattern della pagina impostazioni esistente in /pages/settings/profile.tsx per layout e stile del form.

Piano di implementazione:

1. Aggiungere la colonna JSON notification_preferences alla tabella users tramite migration Supabase. Valore predefinito: tutti e tre impostati su true.
2. Creare il componente della pagina in /pages/settings/notifications.tsx.
3. Al montaggio, caricare da Supabase le preferenze dell'utente corrente.
4. Mostrare tre interruttori usando il componente <Switch> esistente.
5. Al cambio di un interruttore, applicare un debounce di 500ms, poi salvare su Supabase.
6. Mostrare una notifica toast al successo o al fallimento del salvataggio.
7. Gestire lo stato di caricamento mentre il fetch iniziale è in corso.

Ciclo di validazione:

• Accedere. Andare su /settings/notifications. Tutti e tre gli interruttori devono risultare attivi.
• Disattivarne uno. Aggiornare la pagina. L'interruttore deve restare disattivato.
• Scollegare la rete. Cambiare un interruttore. Deve comparire un toast di errore.
• Ricollegare. Cambiare di nuovo. Deve salvare e mostrare un toast di successo.

Sono circa trecento parole. Claude genera l'implementazione in meno di dieci minuti. Tempo totale da "voglio questa funzione" a "è live in produzione": forse novanta minuti, tra scrittura del PRP, generazione del codice, test manuali e deploy.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Cosa succede senza un PRP

Confrontalo con la stessa funzione senza. Scrivi a Claude "costruiscimi una pagina di preferenze delle notifiche". Produce qualcosa. Quel qualcosa non sa quale tabella del database usare, quindi se ne inventa una. Non conosce la tua libreria di componenti, quindi genera componenti nuovi che sembrano diversi dal resto dell'app. Non conosce le tue convenzioni di salvataggio, quindi salva a ogni tasto. Passi due ore a riscrivere la maggior parte di ciò che ti ha dato per adattarlo al tuo codice. La funzione esce in mezza giornata invece che in un'ora e mezza — e il codice che ottieni è per metà tuo e per metà un insieme di congetture di Claude cucite insieme.

Perché il PRP sembra pesante — e perché lo scrivi comunque

Il metodo PRP sembra pesante quando inizi. Sembra più lavoro che scrivere a Claude e sperare. La prima volta che ne salti uno e Claude genera millecinquecento righe da buttare, capirai. Venti minuti di scrittura ti fanno risparmiare da quattro a otto ore di pulizia per funzione, e nel corso di una costruzione completa questo si accumula nella differenza tra uscire in otto settimane e uscire in venti.

Scrivere a Claude sperando ha un nome e un finale prevedibile — ho scritto separatamente della trappola del vibe coding. In breve: la velocità senza struttura sembra un progresso fino al momento in cui non lo è più. Il PRP è il modo di tenere la velocità ed evitare il crollo.

E nota cosa ti impone in silenzio il PRP: pensare. Scrivere il piano di implementazione significa ripercorrere la funzione passo per passo prima che esista codice. Scrivere il ciclo di validazione significa decidere cosa vuol dire "funziona" prima di vedere qualcosa che sembra funzionare. Quel pensiero è il tuo lavoro — è la parte che l'AI non sa fare, e quella che il framework BUILD allena deliberatamente.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Cos'è un Product Requirement Prompt (PRP)?

Un PRP è un breve documento che scrivi prima di chiedere all'AI di costruire una funzione. Ha quattro sezioni — obiettivo, contesto, piano di implementazione e ciclo di validazione — e il suo compito è eliminare le ipotesi che Claude farebbe altrimenti sul tuo database, sulle tue convenzioni e su cosa significa "finito".

Quanto deve essere lungo un PRP?

Circa trecento parole per una funzione di media complessità, che richiedono circa venti minuti per scriverle. Ottieni una funzione funzionante in una-tre ore di costruzione invece delle stesse ore più due giorni di debugging in aggiunta.

Devo essere tecnico per scrivere un PRP?

No. Il piano è in linguaggio semplice, passo per passo, non codice — "controlla se l'email esiste già, crea l'utente, invia l'email di benvenuto." Descrivi cosa deve succedere e come lo verificherai; Claude gestisce l'implementazione. Conoscere a fondo il tuo prodotto conta molto più che conoscere la sintassi.

Quanto tempo fa davvero risparmiare il metodo PRP?

Da quattro a otto ore di pulizia per funzione. In una costruzione di otto settimane con una funzione importante a settimana, questo si accumula nell'uscire in otto settimane invece che in venti — stessi strumenti, stessa AI, disciplina diversa.