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

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

لماذا تُعد هذه مهارة مختلفة فعلًا، وليست نسخة أسرع من المهارة القديمة

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

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

النمط الأوسع، فيما يتجاوز أدوات البرمجة تحديدًا

يجدر الانتباه إلى أن هذا الأمر لا يقتصر على أدوات المطورين. فأحدثت غوغل تصميم مربع البحث لديها — الذي كشفت عنه في الأسبوع نفسه — ليدمج AI Overviews وAI Mode في مسار واحد يمكنه استقبال النصوص والصور وملفات PDF والفيديو وعلامات تبويب Chrome المفتوحة بوصفها مدخلات، ثم يسند العمل إلى وكيل بدلًا من محلل للاستعلامات. والخيط المشترك بين الإصدارين هو نفسه: تبتعد الواجهة عن نموذج «أعطِ الذكاء الاصطناعي تعليمًا واضحًا واحدًا وتحقق من مخرج واضح واحد» وتتجه نحو «سلّم الذكاء الاصطناعي هدفًا غير محدد النطاق بدقة وكومة من المدخلات، ودعه يكتشف الخطوات بنفسه». ويظهر هذا النمط في أي مكان تُنشر فيه الأدوات الوكيلة، وليس في محررات التعليمات البرمجية فحسب — ما يعني أن مهارة المراجعة والتنسيق ستكون ذات صلة خارج أدوار الهندسة بكثير، لكل من تتضمن وظيفته توجيه نظام ذكاء اصطناعي خلال مهمة متعددة الخطوات بدلًا من مطالبة واحدة.

ما الذي ينبغي التدرب عليه فعليًا، بصورة ملموسة

إذا كنت تكتب التعليمات البرمجية أو تديرها، فإن بعض العادات المحددة والقابلة للتحقق تبني هذه المهارة أسرع من القراءة عنها:

  • تعلّم ما هي شجرة العمل المعزولة فعلًا (تتيح ميزة git's worktree فحص فروع متعددة في أدلة منفصلة في الوقت نفسه) قبل أن تثق بادعاء أداة ما بأن التغييرات المتوازية «لا يمكن أن تتعارض». فالعزل أثناء التنفيذ لا يضمن الاتساق عند الدمج — وهذه خطوة منفصلة تستحق المراقبة عن كثب.
  • أسند إلى وكيل برمجة عمدًا مهمة كبيرة بما يكفي لإجباره على تفكيكها، واقرأ كيف يقسم العمل قبل أن تقرأ الفروقات الناتجة. يخبرك التفكيك عن مدى إمكانية الوثوق بالمخرج أكثر مما تخبرك التعليمات البرمجية نفسها.
  • تدرّب على مراجعة الفروقات على دفعات، لا واحدًا تلو الآخر. فمهارة الاحتفاظ بثلاثة أو أربعة تغييرات مترابطة في ذهنك في الوقت نفسه، واكتشاف مواضع اختلافها، تختلف عن مراجعة كل تغيير بمعزل والموافقة عليه بناءً على مزاياه الخاصة.
  • اسأل عما يحدث عند وقوع تعارض، لا عند النجاح فقط. فأي أداة تدّعي إجراء عمليات دمج متوازية تلقائيًا ينبغي أن تكون قادرة على أن تريك ما تفعله عندما يلمس وكيلان المنطق نفسه فعلًا — فهذا المسار الفاشل، أكثر من مسار النجاح السلس، يخبرك بما إذا كانت الأداة آمنة لتسليم عمل حقيقي إليها.

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