تطوير ذكاء اصطناعي مدفوع بالتغذية الراجعة: دع أصوات المستخدمين تُطلق السبرنت القادم

لكل فريق منتج نفس أسطورة النشأة: يقرّر المؤسّس أولاً ما الذي يُبنى، ثم يتوسّع الفريق، ثم يُعيَّن مدير منتج ليقرّر ما الذي يُبنى، ثم يتوسّع أكثر، إلى أن تدرك الشركة في لحظةٍ ما أن الإشارة الحقيقية تأتي من المستخدمين فتبدأ بالإنصات إليهم. التطوير المدفوع بالتغذية الراجعة هو الطريق المختصر. تجاوز مرحلة «نحن نقرّر» واذهب مباشرةً إلى «المستخدمون يقرّرون ونحن نُطلق».

التنفيذ القانوني هو الـ backlog المدفوع بالتصويت: يرى المستخدمون قائمة عامة بطلبات الميزات، يصوّتون لما يهمّهم، وتتحوّل قمّة القائمة إلى السبرنت التالي. أدوات مثل Canny وFider وFeaturebase وUserVoice وFrill وAha هي التي نشرت هذا النمط. لكن في كلّ واحدة منها، تبقى بعد عدّ الأصوات حلقة هندسية بشرية كلاسيكية: يُراجع مدير المنتج لوحة الصدارة، تُكتب تذكرة، يلتقطها مطوّر، ويبدأ سبرنت.

يطوي AgentsRoom هذه الحلقة. تهبط الأصوات مباشرةً على تذاكر يمكن لعملاء البرمجة الذكيين لديك تنفيذها. حين تتجاوز تذكرة عتبة التصويت عندك، تسحبها حرفياً إلى عمود In Progress، فيلتقطها عميل Claude أو Codex أو OpenCode أو Gemini CLI أو Aider باعتماد كلام العميل نفسه بروموبت. من طلب المستخدم إلى الميزة المُطلقة، الخطوة البشرية الوحيدة هي سحب وإفلات ومراجعة diff.

لهذا عدة نتائج مثيرة. أولاً، يصبح ترتيب الأولويات زهيد التكلفة. تتوقّف عن إحراق الساعات في الجدل؛ تنظر إلى عدّاد الأصوات، فإمّا أن تكون الإشارة موجودة أو لا. ثانياً، يصبح ترتيب الأولويات صادقاً. لا يسهل أن تكذب على نفسك حين تكون في أعلى اللوحة ميزة لا ترغب شخصياً ببنائها لكن يرغبها 42 مستخدماً. ثالثاً، يصبح ترتيب الأولويات سريعاً. تتقلّص المسافة بين «المستخدم يريد X» و«X أصبحت في الإنتاج» من أسابيع إلى ساعات.

التطوير بالذكاء الاصطناعي المدفوع بالتغذية الراجعة ليس حلّاً سحرياً. قد تكون الأصوات صاخبة، وأقليّات مرتفعة الصوت موجودة فعلاً، وديكتاتورية الـ upvotes الخالصة تقود إلى منتج يصبح هريسة شعبية من انتصارات صغيرة على حساب رؤية منتج متماسكة. لهذا يمنحك Remote Backlog في AgentsRoom الإشارة الخام «والتحكّم» معاً: أنت من يقرّر أيّ تذاكر تسحب، وأيّ دور للعميل تُسنده، وأيّ diff يُعتمد. الأصوات هي الإشارة، والعملاء هم القوة العاملة، وأنت المحرّر.