GitLab تكشف لماذا يحتاج مبرمجو الذكاء الاصطناعي إلى سياق المنصة وليس الشيفرة وحدها

كل أسبوع تصدر عروض تجريبية لوكلاء ذكاء اصطناعي يحوّلون prompt إلى pull request في خمس دقائق. لكن هذه العروض تنتهي عند الـcommit. فالـPR لا يشير إلى الـissue الذي كان يفترض أن يعالجه. وCI/CD pipeline يفشل لأن الوكيل لم يعلم بقاعدة linter جديدة. وفحص الأمان يعترض على تبعية أضافها الوكيل دون أن يتحقق من القائمة المعتمدة في المؤسسة. هذه إخفاقات سياقية، وهي التي تحدد ما إذا كانت البرمجة بالذكاء الاصطناعي ستسرّع التسليم أم ستخلق أعمال إعادة إنجاز.

ثلاثة مستويات من السياق

نشرت GitLab دليلًا تعليميًا مع Claude Code وآخر مع Codex، ويُظهران النمط نفسه: ماذا يتغير حين يحصل وكيل الذكاء الاصطناعي على قدر أكبر من سياق المنصة.

المستوى 1: شيفرة المستودع فقط. توجّه الوكيل إلى قاعدة الشيفرة وتصف له المشكلة. يقرأ الوكيل الملفات، ويقترح إصلاحًا، ويشغّل البناء. تعمل الشيفرة محليًا، لكن في فراغ. فالوكيل لا يرى acceptance criteria من الـissue، ولا يعرف المتطلبات غير الوظيفية، ولم يقرأ معايير الأسلوب من إعدادات CI.

المستوى 2: شيفرة المستودع + GitLab issue. عند ربط GitLab MCP server، يستطيع الوكيل قراءة الـissue قبل كتابة الشيفرة. تصبح المتطلبات وملاحظات التنفيذ والـlabels والـmilestones مرئية له. يضيف الوكيل `Closes #32` إلى وصف الـMR لأنه يفهم العلاقة بين التغيير والـissue. ويستخدم `get_issue` و`create_merge_request` مع المراجع الصحيحة. وهذه المرة يتطابق الإصلاح مع خطة الفريق.

المستوى 3: الوكيل يعمل داخل merge request. يترك GitLab Code Review Flow ملاحظات تلقائيًا. ويُستدعى الوكيل بوصفه مراجعًا خارجيًا لمعالجة الملاحظات:

• يضيف الاختبارات الناقصة
• يحدّث التوثيق
• يسدّ ثغرات التحقق من الصحة
• يرسل التغييرات مباشرة إلى فرع الـMR

ثم يتحقق الـpipeline من الـcommit الجديد. ويرى المراجع البشري النتيجة في أداة واحدة، دون تنقل بين الأدوات. والنتيجة: جولات مراجعة أقل ودمج أسرع.

السياق أشد أهمية في الأمان

ينتج مبرمجو الذكاء الاصطناعي الشيفرة بسرعة. وكلما زادت الشيفرة، زادت الثغرات المحتملة، وزادت نتائج الماسحات (scanners)، وزادت طلبات fix MR التي تحتاج إلى مراجعة. في السابق كان عنق الزجاجة في جانب الأمان: فحص، ثم ترتيب النتائج حسب الأولوية، ثم تصعيد الحرجة منها، ثم انتظار الإصلاحات. أما الآن فقد انتقل عنق الزجاجة. إذ ينتقل سير العمل من سؤال «أي ثغرة تُصلَح أولًا» إلى سؤال «أي fix MR مولَّد بالذكاء الاصطناعي يُراجَع أولًا».

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

تحلل طبقة الأمان في GitLab النتائج بالاعتماد على سياق المشروع الكامل، وتستبعد الإيجابيات الكاذبة، وتضع علامة على الثغرات المؤكدة. وعند تأكيد الثغرة، ينشئ agentic SAST resolution تلقائيًا MR يتضمن الإصلاح. ثم يتحقق الـpipeline منه، ويوافق عليه المراجع. وتبقى الحوكمة سليمة.

كيف تبدأ

استثمر في AGENTS.md، وهو ملف تعليمات مخصصة. وثّق فيه كيف يعمل المستودع، وما الأوامر التي تُشغَّل، وما التوقعات المتعلقة بالجودة. إنه استثمار لمرة واحدة يؤتي ثماره في كل جلسة وكيل.

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

تأكد من أن جميع المشاريع تُفحَص بأدوات الأمان. وفعّل Security Configuration Profiles على مستوى المجموعة (group level).

ماذا يعني ذلك

يعمل مبرمجو الذكاء الاصطناعي بموثوقية فقط حين توفر لهم المنصة السياق وتضمن أن المخرجات تمر عبر بوابات الجودة (quality gates). والعروض التجريبية التي تستغرق خمس دقائق وتجري في فراغ لا تعكس واقع بيئة الإنتاج. أما المؤسسات التي تنظّم السياق عبر issue tracker وpipeline وsecurity policy ومعايير مراجعة الشيفرة، فستحصل على ميزة تنافسية.