AWS Quick يحصل على ستة وكلاء لمديري المنتجات: من شكاوى العملاء إلى المواصفات

علّمت وكلاء البرمجة الفرق كتابة الشيفرة في أيام بدلاً من أسابيع. لكن للأمر أثراً جانبياً مزعجاً: إذا بنيتم بسرعة شيئاً غير مطلوب، فأنتم ببساطة تصلون إلى الفشل أسرع. تقترح AWS في مدونتها نقل الجهد إلى المراحل الأولى، حيث يختار الفريق المشكلة ويصوغ المهمة. ولهذا أطلقت الشركة AI-PDLC، وهي مجموعة من ستة وكلاء داخل AWS Quick.

ما المشكلة التي يحلّها هذا

إشارات ما يحتاجه العملاء موزعة على عشرات الأنظمة. فالآراء في Slack، ورؤى المبيعات في Salesforce، والحوادث في ServiceNow، والمتطلبات في SharePoint، والمهام في Jira، بينما تضيع القرارات في الرسائل والاجتماعات. ومع كل عملية تسليم يضيع جزء من السياق، فيصل إلى المطوّر تذكرة من سطر واحد دون شرح لسبب الحاجة إليها.

يعمل AWS Quick هنا كطبقة ربط. تجلب الموصّلات المؤسسية البيانات، ويبني النظام رسماً معرفياً للأشخاص والمشاريع والقرارات، ويعتمد الوكلاء على هذه البيانات ويضعون نتائجهم في Space مشترك. لا يبدأ الفريق كل مبادرة من الصفر.

كيف يعمل خط الإنتاج

يتواصل المستخدم مع المنسّق فقط. يقرأ المنسّق تعليمات المتخصصين أثناء العمل، ويطرح أسئلة حول المرحلة الحالية، ويمرّر المهمة إلى الوكيل المناسب. لا يمكن المتابعة إلا بعد أن يؤكد الإنسان النتيجة. تُسجَّل القرارات مرتين: يدوّنها المتخصص في ناتجه الخاص، ويحتفظ المنسّق بسجل عام ويتحقق من وجود القيود.

يتناول المقال أربع مراحل «منتجية» من أصل ثمانٍ. أما المراحل الأربع الأخرى (Engineer وShip وOperate وLearn) فتبقى لوكلاء البرمجة.

• Discover. يجمع الوكيل الشكاوى من Slack وJira وتذاكر الدعم وSalesforce، ويقيّم كل واحدة بحسب الخطورة والتكرار، ويُخرج Pain Point Board.
• Decide. يمنح الوكيل Prioritize درجات من 0 إلى 10. وفي الحالات القائمة على الوكلاء ينظر إلى مدى ملاءمتها لقدرات النماذج اللغوية الكبيرة، وتوافر الأدوات، وتقبّل المستخدمين. أما في التطبيقات العادية فينظر إلى قابلية التنفيذ، والتأثير على الأعمال، وحجم الجهد. بعد ذلك يكتب Working Backwards وثيقة PR/FAQ وفق منهج Amazon، مع أسئلة عن اقتصاديات الوحدة، وأنماط الفشل، والمخاطر التنظيمية، والمنافسين. وإذا لم تصمد الفكرة أمامها، تعرفون ذلك على الورق لا بعد عدة سبرينتات.
• Design. يحوّل Spec Generator كل ذلك إلى مواصفات تتضمن معايير القبول وسيناريو المستخدم والقيود. ويرتبط كل متطلب بالمشكلة الأصلية وتقييم الأولوية ووثيقة PR/FAQ.
• Prototype. يرسم الوكيل Designer خرائط الرحلة، والهياكل السلكية (wireframes)، ونماذج HTML أولية قابلة للنقر.

يُسمّى الملف النهائي prototype_spec.md. وتخدم معايير القبول فيه غرضين: فهي عقد لوكيل البرمجة، ومعيار تقييم لوكيل المراجعة. يتم التسليم عبر Agent Client Protocol (ACP)، وهو معيار مفتوح قائم على JSON-RPC 2.0. ويمكن أن يكون المنفّذ Kiro أو Claude Code أو أي وكيل آخر متوافق.

يُختار الإيقاع مسبقاً. يطرح Deep Discovery من 8 إلى 12 سؤالاً في كل مرحلة ويناسب المجالات غير المألوفة. أما Fast Track فيكتفي بـ3–5 أسئلة ويقترح إجابات افتراضية يمكن قبولها أو تغييرها.

كيف تبدأ وأين تطبّقه

ستحتاجون إلى مساحة عمل AWS Quick مع عميل سطح المكتب، وصلاحيات إنشاء وكلاء مخصصين مع موصّلات متصلة. ثم الخطوات:

• انسخوا (clone) مستودع AI-PDLC من GitHub وخذوا ملف JSON الخاص بالوكلاء؛
• في Quick Desktop انتقلوا إلى Customize → Agents → Create → Create from File؛
• أنشئوا Space مشتركاً للمخرجات وامنحوا الفريق صلاحية الوصول؛
• اختاروا المنسّق واكتبوا «Run the full pipeline» أو «Fast Track».

لا تكلّف الموارد شيئاً في وقت الخمول. تصف AWS ثلاثة سيناريوهات. المنتج الجديد يمر بالمسار كاملاً. الميزة الجديدة يمكنها تخطي البحث المعمّق. أما الخلل القادم من الإنتاج فيُختصر في دورة واحدة، يُسجَّل فيها السبب الجذري كمشكلة، وتتضمن المواصفات معايير قبول قابلة للتحقق.

القيود

هذا مقال من جهة بائعة. عبارة «تتحول الأسابيع إلى أيام أو ساعات» تقدير من AWS دون قياسات ودون تحليل لتطبيقات فعلية. والحل مرتبط بمنظومة Quick وموصّلاتها: خارج AWS سيتعين بناء الشيء نفسه يدوياً. كما تعتمد الجودة على بيانات الإدخال. فإذا كان Slack مليئاً بالضجيج، سيكون تقييم خطورة المشكلات مشوّشاً، وعلى الإنسان في الحلقة أن يراجع الاستنتاجات على أي حال.

ما الذي يمكن أخذه

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