Panoramica delle persona

Le persona sono uno dei concetti più potenti di CodeCourier. Una persona è una configurazione di agente IA denominata e riutilizzabile che definisce esattamente come si comporta un agente quando partecipa a un workflow run o a una sessione di sandbox. Ogni persona specifica lo strumento CLI da usare, il modello, il livello di thinking effort, istruzioni personalizzate, quali skill sono disponibili, quali command e script vengono iniettati, e opzionalmente un documento di contesto associato. Creando persona su misura, passi da un prompting ad-hoc a un approccio sistematico e ripetibile allo sviluppo assistito dall’IA.

Perché le persona sono importanti

Senza persona, ogni workflow run parte da zero. Dovresti specificare manualmente il modello, scrivere system prompt e configurare gli strumenti ogni volta. Le persona risolvono questo problema incapsulando tutte queste decisioni in un’identità riutilizzabile a cui si può fare riferimento per nome in tutto il progetto.

Considera uno scenario reale: il tuo team ha uno standard di codice che richiede una type safety rigorosa, preferisce pattern funzionali e esegue sempre ESLint prima del commit. Invece di ripetere queste istruzioni in ogni prompt, crei una persona “Senior TypeScript Designer” con queste regole incorporate nelle sue istruzioni. Ogni workflow che usa questa persona eredita automaticamente lo stesso comportamento.

Tipi di persona

Ogni persona ha un tipo che determina il suo ruolo all’interno di una pipeline di workflow. CodeCourier definisce dieci tipi di persona, ciascuno progettato per una fase specifica del processo di sviluppo:

Designer

L’agente di coding principale. I designer ricevono un task prompt e lo implementano direttamente nell’ambiente sandbox. Scrivono codice, creano file, installano dipendenze e producono il deliverable effettivo. La maggior parte dei workflow inizia con uno step designer.

Checker

Un agente di review basato su verdetto che valuta l’output del designer. I checker esaminano le modifiche al codice, eseguono test se configurato, e producono un verdetto pass/fail con feedback. Quando un checker respinge il lavoro, il designer può tornare indietro e iterare in base al feedback, creando un loop design-check che migliora automaticamente la qualità.

Optimizer

Un agente specializzato focalizzato su refactoring e miglioramento delle performance. Gli optimizer prendono codice esistente e lo migliorano senza cambiarne la funzionalità. Cercano opportunità per ridurre la duplicazione, migliorare la leggibilità, ottimizzare la dimensione del bundle e applicare le best practice.

Prompter

Un agente di prompt engineering che trasforma istruzioni vaghe e informali in prompt chiari e strutturati con criteri di accettazione espliciti. Eseguire un prompter prima di uno step designer può migliorare drasticamente la qualità dell’implementazione risultante, garantendo che il designer riceva istruzioni non ambigue.

Investigator

Un agente di ricerca che analizza a fondo la codebase per comprendere un problema o una richiesta di funzionalità prima che inizi qualsiasi implementazione. Gli investigator esplorano le strutture dei file, leggono il codice esistente, tracciano le dipendenze e producono un riepilogo dei risultati che gli agenti successivi possono usare come contesto.

Planner

Un agente di architettura che analizza le codebase e crea valutazioni strutturate. Il planner esamina la codebase, identifica problemi e work item, e produce output azionabili che possono essere eseguiti passo dopo passo. Questo tipo alimenta le issue session dedicate di CodeCourier.

Deep-Dive

Un agente di analisi intensiva progettato per problemi complessi e multiforme che richiedono una comprensione approfondita della codebase. Il tipo deep-dive è simile all’investigator ma più approfondito nell’ambito - viene tipicamente impiegato per analisi architetturali, investigazioni di root-cause che attraversano molti sottosistemi, o problematiche trasversali dove una scansione superficiale perderebbe dipendenze critiche. Le sessioni deep-dive in genere durano più a lungo e con un thinking effort più alto rispetto alle sessioni investigator standard.

Reviewer

Un agente di code review specializzato focalizzato su sicurezza, manutenibilità e design pattern. Il reviewer differisce dal checker in un modo fondamentale: non produce verdetti pass/fail. Produce invece feedback di review dettagliato e sfumato - osservazioni, suggerimenti, preoccupazioni ed elogi - su cui un umano o un agente successivo può agire. Usa il tipo reviewer quando vuoi un feedback qualitativo ricco piuttosto che un gate binario.

Custom

Un tipo libero per persona che non rientrano in nessuna delle categorie standard. Il tipo custom non impone aspettative strutturali sul comportamento dell’agente - si comporta esattamente come dettano le sue istruzioni, skill e contesto. Usa questo tipo per agenti altamente specializzati come scrittori di documentazione, assistenti di migrazione, generatori di changelog, o qualsiasi altro ruolo che richieda la massima flessibilità senza conformarsi a un archetipo predefinito.

Come le persona si relazionano ai workflow

I workflow in CodeCourier sono sequenze di step, e ogni step può essere alimentato da una persona. Il tipo di workflow Persona Pipeline è progettato specificamente per questo: selezioni una sequenza di persona, e ciascuna viene eseguita in ordine all’interno dello stesso ambiente sandbox. L’output di una persona diventa il contesto per la successiva.

Ad esempio, una persona pipeline potrebbe essere così:

1. La persona Investigator analizza la codebase e documenta l’architettura rilevante
2. La persona Prompter riscrive la richiesta dell’utente in una specifica tecnica dettagliata
3. La persona Designer implementa la feature in base al prompt affinato
4. La persona Checker revisiona l’implementazione e approva o richiede modifiche
5. La persona Optimizer ripulisce e refattorizza il codice finale

Ogni step in questa pipeline usa una persona diversa, potenzialmente con un modello diverso, set di skill diversi, command e script iniettati diversi, e istruzioni su misura per il proprio ruolo.

Come le persona si relazionano alle sandbox

Quando un workflow run viene eseguito, ogni step di persona viene assegnato a una sandbox. La sandbox fornisce un ambiente cloud E2B isolato con un filesystem Linux completo, accesso a internet e strumenti CLI installati. La configurazione della persona determina quale strumento CLI viene eseguito nella sandbox (Claude Code, OpenCode, Codex o altri) e come quello strumento si comporta (modello, istruzioni, skill, command, script e contesto).

I run step nel database tracciano quale persona ha eseguito ogni step, abilitando analisi per persona come tassi di successo, iterazioni medie, ripartizioni dei costi, punteggi di qualità nel tempo e timeline di attività.

Capacità

Le persona possono essere configurate con:

• Selezione dello strumento CLI - Scegli tra Claude Code, OpenCode, Codex o altri strumenti supportati
• Selezione del modello - Scegli il modello LLM specifico (ad es., claude-opus-4-6, claude-sonnet-4-6)
• Thinking effort - Controlla quanto reasoning applica il modello (low, medium, high, max)
• Istruzioni personalizzate - Testo libero che modella il comportamento dell’agente
• Assegnazione skill - Scegli quali skill (pacchetti di conoscenza di dominio) sono disponibili
• Iniezione command - Seleziona shell command e alias da iniettare nella sandbox
• Iniezione script - Seleziona script eseguibili da iniettare nella sandbox
• Binding del contesto - Associa un documento Context la cui versione attiva viene anteposta alla configurazione della sandbox
• Iniezione learning - Attiva o disattiva l’iniezione dei learning compilati dai run passati
• Toggle abilita/disabilita - Disabilita temporaneamente una persona senza eliminarla

Le persona non controllano le impostazioni dell’infrastruttura della sandbox come memoria, CPU o timeout - queste sono configurate a livello di workflow o di run.

Versioning delle persona

Le persona supportano un sistema di versioning integrato. Ogni volta che salvi modifiche significative alla configurazione o alle istruzioni di una persona, viene creata una nuova versione invece di sovrascrivere quella precedente. Ogni record di versione porta un numero version, un parentPersonaId che punta alla versione precedente, e un flag isLatest che indica se è la versione attualmente attiva.

Questo significa che puoi iterare in sicurezza sulle istruzioni di una persona e tornare sempre a una versione precedente se una modifica produce risultati peggiori. La cronologia delle versioni è visibile dalla pagina di dettaglio della persona, con una vista diff per confrontare le versioni fianco a fianco.

Prossimi passi