La collaborazione fra i livelli¶
I capitoli 3-6 hanno spiegato cosa contiene ciascuna configurazione, per ognuna hanno risposto alla domanda «qui cosa ci scrivo?». Questo capitolo guarda la configurazione nel suo insieme, non più una sua parte alla volta. La stessa regola scritta in parti diverse funziona in modi diversi, perché cambia l'ambito d'applicazione. Dove mettere una regola è una scelta che riguarda l'organizzazione complessiva, non solo la sua scrittura. Per capire il punto in cui ha senso inserirla bisogna partire dall'ambito d'uso di una regola, ad esempio l'indicazione sull'uso di una certa terminologia tecnica può stare nella configurazione generale, se vale in tutti i lavori. Oppure in quella di un progetto, se vale solo per un certo cliente. Una regola sul metodo di verifica delle fonti può stare nella generale, se è il modo abituale di lavorare. Oppure in quella di un progetto editoriale, dove la verifica delle fonti è centrale. La regola scritta è la stessa, ma a seconda di dove finisce vale per tutto o solo per un caso.
Il capitolo ha 5 sezioni. La prima descrive i tre modi in cui due regole presenti in livelli diversi possono interagire tra loro. La seconda mostra com'è fatta tipicamente una configurazione per i modi di lavorare più comuni. La terza spiega come la configurazione cambia nel tempo. La quarta tratta i casi in cui la stessa regola si trova scritta in più di un posto, e come gestirli. La quinta chiude con uno o due esempi completi.
Come si combinano le configurazioni¶
I tre modi descritti in questa sezione sono già stati introdotti al capitolo 6 a proposito di come gli stili si combinano con i livelli sottostanti. Qui vengono ripresi in forma generale, valida per qualsiasi coppia di livelli.
Regole presenti in punti diversi possono combinarsi in tre modi.
Il primo è il completamento. Due regole sullo stesso argomento dicono cose diverse, su aspetti diversi e i contenuti si sommano. Prendendo l'esempio di un utente specializzato in un certo ambito, nella configurazione generale dice di usare l'italiano con le modalità di scrittura di quel settore, in quella di un progetto editoriale aggiunge la terminologia tecnica e le convenzioni delle pubblicazioni scientifiche sempre di quel settore. Non c'è sovrapposizione, le due indicazioni riguardano aspetti che coesistono. È il caso più semplice, perché non c'è competizione.
Il secondo è il rafforzamento. Una regola riprende un'indicazione già data altrove e la specializza per un caso particolare. Ad esempio, la configurazione generale indica «registro divulgativo professionale»; in un progetto di formazione aziendale per ingegneri si specializza in «registro divulgativo fra colleghi tecnici esperti, esempi tratti dall'ambito industriale, niente paragoni dalla vita quotidiana». La regola generale resta valida, quella specifica la rende più precisa per quel contesto. È diverso dal copiare la stessa frase in due istruzioni. Ripetere la stessa indicazione non rafforza nulla, produce solo ridondanza.
Il terzo è l'alternativa. Una regola dice qualcosa di diverso da un'altra scritta altrove, e la regola di prevalenza vista al capitolo 2 fa vincere la più specifica. Ad esempio, la configurazione generale dice «rispondere sempre in italiano»; in un progetto si imposta invece «rispondere in inglese, il cliente lavora a Boston». Per quel progetto vince l'inglese, fuori dal progetto resta l'italiano. È un uso legittimo del meccanismo, con un rischio da tenere presente. Quando un'alternativa è impostata e resta attiva per mesi, è facile dimenticare la regola di partenza scritta nella generale. Il comportamento di Claude appare inatteso, ma è coerente con quanto è stato scritto.
Questi tre modi tornano nelle sezioni che seguono.
Configurazioni globali per profilo¶
Una configurazione complessiva è fatta in modo diverso a seconda di chi la costruisce. Cambia quali livelli si usano, cambia quante regole si mettono in ciascuno, cambia dove si concentra la maggior parte del lavoro. Non è una scelta fatta livello per livello in modo separato, è una scelta che si fa nel complesso, perché dipende dal modo in cui si lavora con Claude. A seconda del modo di lavorare può anche essere corretto non usare uno dei livelli.
Di seguito tre profili di configurazione, presentati come ipotesi rappresentative. Chi struttura il proprio lavoro intorno a progetti continuativi, chi lavora con agenti Cowork su Desktop, chi usa Claude in conversazioni isolate. La sezione descrive la configurazione tipica di ciascuno. Un paragrafo di chiusura tratta il profilo misto, che combina elementi dei tre.
Lavoro per progetti¶
Rientra in questo profilo chi struttura in modo continuativo il proprio lavoro intorno a progetti.
- Un consulente con più clienti, ognuno con un proprio progetto.
- Un formatore aziendale con più aziende seguite in parallelo.
- Un ricercatore con filoni di indagine distinti, ognuno con materiali, terminologia, output suoi.
- Un editore con più collane in lavorazione.
I casi sono diversi, ma il principio è lo stesso. Il progetto è il modo principale di organizzare il lavoro, e ogni progetto ha un suo contesto che dura nel tempo.
Le istruzioni di progetto contengono la maggior parte del lavoro di configurazione, e per questo sono dense e specifiche. Ogni progetto ha le sue regole su materiali di lavoro, terminologia tecnica del settore, modalità di output, vincoli editoriali, eventuali specificità del cliente o dell'oggetto. Possono essere lunghe, articolate in più sezioni, e valgono soltanto per quel progetto.
Le istruzioni generali, in questo profilo, sono tendenzialmente leggere, contenendo solo le regole davvero trasversali, quelle che attraversano tutti i progetti. La lingua, il registro di base, qualche convenzione di metodo che resta valida ovunque. Non contengono dettagli sui temi di lavoro né riferimenti a clienti, perché ogni progetto si fa carico del suo contesto.
Cowork può comparire in coppia con i progetti per chi usa Desktop e gli agenti. Le istruzioni Cowork specializzano un agente per il tipo di lavoro del progetto, e si combinano con l'istruzione di progetto. Quando il lavoro con gli agenti è centrale, si entra nel profilo successivo.
Gli stili restano marginali in questo profilo, perché il progetto già definisce il registro di output. Possono tornare utili per piccole regolazioni dentro un progetto, come l'alternanza fra Conciso ed Esplicativo a seconda del compito, ma non sono al centro della configurazione.
È la scelta tipica di chi ha trovato nel meccanismo dei progetti il modo di tenere separati i contesti di lavoro, senza dover appesantire le generali con regole che valgono solo per alcuni casi.
Lavoro con agenti Cowork¶
Rientra in questo profilo chi usa Claude Desktop con gli agenti Cowork come modo principale di lavorare. Gli agenti sono piccoli assistenti specializzati, ciascuno con la sua istruzione che descrive cosa fa e come. Uno sviluppatore può avere agenti per analizzare codice, eseguire test, aggiornare documentazione. Un consulente può avere agenti specializzati su documenti dei clienti. Un analista può avere agenti che producono report periodici dai file locali.
Le istruzioni Cowork contengono la maggior parte del lavoro di configurazione. Ogni agente ha la sua istruzione, che definisce ruolo, file di lavoro, modalità di esecuzione, vincoli operativi. Gli agenti possono essere molti, ciascuno con istruzioni specifiche, e tipicamente fanno riferimento a file locali sul disco.
Le istruzioni di progetto possono comparire in coppia con quelle Cowork, quando un cliente specifico ha un proprio progetto di lavoro. In quel caso le istruzioni di progetto definiscono il contesto del cliente, e quelle Cowork specializzano gli agenti per quel lavoro. Quando invece gli agenti sono trasversali a più clienti, le istruzioni di progetto sono leggere o assenti.
Le istruzioni generali sono medie. Contengono preferenze trasversali come lingua e registro, eventualmente convenzioni di metodo che valgono sia per gli agenti che per le altre conversazioni. Non sono il livello principale, ma non sono nemmeno marginali come nel profilo precedente, perché chi usa gli agenti Cowork potrebbe voler lavorare anche in conversazioni libere, dove le generali contano.
Gli stili di scrittura, secondo la dinamica vista al capitolo 6, possono propagarsi anche agli output degli agenti. Restano comunque uno strumento operativo per la Chat, non sono il livello dove si concentra la configurazione di questo profilo.
La configurazione che ne risulta è centrata sugli agenti Cowork. Cowork denso, generali medie, progetti densi solo per clienti specifici, stili come strumento di Chat. È la scelta tipica di chi ha trasformato Claude in un assistente automatizzato per attività ricorrenti, dove gli agenti sostituiscono il dialogo libero su compiti specifici.
Lavoro per output singoli¶
Rientra in questo profilo chi usa Claude in conversazioni isolate, senza che ci sia un contesto durevole sopra. Le chat sono occasionali, ognuna nasce per un compito e si chiude lì. Vale per chi resta in Chat, per tradurre un testo, verificare un fatto, scrivere un'email difficile. Vale anche per chi su Desktop usa Cowork in modo puntuale, lanciando un agente per un compito specifico senza un'attività continuativa attorno.
Le istruzioni generali contengono la maggior parte della configurazione. Tutte le preferenze, le regole di lavoro, le modalità di risposta, eventualmente il formato di output preferito. Quando ogni chat parte da zero e si chiude in sé stessa, l'unico modo di avere una configurazione stabile è metterla nelle generali.
Le istruzioni di progetto sono assenti o usate poco. Quando il lavoro non è strutturato attorno a temi durevoli, i progetti non danno vantaggi rispetto al lavoro in Chat libera. Qualcuno crea un progetto per casi che si ripetono spesso, ma è un'eccezione.
Cowork tipicamente non rientra in questo profilo. Gli agenti sono pensati per un'attività continuativa, e chi lavora per output singoli non ha operazioni ricorrenti da affidare. L'unica eccezione è chi su Desktop usa occasionalmente un agente per un compito puntuale, come detto sopra.
Gli stili di scrittura acquistano un ruolo importante in questo profilo. Servono per modulare al volo l'output della singola chat, uno stile più conciso per le risposte rapide, uno più esplicativo per le spiegazioni, uno specifico per le email. Sono utili proprio perché la configurazione cambia frequentemente fra una chat e l'altra.
La configurazione che ne risulta concentra tutto su generali e stili. Generali dense, progetti assenti o rari, Cowork tipicamente non usato, stili come strumento operativo. È la scelta tipica di chi usa Claude come strumento di lavoro puntuale, senza una struttura organizzativa attorno.
In pratica, molti utenti non rientrano puramente in uno solo dei tre profili. Possono avere alcuni progetti densi per certi clienti, e usare Claude in conversazioni libere per il resto del lavoro. Possono avere uno o due agenti Cowork per attività ricorrenti, e poi lavorare in Chat per tutto il resto. La configurazione di chi sta in mezzo combina elementi dei tre profili, in proporzioni che dipendono dal lavoro che si fa. La cosa importante è capire come si lavora di solito, e di conseguenza dove serve mettere le regole.
Promozione e retrocessione delle regole¶
La configurazione non si fa una volta e basta. Cambia nel tempo, perché cambia il modo di lavorare e perché l'uso quotidiano fa scoprire cose nuove. Una regola scritta in un certo punto può rivelarsi al posto sbagliato dopo qualche settimana. Capirlo, e spostarla, fa parte della manutenzione della configurazione.
Il primo movimento possibile è la promozione. Una regola scritta nelle istruzioni di un progetto si rivela, con il tempo, utile per tutti i progetti. Magari riguarda un modo di formattare l'output, una preferenza sulle citazioni, una convenzione sui file da produrre, un certo modo di chiudere le risposte. Quando ci si accorge di ripeterla in più progetti, c'è il segnale che andrebbe spostata in alto, nelle generali, dove vale automaticamente per tutto.
Va considerata anche l'azione contraria, la retrocessione. Una regola scritta nelle istruzioni generali si rivela, con il tempo, valida solo per certi tipi di lavoro. Magari una convenzione sul formato delle date vale solo per i progetti editoriali, non per quelli di formazione aziendale. Magari una preferenza sul registro vale solo per i lavori con clienti esterni, non per quelli interni. In questi casi conviene scendere al livello giusto, perché tenere la regola nelle generali la applica anche dove non è opportuno.
Riconoscere questi spostamenti richiede di rileggere ogni tanto la propria configurazione, soprattutto dopo qualche mese di uso. I segnali da cercare sono concreti. Una regola che si trova ripetuta in più progetti è una candidata alla promozione. Una regola nelle generali che richiede continui distinguo nelle istruzioni di progetto («tranne che per il progetto X», «escluso il caso Y») è una candidata alla retrocessione.
Tenere viva questa attenzione vuol dire avere una configurazione che si adatta al lavoro effettivo. Non solo a quello che si pensava di fare quando si è scritta inizialmente.
Convivenza e ridondanza¶
Una stessa regola può trovarsi scritta in più posti della configurazione. A volte è una svista, altre volte una scelta deliberata. Distinguere i due casi è importante, perché tenere la stessa regola in più posti senza un motivo crea problemi quando arriva il momento di modificarla.
Il principio operativo è uno solo. Si scrive una regola in un certo livello solo quando dice qualcosa di diverso da quanto vale già a un livello precedente. Se le generali fissano l'italiano e il progetto è in italiano, non serve riscriverlo. La regola delle generali si applica automaticamente. Se il progetto è in inglese, allora va scritto.
Non tutte le apparenti ripetizioni sono ridondanze, come visto trattando il meccanismo del rafforzamento nella prima sezione, pure una regola di progetto che dice qualcosa di diverso dalle generali è un'alternativa. Sono casi in cui due regole esistono in due livelli perché ciascuna porta un contributo distinto.
La ridondanza tossica è quando la stessa regola, identica, è scritta in due posti senza che il secondo aggiunga nulla. Capita per «sicurezza», o perché si è dimenticato di aver scritto la regola da un'altra parte. Oppure è presente in due livelli diversi senza correlazioni, capita quando si scrive a distanza di tempo senza verificare cosa c'è già. In queste situazioni il problema non è immediato, si presenta quando arriva il momento di modificare la regola, perché va aggiornata ovunque sia scritta, altrimenti la configurazione resta incoerente.
Quando una ridondanza non necessaria emerge, vale la pena ripulirla. La regola va lasciata nel livello dove serve davvero, e tolta dagli altri. Se vale per tutti i lavori si lascia nelle generali. Se vale solo per un progetto si lascia nelle istruzioni di progetto. Tenerla in un solo posto rende la configurazione più chiara e più facile da mantenere.
Scenari di configurazione completa¶
La sezione precedente ha descritto i profili di configurazione in termini generali. Qui si vedono due scenari completi, due esempi concreti di come la configurazione si presenta per un lavoro reale. Servono come ancora per chi sta costruendo o rivedendo la propria, e mostrano come i meccanismi visti nelle sezioni precedenti si combinano nella pratica.
Consulente di formazione con più clienti¶
Il primo scenario è quello di un consulente che si occupa di formazione aziendale e lavora con più clienti in parallelo. Tre o quattro aziende attive, ciascuna con il suo settore, i suoi prodotti, il suo linguaggio interno. Il profilo è quello del lavoro per progetti, descritto nella sezione precedente. La maggior parte della configurazione sta nei progetti, le generali sono leggere.
Nelle generali ci sono poche regole, quelle che valgono per qualunque cliente. La lingua italiana, il registro divulgativo professionale, la preferenza per output strutturati con paragrafi narrativi più che con liste puntate, una nota sul fatto di evitare frasi enfatiche o di tipo pubblicitario.
Ogni cliente ha le sue istruzioni di progetto, dense e specifiche. Per un cliente del settore industriale c'è una descrizione dell'azienda, della linea di prodotto principale, dei termini tecnici da preferire, delle modalità di comunicazione interne adottate. Per un cliente del settore finanziario c'è una descrizione del posizionamento, della terminologia di compliance, delle convenzioni per i documenti tecnici. Le istruzioni di progetto contengono la maggior parte della configurazione di questo profilo, possono arrivare a varie pagine ciascuna.
Cowork non rientra in questo scenario. Il consulente lavora interamente in Chat, dove i progetti gli danno il contesto necessario per ogni cliente.
Gli stili di scrittura sono usati a volte per aggiustamenti puntuali. Uno stile per le email ai clienti, più sintetico e formale. Uno stile per i documenti formativi, più articolato. Niente stili che riguardino il contenuto, perché il contenuto è già nei progetti.
La configurazione complessiva è asimmetrica. Generali leggere e quasi invariabili, progetti densi e diversi tra loro, stili come strumento di adattamento dell'output al singolo compito solo quando necessario. Il consulente sa che ogni nuovo cliente comporta un nuovo progetto da configurare, ma sa anche che le generali resteranno stabili.
Sviluppatore con agenti Cowork¶
Il secondo scenario è quello di uno sviluppatore freelance che lavora con Claude Desktop e usa gli agenti Cowork per automatizzare i compiti ricorrenti del proprio lavoro. Code review, generazione di test, produzione di documentazione, refactoring. Il profilo è quello del lavoro con agenti Cowork. La maggior parte della configurazione sta nelle istruzioni Cowork, una per agente.
Nelle generali ci sono preferenze trasversali. La lingua italiana per le risposte conversazionali, lo stile sintetico nelle spiegazioni tecniche, una lista delle tecnologie preferite (linguaggio di programmazione principale, framework usati), una nota sul fatto di motivare brevemente le scelte tecniche proposte. Le generali servono anche per le chat libere che lo sviluppatore apre fuori dagli agenti, per chiedere consigli rapidi o spiegazioni.
Le istruzioni di progetto sono presenti per il cliente continuativo con cui lavora da tempo, e contengono il contesto del prodotto su cui lavora. Per altri clienti più occasionali non ha progetti dedicati. Cowork e progetti si combinano per le attività legate al cliente continuativo, dove gli agenti operano sui suoi file.
Le istruzioni Cowork sono il livello principale. Lo sviluppatore ha configurato quattro agenti specializzati. Un agente per la code review, che esamina pezzi di codice e segnala problemi. Un agente per la generazione di test, che produce test unitari da specifiche. Un agente per la documentazione, che produce docstring e file README da codice esistente. Un agente per il refactoring, che propone migliorie strutturali. Ogni agente ha una propria istruzione dettagliata su cosa fare, quali file di lavoro toccare, quali vincoli rispettare.
Gli stili di scrittura sono usati raramente. Uno stile «sintetico» per quando lo sviluppatore lavora a problemi rapidi nella Chat, dove vuole risposte stringate e codice essenziale. La propagazione agli agenti Cowork, vista al capitolo 6, non è importante in questo scenario. Gli agenti hanno già nelle loro istruzioni Cowork specifiche regole su come scrivere gli output.
La configurazione complessiva è centrata sugli agenti. Generali medie e stabili, un progetto attivo per il cliente continuativo, Cowork denso con più agenti, stili come strumento puntuale. Lo sviluppatore aggiunge agenti quando si presentano nuove esigenze ricorrenti, e modifica le istruzioni dei singoli agenti quando cambiano i requisiti del lavoro.
I due scenari mostrano configurazioni diverse, ognuna sensata per il proprio modo di lavorare. Non c'è una configurazione giusta in assoluto, c'è quella che corrisponde al lavoro che si fa. Costruire la propria configurazione vuol dire decidere quali livelli usare, come distribuire le regole, come gestire il cambiamento nel tempo. L'uso quotidiano fa il resto, mostrando dove serve aggiustare e dove la configurazione tiene.