Perché guido l'IA a scrivere al livello di seconda media

25 giugno 2026 · 7 min di lettura

Guido l'IA a scrivere al livello di seconda media ancorandola a ELA7, lo standard linguistico Common Core statunitense per la settima classe (grade 7), il livello di scrittura atteso da un dodicenne. Costringe a frasi precise e concise ed elimina il vocabolario ricercato, così ticket e documenti di design escono scorrevoli e pronti all'azione.

Riuscivo a individuare i ticket scritti dall'IA nel nostro backlog senza controllare chi li avesse aperti. Erano quelli farciti di parole che nessuno userebbe mai in uno standup ("leverage", "utilize", "robust"), incastonate in frasi che dovevi leggere due volte.

Studiare lo standard mi ha insegnato una cosa in cui ora credo per ogni tipo di scrittura: il documento più chiaro che produco è anche il prompt migliore che posso dare a un'IA. La maggior parte delle persone fa l'opposto. Levigano la prosa per sembrare intelligenti e poi danno in pasto alla macchina istruzioni sciatte, chiedendosi perché l'output somigli a una brochure.

Ecco l'assunzione che vale la pena mettere in discussione: che i lettori intelligenti vogliano prosa sofisticata. Non è così. Lo stakeholder che scorre il tuo design doc vuole qualcosa di conciso e scorrevole. L'ingegnere che apre una user story vuole capirla senza dover spendere vera concentrazione per decifrarla. Le parole difficili spendono l'attenzione del lettore senza restituire nulla in cambio.

Cosa dice davvero ELA7

ELA sta per English Language Arts. Gli standard Common Core definiscono, classe per classe, cosa gli studenti americani dovrebbero saper leggere e scrivere. Una riga dello standard linguistico per la settima classe fa gran parte del lavoro al posto mio. L.7.3 chiede a chi scrive di "scegliere un linguaggio che esprima le idee in modo preciso e conciso, riconoscendo ed eliminando la prolissità e la ridondanza." È un'istruzione di editing più affilata di quanto la maggior parte delle guide di stile riesca a mettere insieme in un intero capitolo.

Perché la settima classe e non la quinta? Quando imparavo qualcosa di nuovo, chiedevo all'IA di "explain like I'm 5" (ELI5, spiegamelo come se avessi 5 anni). Funziona, ma taglia via troppo. ELA7 sta a metà tra il linguaggio per bambini e un paper accademico. Mantiene il contenuto reale e scarta l'ornamento.

Quando ho spostato i miei prompt di apprendimento da ELI5 a ELA7, le spiegazioni hanno smesso di sembrare cartoni animati e hanno iniziato a suonare come un collega brillante che ti spiega la cosa davanti a un caffè.

C'è un dettaglio importante per l'obiezione che affronto più avanti: lo stesso standard (L.7.6) si aspetta che gli studenti usino con precisione "parole ed espressioni specifiche del dominio". ELA7 non ti dice di eliminare i termini tecnici. Prende di mira la frase che li circonda.

Perché "suonare intelligenti" costa caro a chi legge

Il meccanismo è semplice. Ogni parola rara e ogni proposizione incassata aggiunge un costo di elaborazione; i linguisti lo chiamano dependency distance. Il lettore tiene l'inizio della tua frase nella memoria di lavoro finché non arriva la fine a completarla, e il vocabolario ricercato e i preamboli più lunghi allungano quella distanza.

Ho pagato quella tassa due volte. Le sessioni di refinement si allungavano perché il team doveva fermarsi a decifrare cosa un PBI troppo ricercato stesse davvero chiedendo di costruire. E le mie proposte tornavano indietro piene di commenti dei miei manager, che mi chiedevano di chiarire punti che sembravano complessi solo perché li avevo scritti così. Entrambe le cose bruciavano tempo che non avevamo.

Vale la pena nominare anche un motivo più profondo. Molta scrittura ricercata è una mossa di status. Cerchiamo la parola più grande perché segnala competenza. A chi conosce davvero l'argomento segnala l'opposto, e allo stakeholder che voleva solo la decisione e la data non segnala proprio niente.

Come uso ELA7 con l'IA

Gestisco backlog in kanban e scrum dal 2015, scrivendo i PBI (product backlog item) e i criteri di accettazione che li riempiono. Da quando sono passato al management in Unity Technologies nel 2021, i documenti sono diventati più grandi: proposte tecniche, strategia ingegneristica, documenti di requisiti di prodotto scritti insieme ai product manager. Sono partito come ingegnere del software, quindi so cosa si prova ad aprire un PBI troppo ricercato e doverlo decifrare prima ancora di poter iniziare.

Quando ChatGPT è diventato utilizzabile all'inizio del 2023, gli ho affidato quel lavoro sul backlog. Le bozze tornavano troppo ricercate. Riconoscibili a colpo d'occhio. Il problema non era mai la lunghezza di un ticket, era la scelta delle parole. Una volta imparato lo standard, ho aggiunto un'istruzione a quei prompt.

Riscrivi questo ticket usando il linguaggio ELA7 (Common Core USA,
settima classe): preciso, conciso, senza prolissità, senza parole
rare usate per effetto. Mantieni tutti i termini di dominio. Poi
verifica il risultato rispetto a ELA7 e segnala ogni frase che non
supera il test.

Il cambiamento è stato immediato. I ticket sono diventati più brevi e più semplici. I criteri di accettazione si leggevano come passi che una persona poteva seguire, non come clausole di un contratto. Il backlog è diventato qualcosa che qualsiasi ingegnere del team poteva prendere in mano e usare, invece di un documento che solo l'autore e uno o due specialisti riuscivano a decifrare.

Nominare un livello scolastico concreto funziona meglio che dire al modello di "scrivere in modo semplice". Nei miei prompt, "semplice" cambiava a malapena l'output; il modello non aveva un bersaglio preciso a cui puntare. "ELA7" gli ha dato un obiettivo specifico, e le bozze tornavano più brevi e più chiare, di solito già pulite abbastanza da pubblicare senza un secondo passaggio.

Non è solo banalizzare il lavoro?

Alcuni dei miei ingegneri più senior si sono opposti. I ticket, dicevano, banalizzano il lavoro e perdono precisione. È la versione più forte dell'obiezione, e in parte hanno ragione.

La precisione conta. Un termine di dominio porta spesso un'informazione che nessuna frase semplice può sostituire, ed eliminarlo per sembrare più amichevoli farebbe perdere significato reale. Se ELA7 volesse dire "elimina il vocabolario tecnico", avrebbero ragione a combatterlo.

Ma non è così. Lo standard mantiene i termini di dominio (è quello che dice L.7.6) e va a caccia di prolissità, parole rare usate per effetto e frasi costruite per fare colpo. Così ho tenuto duro.

L'argomentazione che ho fatto allora è la stessa che faccio ancora oggi: l'intero team ha bisogno di una comprensione chiara del lavoro. Una versione che solo pochi eletti possono decifrare fallisce quel test. Chiamare "precisione" la versione più densa è un errore. È un cancello attorno alla conoscenza, e i cancelli rallentano tutti, incluso lo specialista la prossima volta che è lui a dover fare onboarding.

Dove finisce la regola

ELA7 è per i documenti il cui compito è essere capiti: ticket, design doc, runbook, status update, qualsiasi cosa un team o uno stakeholder legga per agire. Non è una legge valida per ogni tipo di scrittura. Un contratto legale ha bisogno del suo linguaggio preciso e sgraziato. Il marketing gioca secondo altre regole. Una specifica tecnica approfondita per un pubblico di specialisti può essere più densa della settima classe e restare comunque la scelta giusta. Il test è sempre il lettore. Se lo scopo è che qualcuno capisca e agisca, scrivilo secondo ELA7.

Il modo più semplice per sentire la differenza è provarlo su qualcosa che hai già scritto. Prendi il tuo ultimo ticket o design doc, incollalo in uno strumento IA e chiedigli di verificare il testo rispetto a ELA7 e segnalare ogni frase che non supera il test. Leggi cosa ti risponde. Ho scritto questo post seguendo la stessa regola.