ما هي البرمجة الوكيلية؟

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

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

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

باختصار: ما هي البرمجة الوكيلية؟

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

سقف الأوامر والنسخ واللصق

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

يظهر هذا الألم في ثلاثة مواضع يمكن توقّعها. أولًا، السياق يعيش في رأسك وفي سجل دردشتك الخاصة، فلا يستطيع زميل أن يرى لماذا اتخذ الوكيل قرارًا معينًا أو ما جرّبه من قبل. ثانيًا، معدّل الإنجاز محصور بتركيز شخص واحد: خمسة نوافذ طرفية مفتوحة، وخمس جلسات وكلاء منتصفة، ولا سجل مشترك يوضّح أيّها انتهى فعلًا. ثالثًا، لا شيء خاضع للمساءلة؛ فتفكير الوكيل، والـ diff الخاص به، ومخرجات اختباراته، تتفرّق في نافذة دردشة لا يراجعها أحد قبل دمج الشيفرة.

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

تعريف عملي للبرمجة الوكيلية

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

شطرا هذه الجملة يحملان الفكرة كلها. شطر الوكيل هو حلقة من الأفعال: البحث في قاعدة الشيفرة والمتطلبات، وتنفيذ التغيير، وتشغيل الاختبارات والبناء، ثم العودة بملخّص وأدلة قابلة للفحص. أما شطر الشخص فهو حلقة أقصر: تحديد الاتجاه، ومنح الصلاحية، والقبول أو الرفض. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير. والبشر يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وتتوقف الأتمتة عند الحد الذي يتطلب حكمًا بشريًا من الفريق.

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

هذا التمييز يفصل أيضًا بين البرمجة الوكيلية و«Vibe coding» حيث تقبل الشيفرة المولّدة دون قراءتها. فالـ Vibe coding يُسقط الإنسان من طرف القبول، أما البرمجة الوكيلية فتحتفظ بذلك الطرف وتؤتمت الوسط. الأولى اختصار، والثانية سير عمل يمكنك أن تدير فريقًا بأكمله عليه.

سُلّم النضج: أربع مراحل للبرمجة الوكيلية

لا تنتقل الفرق مباشرة إلى وكلاء مستقلين، بل تتدرّج صعودًا. وتسمية الدرجات تجعل من الواضح أين يقف فريقك الآن وكيف تبدو الخطوة التالية الصادقة.

المرحلة الأولى: مساعد الدردشة

يكمل النموذج الأسطر، ويجيب عن الأسئلة، ويصيغ الدوال داخل محرّرك، وأنت تقود كل خطوة. لا وجود لمهمة دائمة ولا ملكية ولا تقرير؛ والقيمة هنا في سرعة الكتابة والإجابات السريعة. من هنا بدأ معظم المطوّرين، وما زال هذا هو الأداة المناسبة لإصلاح من سطر واحد. واللجوء إلى وكيل في هذه الحالة مبالغة لا داعي لها.

المرحلة الثانية: الوكيل الواحد

تُسند مهمة واحدة محددة النطاق إلى وكيل واحد وتدعه يكمل الحلقة كاملة: يقرأ الملفات ذات الصلة، وينفّذ التغيير، ويشغّل الفحوصات، ويعود بـ diff وملخّص. يعمل الوكيل انطلاقًا من الحالة الراهنة للشيفرة، لا من أمر فارغ. وهذه هي الدرجة الحقيقية الأولى في البرمجة الوكيلية، لأن العمل — لا الرسالة — يصبح الوحدة لأول مرة. ونقطة البداية الجيدة هي تغيير صغير منخفض المخاطر؛ ودليلنا حول كيفية إسناد مهمتك الأولى إلى وكيل برمجة بالذكاء الاصطناعي يتناول هذه الدرجة تحديدًا.

المرحلة الثالثة: الوكلاء المتوازون

الآن تشغّل عدة وكلاء في وقت واحد، لكل واحد مهمته الخاصة، وكل واحد في worktree معزول حتى لا تتصادم أعمالهم. فالعمل على الواجهة الأمامية، ونقطة نهاية في الواجهة الخلفية، وإصلاح خطأ، ومجموعة من تغطيات الاختبار، يمكن أن يسير كلها في الوقت نفسه. ويتوقف تحديد معدّل الإنجاز بتركيز شخص واحد. لكن العقبة هنا هي التنسيق: خمسة وكلاء في خمسة نوافذ طرفية يعني سرعة أكبر وفوضى أكبر أيضًا، إلا إذا بقي شيء ما يحفظ الأهداف والـ diffs والنتائج في مكان واحد. وهذه هي الدرجة التي تتجاوز فيها الفرق أدوات tmux والسكربتات المرتجلة؛ راجع كيفية تشغيل عدة وكلاء Claude Code بالتوازي للتفاصيل العملية.

المرحلة الرابعة: الـ Crew المنسّق

في الدرجة العليا، يفسّر وكيل قائد هدفًا أكبر، ويقسّمه إلى مهام، ويستعين بأعضاء وكلاء آخرين، ويعيد نتيجتهم المجمّعة في مهمة واحدة. والـ Crew مجموعة قابلة لإعادة الاستخدام من الأشخاص والوكلاء ينسّقها وكيل قائد واحد. لم تعد تُسند تغييرات فردية، بل تُسند نتائج نهائية. وهذا أمر بالغ القوة، وهو أيضًا الدرجة التي يكون فيها إغراء تجاوز القبول البشري في أشدّه، ولهذا تحديدًا تصبح بوابة القبول أكثر أهمية هنا.

استخدم وكيلًا واحدًا عندما يكون العمل صغيرًا ومحددًا بوضوح. واستخدم Crew عندما يحتاج القائد إلى تفسير الهدف وإشراك أعضاء وكلاء آخرين وإعادة نتائجهم في مهمة واحدة. أما الصعود درجة إلى أعلى مبكرًا، قبل أن تمتلك الرؤية الكافية لمراجعة ما فعله الوكلاء، فهو أكثر الطرق شيوعًا لاحتراق الفرق.

حلقة الوكيل: البحث، والتنفيذ، والاختبار، والتقرير

يستحق هذا التسلسل من الأفعال وقفة أطول، لأنه هو ما يفصل الوكيل عن مجرد إكمال تلقائي متطوّر.

البحث. قبل أن يلمس الشيفرة، يقرأ الوكيل القادر سياق المنتج، وقاعدة الشيفرة، والمهام السابقة ذات الصلة، وقواعد الفريق، ثم يستكمل النطاق ومعايير القبول. وهذه هي الخطوة التي تتجاهلها الدردشة كليًا؛ فالأمر يبدأ من لا شيء، أما الوكيل فيبدأ من مستودعك كما هو اليوم.

التنفيذ. يُجري الوكيل التغيير في worktree معزول، فلا تسرّب جلسة نصف مكتملة أي تلوث إلى الفرع الرئيسي أو إلى عمل وكيل آخر. وتُعدّ أدوات Git worktree هي الآلية المملّة والمجرّبة التي يقوم عليها هذا الأمر؛ فهي تتيح لفروع كثيرة أن توجد في الوقت نفسه كأدلة عمل منفصلة.

الاختبار. يشغّل الوكيل فحص الأنواع، ومجموعة الاختبارات، والبناء، ويرفق النتائج. وهذا هو الفرق بين «إليك بعض الشيفرة» و«تغيير يجتاز الفحوصات». فالتقرير بلا أدلة مجرد ادعاء.

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

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

أين يبقى الإنسان: عقد القبول

أهم جملة في البرمجة الوكيلية تتعلق بالأجزاء التي لا تؤتمتها. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير. والبشر يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. اترك قرارات القبول والإطلاق النهائية للبشر.

لنفصّل ذلك في المواضع الثلاثة التي يبقى فيها الإنسان:

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

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

البرمجة الوكيلية كسير عمل جماعي مع Sharkly

كل ما سبق يعمل مع مطوّر واحد ووكيل واحد، لكنه ينهار مع فريق ما لم يكن العمل والسياق والمراجعة في مكان مشترك. وهذه الفجوة هي ما تسدّها Sharkly.

Sharkly ليست بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى، بل تضيف طبقة المهمة المشتركة وComputer والسياق والتحكم والمراجعة حول الأدوات التي يستخدمها فريقك بالفعل. تقوم Claude Code وCodex والأدوات المشابهة بالتنفيذ، بينما تدير Sharkly الإسناد على مستوى الفريق، وأجهزة Computer المتصلة، وسياق المهمة، والتقدم، والعوائق، والنتائج، والمراجعة البشرية عبر هذه الأدوات. فأنت تحتفظ باشتراكات النماذج ومفاتيح API التي أعدّها فريقك أصلًا، وتجعل Sharkly عمليات التشغيل قابلة للإسناد والتتبع.

وإليك كيف ينطبق سُلّم المراحل الأربع على المنتج:

• المهمة هي وحدة العمل الأساسية في Sharkly، وفيها يعيش الطلب، وdiff الوكيل، ونتائج الاختبارات، والمراجعة. وهذا هو السجل المشترك الذي لم تملكه الدردشة يومًا.
• الوكيل يحدد كيف يجب التعامل مع العمل؛ وComputer يوفّر المضيف والموارد المحلية؛ وRuntime ينفّذ جلسة الوكيل الفعلية؛ وتبقى المهمة هي السجل المشترك للفريق. لكل دور وظيفة واحدة.
• تشغيل الوكلاء بالتوازي آمن لأن كل واحد يعمل في worktree معزول على Computer متصل، فلا تتعارض عمليات التشغيل المتزامنة.
• الـ Crew يتولى الدرجة المنسّقة: مجموعة قابلة لإعادة الاستخدام من الأشخاص والوكلاء ينسّقها وكيل قائد واحد، وتُعاد النتيجة المجمّعة إلى مهمة واحدة.

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

والمكسب العملي هو نظام يبقى فيه السياق والتقدم والعوائق والنتائج والمراجعة البشرية مرئيًا، ثم أسند إليه مهمة واحدة منخفضة المخاطر.

أخطاء شائعة عند تبنّي البرمجة الوكيلية

تتكرر أنماط فشل معينة مرارًا. تجنّبها ويصبح التدرّج أكثر سلاسة بكثير.

1. الصعود إلى الـ Crews قبل القدرة على مراجعة وكيل واحد. إذا لم تستطع رؤية عمل وكيل واحد وقبوله بوضوح، فخمسة وكلاء سيدفنونك. أتقن المرحلة الثانية قبل الرابعة.
2. تسليم اتجاه غامض. عبارة «حسّن مسار الدفع» ليست مهمة. حدّد نطاقها، أو دع الوكيل يصوغ النطاق ومعايير القبول ثم أكّدها قبل أن يبدأ التنفيذ.
3. تجاوز بوابة القبول تحت ضغط المواعيد. في اللحظة التي تدمج فيها مخرجات وكيل دون قراءتها لأن الاختبارات نجحت، تكون قد استبدلت البرمجة الوكيلية بالـ Vibe coding. نجاح الاختبارات ضروري لكنه ليس كافيًا.
4. تشغيل وكلاء متوازين دون عزل. الوكلاء المتزامنون الذين يتشاركون دليل عمل واحد يفسدون تغييرات بعضهم بعضًا. وworktrees المعزولة لكل وكيل ليست خيارًا اختياريًا في المرحلة الثالثة.
5. ترك السياق في دردشات خاصة. إذا لم يكن منطق التغيير مدوّنًا في المهمة، فلن يستطيع الشخص التالي مراجعته أو البناء عليه. حافظ على السجل مشتركًا.

البرمجة الوكيلية مقارنة بمصطلحات أخرى ذات صلة

المصطلحات المحيطة بهذا المجال كثيرة ومتشابكة. وإليك كيف تقف البرمجة الوكيلية إلى جانب المصطلحات التي تُخلط بها.

البرمجة الوكيلية هي سير العمل، أما التنسيق فهو ما تحتاجه بمجرد أن يصبح لديك أكثر من وكيل واحد يشغّله. وهما ركنان في النظام نفسه، ولهذا فإن الفرق التي تتبنّى أحدهما ترغب عادة في الآخر بعد وقت قصير.

حالات استخدام واقعية

نقطة نهاية في الواجهة الخلفية تحت ضغط الموعد. يصف مطوّر نقطة نهاية جديدة ومدخلاتها ومعايير قبولها في صورة مهمة. فيبحث الوكيل في أنماط المسارات القائمة، ويكتب المعالج والاختبارات في worktree معزول، ويشغّل مجموعة الاختبارات، ويعود بـ diff مع فحوصات ناجحة. ثم يراجع المطوّر ويدمج. الوقت الفعلي المستغرق: رسالة لتحديد النطاق ومراجعة.

حملة إصلاح أخطاء متوازية. يسجّل قائد تقني ست مهام أخطاء غير مترابطة قبل الاجتماع اليومي. يستلمها ستة وكلاء، كل واحد على worktree وComputer خاص به. وبحلول منتصف الصباح، تحمل المهام ستة diffs مع أدلة اختبار جاهزة للمراجعة. ولم يعد تركيز شخص واحد يحدّ من إنجاز ستة إصلاحات.

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

الخاتمة

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

• الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير؛ والبشر يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة.
• تنضج عبر أربع درجات: مساعد الدردشة، والوكيل الواحد، والوكلاء المتوازون، والـ Crew المنسّق.
• بوابة القبول لا تنتقل أبدًا إلى الآلة، مهما بلغت قدرة الوكيل.
• العمل المتوازي يحتاج إلى عزل، والعمل الجماعي يحتاج إلى مهمة مشتركة تعود إليها النتائج.
• الجزء الصعب هو التنسيق والمراجعة، وهي الطبقة التي تضيفها Sharkly حول أدوات البرمجة التي تشغّلها بالفعل.

ابدأ من أدنى درجة مفيدة. نزّل Sharkly، واربط Computer واحدًا، وأنشئ وكيلًا واحدًا، وأسند إليه مهمة صغيرة ومملّة. واقبل النتيجة بنفسك. تلك الحلقة الواحدة، عند تشغيلها مرة واحدة، تعلّمك عن البرمجة الوكيلية أكثر من أي تعريف، بما في ذلك هذا التعريف.

الأسئلة الشائعة

ما هي البرمجة الوكيلية ببساطة؟ إنها طريقة لبناء البرمجيات تُسند فيها قطعة عمل محددة النطاق إلى وكيل برمجة بالذكاء الاصطناعي يبحث في قاعدة شيفرتك، وينفّذ التغيير، ويشغّل الاختبارات، ويعود بتقرير مدعوم بالأدلة، بدلًا من تبادل رسالة واحدة في كل مرة في محادثة. وتبقى أنت المسؤول عن تحديد ما يجب بناؤه وعما إذا كانت النتيجة جيدة بما يكفي للنشر.

كيف تختلف البرمجة الوكيلية عن استخدام ChatGPT أو Copilot لكتابة الشيفرة؟ مساعدات الدردشة والإكمال التلقائي تجيب عن أمر وتعيد النتيجة إليك لتدمجها وتتحقق منها. أما الوكيل فيأخذ مهمة كاملة عبر البحث والتنفيذ والاختبار ثم تقرير بالنتيجة. تتغير الوحدة من رسالة إلى قطعة عمل، ويبدأ الوكيل من مستودعك الفعلي لا من صندوق فارغ.

هل البرمجة الوكيلية هي نفسها Vibe coding؟ لا. الـ Vibe coding يعني قبول الشيفرة المولّدة دون قراءتها، وهو ما يُسقط الإنسان من خطوة القبول. أما البرمجة الوكيلية فتُبقي القبول بيد شخص بحزم وتؤتمت الوسط فقط: البحث والتنفيذ والاختبار. الأولى اختصار، والثانية سير عمل قابل للمراجعة.

هل تحل البرمجة الوكيلية محل المطوّرين؟ لا. إنها تنقل المطوّر من كتابة كل سطر إلى تحديد الاتجاه ومنح الصلاحية وقبول النتيجة. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون التقارير؛ والبشر يقرّرون ماذا يُبنى وهل يُنشر. أما القبول النهائي والإطلاق فيبقيان بيد البشر.

ما الأدوات التي أحتاجها لبدء البرمجة الوكيلية؟ أداة برمجة بالذكاء الاصطناعي قادرة على تنفيذ المهام (Claude Code وCodex وما شابههما)، وطبقة لإسناد العمل والحفاظ على سياق مشترك ومراجعة النتائج على مستوى الفريق. وSharkly هي تلك الطبقة؛ فهي تعمل فوق أدوات التنفيذ والاشتراكات التي تمتلكها بالفعل. راجع ما هي Sharkly للحصول على نظرة عامة.

كيف تشغّل الفرق العديد من وكلاء البرمجة في وقت واحد دون فوضى؟ يعمل كل وكيل على مهمته الخاصة في worktree معزول، وتعود كل نتيجة إلى مهمة مشتركة يستطيع شخص مراجعتها. هذا المزيج، أي العزل في التنفيذ مع سجل مشترك للمراجعة، هو ما يمنع تصادم عمليات التشغيل المتوازية. ويتناول دليلنا حول تشغيل عدة وكلاء Claude Code بالتوازي تفاصيل الإعداد.

أين يبقى الإنسان في سير عمل البرمجة الوكيلية؟ في ثلاثة مواضع: الاتجاه (ماذا نبني)، والصلاحية (ما يُسمح للوكيل بلمسه)، والقبول (هل تُنشر النتيجة). كل ما بين هذه المواضع يمكن أتمتته، أما هذه الثلاثة فتبقى بيد البشر.