لا تزال معظم أعمال البرمجة تبدأ كجملة في محادثة جماعية. «تصدير CSV يُسقط الصف الأخير». «هل يمكننا إضافة SSO قبل العرض التجريبي؟». «بيئة الإنتاج تُعيد أخطاء 500 عند الدفع مرة أخرى». يردّ أحدهم بإيموجي إعجاب، وربما يُوجَّه وكيل برمجي إلى المشكلة، وبعد ثلاثة أيام لا يستطيع أحد أن يقول هل شُحن العمل، ولا من راجعه، ولا أي commit أصلحه. تتلاشى الرسالة مع التمرير، ويتحول العمل إلى حكاية شفهية.
هذه الفجوة مشكلة بنيوية، لا مشكلة انضباط. فرسالة المحادثة لا مالك لها، ولا حالة، ولا اختبار قبول، ولا رابط يصلها بالـ diff الذي يحلّها. وجّه وكيلاً برمجياً إلى تلك الرسالة وستكون قد أنشأت عملاً يستحيل تتبعه. ويسوء الأمر أكثر بمجرد تشغيل أكثر من وكيل واحد، لأنك حينها لن تعرف أيضاً أي وكيل لمس المهمة.
تستعرض هذه المقالة كيفية تحويل رسالة محادثة إلى مهمة برمجية قابلة للتتبع: ما الذي يمنحك إياه إعداد يدوي بسيط، وأين يتوقف عن التوسّع، وما الذي تضيفه طبقة المهام المشتركة. Sharkly هي مساحة العمل للنسخة القابلة للتتبع، لأنها تقف فوق وكلاء البرمجة لديك وتحتفظ بالهدف، والتشغيل، والعوائق، والـ diff، والمراجعة البشرية في سجل واحد. أنت تملك وكلاء البرمجة بالفعل. والمهمة هي تحويل عملهم إلى شيء يستطيع الفريق متابعته.
لماذا تكون المحادثات مقبرة مهام البرمجة
المحادثة الجماعية مُحسَّنة لسرعة الحوار، وهذا عكس ما تحتاجه مهمة برمجية. المهمة الحقيقية تحمل هدفًا معلنًا، ومالكًا، ومعايير قبول، وحالة يمكن الاستعلام عنها، ورابطًا يعود إلى التغيير الذي أغلقها. أما رسالة المحادثة فلا تحمل شيئًا من ذلك. كل ما تحمله هو طابع زمني وتفاعل.
نمط الفشل محدد. يصل الطلب، ويُوافق عليه ضمن النقاش بشكل غير رسمي، ويستمر النقاش في التحرك. بعد يومين يسأل أحدهم «هل أصلحنا خطأ التصدير في النهاية؟»، وتتطلب الإجابة البحث في Slack، والتخمين، والتمرير في قناة تظهر فيها العبارة نفسها تسع مرات. وحتى إن وجدت الرسالة، فهي لا تخبرك ما إذا كان الإصلاح قد دُمج. المحادثة والشيفرة تعيشان في نظامين منفصلين لم يعرف أحدهما اسم الآخر.
وجّه وكيلاً برمجياً مستقلاً إلى تلك الرسالة وسيقصر أثر التتبع. يقرأ الوكيل سطرًا في Slack، ويعمل في طرفية على حاسوب أحدهم، ويعدّل الملفات، ثم يعود ليرد في النقاش السريع نفسه الذي ابتلع الطلب. الآن لديك سجل تنفيذ لم يحفظه أحد، وتغيير لم يربطه أحد، وقرار لم يسجله أحد.
مسار العمل اليدوي، ومتى يتوقف عن التوسّع
لست بحاجة إلى منتج لتبدأ. مسار عمل يدوي قابل للتطبيق: انسخ رسالة المحادثة، وألصقها في وكيل البرمجة كموجّه، ودعه يعمل في Git worktree معزول حتى لا يتعارض مع نسختك الرئيسية، ثم افتح pull request يرتبط بمشكلة تتبّع مع سطر Closes #123. هذا تتبع حقيقي، وهو غالبًا كافٍ لمطوّر فردي يتعامل مع طلب واحد في كل مرة.
وإليك المقارنة الصادقة. إذا كنت شخصًا واحدًا، تشغّل وكيلاً واحدًا، وتغلق مهمة قبل الانتقال إلى التالية، فإن حلقة النسخ واللصق إلى worktree تعمل، ولا ينبغي أن تضيف أدوات إليها. فكلفة نظام مشترك ستتجاوز عائده.
يتوقف هذا الإعداد عن التوسّع في اللحظة التي يتحقق فيها أمران معًا: وكيلان يعملان، أو شخصان يوجّهان العمل، أو مستودعان في اللعب. عندها تبدأ ثقوب في المسار اليدوي:
| ما الذي ينكسر | لماذا لا تستطيع الحلقة اليدوية تغطيته |
|---|---|
| «أي وكيل لديه خطأ التصدير؟» | الإسناد كان في رأسك، لا في سجل |
| «هل انتهى هذا أم ما زال قيد التنفيذ؟» | الحالة كانت طرفية أغلقتها، لا حقلاً قابلاً للاستعلام |
| «من وافق على تغيير المصادقة؟» | الموافقة كانت إيموجي إعجاب، وقد تلاشت مع التمرير |
| «أين الـ diff الخاص بطلب Slack ذاك؟» | الـ PR يرتبط بمشكلة، لكن المشكلة لا ترتبط بالطلب أبدًا |
| «ما الذي غيّره الوكيل فعليًا؟» | سجل التشغيل كان في جلسة انتهت |
كل ثقب هو موضع تعود فيه المهمة إلى عدم القابلية للتتبع. يمكنك ترقيعها يدويًا بمزيد من المشكلات، واصطلاحات التسمية، والانضباط. وهذا ينجح إلى أن يتوقف، وحينها يفشل بهدوء، وهي أسوأ طريقة لفشل أي عملية.
ماذا يعني «قابل للتتبع» عندما تصبح المهمة مشتركة
القابلية للتتبع ليست انطباعًا. كل سؤال حول قطعة عمل له إجابة تعيش في مكان واحد وتصمد أمام رحيل الأشخاص الذين كانوا متصلين حين بدأت. المهمة القابلة للتتبع تُبقي السياق، والإسناد، والتقدم، والعوائق، والنتائج، والمراجعة البشرية ظاهرة من الطلب حتى الإصدار.
يمثّل Sharkly ذلك في صورة Task، وهي وحدة العمل الأساسية في النظام. الـ Task ليست رسالة محادثة ولا جلسة طرفية. إنها السجل المشترك الذي تصبح عليه رسالة المحادثة بمجرد أن تقرر التصرف بناءً عليها. يوضع الهدف في الوصف، ويصبح وكيل أو شخص هو الـ Assignee. تعود تنفيذات الوكيل وعوائقه ونتائجه والنقاش اللاحق جميعًا إلى الخط الزمني للمهمة بدل أن تختفي في طرفية خاصة. وعندما يصل التغيير، يُربط الـ pull request بالمعرّف، فيتعرف الطلب والـ diff أخيرًا على اسمَي بعضهما.
وهناك حدّ مهم ينبغي توضيحه، لأن القارئ قد يفترض شيئًا خاطئًا. Sharkly ليست بديلاً عن Claude Code أو Codex أو وكلاء البرمجة الآخرين لديك. تلك الأدوات تنفّذ العمل. أما Sharkly فتضيف طبقة المهمة المشتركة والسياق والمراجعة حولها. الوكيل لا يزال هو من يكتب الشيفرة، وSharkly تجعل العمل قابلاً للإسناد والتتبع.
تحويل رسالة محادثة إلى مهمة قابلة للتتبع باستخدام Sharkly
سير العمل قصير بما يكفي لتحفظه في رأسك. ابدأ برسالة حقيقية، ولتكن خطأ تصدير CSV، وانقلها خارج القناة:
- التقط الرسالة في صورة Task. أنشئ Task يكون الطلب فيها هو الهدف. إذا كانت محادثتك في Slack، فإن بوت Slack لوكلاء البرمجة يحوّل الإشارة إلى Task دون مغادرة النقاش.
- صُغها بحيث يستطيع وكيل تنفيذها. تقرير خطأ من سطر واحد ليس مواصفة قابلة للتنفيذ. أضف خطوات إعادة الإنتاج، والسلوك المتوقع، واختبار قبول. الأمر نفسه ينطبق على إدارة مهام وكلاء الذكاء الاصطناعي: المهمة التي يستطيع الوكيل إغلاقها تحتاج وصفًا يستطيع التصرف بناءً عليه.
- أسندها ودع الوكيل يعمل. يتولى الوكيل المهمة، ويعمل في worktree معزول حتى لا يتصادم العمل المتوازي، ويبثّ تقدمه إلى المهمة. أنت تراقب سجلاً، لا طرفية.
- راجع واقبل. يرفق الوكيل ملخص تغييره، ونتائج اختباراته، وحدوده المعروفة. ثم يقبل شخص أو يطلب تعديلات أو يتخذ قرار الدمج.
والخطوة الأخيرة هي العقد الذي يستحق أن يُقال بوضوح: الوكلاء يبحثون، وينفذون، ويختبرون، ويقدّمون التقارير. والبشر يحددون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. تتوقف الأتمتة عند حدّ حكم الفريق. المهمة القابلة للتتبع تجعل هذا التسليم ممكنًا، لأن الإنسان الذي يراجع التغيير يرى المسار الكامل من الطلب إلى الـ diff. وعندما ينتهي العمل، يمكنك تتبع ما أنجزه الوكيل دون إعادة تركيبه من الذاكرة. وهو العمود نفسه الذي يقوم عليه سير عمل ينتقل من المتطلبات إلى الشيفرة، لكن بدايةً من قصاصة محادثة لا من تذكرة رسمية.
يمكنك بناء نسخة من هذا يدويًا بالمشكلات والـ worktrees، أو استخدام Sharkly لإدارة سير العمل بحيث يصمد التتبع عندما يرتفع الحجم.
قائمة تحقق يمكنك تطبيقها اليوم
طبّقها على إعدادك الحالي. كل مربع غير محدَّد هو موضع يمكن أن تفلت فيه مهمة وُلدت في المحادثة من التتبع:
- [ ] كل طلب محادثة يُنفَّذ يتحول إلى Task لها مالك، وليس إيموجي تفاعل.
- [ ] لكل Task وصف يستطيع وكيل تنفيذه: خطوات إعادة الإنتاج، والسلوك المتوقع، واختبار القبول.
- [ ] كل وكيل يعمل في worktree معزول، بحيث لا تلمس مهمتان الملفات نفسها أبدًا.
- [ ] يعود سجل تشغيل الوكيل وعوائقه ونتائجه إلى الـ Task، لا إلى طرفية تُغلق.
- [ ] يرتبط الـ pull request بالـ Task عبر المعرّف، فيصبح الطلب والـ diff على بعد نقرة واحدة.
- [ ] يقبل إنسان النتيجة أو يرفضها، ويُسجَّل ذلك القرار على الـ Task.
- [ ] يمكنك الإجابة عن سؤال «هل انتهى هذا، ومن أنجزه، وأين الـ diff؟» دون البحث في المحادثة.
عند التعامل مع طلب واحد في كل مرة، تجتاز الحلقة اليدوية معظم هذه البنود من تلقاء نفسها. وعند تشغيل عدة وكلاء عبر فريق، تمنحك Sharkly مكانًا واحدًا لإدارة مهامهم ونتائجهم. نزّل Sharkly وانقل طلب محادثة حقيقيًا واحدًا إلى Task قبل أن تسلّم القناة بأكملها لها.
الأسئلة الشائعة
هل أحتاج إلى Sharkly لجعل المهام المولودة في المحادثة قابلة للتتبع؟ لا. المطوّر الفرد الذي يشغّل وكيلاً واحدًا يحصل على تتبع حقيقي من worktree زائد pull request يرتبط بمشكلة. أما نمط صندوق وارد وكيل الذكاء الاصطناعي فيستحق كلفته عندما يصبح لديك عدة وكلاء أو أشخاص وتبدأ الروابط اليدوية في الانزلاق.
ما الذي يجعل رسالة المحادثة صعبة التنفيذ على وكيل برمجي؟ أنها تفتقر عادةً إلى خطوات إعادة الإنتاج، والنتيجة المتوقعة، واختبار القبول. حوّل «التصدير معطوب» إلى «تصدير CSV يُسقط الصف الأخير؛ المتوقع N صفًا، والناتج N-1؛ يُصلح عندما يتطابق العدد». الآن صار لدى الوكيل شيء يمكنه الإغلاق مقابله.
كيف يختلف هذا عن نظام تذاكر عادي؟ التذكرة تتبع عملاً سينجزه إنسان. أما مهمة الشيفرة القابلة للتتبع فتحمل أيضًا سجل تنفيذ الوكيل، وتشغيله المعزول، والـ diff المرتبط، فيغطي السجل القرار والتغيير معًا. راجع وكلاء البرمجة بمشاركة بشرية لمعرفة أين يبقى الإنسان في الحلقة.
هل يمكن لـ Sharkly قراءة قناة Slack مباشرة؟ تربط وكيل Sharkly بـ Slack بحيث تتحول الإشارة إلى Task. تبقى المحادثة في Slack، ويبقى سجل العمل القابل للتتبع في Sharkly.
