السرعة ليست المشكلة… المشكلة في ما لا تراه
في 2026 لم يبقَ مطوّر عربي تقريباً لم يجرّب وكيل برمجة ذكياً يكتب له ملفاً كاملاً أو يصلح خطأً في ثوانٍ. المكسب في السرعة حقيقي ولا جدال فيه، لكن المشكلة الحقيقية ظهرت في الطرف الآخر من المعادلة: من يراجع كل هذا الكود؟ المطوّر الذي كان يكتب 100 سطر في اليوم أصبح اليوم مسؤولاً عن مراجعة 1000 سطر لم يكتبها بنفسه، وهذا تحوّل في طبيعة العمل لا في حجمه فقط.
الأخطر أن الاعتماد على أدوات المراجعة الآلية وحدها يمنح شعوراً زائفاً بالأمان. في دراسة أكاديمية حديثة (arXiv 2509.13650) اختبر الباحثون أداة مراجعة كود مدعومة بالذكاء الاصطناعي على سبع مجموعات بيانات تحتوي ثغرات أمنية موثّقة، وكانت النتيجة صادمة: على مشروع Wireshark المكتوب بلغة C، مرّت الأداة على 878 ملفاً من أصل 898 دون أن تُخرج تعليقاً واحداً، رغم وجود 127 ثغرة أمنية موثّقة في الكود. وفي مجموعة اختبارات حقن SQL، اكتفت الأداة بالإشارة إلى أخطاء إملائية. السبب الهندسي واضح: هذه الأدوات تفتقر إلى التحليل الدلالي العميق الذي يتبع المؤشرات وحدود المصفوفات ومسار التحكم بين الدوال، وهي تحديداً مواضع الثغرات الخطيرة.
الخلاصة العملية ليست "توقّف عن استخدام الوكلاء"، بل "لا تستخدمهم بخطوة واحدة". الحل هو دورة عمل من ثلاث مراحل، لكل مرحلة برومبت متخصص، وكلها موجودة على شبّيك.
المرحلة الأولى: لا تطلب كوداً قبل أن تكتب مواصفة
أكبر سبب لفشل وكلاء البرمجة ليس ضعف الموديل، بل غموض الطلب. عندما تكتب "أضف تسجيل دخول للمستخدمين"، فأنت تترك للوكيل أن يخترع عشرين قراراً نيابةً عنك: أي طريقة تشفير، أين تُخزَّن الجلسة، ماذا يحدث عند فشل المحاولة خمس مرات، وهل البريد الإلكتروني حساس لحالة الأحرف. ثم تُمضي ساعة في تصحيح افتراضاته بدلاً من نصف ساعة في كتابة الطلب بدقة من البداية.
هذا ما يسمّيه مجتمع المطوّرين اليوم "التطوير المدفوع بالمواصفات" (Spec-Driven Development)، وهو التوجّه السائد في أدوات 2026. برومبت مهندس مواصفات المهام لوكلاء البرمجة الذكية يقوم بهذه المرحلة: تعطيه وصفاً عامياً لما تريد، فيخرج لك مواصفة مهمة منظّمة فيها النطاق، المدخلات والمخرجات، الحالات الحدّية، معايير القبول، وما يجب على الوكيل ألّا يلمسه. تنسخ هذه المواصفة وتضعها في الوكيل، فتنتقل من "خمّن ما أريد" إلى "نفّذ ما هو مكتوب".
ابدأ من هنا: مهندس مواصفات المهام لوكلاء البرمجة الذكية
المرحلة الثانية: مراجعة هندسية قبل المراجعة الأمنية
بعد أن يُخرج الوكيل الكود، لا تقفز مباشرة إلى سؤال "هل هو آمن؟". هناك طبقة أسبق وأكثر إلحاحاً: هل هذا الكود صحيح وقابل للصيانة أصلاً؟ الكود المولّد غالباً يعمل في الحالة السعيدة فقط، ويخفي مشكلات في معالجة الأخطاء، وتعقيداً زمنياً غير ضروري، وتكراراً للمنطق في ثلاثة أماكن، وأسماء متغيّرات لا تعني شيئاً لمن سيقرأ الملف بعد ستة أشهر.
برومبت مراجع كود Python متقدم يملأ هذه الفجوة. يقرأ الكود ويعطيك مراجعة مرتّبة بحسب الأهمية: أخطاء منطقية حقيقية، ثم مشكلات الأداء، ثم مخالفات الأسلوب والتوثيق، مع اقتراح بديل لكل ملاحظة لا مجرّد انتقاد. هذه هي المرحلة التي تحوّل الكود المولّد من "شيء يعمل" إلى "شيء يمكن أن يبقى في المشروع".
راجع كودك هنا: مراجع كود Python متقدم
مراجع كود Python متقدم
حوّل Claude أو ChatGPT إلى مراجع كود Python محترف يحلل الأداء والأمان والنمط.
المرحلة الثالثة: التدقيق الأمني هو خط الدفاع الذي لا يُختصر
هنا نعود إلى نتيجة الدراسة التي بدأنا بها. الثغرات التي تهرب من الأدوات الآلية هي تلك التي تمتدّ بين الدوال والملفات: مدخل غير موثوق يصل إلى استعلام قاعدة بيانات بعد ثلاث طبقات، أو صلاحية تُفحص في مكان وتُستخدم في مكان آخر، أو سرّ يُكتب في الملف بدلاً من متغيّرات البيئة. الوكيل لا يكتب هذه الأخطاء بسوء نيّة، بل لأنه يرى جزءاً من السياق فقط.
برومبت مدقّق أمني للكود المولّد بالذكاء الاصطناعي مصمّم تحديداً لهذا السيناريو: مراجعة أمنية موجّهة للكود الذي كتبه وكيل ذكي، تبحث عن حقن الاستعلامات، التحقّق الناقص من المدخلات، أخطاء الصلاحيات، تسريب الأسرار، والتبعيات غير الآمنة، وتُخرج لك قائمة مصنّفة بالخطورة مع خطوة إصلاح لكل بند. اجعل هذه المرحلة إلزامية قبل أي دمج (merge)، لا خياراً إضافياً عند توفّر الوقت.
دقّق كودك أمنياً: مدقّق أمني للكود المولّد بالذكاء الاصطناعي
الخطوة المكمّلة: ملف AGENTS.md في جذر مشروعك
الدورة الثلاثية أعلاه تعالج كل مهمة على حدة، لكن هناك طبقة تُوفّر عليك تكرار نفس التعليمات في كل مرة: ملف AGENTS.md في جذر المستودع. صار هذا الملف معياراً فعلياً في 2026، ووظيفته أن يعطي الوكيل السياق الذي لا يستطيع استنتاجه من الكود وحده.
ضع فيه ستة أقسام فقط: المكدّس التقني بإصدارات محدّدة (pnpm لا npm مثلاً)، الأوامر القابلة للتنفيذ (التثبيت، الاختبار، الفحص، البناء) كاملة كما تُكتب في الطرفية، مثال كود واحد يمثّل أسلوبك خصوصاً في الأنماط غير البديهية، قواعد الاختبار ومتطلّبات الحتمية، حدود الصلاحيات في ثلاث طبقات (مسموح دائماً / اسأل أولاً / ممنوع تماماً مثل الأسرار و force push)، وأخيراً الأدوات غير القياسية الموجودة في مشروعك والتي لا يعرفها الوكيل مسبقاً.
وقاعدتان مهمّتان من تجربة الفرق: ابقِ الملف تحت 200 سطر لأن كل سطر يُستهلك من نافذة السياق في كل مهمة، واحذف النظرة المعمارية العامة — لم يثبت أنها تحسّن نتائج المهام، وتصبح مضلّلة حين يتغيّر المشروع ولا يُحدّث الملف. تعامل مع AGENTS.md كما تتعامل مع الكود: تحت إدارة الإصدارات، ويُحدَّث في نفس الـ PR الذي يغيّر الأوامر أو الاعتماديات.
كيف تطبّق الدورة كاملة في عشر دقائق
ابدأ بمهمة صغيرة حقيقية من مشروعك الحالي، لا بمثال تجريبي. افتح برومبت مهندس المواصفات، الصق وصفك العامي للمهمة، واحصل على المواصفة. أعطِ المواصفة لوكيلك البرمجي (ChatGPT أو Claude أو الوكيل المدمج في محرّرك) واطلب التنفيذ ضمن نطاقها فقط. خذ الكود الناتج وضعه في برومبت مراجع الكود، طبّق ما تقتنع به من ملاحظاته، ثم خذ النسخة المعدّلة إلى برومبت المدقّق الأمني قبل الدمج.
ثلاث نصائح تفرق كثيراً في النتيجة: أولاً، لا تمرّر ملفاً كاملاً بآلاف الأسطر إلى المراجعة — قسّمه إلى وحدات منطقية لأن دقّة المراجعة تنخفض مع طول المدخل. ثانياً، أرفق مع الكود سياقه: ما مصدر المدخلات، ومن يستدعي هذه الدالة، وهل هي معرّضة للإنترنت مباشرة؛ فالمراجعة الأمنية بلا سياق تخميناً. ثالثاً، احتفظ بمواصفة المهمة في وصف الـ PR — ستجد أنها أفضل توثيق ممكن لقرار اتخذته قبل شهرين.
جرّب وشاركنا النتيجة
الفرق بين فريق يستفيد من وكلاء البرمجة وفريق يتراكم عليه الدين التقني ليس في الموديل الذي يستخدمه، بل في وجود دورة عمل مكتوبة يمشي عليها الجميع. هذه البرومبتات الثلاثة تعمل مع ChatGPT وClaude وGemini، ويمكنك تثبيتها كخطوات قياسية في فريقك اليوم.
طبّقها على مهمة واحدة هذا الأسبوع، ثم أخبرنا: ما أغرب ملاحظة خرجت لك من مرحلة التدقيق الأمني ولم تكن تتوقّعها؟ تجاربكم هي ما يصنع المحتوى القادم على شبّيك.