Abbiamo lasciato Jira: agenti di IA e un tasks.md che si compila da solo

L’ultimo ticket che abbiamo aperto nel nostro Jira per un progetto interno è di febbraio. Nessuno ha deciso in una riunione di smettere di usarlo. È successo da solo: ogni volta che qualcuno scriveva un ticket, finiva per scrivere la stessa cosa nel prompt dell’agente, e il ticket non lo rileggeva più nessuno. Dopo qualche settimana la gente ha smesso di scrivere la prima versione.

Oggi il lavoro di ogni progetto si gestisce in un file di testo, tasks.md, che vive dentro il progetto stesso e che gli agenti compilano mentre lavorano. Per noi funziona meglio di Jira quasi in tutto. In una cosa funziona peggio, ed è quella che ci pesa di più: sapere cosa sta facendo ognuno.

Questo testo ha un’opinione. Credo che Jira, e quasi qualsiasi tracker di ticket, sia pensato per distribuire ore di programmatore, che per vent’anni sono state la voce più cara di un progetto. Con gli agenti, scrivere il codice costa minuti o ore. Adesso il costo sta nel sapere cosa vuoi e nel verificare che quello che torna indietro sia corretto, e una board di ticket non aiuta in nessuna delle due cose.

È anche un testo a metà. Usiamo questo sistema da otto mesi, l’abbiamo cambiato quattro volte e lo cambieremo ancora. Racconto cosa ci è andato bene, cosa ci è andato male e cosa non sappiamo ancora risolvere.

Un avvertimento prima di cominciare: siamo un’agenzia, e una parte di quello che vendiamo sono ore di sviluppo. Se stimare in ore smette di avere senso, tocca a noi prima che a chiunque altro.

A cosa serviva Jira

Togli le integrazioni, i colori e i campi personalizzati, e a Jira restano quattro funzioni:

1. Una coda: cosa c’è da fare e in che ordine.
2. Una ripartizione: chi fa cosa.
3. Una stima: quanto costerà, in ore o in punti, per sapere cosa entra in uno sprint.
4. Uno stato: a che punto è ogni cosa, perché chi non sta programmando lo sappia senza chiedere.

Tutte e quattro ruotano attorno alla stessa risorsa scarsa: il tempo di una persona che sa programmare. Lo sprint esiste perché quel tempo si esaurisce ogni due settimane. I punti esistono perché bisogna ripartirlo prima di spenderlo. Le colonne “In corso” e “In revisione” esistono perché un task poteva restare giorni in ciascuna.

Per anni abbiamo lavorato così, e funzionava. Avevamo i refinement il lunedì, il planning ogni due settimane, una retro che a volte saltava e una board per progetto. La board era il modo in cui il cliente, il project manager e il team vedevano la stessa cosa.

Cosa è cambiato con gli agenti

La prima cosa che abbiamo notato è che le stime hanno smesso di tornare, e non perché fossero sbagliate. Un task da tre punti, che prima era un giorno e mezzo di lavoro, si faceva in un pomeriggio. Uno da cinque, in un giorno. Quelli da otto continuavano a costare lo stesso o di più, perché lì la parte difficile non è mai stata scrivere: era capire cosa bisognava fare.

Per un paio di mesi abbiamo provato a ricalibrare i punti. Non ha funzionato. Il tempo di un task non dipendeva più dalla sua dimensione, dipendeva da quanto era spiegato bene. Un task grande ma chiaro usciva in una mattina. Uno piccolo ma ambiguo poteva mangiarsi due giorni di andata e ritorno, perché l’agente faceva con grande sicurezza qualcosa che non era quello che volevamo, bisognava spiegarlo di nuovo, e tornava a fare un’altra cosa.

Lì abbiamo capito che avevamo spostato il collo di bottiglia. Prima il lavoro si bloccava su “chi ha tempo per farlo”. Adesso si blocca in due punti:

• Prima di cominciare: scrivere bene cosa vuoi. Non in un ticket di due righe, ma con il contesto, i vincoli, cosa non va toccato e come capirai che va bene.
• Alla fine: rivedere quello che ha fatto l’agente. Leggere la modifica, provarla, capire se ha rotto qualcosa che non si vede.

Jira non ha una colonna per nessuna delle due. Ha “Da fare”, “In corso” e “Fatto”, e la maggior parte dello sforzo non sta più in “In corso”.

L’altra cosa che è cambiata è il tempo che un task passava in ogni stato. Se un task resta “In corso” per quaranta minuti, spostarlo sulla board costa quasi quanto farlo. La gente ha smesso di spostarlo. La board ha cominciato a mentire. E una board che mente è peggio di nessuna board, perché qualcuno la guarda e ci crede.

Il tasks.md

L’alternativa è nata da un progetto piccolo, quasi per caso. Uno sviluppatore del team ha cominciato a lasciare all’agente una lista di cose da fare in un file di testo nella radice del progetto, per non dovergli rispiegare il contesto ogni mattina. Dopo una settimana l’agente aggiornava quella lista da solo: segnava quello che finiva, aggiungeva quello che trovava per strada e annotava perché lasciava qualcosa a metà.

L’abbiamo copiato negli altri progetti. Oggi ce l’hanno tutti, e somiglia a questo:

# Task

## In corso
- [ ] Esportazione ordini in CSV con filtro per negozio (Laura, dal 14-ott)
  - Manca: provare con più di 10.000 righe
- [ ] Passaggio del gateway di pagamento alla nuova API (Dani, dal 15-ott)

## Da fare
- [ ] La ricerca ignora gli accenti ("perche" non trova "perché")
- [ ] Rivedere i testi legali della pagina di checkout (in attesa di risposta del cliente)

## Fatto
- [x] Login con magic link via email (Laura, 13-ott)
  - Tolto il login con password da mobile su richiesta del cliente
- [x] Corretto il calcolo dell'IVA nei resi parziali (Dani, 11-ott)

Le regole sono poche:

• L’agente lo legge all’inizio di ogni sessione. Così sa cosa c’è di aperto, chi se ne occupa e cosa si è deciso prima, senza che nessuno glielo racconti.
• L’agente lo aggiorna alla fine. Sposta quello che ha fatto in “Fatto”, con una riga su cosa è cambiato e, se serve, perché. Se ha trovato qualcosa di rotto che non toccava a lui sistemare, lo aggiunge a “Da fare”.
• Le persone lo leggono e lo correggono. Se una priorità cambia, la riga si sposta a mano. Nessuno deve “spostare card” perché lo stato sia aggiornato, perché lo stato lo scrive chi fa il lavoro.
• Tutto quello che non sta in una riga va da un’altra parte. Le decisioni di design e le regole del progetto vivono in un file a parte che l’agente legge anche lui. Il tasks.md è solo la lista.

Rispetto a Jira, vince su tre fronti. Vive con il codice, quindi si salva, si versiona e si recupera insieme a lui. L’agente lo legge senza integrazioni, senza permessi e senza connettori, perché è testo. E una persona lo legge tutto in trenta secondi, cosa che non si può dire di una board con centoventi card.

Perde su altri, e li racconto più sotto.

Cosa è andato bene

La modifica uscita dalla riunione

In primavera avevamo una riunione di avanzamento con un cliente del settore della distribuzione. A metà riunione, il direttore operativo ha detto che il report degli ordini che gli avevamo consegnato andava bene, ma che quello che serviva davvero era vederlo per negozio e poterlo scaricare per girarlo a ogni responsabile.

Con il nostro processo precedente, sarebbe stato un ticket, un refinement il lunedì dopo, una stima e, con un po’ di fortuna, l’ingresso nello sprint della settimana successiva. Due settimane, a essere ottimisti.

La sviluppatrice che era in riunione l’ha annotato nel tasks.md mentre parlavano, con le parole del cliente. All’uscita ha aperto una sessione con l’agente. Alle cinque del pomeriggio gli abbiamo mandato un link all’ambiente di test con il filtro per negozio e il download. La risposta del direttore è stata un vocale su WhatsApp che ogni tanto ci riascoltiamo ancora.

L’agente ha fatto la sua parte, ma quello che ha fatto risparmiare le due settimane è che tra la richiesta e il codice non c’era nient’altro: niente ticket, niente coda, niente planning. L’unica cosa che serviva era capire bene cosa chiedeva il cliente, e quello lo avevamo già perché eravamo in riunione.

L’MVP uscito in anticipo

Per una startup avevamo pianificato un primo prodotto in sei settimane: registrazione utenti, una dashboard con tre viste, pagamenti e notifiche. È uscito in due e mezza.

Quello che ha pesato di più è che, senza sprint, il cliente vedeva progressi ogni giorno e correggeva ogni giorno. Quando nella seconda settimana si è accorto che una delle tre viste della dashboard non l’avrebbe usata nessuno, l’abbiamo tolta quello stesso pomeriggio. In uno sprint di due settimane quel cambio sarebbe arrivato tardi, con la vista già costruita e testata.

La fondatrice ci ha detto dopo che eravamo il primo fornitore con cui non aveva la sensazione di stare aspettando.

Il cliente che ha smesso di chiedere il report settimanale

A diversi clienti mandavamo un report settimanale di stato. Lo scriveva il project manager il venerdì, partendo dalla board di Jira, e ci voleva un’ora abbondante.

Un cliente ci ha chiesto se poteva vedere direttamente “quella lista che usate”. Gli abbiamo dato accesso in lettura al tasks.md. Due settimane dopo ci ha chiesto di smettere di mandargli il report: preferiva guardare la lista quando gli andava, e lì c’era tutto quello che gli serviva sapere. Detto da lui, nel file capiva meglio che nel report, perché ogni riga l’aveva scritta chi aveva fatto il lavoro.

Non tutti i clienti lo vogliono così, e va bene. Ma nessuno ci ha chiesto di tornare alla board.

L’onboarding in un giorno

Quando qualcuno entra in un progetto a metà strada, di solito passa due o tre giorni a leggere ticket, fare domande e capire cosa è rimasto a metà. Quest’estate è entrato uno sviluppatore nuovo in un progetto avviato da quattro mesi. Ha chiesto all’agente di leggere il tasks.md e il file delle regole e di spiegargli lo stato del progetto. Quella stessa mattina ha chiuso il suo primo task.

Meno riunioni

Abbiamo smesso di fare planning e refinement. Continuiamo a parlarci, ma in un altro modo: dieci minuti al mattino per dire su cosa lavorerà ognuno, e conversazioni brevi quando serve decidere qualcosa. Dopo un mese, le persone del team raccontavano di avere i pomeriggi interi per lavorare senza interruzioni, e si vedeva in quello che usciva.

Cosa è andato male

Due persone, lo stesso task

Un martedì, due sviluppatori hanno corretto lo stesso bug nello stesso momento. Il cliente l’aveva segnalato su due canali diversi, uno l’ha visto nella mail e l’altro nella chat del progetto, e ognuno l’ha passato al proprio agente. Nessuno dei due ha guardato il tasks.md prima di cominciare, e nemmeno gli agenti, perché il task non era ancora annotato. Ce ne siamo accorti in revisione: due correzioni diverse per la stessa cosa, entrambe ragionevoli e incompatibili tra loro.

Abbiamo perso un pomeriggio. Non è molto, ma è esattamente il tipo di cosa che una board con un responsabile assegnato evita, e noi l’avevamo tolta.

”In corso” per nove giorni

In un altro progetto, un task è rimasto segnato come “In corso” per nove giorni. La persona che se ne occupava era passata a un altro progetto urgente e non l’aveva spostato. Gli agenti, ogni volta che leggevano il file, davano per scontato che qualcuno ci stesse lavorando e non lo toccavano. L’abbiamo scoperto quando il cliente ha chiesto di quella funzionalità.

Un file che si compila da solo si compila con quello che l’agente sa. Quello che succede fuori dalla sessione (qualcuno cambia progetto, un cliente cambia idea al telefono) non arriva al file se una persona non lo scrive.

L’agente che ha dato per finito qualcosa a metà

Il tasks.md lo aggiorna l’agente, e l’agente a volte è ottimista. Abbiamo avuto task segnati come fatti che lo erano a metà: l’esportazione funzionava, ma non con i dati reali del cliente; il modulo si inviava, ma la mail di conferma non partiva. Il file diceva “Fatto” con la stessa sicurezza in entrambi i casi.

Da allora, un task non è fatto perché lo dice l’agente. È fatto quando una persona l’ha rivisto, e l’agente non può spuntare quella casella.

”Cosa state facendo adesso?”

Questa è quella che ci è costata di più. Un cliente ha chiamato un giovedì e ha chiesto, con tutte le ragioni, su cosa stavamo lavorando quella settimana. Il project manager non lo sapeva con certezza. Sul progetto c’erano due persone, ognuna con due o tre sessioni di agente aperte, e il tasks.md rifletteva quello che era stato finito, ma non quello che stava succedendo in quel momento. Ha dovuto chiedere nella chat del team e richiamare il cliente venti minuti dopo.

Con Jira quella domanda si risolveva guardando una colonna. Quella colonna mentiva spesso, ma la risposta c’era.

La trappola della velocità

Il cliente della modifica in riunione si è abituato a ricevere le cose in giornata. Tre mesi dopo ha chiesto un’integrazione con il suo sistema di fatturazione, che dipendeva da un fornitore esterno e da permessi che hanno impiegato una settimana ad arrivare. Per lui, una settimana era lentissima. Prima, la stessa integrazione sarebbe stata uno sprint intero e gli sarebbe sembrata normale.

Andare veloci cambia quello che il cliente si aspetta, e quando qualcosa non può andare veloce, bisogna spiegarlo prima che lo chieda. L’abbiamo imparato tardi.

Il problema che non abbiamo risolto: lavorare in parallelo

Se c’è una cosa che Jira faceva bene e noi ancora no, è coordinare più persone che lavorano contemporaneamente sullo stesso progetto.

Con gli agenti, ogni sviluppatore può avere diversi task che avanzano nello stesso momento. Questo moltiplica quello che esce, ma moltiplica anche le possibilità che due task mettano le mani sullo stesso pezzo di codice, o che due persone risolvano lo stesso problema ognuna per conto suo. E il tasks.md non basta, perché riflette quello che è stato deciso o finito, non quello che si sta facendo in questo momento.

Quello che facciamo oggi è poco sofisticato: gli sviluppatori si parlano. Prima di cominciare qualcosa che tocca una parte delicata del progetto, si avvisa nella chat del team con un “stamattina metto mano ai pagamenti”. La riunione di dieci minuti di ogni mattina serve soprattutto a questo. E la regola è che un task si annota nel file, con il nome, prima di darlo a un agente, non dopo.

Funziona perché siamo in pochi per progetto e ci conosciamo. Non so se funzionerebbe con quindici persone.

Abbiamo provato altre cose che non hanno funzionato:

• Un file di task per persona. Ognuno sapeva il suo e nessuno vedeva l’insieme. È durato due settimane.
• Far dire all’agente su cosa sta lavorando. Gli abbiamo chiesto di scrivere nel file, all’inizio, cosa avrebbe toccato. Lo faceva, ma quando due sessioni partivano quasi insieme, nessuna vedeva quello che aveva scritto l’altra.
• Tornare a una board solo per quello che è in corso. È durata meno del file per persona. Nessuno la aggiornava, per lo stesso motivo di prima.

Stiamo guardando strumenti che provano a risolvere proprio questo. Orca, di Stably AI, è un’applicazione desktop open source che lancia più agenti in parallelo, ognuno isolato, e ti permette di vedere in un’unica schermata cosa sta facendo ciascuno e confrontare i risultati. Risolve la parte di vedere cosa fa ogni agente di una persona. La parte di vedere cosa fa ogni persona del team resta aperta.

Cosa stanno facendo Atlassian e Linear

I produttori di tracker hanno visto la stessa cosa e hanno risposto mettendo gli agenti dentro.

Atlassian ha aperto Agents in Jira in beta a febbraio 2026 e l’ha annunciato come disponibile per tutti a maggio, a Team ‘26. Assegni un ticket a un agente dallo stesso menu a tendina che usi per una persona, e l’agente legge il ticket e vi registra i suoi progressi.

Linear ha preso una decisione che mi sembra migliore: una issue si assegna solo alle persone e si delega agli agenti. L’agente lavora, ma il responsabile resta un essere umano. È una distinzione piccola sullo schermo e grande nella pratica, perché chiarisce chi risponde quando l’agente sbaglia, che è proprio quello che ci è successo con i task che l’agente dava per finiti.

Le due risposte hanno lo stesso problema di fondo: danno per scontato che un ticket sia una buona specifica per un agente, e quasi nessuno lo è. “Sistemare il login su Safari” basta a una persona che sa a chi chiedere. Un agente con quel ticket farà qualcosa, e lo farà con grande sicurezza. Il fatto che assegnare ticket agli agenti sia comodo rende più facile mandare lavoro spiegato male a qualcosa che non fa domande.

Dove Jira ha ancora ragione

Se sei arrivato fin qui pensando “a voi funziona perché siete in pochi”, hai in parte ragione. Ci sono situazioni in cui io Jira non lo toglierei:

• Più team che dipendono l’uno dall’altro. Un tasks.md coordina un progetto. Quando il team dei pagamenti dipende dal fatto che quello di piattaforma cambi qualcosa, e ognuno lavora sulle sue cose, serve un posto comune dove quella dipendenza si veda.
• Persone che non sono nel progetto. Direzione, supporto, vendite o compliance devono sapere cosa sta succedendo senza aprire un file dentro il codice. Una board è un’interfaccia per loro, e questo non cambia perché il codice lo scrive un agente.
• Audit. Se ti certificano ISO 27001 o SOC 2, l’auditor vorrà vedere che ogni modifica ha una richiesta, un’approvazione e un responsabile. Se il tuo processo di change management è già costruito su Jira, rifarlo non conviene.
• Il team di un cliente. Quando entriamo nel team di prodotto di un cliente, lavoriamo con i suoi strumenti. Con Orquest usavamo il loro Jira e partecipavamo ai loro daily. Lì non c’è niente da discutere: il tracker è loro.

Quello che hanno in comune è che quasi tutto è comunicazione con persone che non stanno dentro il codice. La parte di Jira che ha ancora senso è quella che parla con gli esseri umani. Quella che per noi ha perso senso è quella che pianificava il lavoro dei programmatori.

Cosa faremmo se cominciassimo oggi

Questa cosa continua a cambiare, ma se domani un team ci chiedesse come cominciare, gli diremmo questo:

1. Smetti di stimare il lavoro che fa un agente. Se il team continua a dare punti a task da quaranta minuti, sta misurando il rituale, non il lavoro.
2. Metti la lista dei task dentro il progetto, in un file che l’agente legga all’inizio e aggiorni alla fine. È il modo più economico per dare all’agente una memoria tra le sessioni.
3. Annota il task prima di darlo a un agente, con il nome. È l’unica regola che ci ha davvero evitato lavoro doppio.
4. Un task è fatto solo quando lo rivede una persona. L’agente può proporre che è finito; non può deciderlo.
5. Parla con il resto del team prima di toccare qualcosa di delicato. Un messaggio di una riga in chat evita un pomeriggio perso. Non abbiamo ancora trovato niente di meglio.
6. Chiudi quello che è fermo da settimane. Un task che nessuno ha toccato in sei settimane è una decisione che nessuno ha voluto prendere. Se era importante, qualcuno lo riaprirà.
7. Tieni Jira, o quello che usi, per parlare con chi non sta nel codice. Clienti che lo preferiscono, direzione, audit.

Tra sei mesi è probabile che questo testo sia già invecchiato. Se risolviamo il lavoro in parallelo, lo racconteremo qui. E se qualcuno l’ha già risolto, ci piacerebbe molto sapere come: scrivici a info@soamee.com.