Una bacheca di feedback per gli agenti IA: lascia che siano i tuoi utenti a scrivere il prompt

Un utente ti scrive alle 23. "Il pulsante di esportazione non fa niente su Safari."

Sai già cosa succede dopo, perché è successo cento volte. Lo leggi. Lo capisci. Poi apri un tracker e lo riscrivi, con parole tue, con i percorsi dei file, i passi per riprodurlo e il contesto che l'utente non aveva. Poi, più tardi, apri un terminale e lo scrivi una terza volta, sotto forma di prompt.

Tre scritture della stessa richiesta. La prima era gratis e veniva dalla persona che il bug l'ha incontrato davvero. Le altre due sono tue.

Sono la seconda e la terza scrittura la parte del mestiere che gli agenti hanno reso assurda.

L'ultima cosa che continui a battere a mano

Gli agenti di codice hanno tolto un sacco di digitazione. Non hanno tolto il brief. Qualcosa deve comunque dire all'agente cosa costruire, con abbastanza dettaglio perché non tiri a indovinare, e quel qualcosa è ancora un umano seduto a una tastiera che converte le parole degli altri in istruzioni.

Solo che spesso la conversione non serve a niente. Una buona segnalazione di bug contiene già quello che serve a un agente: cosa ci si aspettava, cosa è successo, su quale pagina, con quale browser. Una buona richiesta di funzionalità contiene già l'intenzione e il motivo. Chi l'ha scritta era più vicino al problema di quanto lo fossi tu.

Quello che facciamo invece è trattare quel testo come materia prima da rilavorare, perché lo strumento che l'ha raccolto e lo strumento che esegue il lavoro non sono mai stati lo stesso strumento. Il feedback vive in un prodotto, i ticket in un secondo, e l'agente gira in un terminale che non conosce né l'uno né l'altro.

Elimina lo scarto e il passaggio di riscrittura non ha più dove avvenire.

Cosa diventa una bacheca di feedback quando la bacheca sa eseguire

Un backlog pubblico è una pagina che i tuoi utenti possono raggiungere. Segnalano un bug, chiedono una funzionalità, votano quello che ha chiesto qualcun altro, seguono una discussione e vedono cambiare uno stato. Fin qui è una bacheca di feedback, e ce ne sono di ottime.

La differenza è dove atterra il ticket. Non atterra in un prodotto di feedback in attesa di essere esportato. Atterra nella bacheca dei task da cui i tuoi agenti già lavorano, come ticket a pieno titolo, accanto a quelli che hai scritto tu.

Da lì, spostarlo in In Progress avvia un agente il cui brief è il ticket: il titolo, la descrizione con le parole di chi ha segnalato, la pagina su cui si trovava, il browser che usava e la conversazione che nel frattempo ci hai avuto sopra. Nessuno ha riscritto niente. Il prompt è la segnalazione.

La conseguenza interessante non è la velocità. È che la persona che ha descritto il problema è adesso la persona che ha specificato il lavoro, cioè quello che tutti dicono di volere dal feedback degli utenti e che quasi nessuno struttura per davvero. Quel ribaltamento ha un nome, ed è il backlog guidato dal cliente: la coda smette di essere la tua ipotesi su cosa conta e diventa il registro di quello che è stato chiesto sul serio.

Tre porte, perché la gente segnala da dove si trova

Una bacheca di feedback funziona solo se segnalare costa meno che lamentarsi da un'altra parte. Il che vuol dire andare a prendere le persone dove il problema è successo.

La pagina pubblica è la porta ovvia: un URL che condividi, con una vista a lista o a roadmap, i voti e un modulo. Va bene per un prodotto con utenti che se lo mettono tra i preferiti, e fa anche da prova visibile che il lavoro avanza, che vale più di una mail di stato che nessuno legge.

Il widget incorporabile è la seconda: un piccolo script sul tuo sito che apre un modulo sul posto. La persona non lascia mai la pagina dove sta il bug, che è esattamente il momento in cui è più disposta a descriverlo.

L'estensione Chrome è la terza, ed è quella che cambia di più i comportamenti. Il tuo utente seleziona il testo sbagliato su una pagina qualsiasi, clicca sull'estensione, e il ticket parte con l'URL e la selezione già allegati. Quello che ricevi non è "non funziona", è una segnalazione con le coordinate.

Per un'agenzia, la terza porta è di solito il cliente stesso, e la modalità portale clienti è su invito: una bacheca per cliente, nessun altro può vederla, nessun abbonamento SaaS in più nello stack.

Smistamento, perché "l'agente giusto" non è un agente solo

Un ticket in arrivo non è indirizzato a nessuno. È il problema pratico di qualunque casella di posta: qualcuno deve decidere chi lo prende.

I ticket che arrivano dall'esterno vengono smistati verso l'agente la cui specialità corrisponde, così un layout rotto va a uno specialista frontend e una query che perde va a uno backend, senza che tu debba fare il triage della coda a mano ogni mattina. Quando non è configurato niente, il ripiego è volutamente stupido e prevedibile: il primo agente di sviluppo del progetto, mai un ruolo di marketing o di product management che si trova per caso in cima alla lista.

Puoi anche puntare un ticket su un intero team di agenti invece che su uno solo, così che una richiesta di un cliente passi da uno step di sviluppo e poi da uno di QA prima di arrivare a te.

La parte che tutti dimenticano: cosa vede tornare indietro chi ha segnalato

Raccogliere feedback è facile. È chiudere il cerchio che fa perdere gente ai prodotti.

Quando un ticket entra in sviluppo, il suo autore lo viene a sapere. Quando viene prioritizzato, lo viene a sapere. Quando decidi che non lo farai, lo viene a sapere, con il motivo che hai scritto, che è molto meglio del silenzio. E quando la correzione esce davvero, riceve un messaggio che glielo dice, raggruppato in una sola notifica per rilascio invece di cinque mail separate per cinque ticket.

C'è un dettaglio più piccolo che conta più di quanto sembri: il commit che chiude un ticket utente cita per nome chi l'ha segnalato, e quel credito sopravvive fino al changelog pubblico. Le persone che vedono il proprio nome attaccato a una modifica rilasciata segnalano anche il bug successivo. È tutto qui il meccanismo di fidelizzazione, e non costa niente. Fai girare quel ciclo per qualche mese e ottieni lo sviluppo guidato dal feedback come fatto osservabile invece che come slogan: i voti decidono l'ordine, e l'ordine decide i rilasci.

Se una richiesta arriva vaga, la definizione del ticket si mette tra la segnalazione e il lavoro: un agente Product Manager trasforma la richiesta confusa in un mockup del tuo prodotto reale con la modifica applicata, così validi l'idea sullo stesso ticket prima che venga scritta una riga di codice.

Dove si fermano gli strumenti classici

Non è una stoccata a chi c'era prima. Canny, Featurebase, Fider e UserVoice fanno bene raccolta, deduplicazione e classifica, e hanno anni di rifinitura sulle parti che contano per i team di prodotto. Si fermano tutti nello stesso punto per la stessa ragione strutturale: sono stati costruiti per organizzazioni in cui lo sviluppo è un altro reparto, raggiungibile solo attraverso un'esportazione.

L'ultima riga è quella che decide. In un team grande, riscrivere una richiesta in una specifica è un lavoro vero con un valore vero, e l'esportazione non è il collo di bottiglia. In un team da una a cinque persone che rilascia con agenti di codice, quella riscrittura è il collo di bottiglia, ed è pura perdita.

Cosa questo non risolve

Una bacheca di feedback collegata agli agenti non è un pilota automatico, e trattarla come tale produce esattamente quello che ti aspetteresti.

I ticket scritti male continuano a produrre lavoro fatto male. Una segnalazione di una riga senza un percorso per riprodurre il problema non dà niente su cui lavorare a un agente, che farà con grande sicurezza la cosa sbagliata. La bacheca può solo trasmettere quello che è stato scritto.

Niente va in merge da solo. Un agente produce un branch e un diff, e tutte le regole che avevi sulla revisione del lavoro degli agenti restano valide, soprattutto per tutto quello che tocca autenticazione, pagamenti o dati. Un ticket che arriva da uno sconosciuto non è un motivo per abbassare quell'asticella. È un motivo per alzarla.

E il volume è reale. Una bacheca pubblica che funziona diventa rumorosa, che è un bel problema con un costo vero. I doppioni vengono segnalati al momento dell'invio, i voti separano quello che voleva una persona da quello che volevano in quaranta, e chiudere un ticket con un motivo scritto è più rapido che lasciarlo marcire. Ma qualcuno la casella deve comunque leggerla.

Metterla in piedi

Apri il backlog di un progetto, clicca su Backlog pubblico, scegli un URL e una modalità di visibilità. La configurazione è tutta qui, e da quel momento la pagina è online.

Quello che fai dopo conta più della configurazione. Metti il link dove i tuoi utenti già sono: nell'app, nelle risposte del supporto, in fondo alle note di rilascio. Una bacheca di feedback che nessuno conosce non raccoglie niente, e il modo in cui questa funzionalità fallisce non è tecnico: è che il link non viene mai condiviso.

AgentsRoom è il centro di comando su cui gira tutto questo: una bacheca dei task dove una card diventa un agente in esecuzione, una pagina di feedback pubblica o privata collegata a essa, un widget incorporabile, un'estensione Chrome, e notifiche ai clienti che partono quando il lavoro esce davvero. Funziona con Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe e Kimi Code.

Scarica AgentsRoom e pubblica la tua prima bacheca.

Domande frequenti

Che cos'è una bacheca di feedback per gli agenti IA?

Una pagina pubblica dove gli utenti segnalano bug e chiedono funzionalità, collegata alla stessa bacheca dei task da cui lavorano i tuoi agenti di codice. La differenza rispetto a uno strumento di feedback classico sta nell'ultimo passaggio: invece di esportare la richiesta in un tracker e riscriverla come prompt, è il ticket stesso a diventare il brief dell'agente, con le parole usate da chi ha segnalato.

Un ticket di un utente può davvero avviare da solo un agente IA?

Avviare resta un atto deliberato: qualcuno sposta il ticket in In Progress, e l'agente parte con il ticket come prompt. Quello che è automatico è lo smistamento, che manda un ticket in arrivo all'agente la cui specialità corrisponde. L'esecuzione automatica integrale di qualunque cosa scriva uno sconosciuto non è una funzionalità, è una falla di sicurezza.

In cosa è diverso da Canny, Featurebase, Fider o UserVoice?

Quelli sono eccellenti nel raccogliere, deduplicare e ordinare la domanda, e si fermano tutti allo stesso punto: ti consegnano una lista prioritizzata, e resta comunque un umano a trasformare ogni riga in lavoro. Non hanno uno strato di esecuzione perché sono nati per team di prodotto i cui sviluppatori stanno da un'altra parte. Qui la scommessa è opposta: la superficie di raccolta e la superficie di esecuzione sono lo stesso oggetto.

Bisogna per forza rendere pubblica la propria roadmap per usarlo?

No. Pubblica, non elencata e su invito sono tre modalità distinte. Un'agenzia che tiene una bacheca per cliente usa la modalità su invito e nessun motore di ricerca la vede mai. Uno sviluppatore solo che vuole richieste e voti dai suoi utenti usa quella pubblica. La parte di esecuzione funziona allo stesso modo in tutte e tre.

Cosa impedisce a una bacheca pubblica di riempirsi di rumore?

Niente impedisce al rumore di arrivare, e far finta del contrario sarebbe disonesto. Quello che cambia la bacheca è il costo di gestirlo: i quasi doppioni vengono segnalati al momento dell'invio, i voti ti dicono cosa si vuole davvero, e un ticket che non farai viene chiuso con un motivo che arriva al suo autore. I ticket che tieni arrivano con il contesto che uno sconosciuto ha già scritto per te.