بنيتَ عادةً كاملة حول لوحة Kanban: عمود لكل مهمة، ووكيل برمجة واحد لكل بطاقة، يعمل كل واحد منها داخل git worktree خاص به حتى لا يتصادم أي شيء. كانت طريقة نظيفة لتشغيل ثلاثة أو أربعة وكلاء في وقت واحد، مع الاحتفاظ بالقدرة على مراجعة الـ diffs واحدًا تلو الآخر. ثم أوقفت الشركة التي كانت تدير الأداة خدماتها السحابية، فبرز السؤال الصادق: أين ستُشغّل وكلاء البرمجة الآن، وهل يصمد هذا الحل بعد تجاوز حدود حاسوب واحد وشخص واحد؟
إذا كنت تبحث عن بديل لـ Vibe Kanban، فأنت لا تبحث عن بديل لـ Claude Code أو Codex، بل عن الطبقة المحيطة ببيئات التشغيل تلك: المكان الذي يُسلَّم فيه لكل وكيل مهمته، ويُحافظ فيه على عزل عمله، ويُعرض عليك ما تغيّر قبل دمج أي شيء. يستعرض هذا الدليل تلك الطبقة. وهو يمنح Vibe Kanban الفضل الكامل في النمط الذي أثبته، ويحدّد النقطة الدقيقة التي تتوقف عندها اللوحة المحلية، ثم يوضح كيف تتجاوز Sharkly ذلك الحد نحو مهام مشتركة وCrews وSprints لفريق كامل.
باختصار
ابتكر Vibe Kanban نموذج «لوحة لكل وكيل»: تشغيل عدة وكلاء برمجة بالتوازي، كل واحد في worktree خاص به، ثم مراجعة مخرجاتهم على لوحة Kanban على جهازك. تحافظ Sharkly على هذا النموذج وتضيف إليه طبقة الفريق: سجل مهمة (Task) مشترك، وأجهزة Computers متصلة، وCrews، وSprints، ومراجعة بشرية من لحظة الطلب حتى الإصدار. إذا كنت تعمل بمفردك على جهاز واحد، فاللوحة المحلية كافية. أما إذا احتاج فريق إلى سياق مشترك وبوابة مراجعة، فهناك تبدأ Sharkly.
المشكلة التي يحلّها بديل Vibe Kanban فعليًا
أصاب Vibe Kanban في أمر غابت عنه معظم الأدوات: عندما تشغّل عدة وكلاء برمجة بالذكاء الاصطناعي في وقت واحد، فإن الجزء الصعب ليس النماذج، بل التعارضات. وكيلان يحرّران الملفات نفسها، ومخرجات متناثرة بين تبويبات الطرفية، ولا رؤية واحدة تحدّد أي مهمة أُنجزت، وأيها متعطّلة، وأيها انحرفت بصمت.

كانت فكرة «لوحة لكل وكيل» أنيقة. امنح كل مهمة بطاقتها الخاصة. وامنح كل بطاقة git worktree خاصًا بها، ليعمل الوكيل على فرع معزول داخل مجلد معزول. ثم دع Claude Code أو Gemini CLI أو Codex أو أي بيئة تشغيل أخرى تنفّذ العمل داخل تلك البيئة المعزولة، لتعيد الـ diff بعدها للمراجعة. بهذا تحوّل الوضع من «لديّ خمسة وكلاء ولا فكرة عمّا فعل أيٌّ منهم» إلى لوحة يمكنك قراءتها فعلًا. وإذا أردت تفاصيل هذا النمط المتوازي بحد ذاته، فإن دليلنا حول كيفية تشغيل عدة وكلاء Claude Code بالتوازي يشرح إعداد الـ worktree بالتفصيل.
لم تكن الفجوة يومًا في النمط نفسه، بل فيما لا تستطيع اللوحة المحلية الوصول إليه. فاللوحة على جهازك هي لوحة لك وحدك. لا يستطيع زميلك رؤية المهمة، ولا التقاط بطاقة متعطّلة، ولا مراجعة الـ diff قبل الدمج، ولا معرفة ما إذا كان الـ sprint يسير على المسار الصحيح من الجهة الأخرى للغرفة. عندما يكون العمل فرديًا، فلا مشكلة في ذلك. أما عندما يكون العمل ملكًا لفريق، فالقطعة الناقصة هي سجل مشترك، وهذا نوع مختلف تمامًا من الأدوات.
ما أثبته Vibe Kanban، بصراحة تامة
لنمنح الأداة أفضل وصف يليق بها، فقد استحقّت ذلك. لقد تعامل Vibe Kanban مع تشغيلات الوكلاء كوحدات عمل من الدرجة الأولى، لا كجلسات طرفية تُرمى بعد الاستخدام. وجعل عزل الـ worktree هو الوضع الافتراضي، فكفّت الوكلاء المتوازية عن التداخل. وجعل التبديل بين بيئات التشغيل رخيصًا، فلم تعد مرتبطًا بنموذج واحد. وجعل المراجعة خطوة أساسية لا فكرة لاحقة، بأن وضع الـ diff أمامك قبل أن تنقل البطاقة إلى «منجز».
هذه الأفكار الأربع صحيحة، وأي بديل جاد عليه أن يحافظ عليها جميعًا. فبديل Vibe Kanban الذي يتخلى عن عزل الـ worktree، أو يخفي الـ diff، أو يحبسك في بيئة تشغيل واحدة، هو تراجع مهما أضاف من ميزات أخرى. المستوى الذي وضعته اللوحة هو الأرضية، لا السقف.
ما تغيّر هو قصة الصيانة. فالمشروع مفتوح المصدر وما زال قابلاً للتشغيل محليًا، لكن ميزات السحابة التي كانت تديرها الشركة أُزيلت، وأصبحت الإصلاحات المستمرة تعتمد على مساهمين من المجتمع. بالنسبة لمطوّر فردي، قد يكون هذا مقبولًا تمامًا. أما لفريق يراهن على الأداة بربع نتائج التسليم، فإن «الاعتماد على من يظهر للمساهمة» مخاطرة حقيقية تستحق التقييم، وهذا هو السبب الصادق وراء تنشّط رغبة الانتقال إلى بديل الآن.
أين تنتهي اللوحة المحلية وتواصل Sharkly
إليك زوج القرار، مصوغًا بالطريقة التي ينكشف بها الخيار فعليًا.
استخدم لوحة محلية عندما تكون شخصًا واحدًا على جهاز واحد، والمهام ملكك وحدك، ولا يحتاج أحد آخر لرؤية العمل حتى تفتح pull request. فإعداد «لوحة لكل وكيل» خفيف، ويعمل حيث تعمل أنت، ولا يضيف أي عبء تنسيقي لأنه لا يوجد أحد آخر لتنسيق العمل معه. واللجوء إلى منصة فريق في هذه الحالة مبالغة لا داعي لها.

واستخدم Sharkly عندما تتوقف تشغيلات الوكلاء عن كونها خاصة. فبمجرد أن يحتاج شخص ثانٍ إلى إسناد مهمة، أو معالجة عائق، أو مراجعة diff قبل الدمج، تصبح اللوحة التي تعيش على حاسوبك عنق الزجاجة. هذا هو الحد الفاصل. Sharkly هي الطبقة التي تحيط ببيئات التشغيل نفسها التي تستخدمها بالفعل، وتجعل كل تشغيل قابلًا للإسناد والرؤية والمراجعة من الفريق، لا منك وحدك.
وإليك تعريفًا سريعًا على طريقة المعاجم، لأن ما يلي يعتمد عليه. المهمة (Task) هي وحدة العمل الأساسية في Sharkly. تحمل الهدف، والوكيل المُسنَد إليها، وبيئة التشغيل، والتقدّم، والعوائق، والـ diff الناتج، والمراجعة البشرية، كل ذلك في سجل مشترك واحد. وحيث تكون البطاقة على اللوحة المحلية ملكك، فإن المهمة ملك الفريق.
وأخيرًا حدّ واضح، لأن القارئ المنتقل من لوحة قد يفترض غير ذلك. Sharkly ليست بديلًا لـ Claude Code أو Codex أو Gemini. فهي لا تشغّل النموذج ولا تكتب الكود، بل تضيف طبقة المهمة المشتركة، والـ Computer المتصل، والسياق، والتحكم، والمراجعة حول أدوات التنفيذ التي يستخدمها فريقك بالفعل. وإذا كنت تحب في Vibe Kanban حرية تبديل بيئات التشغيل، فإن Sharkly تحافظ على هذه الحرية وتضع فريقًا حولها.
مسار الانتقال: احتفظ ببيئات التشغيل والمستودعات، وأضف طبقة المراجعة
أجمل ما في ترك لوحة تُغلق خدماتها هو قِلّة ما عليك التخلي عنه. فأنت لا تعيد بناء منظومتك، بل تحتفظ بالأجزاء التي كانت ناجحة وتضيف الجزء الذي كان ناقصًا.
احتفظ ببيئات التشغيل. يواصل Claude Code وCodex وGemini CLI وOpenCode وCline وغيرها التنفيذ تمامًا كما كانت. ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المُهيّأة مسبقًا في تلك الأدوات. أنت تأتي باشتراكك الخاص؛ فـ Sharkly لا تقف بين الوكيل والنموذج. وإذا أردت الأساس المفاهيمي لما تفعله هذه البيئات، فإن شرحنا حول ما يعنيه البرمجة بالوكلاء لفرق التطوير يضع المصطلحات في مكانها.
احتفظ بمستودعاتك وبعادتك مع الـ worktree. تشغّل Sharkly الوكلاء في worktrees معزولة على أجهزة Computers متصلة، أي العزل نفسه الذي كنت تعتمد عليه، لكنه مرتبط الآن بمهمة مشتركة بدل بطاقة محلية. ويمكن للواجهة الأمامية والخلفية وإصلاح الأخطاء وتغطية الاختبارات أن تتقدّم في الوقت نفسه دون تصادم، وهذا هو سبب وجود نموذج «لوحة لكل وكيل» من الأصل.
أضف طبقة المراجعة التي كانت ناقصة. هذا هو الجزء الجديد. يعود التنفيذ والعوائق والنتائج والنقاش اللاحق إلى الخط الزمني للمهمة حيث يراها الفريق. يبحث الوكيل وينفّذ ويختبر ويقدّم تقريرًا. أما البشر فيضعون التوجّه، ويمنحون الصلاحية، ويقبلون النتيجة. تتوقف الأتمتة حيث يلزم حكم الفريق، ثم تعود بتسليم يحمل سياقًا كاملاً وأدلة قابلة للفحص. هذه الجملة الأخيرة هي العقد الذي لم تستطع لوحة محلية فرضه، لأنه لم يكن هناك فريق في الطرف الآخر منه.
إذن فالانتقال تراكمي. صِل جهاز Computer، ووجّه Sharkly إلى بيئات التشغيل التي لديك بالفعل، وابدأ بتوجيه العمل دون إعادة بناء العملية التي يفهمها فريقك مسبقًا. لقد علّمتك اللوحة تشغيل الوكلاء بالتوازي، وSharkly تتيح لبقية الفريق المشاركة في ذلك.
من لوحة فردية إلى نظام فريق: Crews وSprints وProjects
بمجرد أن تصبح التشغيلات مشتركة، تُفتح ثلاث قدرات لم يكن في مقدور لوحة أحادية المستخدم تقديمها.
Crews، للعمل الذي يحتاج أكثر من وكيل واحد. الـ Crew مجموعة قابلة لإعادة الاستخدام من الأشخاص والوكلاء ينسّقها وكيل قائد واحد. وبالنسبة للعمل الصغير واضح المعالم لا تحتاج إليها: أسنِد المهمة إلى وكيل واحد وأبقِ الأجزاء المتحركة عند الصفر. استخدم الـ Crew عندما يحتاج الوكيل القائد إلى تفسير هدف أوسع، واستدعاء أعضاء آخرين من الوكلاء، وجمع نتائجهم في مهمة واحدة. هذه هي القاعدة الصادقة. الـ Crew رافعة عندما يكون العمل متعدد الأجزاء فعلًا، وعبء زائد عندما لا يكون كذلك.
Sprints وProjects، لتتبّع يستمر أبعد من بطاقة واحدة. تُظهر اللوحة المحلية المهام التي بين يديك اليوم. أما الـ Sprint فيتتبّع الإنجاز والملكية والاعتماديات وتغيّرات النطاق والعوائق عبر مجموعة من الأعمال على مدى زمني. وبالنسبة لفريق هجين من أشخاص ووكلاء، هذا هو الفرق بين «فعلت الوكلاء بعض الأشياء هذا الأسبوع» وخطة يمكنك فعليًا إعداد تقارير مقابلها. وشرحنا التمهيدي حول تنسيق وكلاء الذكاء الاصطناعي لفرق التطوير يستعرض لماذا تُكسب إنتاجية الفريق أو تُخسر في طبقة التنسيق، لا في النماذج.
شفافية الفريق، كوضع افتراضي لا كمشاركة شاشة. أبقِ السياق والتقدّم والعوائق والنتائج والمراجعة البشرية ظاهرة من الطلب حتى الإصدار. على اللوحة المحلية، كانت الرؤية تتوقف عند شاشتك. أما في نظام مشترك، فلا تأتي الرافعة من فتح المزيد من محادثات الذكاء الاصطناعي، بل من مشاركة الأدوار والقواعد والسياق وسير العمل، ليصبح إعداد جيد واحد قدرة يعيد الفريق كله استخدامها.
Vibe Kanban مقابل Sharkly: مقارنة منصفة
| البُعد | Vibe Kanban (لوحة محلية) | Sharkly (طبقة الفريق) |
|---|---|---|
| الوحدة الأساسية | بطاقة على جهازك | مهمة (Task) مشتركة للفريق |
| الوكلاء المتوازون | نعم، معزولون في worktrees | نعم، معزولون في worktrees على أجهزة Computers متصلة |
| بيئات التشغيل | Claude Code وGemini وCodex وغيرها | نفس بيئات التشغيل، تُستخدم كما هي |
| المراجعة | مراجعة الـ diff، بشكل فردي | مراجعة بشرية من الطلب حتى الإصدار، على مستوى الفريق |
| تجميع الوكلاء المتعددين | ليس جزءًا من النموذج | Crews بقيادة وكيل قائد |
| التخطيط على مدى زمني | عرض اللوحة | Projects وSprints |
| فوترة النموذج | مفاتيحك الخاصة، ويعمل محليًا | أحضر اشتراكك الخاص؛ تبقى المفاتيح داخل الأدوات |
| الصيانة | مفتوحة المصدر، يديرها المجتمع بعد الإغلاق | منصة تُطوَّر بنشاط |
| الأنسب لـ | مطوّر فردي على جهاز واحد | فرق توجّه عمل الوكلاء وتراجعه معًا |
اقرأ الجدول كتقسيم للأدوار، لا كلوحة نتائج. فبالنسبة لمطوّر فردي يريد لوحة محلية مجانية ولا شيء أكثر، قد يظل المشروع الذي يديره المجتمع الخيار الصحيح، ولا حرج في البقاء هناك. أما بالنسبة لفريق يحتاج إلى أن تكون التشغيلات مشتركة وقابلة للإسناد والمراجعة، فقد كانت اللوحة ستضيق بها المساحة دائمًا، وSharkly هي المكان الذي تواصل فيه بيئات التشغيل نفسها عملها مع إضافة الفريق. يمكنك تنزيل Sharkly وربط جهاز Computer واحد لترى الفرق على عمل حقيقي.
أخطاء شائعة عند الانتقال من لوحة محلية
- التعامل مع الأمر كاستبدال متماثل. أنت لا تبحث عن لوحة أخرى، بل عن طبقة الفريق التي لم تملكها اللوحة يومًا. وإذا كان البديل يكتفي بإعادة إنتاج الأعمدة والبطاقات، فهو لم يحلّ شيئًا.
- التخلي عن عزل الـ worktree للتحرك أسرع. هذا العزل هو سبب عدم تصادم الوكلاء المتوازية. حافظ عليه. أي أداة تجعل الوكلاء يتشاركون مجلد العمل نفسه تعيد عليك مشكلة حقيقية كنت قد تجاوزتها.
- إضافة Crew لعمل وكيل واحد. لا تلجأ إلى Crew إلا عندما يحتاج الهدف فعلًا إلى وكيل قائد ينسّق الأعضاء. أما في مهمة محددة النطاق، فوكيل واحد وصفر أجزاء متحركة هو الجواب الصحيح.
- تخطّي بوابة المراجعة بدافع الشعور بالإنتاجية. الهدف من هذه الطبقة هو أن يقبل البشر النتيجة. ودمج diffs الوكلاء دون مراجعة لأن ذلك أسرع يعيد عليك بالضبط الأمان الذي وُجد النظام كله لتوفيره.
- ترحيل كل شيء من اليوم الأول. ابدأ بمتطلب حقيقي واحد ومهمة واحدة منخفضة المخاطر. أثبت الحلقة، ثم وسّعها.
الخاتمة
أثبت Vibe Kanban نمطًا يستحق البقاء: الوكلاء يعملون بأفضل صورة بالتوازي، معزولين في worktrees خاصة بهم، والمراجعة خطوة حقيقية. هذا النمط هو الأرضية الآن، وأي بديل لـ Vibe Kanban يتخلى عنه إنما يسير إلى الوراء.
- كان نموذج «لوحة لكل وكيل» صحيحًا؛ فوجود وكلاء متوازين معزولين في worktrees مع مراجعة الـ diff هو الشكل الصحيح.
- تنتهي اللوحة المحلية عند شخص واحد على جهاز واحد. أما العمل المشترك فيحتاج سجلًا مشتركًا.
- تحافظ Sharkly على بيئات التشغيل ومستودعاتك وعادتك مع الـ worktree، وتضيف طبقة الفريق حولها.
- تحمل المهمة الهدف وبيئة التشغيل والتقدّم والعوائق والـ diff والمراجعة في مكان واحد.
- تحوّل Crews وSprints وProjects التشغيلات المتوازية إلى خطة يمكن للفريق إعداد تقارير مقابلها.
- الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون تقاريرهم؛ والبشر يضعون التوجّه ويمنحون الصلاحية ويقبلون النتيجة.
إذا كنت تختار أين ستشغّل وكلاء البرمجة بعد ذلك، فاحتفظ بالأدوات التي يستخدمها فريقك بالفعل وأضف الطبقة التي تجعل التشغيلات قابلة للإسناد والتتبّع. صِل جهاز Computer واحدًا، وأنشئ وكيلًا واحدًا، وأسنِد إليه مهمة رتيبة. ثم دع بقية الفريق يشاهد العمل يعود إلى المهمة. ابدأ من Sharkly، وتغطي الوثائق كل مفهوم بمزيد من العمق على docs.sharkly.ai.
الأسئلة الشائعة
هل ما زال Vibe Kanban قابلًا للاستخدام بعد إغلاق Bloop؟ نعم. المشروع مفتوح المصدر وما زال قابلًا للتشغيل محليًا. أُزيلت ميزات السحابة التي كانت تديرها الشركة، وأصبحت الإصلاحات والتحديثات تعتمد الآن على مساهمين من المجتمع. قد يكون هذا كافيًا للاستخدام الفردي، أما للفريق الذي يعتمد عليه في التسليم، فمخاطرة الصيانة تستحق التقييم.
هل Sharkly بديل لـ Claude Code أو Codex؟ لا. Sharkly ليست بديلًا لـ Claude Code أو Codex أو غيرهما من أدوات التنفيذ. تلك البيئات تنفّذ العمل، أما Sharkly فتضيف طبقة المهمة المشتركة وComputer والسياق والتحكم والمراجعة حولها. وتستمر في استخدام الوكلاء أنفسهم.
هل عليّ التخلي عن تشغيل الوكلاء في worktrees متوازية؟ لا. تشغّل Sharkly الوكلاء في worktrees معزولة على أجهزة Computers متصلة، وهو العزل نفسه الذي اعتمد عليه نموذج «لوحة لكل وكيل». ويمكن للواجهة الأمامية والخلفية والاختبارات أن تتقدّم في الوقت نفسه دون تصادم. راجع كيفية تشغيل عدة وكلاء Claude Code بالتوازي للنمط الأساسي.
ما الذي يتضمنه الانتقال من لوحة محلية فعليًا؟ احتفظ ببيئات التشغيل ومستودعاتك. صِل جهاز Computer، ووجّه Sharkly إلى أدوات التنفيذ التي تستخدمها بالفعل، وابدأ بتوجيه العمل كمهام مشتركة. ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المُهيّأة مسبقًا في تلك الأدوات، فلا تتغير الفوترة.
متى يجب ألّا أستخدم Sharkly؟ عندما تكون شخصًا واحدًا على جهاز واحد ولا يحتاج أحد آخر لرؤية العمل أو مراجعته، فاللوحة المحلية كافية. أما Sharkly فتستحق مكانها من اللحظة التي يحتاج فيها شخص ثانٍ إلى إسناد تشغيل وكيل أو معالجته أو مراجعته.
ما الفرق بين البطاقة والمهمة (Task)؟ البطاقة على اللوحة المحلية ملكك وتعيش على جهازك. أما المهمة فهي سجل الفريق المشترك: تحمل الهدف والوكيل المُسنَد وبيئة التشغيل والتقدّم والعوائق والـ diff والمراجعة البشرية، وتعود إليها نتائج التنفيذ.



