La tua IA sta inventando il tuo prodotto

Perché l'output varia così tanto

Stesso prompt, inviato allo stesso modello, a sessanta secondi di distanza.

Prompt: "Scrivi i criteri di accettazione per un ticket: l'utente può configurare le impostazioni del fornitore di IA."

Primo tentativo — senza contesto: il risultato è una checklist generica. "L'utente può selezionare un fornitore di IA da un menu a tendina. L'utente può salvare le impostazioni. L'utente vede un messaggio di conferma." Potrebbe essere qualsiasi prodotto, qualsiasi piattaforma, qualsiasi decennio. Non c'è nulla di sbagliato. Non c'è nulla di utile, però.

Secondo tentativo — con contesto del prodotto: il risultato fa riferimento alle pagine di amministrazione di Jira Cloud, ai permessi del Forge resolver, alla validazione delle chiavi API per fornitore (OpenAI, Anthropic, Google, Mistral, xAI), al comportamento dello scope dei dati a livello di organizzazione vs. progetto, e alle azioni di scrittura condizionate dalla licenza. Specifica che le impostazioni persistono tramite @forge/sql e che l'interfaccia usa componenti Atlaskit con token xcss. Sembra scritto da qualcuno che ha davvero lavorato in quella codebase.

Il modello non è cambiato. La temperatura non è cambiata. L'input è cambiato. Questo divario — tra generico e concreto — è il tema centrale di questo articolo.

Quando l'output dell'IA sembra inconsistente, l'istinto è incolpare il modello: cambiare fornitore, upgraddare il piano, aggiustare la temperatura. Quasi sempre, è la leva sbagliata.

Ogni prompt parte da zero. Il modello non ha memoria del tuo prodotto, dei tuoi utenti, dei tuoi vincoli o della tua ultima conversazione, a meno che tu non fornisca esplicitamente queste informazioni. "Scrivi criteri di accettazione" significa qualcosa di completamente diverso per un'app Forge nativa a Jira che serve team di ingegneria da dieci a cento persone rispetto a un'app mobile di fitness per il consumatore.

Il modello risponde al mondo che gli descrivi. Se non descrivi nulla, ne inventa uno — e raramente è il tuo.

È per questo che due persone nello stesso team possono usare lo stesso modello e ottenere risultati radicalmente diversi. Non è una questione di competenza. Non è la struttura del prompt. È se al modello è stata fornita abbastanza realtà del prodotto con cui lavorare.

Per il quadro più ampio su perché questo causa errori così costosi in Jira, inizia da: L'IA non risolve i team mal allineati. Li nasconde.

La soluzione non è una migliore tecnica di prompting. È costruire uno strato di contesto riutilizzabile — una descrizione compatta e onesta del mondo del tuo prodotto — da allegare prima di ogni prompt. Lo scrivi una volta. Lo riusi ovunque. Il modello smette di indovinare e inizia a lavorare con gli stessi vincoli del tuo team.

I quattro livelli

Il contesto del prodotto non è un unico blocco di testo. Si scompone naturalmente in quattro livelli, ognuno con un compito diverso.

• Riepilogo del prodotto copre cosa fa il prodotto, per chi e quali risultati contano — una verità operativa, non testo di marketing. La differenza è importante. "Uno strumento di gestione dei progetti per i team" potrebbe descrivere qualsiasi cosa. "Just è un copilota IA nativo a Jira per i team di prodotto e ingegneria su Jira Cloud. Compito principale: trasformare issue Jira ambigue in piani di esecuzione strutturati — chiarimenti, piani passo-passo e scrittura nei campi Jira — senza uscire dal pannello dell'issue. Non è un chatbot. Non è uno strumento autonomo. Costruito su Atlassian Forge." descrive esattamente un prodotto.
• Audience copre chi sono gli utenti, di cosa hanno bisogno, cosa si aspettano e cosa non sanno.
• Linguaggio di design copre i pattern visivi, la libreria di componenti, le abitudini di interazione e le cose che non si fanno mai.
• Stack e vincoli copre i framework reali, i limiti di runtime, le integrazioni e le scelte esplicitamente fuori portata.

La versione sbagliata di ogni campo si adatta a migliaia di prodotti. Quella giusta si adatta esattamente a uno. Questo è il test.

L'audience è dove il contesto generico si rompe

L'audience è di solito il primo campo che i team semplificano troppo. "Product manager e sviluppatori" sembra ragionevole. È anche troppo vago per aiutare il modello a prendere decisioni migliori.

Un campo audience utile è specifico sulla composizione del team, la familiarità con l'IA, le aspettative di fiducia e ciò che gli utenti non vogliono. Per Just, significa PM e ingegneri senior in team Jira Cloud da 10 a 100 persone, con una familiarità moderata con l'IA, che gestiscono le proprie chiavi API e tengono più a un output affidabile che a uno spettacolare.

La riga "Non per" è altrettanto importante. Dire che non è per team al di fuori di Jira Cloud o per utenti che vogliono agenti completamente autonomi elimina intere categorie di assunzioni errate prima che possano formarsi.

È questo che rende il contesto radicato invece che decorativo. Al modello non viene solo detto chi è l'utente. Gli viene anche spiegato in quale mondo opera quell'utente e quali tipi di workflow sembrerebbero sbagliati.

Estrai ciò che esiste già

La maggior parte dei team ha già tutti e quattro i livelli di contesto — sono semplicemente dispersi tra codebase, file di design, documentazione e memoria del team, invece di essere in una forma che l'IA possa usare.

Dal tuo repository: punta un agente di codice — Claude Code, Codex o simile — sulla tua codebase e chiedi un riepilogo in markdown che copra lo scopo del prodotto, lo stack, i limiti di implementazione e i vincoli noti. Un repository ben strutturato produce una prima bozza utilizzabile in pochi minuti.

Dai tuoi file di design: identifica il nome della libreria di componenti, da tre a cinque pattern di interazione chiave su cui si basa il tuo prodotto, e tre cose che l'UI non fa mai. Gli anti-pattern contano quanto i pattern.

Dalla documentazione esistente: note di onboarding, file README, brief interni o contesto di marketing possono tutti contribuire frammenti di riepilogo del prodotto e definizione dell'audience. Non devono essere perfetti per essere utili.

Dalla tua testa: se nulla di quanto sopra esiste ancora, apri un documento vuoto e scrivi ora un paragrafo per campo. Sarà imperfetto. Il contesto imperfetto batte nessun contesto di gran lunga.

Non hai bisogno di documentazione perfetta. Hai bisogno di una descrizione compatta e onesta del mondo in cui vive il tuo prodotto.

Salvalo una volta, riusalo ovunque

Il contesto si ripaga solo se è riutilizzabile. Scriverlo una volta e incollarlo in una singola sessione aiuta quella sessione. Renderlo persistente aiuta ogni sessione.

• In Just, il pannello di amministrazione ha una sezione dedicata per ognuno di questi quattro campi di contesto — Riepilogo del Prodotto, Audience, Linguaggio di Design e Stack. Incolla il tuo contenuto in ogni campo una volta per progetto. Ogni insight futuro, ogni chiarimento, ogni piano e ogni step di esecuzione in quel progetto sarà automaticamente radicato in questo contesto.
• Se non usi Just, crea un unico file context.md nella root del tuo repository o nella documentazione condivisa. Strutturalo con le stesse quattro sezioni. Incollalo all'inizio di ogni sessione IA — assistenti di codice, strumenti chat, generatori di documenti. Il formato conta meno dell'abitudine: prima il contesto, poi il prompt.

Tratta il tuo strato di contesto come un documento vivo, non come un artefatto del giorno del lancio. Revisionalo quando il prodotto cambia significativamente — una nuova integrazione, un cambio importante di audience, una migrazione del design system. Non revisionarlo ogni sprint. Se il tuo riepilogo del prodotto cambia ogni due settimane, non è un riepilogo del prodotto — sono appunti di riunione.

Il contesto non è prompt engineering

Il contesto del prodotto non è prompt engineering. Non è un trucco, un template o un hack intelligente. È dare al modello lo stesso briefing che daresti a un nuovo collaboratore il primo giorno: ecco cosa costruiamo, per chi, come deve apparire e su cosa gira.

I team che lo fanno una volta — e lo riusano in modo coerente — ottengono output che sembrano provenire da qualcuno che comprende davvero il prodotto. Perché in ogni senso funzionale, è così. Il modello non è diventato più intelligente. Hai semplicemente smesso di chiedergli di indovinare.