Vibe coding في 2026: كيف تبني برمجيات ضخمة بالذكاء الاصطناعي (من تطبيقك الأول إلى حجم Google)

قبل عامين، كانت عبارة “صف فقط ما تريد ودع الذكاء الاصطناعي يكتب الكود” تبدو كطرفة. وفي 2026 أصبحت هذه هي الطريقة التي يُبنى بها جزء ضخم ومتنامٍ من برمجيات العالم فعليًا. يذكر GitHub أن نحو 46% من كل الكود الجديد يُولّده الذكاء الاصطناعي الآن. وقالت Google إن نحو ربع قاعدة كودها الخاصة يتم بمساعدة الذكاء الاصطناعي. وتتوقع Gartner أن 60% من كل كود البرمجيات الجديد سيكون مكتوبًا آليًا بنهاية هذا العام. لم تنجُ Vibe coding من دورة الضجيج فحسب — بل ابتلعت الصناعة بهدوء.

أبني برمجيات الإنتاج بالكامل تقريبًا عبر توجيه وكلاء الذكاء الاصطناعي بالإنجليزية البسيطة. لا صياغة أكتبها بيدي، ولا شهادة في علوم الحاسوب — فقط تعليمات دقيقة، ومراجعة صارمة، وطريقة تمنع المشروع كله من الانهيار تحت ثقله. هذا هو الدليل الذي كنت أتمنى أن يعطيني إياه أحد في اليوم الأول: ما هي Vibe coding حقًا في 2026، وكيف تبدأ من الصفر، والأدوات والنماذج الدقيقة التي تستحق وقتك الآن، و— الجزء الذي يريد الجميع معرفته سرًا — هل يمكنك فعلًا استخدام هذا لبناء شيء بحجم Google أو Facebook.

الخلاصة: يمكنك أن تصل بـVibe coding إلى مدى مذهل، أبعد مما توقع الجميع تقريبًا. لكن من يُطلقون برمجيات جدية واسعة النطاق بالذكاء الاصطناعي ليسوا من يرمون الموجّهات على روبوت محادثة ويدعون. إنهم يتبعون عملية منظمة. بنهاية هذا المقال ستعرف بالضبط كيف تبدو تلك العملية، وستكون لديك حزمة أدوات تبدأ باستخدامها اليوم.

ما هو Vibe coding حقًا؟ (تعريف 2026)

صاغ المصطلح Andrej Karpathy في فبراير 2025، وانتشر إلى حد أن قاموس Collins اختاره كلمة العام 2025. كان تأطيره الأصلي فضفاضًا عن قصد: تستسلم للإحساس، وتصف ما تريد، وتقبل ما يعيده النموذج دون أن تقلق على التفاصيل.

تلك النسخة العابرة ماتت، وبصراحة، كان ذلك خيرًا. في 2026 تعني Vibe coding شيئًا أنضج: تكتب مواصفات دقيقة باللغة الطبيعية، وينفذها وكيل ذكاء اصطناعي، وتبقى في الحلقة كمعماري ومراجع وصاحب القرار النهائي. أنت لا تكتب الكود. أنت تدير النظام الذي يكتب الكود — وأنت مسؤول عمّا يُطلق.

نقل Karpathy نفسه مرمى الأهداف في أوائل 2026، فأحال “Vibe coding” إلى التقاعد واقترح “الهندسة الوكيلية” بدلًا منه: وكيلية لأنك تنسّق وكلاء بدلًا من كتابة الكود 99% من الوقت، وهندسة لأن إتقانها حرفة حقيقية تقف خلفها خبرة فعلية. لم يرسخ الاسم تمامًا — لا يزال معظم الناس يقولون “Vibe coding” — لكن التحول الذي يصفه صحيح تمامًا. انتقل مركز الثقل من الكتابة إلى الإدارة.

إليك البيانات المهمة. نحو 92% من مطوري الولايات المتحدة يستخدمون أدوات البرمجة بالذكاء الاصطناعي يوميًا، و82% من المطورين عالميًا يستخدمونها أسبوعيًا على الأقل. وفي دفعات Y Combinator الأخيرة، لدى نسبة لافتة من الشركات الناشئة قواعد كود يزيد أكثر من 90% منها على توليد الذكاء الاصطناعي. لم تعد هذه تقنية هامشية. إنها الخيار الافتراضي، وإما أن تتقنها أو تتأخر.

الحقيقة الصريحة عن “Vibe coding لموقع بحجم Google أو Facebook”

لنتعامل مع الحلم مباشرة، لأنه السؤال الذي يتكرر أكثر.

هل يمكنك أن تجلس هذا الأسبوع وتنجز بنقرة واحدة نسخة تعمل من google.com أو facebook.com؟ لا. من يقول غير ذلك يبيعك دورة. Google تعني آلاف المهندسين، وبنية تحتية بحجم كوكب، وعقدًا من الأنظمة المتراكمة، وتقنية بحث وترتيب صعبة حقًا. لقطة شاشة لـ“نسخة Facebook مبنية بموجّه واحد” هي نموذج واجهة بلا خلفية حقيقية، وبلا مصادقة على نطاق واسع، وبلا نموذج بيانات ينجو من الاحتكاك بالمستخدمين، وبلا أمان يستحق الاسم.

لكن هذا هو الجزء الذي هو صحيح، وهو الحقيقة الأكثر إثارة للاهتمام: البرمجيات الكبيرة بمستوى الإنتاج يُبنى بعضها بهذه الطريقة الآن تمامًا — بما في ذلك داخل الشركات التي تحاول تقليدها. إحصائية Google عن ربع الكود كله هي المؤشر. الفرق بين عرض عابر وشيء حقيقي ليس في الموجّهات. إنه في المنهج.

العرض التوضيحي سهل. أما البرمجيات التي آمنة وقابلة للتوسع والصيانة فهي صعبة — وهذه الفجوة هي التوتر المُحدِّد لـVibe coding في 2026. الفرق التي تعبرها تتعامل مع وكلاء الذكاء الاصطناعي كمهندسين مبتدئين سريعين لا يكلّون ومفرطين في الثقة أحيانًا، وتحيطهم بالانضباط نفسه الذي تطبقه مؤسسة هندسية جيدة على البشر: معمارية واضحة، وعمل مفكك، وسياق مشروع دائم، واختبارات آلية، ومراجعة أمنية يُعامل فيها كل سطر يُخرجه الذكاء الاصطناعي كغير موثوق حتى يثبت العكس.

لذا أعد صياغة الهدف. لن تُوجد بالسحر Google من العدم. وأنت يمكنك أن تبني بـVibe coding منتجًا حقيقيًا طموحًا متعدد الميزات — شبكة اجتماعية، أو سوقًا، أو منصة SaaS — حتى جودة إنتاج حقيقية، بنفسك أو بفريق صغير جدًا، في جزء صغير من الوقت الذي كان يتطلبه. هذه ليست نسخة مخففة من الحلم. ولمؤسس منفرد، إنها على حدود السحر. وبقية هذا الدليل هي كيف تفعلها فعليًا.

كيف تبدأ مع Vibe coding (الأساسيات المطلقة)

إن لم تفعل هذا من قبل، ها هو النموذج الذهني كله في جملة واحدة: أنت المعماري والمدير؛ والذكاء الاصطناعي هو الباني. استوعب ذلك وسيتبع كل شيء آخر.

إليك كيف تحصل على أول نتيجة حقيقية، خطوة بخطوة.

1. اختر وكيلًا واحدًا ومشروعًا واحدًا. لا تقضِ أسبوعًا تتسوق الأدوات. خذ وكيل برمجة واحدًا بالذكاء الاصطناعي (التوصيات أدناه) واختر مشروعًا صغيرًا لكنه حقيقي — موقعًا شخصيًا، أو متتبع عادات، أو أداة صغيرة تريدها فعلًا. الحقيقي يتغلب على البرنامج التعليمي.
2. صف النتيجة، لا التنفيذ. أخبر الوكيل ما تريده و لماذا، بلغة بسيطة. “ابنِ لي موقعًا شخصيًا نظيفًا بصفحة رئيسية، ومدونة بصفحات مقالات منفصلة، ووضع داكن، ونموذج تواصل يرسل لي بريدًا.” لست بحاجة إلى معرفة ما هي React أو PostgreSQL بعد. تحتاج إلى معرفة ما تريد.
3. اقرأ ما يفعله — لا تقبله فقط. هذه هي العادة الوحيدة التي تفصل من يُطلقون عملًا عن من يصابون بـ“دوار Vibe”. عندما يشرح الوكيل خطته، اقرأها. وعندما يكتب كودًا، اطلب منه شرح أي شيء لم تتبعه. أنت لا تحفظ الصياغة؛ أنت تبني حكمًا على ما إذا كان العمل سليمًا.
4. كرر في خطوات صغيرة محددة. “الآن أضف مفتاح الوضع الداكن.” “يجب أن يتحقق نموذج التواصل من البريد قبل الإرسال.” تغيير واحد في كل مرة. الخطوات الصغيرة تُبقي الوكيل دقيقًا وتُبقيك أنت قادرًا على معرفة متى ينكسر شيء.
5. اختبر الشيء باستمرار. انقر كل زر. جرّب أن تكسر نماذجك. اطلب من الوكيل كتابة اختبارات. كلما أسرعت في اكتشاف مشكلة، كان إصلاحها أرخص.
6. تعامل مع الذكاء الاصطناعي كند، لا كعرّاف. اعترض. اختلف. اسأل “هل هناك طريقة أبسط؟” القاعدة الذهبية لـVibe coding في 2026 صريحة: لا تُطلق أبدًا كودًا لا تفهمه على الأقل بمستوى عالٍ. لست بحاجة إلى قراءة كل سطر. لكنك تحتاج إلى معرفة الغرض من كل جزء.

هذا كل شيء. هذه هي الحلقة. وكل ما تبقى في هذا المقال يدور حول القيام بهذه الحلقة أفضل، وعلى نطاق أكبر، مع الأدوات المناسبة.

الأدوات: ما تستخدمه فعلًا في 2026

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

الوكلاء المعتمدون على الطرفية أولًا (حيث يجري العمل الجاد)

تعمل هذه في طرفيتك، وتعدّل الملفات مباشرة على جهازك في حلقة تغذية راجعة محكمة، وتميل إلى كونها الأقدر على الهندسة الحقيقية.

• Claude Code — أداتي اليومية، ومتصدر القدرة الخام. يعمل بـClaude Opus 4.8، ويتصدر لوحة SWE-bench Verified بنسبة 88.6%. وهو قابل للبرمجة بعمق (خطافات، و“Routines” مجدولة، وكل شيء) ويقرأ ملف CLAUDE.md في مستودعك لتحميل سياق المشروع تلقائيًا في كل جلسة. وتبدأ الفئات المدفوعة من نحو $20 شهريًا.
• OpenAI Codex — مدعوم بـGPT-5.5، ويتصدر لوحة Terminal-Bench، ويغطي CLI والسحابة والويب والجوال تحت حساب واحد، بأسعار ابتدائية من نحو $8 شهريًا. ممتاز إن كنت تعيش داخل منظومة ChatGPT.
• OpenCode — المتميز في المصادر المفتوحة (أكثر من 172 ألف نجمة على GitHub، بترخيص MIT). إنه وكيل طرفية حقيقي، لا غلاف، وهو محايد تجاه النماذج: أحضر مفتاح API لأي نموذج — Claude أو GPT أو Gemini أو Kimi أو GLM أو DeepSeek أو Qwen — وشغّله. ووتيرة الميزات عالية لأن المجتمع يُطلق بسرعة. هذا هو الخيار إن أردت التحرر من أي بائع واحد.
• Aider, Cline, Hermes Agent, Goose, Kilo Code — طبقة صحية مفتوحة المصدر. كلها مجانية التشغيل؛ تدفع فقط مقابل رموز النموذج التي تمررها عبرها.

بيئات عمل أصلية في IDE وبيئات مرئية (حيث يلتقي التحرير بالإدارة)

• Cursor — أنظف تجربة محرر شاملة. نموذج Composer فيه رخيص لكل مخرج، ويمكن لـCursor 2.0 تشغيل ما يصل إلى ثمانية وكلاء بالتوازي. إن أردت أن ترى كودك بينما تدير، فابدأ هنا.
• Google Antigravity — بيئة عمل Google القائمة على الوكلاء أولًا، مجانية للأفراد في معاينة عامة، وتستخدم Gemini 3.5 Flash افتراضيًا، مع إدارة مرئية للوكلاء المتوازيين. الورقة الرابحة المثيرة للانتباه. (ملاحظة: الفئة المجانية القديمة من Gemini CLI بسعة 1,000 طلب يوميًا تنتهي June 18, 2026 مع دمج Google لها في Antigravity CLI — لذا إن كنت تعتمد عليها، فاليوم هو يوم الانتقال.)
• GitHub Copilot — الخيار الأصلي في GitHub، والأقوى إن كان كودك يعيش هناك بالفعل وتريد أتمتة من issue إلى PR. فئة Pro بـ$10 شهريًا.
• Windsurf / Devin Desktop — تطوّر Windsurf إلى Devin Desktop، مع انحياز إلى وكلاء سحابيين مستقلين متوازيين يفتحون طلبات سحب بينما تفعل شيئًا آخر.

ملاحظة تقنية تستحق المعرفة: كل وكيل جاد تقريبًا يدعم الآن Model Context Protocol (MCP), وهو معيار مفتوح يتيح لك توصيل الأدوات الخارجية نفسها (البحث على الويب، وقواعد البيانات، وإدارة مشروعك، وغيرها) بأي وكيل بالإعداد نفسه. تعلّم MCP مرة، واستخدمه في كل مكان.

النماذج: تشكيلة 2026 (ومتى تستخدم كلًا منها)

وكيلك هو قمرة القيادة؛ والنموذج هو المحرك. وقد كانت منتصف 2026 فترة جامحة تمامًا لإصدارات النماذج — ثلاثة من أهمها أدناه صدرت في الأسابيع القليلة الماضية من كتابة هذا.

النماذج المغلقة المتقدمة (أعلى قدرة، سعر مرتفع)

• Claude Opus 4.8 (Anthropic) — صدر في 28 مايو 2026. متصدر الجودة الحالي للهندسة المعقدة متعددة الملفات وطويلة السياق: 88.6% على SWE-bench Verified. بسعر $5 لكل مليون رمز إدخال و$25 لكل مليون رمز إخراج. هذا ما ألجأ إليه عندما يكون الخطأ مكلفًا — المعمارية، وإعادة الهيكلة الكبيرة، وأي شيء حامل.
• GPT-5.5 (OpenAI) — متقارب مع Opus، ومتصدر Terminal-Bench. بارع في إنتاج مخرجات قابلة للاستخدام حتى عندما يغفل موجّهك الحالات الحدية، ما يجعله رائعًا للنماذج الأولية السريعة.
• Gemini 3.1 Pro / 3.5 Flash (Google) — قوي، ومندمج بعمق في منظومة Google وAntigravity، مع Flash المحسّن للسرعة.

طفرة الأوزان المفتوحة (القصة الحقيقية لعام 2026)

هنا يصبح الأمر ممتعًا، وهنا تكمن الوفورات. موجة من النماذج ذات الأوزان المفتوحة — كثير منها من مختبرات صينية — أصبحت منافسة حقًا للحدود المتقدمة، وهي رخيصة أو مجانية للاستضافة الذاتية. والجغرافيا السياسية جزء من الوقود هنا: القيود الأمريكية الأخيرة على تصدير أفضل النماذج الأمريكية إلى الخارج جعلت النماذج المفتوحة بتراخيص متساهلة أكثر جذبًا استراتيجيًا في العالم.

• Kimi K2.7-Code (Moonshot AI) — صدر في June 12, 2026. وحش بأوزان مفتوحة يضع البرمجة أولًا: نموذج Mixture-of-Experts بتريليون معامل (32B نشطة لكل رمز)، و نافذة سياق 256K رمز، وإدخال متعدد الوسائط، وترخيص MIT معدّل يسمح بالاستخدام التجاري. وتزعم Moonshot نحو استهلاك أقل بنسبة 30% لرموز الاستدلال من سابقه، إضافة إلى مكاسب بعشرات النقاط المئوية في معايير القياس، وهذا مهم لأن الرموز مال. ويقترن بـKimi Code CLI القائم على الطرفية (خطط من $19 شهريًا) ويعمل بنحو $0.95 لكل مليون رمز إدخال عبر API. مبني خصيصًا لحلقات الوكلاء الطويلة من التخطيط والتنفيذ والتنقيح. خيار قوي للتشغيلات الطويلة جدًا دون إشراف.
• GLM 5.2 (Z.ai، سابقًا Zhipu AI) — صدر في June 13, 2026، بعد Kimi بيوم واحد. نموذج MoE بـ744 مليار معامل (≈40B نشطة) مع نافذة سياق قابلة للاستخدام بمليون رمز — كبيرة بما يكفي لتغذيتها مستودعًا كاملًا — وأوزان مفتوحة بترخيص MIT على Hugging Face. وتزعم Z.ai أنها تتفوق على GPT-5.5 في بعض معايير البرمجة طويلة الأفق بنحو سدس التكلفة، مع ملاحظة أن تلك المعايير أعلنها البائع ولم تكن مستقلة التحقق عند الإطلاق. الميزة القاتلة لممارسي Vibe coding: يصدر عبر نقطة نهاية متوافقة مع Anthropic و خطة GLM Coding تبدأ من نحو $10 شهريًا، لذا يدخل مباشرة في Claude Code وOpenCode وCline وRoo Code وGoose وأمثالها. رائع للواجهة الأمامية والعمل المكثف على واجهة المستخدم، وقيمة مذهلة لمعظم برمجتك الوكيلية.
• DeepSeek V4 (وV4-Flash الأرخص) — الخيار الأمثل للعمل عالي الحجم والحساس للتكلفة حيث تريد جودة معقولة بأدنى الأسعار.
• Qwen 3.5 — أداء ممتاز لكل معامل، خصوصًا المتغيرات الأصغر التي تعمل بسرعة على أجهزة المستهلكين.

تشغيل النماذج بنفسك: Ollama وOllama Cloud

إن كانت الخصوصية أو ضبط التكلفة أو مجرد عدم الاعتماد على API أي جهة تروق لك، Ollama فهو “لحظة Docker لنماذج LLM المحلية”: أمر واحد لتنزيل النماذج المفتوحة وتشغيلها (Llama وQwen وMistral وDeepSeek وGemma وغيرها) محليًا، مع API متوافق مع OpenAI على localhost:11434 يمكن لأي وكيل أن يشير إليه.

العقبة مع المحلي كانت دائمًا العتاد — النماذج المفتوحة بمستوى الحدود المتقدمة تحتاج VRAM كبيرة. وهذا بالضبط ما Ollama Cloud يحله، وهو متاح الآن للعموم. إنه استدلال مُدار: تشغّل النماذج المفتوحة الكبيرة نفسها على وحدات GPU في مركز بيانات Ollama دون الحاجة إلى GPU محلية, و— هذا هو الجزء الذكي — يكشف واجهة HTTP المطابقة لإعدادك المحلي. لا إعادة كتابة كود، ولا SDK جديد. تشير فقط إلى نموذج سحابي وتنطلق. والأسعار معقولة: فئة مجانية، وهو Pro بنحو $20 شهريًا، وفئة Max أعلى بنحو $100 شهريًا، تُحاسب بوقت GPU لا بالرموز. وتلتزم Ollama أيضًا بعدم التسجيل، وعدم التدريب على بياناتك، وعدم الاحتفاظ إطلاقًا لدى شركاء الاستضافة — وهذا مهم إن كنت تعمل على أي شيء حساس أو تحت GDPR.

استراتيجية توجيه النماذج المتعددة

إليك النمط الذي يستخدمه أفضل الممارسين فعليًا، وهو أكبر رافعة تكلفة واحدة في Vibe coding: لا تشغّل كل شيء على النموذج الأغلى. وجّه حسب المهمة.

• استخدم نموذجًا متقدمًا (Opus 4.8، GPT-5.5) للحصة الصغيرة من العمل حيث يكون الخطأ مكلفًا حقًا: المعمارية، وتصميم المخطط، والمنطق الحساس أمنيًا، وإعادة الهيكلة الكبيرة.
• استخدم نموذجًا مفتوحًا قويًا رخيصًا (GLM 5.2، Kimi K2.7، DeepSeek V4) لمعظم الكدح: تنفيذ الميزات، والكود المتكرر، وواجهة المستخدم، والاختبارات.
• استخدم محليًا أو عبر Ollama Cloud نماذج مفتوحة للاستدلال عالي الحجم منخفض المخاطر: التصنيف، والتلخيص، والتعديلات البسيطة.

الفرق التي توجّه بهذه الطريقة تخفض فواتير الاستدلال عادة بنسبة 60–80% دون خسارة جوهرية في الجودة. ومع وكيل محايد تجاه النماذج مثل OpenCode، يكون التبديل بسهولة تغيير مفتاح API.

نظام الملفات الذي يجعل مشاريع Vibe coding الكبيرة ممكنة (AGENTS.md وCLAUDE.md & وأخواتهما)

هذا أهم قسم في المقال، و— بإفصاح كامل — الجزء الذي وُجد بقية الدليل لتمهيده. هنا يحترق الجميع تقريبًا، وأنا نفسي جدًا حين بدأت. لذا لنمض ببطء وبشكل ملموس، لأن هذا هو الفرق بين مشروع ينمو لأشهر وآخر ينهار بهدوء في الأسبوع الثاني.

إليك الواقع القاسي: لا ذاكرة لوكلاء الذكاء الاصطناعي بين الجلسات. أغلق الطرفية ويتبخر كل ما “عرفه” الوكيل عن مشروعك. افتح جلسة جديدة غدًا ويصبح غريبًا تمامًا من جديد — لا يتذكر حزمتك التقنية، ولا أعرافك، ولا القرارات التي اتخذتها الأسبوع الماضي، ولا ما كان في منتصف بنائه. انتقل من Claude Code إلى Cursor، أو بدّل نموذجًا بآخر، وتبدأ من الصفر مرة أخرى. في مشروع صغير يمكنك إعادة شرح كل شيء في فقرة. أما في مشروع كبير، فهذه الحقيقة الواحدة هي ما يقتلك: تنفق وقتًا أطول في إعادة إطلاع الوكيل مما تنفقه في البناء، وهو يناقض خيارات اتخذتها بالفعل، وتنجرف قاعدة الكود إلى فوضى.

الحل هو اللعبة كلها، لذا سأقوله بصراحة: يجب أن تعيش ذاكرة مشروعك في ملفات داخل المستودع، لا في المحادثة. المحادثة قابلة للرمي. أما الملفات فدائمة. وفي كل جلسة، يعيد الوكيل بناء فهمه عبر قراءة تلك الملفات أولًا — ولأنها Markdown عادي في مستودعك، يمكن لأي وكيل وأي نموذج وأي أداة قراءتها. تتوقف عن إعادة شرح مشروعك إلى الأبد وتوثقه مرة واحدة، كما ينبغي. هذا ما يجعل مشروعًا ينجو من إعادة ضبط السياق، وتبديل النماذج، وتغيير الأدوات. وليس مصادفة أنه أيضًا ما يتيح لشخص واحد أن يحمل طموحًا بحجم Google: أنت لا تحمله في رأسك. تحمله على القرص.

إليك طبقة التوثيق التي أضعها في جذر كل مشروع جاد:

project-root/
├── README.md          # الباب الأمامي: ما هو، ولماذا يوجد، وكيف تشغّله
├── AGENTS.md          # تعليمات تشغيل وكيل الذكاء الاصطناعي عبر الأدوات (المعيار)
├── CLAUDE.md          # إرشادات خاصة بـClaude Code (رقيقة؛ تستورد AGENTS.md)
├── GEMINI.md          # إرشادات خاصة بـGemini CLI (رقيقة؛ تستورد AGENTS.md)
├── CONVENTIONS.md     # أعراف البرمجة (تُحمّلها aider تلقائيًا أيضًا)
├── CONTEXT.md         # سياق المشروع الطويل للبشر ونماذج LLM
├── llms.txt           # خريطة مقروءة آليًا للمستودع/المستندات للوكلاء
├── VISION.md          # "لماذا" والنجم الشمالي طويل الأمد
├── ROADMAP.md         # إلى أين يتجه المشروع: المراحل والمعالم
├── TASKS.md           # قائمة المهام النشطة / سجل العمل ("المؤشر")
├── TODO.md            # تدوين سريع وحر لما لم يُخطط له بعد
├── DECISIONS.md       # فهرس القرارات المعمارية (لا يُعاد فتحها)
└── CHANGELOG.md       # تاريخ مقروء للبشر ومُرقّم لما تم إطلاقه

قد يبدو هذا كثيرًا. وهو ليس كذلك — حين ترى أن هذه الملفات تؤدي ثلاث وظائف مختلفة. فكّر فيها على ثلاث طبقات, من الأكثر ديمومة إلى الأكثر قابلية للرمي.

الطبقة 1 — القواعد (دائمة، نادرًا ما تتغير)

هذه تحدد كيف ينبغي أن يتصرف الوكيل في مستودعك. تكتبها مبكرًا وتعدّلها أحيانًا.

• AGENTS.md هو قلب النظام والملف الذي يحل مشكلة قابلية النقل. إنه المعيار المفتوح المحايد تجاه الأدوات لإخبار أي وكيل برمجة بالذكاء الاصطناعي كيف يعمل مشروعك: الحزمة التقنية، وكيفية تثبيته وتشغيله، وكيفية تشغيل الاختبارات والفحص، والأعراف التي يجب اتباعها، والأشياء التي لا تُفعل أبدًا. ظهر في 2025 من تعاون بين Sourcegraph وOpenAI وGoogle وCursor وFactory، ويُدار الآن تحت Linux Foundation، وتتبناه أكثر من 30 أداة ويوجد في أكثر من 60,000 مستودع. والفكرة كلها هي قابلية النقل: اكتبه مرة واحدة فتقرأه Codex وCursor وWindsurf وCline وCopilot وGemini CLI وغيرها أصلًا. وكل ما هو مشترك يعيش هنا.
• CLAUDE.md هو ملف التعليمات الأصلي الخاص بـClaude Code — وهنا المفاجأة التي تنال من الجميع، وقد تكون بالضبط ما أحرقك: حتى منتصف 2026، لا يقرأ Claude Code تلقائيًا AGENTS.md. إنه يقرأ CLAUDE.md. إن كان مستودعك يحتوي فقط على AGENTS.md، فإن Claude Code يحمّل صفرًا من تعليمات المشروع، ولن ينبّهك إلى ذلك. ستحصل فقط على مخرجات أسوأ وتتساءل عن السبب. والإصلاح بسيط للغاية وموثّق رسميًا: اجعل CLAUDE.md ملفًا رفيعًا يستدعي الملف المشترك بسطر واحد — @AGENTS.md — ليقرأ Claude تعليماتك العامة مع أي إضافات خاصة بـ Claude. (النهج الشائع الآخر هو رابط رمزي: ln -s AGENTS.md CLAUDE.md، مما يجعل الملفين ملفًا واحدًا حرفيًا.) مصدر واحد للحقيقة، بلا تكرار، بلا انحراف.
• GEMINI.md هي الفكرة نفسها بالنسبة إلى Gemini CLI من Google — ملف التعليمات الخاص بأداتها. أبقِه رفيعًا واجعله يشير رجوعًا إلى AGENTS.md أيضًا. النمط لا يتغير أبدًا: ملف مشترك واحد للعالم، وملف رفيع واحد لكل أداة.
• CONVENTIONS.md يحفظ اصطلاحاتك البرمجية — التسمية، والتنسيق، والأنماط، وقواعد الطريق المعمارية. إنه مفيد بذاته وهو الملف الذي يحمّله وكيل aider في السياق بحكم الاصطلاح. أشر إليه من داخل AGENTS.md حتى ترث كل أداة المعايير نفسها.

ثمرة هذه الطبقة هي بالضبط ما أردته: استقلال حقيقي عن الأدوات. لأن القواعد المشتركة تعيش في AGENTS.md وكل أداة تشير إليه فقط، يمكنك تسليم المشروع نفسه إلى Claude Code اليوم، وCursor غدًا، وOpenCode الأسبوع القادم — وكلها تعمل من تعليمات متطابقة. لا إعادة شرح، ولا ارتباط بأداة واحدة. هذا ما تعنيه قابلية النقل عمليًا.

الطبقة 2 — المعرفة والحالة الحية (هذه هي الذاكرة الفعلية)

هذه الطبقة هي ما ما هو المشروع و أين يقف الآن. ملفات «الآن» تتغير في كل جلسة — وهي العلاج الحقيقي لفقدان الذاكرة.

• README.md — الواجهة الأمامية، مكتوبة للبشر أولًا: ما المشروع، ولماذا وُجد، وكيف تشغّله. كل قادم جديد (وكل وكيل) يبدأ من هنا.
• CONTEXT.md — خلفية مطوّلة للبشر ولنماذج LLM معًا: المجال، والمشكلة التي تحلّها، والمفاهيم والمصطلحات الأساسية، والقيود. هذا هو السياق العميق الذي لا مكان له في ملف تعليمات موجز، لكن الوكيل يحتاجه لاتخاذ أحكام جيدة.
• VISION.md — النجم الشمالي: لماذا وُجد هذا المشروع وإلى أين يتجه على المدى البعيد. يبقيك أنت والوكيل موجّهين إلى الهدف نفسه حين تكون غارقًا في ميزة واحدة.
• llms.txt — خريطة Markdown صغيرة قابلة للقراءة آليًا تشير للوكلاء (ولأدوات جلب الوثائق) إلى أهم ملفاتك مع وصف من سطر واحد، ليجدوا السياق الصحيح بسرعة ويستهلكوا رموزًا أقل. تحفّظ صادق: كـ public-website تكتيك SEO، llms.txt لا يزال غير مُثبت — شركات الذكاء الاصطناعي الكبرى لم تلتزم بقراءته، والدراسات تُظهر لا فائدة قابلة للقياس في الترتيب حتى الآن. لكن كـ repo/docs فهرس لوكلاء البرمجة، فإنه يستحق مكانه.
• ROADMAP.md — إلى أين يتجه المشروع، مقسّمًا إلى مراحل (انظر القسم التالي) ومعالم. خريطتك للرحلة كلها.
• TASKS.md — الملف الأهم للاستمرارية اليومية. هذا هو المؤشر: ما أُنجز، وما قيد التنفيذ الآن، وما التالي، وأي عوائق. حين تقرأه جلسة جديدة، تعرف بالضبط من أين تكمل. أبقِه موجزًا وحديثًا — فهو لإعادة التوجيه السريع، لا للنثر.
• TODO.md — التقاط حرّ للأفكار والأشياء الصغيرة غير المجدولة بعد. يُبقي TASKS.md التركيز على العمل الجاري دون أن يفلت شيء من الشقوق.
• DECISIONS.md — سجل يُضاف إليه فقط، للخيارات المعمارية التي اتخذتها و لماذا. «اخترنا Postgres على SQLite لأننا نحتاج كتابات متزامنة.» هذا ما يمنع الوكيل من إعادة فتح أسئلة محسومة بهدوء أو مخالفة قرار بعد ثلاث جلسات. الأحدث في الأعلى؛ لا يُحرَّر أبدًا، بل يُضاف إليه فقط.
• CHANGELOG.md — سجل مقروء للبشر ومرقّم بالإصدارات لما شُحن فعليًا، بالترتيب. إنه تاريخ مشروعك وأسرع طريقة لجلسة عائدة لترى ما تغيّر مؤخرًا.

الطبقة 3 — الجلسة (عابرة، تعيش في المحادثة فقط)

هذه هي المحادثة التي تجريها الآن. إنها الطبقة الوحيدة التي لا تبقى — وهذا لا بأس به، لأن كل شيء مهم فيها يُكتب رجوعًا إلى الطبقة 2 قبل أن تغلق. وأي شيء يعيش هنا فقط هو، بحكم التعريف، على وشك النسيان.

كيف تسير الجلسة فعليًا

مجتمعة، الإيقاع اليومي ممل تقريبًا — وهذا هو المقصود. الجلسة العادية تبدو هكذا:

1. افتح الجلسة. أول ما يفعله الوكيل هو قراءة القواعد والحالة: AGENTS.md (عبر CLAUDE.md/GEMINI.md)، ثم ROADMAP.md, TASKS.md، و DECISIONS.md.
2. أعِد التوجيه. يُبلّغك: «نحن في المرحلة 2، كانت المهمة الأخيرة تدفق تسجيل الدخول، والتالية هي middleware المصادقة، لا عوائق.» تؤكد أو تعيد التوجيه. ثلاثون ثانية، بلا جهد، بلا إعادة شرح.
3. أنجز مهمة واحدة. يعمل على بند واحد من TASKS.md، متبعًا الاصطلاحات ومحترمًا القرارات المقفلة.
4. أعد كتابة الذاكرة. قبل الإغلاق، يحدّث الوكيل TASKS.md (حرّك المؤشر)، ويضيف سطرًا في CHANGELOG.md (ما شُحن)، ويسجّل أي خيار جديد في DECISIONS.md.
5. أغلق. تفرغ نافذة السياق — ولا يهم، لأن لا شيء ذا قيمة كان فيها. كل شيء على القرص.

غدًا تفتح جلسة جديدة، أو تنتقل إلى أداة مختلفة تمامًا، وتعيد الخطوة 1 بناء السياق كله في ثوانٍ. هذا تموت مشكلة فقدان الذاكرة، وهو السبب الكامل الذي يمكّن بانيًا منفردًا من الحفاظ على مشروع كبير يمتد أشهرًا متماسكًا.

هذا هو «agentic engineering» في صورة ملموسة. عصر الموجّه العملاق الواحد انتهى؛ عصر التفكيك الاستراتيجي قد حان. أنت لا تدردش مع ذكاء اصطناعي فحسب — بل تبني وتشغّل نظام تشغيل لوكلائك، وهذه الوثائق هي مصدر الحقيقة الواحد. أعدّه مرة واحدة، وسيعود العمل اليومي سهلًا بلا عناء بينما يتجاوز المشروع بهدوء أي شيء يمكن لمحادثة واحدة أن تحتويه.

خارطة طريق واقعية: بناء تطبيق كبير بـVibe coding، مرحلة بمرحلة

فكيف توجّه كل هذا نحو شيء طموح — شبكة تواصل حقيقية أو سوقًا إلكترونيًا؟ أنت لا تبنيه كله دفعة واحدة. تنتقل عبر المراحل، وتدع الوكيل يعمل خطوة صغيرة واحدة فقط داخل كل مرحلة.

• المرحلة 0 — الأساس. جهّز المستودع، ونظام الوثائق أعلاه، واختر حزمتك التقنية. شغّل «hello world» محليًا. اقفل قراراتك المعمارية الكبرى قبل أي ميزات.
• المرحلة 1 — المعمارية & البيانات. حدّد شكل النظام: نموذج البيانات، والمكوّنات الرئيسية، وكيف تتواصل. هذا عمل نموذج من الحدود — أنجزه صحيحًا يصبح كل ما بعده أسهل.
• المرحلة 2 — الميزات الأساسية. ابنِ قلب المنتج من طرف إلى طرف حتى تعمل رحلة المستخدم الأساسية. (لشبكة تواصل: الحسابات، والملفات الشخصية، والنشر، وتدفق المحتوى.)
• المرحلة 3 — التكاملات & المصادقة. مصادقة حقيقية، وخدمات خارجية، واستمرارية، والنسيج الرابط.
• المرحلة 4 — الواجهة & الصقل. الواجهة الأمامية، والتصميم المتجاوب، والتعريب الدولي إن احتجته. عمل رائع لنموذج قوي في الواجهات مثل GLM 5.2.
• المرحلة 5 — التصليد. الاختبارات، والأداء، ومعالجة الأخطاء، و الأمان — الجزء الذي تتخطاه العروض التجريبية دائمًا ولا تستطيع المنتجات الحقيقية تخطيه أبدًا.
• المرحلة 6 — النشر & التشغيل. اشحنه. جهّز النشر، والمراقبة، والنسخ الاحتياطية، وأدلة التشغيل لما تتعطل الأمور.
• المرحلة 7 — الإطلاق & الامتثال. الصفحات القانونية، والوثائق العامة، و(إن كنت تعمل في مكان مثل الاتحاد الأوروبي) متطلبات الخصوصية والإفصاح غير القابلة للتفاوض لموقع تجاري.
• المرحلة 8 — التكرار. الآن أنت منتج حقيقي. أصلح، وحسّن، وانمُ، إلى الأبد.

لاحظ ما يفعله هذا: يحوّل جبلًا يبدو مستحيلًا («ابنِ شبكة تواصل») إلى سلسلة طويلة من جلسات فردية قابلة للإنجاز. هذه هي الحيلة كلها. المشاريع الضخمة لا تُبنى بموجّهات ضخمة. بل تُبنى بألف خطوة صغيرة موجّهة جيدًا وموثّقة جيدًا.

المزالق (أي: لا تُصب بـ“دوار Vibe”)

اكتسب 2025 لقبًا: سنة «vibe hangover». هرعت فرق كثيرة إلى استبدال الهندسة الحذرة بالموجّهات، فاصطدمت بالواقع مباشرة. تعلّم منها.

• الأمان هو الأكبر. بنَت شركة أمن مؤخرًا 15 تطبيقًا متطابقًا عبر خمس أدوات Vibe coding شائعة، ووجدت 69 ثغرة أمنية، ست منها حرجة. الكود المولّد بالذكاء الاصطناعي أكثر عرضة للثغرات بشكل غير متناسب. تعامل مع كل سطر من مخرجات AI كغير موثوق حتى يُراجَع ويُفحص. لا تدع وكيلًا يبتكر نظام مصادقة خاصًا به أو يتعامل مع الأسرار دون عينيك عليه.
• تعفّن الكود حقيقي. تتبّعت الدراسات ارتفاع تقلّب الكود وتضاعف الكود المكرر مع صعود حجم AI. انضباط إعادة الهيكلة يصبح أهم لا أقل. اجعل الوكيل ينظّف بعد نفسه.
• فجوة الثقة صحية. تفضيل المطورين لأدوات AI في الواقع انخفض from 77% in 2023 to about 60% in 2026, even as usage kept climbing. That’s not pessimism — it’s maturity. The industry learned to use the tools without blindly trusting them. You should too.
• تصحيح الأخطاء قد يأكل مدخراتك. تشير نسبة معتبرة من المطورين إلى أنهم يقضون مزيدًا في إصلاح كود AI مما كان سيستغرقه كتابته بأنفسهم — تقريبًا دائمًا لأنهم قبلوا مخرجات لم يفهموها وتخطوا الاختبارات. والعلاج هو نفسه كما كان دائمًا: خطوات صغيرة، واختبار مستمر، ومراجعة حقيقية.

لا شيء من هذا سبب لتجنب Vibe coding. بل هو سبب لفعله كالمحترفين.

حزمة Vibe coding ذكية لعام 2026 (توصيتي)

إن أردت تجاوز شلل التحليل، فهذه إعدادات ملموسة أسلمها بسرور لمبتدئ أو ليشغّلها في مشروع جدي.

حزمة البداية الخفيفة شبه المجانية

• الوكيل: OpenCode (مجاني، مفتوح المصدر، لا يفرض نموذجًا معينًا) أو Google Antigravity (مجاني في النسخة التجريبية).
• النماذج: GLM 5.2 عبر خطة Coding Plan بنحو 10 دولارات شهريًا لمعظم العمل، إضافة إلى الطبقة المجانية من Ollama Cloud للمهام الكثيرة الصغيرة.
• الطريقة: نظام الوثائق أولًا أعلاه. غير قابل للتفاوض.
• التكلفة: بسعر فنجاني قهوة شهريًا تقريبًا.

حزمة الباني الجاد (ما أستخدمه فعليًا)

• الوكيل الأساسي: Claude Code، للقدرة الخام ومدى قابليته للبرمجة.
• نموذج المعمارية: Claude Opus 4.8 للقرارات الحاملة.
• نماذج العمل اليومي: GLM 5.2 وKimi K2.7-Code للعمل اليومي الروتيني، موجّهة عبر إعداد لا يفرض نموذجًا. وKimi خصوصًا للتشغيلات المستقلة الطويلة جدًا بفضل كفاءته في الرموز وسياقه 256K.
• الطبقة الرخيصة/المحلية: Ollama Cloud (Pro) للاستدلال الكثيف منخفض المخاطر.
• الغراء: MCP للأدوات، وبنية مشروع صارمة تبدأ بالوثائق وتربط كل شيء.

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

الأسئلة الشائعة

هل يستطيع شخص لا يعرف البرمجة إطلاقًا أن يمارس Vibe coding لشيء حقيقي في 2026؟ نعم — هذا هو جوهر ما وصلت إليه الأدوات. غير المهندسين يشحنون برمجيات عاملة بتحديد النية وتقييم النتائج. ما زلت تحتاج إلى حكم وصبر واستعداد لتعلّم ما يفعله AI على مستوى عالٍ، لكنك لا تحتاج إلى كتابة الكود بيدك.

هل Vibe coding ما زال ذا صلة، أم أن «agentic engineering» يحل محله؟ الشيء نفسه باسم أفضل. «agentic engineering» هو مجرد Vibe coding يُمارس بانضباط — تنسيق الوكلاء، وتحديد بوابات الجودة، والحفاظ على الإشراف البشري في النقاط الحرجة. معظم الناس ما زالوا يقولون «Vibe coding» في الحديث؛ والممارسة تحته نضجت فقط.

ما أفضل نموذج AI للبرمجة الآن؟ للجودة القصوى، Claude Opus 4.8 (88.6% على SWE-bench Verified) وGPT-5.5 هما رائدا الحدود. وللأفضل قيمة، النماذج مفتوحة الأوزان مثل GLM 5.2 وKimi K2.7-Code قريبة بشكل ملحوظ بجزء من التكلفة. الجواب الذكي هو استخدام الاثنين — نماذج الحدود للـ10% الصعبة، والرخيصة القوية للـ90% الأخرى.

كيف أمارس Vibe coding مجانًا (أو شبه مجانًا)؟ استخدم وكيلًا مجانيًا مفتوح المصدر مثل OpenCode، واقرنه بالطبقة المجانية من Ollama Cloud أو خطة أقل من 15 دولارًا مثل Coding Plan من GLM أو Kimi Code، وشغّل النماذج مفتوحة الأوزان. Google Antigravity مجاني أيضًا للأفراد في النسخة التجريبية. يمكنك بناء قدر جدي من العمل بسعر شطيرة شهريًا.

هل يمكنني فعلًا بناء شركة ناشئة أو تطبيق كبير بهذه الطريقة؟ منتج حقيقي متعدد الميزات بجودة إنتاجية — نعم، والناس يفعلون ذلك منفردين طوال الوقت. نسخة حرفية من Google أو Facebook بالحجم الكامل — لا، فذاك آلاف المهندسين وبنية تحتية بحجم كوكب. الهدف الواقعي والمثير حقًا هو منتج طموح بجودة إنتاجية يبنيه شخص واحد أو فريق صغير، وهو ما كان مستحيلًا سابقًا.

هل الكود المولّد بالذكاء الاصطناعي آمن بما يكفي للشحن؟ ليس افتراضيًا. كود AI أكثر عرضة للثغرات بشكل غير متناسب، لذا يجب أن تراجعه وتفحصه، وألا تدع الوكلاء يتعاملون مع المصادقة أو الأسرار دون إشراف، وتعامل مع كل المخرجات كغير موثوقة حتى تُتحقق. مع هذا الانضباط، فهو قابل للشحن تمامًا. وبدونه، هو اختراق ينتظر الحدوث.

Claude Code مقابل Cursor — أيهما يختار المبتدئ؟ إن أردت الوكيل الأقدر وكنت مرتاحًا في الطرفية، فـ Claude Code. وإن أردت رؤية كودك في محرر مصقول بينما توجّه AI، فـ Cursor. كثيرون يستخدمون الاثنين. أي منهما نقطة بداية جيدة؛ لا تُعذّب نفسك بالاختيار.

ما هو Ollama Cloud ولماذا أستخدمه؟ يشغّل Ollama Cloud نماذج مفتوحة المصدر كبيرة على وحدات GPU مُدارة في مراكز بيانات، فلا تحتاج أجهزة باهظة، مع كشف الـAPI نفسه تمامًا لتشغيل Ollama محليًا — فهو بديل مباشر. استخدمه للاستدلال الصديق للخصوصية والمنضبط التكلفة، خصوصًا العمل الكثيف، مع طبقة مجانية للبدء.

ما الفرق بين AGENTS.md وCLAUDE.md — وهل يقرأ Claude Code ملف AGENTS.md؟ AGENTS.md هو المعيار المفتوح عبر الأدوات (يُدار تحت مؤسسة Linux Foundation ويقرأه Codex وCursor وWindsurf وCline وGemini CLI وأكثر من 30 غيرها)؛ CLAUDE.md هو ملف التعليمات الأصلي الخاص بـ Claude Code. المفارقة: حتى منتصف 2026، لا يقرأ Claude Code تلقائيًا AGENTS.md — إذا كان المستودع يحتوي هذا الملف فقط، فلن يحمّل Claude Code أي تعليمات للمشروع ولن ينبّهك. الحل هو إبقاء AGENTS.md مصدر الحقيقة المشترك، وجعل CLAUDE.md ملفًا رفيعًا يستورده بسطر @AGENTS.md واحد (أو اربط الاثنين برابط رمزي عبر ln -s AGENTS.md CLAUDE.md). ملف واحد للعالم، وملف رفيع واحد لكل أداة.

كيف أوقف نسيان وكيل AI لمشروعي بين الجلسات؟ ضع ذاكرة المشروع في ملفات داخل المستودع، لا في المحادثة. أبقِ ملفًا AGENTS.md للقواعد، وملفًا ROADMAP.md للخطة، وملفًا TASKS.md للمؤشر الحالي (منجز / قيد التنفيذ / التالي)، وملفًا DECISIONS.md للقرارات المقفلة. اجعل الوكيل يقرأ هذه في بداية كل جلسة ويكتب التحديثات في نهايتها. ولأنها كلها Markdown عادي على القرص، يبقى السياق حيًّا بعد إعادة ضبط السياق وتبديل النماذج وتغيير الأدوات كليًا.

إلى أين من هنا

Vibe coding في 2026 ليس حيلة ترويجية وليس اختصارًا للكسالى. إنه طريقة حقيقية وقوية أخذت تصبح المعيار لبناء البرمجيات — طريقة تمنح نفوذًا هائلًا لأي شخص مستعد لتعلّم توجيهها جيدًا. حاجز إنشاء البرمجيات انهار. والحاجز الجديد هو الذوق والحكم والانضباط.

فابدأ صغيرًا اليوم. اختر وكيلًا واحدًا، ووجّهه إلى مشروع حقيقي، وشغّل الحلقة: صف، راجع، كرّر، اختبر. ثم حين تكون مستعدًا للتوسع، جهّز نظام الوثائق أولًا ليكون لمشروعك ذاكرة وليتوسع وكلاؤك معك. الفجوة بين «لدي فكرة» و«إنه مباشر على الإنترنت» لم تكن أصغر من هذا. السؤال الوحيد المتبقي هو ماذا ستبني.

---

تبني شيئًا طموحًا وتريد نظام الوثائق والموجّهات الدقيق الذي يجعل Vibe coding واسع النطاق يعمل فعلًا؟ ذلك دليل قائم بذاته — وقراءة تالية رائعة على هذا الموقع.