مقدمة: المشكلة الخفية في البرمجة بمساعدة الذكاء الاصطناعي
أدوات البرمجة بالذكاء الاصطناعي مثل GitHub Copilot وCursor وClaude Code تنتج كودًا نظيفًا في المشاريع الصغيرة الجديدة (Greenfield)، لكنها تتراجع بسرعة في قواعد الكود الكبيرة والقديمة (Brownfield) — لأنها تفتقر للسياق المحيط الذي يستخدمه مهندس خبير لاتخاذ القرار نفسه. الحل هو إطار عمل RPI: ابحث (Research) في قاعدة الكود أولًا، ثم خطّط (Plan) للتغيير صراحةً، ثم نفّذ (Implement) وفق تلك الخطة، بدلًا من ترك النموذج يخمّن أثناء التوليد.
يُبلّغ كثير من المطورين أنه رغم ازدياد سرعة تسليم الكود، يُنفَق جزء كبير من وقتهم في إصلاح كود سيء كتبه الذكاء الاصطناعي الأسبوع الماضي. هذا الكود منخفض الجودة، المعروف في مجتمع المطورين بـ«Slop»، يمكن أن يخلق دَينًا تقنيًا كبيرًا.
في هذا المقال، ستتعرف على نهج علمي وعملي يُدعى هندسة السياق (Context Engineering) وإطار عمل RPI الذي يساعدك على حل مشكلات معقدة في الكود القديم دون إنتاج Slop.
ما هي هندسة السياق؟
لفهم هندسة السياق، نحتاج أولاً لفهم كيف تعمل النماذج اللغوية الكبيرة (LLMs).
الطبيعة عديمة الحالة للنماذج اللغوية
النماذج اللغوية عديمة الحالة. هذا يعني أنها لا تملك ذاكرة للمحادثات السابقة، والشيء الوحيد الذي يحدد المخرجات هو الرموز المُدخَلة (tokens). كل ما تضعه في نافذة السياق يؤثر مباشرة على جودة الاستجابة.
مفهوم «المنطقة الغبية»
عمليًا، ينخفض أداء النموذج بشكل ملحوظ عندما تُملأ نافذة السياق بأكثر من نحو 40 بالمئة؛ ويوصي دليل هندسة السياق من HumanLayer بإبقاء الاستخدام ضمن نطاق 40–60%. يسمّي Dex Horthy من HumanLayer هذه الظاهرة «المنطقة الغبية».
تشبيه المكتب الفوضوي: فكّر في المنطقة الغبية كمكتب فوضوي. عندما يمتلئ مكتبك بأوراق مبعثرة، وملاحظات قديمة، وأدوات غير ضرورية، يصبح إيجاد ما تحتاجه فعليًا صعبًا وتنخفض جودة عملك. تعمل نافذة سياق الذكاء الاصطناعي بنفس الطريقة تمامًا.
الحل: الضغط الذكي
الحل هو الضغط الذكي (Smart Compaction). بدلاً من تراكم المعلومات في السياق عشوائيًا، يجب أن:
- تلخّص تاريخ المحادثة بذكاء
- تُضمّن فقط الملفات ذات الصلة في السياق
- تزيل مخرجات JSON الطويلة، والسجلات، ونتائج الاختبار
- تستخدم وكلاء فرعيين (Sub-agents) لتلخيص المعلومات
إطار عمل RPI: حل عملي للبرمجة الخالية من Slop
لحل مشكلات معقدة في قواعد الكود القديمة، لا يجب أن تبدأ البرمجة فورًا. إطار عمل RPI سير عمل من ثلاث مراحل يمنع إنتاج Slop:
1. البحث (Research) - ضغط الحقيقة
في هذه المرحلة، الهدف هو فهم كامل للنظام وإيجاد الملفات الصحيحة. أنت لا تكتب كودًا بعد؛ أنت «تضغط الحقيقة».
تقنيات رئيسية:
- استخدم وكلاء فرعيين لقراءة أقسام كبيرة من الكود وإرجاع ملخصات مفيدة فقط
- حدّد بنية المشروع، وأنماطه المعمارية، وتبعياته
- افهم نقاط الدخول وتدفق البيانات
2. التخطيط (Plan) - ضغط النية
بعد فهم النظام، اكتب خطة تنفيذ مفصّلة. يجب أن تتضمن هذه الخطة:
- أسماء الملفات الدقيقة التي تحتاج للتغيير
- مقتطفات الكود الفعلية المُراد إضافتها أو تعديلها
- ترتيب التغييرات
- الاختبارات التي يجب كتابتها
تُسمّى هذه المرحلة «ضغط النية». خطة جيدة ومفصّلة تضمن ارتكاب حتى النماذج الأضعف أخطاء أقل لأن الغموض يُقلَّل.
3. التنفيذ (Implement) - الإنتاج النهائي للكود
فقط بعد إكمال المرحلتين السابقتين يجب أن تدخل مرحلة التنفيذ. في هذه المرحلة:
- نفّذ الخطة خطوة بخطوة
- تحقق من كل تغيير بالاختبارات ذات الصلة
- حافظ على نظافة السياق وأزل المعلومات غير الضرورية
RPI مقابل QRSPI: ما الذي تغيّر في 2026
في 2026 عاد ديكس هورثي إلى RPI في محاضرة بعنوان "كل ما أخطأنا فيه بشأن Research-Plan-Implement". حقق الخبراء نتائج جيدة بالنسخة الثلاثية، لكن فرقهم لم تحققها، وأرجع ذلك إلى سببين: البحث كان يعود مليئاً بالآراء لأن الوكيل يعرف الميزة المطلوب بناؤها، وموجّه التخطيط الواحد كان يضم أكثر من 85 تعليمة، بينما تتبع النماذج المتقدمة نحو 150 إلى 200 تعليمة بثبات بعد إضافة موجّه النظام والأدوات وتعريفات MCP، فكانت خطوات مثل نقاش التصميم تُتخطّى كثيراً.
سير العمل المعدّل، الذي يُلقّب "كريسبي" (QRSPI)، يقسّم العمل إلى مراحل أصغر، لا يتجاوز كل موجّه فيها 40 تعليمة:
- الأسئلة: تحويل التذكرة إلى أسئلة بحث في نافذة سياق واحدة.
- البحث: الإجابة عنها في نافذة جديدة لا ترى التذكرة، فيبقى الناتج حقائق فقط.
- نقاش التصميم: مستند من نحو 200 سطر يضم الوضع الحالي والوضع المطلوب والأنماط المتبعة والأسئلة المفتوحة، يراجعه المهندس.
- مخطط البنية: المراحل والتواقيع ونقاط الاختبار، "مثل ملف ترويسة في C"، على شكل شرائح عمودية لا كل أعمال قاعدة البيانات أولاً.
- الخطة وwork tree والتنفيذ وpull request: تُراجَع الخطة سريعاً، أما الكود نفسه فيُقرأ ويُراجَع.
النقطة الأخيرة تراجع صريح: يطلب هورثي الآن من الفرق المسؤولة عن أنظمة الإنتاج قراءة الكود، واستهداف تسريع من 2 إلى 3 أضعاف بجودة قريبة من عمل الإنسان بدلاً من إنتاج أكبر لم يتحقق منه أحد.
دور الإنسان: لا تُفوّض التفكير
أحد أكبر أخطاء المطورين هو الاعتقاد بأن الذكاء الاصطناعي يمكنه استبدال التفكير. هذا الافتراض خطير.
الذكاء الاصطناعي مُضخِّم، لا بديل
الذكاء الاصطناعي مُضخِّم لقدراتك، لا بديل عنها. أخطر شيء هو السماح للذكاء الاصطناعي بإنتاج كود دون مراجعة الخطة. هذا يعادل:
- السماح لمبرمج مبتدئ عديم الخبرة باتخاذ قرارات معمارية
- قبول أي اقتراح بشكل أعمى دون فهم العواقب
المواءمة الذهنية
مراجعة الإنسان للخطة تخلق «مواءمة ذهنية» في الفريق. عندما يراجع أحدهم خطة الذكاء الاصطناعي:
- تُكتشف الأخطاء المنطقية قبل البرمجة
- تزداد معرفة الفريق
- تُوثَّق القرارات المعمارية
ما يجب التركيز عليه
بدلاً من قراءة الكود المولَّد سطرًا بسطر، ركّز على مراجعة «البحث» و«الخطة». إذا كانت هاتان المرحلتان صحيحتين، فمن المرجح جدًا أن يكون الكود النهائي صحيحًا أيضًا.
إدارة نافذة السياق: ابقَ في المنطقة الذكية
للبرمجة الفعّالة بمساعدة الذكاء الاصطناعي، تحتاج لتتعلم البقاء في «المنطقة الذكية». هذا يعني:
القواعد الذهبية لإدارة السياق
- أقل من 40%: املأ دائمًا أقل من 40% من نافذة السياق
- الضغط المستمر: أزل المعلومات غير الضرورية بعد كل مرحلة
- الوكلاء الفرعيون: استخدمهم لقراءة الملفات الكبيرة
- التلخيص: لخّص تاريخ المحادثة دوريًا
حجم النموذج هو الرافعة الأخرى التي يلجأ إليها الناس، وليس دائمًا الخيار الصحيح: نموذج بـ27 مليون معامل تفوّق على نماذج أكبر بكثير في ARC-AGI لأنه يستدل عبر حلقات متكررة بدل التوسّع في الحجم.
الخاتمة: المستقبل للفرق القادرة على التكيّف
استخدام الذكاء الاصطناعي في البرمجة لم يعد خيارًا بل ضرورة تنافسية. لكن الفرق بين الفرق الناجحة والفرق الغارقة في الدَين التقني يكمن في كيفية استخدامه.
المستقبل للفرق التي:
- تتعلم إدارة السياق والبقاء في المنطقة الذكية
- تستخدم إطار عمل RPI (البحث، التخطيط، التنفيذ)
- لا تُفوّض التفكير وتراجع الخطط
- تُكيّف عملياتها مع أدوات تكتب الآن معظم الكود
بتطبيق مبادئ هندسة السياق وإطار عمل RPI، يمكنك الاستفادة من مزايا الذكاء الاصطناعي المذهلة دون الوقوع في فخ إنتاج كود منخفض الجودة.
يستند هذا المقال إلى تجارب عملية وأبحاث Dex Horthy من HumanLayer حول تحسين استخدام الذكاء الاصطناعي في تطوير البرمجيات.
الانضباط ذاته ينطبق خارج البرمجة: يحتاج الذكاء الاصطناعي العامل في دعم العملاء إلى الحواجز الوقائية ذاتها التي يفرضها RPI في قاعدة الكود — عملية محددة يجب على النموذج اتّباعها، لا حرية كاملة.
الأسئلة الشائعة
ماذا يعني RPI؟
Research وPlan وImplement (البحث، التخطيط، التنفيذ): سير عمل من ثلاث مراحل لوكلاء البرمجة بالذكاء الاصطناعي. يبحث الوكيل أولاً في كيفية عمل الكود المعني، ثم يكتب خطة صريحة للتغيير، وبعدها فقط ينفّذ، ويبدأ كل مرحلة بسياق جديد ومضغوط.
ما هي «Dumb Zone»؟
تسمية Dex Horthy من HumanLayer لتراجع أداء النموذج عندما تمتلئ نافذة السياق بأكثر من 40 بالمئة تقريباً. كالمكتب المزدحم، كلما زادت المواد غير المهمة في السياق ساءت النتيجة.
ما هو الضغط الذكي (Smart Compaction)؟
بدلاً من تكديس كل شيء في السياق: لخّص سجل المحادثة، وأدرج الملفات المهمة فقط، واحذف مخرجات JSON الطويلة والسجلات ونتائج الاختبارات، واستخدم وكلاء فرعيين لقراءة أجزاء الكود الكبيرة وتلخيصها.
ما الذي يراجعه الإنسان عندما يكتب وكيل الذكاء الاصطناعي الكود؟
مرحلتا البحث والخطة، لا قراءة الكود المولّد سطراً بسطر. إذا كانت المرحلتان صحيحتين فالأرجح أن يكون الكود النهائي صحيحاً، وتُكتشف الأخطاء المنطقية قبل كتابة أي كود.
