Ruolo: lente operativa, non costume

Il ruolo è una lente di lavoro. Non serve a travestire il modello da “guru”, “ninja” o “senior 10x”. Serve a chiarire quali competenze deve attivare, quali priorità deve seguire e quali trade-off deve privilegiare quando produce una risposta.

Perché questa lezione conta

Molti prompt iniziano con frasi enfatiche: “Agisci come il miglior sviluppatore al mondo”. Queste formule raramente migliorano l’output, perché non dicono al modello cosa valutare, cosa ignorare e come decidere in caso di conflitto.

Un ruolo operativo invece specifica:

• campo di competenza;
• criteri di priorità;
• livello di rischio accettabile;
• destinatario della risposta;
• cosa non deve fare.

Nel corso questo è il primo pezzo dell’anatomia del prompt: prima di fornire contesto e obiettivo, devi decidere da quale prospettiva vuoi che il modello lavori.

Ruolo debole e ruolo operativo

Ruolo debole:

Sei un programmatore esperto. Aiutami a migliorare questo codice.

Ruolo operativo:

Agisci come reviewer backend in una codebase TypeScript.
Priorità, in ordine:
1. correttezza del comportamento;
2. sicurezza e gestione input non fidati;
3. regressioni rispetto ai test esistenti;
4. leggibilità del diff.

Non proporre refactor estetici se non riducono un rischio concreto.

Il secondo ruolo non è più lungo per decorazione. Dice al modello come filtrare le possibili risposte.

Componenti di un buon ruolo

Competenza

Non basta dire “esperto”. Specifica l’area:

• reviewer frontend accessibilità;
• architetto software pragmatico;
• debugger backend HTTP;
• maintainer di libreria pubblica;
• docente che deve spiegare un concetto a principianti.

Ogni area cambia il tipo di risposta. Un reviewer sicurezza cercherà superfici d’attacco; un docente cercherà progressione didattica; un maintainer penserà a compatibilità e API pubbliche.

Priorità

Le priorità risolvono conflitti. Se chiedi “migliora performance e leggibilità”, il modello non sa quale sacrificare quando entrano in tensione. Scrivere l’ordine evita risposte generiche.

Esempio:

Priorità:
1. non cambiare comportamento pubblico;
2. ridurre duplicazione;
3. migliorare nomi solo se aiuta il refactor;
4. evitare nuove dipendenze.

Soglia di intervento

Un ruolo deve dire anche quando tacere. In una code review, commenti cosmetici possono creare rumore. In un debug, ipotesi non verificabili possono rallentare.

Segnala solo problemi che modificheresti prima del merge.
Metti il resto in "note non bloccanti" e limitale a massimo 3.

Laboratorio guidato

Trasforma tre ruoli vaghi in ruoli operativi.

Parti da questi esempi:

1. “Sei un senior developer”;
2. “Sei un esperto di sicurezza”;
3. “Sei un insegnante bravo”.

Per ciascuno scrivi:

• competenza specifica;
• priorità ordinate;
• cosa deve ignorare;
• formato di risposta;
• soglia per segnalare un problema.

Poi applica i ruoli allo stesso task e confronta gli output.

Output atteso

Una libreria di ruoli riusabili per i task ricorrenti del tuo lavoro.

Esempio di struttura:

Ruolo: reviewer di diff TypeScript
Usalo quando: devo valutare una PR prima del merge
Priorità: correttezza, sicurezza, regressioni, manutenibilità
Ignora: stile minore, preferenze personali, refactor fuori scope
Output: finding ordinati per severità con file/riga/motivo/fix

Checklist di verifica

• il ruolo contiene competenze concrete, non aggettivi;
• le priorità sono ordinate;
• il ruolo dice cosa ignorare;
• il ruolo è riusabile in più prompt;
• l’output cambia in modo utile rispetto a un prompt senza ruolo.

Errori comuni

Ruolo teatrale. “Sei un genio assoluto” non specifica un comportamento verificabile.

Ruolo troppo largo. “Sviluppatore full stack” può voler dire tutto e niente. Meglio un ruolo stretto per un task stretto.

Ruolo senza priorità. Se non indichi cosa conta di più, il modello bilancia a modo suo.

Collegamenti

• Modulo: Anatomia del prompt operativo — lezione 6 del corso.
• Lezione precedente: Cosa l’LLM non sa: aggiornamento, dominio, repo.
• Prossima lezione: Contesto: cosa esiste, cosa serve sapere, cosa non inventare.