Ein Feedback-Board für KI-Agenten: Lass deine Nutzer den Prompt schreiben

Ein Nutzer schreibt dir um 23 Uhr. "Der Export-Button macht auf Safari gar nichts."

Du weißt, was jetzt kommt, weil es schon hundertmal so war. Du liest es. Du verstehst es. Dann öffnest du einen Tracker und tippst es noch einmal, in deinen eigenen Worten, mit den Dateipfaden, den Schritten zum Reproduzieren und dem Kontext, den der Nutzer nicht hatte. Und später öffnest du ein Terminal und tippst es ein drittes Mal, als Prompt.

Dreimal dieselbe Meldung geschrieben. Das erste Mal war gratis und kam von der Person, die den Bug tatsächlich erwischt hat. Die anderen beiden gehen auf deine Rechnung.

Genau dieses zweite und dritte Schreiben ist der Teil der Arbeit, den die Agenten absurd gemacht haben.

Das Letzte, was du noch von Hand tippst

Coding-Agenten haben viel Tipparbeit abgeschafft. Das Briefing haben sie nicht abgeschafft. Irgendetwas muss dem Agenten weiterhin sagen, was zu bauen ist, und zwar genau genug, damit er nicht rät. Dieses Irgendetwas ist immer noch ein Mensch an einer Tastatur, der die Worte anderer Leute in Anweisungen übersetzt.

Nur ist diese Übersetzung oft sinnlos. Ein guter Bugreport enthält bereits alles, was ein Agent braucht: was erwartet wurde, was passiert ist, auf welcher Seite, in welchem Browser. Ein guter Feature-Wunsch enthält bereits die Absicht und den Grund dahinter. Die Person, die ihn geschrieben hat, war näher am Problem als du.

Stattdessen behandeln wir diesen Text als Rohmaterial, das erst noch aufbereitet werden muss, weil das Werkzeug, das ihn eingesammelt hat, nie dasselbe war wie das Werkzeug, in dem gearbeitet wird. Feedback liegt in einem Produkt, Tickets in einem zweiten, und der Agent läuft in einem Terminal, das von beiden nichts weiß.

Nimm die Lücke weg, und das Neuschreiben hat keinen Ort mehr, an dem es stattfinden könnte.

Was aus einem Feedback-Board wird, wenn das Board ausführen kann

Ein öffentliches Backlog ist eine Seite, die deine Nutzer erreichen können. Sie melden einen Bug, wünschen sich ein Feature, stimmen für den Vorschlag von jemand anderem, verfolgen einen Thread und sehen, wie sich ein Status ändert. Bis hierhin ist das ein Feedback-Board, und davon gibt es gute.

Der Unterschied liegt darin, wo das Ticket landet. Es landet nicht in einem Feedback-Produkt und wartet auf den Export. Es landet auf dem Task-Board, aus dem deine Agenten ohnehin schon arbeiten, als vollwertiges Ticket, direkt neben denen, die du selbst geschrieben hast.

Von dort aus startet das Verschieben auf In Progress einen Agenten, dessen Briefing das Ticket ist: der Titel, die Beschreibung in den Worten des Melders, die Seite, auf der er war, der Browser, den er benutzt hat, und der Austausch, den du seitdem mit ihm hattest. Niemand hat irgendetwas neu geschrieben. Der Prompt ist die Meldung.

Die interessante Folge ist nicht Geschwindigkeit. Sie ist, dass die Person, die das Problem beschrieben hat, jetzt auch die Person ist, die die Arbeit spezifiziert hat. Genau das behaupten alle von Nutzerfeedback zu wollen, und fast niemand richtet seine Abläufe darauf aus. Diese Umkehrung hat einen Namen: ein kundengetriebenes Backlog. Die Warteschlange ist nicht mehr deine Vermutung darüber, was wichtig ist, sondern ein Protokoll dessen, was tatsächlich gewünscht wurde.

Drei Türen, weil Leute dort melden, wo sie gerade sind

Ein Feedback-Board funktioniert nur, wenn Melden billiger ist als sich woanders zu beschweren. Das heißt: die Leute dort abholen, wo das Problem aufgetreten ist.

Die öffentliche Seite ist die naheliegende Tür: eine URL, die du teilst, mit Listen- oder Roadmap-Ansicht, Upvotes und einem Formular. Das passt zu einem Produkt mit Nutzern, die sich die Seite als Lesezeichen speichern, und nebenbei ist sie ein sichtbarer Beleg dafür, dass sich etwas bewegt, was mehr wert ist als eine Status-Mail, die niemand liest.

Das einbettbare Widget ist die zweite: ein kleines Skript auf deiner eigenen Seite, das ein Formular direkt an Ort und Stelle öffnet. Die Person verlässt die Seite mit dem Bug nie, und genau in diesem Moment ist sie am ehesten bereit, ihn zu beschreiben.

Die Chrome-Erweiterung ist die dritte, und sie verändert das Verhalten am stärksten. Dein Nutzer markiert den kaputten Text auf einer beliebigen Seite, klickt auf die Erweiterung, und das Ticket ist abgeschickt, mit URL und Auswahl bereits im Anhang. Was bei dir ankommt, ist nicht "geht nicht", sondern eine Meldung mit Koordinaten.

Für eine Agentur ist die dritte Tür meistens der Kunde selbst, und der Modus Kundenportal läuft nur auf Einladung: ein Board pro Kunde, sonst sieht es niemand, kein zusätzliches SaaS-Abo im Stack.

Routing, weil "der richtige Agent" nicht ein einzelner Agent ist

Ein eingehendes Ticket ist an niemanden adressiert. Das ist das praktische Problem jedes Posteingangs: Irgendjemand muss entscheiden, wer es übernimmt.

Tickets, die von außen kommen, werden an den Agenten geroutet, dessen Spezialgebiet dazu passt: Ein kaputtes Layout geht an einen Frontend-Spezialisten, eine Query, die Speicher frisst, an einen Backend-Spezialisten, ohne dass du jeden Morgen die Warteschlange von Hand sortierst. Ist nichts konfiguriert, ist der Rückfall bewusst dumm und vorhersehbar: der erste Entwicklungsagent im Projekt, nie eine Marketing- oder PM-Rolle, die zufällig ganz oben in der Liste steht.

Du kannst ein Ticket auch auf ein ganzes Agenten-Team richten statt auf einen einzelnen Agenten, sodass ein Kundenwunsch erst durch einen Dev-Schritt und dann durch einen QA-Schritt läuft, bevor er bei dir ankommt.

Der Teil, den alle vergessen: was beim Melder zurückkommt

Feedback einsammeln ist leicht. Den Kreis zu schließen ist die Stelle, an der Produkte ihre Leute verlieren.

Wenn ein Ticket in die Entwicklung geht, erfährt sein Autor davon. Wenn es priorisiert wird, erfährt er davon. Wenn du entscheidest, es nicht zu machen, erfährt er auch das, mit der Begründung, die du geschrieben hast, und das ist deutlich besser als Schweigen. Und wenn der Fix tatsächlich ausgeliefert wird, bekommt er eine Nachricht, die genau das sagt, gebündelt zu einer Benachrichtigung pro Release statt fünf einzelner Mails für fünf Tickets.

Ein kleineres Detail wiegt schwerer, als es aussieht: Der Commit, der ein Nutzer-Ticket schließt, nennt den Melder beim Vornamen, und diese Nennung übersteht den Weg bis ins öffentliche Changelog. Wer seinen Namen an einer ausgelieferten Änderung sieht, meldet auch den nächsten Bug. Das ist der komplette Bindungsmechanismus, und er kostet nichts. Lass diese Schleife ein paar Monate laufen, und du bekommst feedbackgetriebene Entwicklung als beobachtbare Tatsache statt als Slogan: Die Upvotes bestimmen die Reihenfolge, und die Reihenfolge bestimmt die Releases.

Kommt ein Wunsch vage an, sitzt das Zuschneiden von Tickets zwischen Meldung und Arbeit: Ein Product-Manager-Agent macht aus dem unscharfen Wunsch ein Mockup deines echten Produkts mit der eingebauten Änderung, sodass du die Idee am selben Ticket abnimmst, bevor eine Zeile Code geschrieben wird.

Wo die klassischen Tools aufhören

Das ist kein Seitenhieb auf die Etablierten. Canny, Featurebase, Fider und UserVoice machen Sammeln, Entdoppeln und Gewichten gut, und sie haben jahrelangen Feinschliff an genau den Stellen, die Produktteams wichtig sind. Sie hören alle an derselben Stelle auf, und das aus demselben strukturellen Grund: Sie wurden für Organisationen gebaut, in denen die Entwicklung eine andere Abteilung ist, erreichbar nur über einen Export.

Die letzte Zeile entscheidet. In einem großen Team ist es ein echter Job mit echtem Wert, aus einem Wunsch eine Spezifikation zu machen, und der Export ist nicht der Engpass. In einem Team von einer bis fünf Personen, das mit Coding-Agenten ausliefert, ist genau dieses Neuschreiben der Engpass, und es ist reiner Verlust.

Was das nicht löst

Ein Feedback-Board, das an Agenten angebunden ist, ist kein Autopilot, und wer es als einen behandelt, bekommt genau das Ergebnis, das zu erwarten ist.

Schlechte Tickets erzeugen weiterhin schlechte Arbeit. Eine einzeilige Meldung ohne Weg zum Reproduzieren gibt einem Agenten nichts an die Hand, und er wird selbstbewusst etwas Falsches tun. Das Board kann nur weitergeben, was geschrieben wurde.

Nichts merged sich von selbst. Ein Agent produziert einen Branch und einen Diff, und jede Regel, die du zum Prüfen von Agenten-Output hattest, gilt weiter, besonders bei allem, was Authentifizierung, Zahlungen oder Daten berührt. Ein Ticket von einem Fremden ist kein Grund, diese Latte tiefer zu legen. Es ist ein Grund, sie höher zu legen.

Und die Menge ist real. Ein öffentliches Board, das funktioniert, wird laut, und das ist ein gutes Problem mit echten Kosten. Duplikate werden beim Absenden markiert, Upvotes trennen das, was eine Person wollte, von dem, was vierzig Leute wollten, und ein Ticket mit schriftlicher Begründung zu schließen geht schneller, als es vergammeln zu lassen. Aber den Posteingang liest trotzdem jemand.

Einrichten

Öffne das Backlog eines Projekts, klick auf Public backlog, wähl eine URL und einen Sichtbarkeitsmodus. Das ist die gesamte Einrichtung, und ab diesem Moment ist die Seite live.

Was du danach machst, zählt mehr als die Einrichtung. Setz den Link dorthin, wo deine Nutzer ohnehin schon sind: in die App, in deine Support-Antworten, unter deine Release Notes. Ein Feedback-Board, von dem niemand weiß, sammelt nichts, und der Fehlerfall dieser Funktion ist nicht technisch: Der Link wird schlicht nie geteilt.

AgentsRoom ist das Kommandozentrum, auf dem das läuft: ein Task-Board, auf dem aus einer Karte ein laufender Agent wird, eine öffentliche oder private Feedback-Seite, die daran angebunden ist, ein einbettbares Widget, eine Chrome-Erweiterung und Kundenbenachrichtigungen, die auslösen, wenn die Arbeit tatsächlich ausgeliefert wird. Es funktioniert mit Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe und Kimi Code.

AgentsRoom herunterladen und dein erstes Board veröffentlichen.

Häufig gestellte Fragen

Was ist ein Feedback-Board für KI-Agenten?

Eine öffentliche Seite, auf der Nutzer Bugs melden und sich Features wünschen, angebunden an dasselbe Task-Board, aus dem deine Coding-Agenten arbeiten. Der Unterschied zu einem klassischen Feedback-Tool liegt im letzten Schritt: Statt den Wunsch in einen Tracker zu exportieren und als Prompt neu zu formulieren, wird das Ticket selbst zum Briefing des Agenten, in den Worten, die der Melder benutzt hat.

Kann ein Nutzer-Ticket wirklich von allein einen KI-Agenten starten?

Der Start bleibt eine bewusste Handlung: Jemand zieht das Ticket auf In Progress, und der Agent startet mit dem Ticket als Prompt. Automatisch läuft das Routing, das ein eingehendes Ticket an den Agenten schickt, dessen Spezialgebiet dazu passt. Alles automatisch auszuführen, was ein Fremder schreibt, ist kein Feature, sondern ein Sicherheitsloch.

Worin unterscheidet sich das von Canny, Featurebase, Fider oder UserVoice?

Die sind hervorragend darin, Nachfrage zu sammeln, zu entdoppeln und zu gewichten, und sie hören alle an derselben Stelle auf: Du bekommst eine priorisierte Liste, und ein Mensch macht aus jeder Zeile trotzdem noch Arbeit. Ihnen fehlt die Ausführungsebene, weil sie für Produktteams gebaut wurden, deren Entwickler woanders sitzen. Die Wette hier ist die umgekehrte: Die Fläche, auf der gesammelt wird, und die Fläche, auf der ausgeführt wird, sind dasselbe Objekt.

Muss man seine Roadmap öffentlich machen, um das zu nutzen?

Nein. Öffentlich, nicht gelistet und nur auf Einladung sind drei getrennte Modi. Eine Agentur mit einem Board pro Kunde nimmt den Einladungsmodus, und keine Suchmaschine bekommt es je zu sehen. Ein Solo-Entwickler, der Wünsche und Upvotes von seinen Nutzern will, nimmt öffentlich. Die Ausführung funktioniert in allen drei Modi gleich.

Was verhindert, dass ein öffentliches Board mit Rauschen volläuft?

Nichts hält das Rauschen davon ab anzukommen, und etwas anderes zu behaupten wäre unehrlich. Was das Board ändert, sind die Kosten im Umgang damit: Fast-Duplikate werden beim Absenden markiert, Upvotes zeigen dir, was tatsächlich gewollt ist, und ein Ticket, das du nicht machen wirst, wird mit einer Begründung geschlossen, die bei seinem Autor ankommt. Die Tickets, die übrig bleiben, kommen mit dem Kontext, den ein Fremder dir schon geschrieben hat.