Tablica feedbacku dla agentów AI: niech prompt napiszą twoi użytkownicy

Użytkownik pisze do ciebie o dwudziestej trzeciej. "Przycisk eksportu nic nie robi w Safari".

Wiesz, co będzie dalej, bo zdarzyło się to już sto razy. Czytasz. Rozumiesz. Potem otwierasz tracker i piszesz to samo jeszcze raz, własnymi słowami, ze ścieżkami plików, krokami reprodukcji i całym kontekstem, którego użytkownik nie miał. A później otwierasz terminal i piszesz to po raz trzeci, jako prompt.

Trzy zapisy tego samego zgłoszenia. Pierwszy był darmowy i przyszedł od osoby, która realnie natrafiła na ten błąd. Dwa pozostałe są twoje.

Ten drugi i trzeci zapis to ta część roboty, którą agenty uczyniły absurdalną.

Ostatnia rzecz, którą wciąż piszesz ręcznie

Agenty kodujące usunęły mnóstwo pisania. Nie usunęły briefu. Coś nadal musi powiedzieć agentowi, co ma zbudować, na tyle dokładnie, żeby nie zgadywał, a tym czymś nadal jest człowiek siedzący przy klawiaturze i przekładający cudze słowa na instrukcje.

Tyle że to przekładanie jest zwykle bez sensu. Dobre zgłoszenie błędu zawiera już wszystko, czego agent potrzebuje: czego się spodziewano, co się wydarzyło, na której stronie, w której przeglądarce. Dobra prośba o funkcję zawiera już intencję i jej powód. Osoba, która to napisała, była bliżej problemu niż ty.

Zamiast tego traktujemy ten tekst jak surowiec do ponownej obróbki, bo narzędzie, które go zebrało, i narzędzie, które wykonuje pracę, nigdy nie były tym samym narzędziem. Feedback mieszka w jednym produkcie, zgłoszenia w drugim, a agent działa w terminalu, który nie wie o żadnym z nich.

Zlikwiduj tę szczelinę, a etap przepisywania nie ma już gdzie się wydarzyć.

Czym staje się tablica feedbacku, gdy tablica potrafi wykonywać

Publiczny backlog to strona, do której docierają twoi użytkownicy. Zgłaszają błąd, proszą o funkcję, głosują na to, o co poprosił ktoś inny, śledzą wątek i patrzą, jak zmienia się status. Na razie to zwykła tablica feedbacku i istnieją dobre.

Różnica polega na tym, gdzie ląduje zgłoszenie. Nie ląduje w produkcie do feedbacku, czekając na eksport. Ląduje na tablicy zadań, z której twoje agenty i tak już pracują, jako pełnoprawne zgłoszenie, obok tych, które napisałeś sam.

Stamtąd przeniesienie go do In Progress uruchamia agenta, którego briefem jest to zgłoszenie: tytuł, opis własnymi słowami zgłaszającego, strona, na której był, przeglądarka, której używał, i cała rozmowa, którą od tamtej pory z nim odbyłeś. Nikt niczego nie przepisał. Prompt to zgłoszenie.

Ciekawą konsekwencją nie jest szybkość. Chodzi o to, że osoba, która opisała problem, jest teraz osobą, która wyspecyfikowała pracę, czyli o to, czego wszyscy rzekomo oczekują po feedbacku użytkowników i pod co prawie nikt się nie organizuje. Ta inwersja ma swoją nazwę i jest nią backlog sterowany przez klienta: kolejka przestaje być twoim domysłem na temat tego, co ważne, a staje się zapisem tego, o co realnie poproszono.

Trzy drzwi, bo ludzie zgłaszają tam, gdzie są

Tablica feedbacku działa tylko wtedy, gdy zgłoszenie kosztuje mniej niż narzekanie gdzie indziej. To znaczy, że trzeba wyjść ludziom naprzeciw tam, gdzie problem się wydarzył.

Publiczna strona to oczywiste drzwi: adres URL, który udostępniasz, z listą albo widokiem roadmapy, głosami i formularzem. Sprawdza się przy produkcie, którego użytkownicy dodadzą go do zakładek, i przy okazji jest widocznym dowodem, że praca idzie do przodu, a to warte więcej niż mail o statusie, którego nikt nie czyta.

Osadzalny widget to drugie drzwi: mały skrypt na twojej własnej stronie, który otwiera formularz na miejscu. Człowiek nigdy nie opuszcza strony, na której siedzi błąd, czyli momentu, w którym najbardziej chce mu się go opisać.

Rozszerzenie do Chrome to trzecie drzwi i to ono najmocniej zmienia zachowania. Twój użytkownik zaznacza zepsuty tekst na dowolnej stronie, klika rozszerzenie i zgłoszenie trafia do ciebie z już dołączonym adresem URL oraz zaznaczeniem. Dostajesz nie "nie działa", tylko raport ze współrzędnymi.

W agencji trzecimi drzwiami jest zwykle sam klient, a tryb portalu klienta działa tylko na zaproszenie: jedna tablica na klienta, nikt inny jej nie widzi, żadnej dodatkowej subskrypcji SaaS w stosie.

Routing, bo "właściwy agent" to nie jeden agent

Przychodzące zgłoszenie nie jest zaadresowane do nikogo. To praktyczny problem każdej skrzynki odbiorczej: ktoś musi zdecydować, kto je bierze.

Zgłoszenia przychodzące z zewnątrz trafiają do agenta, którego specjalizacja pasuje, więc rozjechany layout idzie do specjalisty od frontendu, a przeciekające zapytanie do kogoś od backendu, bez ręcznego segregowania kolejki co rano. Kiedy nic nie jest skonfigurowane, zachowanie awaryjne jest celowo głupie i przewidywalne: pierwszy agent deweloperski w projekcie, nigdy rola marketingowa czy produktowa, która akurat stoi na górze listy.

Możesz też skierować zgłoszenie do całego zespołu agentów zamiast do jednego, tak żeby prośba klienta przeszła najpierw etap deweloperski, a potem etap QA, zanim dotrze do ciebie.

Część, o której wszyscy zapominają: co widzi zgłaszający

Zbieranie feedbacku jest łatwe. Produkty tracą ludzi na zamykaniu pętli.

Kiedy zgłoszenie wchodzi w development, jego autor dostaje o tym informację. Kiedy zostaje spriorytetyzowane, też. Kiedy zdecydujesz, że tego nie zrobisz, również, wraz z powodem, który napisałeś, a to nieporównywalnie lepsze niż cisza. A kiedy poprawka faktycznie trafia do wydania, zgłaszający dostaje wiadomość, że tak się stało, zgrupowaną w jedno powiadomienie na wydanie zamiast pięciu osobnych maili do pięciu zgłoszeń.

Jest jeszcze drobiazg, który znaczy więcej, niż wygląda: commit zamykający zgłoszenie użytkownika wymienia jego autora z imienia, a to podziękowanie przechodzi dalej do publicznego changelogu. Ludzie, którzy widzą swoje imię przy wydanej zmianie, zgłaszają kolejny błąd. To cały mechanizm retencji i nie kosztuje nic. Puść tę pętlę przez kilka miesięcy, a dostaniesz rozwój napędzany feedbackiem jako obserwowalny fakt, a nie hasło: głosy decydują o kolejności, a kolejność decyduje o wydaniach.

Jeśli prośba przychodzi mglista, między zgłoszeniem a pracą staje doprecyzowanie zgłoszenia: agent Product Manager zamienia rozmytą prośbę w makietę twojego prawdziwego produktu z naniesioną zmianą, więc pomysł walidujesz na tym samym zgłoszeniu, zanim powstanie choćby linijka kodu.

Gdzie zatrzymują się klasyczne narzędzia

To nie jest przytyk pod adresem zasiedziałych graczy. Canny, Featurebase, Fider i UserVoice dobrze robią zbieranie, deduplikację i porządkowanie, i mają lata dopracowywania tych elementów, które są ważne dla zespołów produktowych. Zatrzymują się w tym samym miejscu z tego samego strukturalnego powodu: powstały dla organizacji, w których inżynieria to inny dział, dostępny wyłącznie przez eksport.

Rozstrzyga ostatni wiersz. W dużym zespole przepisanie prośby na specyfikację to prawdziwa praca o prawdziwej wartości, a eksport nie jest wąskim gardłem. W zespole od jednej do pięciu osób, który wypuszcza produkt z agentami kodującymi, to właśnie przepisywanie jest wąskim gardłem i jest czystą stratą.

Czego to nie rozwiązuje

Tablica feedbacku podpięta do agentów nie jest autopilotem, a traktowanie jej jak autopilota daje dokładnie to, czego można się spodziewać.

Złe zgłoszenia nadal dają złą pracę. Jednolinijkowy raport bez ścieżki reprodukcji nie daje agentowi nic, z czym mógłby pracować, a on i tak z pełnym przekonaniem zrobi coś nie tak. Tablica może przekazać dalej tylko to, co zostało napisane.

Nic nie mergeuje się samo. Agent produkuje gałąź i diff, i nadal obowiązuje każda zasada, jaką miałeś wobec przeglądania wyników agenta, zwłaszcza przy wszystkim, co dotyka autoryzacji, płatności albo danych. Zgłoszenie od obcej osoby nie jest powodem, żeby obniżyć tę poprzeczkę. Jest powodem, żeby ją podnieść.

Ilość też jest realna. Publiczna tablica, której się udaje, robi się hałaśliwa, a to dobry problem o prawdziwym koszcie. Duplikaty są oznaczane w momencie wysyłki, głosy oddzielają to, czego chciała jedna osoba, od tego, czego chciało czterdzieści, a zamknięcie zgłoszenia z napisanym powodem jest szybsze niż pozwolenie mu gnić. Ale ktoś nadal czyta tę skrzynkę.

Uruchomienie

Otwórz backlog projektu, kliknij Public backlog, wybierz adres URL i tryb widoczności. To cała konfiguracja, a strona jest w tym momencie żywa.

To, co robisz potem, liczy się bardziej niż sama konfiguracja. Umieść link tam, gdzie twoi użytkownicy już są: w aplikacji, w odpowiedziach supportu, na dole notek o wydaniu. Tablica feedbacku, o której nikt nie wie, nie zbiera niczego, a scenariusz porażki tej funkcji nie jest techniczny: polega na tym, że link nigdy nie zostaje udostępniony.

AgentsRoom to centrum dowodzenia, na którym to wszystko działa: tablica zadań, gdzie karta staje się działającym agentem, publiczna albo prywatna strona feedbacku podpięta do niej, osadzalny widget, rozszerzenie do Chrome i powiadomienia dla klientów odpalane wtedy, gdy praca naprawdę trafia do wydania. Działa z Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe i Kimi Code.

Pobierz AgentsRoom i opublikuj swoją pierwszą tablicę.

Często zadawane pytania

Czym jest tablica feedbacku dla agentów AI?

To publiczna strona, na której użytkownicy zgłaszają błędy i proszą o funkcje, podpięta do tej samej tablicy zadań, z której wykonują twoje agenty kodujące. Różnica wobec klasycznego narzędzia do feedbacku leży w ostatnim kroku: zamiast eksportować zgłoszenie do trackera i przepisywać je na prompt, samo zgłoszenie staje się briefem agenta, w słowach, których użył zgłaszający.

Czy zgłoszenie użytkownika naprawdę może samo uruchomić agenta AI?

Uruchomienie pozostaje świadomą decyzją: ktoś przenosi zgłoszenie do In Progress, a agent startuje z tym zgłoszeniem jako promptem. Automatyczny jest routing, który kieruje przychodzące zgłoszenie do agenta o pasującej specjalizacji. Pełne automatyczne wykonywanie wszystkiego, co napisze obca osoba, to nie funkcja, tylko dziura w bezpieczeństwie.

Czym to się różni od Canny, Featurebase, Fider czy UserVoice?

Tamte świetnie zbierają, deduplikują i porządkują zapotrzebowanie, i wszystkie zatrzymują się w tym samym miejscu: podają ci uporządkowaną listę, a człowiek i tak zamienia każdą linijkę w pracę. Nie mają warstwy wykonawczej, bo powstały dla zespołów produktowych, których inżynierowie siedzą gdzie indziej. Zakład jest tutaj odwrotny: powierzchnia zbierania i powierzchnia wykonania to ten sam obiekt.

Czy trzeba upublicznić roadmapę, żeby z tego korzystać?

Nie. Publiczna, niepubliczna z linkiem i tylko na zaproszenie to trzy osobne tryby. Agencja prowadząca jedną tablicę na klienta używa trybu na zaproszenie i żadna wyszukiwarka nigdy jej nie zobaczy. Solowy deweloper, który chce próśb i głosów od użytkowników, używa trybu publicznego. Część wykonawcza działa tak samo we wszystkich trzech.

Co powstrzymuje publiczną tablicę przed zalaniem szumem?

Nic nie powstrzymuje szumu przed nadejściem i udawanie czegoś innego byłoby nieuczciwe. Tablica zmienia koszt radzenia sobie z nim: bliskie duplikaty są oznaczane przy wysyłce, głosy mówią ci, czego naprawdę się chce, a zgłoszenie, którego nie zrobisz, zamykasz z powodem, który dociera do jego autora. Te zgłoszenia, które zostają, przychodzą z kontekstem, który obca osoba już dla ciebie napisała.