Yapay zeka ajanları için geri bildirim panosu: promptu kullanıcıların yazsın

Bir kullanıcı gece 11'de sana yazıyor. "Safari'de dışa aktarma butonu hiçbir şey yapmıyor."

Sonrasında ne olacağını biliyorsun, çünkü bu yüz kez yaşandı. Okuyorsun. Anlıyorsun. Sonra bir issue tracker açıp aynı şeyi bir kez daha yazıyorsun: kendi cümlelerinle, dosya yollarıyla, tekrar üretme adımlarıyla ve kullanıcının sahip olmadığı bağlamla. Ardından bir terminal açıp üçüncü kez yazıyorsun, bu sefer prompt olarak.

Aynı talep üç kez yazıldı. İlki bedavaydı ve hatayı bizzat yaşayan kişiden geldi. Diğer ikisi senin.

İşin, ajanlar sayesinde saçma hale gelen kısmı işte o ikinci ve üçüncü yazım.

Hâlâ elle yazdığın son şey

Kodlama ajanları yazılacak çok şeyi ortadan kaldırdı. Brief'i kaldırmadı. Ajana ne yapacağını, tahmin yürütmesine gerek kalmayacak ayrıntıda birinin söylemesi gerekiyor ve o biri hâlâ klavye başında oturup başkalarının cümlelerini talimata çeviren bir insan.

Oysa bu çeviri çoğu zaman gereksiz. İyi bir hata bildirimi ajanın ihtiyaç duyduğu şeyi zaten içeriyor: ne bekleniyordu, ne oldu, hangi sayfada, hangi tarayıcıda. İyi bir özellik talebi niyeti ve gerekçeyi zaten taşıyor. Onu yazan kişi, soruna senden daha yakındı.

Buna rağmen o metni yeniden işlenecek bir hammadde gibi ele alıyoruz, çünkü onu toplayan araçla işi yürüten araç hiçbir zaman aynı araç olmadı. Geri bildirim bir üründe yaşıyor, ticket'lar bir başkasında, ajan ise ikisinden de habersiz bir terminalde çalışıyor.

Aradaki boşluğu kaldır, yeniden yazma adımının gerçekleşecek bir yeri kalmasın.

Pano işi yürütebildiğinde geri bildirim panosu neye dönüşür

Herkese açık backlog, kullanıcılarının erişebildiği bir sayfa. Hata bildiriyorlar, özellik istiyorlar, başkasının istediği şeye oy veriyorlar, bir konuyu takip ediyorlar ve durumun değişmesini izliyorlar. Buraya kadar anlatılan bir geri bildirim panosu ve piyasada iyileri de var.

Fark, ticket'ın nereye düştüğünde. Dışa aktarılmayı bekleyen bir geri bildirim ürününe düşmüyor. Ajanlarının zaten çalıştığı görev panosuna, kendi yazdığın ticket'ların yanına, tam yetkili bir ticket olarak düşüyor.

Oradan onu In Progress'e taşımak, brief'i o ticket olan bir ajan başlatıyor: başlık, bildiren kişinin kendi cümleleriyle açıklama, bulunduğu sayfa, kullandığı tarayıcı ve o günden beri onunla yaptığın yazışma. Kimse hiçbir şeyi yeniden yazmadı. Prompt, bildirimin kendisi.

İlginç sonuç hız değil. Sorunu tarif eden kişinin artık işi tanımlayan kişi olması. Herkesin kullanıcı geri bildiriminden beklediğini söylediği ama neredeyse kimsenin yapısını kurmadığı şey de bu. Bu tersine çevirmenin bir adı var: müşteri odaklı backlog. Kuyruk, neyin önemli olduğuna dair senin tahminin olmaktan çıkıp gerçekte ne istendiğinin kaydına dönüşüyor.

Üç kapı, çünkü insanlar bulundukları yerden bildirir

Bir geri bildirim panosu ancak bildirmek başka bir yerde şikayet etmekten daha ucuzsa işe yarar. Bu da insanlarla sorunun yaşandığı yerde buluşmak demek.

Herkese açık sayfa en bariz kapı: paylaştığın bir URL, liste ya da yol haritası görünümü, oylar ve bir form. Sayfayı yer imlerine ekleyecek kullanıcıları olan bir ürün için işe yarar ve aynı zamanda işin ilerlediğinin görünür kanıtı olur, ki bu kimsenin okumadığı bir durum e-postasından çok daha değerlidir.

İkincisi gömülebilir widget: kendi sitene koyduğun, formu olduğu yerde açan küçük bir script. Kişi hatanın olduğu sayfadan hiç ayrılmıyor, ki hatayı anlatmaya en istekli olduğu an tam olarak o an.

Üçüncüsü Chrome uzantısı ve davranışı en çok değiştiren de bu. Kullanıcın herhangi bir sayfada bozuk metni seçiyor, uzantıya tıklıyor ve ticket, URL ile seçim zaten ekli halde açılıyor. Eline geçen şey "çalışmıyor" değil, koordinatları olan bir bildirim.

Bir ajans içinse üçüncü kapı genelde müşterinin kendisi ve müşteri portalı modu yalnızca davetle çalışıyor: her müşteri için bir pano, başka kimse göremiyor, stack'e fazladan bir SaaS aboneliği eklenmiyor.

Yönlendirme, çünkü "doğru ajan" tek bir ajan değil

Gelen bir ticket kimseye adreslenmiş değildir. Her gelen kutusunun pratikteki sorunu budur: birinin onu kimin alacağına karar vermesi gerekir.

Dışarıdan gelen ticket'lar uzmanlığı uyan ajana yönlendirilir; bozuk bir yerleşim frontend uzmanına, sızdıran bir sorgu backend tarafına gider ve sen her sabah kuyruğu elle ayıklamak zorunda kalmazsın. Hiçbir şey ayarlanmamışsa geri düşüş bilinçli olarak aptal ve öngörülebilirdir: projedeki ilk geliştirme ajanı, listenin tepesinde denk gelen bir pazarlama ya da PM rolü asla değil.

Bir ticket'ı tek bir ajan yerine bütün bir ajan ekibine de yönlendirebilirsin; böylece bir müşteri talebi sana ulaşmadan önce bir geliştirme adımından, ardından bir QA adımından geçer.

Herkesin unuttuğu kısım: bildiren kişi geri ne görüyor

Geri bildirim toplamak kolay. Ürünlerin insanları kaybettiği yer döngüyü kapatmak.

Bir ticket geliştirmeye alındığında yazarına haber gidiyor. Önceliklendirildiğinde haber gidiyor. Yapmayacağına karar verdiğinde de haber gidiyor, üstelik yazdığın gerekçeyle birlikte, ki bu sessizlikten çok daha iyi. Düzeltme gerçekten yayına çıktığında ise bunu söyleyen bir mesaj alıyor; beş ticket için beş ayrı e-posta yerine sürüm başına tek bildirimde toplanmış olarak.

Göründüğünden daha önemli, küçük bir ayrıntı var: bir kullanıcı ticket'ını kapatan commit, bildiren kişiyi adıyla anıyor ve bu teşekkür herkese açık changelog'a kadar taşınıyor. Yayına çıkmış bir değişikliğin yanında kendi adını gören insanlar bir sonraki hatayı da bildiriyor. Elde tutma mekanizmasının tamamı bu ve hiçbir maliyeti yok. Bu döngüyü birkaç ay çalıştır, geri bildirim odaklı geliştirme bir slogan olmaktan çıkıp gözlemlenebilir bir olguya dönüşsün: sırayı oylar belirliyor, sürümleri de sıra belirliyor.

Talep muğlak geldiyse, bildirimle iş arasında ticket kapsam belirleme duruyor: bir Product Manager ajanı, bulanık talebi değişikliğin uygulandığı ve gerçek ürününe sadık bir makete çeviriyor, böylece tek satır kod yazılmadan fikri aynı ticket üzerinde doğruluyorsun.

Klasik araçların durduğu yer

Bu, yerleşik araçlara atılmış bir taş değil. Canny, Featurebase, Fider ve UserVoice toplamayı, yinelenenleri ayıklamayı ve sıralamayı iyi yapıyor; ürün ekipleri için önemli olan kısımlarda yılların cilası var. Hepsi aynı yerde ve aynı yapısal nedenle duruyor: mühendisliğin ayrı bir departman olduğu ve ona ancak bir dışa aktarımla ulaşılabildiği organizasyonlar için tasarlandılar.

Kararı veren satır sonuncusu. Büyük bir ekipte bir talebi spesifikasyona çevirmek gerçek bir iştir, gerçek bir değer üretir ve dışa aktarım orada darboğaz değildir. Kodlama ajanlarıyla iş çıkaran bir ila beş kişilik bir ekipteyse o yeniden yazma darboğazın ta kendisidir ve saf kayıptır.

Bunun çözmediği şeyler

Ajanlara bağlı bir geri bildirim panosu otopilot değildir ve onu otopilot sanmak tam da beklediğin sonucu üretir.

Kötü ticket'lar hâlâ kötü iş üretir. Tekrar üretme yolu olmayan tek satırlık bir bildirim ajana çalışacak hiçbir şey vermez, ajan da özgüvenle yanlış bir şey yapar. Pano yalnızca yazılanı iletebilir.

Hiçbir şey kendi kendine birleşmez. Ajan bir dal ve bir diff üretir; ajan çıktısını incelemeye dair sahip olduğun her kural, özellikle kimlik doğrulamaya, ödemelere ya da veriye dokunan her şey için geçerliliğini korur. Bir yabancıdan gelen ticket, bu çıtayı düşürmek için değil, yükseltmek için bir gerekçedir.

Hacim de gerçek bir mesele. Tutan bir herkese açık pano gürültülü hale gelir; bu iyi bir sorundur ama gerçek bir maliyeti vardır. Yinelenen kayıtlar gönderildikleri anda işaretlenir, oylar bir kişinin istediğiyle kırk kişinin istediğini birbirinden ayırır ve bir ticket'ı yazılı bir gerekçeyle kapatmak onu çürümeye bırakmaktan hızlıdır. Ama gelen kutusunu yine de birinin okuması gerekir.

Kurulum

Bir projenin backlog'unu aç, Herkese açık backlog'a tıkla, bir URL ve bir görünürlük modu seç. Kurulumun tamamı bu ve sayfa o anda yayında.

Sonrasında ne yaptığın kurulumdan daha önemli. Bağlantıyı kullanıcılarının zaten bulunduğu yerlere koy: uygulamanın içine, destek yanıtlarına, sürüm notlarının altına. Kimsenin haberi olmadığı bir geri bildirim panosu hiçbir şey toplamaz ve bu özelliğin bozulma biçimi teknik değildir: bağlantı hiçbir zaman paylaşılmaz.

AgentsRoom, bunun üzerinde çalıştığı komuta merkezidir: bir kartın çalışan bir ajana dönüştüğü görev panosu, ona bağlı herkese açık ya da özel bir geri bildirim sayfası, gömülebilir bir widget, bir Chrome uzantısı ve iş gerçekten yayına çıktığında tetiklenen müşteri bildirimleri. Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe ve Kimi Code ile çalışır.

AgentsRoom'u indir ve ilk panonu yayına al.

Sıkça sorulan sorular

Yapay zeka ajanları için geri bildirim panosu nedir?

Kullanıcıların hata bildirdiği ve özellik istediği, kodlama ajanlarının çalıştığı görev panosuna bağlı herkese açık bir sayfa. Klasik bir geri bildirim aracından farkı son adımda: talebi bir issue tracker'a aktarıp prompt olarak yeniden yazmak yerine, ticket'ın kendisi ajanın brief'i oluyor, üstelik bildiren kişinin kendi cümleleriyle.

Bir kullanıcı ticket'ı gerçekten kendi başına bir yapay zeka ajanı başlatabilir mi?

Başlatmak bilinçli bir hareket olarak kalıyor: birisi ticket'ı In Progress'e taşıyor ve ajan, promptu o ticket olacak şekilde açılıyor. Otomatik olan kısım yönlendirme: gelen ticket, uzmanlığı ona uyan ajana düşüyor. Bir yabancının yazdığı her şeyin otomatik olarak çalıştırılması bir özellik değil, güvenlik açığıdır.

Bunun Canny, Featurebase, Fider veya UserVoice'tan farkı ne?

Bu araçlar talep toplamada, yinelenenleri ayıklamada ve sıralamada çok iyi, ama hepsi aynı yerde duruyor: sana öncelik sırasına dizilmiş bir liste veriyorlar ve her satırı işe çeviren yine bir insan oluyor. Yürütme katmanları yok, çünkü mühendisleri başka yerde olan ürün ekipleri için tasarlandılar. Buradaki iddia tam tersi: toplama yüzeyi ile yürütme yüzeyi aynı nesne.

Bunu kullanmak için yol haritanı herkese açmak zorunda mısın?

Hayır. Herkese açık, listelenmemiş ve yalnızca davetle olmak üzere üç ayrı mod var. Her müşterisi için ayrı bir pano işleten bir ajans yalnızca davetle modunu kullanır ve panoyu hiçbir arama motoru görmez. Kullanıcılarından talep ve oy toplamak isteyen tek kişilik bir geliştirici herkese açık modu seçer. Yürütme tarafı üçünde de aynı şekilde çalışır.

Herkese açık bir panonun gürültüyle dolmasını ne engelliyor?

Gürültünün gelmesini hiçbir şey engellemiyor, aksini iddia etmek dürüst olmaz. Panonun değiştirdiği şey, gürültüyle başa çıkmanın maliyeti: birbirine çok benzeyen kayıtlar gönderim anında işaretleniyor, oylar neyin gerçekten istendiğini söylüyor ve yapmayacağın bir ticket, yazarına ulaşan bir gerekçeyle kapanıyor. Elinde tuttuğun ticket'lar ise bir yabancının senin yerine yazdığı bağlamla geliyor.