Un tablero de feedback para agentes de IA: deja que tus usuarios escriban el prompt

Un usuario te escribe a las once de la noche. "El botón de exportar no hace nada en Safari."

Ya sabes lo que viene después, porque ha pasado cien veces. Lo lees. Lo entiendes. Luego abres un gestor de tareas y lo escribes otra vez, con tus palabras, con las rutas de los archivos, los pasos para reproducirlo y el contexto que el usuario no tenía. Y más tarde abres un terminal y lo escribes por tercera vez, en forma de prompt.

Tres redacciones de la misma petición. La primera salió gratis y la escribió la persona que se topó de verdad con el bug. Las otras dos las pagas tú.

Esa segunda y esa tercera redacción son la parte del oficio que los agentes han vuelto absurda.

Lo último que sigues escribiendo a mano

Los agentes de código han eliminado un montón de tecleo. No han eliminado el encargo. Algo tiene que seguir diciéndole al agente qué construir, con detalle suficiente para que no lo adivine, y ese algo sigue siendo un humano sentado a un teclado convirtiendo las palabras de otros en instrucciones.

Solo que esa conversión casi nunca aporta nada. Un buen reporte de bug ya contiene lo que un agente necesita: qué se esperaba, qué ocurrió, en qué página, en qué navegador. Una buena petición de funcionalidad ya contiene la intención y el motivo. Quien la escribió estaba más cerca del problema que tú.

Y aun así tratamos ese texto como materia prima que hay que reprocesar, porque la herramienta que lo recogió y la herramienta que ejecuta el trabajo nunca fueron la misma. El feedback vive en un producto, los tickets en otro, y el agente corre en un terminal que no sabe nada de ninguno de los dos.

Elimina el hueco y el paso de reescritura se queda sin sitio donde ocurrir.

En qué se convierte un tablero de feedback cuando el tablero puede ejecutar

Un backlog público es una página a la que llegan tus usuarios. Reportan un bug, piden una funcionalidad, votan lo que pidió otro, siguen un hilo y ven cómo cambia un estado. Hasta aquí esto es un tablero de feedback, y los hay buenos.

La diferencia está en dónde aterriza el ticket. No aterriza en un producto de feedback a la espera de que alguien lo exporte. Aterriza en el tablero de tareas desde el que ya trabajan tus agentes, como un ticket de pleno derecho, al lado de los que escribiste tú.

A partir de ahí, moverlo a In Progress lanza un agente cuyas instrucciones son el propio ticket: el título, la descripción con las palabras de quien lo escribió, la página en la que estaba, el navegador que usaba y la conversación que hayas tenido con él desde entonces. Nadie ha reescrito nada. El prompt es el reporte.

La consecuencia interesante no es la velocidad. Es que quien describió el problema pasa a ser quien especifica el trabajo, que es lo que todo el mundo dice querer del feedback de usuarios y casi nadie organiza para que ocurra. Esa inversión tiene nombre: un backlog dirigido por el cliente. La cola deja de ser tu apuesta sobre lo que importa y se convierte en el registro de lo que se pidió de verdad.

Tres puertas, porque la gente reporta donde está

Un tablero de feedback solo funciona si reportar cuesta menos que quejarse en otra parte. Eso significa ir a buscar a la gente donde ocurrió el problema.

La página pública es la puerta evidente: una URL que compartes, con una vista de lista o de roadmap, votos y un formulario. Funciona para un producto con usuarios que la van a guardar en marcadores, y de paso sirve como prueba visible de que el trabajo avanza, que vale más que un correo de estado que nadie lee.

El widget integrable es la segunda: un script pequeño en tu propia web que abre un formulario allí mismo. La persona no sale de la página donde está el bug, que es justo el momento en el que más dispuesta está a describirlo.

La extensión de Chrome es la tercera, y es la que más cambia el comportamiento. Tu usuario selecciona en cualquier página el texto que falla, hace clic en la extensión y el ticket se crea con la URL y la selección ya adjuntas. Lo que recibes no es "no funciona", es un reporte con coordenadas.

En una agencia, la tercera puerta suele ser el propio cliente, y el modo portal de cliente es solo por invitación: un tablero por cliente, nadie más puede verlo, ninguna suscripción SaaS extra en el stack.

Enrutado, porque "el agente adecuado" no es un solo agente

Un ticket que entra no va dirigido a nadie. Ese es el problema práctico de cualquier bandeja de entrada: alguien tiene que decidir quién lo coge.

Los tickets que llegan de fuera se enrutan al agente cuya especialidad encaja, así que un layout roto va a un especialista de frontend y una consulta que se desmadra va a uno de backend, sin que tengas que triar la cola a mano cada mañana. Cuando no hay nada configurado, el comportamiento por defecto es deliberadamente tonto y previsible: el primer agente de desarrollo del proyecto, nunca un rol de marketing o de producto que casualmente esté arriba de la lista.

También puedes apuntar un ticket a un equipo de agentes entero en vez de a uno solo, de modo que una petición de cliente pase por una etapa de desarrollo y luego por una de QA antes de llegar a ti.

La parte que todo el mundo olvida: qué recibe de vuelta quien reportó

Recoger feedback es fácil. Donde los productos pierden a la gente es al cerrar el círculo.

Cuando un ticket entra en desarrollo, se avisa a su autor. Cuando se prioriza, se le avisa. Cuando decides que no lo vas a hacer, se le avisa, con el motivo que escribiste, que es infinitamente mejor que el silencio. Y cuando el arreglo sale de verdad, recibe un mensaje que se lo dice, agrupado en una sola notificación por versión en lugar de cinco correos sueltos para cinco tickets.

Hay un detalle menor que pesa más de lo que parece: el commit que cierra un ticket de usuario acredita por su nombre a quien lo reportó, y ese crédito sobrevive hasta el changelog público. La gente que ve su nombre pegado a un cambio publicado también reporta el siguiente bug. Ese es todo el mecanismo de retención, y no cuesta nada. Deja ese círculo girando unos meses y tienes desarrollo guiado por el feedback como un hecho observable y no como un eslogan: los votos deciden el orden, y el orden decide las versiones.

Si una petición llega vaga, el acotado de tickets se coloca entre el reporte y el trabajo: un agente Product Manager convierte la petición difusa en una maqueta de tu producto real con el cambio aplicado, así validas la idea en el propio ticket antes de escribir una línea de código.

Dónde se paran las herramientas clásicas

Esto no va contra las herramientas ya establecidas. Canny, Featurebase, Fider y UserVoice hacen bien la recogida, la deduplicación y la priorización, y llevan años puliendo justo las partes que le importan a un equipo de producto. Se paran en el mismo punto por la misma razón estructural: nacieron para organizaciones donde ingeniería es otro departamento, al que solo se llega a través de una exportación.

La última fila es la que decide. En un equipo grande, convertir una petición en una especificación es un trabajo real con valor real, y la exportación no es el cuello de botella. En un equipo de una a cinco personas que publica con agentes de código, esa reescritura es el cuello de botella, y es pérdida pura.

Lo que esto no resuelve

Un tablero de feedback conectado a agentes no es un piloto automático, y tratarlo como tal produce exactamente lo que cabría esperar.

Los tickets malos siguen produciendo trabajo malo. Un reporte de una línea sin pasos para reproducirlo no le da al agente nada con lo que trabajar, y hará algo equivocado con toda la seguridad del mundo. El tablero solo puede transmitir lo que se escribió.

Nada se fusiona solo. Un agente produce una rama y un diff, y todas las reglas que ya tenías sobre revisar la salida de un agente siguen valiendo, sobre todo en lo que toca a autenticación, pagos o datos. Que un ticket venga de un desconocido no es motivo para bajar el listón. Es motivo para subirlo.

Y el volumen es real. Un tablero público que funciona se llena de ruido, que es un buen problema con un coste real. Los duplicados se marcan en el momento del envío, los votos separan lo que quería una persona de lo que quieren cuarenta, y cerrar un ticket con un motivo escrito es más rápido que dejarlo pudrirse. Pero alguien sigue teniendo que leer la bandeja de entrada.

Cómo se monta

Abre el backlog de un proyecto, pulsa Public backlog, elige una URL y un modo de visibilidad. Ese es todo el montaje, y a partir de ahí la página ya está en línea.

Lo que hagas después importa más que el montaje. Pon el enlace donde ya están tus usuarios: en la app, en tus respuestas de soporte, al final de tus notas de versión. Un tablero de feedback que nadie conoce no recoge nada, y el modo de fallo de esta funcionalidad no es técnico: es que el enlace nunca se llega a compartir.

AgentsRoom es el centro de mando sobre el que funciona todo esto: un tablero de tareas donde una tarjeta se convierte en un agente en marcha, una página de feedback pública o privada conectada a él, un widget integrable, una extensión de Chrome y notificaciones al cliente que se disparan cuando el trabajo sale de verdad. Funciona con Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe y Kimi Code.

Descarga AgentsRoom y publica tu primer tablero.

Preguntas frecuentes

¿Qué es un tablero de feedback para agentes de IA?

Una página pública donde los usuarios reportan bugs y piden funcionalidades, conectada al mismo tablero de tareas desde el que ejecutan tus agentes de código. La diferencia con una herramienta de feedback clásica está en el último paso: en lugar de exportar la petición a un gestor de incidencias y reescribirla como prompt, el propio ticket se convierte en las instrucciones del agente, con las palabras que usó quien lo reportó.

¿De verdad puede un ticket de usuario arrancar un agente de IA por sí solo?

Arrancar sigue siendo un acto deliberado: alguien mueve el ticket a In Progress y el agente se lanza con el ticket como prompt. Lo que sí es automático es el enrutado, que manda cada ticket entrante al agente cuya especialidad encaja. Ejecutar de forma automática cualquier cosa que escriba un desconocido no es una funcionalidad, es un agujero de seguridad.

¿En qué se diferencia esto de Canny, Featurebase, Fider o UserVoice?

Son excelentes recogiendo, deduplicando y ordenando la demanda, y todas se paran en el mismo sitio: te entregan una lista priorizada y sigue haciendo falta un humano que convierta cada línea en trabajo. No tienen capa de ejecución porque nacieron para equipos de producto cuyos desarrolladores están en otra parte. Aquí la apuesta es la contraria: la superficie donde se recoge y la superficie donde se ejecuta son el mismo objeto.

¿Hay que hacer público el roadmap para poder usarlo?

No. Público, no listado y solo por invitación son tres modos distintos. Una agencia que lleva un tablero por cliente usa el modo por invitación y ningún buscador lo ve jamás. Un desarrollador en solitario que quiere peticiones y votos de sus usuarios usa el modo público. La parte de ejecución funciona igual en los tres.

¿Qué impide que un tablero público se llene de ruido?

Nada impide que llegue el ruido, y decir lo contrario sería deshonesto. Lo que cambia el tablero es el coste de gestionarlo: los casi duplicados se marcan al enviarlos, los votos te dicen qué se quiere de verdad y un ticket que no vas a hacer se cierra con un motivo que llega a su autor. Los tickets que sí te quedas llegan con el contexto que un desconocido ya escribió por ti.