يرى أيان غوبتا أن لوحات العمل، أو canvases، توفر طريقة أكثر عملية لإدارة سير العمل الذي تنفذه وكلاء الذكاء الاصطناعي داخل تطبيق GitHub Copilot. فبدلاً من ترك الخطة والتغييرات ونتائج التحقق وقرارات الموافقة مدفونة في سجل محادثة طويل، تضع اللوحة هذه العناصر على مساحة مشتركة ومستدامة يمكن للإنسان والوكيل تحديثها ومراجعتها أثناء التنفيذ.
ينطلق غوبتا من ملاحظة أساسية: المحادثة مناسبة لتحديد النية، خصوصاً عندما تكون المشكلة غير واضحة وتحتاج إلى التفكير والتنقيح والتوجيه السريع. لكنها تصبح أقل ملاءمة عندما يبدأ الوكيل في تنفيذ عمل فعلي يمتد عبر مراحل متعددة. عندها تتراكم التعليمات والسجلات والتصحيحات والتحولات في مسار واحد، ويصبح على الفريق إعادة بناء ما حدث من تاريخ المحادثة.
من سجل محادثة إلى حالة تشغيل واضحة
بحسب غوبتا، لا تكمن المشكلة في غياب المعلومات بالضرورة، بل في صعوبة الوصول إليها وفهم حالتها الحالية. فقد لا يكون واضحاً من المحادثة ما المرحلة التي وصل إليها العمل، وما القرارات التي اتُخذت، وما الذي تعطل، وما الذي جرى التحقق منه، وما الذي لا يزال يحتاج إلى حكم بشري.
تتعامل اللوحات مع هذه المشكلة عبر جعل حالة سير العمل صريحة ودائمة. يستطيع الإنسان فحص التقدم وتوجيهه أو إيقافه، بينما يواصل الوكيل تحديث الحالة والانتقال بين نقاط التنفيذ. وبهذا لا يبدأ كل تفاعل من الصفر، ولا يضطر الفريق إلى إعادة تمرير السياق نفسه في كل مرة.
تجربتان مختلفتان والنمط نفسه
كانت التجربة الأولى لغوبتا هي Java Modernization Studio، وهي لوحة مخصصة لسير عمل تحديث تطبيقات Java. يتضمن هذا النوع من العمل التقييم والتخطيط وتنفيذ مهام الترحيل وعمليات التحقق ثم الاستعداد للإطلاق، وهي مراحل تحتاج إلى إمكانية التدقيق والحوكمة.
في تجربة تعتمد على المحادثة فقط، قد تختلط هذه الخطوات ببعضها. أما اللوحة فتجعل كل مرحلة واضحة وقابلة للفحص، بحيث ترى الفرق ما تم إنجازه وتتحقق منه بدلاً من محاولة استنتاجه من السجل. كما تتيح للمراجعين التركيز على القرارات المهمة، بينما يستمر الوكلاء في تنفيذ العمل بين نقاط التحقق.
أما التجربة الثانية، Site Studio، فكانت موجهة إلى إنشاء محتوى المواقع الشخصية وإدارته. ورغم اختلافها عن تحديث Java، فإنها تتضمن تحديات تنسيق مشابهة: متابعة تقدم الأقسام، وتكرار التعديلات، ودورات المراجعة، وتغيرات الحالة. تحفظ اللوحة المسودات والقيم أثناء العمل، وتُظهر حالة كل قسم، وتحدد نقاط المراجعة البشرية بوضوح.
النمط القابل للتكرار
استخلص غوبتا من التجربتين مخططاً عملياً يمكن تطبيقه على سير العمل المتكرر:
- تحديد حالات سير العمل بوضوح.
- إظهار القرارات التي تستحق المتابعة.
- حفظ التقدم والمسودات فوراً أثناء التنفيذ.
- تحديد نقاط صريحة للموافقة البشرية.
يغيّر هذا الأسلوب طبيعة العلاقة مع الوكيل: بدلاً من التعامل مع كل مطالبة باعتبارها تفاعلاً منفصلاً، يصبح سير العمل نظاماً له ذاكرة وبنية ونقاط تحكم. وتبقى مسؤولية الإنسان حاضرة في التوجيه والمراجعة والموافقة، حتى عندما يتولى الوكيل جزءاً أكبر من التنفيذ.
ما الذي يتغير عملياً؟
الفائدة التي يركز عليها غوبتا ليست تحسين شكل الواجهة فقط. فالسطح المستدام يقلل الحاجة إلى إعادة المطالبات، ويحد من فقدان السياق ومن جولات الأخذ والرد غير الضرورية، كما قد يقلل إعادة العمل في المهام المتكررة. وبذلك يمكن أن يتحول الاستثمار في تصميم سير العمل إلى كفاءة أفضل وتقدم أكثر قابلية للتوقع، مع إبقاء القرارات المهمة قابلة للمراجعة.
لكن هذا الاستثمار له تكلفة أولية. يذكر غوبتا أن بناء لوحة Site Studio استهلك نحو 2,000 رصيد من أرصدة الذكاء الاصطناعي، بينما استهلكت لوحة التحديث نحو 3,000 رصيد. لذلك لا يقدم اللوحات باعتبارها وسيلة مجانية أو فورية، بل باعتبارها استثماراً في بنية سير العمل، خصوصاً عندما يتكرر النوع نفسه من العمل.
تتوفر اللوحتان اللتان بناهما غوبتا في مستودع awesome-copilot، ويمكن استخدامهما أو تكييفهما أو الاستفادة من تصميمهما. ويوصي من يستخدمون وكلاء Copilot باختيار سير عمل متكرر واحد، ثم بناء لوحة أولية له باستخدام الأمر /create-canvas، وتجربتها على عمل فعلي وتطويرها وفق الاستخدام. كما يمكن مشاركة اللوحة لاحقاً مع مجتمع awesome-copilot.