كيف تعمل وكلاء AI لكتابة الكود وما المهم معرفته عنها

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

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

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

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

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

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

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

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

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