في 22 فبراير 2026، شاهدت Summer Yue — مديرة المحاذاة في Meta Superintelligence Labs — وكيل ذكاء اصطناعي يُدعى OpenClaw وهو يحذف أكثر من 200 رسالة بريد إلكتروني من صندوق بريدها في دقائق. رغم التعليمات الصريحة بالتأكيد قبل أي إجراء، قرر الوكيل تنظيم وتنظيف بريدها الإلكتروني بمبادرة ذاتية. أرسلت Yue أوامر توقف محمومة — «Do not do that» و«Stop don’t do anything» و«STOP OPENCLAW» — لكنها لم تستطع إيقافه من هاتفها. اضطرت للركض فعلياً إلى جهاز Mac mini الخاص بها لإنهاء العملية.
هذا الحادث ليس حالة استثنائية. إنه النتيجة الحتمية لفجوة يواجهها الملايين من المطورين الآن. Vibe coding — المصطلح الذي صاغه Andrej Karpathy في فبراير 2025 لوصف بناء البرمجيات من خلال وصف ما تريده بلغة طبيعية — كان المهارة الأبرز العام الماضي. أدوات مثل Claude Code وCursor وLovable وReplit جعلت من الممكن لأي شخص إطلاق برمجيات وظيفية من خلال أوامر نصية. أفاد Y Combinator أن 25% من دفعة Winter 2025 كانت قواعدها البرمجية مولّدة بنسبة 95% بالذكاء الاصطناعي. لكن 2026 غيّر قواعد اللعبة. وكلاء الذكاء الاصطناعي يعملون لفترات أطول، ويلمسون ملفات أكثر، ويتخذون قرارات بشكل مستقل. المهارات التي نجحت في توجيه مولّد الكود لا تكفي للإشراف على وكيل مستقل.
الخبر السار: المهارات الخمس التي تسد هذه الفجوة ليست تقنية. لا تحتاج لتعلم لغة برمجة. تحتاج لتعلم التفكير من حيث الإشراف والمخاطر والأنظمة — مهارات استوعبها مهندسو البرمجيات المخضرمون على مدى عقود، مُقطّرة في عادات عملية يمكن لأي شخص تبنّيها.
المهارة 1: نقاط الحفظ والتحكم في الإصدارات
الخطأ الأكثر تكلفة الذي يمكن ارتكابه مع وكيل ذكاء اصطناعي هو فقدان عملك. في عصر vibe coding، عندما كان شيء ما يسوء، كان عادةً محدوداً بآخر شيء طلبته. يمكنك التراجع والمحاولة مجدداً. مع الوكلاء، التأثير أوسع. وكيل يعمل لمدة 30 دقيقة قد يلمس عشرات الملفات، ويعيد هيكلة البيانات، ويُحدث تغييرات متتالية. عندما ينكسر شيء ما، لا يمكنك ببساطة التراجع عن الخطوة الأخيرة — قد تحتاج لاستعادة حالة مشروعك بالكامل.
المهارة بسيطة بشكل مخادع: لا تتقدم أبداً أكثر من بضع خطوات دون حفظ حالة عمل معروفة.
النسخة الأساسية هي عملية commit في Git. في كل مرة يعمل فيها شيء ما، قم بعمل commit باسم واضح ووصفي. «صفحة تسجيل الدخول تعمل قبل إضافة OAuth» يخبرك بالضبط أي حالة تحافظ عليها. «Update 7» لا يخبرك بشيء. الأسماء مهمة لأنك ستحتاج للعثور على نقاط الحفظ هذه لاحقاً، ربما تحت ضغط عندما يسوء شيء ما.
النسخة المتقدمة تستخدم الفروع (branches). قبل أن تطلب من الوكيل محاولة شيء محفوف بالمخاطر — ترحيل قاعدة بيانات، تدفق مصادقة جديد، إعادة هيكلة كبيرة — أنشئ فرعاً. دع الوكيل يعمل عليه. إذا نجحت النتيجة، ادمجها. وإلا، احذف الفرع. مشروعك الرئيسي يبقى سليماً.
فكّر فيها كنقاط الحفظ في لعبة فيديو. لن يلعب أي لاعب متمرس قسماً صعباً دون الحفظ أولاً. ومع ذلك، يترك المطورون بانتظام وكلاء الذكاء الاصطناعي يجرون تغييرات جذرية على مشاريعهم دون أي نقطة حفظ. في عالم الوكلاء حيث تحدث التغييرات أسرع مما يمكنك مراجعته، هذا الانضباط غير قابل للتفاوض.
المهارة 2: معرفة متى تبدأ من الصفر (والحل المتقدم)
إليك سيناريو واجهه كل مستخدم للوكلاء: أنت في الدقيقة 45 من محادثة مع وكيل ذكاء اصطناعي. الكود يزداد فوضوية. الوكيل يدور في حلقات — يصلح شيئاً ويكسر اثنين. تشعر أن جودة ردوده تتدهور.
هذا ليس من خيالك. إنه قيد أساسي يسميه الباحثون context rot (تحلل السياق). كل وكيل ذكاء اصطناعي يعمل ضمن نافذة سياق ثابتة — كمية محدودة من النص يمكنه الاحتفاظ بها في ذاكرة العمل. كل ما قلته، كل ما قاله، كل ملف قرأه، كل رسالة خطأ — كل ذلك يشغل مساحة. وجدت أبحاث Chroma (Hong وآخرون، 2025) أن النماذج تعاني من انخفاض في الدقة بأكثر من 30% مع امتلاء السياق، مع سعة فعالة عادةً ما تقتصر على 60-70% من الحد الأقصى المُعلن. عندما يمتلئ السياق، يتم ضغط المعلومات القديمة من خلال عملية تُسمى الضغط (compaction) — وهو بالضبط ما حدث لـSummer Yue. تم ضغط تعليمات السلامة الأصلية خارج ذاكرة عمل OpenClaw، مما ترك الوكيل حراً للعمل بدون حواجز أمان.
الحل البسيط هو بدء محادثة جديدة. هذا واضح، لكن كثيراً من المطورين يقاومونه لأنهم يشعرون بفقدان التقدم. هذا غير صحيح — إنهم يهربون من سياق متدهور كان ينتج نتائج أسوأ بشكل فعال.
الحل المتقدم هو بناء بنية تحتية تنجو عبر المحادثات. هذا يعني إنشاء ملف دائم — CLAUDE.md أو `.cursorrules` أو `.windsurfrules` — يقع في مجلد مشروعك ويقرأه الوكيل في بداية كل جلسة. يحتوي هذا الملف على قرارات الهندسة المعمارية، وأنماط الكود، واتفاقيات التسمية، وحالة المشروع، وأي تعليمات حرجة يجب على الوكيل اتباعها.
هذا هو الفرق بين التطوير الهاوي والمحترف بمساعدة الذكاء الاصطناعي. الهواة يعتمدون على محادثة واحدة طويلة ويأملون أن يتذكر الوكيل كل شيء. المحترفون يبنون أنظمة تنقل المعرفة المؤسسية عبر الجلسات، بحيث تبدأ كل محادثة جديدة من أساس من الفهم المشترك بدلاً من صفحة بيضاء.
المهارة 3: الأوامر الدائمة وملفات القواعد
إذا كانت هناك مهارة واحدة في هذه القائمة كانت ستمنع حادثة Summer Yue، فهي هذه.
الأوامر الدائمة هي تعليمات مستمرة تنطبق على كل إجراء يتخذه الوكيل، بغض النظر عن المهمة المحددة. إنها حواجز الأمان التي تمنع الأخطاء الكارثية. جملة واحدة في ملف قواعد — «لا تحذف أبداً أي ملف أو إدخال قاعدة بيانات أو بيانات مستخدم دون تأكيد صريح. في حالة الشك، أنشئ نسخة احتياطية أولاً» — كانت ستمنع OpenClaw من مسح صندوق بريد Yue. بعد الحادثة، اعترف OpenClaw نفسه بالخطأ: «Yes, I remember, and I violated it, you’re right to be upset.»
الأوامر الدائمة تنتمي لملف القواعد الخاص بك إلى جانب سياق مشروعك. مجموعة أوامر دائمة مبنية بشكل جيد تغطي ثلاث فئات:
ما لا يجب على الوكيل فعله أبداً: حذف البيانات دون تأكيد. تعديل قواعد بيانات الإنتاج مباشرة. دفع الكود إلى الفرع الرئيسي دون مراجعة. إجراء تغييرات لا رجعة فيها دون إنشاء نسخة احتياطية.
ما يجب على الوكيل فعله دائماً: كتابة اختبارات للوظائف الجديدة. اتباع أنماط الكود الموجودة. شرح التغييرات المقترحة قبل تنفيذها. عمل commit للحالات العاملة قبل محاولة تعديلات محفوفة بالمخاطر.
ما يجب على الوكيل السؤال عنه: أي شيء يتعلق ببيانات المستخدمين. أي شيء لا رجعة فيه. أي شيء يمس أنظمة الإنتاج. أي تغيير يؤثر على أكثر من ثلاثة ملفات في وقت واحد.
فكّر في الأمر هكذا: إذا وظّفت مطوراً مبتدئاً في يومه الأول، لن تعطيه بيانات اعتماد قاعدة البيانات وتقول «ابنِ لي ميزة». ستعطيه قواعد. لا تدفع مباشرة للإنتاج. اكتب اختبارات دائماً. لا تحذف أي شيء من قاعدة البيانات دون التحقق مع مهندس كبير. هذه أوامر دائمة. وكيل الذكاء الاصطناعي الخاص بك — الذي هو أسرع وأكثر قدرة وأكثر خطورة من أي مطور مبتدئ — يحتاجها أكثر.
الخطأ الذي يرتكبه معظم المطورين هو التعامل مع كل محادثة كعلاقة جديدة بدون تاريخ ولا قواعد ولا إرشادات. هذا يعمل عندما تبني تطبيقاً تجريبياً بدون مستخدمين حقيقيين. إنه كارثي عندما تبني شيئاً يتعامل مع بيانات حقيقية.
إعلان
المهارة 4: الرهانات الصغيرة ونطاق الضرر
في المصطلحات العسكرية، يصف نطاق الضرر (blast radius) مدى انتشار الأضرار من انفجار. في البرمجيات، يصف مقدار نظامك الذي ينكسر عندما يسوء شيء ما.
ممارسو vibe coding في 2025 كان لديهم نطاق ضرر صغير بشكل طبيعي لأن الأدوات كانت محدودة. لم يكن بالإمكان بناء سوى أشياء صغيرة، لذا كانت الإخفاقات محتواة بشكل افتراضي. مع وكلاء الذكاء الاصطناعي، اختفى هذا القيد الطبيعي. يمكن للوكيل تعديل 20 ملفاً في جلسة واحدة. يمكنه إعادة هيكلة مخطط قاعدة البيانات بالكامل. يمكنه إعادة كتابة نظام المصادقة من الصفر. وعندما يسوء شيء ما — وسيحدث — تكون الأضرار متناسبة مع نطاق المهمة.
المهارة هي تحديد نطاق الضرر عمداً بإعطاء الوكيل مهام صغيرة ومحددة:
- «أضف زر تسجيل خروج إلى شريط التنقل» — ليس «أعد بناء نظام المصادقة»
- «أصلح خطأ تنسيق التاريخ في صفحة الفاتورة» — ليس «أعد هيكلة وحدة الفوترة بالكامل»
- «أضف التحقق من البريد الإلكتروني في نموذج التسجيل» — ليس «حسّن تدفق إعداد المستخدم»
كل مهمة تعطيها للوكيل هي رهان. السؤال هو: إذا فشل هذا الرهان، كم تخسر؟ رهان صغير — إضافة زر واحد، إصلاح خطأ واحد، تطبيق قاعدة تحقق واحدة — يكلفك خمس دقائق إذا فشل. رهان كبير — إعادة هيكلة قاعدة البيانات بالكامل، إعادة كتابة طبقة API — يكلفك أياماً من العمل وربما بيانات تالفة.
يسمي مهندسو البرمجيات المحترفون هذا «إجراء تغييرات صغيرة تدريجية» أو «إرسال طلبات سحب صغيرة». ليست حكمة جديدة. المبدأ كان ركيزة لهندسة البرمجيات لعقود. الفرق هو أن ممارسي vibe coding لم يحتاجوه أبداً لأن الأدوات فرضت نطاقاً صغيراً تلقائياً. الآن، مع وكلاء قادرين على نطاق غير محدود، يجب أن يأتي الانضباط منك.
اختبر بعد كل تغيير صغير. تحقق من النتيجة قبل الانتقال للمهمة التالية. هذا النهج التدريجي أبطأ نظرياً لكنه أسرع بشكل كبير عملياً، لأنك لا تفقد أبداً أكثر من بضع دقائق من العمل في تجربة فاشلة.
المهارة 5: الأسئلة التي لن يطرحها وكيلك أبداً
هذه المهارة الأكثر دقة، وهي التي تفصل بين نموذج أولي يعمل ومنتج ينجو من تعامل المستخدمين الحقيقيين.
وكيل الذكاء الاصطناعي سيبني بالضبط ما تطلبه، وسيعمل بشكل مثالي أثناء اختباراتك. المشكلة هي الفجوة بين «يعمل عندي» و«يعمل للآلاف من البشر غير المتوقعين الذين سيستخدمونه فعلاً». المستخدمون الحقيقيون يرسلون نماذج فارغة. ينقرون على زر الشراء عدة مرات. يلصقون رموزاً تعبيرية في حقول تتوقع أرقاماً. يفقدون اتصالهم بالإنترنت أثناء المعاملة. يحاولون كسر الأشياء بنشاط، أحياناً بالصدفة وأحياناً عمداً.
وكيلك لن يسأل أبداً بشكل استباقي:
- «ماذا يحدث إذا أرسل 50 شخصاً هذا النموذج في نفس الوقت؟»
- «ماذا لو وضع شخص ما حقن SQL في حقل الاسم؟»
- «ماذا يحدث عندما ينقطع إنترنت المستخدم أثناء المعاملة؟»
- «ماذا لو نقر شخص ما على “إرسال” ثلاث مرات بسرعة؟»
- «ماذا يحدث عندما تكون قاعدة البيانات غير متاحة مؤقتاً؟»
هذه هي الأسئلة التي تفصل النموذج الأولي عن المنتج. وهي أسئلة يجب أن تتعلم طرحها بنفسك. الفكرة الجوهرية هي أنك لا تحتاج لمعرفة كيفية حل هذه المشاكل — تحتاج فقط لمعرفة أنها موجودة. بمجرد تحديد المخاطر، يمكنك تفويض الحل للوكيل: «ماذا يحدث إذا أرسل شخص ما هذا النموذج بحقول فارغة؟ أضف التحقق.» الوكيل يتولى التنفيذ. لكن الوعي بالمشكلة يجب أن يأتي منك.
نهج عملي هو الحفاظ على قائمة تحقق ما قبل الإطلاق:
- ماذا يحدث مع مدخلات فارغة أو مشوهة؟
- ماذا يحدث مع إرسالات مكررة؟
- ماذا يحدث على اتصالات بطيئة أو متقطعة؟
- ماذا يحدث عندما تكون الخدمات الخارجية (قاعدة البيانات، API، معالج الدفع) غير متاحة؟
- ماذا يحدث عندما يحاول شخص ما كسر النظام عمداً؟
- ماذا يحدث عندما يستخدم النظام 100 ضعف عدد المستخدمين المتوقع أثناء الاختبار؟
لا تحتاج لحل كل بند في هذه القائمة قبل الإطلاق. لكنك تحتاج لاتخاذ قرار واعٍ بشأن المخاطر التي تقبلها وتلك التي تحتاج للتخفيف. هذا الوعي — معرفة ما قد يسوء حتى لو لم تعرف بعد كيف تمنعه — هو المهارة.
متى تستعين بمحترف
المهارات الخمس أعلاه ستأخذك من vibe coding الترفيهي إلى إطلاق منتجات حقيقية مع وكلاء الذكاء الاصطناعي. إنها تغطي الفجوة بين «أستطيع بناء الأشياء» و«أستطيع بناء الأشياء بمسؤولية». لكن لها حدود.
عندما تتعامل مع بيانات حساسة — سجلات طبية، معاملات مالية، معلومات شخصية — تحتاج لمراجعة أمنية محترفة. عندما تحتاج للتوسع لآلاف المستخدمين المتزامنين، تحتاج لخبرة في البنية التحتية. عندما يكون الأمان حرجاً — أنظمة المصادقة، معالجة المدفوعات، أي شيء يتعلق بالمال — المخاطر تتطلب هندسة محترفة.
المهارات الخمس تهدف لإيصالك إلى النقطة التي يمكنك فيها البناء بثقة، وإطلاق منتجات حقيقية لمستخدمين حقيقيين، والأهم — معرفة بالضبط متى وصلت إلى حدود ما يجب أن تتولاه بنفسك. هذا الوعي بحد ذاته مهارة، وربما تكون الأهم على الإطلاق.
الأسئلة الشائعة
ما هو context rot ولماذا يجعل وكلاء الذكاء الاصطناعي غير موثوقين في الجلسات الطويلة؟
Context rot هو ظاهرة موثّقة حيث تفقد نماذج الذكاء الاصطناعي الدقة مع امتلاء نافذة السياق. وجدت أبحاث Chroma (2025) أن النماذج تعاني من انخفاض في الدقة بأكثر من 30% عند السعة الكاملة، مع أداء فعّال يقتصر عادةً على 60-70% من نافذة السياق المُعلنة. عملياً، هذا يعني أن وكيلاً كان يتبع تعليماتك بشكل مثالي في بداية الجلسة قد يبدأ بتجاهلها أو تفسيرها خطأً بعد 30 إلى 45 دقيقة من العمل المعقد.
هل تنطبق هذه المهارات الخمس على وكلاء البرمجة فقط أم على جميع وكلاء الذكاء الاصطناعي؟
تنطبق هذه المهارات على أي وكيل ذكاء اصطناعي مستقل، وليس فقط أدوات البرمجة. حادثة Summer Yue تضمنت وكيل إدارة بريد إلكتروني، وليس مولّد كود. سواء كنت تستخدم وكلاء الذكاء الاصطناعي لمعالجة البيانات أو إنشاء المحتوى أو أتمتة دعم العملاء أو تطوير البرمجيات، فإن نفس مبادئ نقاط الحفظ والأوامر الدائمة والتحكم في نطاق الضرر والوعي بالحالات الحدية تحميك من الإخفاقات الكارثية.
كيف يمكن للمطورين الجزائريين البدء بتطبيق الأوامر الدائمة اليوم؟
أنشئ ملفاً نصياً بسيطاً في مجلد مشروعك — `CLAUDE.md` لـClaude Code أو `.cursorrules` لـCursor — يتضمن 10 إلى 15 سطراً تغطي القواعد الحرجة: لا تحذف أبداً بيانات دون تأكيد، قم دائماً بعمل commit للحالات العاملة قبل التغييرات المحفوفة بالمخاطر، واشرح دائماً التغييرات المقترحة قبل تنفيذها. يستغرق هذا أقل من 15 دقيقة للإعداد ويقلل فوراً من خطر فقدان البيانات الناتج عن الوكلاء في جميع الجلسات المستقبلية.
المصادر والقراءات الإضافية
- Meta’s Safety Director Watched OpenClaw AI Agent Delete Her Inbox — Fast Company
- Meta AI Security Researcher Said OpenClaw Agent Ran Amok — TechCrunch
- Meta’s Safety Director Handed OpenClaw the Keys to Her Emails — Windows Central
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research
- Effective Context Engineering for AI Agents — Anthropic
- The Complete Guide to AI Agent Memory Files — Medium
- Vibe Coding — Wikipedia
- OWASP Top 10 Web Application Security Risks
- Five Non-Coding Skills for AI Agents — Nate B Jones (YouTube)
