Tre modi in cui l’IA entra in Jira

Tre strade, lo stesso backlog

Nel 2026 di IA ce n’è ovunque. Quello che manca, semmai, è capire dove convenga davvero applicarla.

Se il tuo team lavora dentro Jira, questa spinta l’ha già sentita. Atlassian ha portato Rovo direttamente nella piattaforma. OpenAI e Anthropic hanno aperto connettori che permettono a ChatGPT e Claude di leggere il backlog. E una nuova generazione di app native Forge, tra cui Just, inserisce l’IA direttamente nel pannello dell’issue, trattando il ticket sia come punto di partenza sia come destinazione finale.

Tre strade. Lo stesso backlog. Esperienze molto diverse.

La tentazione è chiedersi quale sia la migliore. Di solito, però, non è questa la domanda giusta. Quella più sincera è spesso: quale di queste opzioni si adatta davvero al nostro modo di lavorare?

Per alcuni team conta soprattutto la copertura governata. Per altri la libertà di scegliere i modelli di frontiera. Per altri ancora un unico flusso strutturato in Jira, capace di usare più fornitori senza uscire dall’issue.

Prima strada: Rovo

Rovo è il livello di IA di Atlassian, intrecciato con Jira Cloud, Confluence e Jira Service Management. Si basa su un Teamwork Graph che collega persone, progetti e contenuti nell’ecosistema Atlassian, ed è stato lanciato attorno a tre pilastri: Search, Chat e Agents.

• Punto di forza: la copertura. Rovo Search pesca tra Jira, Confluence e un lungo elenco di app di terze parti rispettando i permessi già esistenti, quindi è utile per i team sommersi da conoscenze sparse ovunque.
• Punto di forza: il percorso di approvazione più semplice. Non ci sono chiavi di fornitori da gestire, né modelli da scegliere, né budget di token da controllare. La governance resta dentro il modello di permessi e audit già previsto da Atlassian. Anche il prezzo oggi è più lineare: nel 2026 Rovo è presentato come parte dei piani Atlassian Cloud, con accesso e utilizzo legati al livello del piano e alle relative soglie.
• Contropartita: meno controllo e meno profondità dentro la singola issue. La scelta del modello è bloccata e l’IA rimane accanto al lavoro, non dentro un percorso strutturato di pianificazione nel pannello dell’issue.

Rovo è la strada giusta quando il problema principale è trovare informazioni distribuite tra più prodotti e la priorità è avere accesso regolato senza dover configurare nulla.

Seconda strada: i connettori

I connettori seguono la logica opposta. Invece di chiudere l’IA dentro Atlassian, portano i dati di Jira là dove l’IA vive già: ChatGPT, Claude Desktop, Cursor o qualsiasi client che supporti il Model Context Protocol (MCP).

• Punto di forza: libertà di modello. Ti danno accesso a ciò che offre il client esterno. Oggi significa Claude Opus 4.6, GPT-5.4, Gemini 3.0 Pro e qualunque altra novità arrivi domani.
• Punto di forza: esperienza familiare. Per questo risultano interessanti per gli utenti esperti che vivono già in Claude, ChatGPT o Cursor e vogliono modelli avanzati senza imparare un’altra interfaccia. La versione più attuale di questo ponte passa sempre più spesso da MCP: il client si collega a un server MCP di Atlassian o di terze parti, scopre gli strumenti Jira e li usa dentro la conversazione.
• Contropartita: l’utente diventa il livello di integrazione. Il contesto resta superficiale se qualcuno non continua a incollarlo a mano, la scrittura di ritorno verso Jira è possibile ma raramente strutturata, e ogni conversazione di solito resta privata dentro un singolo client. Anche l’autenticazione può essere macchinosa: il server MCP ufficiale di Atlassian usa OAuth e molti team finiscono per affiancare un connettore gestito da terzi per rendere l’esperienza più fluida.

I connettori sono la strada giusta quando il problema centrale è portare il contesto di Jira dentro un’IA esterna potente e l’utente apprezza più la flessibilità del modello che il flusso condiviso del team.

Terza strada: Just

Just prende una terza direzione. È un’app Jira nativa Forge che inserisce l’esperienza di IA direttamente nel pannello dell’issue, non come chat laterale, ma come ciclo strutturato: generazione di insight, chiarimento, pianificazione, esecuzione e scrittura finale nei campi di Jira.

• Punto di forza: profondità di flusso. L’IA vive dentro il ticket, non in un client separato, e l’issue diventa sia l’input sia la destinazione.
• Punto di forza: un sistema nativo di Jira che può combinare più fornitori. Invece di limitarsi a una richiesta e una risposta, Just esegue un percorso strutturato: analisi, chiarimento, pianificazione, ricerca sul web, lavoro sulle immagini, esecuzione e applicazione finale in Jira. Ogni passaggio può essere attivato, saltato o rivisto prima di toccare l’issue. Poiché nasce per lavorare con più fornitori, il team può assegnare fasi diverse a modelli diversi e unire, in un solo sistema, contesto di progetto riutilizzabile, esecuzione visibile, consumo di token, costi e cicli di feedback.
• Contropartita: più configurazione e vincoli di piattaforma. Just include chiavi di prova per iniziare, ma sul lungo periodo funziona a consumo con le tue chiavi dei fornitori. Questo richiede una configurazione un po’ più avanzata: qualcuno nel team deve collegare, creare e gestire le API key dell’organizzazione. È anche una scelta più adatta quando l’uso dell’IA varia molto tra le persone, perché non impone lo stesso costo fisso per postazione a tutti. Ho spiegato meglio questo compromesso economico in Il budget IA di cui quasi nessuno parla. Essendo un’app Forge, resta inoltre soggetta ai limiti di esecuzione della piattaforma Atlassian.

Just è la strada giusta quando vuoi mettere insieme, dentro Jira, i punti forti di più fornitori di IA in un flusso verificabile e sei disposto a investire un po’ più di configurazione per ottenere questo controllo.

La differenza vera: dove vive l’IA

Se togli l’elenco delle funzionalità e riduci ogni opzione alla sua essenza, la differenza è di architettura.

Rovo è la metropolitana. Copre tutta la città. Ti porta da Jira a Confluence fino a Google Drive in un unico sistema. Le linee sono definite, gli orari li gestisce qualcun altro e tu ti affidi all’operatore.

I connettori sono come un servizio con conducente. Scegli il mezzo, scegli chi guida e vai esattamente dove vuoi. Però sei tu a dare le indicazioni, il tragitto resta privato e il resto del team in pratica non vede l’intero percorso.

Just è una navetta dedicata. Copre un solo corridoio, l’issue di Jira, ma lo fa con fermate, punti di revisione e trasparenza. Inoltre può cambiare fornitore lungo il tragitto senza costringere il team a uscire da Jira. Tutti possono vedere dov’è la navetta, cosa sta trasportando e quando arriva.

Mappa in sintesi

Se comprimi l’intero confronto ai suoi elementi essenziali, il contrasto diventa immediato.

La scelta, nella sua forma più pulita, è questa: copertura governata, libertà personale di modello oppure un flusso strutturato in Jira capace di combinare il meglio di più fornitori.

Come scegliere la strada

Nessuna strada è giusta in assoluto per tutti. Un team che deve cercare informazioni in sei prodotti SaaS diversi e vuole zero carico infrastrutturale dovrebbe partire da Rovo.

Uno sviluppatore che vuole far ragionare Claude Opus 4.6, GPT-5.4 o Gemini 3.0 Pro sul backlog dal proprio client probabilmente preferirà un connettore.

Un team di prodotto o delivery che vuole un flusso Jira verificabile, in cui passaggi diversi possono usare fornitori diversi e in cui costi, qualità e risultati restano visibili all’intera squadra, dovrebbe guardare Just su Atlassian Marketplace.

Molti team useranno più di una soluzione. Queste strade non si escludono a vicenda. La cosa importante è scegliere con intenzione, in base a come il team lavora davvero e a dove nasce davvero l’attrito, non in base alla demo di IA che la settimana scorsa sembrava più impressionante.