بعد 3,400 commit في العام الماضي، معظمها شُحن عبر مزيج من Claude Code، Codex CLI، PI، Gemini CLI، وOpenCode تعمل جنباً إلى جنب على نفس شجرة العمل، كوّنتُ آراءً قويّة حول ما هذا وما ليس عليه. ليس إكمالاً تلقائياً. ليس “تعزيزاً للإنتاجية.” إنه نموذج متعاون جديد، والفِرق التي تتعامل معه كإكمال تلقائي تترك معظم القيمة على الأرض.

ما كان الإكمال التلقائي

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

كان ذلك مفيداً. الآن هو جزء صغير مما تفعله الجيل الحالي من الأدوات.

ما هو نموذج المتعاون

الوكيل البرمجي الحديث (Claude Code، Codex، Gemini، Cursor، OpenCode، أياً كان) لا يُكمل سطرك. إنه يتولّى مهمّة - أحياناً بسياق 50+ ملفاً، أحياناً يشغّل shell، أحياناً يكرّر لدقائق، أحياناً يتوقّف ليسألك سؤالاً توضيحياً احتاج منك جواباً فعلياً.

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

التشبيه الصحيح هو وجود مبرمج زوجي رخيص بما يكفي لتشغيله بالتوازي. ومضمون ذاك التشبيه: تحتاج إلى تخطيط العمل بشكل مختلف عمّا كان لديك حين كنت تُكمل السطور.

خمسة أشياء غيّرتُها في طريقة عملي

1. أُحدّد المواصفات قبل التنفيذ، دائماً

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

هذا لا يعمل مع وكيل. الوكيل الذي يُعطى مواصفة غامضة ينتج تنفيذاً غامضاً، إضافةً إلى ثلاثة abstractions تبدو معقولة، ويُكلّفك وقت مراجعة جميعها. يجب أن تُقدّم الوضوح مسبقاً. “ابنِ شيئاً يفعل X، بهذه القيود، باستخدام هذا النمط القائم من الملف Y، ولا تضف abstraction متعدّد الأغراض ما لم أطلبه.”

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

2. أقرأ الـdiff بعناية. في كل مرة.

هناك إغراء قوي، حين ينتج الوكيل 500 سطر من الكود الذي يبدو ناجحاً، لتصفّحه وقبوله. لا تتصفّح. الـ500 سطر كثيراً ما تحتوي على:

  • abstraction لم تطلبه.
  • تعليق يصف كوداً كان مختلفاً سابقاً.
  • اسم دالة مخترَع لا يتّسق مع اتفاقية تسمية codebase الخاص بك.
  • “TODO” كتبه الوكيل لنفسه ثم لم يُنجزه.

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

3. أشغّل وكلاء متعدّدين بالتوازي لمهام غير مترابطة

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

المهارة التي تتضاعف هنا هي تحليل العمل. تحديد ثلاث ساعات من العمل المتوازي فعلاً - لا متوازي زائف، متوازٍ حقيقياً - وإعداده مع ثلاثة وكلاء هي مهارة محدّدة بشكل غريب لم يعلّمني إيّاها أحد، والآن أفعلها بشكل تلقائي.

4. أحتفظ بطبقة مهارات مشتركة عبر جميع الوكلاء

وكلاء CLI المختلفة (Claude Code، Codex، Gemini، PI، OpenCode) لها خصائص مختلفة. ما يشتركون فيه هو سياق المشروع - الاتفاقيات، ملفات القواعد، أوامر الاختبار. أُدير ذاك السياق المشترك في مكان واحد (rice-shared-skills) وكل وكيل يسحب منه. حين أُحدّث معياراً للترميز، كل وكيل يراه في دقائق.

هذا ما يجعل تعدّد الوكلاء ممكناً. بدونه، كل وكيل عنده رؤيته الخاصة المتباينة لمشروعك، وتُنفق وقتك الكبير في التوفيق بين الانجراف.

5. أُبدّل الوكلاء في منتصف المهمّة حين يعلق أحدهم

قد يعلق Claude Code في حلقة يُفكّر في إعادة هيكلة معيّنة. أُحوّل نفس السياق إلى Codex، ألصق الحالة، وكثيراً ما أنفكّ في دقائق. ليس لأن Codex “أذكى” بشكل مطلق - جميعها متشابهة تقريباً - بل لأن أدنى حدود كل نموذج منفرد مختلفة، ونموذج مختلف بنفس السياق يهرب منها برخص.

هذا أحد أسباب كتابتي لـraise: تبديل بين 17 أداة ذكاء اصطناعي عبر تبديلات symlink ذرّية مع حفظ بيانات اعتماد، لأن إعادة إعداد كل منها يدوياً كان يأكل يومي.

ما هذا ليس عليه

بعض ما نموذج المتعاون ليس عليه:

  • ليس بديلاً عن حكم الكبير. الوكيل يولّد؛ أنت تراجع. إن لم تستطع المراجعة بمصداقية، أنت تنشر كوداً عشوائياً للإنتاج. المعيار لـ”لا أستطيع مراجعة هذا” يجب أن يكون “هذا الـPR لا يشحن”، مثله كمثل مع إنسان.
  • ليس مجّانياً. أدفع ثمنه، والتكلفة غير ضئيلة. الفِرق التي ترفض الهندسة بمساعدة LLM بسبب تكلفة كل مقعد تُحسب رياضياً بإطار الإكمال التلقائي وتفوّت أن الوكيل يُنجز ساعتين إلى ثلاث من العمل في 15 دقيقة على المهام التي يناسبها.
  • ليس موحّداً عبر أنواع المهام. الوكيل ممتاز في إعادة الهيكلة، كتابة boilerplate، توليد الاختبارات، شرح الكود غير المألوف، وكتابة التوثيق. متوسّط في قرارات المعمارية، حكم المنتج، وأي شيء يتطلّب التفاوض مع بشر. اعرف التفاوت.

مضمون السيرة الذاتية

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

سأقول الجزء الهادئ: هذا هو حيث تذهب كثير من طاقتي بين الوظائف. تشغيل أحمال عمل حقيقية عبر pipelines حقيقية بمساعدة الذكاء الاصطناعي، تدوين ما يعمل وما لا، شحن أدوات تجعل النمط أكثر موثوقية. إن كنتَ توظّف لهذه المهارة، أنا هنا -وعندي رسم commit يدعم الادعاء.