كيف تعمل وكلاء الذكاء الاصطناعي لكتابة الشيفرة البرمجية وما الذي يجب معرفته عنها

المبرمج في عام 2025 يكتب الشيفرة من الصفر بوتيرة أقل فأقل. فهو يصوغ المهمة، ويشغّل وكيل الذكاء الاصطناعي، ثم يراقبه وهو يولّد عشرات الملفات، ويعيد هيكلة البنية البرمجية، بل ويشغّل الاختبارات. وقد تحولت أدوات مثل Cursor وGitHub Copilot Workspace وDevin وClaude Code خلال العام الأخير من تجارب غريبة إلى واقع يومي لمئات الآلاف من المطورين. لكن قلّة من المستخدمين يفهمون فعلاً ما الذي يجري تحت الغطاء. وقد نشر موقع Ars Technica تحليلاً مفصلاً للآلية الداخلية لوكلاء الذكاء الاصطناعي المخصصين للبرمجة، وتستحق استنتاجاته انتباه كل من يوكل إلى الآلة جزءاً من عمله، ولو كان صغيراً.

أساس أي وكيل برمجي هو نموذج لغوي كبير، سواء كان GPT-4o أو Claude 3.5 Sonnet أو Gemini. لكن النموذج وحده ليس سوى المحرك، أما الوكيل فهو منظومة هندسية كاملة تحيط به.

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

وبذلك يؤدي الوكيل دور أمين مكتبة ذكي يضع أمام النموذج الكتب المطلوبة للإجابة عن سؤال محدد، بدلاً من أن يكدّس المكتبة كلها على الطاولة.

الآلية الرئيسية الثانية هي سلاسل الاستدلال، أو chain-of-thought. فبدلاً من توليد الإجابة دفعة واحدة، يقسّم الوكيل المهمة المعقدة إلى خطوات متتابعة. يحلل أولاً بنية المشروع، ثم يصوغ خطة التعديلات، ثم ينفذ كل خطوة ويتحقق من نتيجتها، ويصحح المسار عند الحاجة. وليس هذا مجرد أسلوب شكلي، إذ تشير الأبحاث إلى أن الاستدلال خطوة بخطوة يخفض عدد الأخطاء بصورة جذرية عند حل المهام المعقدة. وتذهب بعض الوكلاء أبعد من ذلك فتعتمد ما يُعرف بالبنية متعددة الوكلاء: يعمل نموذج بدور «المعماري» ويفكك المهمة، وينفذ آخر كتابة الشيفرة، ويتولى ثالث المراجعة، ورابع الاختبار. وتتواصل هذه النماذج فيما بينها عبر موجّهات (prompts) منظمة، محاكيةً عمل فريق مطورين حقيقي. وعلى هذا النحو بُني Devin من Cognition وعدد من الأنظمة المتقدمة الأخرى.

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

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

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

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