تبدأ بطرفية واحدة وClaude Code. ثم تصل مهمة ثانية، فتفتح طرفية أخرى وتشغّل عليها Codex. ثم يأتي إصلاح في الواجهة الأمامية ليذهب إلى طرفية ثالثة. والآن أنت تتنقل بزر Alt+Tab بين ثلاث نوافذ، محاولًا تذكّر أيّها ينتظرك، وأيّها طرح سؤالًا قبل عشر دقائق، وأيّها انتهى بهدوء وجلس بلا عمل بينما تحرق انتباهك على النافذتين الأخريين. لا شيء يحترق. لكنك أنت من صار يوزّع العمل بين الوكلاء، وهذه المهمة تزداد سوءًا مع التوسّع أكثر من أيٍّ منهم.
الطرفيات ليست هي التكلفة. أنت هي. فعندما تعمل الوكلاء يدويًا، يبقى كل قرار حول ما سيحدث بعد ذلك في مكان واحد: رأسك. أي وكيل سيأخذ المهمة التالية، وهل آخر diff آمن، وما الذي فشل بينما كنت تقرأ نافذة أخرى. هذا التنسيق عمل حقيقي، وغير مدفوع، وينمو أسرع من عدد الوكلاء الذين تضيفهم.
توضّح هذه المقالة التكلفة الحقيقية لتشغيل وكلاء البرمجة يدويًا، وأين تختفي الفاتورة حتى تتراكم، وسير العمل الذي يزيل معظمها. Sharkly هي طبقة الإدارة التي تقف فوق وكلائك: تحتفظ بـ Claude Code أو Codex أو أي بيئة تشغيل تستخدمها بالفعل، بينما تحمل Sharkly المهام والعزل والمراجعة في مكان مشترك واحد بدلًا من جدار من الطرفيات.
الخلاصة السريعة
يبدو تشغيل وكلاء البرمجة يدويًا مجانيًا لأن لا أداة تتقاضى مقابلًا عليه. لكن التكلفة الحقيقية هي انتباهك: أنت تصبح الموجّه بين الوكلاء، والذاكرة التي تعرف ما يفعله كل واحد منهم، والمراجع الوحيد الذي عليه أن يلحق بكل نافذة. تبقى هذه التكلفة صغيرة مع وكيلين أو ثلاثة، ثم تتراكم بعد الخمسة. يمكنك الاستمرار في فعل ذلك يدويًا، أو تمرير وكلائك الحاليين عبر طبقة مهام مثل Sharkly توزّع العمل، وتعزل كل تشغيل، وتعيد كل نتيجة إلى مهمة (Task) للمراجعة.
المشكلة ليست في الطرفيات، بل فيك
إليك تعريفًا يستحق التذكّر: الطرفية هي المكان الذي يعمل فيه الوكيل؛ والمهمة هي العمل الذي يعمل عليه. وعندما تدير الوكلاء يدويًا، لا شيء يربط بين الاثنين سواك. تعرض الطرفية المخرجات، لكنها لا تعرف ما كانت المهمة، ولا هل انتهت، ولا من يقرر ما سيحدث بعد ذلك. أنت من يوفّر كل ذلك من ذاكرته، نافذة تلو الأخرى.
ولهذا فإن «الطرفيات أكثر من اللازم» عرضٌ للمشكلة، لا المرض نفسه. تقسيم وكيل واحد على خمسة أجزاء (panes) باستخدام tmux لا يقلّل التنسيق، بل يعيد ترتيبه فقط. فما زلت تحمل في رأسك خريطة تحدّد أي جزء مسؤول عن أي مهمة، وأيّها قيد التشغيل، وأيّها انتهى ويحتاج إلى نظرة بشرية. ولا تعيش هذه الخريطة في أي مكان مشترك، لذا بمجرد أن تبتعد عنها تتقادم، وبمجرد أن يحتاجها أحد زملائك لا تكون موجودة.
ما الذي يكلّفه تشغيل الوكلاء يدويًا فعلًا
الفاتورة تُدفع بالانتباه، وللانتباه سعر قابل للقياس. فعندما تنتقل بين مهام غير مترابطة، لا تستأنف فورًا. وقد وجدت أبحاث أجرتها غلوريا مارك وزملاؤها حول العمل المعرفي المتقطّع، والمنشورة في CHI 2008، أن الناس يستغرقون في المتوسط أكثر من عشرين دقيقة للعودة إلى مهمة متقطّعة بعد أن يُسحبوا بعيدًا عنها. ويقدّر ملخّص الجمعية الأمريكية لعلم النفس لأبحاث التبديل بين المهام خسارة الإنتاجية الناتجة عن التنقل بين المهام بما يصل إلى 40 بالمئة. وفي كل مرة ينتهي فيها وكيل وتستدير إلى نافذة مختلفة، تدفع شكلًا من أشكال هذه الضريبة.
تشغيل الوكلاء يدويًا يحوّل هذا التبديل إلى حلقتك الرئيسية. وهنا تتراكم التكلفة:
| التكلفة الخفية | كيف تبدو عند العمل اليدوي | لماذا تتراكم |
|---|---|---|
| التوجيه | تقرّر من ذاكرتك أي وكيل سيأخذ كل مهمة جديدة | كل وكيل إضافي يعني مزيدًا من الاقترانات التي تحملها في رأسك |
| إعادة تحميل السياق | تعيد قراءة كل طرفية لتتذكر ما كانت تفعله | كل تبديل يعيد عقارب الساعة إلى الصفر في الدخول مجددًا إلى تلك المهمة |
| انحراف الحالة | كل طرفية تحمل فرعها وبيئتها وتعديلاتها نصف المكتملة | مهمتان في مجلد واحد تفسدان إحداهما الأخرى بصمت |
| تراكم المراجعات | أنت الوحيد الذي رأى كل تشغيل يحدث | العمل المنتهي ينتظر الشخص الوحيد القادر على مراجعته |
| لا سجل مشترك | الحالة تعيش في جلستك، لا في مكان يستطيع زميل رؤيته | ابتعد قليلًا يصبح التقدم غير مرئي؛ ولا أحد يستطيع متابعته |
لا شيء من هذا يظهر على شكل انهيار. إنه يظهر في صورة يوم بدا مزدحمًا وأنتج ثلاثة طلبات سحب مدموجة بدل ثمانية، دون لحظة واحدة تستطيع الإشارة إليها كسبب للمشكلة.
أنماط الفشل تختفي حتى تتراكم
مع وكيلين، تستطيع الاحتفاظ بالخريطة كاملة في ذاكرتك العاملة وتكون التكلفة قريبة من الصفر. ويستحق هذا أن يُقال بوضوح، لأنه الموضع الذي تبالغ فيه معظم النصائح في تضخيم المشكلة: إذا كنت تشغّل وكيلًا أو وكيلين على جهاز واحد وتراجع كل واحد قبل بدء التالي، فلست بحاجة إلى طبقة إدارة بعد. أبقِ الأجزاء المتحركة عند الصفر.
تتغيّر المعادلة عندما يتداخل العمل في الزمن أو في الحالة. شغّل ثلاثة وكلاء في نسخة العمل نفسها (checkout) وستصطدم بمشكلة العزل التي تناولناها في عدة وكلاء برمجة في المستودع نفسه: وكيلان يلمسان الملفات ذاتها، فيطمس أحدهما عمل الآخر بصمت. عالج ذلك بـ worktree لكل مهمة، وهو الانضباط الذي شرحناه في worktrees وكلاء البرمجة، فتستبدل مشكلة دمج بمشكلة محاسبة: أي مجلد يقابل أي مهمة، وأيّها آمن للحذف، وأيّها يراجعه إنسان الآن. ثم حُلّ ذلك بمزيد من الطرفيات فتعود إلى نقطة البداية، لكن بمزيد من النوافذ.
التكلفة الأخيرة هي الهادئة. فعندما يحدث كل تشغيل في طرفية خاصة، لا يجد العمل المنتهي مكانًا يذهب إليه سوى انتباهك. وهكذا تصبح المراجعة عنق الزجاجة، لأنك الشخص الوحيد الذي شاهد الوكيل يعمل والوحيد القادر على الحكم إن كان الـ diff جيدًا. ولا تفيد الوكلاء المتوازية إذا كانت مراجعة مخرجاتها تتسلسل عند إنسان واحد. هذا هو الفخ الموصوف في لماذا يهم أفضل وكيل برمجة أقل من طريقة إدارتك له: أصبح النموذج أسرع، لكن طابور مراجعاتك لم يصبح كذلك.
ما الذي تزيله طبقة الإدارة
لوحة المهام تزيل الجزء الذي كنت تؤديه يدويًا: أن تكون النسيج الرابط بين الوكلاء والعمل. في Sharkly، المهمة (Task) هي الوحدة التي تملك التشغيل. تُسند مهمة إلى وكيل، فتُهيّئ Sharkly له worktree معزولًا على حاسوب متصل، وتشغّل جلسة الوكيل هناك، ثم تعيد الـ diff والسجلات وأي عوائق إلى تلك المهمة. وهكذا يصبح التوجيه والعزل والسجل الذي كنت تحمله في رأسك من خصائص المهمة نفسها بدلًا من ذلك.
وهذا يحافظ على تقسيم عمل واضح. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير؛ والبشر يحدّدون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. Sharkly ليست بديلًا عن Claude Code أو Codex أو بيئة التشغيل التي تستخدمها بالفعل؛ فتلك هي التي تنفّذ. بل تضيف حولها المهمة المشتركة والحاسوب المتصل وطبقة المراجعة، بحيث يبقى السياق والتقدم والعوائق والنتائج والمراجعة البشرية مرئية من الطلب حتى الإصدار، بدلًا من أن تتناثر على خمس جلسات لا يراها أحد سواك. وعندما تحتاج إلى متابعة عدة تشغيلات في وقت واحد، فهذا هو الاستخدام الحقيقي الذي وُجدت له لوحة متابعة الوكلاء، ولهذا تنتهي الفرق إلى الرغبة في الطبقة التي تعلو Claude Code وCodex بدل طرفية أخرى.
إذا كنت تشغّل بالفعل عدة وكلاء، فهذا هو سير العمل الذي بُنيت Sharkly حوله. يمكنك الاستمرار في التوجيه يدويًا بين الطرفيات، أو تشغيل وكلاء البرمجة الحاليين لديك عبر Sharkly وترك اللوحة تحمل الخريطة.
متى يكون العمل اليدوي كافيًا، ومتى لا يكون
قاعدة القرار الصادقة قصيرة:
- شغّل الوكلاء يدويًا عندما يكون لديك وكيل أو وكيلان، على جهاز واحد، وتراجع كل واحد قبل بدء التالي. فعبء أي أداة لا يستحق العناء بعد.
- وانتقل إلى طبقة مهام عندما يبدأ وكيل ثالث، أو يمتد العمل على أكثر من مستودع، أو يحتاج شخص غيرك إلى رؤية ما يجري تشغيله. فهذه هي النقطة التي تتوقف عندها تكلفة التنسيق عن الاتساع داخل رأس شخص واحد.
المؤشر ليس عدد الطرفيات. إنه تلك اللحظة التي تجد نفسك تسأل فيها: «انتظر، في أي نافذة كان ذلك؟» هذا السؤال هو ضريبة التنسيق وقد ظهرت في صورة جملة، وهو الفوضى نفسها في إدارة الوكلاء التي وُجدت لوحة المهام لإنهائها.
الأسئلة الشائعة
ألا يكفي tmux أو أي مضاعِف طرفيات؟ إنه يرتّب النوافذ، لكنه لا يزيل التنسيق. فما زلت تحمل في رأسك أي جزء مسؤول عن أي مهمة، وما الذي انتهى، ومن يراجعه. المضاعِف يحل مساحة الشاشة. أما تكلفة تشغيل الوكلاء يدويًا فهي الانتباه، لا البكسلات.
كم وكيلًا يمكنني تشغيله يدويًا قبل أن يصبح الأمر مؤلمًا؟ معظم الناس يكونون بخير مع وكيل أو وكيلين، ويبدأون في الشعور بالعبء عند ثلاثة إلى خمسة، خصوصًا عندما يمتد العمل على أكثر من مستودع. الرقم الدقيق يعتمد على مدة تشغيل كل مهمة ومقدار المراجعة التي تحتاجها. والعلامة الفارقة هي عندما يستهلك التوجيه وإعادة قراءة النوافذ من يومك أكثر مما تستهلكه المراجعة الفعلية.
هل تجعل لوحة المهام وكلائي أسرع؟ لا، وSharkly لا تدّعي ذلك. الوكلاء يعملون بالسرعة نفسها. ما يتغيّر هو العبء الواقع عليك: يتوقف التوجيه والعزل والمراجعة عن السكن في رأسك، ويبدأ بالعودة إلى مهمة يكون فيها العمل مرئيًا وقابلًا للمراجعة.
وماذا عن الحفاظ على السياق بين الجلسات؟ الطرفيات الخاصة تفقد السياق لحظة إغلاقها. أما ربط التشغيل بمهمة فيحفظ الهدف والـ diff والنقاش معًا، وهذه هي مشكلة الحفاظ على السياق بين الجلسات محلولة على مستوى السجل بدلًا من الذاكرة.
هل يمكنني مع ذلك استخدام Claude Code وCodex معًا بهذه الطريقة؟ نعم. تدير Sharkly العمل حول الأدوات ولا تستبدلها. راجع كيفية تشغيل Claude Code وCodex معًا لمعرفة النمط.
