Papan feedback untuk agen AI: biarkan penggunamu yang menulis prompt-nya

Seorang pengguna menulis kepadamu pukul sebelas malam. "Tombol ekspor tidak melakukan apa-apa di Safari."

Kamu tahu apa yang terjadi berikutnya, karena sudah terjadi seratus kali. Kamu membacanya. Kamu memahaminya. Lalu kamu membuka tracker dan mengetiknya lagi, dengan kata-katamu sendiri, lengkap dengan path berkas, langkah reproduksi, dan konteks yang tidak dimiliki pengguna itu. Lalu, belakangan, kamu membuka terminal dan mengetiknya untuk ketiga kali, sebagai prompt.

Tiga kali menulis permintaan yang sama. Yang pertama gratis dan datang dari orang yang benar-benar kena bug-nya. Dua sisanya tanggunganmu.

Penulisan kedua dan ketiga itulah bagian pekerjaan yang jadi absurd sejak ada agen.

Hal terakhir yang masih kamu ketik sendiri

Agen coding menghapus banyak sekali pengetikan. Ia tidak menghapus briefing-nya. Tetap harus ada yang memberitahu agen apa yang mesti dibangun, cukup detail supaya ia tidak menebak-nebak, dan yang memberitahu itu masih manusia yang duduk di depan keyboard, mengubah kata-kata orang lain jadi instruksi.

Padahal konversi itu sering sia-sia. Laporan bug yang bagus sudah memuat apa yang dibutuhkan agen: apa yang diharapkan, apa yang terjadi, di halaman mana, di browser mana. Permintaan fitur yang bagus sudah memuat maksud dan alasannya. Orang yang menulisnya berdiri lebih dekat ke masalahnya ketimbang kamu.

Yang kita lakukan malah memperlakukan teks itu sebagai bahan mentah yang harus diolah ulang, karena alat yang mengumpulkannya dan alat yang mengeksekusi pekerjaan tidak pernah jadi satu alat. Feedback tinggal di satu produk, tiket di produk kedua, dan agennya jalan di terminal yang tidak tahu-menahu soal keduanya.

Hapus jarak itu, dan langkah menulis ulang tidak punya tempat untuk terjadi lagi.

Jadi apa sebuah papan feedback kalau papannya bisa mengeksekusi

Backlog publik adalah halaman yang bisa dijangkau penggunamu. Mereka melaporkan bug, meminta fitur, mendukung permintaan orang lain, mengikuti sebuah utasan, dan melihat statusnya berubah. Sejauh ini ini papan feedback biasa, dan yang bagus sudah banyak.

Bedanya ada di tempat tiketnya mendarat. Ia tidak mendarat di produk feedback sambil menunggu diekspor. Ia mendarat di papan tugas tempat agen-agenmu sudah bekerja, sebagai tiket kelas satu, bersebelahan dengan tiket yang kamu tulis sendiri.

Dari situ, memindahkannya ke In Progress memunculkan agen yang briefing-nya adalah tiket itu sendiri: judulnya, deskripsi dengan kata-kata si pelapor, halaman yang sedang ia buka, browser yang ia pakai, dan percakapan kalian sesudahnya. Tak ada yang menulis ulang apa pun. Prompt-nya adalah laporannya.

Konsekuensi menariknya bukan kecepatan. Melainkan bahwa orang yang menggambarkan masalahnya kini jadi orang yang menentukan spesifikasi pekerjaannya, dan itulah yang semua orang klaim ingin didapat dari feedback pengguna sementara nyaris tak ada yang menyiapkan strukturnya. Pembalikan itu punya nama: backlog yang digerakkan klien. Antreannya berhenti jadi tebakanmu soal apa yang penting dan berubah jadi catatan tentang apa yang benar-benar diminta.

Tiga pintu, karena orang melapor dari tempat mereka berada

Papan feedback cuma jalan kalau melapor lebih murah ketimbang mengeluh di tempat lain. Artinya menemui orang di tempat masalahnya terjadi.

Halaman publik adalah pintu yang paling jelas: satu URL yang kamu bagikan, dengan tampilan daftar atau roadmap, upvote, dan sebuah formulir. Ia cocok untuk produk yang penggunanya mau menyimpannya di bookmark, dan sekaligus jadi bukti kasatmata bahwa pekerjaannya bergerak, yang nilainya lebih besar ketimbang email status yang tak dibaca siapa-siapa.

Widget yang bisa ditanam adalah pintu kedua: skrip kecil di situsmu sendiri yang membuka formulir di tempat. Orangnya tidak perlu meninggalkan halaman tempat bug-nya berada, dan justru saat itulah ia paling mau menjelaskannya.

Ekstensi Chrome adalah pintu ketiga, dan inilah yang paling mengubah kebiasaan. Penggunamu memilih teks yang bermasalah di halaman mana pun, mengklik ekstensinya, dan tiketnya terkirim dengan URL serta bagian yang dipilih sudah menempel. Yang kamu terima bukan lagi "tidak jalan", melainkan laporan yang punya koordinat.

Untuk agensi, pintu ketiga biasanya kliennya sendiri, dan mode portal klien bersifat khusus undangan: satu papan per klien, tak ada orang lain yang bisa melihatnya, tanpa tambahan langganan SaaS di tumpukanmu.

Pengarahan, karena "agen yang tepat" bukan satu agen

Tiket yang masuk tidak dialamatkan ke siapa-siapa. Itulah masalah praktis tiap kotak masuk: harus ada yang memutuskan siapa yang mengambilnya.

Tiket yang datang dari luar diarahkan ke agen dengan keahlian yang cocok, jadi tata letak yang rusak jatuh ke spesialis frontend dan query yang bocor jatuh ke spesialis backend, tanpa kamu memilah antrean satu per satu tiap pagi. Kalau tidak ada yang dikonfigurasi, cadangannya sengaja dibuat bodoh dan bisa ditebak: agen development pertama di proyek itu, bukan peran marketing atau PM yang kebetulan nangkring di puncak daftar.

Kamu juga bisa mengarahkan tiket ke satu tim agen utuh alih-alih ke satu agen, supaya permintaan klien melewati tahap dev lalu tahap QA sebelum sampai kepadamu.

Bagian yang selalu dilupakan: apa yang dilihat si pelapor sesudahnya

Mengumpulkan feedback itu gampang. Menutup lingkarannya, di situlah produk kehilangan orang.

Saat sebuah tiket masuk ke tahap pengembangan, penulisnya diberitahu. Saat tiketnya diprioritaskan, ia diberitahu. Saat kamu memutuskan tidak akan mengerjakannya, ia diberitahu, lengkap dengan alasan yang kamu tulis, dan itu jauh lebih baik ketimbang kesunyian. Lalu saat perbaikannya benar-benar dirilis, ia menerima pesan yang mengabarkannya, dikelompokkan jadi satu notifikasi per rilis alih-alih lima email terpisah untuk lima tiket.

Ada detail kecil yang bobotnya lebih besar dari kelihatannya: commit yang menutup tiket pengguna mencantumkan nama depan si pelapor, dan kredit itu ikut masuk ke changelog publik. Orang yang melihat namanya menempel pada perubahan yang sudah rilis akan melaporkan bug berikutnya juga. Itu saja seluruh mekanisme retensinya, dan ongkosnya nol. Jalankan lingkaran itu beberapa bulan dan kamu mendapat pengembangan yang digerakkan feedback sebagai fakta yang bisa diamati, bukan sekadar slogan: upvote menentukan urutannya, dan urutan menentukan rilisnya.

Kalau permintaannya datang samar, penentuan cakupan tiket berdiri di antara laporan dan pekerjaannya: agen Product Manager mengubah permintaan kabur itu jadi mockup produkmu yang sesungguhnya dengan perubahannya sudah diterapkan, jadi kamu memvalidasi idenya di tiket yang sama sebelum satu baris kode ditulis.

Di mana alat-alat klasik berhenti

Ini bukan serangan ke pemain lama. Canny, Featurebase, Fider, dan UserVoice mengerjakan pengumpulan, penyaringan duplikat, dan pengurutan dengan baik, dan mereka punya pengalaman bertahun-tahun memoles bagian yang penting bagi tim produk. Mereka berhenti di titik yang sama karena alasan struktural yang sama: mereka dibangun untuk organisasi tempat engineering adalah departemen lain, yang cuma bisa dijangkau lewat ekspor.

Baris terakhir itulah yang menentukan. Di tim besar, mengubah permintaan jadi spesifikasi adalah pekerjaan sungguhan dengan nilai sungguhan, dan ekspornya bukan hambatan. Di tim satu sampai lima orang yang merilis dengan agen coding, penulisan ulang itulah hambatannya, dan itu kerugian murni.

Yang tidak diselesaikan oleh ini

Papan feedback yang tersambung ke agen bukan autopilot, dan memperlakukannya sebagai autopilot menghasilkan persis apa yang kamu bayangkan.

Tiket buruk tetap menghasilkan pekerjaan buruk. Laporan satu baris tanpa jalur reproduksi tidak memberi agen apa pun untuk dipegang, dan ia akan mengerjakan sesuatu yang salah dengan penuh percaya diri. Papan ini cuma bisa meneruskan apa yang ditulis.

Tidak ada yang ter-merge sendiri. Agen menghasilkan branch dan diff, dan semua aturanmu soal meninjau hasil kerja agen tetap berlaku, apalagi untuk apa pun yang menyentuh autentikasi, pembayaran, atau data. Tiket dari orang asing bukan alasan menurunkan standar itu. Justru alasan untuk menaikkannya.

Dan volumenya nyata. Papan publik yang berhasil pasti jadi ramai, dan itu masalah bagus yang tetap ada ongkosnya. Duplikat ditandai saat dikirim, upvote memisahkan apa yang diinginkan satu orang dari apa yang diinginkan empat puluh orang, dan menutup tiket dengan alasan tertulis lebih cepat ketimbang membiarkannya membusuk. Tapi tetap ada yang harus membaca kotak masuknya.

Cara menyiapkannya

Buka backlog sebuah proyek, klik Public backlog, pilih URL dan mode visibilitasnya. Itu saja seluruh setup-nya, dan halamannya sudah hidup sejak saat itu.

Apa yang kamu lakukan sesudahnya lebih penting ketimbang setup-nya. Taruh tautannya di tempat penggunamu sudah berada: di dalam aplikasi, di balasan supportmu, di bagian bawah catatan rilis. Papan feedback yang tidak diketahui siapa pun tidak mengumpulkan apa-apa, dan mode gagal fitur ini bukan soal teknis, melainkan tautannya tak pernah dibagikan.

AgentsRoom adalah pusat komando tempat semua ini berjalan: papan tugas yang mengubah kartu jadi agen yang berjalan, halaman feedback publik atau privat yang tersambung ke papan itu, widget yang bisa ditanam, ekstensi Chrome, dan notifikasi klien yang menyala saat pekerjaannya benar-benar dirilis. Ia bekerja dengan Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, dan Kimi Code.

Unduh AgentsRoom dan terbitkan papan pertamamu.

Pertanyaan yang sering diajukan

Apa itu papan feedback untuk agen AI?

Sebuah halaman publik tempat pengguna melaporkan bug dan meminta fitur, tersambung ke papan tugas yang sama tempat agen codingmu bekerja. Bedanya dengan alat feedback klasik ada di langkah terakhir: alih-alih mengekspor permintaannya ke tracker lalu menulis ulang jadi prompt, tiketnya sendiri yang jadi briefing agen, dengan kata-kata si pelapor.

Benarkah tiket dari pengguna bisa langsung memulai agen AI?

Memulai tetap tindakan sadar: seseorang memindahkan tiketnya ke In Progress, lalu agennya muncul dengan tiket itu sebagai prompt. Yang otomatis adalah pengarahannya, yang mengirim tiket masuk ke agen dengan keahlian yang cocok. Mengeksekusi otomatis apa pun yang ditulis orang asing bukan fitur, itu lubang keamanan.

Apa bedanya dengan Canny, Featurebase, Fider, atau UserVoice?

Semuanya hebat dalam mengumpulkan, menyaring duplikat, dan mengurutkan permintaan, dan semuanya berhenti di titik yang sama: mereka menyerahkan daftar berprioritas, lalu manusia tetap harus mengubah tiap barisnya jadi pekerjaan. Mereka tidak punya lapisan eksekusi karena dibangun untuk tim produk yang insinyurnya ada di tempat lain. Taruhan di sini justru sebaliknya: permukaan pengumpulan dan permukaan eksekusi adalah objek yang sama.

Haruskah roadmap-mu dibuat publik untuk memakainya?

Tidak. Publik, tak terdaftar, dan khusus undangan adalah tiga mode terpisah. Agensi yang menjalankan satu papan per klien memakai mode khusus undangan, dan tak ada mesin pencari yang pernah melihatnya. Developer solo yang ingin menerima permintaan dan upvote dari pengguna memakai mode publik. Bagian eksekusinya bekerja sama persis di ketiganya.

Apa yang mencegah papan publik penuh sampah?

Tidak ada yang mencegah sampah itu datang, dan berpura-pura sebaliknya cuma tidak jujur. Yang diubah papan ini adalah ongkos menanganinya: tiket yang nyaris kembar ditandai saat dikirim, upvote memberitahumu apa yang benar-benar diinginkan, dan tiket yang tidak akan kamu kerjakan ditutup dengan alasan yang sampai ke penulisnya. Tiket yang kamu simpan datang lengkap dengan konteks yang sudah ditulis orang asing untukmu.