في موجة برمجة الذكاء الاصطناعي هذه، المفاهيم تتطاير في كل مكان، والأدوات تغيّر قشرتها كل يوم، لكن الأساس ليس بتلك “الغرائبية”.
Agent ليس سحراً؛ جوهره أنك تُلبِس الـ LLM غير المستقر طبقة من “قيود مُهيكلة” (Harness) لتجعل المخرجات أكثر قابلية للتحكم. Claude Code وCodex يسيران على هذا النهج.
1）افهم الـ LLM جيداً: إنه فقط يخمّن الـ Token التالي
عندما تفهم هذه النقطة، كثير من “المشاكل الغيبية” لن تعود غيبية.
كيف تُطعمه السياق يميل هناك؛ كيف تُوجّهه يسير إلى ذلك الاتجاه.
لذا انتقال الـ Prompt من “عبادة التنسيق” إلى “التعبير الطبيعي” أمر حتمي، لكن إتقان طرح الأسئلة يظل مهارة صلبة.
2）Prompt لم يصبح بلا فائدة، بل ينبغي أن يكون “توجيه أقل، وتغذية راجعة أكثر”
- لا تبدأ بحشو الحلول؛ اشرح الواقع والهدف أولاً ودع النموذج يعطيك زوايا نظر؛
- تكرار موجّه بالمشكلة: انظر للنتيجة → صحّح الخطأ → أعد كتابة التعليمات → تحقّق في محادثة جديدة؛
- تثبيت الكلمات المفتاحية بشكل صارم قد يسحب النموذج إلى حفرة.
الخلاصة: تحكّم أقل في المسار، وتحقّق أكثر من النتيجة.
3）AGENTS.md مهم جداً، لكن لا تكتبه كـ“موسوعة القيود الخانقة”
في المجتمع ستجد كثيراً من “يجب/ممنوع/مبادئ” الطويلة جداً، ومعظمها ضجيج.
إذا حشوت النموذج بقيود أكثر من اللازم، فعادةً لن يصبح “أثبت”، بل سيصبح “أبلد”.
ما ينبغي للتعليمات العامة فعله هو تحديد الحدود وشرح الأدوات، لا ترويض الأسلوب.
4）لا تدع “تسويق المصطلحات الجديدة” يقودك
RAG وContext Engineering وMCP وSkills……
الكثير منها في جوهره تغليف جديد لمشكلات قديمة، أو تحويل الـ Prompt إلى معايير.
ما يستحق المتابعة ليس “اللفظ”، بل: هل يقلّل فعلاً احتكاكك ويقصّر مسار التسليم؟
5）للتطوير المتوازي سقف: مهمتان هما حدّ معظم الناس
تشغيل ثلاثة أو أربعة Agent يبدو عالي الكفاءة، لكن عملياً يعني أن ذاكرة دماغك المؤقتة ستنفجر.
طنين الإشعارات لن يفعل سوى قطع حالة التدفق وصناعة وهم “أنا مشغول جداً”.
الاقتراح: أطفئ الإشعارات، وراجع التقدّم بشكل استباقي.
الاستجابة السلبية للإشعارات = تُقاد بإيقاعها؛ التفقد الاستباقي للمهام = أنت من يتحكم بالإيقاع.
6）الملفات هي الذاكرة: انقل السياق من “الدماغ” إلى “نظام الملفات”
CLI Agent يعتمد أكثر على منطق البحث النصي.
لكي يكون الـ Agent ثابتاً، لا تعتمد على الدعاء، بل على وثائق مشروع قابلة للبحث وقابلة لإعادة الاستخدام.
اجعل الملفات موجّهة للتنفيذ النهائي، ولا تحشو فيها نفايات العملية.
الجوهر هو تعويض القصور البنيوي الفطري في سياق النموذج وانتباهه.
7）تبسيط العملية: خطّط أولاً، ثم اكتب الكود
طريقتك ذات الخطوتين الآن عملية جداً:
- مناقشة الخطة مراراً وتثبيتها (PLAN / مجلد plans)
- تنفيذ الكود وفق الخطة النهائية، وترسيخ وثائق التنفيذ (مجلد docs)
ملف الخطة هو المرساة، والكود هو الناتج.
8）التركيز على النتيجة: انشغل أقل بـ“عملية أنيقة”، وراقب أكثر “تسليماً قابلاً للتحقق”
انتقل من “أعلّم الـ Agent كتابة الكود خطوة بخطوة” إلى “أنا أدير الحل ومعايير القبول”.
الأخطاء الصغيرة في الوسط لا تدقق فيها فوراً؛ اجمعها واصلحها دفعة واحدة في مرحلة المراجعة.
جودة الكود لا تُحكم بالعاطفة؛ تُحكم بالاختبارات وبنية قابلة للتتبّع.
الهدف الأساسي واحد فقط: It just works.
9）ترقية العقلية: من منفّذ إلى مدير
استخدم Codex كـ“عقل خارجي + بطة مطاطية (Rubber Duck)”: أنت تفكك المشكلة، وتضع المعايير، وتتخذ المفاضلات؛
وهو يتكفّل بالتنفيذ على نطاق واسع.
لا تتعامل مع الـ Agent كإله، ولا كدمية—إنه مُضخِّم: يضخّم حكمك، ويضخّم فوضاك أيضاً.
10）دروس من ممارسات خاطئة
- السعي الأعمى وراء تشغيل “autonomous” لفترات طويلة ليس ذا جدوى كبيرة؛
- ما له قيمة فعلاً هو تقليل التدخّل البشري ورفع احتمال تسليم مستقر؛
- نسخ Prompt/Skills من الآخرين يسرّع البداية، لكنه قد لا يلائم مشروعك؛
- مسار النمو الأكثر فاعلية: راقب عملية التنفيذ، وابحث عن السبب الجذري للفشل، وكرّر تطوير منهجيتك.
