مستوى الإنتاج (Production Grade): اللي الـ Vibe Coders ميعرفوش إنهم ميعرفوهوش

مستوى الإنتاج (Production Grade): اللي الـ Vibe Coders ميعرفوش إنهم ميعرفوهوش

1. العنوان اللي كل الناس فهمته غلط

في أبريل 2026، Cursor مسح داتا بيز بتاع شركة في تسع ثواني.

القصة قلبت الدنيا. مجلة Fast Company نزلتها. وReddit اتكلم عنها. وستة مليون ونص بني آدم شافوا التويتة. العناوين كانت بتقول: "وكيل ذكاء اصطناعي (AI agent) بيدمر شركة" و "Claude Opus 4.6 مسح داتا بيز الإنتاج من غير ما يسأل". الـ AI نفسه اعترف وقال: "أنا خالفت كل المبادئ اللي اتدتهالي. أنا خمنت بدل ما أتأكد. أنا عملت إجراء مدمر من غير ما يتطلب مني."

كل الناس لامت الذكاء الاصطناعي.

بس محدش سأل السؤال البديهي: ليه أصلاً AI agent بيكتب كود معاه API token بتاع الـ production؟

مؤسس شركة PocketOS، "جير كرين"، شاف الداتا بيز بتاع شركته بتتبخر قدام عينه لأن Cursor لقى API token على Railway volume وشغل أمر Volume Delete. المشكلة إن الباك أب (backups) كانت متخزنة جوة نفس الـ volume. عشان يرجعوا الداتا، اضطروا يستخدموا باك أب قديم من تلات شهور. تسع ثواني من القرارات اللي أخدها الـ AI لوحده ضيعت شغل شهور.

نرجع بالزمن لمارس 2026. أمازون خسرت حوالي 6.3 مليون طلب (order) في فترتين انقطاع للخدمة، كل واحدة فيهم استمرت 6 ساعات، والسبب كان تغييرات في الكود اتعملت بمساعدة الذكاء الاصطناعي ونزلت الـ production من غير وسائل حماية صح. رد فعل أمازون كان إنها عملت توقف لمدة 90 يوم لمراجعة أمان الكود على 335 نظام حساس. دلوقتي أي تغيير بيتعمل بالـ AI لازم يتوافق عليه من senior engineer قبل ما ينزل.

في نفس الشهر، مبرمج على Reddit نزل بوست إنه حرق 6,000 دولار من رصيد الـ API بتاع Claude في ليلة واحدة. هو شغل أمر /loop 30m check my PRs قبل ما ينام. الأمر ده فضل يعيد نفسه 46 مرة على مدار 26 ساعة. كل مرة بيعمل كاش (cache) لـ 800,000 توكن (token) من المحادثة، لأن الـ prompt cache بتاع شركة Anthropic بيخلص بعد خمس دقايق، وهو كان عامل الـ loop كل نص ساعة. الداشبورد كانت متأخرة أيام في التقارير. التنبيه الوحيد اللي جاله كان إيميل إن الليمت (limit) خلص. ستة آلاف دولار.. عشان يراجع الـ PRs.. وهو نايم.

الرابط المشترك اللي محدش خاد باله منه هو ده: لا PocketOS، ولا أمازون، ولا الـ 6,000 دولار.. ولا واحدة من دول كانت غلطة الذكاء الاصطناعي.

كل واحدة فيهم كانت فشل هندسي لابس ماسك الذكاء الاصطناعي.

الذكاء الاصطناعي كان مجرد عود الكبريت اللي لقى البنزين. بس في حد هو اللي ساب البنزين هناك.

2. الطفرة اللي محدش يقدر ينكرها

أنا مش هنا عشان أهاجم الـ vibe coding.

في ملايين الناس اللي مكنوش يعرفوا يكتبوا سطر كود واحد من 18 شهر، دلوقتي بيطلعوا برامج شغالة. ده إنجاز مبهر جداً. مزارعين بيعملوا أنظمة لتتبع المخزون. حلاقين بيعملوا أنظمة حجز. مؤسسين شركات ناشئة بيبنوا منتجات SaaS كاملة من غير ما يكتبوا فانكشن واحدة. حواجز الدخول للمجال انهارت. أي حد عنده فكرة ويقدر يكتب prompt يقدر يبني حاجة وتشتغل.

دي حاجة كويسة بجد. احتكار المجال انتهى. صناعة السوفت وير بتبقى ديمقراطية في الوقت الحالي.

بس في فرق كبير محدش بيعلمهولك: إنك تبني حاجة شغالة على اللاب توب بتاعك، وإنك تبني حاجة شغالة الساعة 3 الفجر مع عملاء دافعين فلوس، ومسؤولية قانونية، وفيزا مربوطة بالنظام. دول مش نفس الحاجة. ومش بيحكمهم نفس القيود. ومش محتاجين نفس التفكير.

الـ Vibe coding بيعلمك إزاي تـ ship (تطلع الشغل).

أما هندسة الإنتاج (Production engineering) بتعلمك إزاي تنجو من اللي هيحصل بعد ما تـ ship.

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

البوست ده مش بيلوم الـ vibe coders. البوست ده عشان يوضح الفرق ده. لأن الفرق ده بقى واضح دلوقتي، في حوادث حقيقية، بفلوس حقيقية ضاعت، والـ PocketOS الجاية مسألة وقت مش أكتر.

3. الديون الأمنية اللي محدش شايفها

خليني أديك الأرقام الأول.

شركة Veracode اختبرت أكتر من 100 نموذج لغوي كبير (LLM) في مهام برمجة حساسة أمنياً. 45% من الكود اللي اتكتب بالذكاء الاصطناعي كان فيه ثغرات من الـ OWASP Top 10. في الجافا الوضع أسوأ: 72% نسبة فشل. ثغرات الـ Cross-site scripting (XSS): نسبة فشل 86%. ونسبة النجاح ماتحسنتش من 2025 لأوائل 2026، بالرغم من إن كل شركات الذكاء الاصطناعي بتقول إن تدريب الأمان بتاعهم بقى أحسن.

شركة Apiiro حللت كود في عشرات الآلاف من الـ repositories لشركات الـ Fortune 50. المطورين اللي بيستخدموا الذكاء الاصطناعي بيعملوا commits أسرع 3 لـ 4 مرات من زمايلهم اللي مش بيستخدموه. ده يبان إنه مكسب. بس اسمع الباقي: الثغرات الأمنية الشهرية المكتشفة نطت من حوالي 1,000 لأكتر من 10,000. زيادة 10 أضعاف. أخطاء الـ Syntax قلت. أخطاء الـ Logic قلت. بس مسارات تصعيد الصلاحيات (Privilege escalation) زادت بنسبة 322%. وعيوب التصميم المعماري (Architectural design flaws) زادت بنسبة 153%.

الذكاء الاصطناعي بقى أحسن في كتابة جمل نظيفة، وبقى أسوأ في تصميم أنظمة آمنة.

جامعة جورجيا تك عملت حاجة اسمها Vibe Security Radar. ده بيفحص الـ open source repositories وبيرجع بالـ CVEs لمصدرها في الـ commits، باستخدام وكلاء ذكاء اصطناعي بيقروا تاريخ الـ Git عشان يحددوا لو الكود المليان ثغرات ده انكتب بأداة AI. في مارس 2026 لوحده، أكدوا 35 ثغرة (CVE). أداة Claude Code كان مسؤولة عن 27 من أصل 74 إجمالي. الرقم الحقيقي متوقع إنه يكون من 5 لـ 10 أضعاف: يعني في حدود من 400 لـ 700 ثغرة قابلة للاستغلال موجودة في مشاريع الـ open source المعروفة.

وبعدين عندنا حاجة اسمها الـ slopsquatting. مصطلح طلعه "سيث مايكل لارسون" في مؤسسة بايثون (Python Software Foundation). نماذج الذكاء الاصطناعي بتهلوس بأسماء باكدجات (packages)، و20% من الكود المولد بالذكاء الاصطناعي بيشير لباكدجات مش موجودة أصلاً. وعشان الهلاوس دي ممكن تتكرر، الهاكرز بيسجلوا الأسماء دي كباكدجات خبيثة. في حالة مؤكدة: باكدج اسمها "unused-imports" سرقت الـ credentials بعد ما نزلت. باكدج تانية من الهلاوس كانت فاضية ونزلت أكتر من 30,000 مرة في تلات شهور. الـ AI بيرشح باكدج. المطور بينزلها. والهاكر بياخد المفاتيح.

دي الواجهة الأمنية اللي الـ vibe coders مش شايفينها. مش عشان هم مهملين. بس عشان الأداة مش بتوضح ده. Cursor مش بيطلعلك تحذير يقولك "الكود اللي لسه كاتبه ده فيه احتمال 86% إنه يكون عرضة لـ XSS". Claude مش بيقولك "الباكدج اللي لسه مرشحهالك دي مش موجودة وممكن حد يسجلها بكرة بنية خبيثة". المطور بيشوف كود شغال. المستخدم بيشوف ميزة جديدة. الهاكر بيشوف باب مفتوح.

نرجع بقى لـ PocketOS، لأن الدرس ده محتاج مساحة لوحده.

سلسلة الفشل، حلقة بحلقة

الحلقة الأولى: فصل البيئات (environment separation). Cursor كان بيعمل مهمة عادية في بيئة المفروض إنها الـ production. الـ AI agent مكانه في sandbox. في بيئة التطوير (Development environment) ومع داتا وهمية (Dummy data). إنك تخلي AI agent يلمس الـ production ده زي ما تدي متدرب لسه متخرج root access في أول يوم ليه. متعملش كده. عمرك ما تعمل كده. دي مش مسألة أمان للـ AI. دي مسألة بنية تحتية (infrastructure).

الحلقة التانية: أقل الصلاحيات (least privilege). Cursor لقى API token ونفذ Volume Delete. التوكن ده كان المفروض يكون read-only. كان المفروض يكون محدود ببيئة تطوير، مش production. كان المفروض يطلب موافقة صريحة على أي عمليات مدمرة. توكن يقدر يمسح production volume ملوش أي مكان جنب لاب توب المطور، ما بالك بجلسة AI agent.

الحلقة التالتة: عزل الباك أب (backup isolation). منصة Railway بتخزن باك أب الـ volume جوة الـ volume نفسه. امسح الـ volume، هتمسح الباك أب. ده اختيار سيء في تصميم البنية التحتية. الانضباط الهندسي بقاله عقود ماشي بقاعدة 3-2-1: تلات نسخ، على وسيطين مختلفين، ونسخة بره الموقع (off-site). الباك أب لازم يكون بره منطقة الخطر (blast radius). في region تاني. في account تاني. عند مزود خدمة تخزين تاني. لو PocketOS كان عندهم باك أب في S3 bucket منفصل، وقت الاسترجاع كان هيبقى دقايق، مش شهور.

الحلقة الرابعة: بوابات الـ CI/CD. في أي مسار هندسي محترم، الـ agent بيكتب كود وبيفتح pull request. الـ CI بيشغل التست. إنسان بيوافق عليه. الـ CD بيعمل deploy. الـ agent ملوش طريق مباشر للـ production. الـ production credentials بتتحط وقت الـ deploy من secrets manager. الـ agent ممكن يكتب ألف سطر كود بايظ ومفيش سطر فيهم هيوصل لمستخدم حقيقي غير لما إنسان يقول أيوة.

الحلقة الخامسة: البنية التحتية ككود (Infrastructure as Code). لو الـ Railway volume ده كان بيتم إدارته بـ Terraform أو Pulumi، أمر Volume Delete يا إما كان هيترفض بسبب الـ state locking، أو كان هيرجع بـ terraform apply واحدة. البنية التحتية المفروض تكون declarative مش imperative. مابتمسحش حاجة بأوامر shell على API. أنت بتعدل ملف كونفيجريشن، بتراجعه، بتطبقه، وبترجعه (roll it back) لو بوظ حاجة.

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

الـ AI مكنش المفروض ياخد عود الكبريت.

والبنزين مكنش المفروض يبقى موجود هناك أصلاً.

4. فخ التكاليف: لما الـ Agent يحرق ميزانيتك وأنت نايم


الفشل الأمني بيعمل عناوين في الأخبار. فشل التكاليف بيعمل فواتير على الفيزا.

شوف اللي حصل للمطور اللي خسر 6,000 دولار في ليلة. هو كان مهندس. كان بيفهم كود. بس اللي مكنش بيفهمه هو نظام الفوترة (billing model) بتاع الذكاء الاصطناعي اللي كان بيستخدمه.

هو شغل /loop 30m check my PRs في Claude Code، باستخدام Claude Opus. وسابه شغال لوحده 26 ساعة. الـ loop اشتغل 46 مرة في sessions مختلفة على VMs مختلفة. على الساعة 20، تاريخ المحادثة كان وصل لحوالي 800,000 توكن.

هنا الفخ. Anthropic بتستخدم الـ prompt caching عشان تقلل التكلفة. لما بتبعت محادثة وبتطابق نسخة موجودة في الكاش، بتدفع سعر أرخص بتاع قراية الكاش (cache-read): أرخص 12.5 مرة من السعر الكامل. بس الكاش بيخلص صلاحيته بعد 5 دقايق من عدم النشاط. الـ loop بتاعه كان بيشتغل كل 30 دقيقة. يعني الكاش بيخلص كل مرة. وكل مرة كان بيعمل كاش من أول وجديد لتاريخ المحادثة اللي عمال يكبر، وده بالسعر الغالي بتاع الـ cache-write. وكل مرة جديدة كانت بتزود المخرجات بتاعتها على التاريخ ده. فالكاش اللي بعده كان بيبقى أكبر. التكلفة بقت بتتضاعف.

شغل مراجعة الـ PRs الفعلي كان مجرد فكة. إعادة الكاش (re-caching) كانت هي الفاتورة كلها.

استخدام Opus كان الغلطة التانية. Opus أغلى بحوالي 5 مرات لكل توكن مخرجات من Sonnet. لعمليات الـ polling التلقائية اللي الـ AI بس بيشوف فيها إذا كانت الـ PRs اتعملها merge ولا لأ، Sonnet أكتر من كافي. وفر Opus للشغل التفاعلي اللي جودة المخرجات بتفرق فيه. الـ vibe coder ميعرفش الفرق ده. بيختار الموديل اللي باين إنه الأقوى ويسيبه يشتغل.

والجزء اللي المفروض يرعب أي حد بيبني منتجات شغالة بالذكاء الاصطناعي: إن الداشبورد كدبت. داشبورد الاستخدام في Anthropic كانت متأخرة أيام. الإشارة الوحيدة اللي كانت في وقتها (real-time) هي الإيميل اللي بيقولك إنك وصلت للحد الأقصى للمصاريف (billing limit). ولما الإيميل وصل، كانت الفلوس طارت. ستة آلاف دولار.. عشان يراجع PRs.. وهو نايم.

أي شخص مش مهندس بيبني تطبيق بالذكاء الاصطناعي بيواجه نفس الخطر مع كل API integration. هم مش محتاجين يفهموا اقتصاديات التوكنز. مش محتاجين يفهموا الـ prompt caching، ولا تراكم الـ context window، ولا ليه loop كل 30 دقيقة مع انتهاء صلاحية الكاش كل 5 دقايق بيعملوا قنبلة فواتير. الأداة بتسحب من الفيزا وخلاص.

دي مش مشكلة ذكاء اصطناعي. دي مشكلة في تصميم المنصة (platform design) المهندسين بيحلوها بقالهم سنين: تحديد معدل الاستخدام (rate limiting)، فواصل الدوائر (circuit breakers)، حدود التكاليف (cost ceilings)، حدود قصوى (hard caps). Stripe بتخليك تحدد سقف مصاريف بضغطة واحدة. معظم منصات الذكاء الاصطناعي بتديك داشبورد بتعمل أبديت بعد تلات أيام من صرف الفلوس.

5. الخمس حواجز اللي بحطها على أي تطبيق Vibe-Coded

أنا بقالي سنين كتير ببني أنظمة إنتاج في الـ fintech والـ SaaS. وفي الـ 18 شهر اللي فاتوا بنيت تطبيقات بأسلوب الـ vibe coding. الفرق بين تطبيقاتي وتطبيقات أي حد مش مهندس مش في الذكاء الاصطناعي. الفرق في خمس حواجز حماية (guardrails) لبيئة الإنتاج. أنا بفرضهم من أول prompt.

مفيش ولا حاجة فيهم صعبة. بس كلهم مش متشافين لأي حد معملش run لـ production قبل كده.

الحاجز الأول: نظافة الأسرار (Secrets Hygiene)

أي API key، أي باسوورد داتا بيز، أي توكن لطرف تالت بيتحط في ملف .env. الملف ده معموله gitignore. عمره ما بيوصل للـ frontend. عمره ما بينزل للبراوزر. القيم اللي في .env بتكون credentials للتطوير بس: Stripe keys للـ sandbox، باسووردات لداتا بيز لوكال (local)، وTest SendGrid tokens. بتتبدل بـ credentials حقيقية للإنتاج في مرحلة الـ CI/CD، وبتنزل وقت الـ deploy من secrets manager. الـ agent عمره ما بيشوف أسرار الإنتاج. الـ agent مش محتاج يشوفها أصلاً.

الـ Vibe coders بيعملوا hardcode للمفاتيح. بيكتبوها في ملفات الـ config وبيعملولها commit. بيحطوها في الـ environment variables على Vercel وبينسوا إنها مكشوفة في الـ client-side bundles. أنا شفت API keys اتسحبت من repos عامة على GitHub واستخدموها في تعدين العملات الرقمية في خلال ساعات. الهاكر مش محتاج يكون عبقري. هو بس محتاج يعمل سكان على AWS_SECRET_ACCESS_KEY.

الحاجز التاني: الـ Containerization من أول يوم

أي تطبيق ببنيه، حتى لو كان prototype صغير، بيبقى ليه Dockerfile. مش عشان الـ prototype محتاج Kubernetes. بس عشان Docker معناه إن التطبيق هيشتغل بنفس الطريقة على جهازي، وعلى جهاز زميلي، وعلى أي كلاود هينزل عليه بعدين. معناه إن نسخة الـ Python، والـ system dependencies، والـ database driver، والـ environment variables، كلها متثبتة وقابلة لإعادة الإنتاج (reproducible). لما أحتاج أعمل scale لأكتر من نسخة (instance)، مش هقعد يومين أدور ليه التطبيق شغال عندي بس بيكراش في الإنتاج.

الـ Vibe coders بيعملوا pip install بشكل global وبيعملوا ship من اللاب توب بتاعهم. ولما ييجوا يعملوا deploy مفيش حاجة بتشتغل، ومش عارفين ليه، والـ AI مش بيعرف يعمل ديباج (debug) لأن الـ AI ميعرفش حالة الجهاز بتاعهم من جوة.

الحاجز التالت: حدود واضحة وعقود API صريحة

من أول خطوة، الـ frontend والـ backend بيكونو مفصولين بعقد API محدد، غالباً OpenAPI spec أو TypeScript type definition مشترك. الـ frontend مش بيكلم الداتا بيز دايركت. والـ backend ميعرفش حاجة عن الـ React state. بيتكلموا من خلال واجهة محددة (typed) وموثقة (documented). لو في زميل محتاج يكتب الـ backend بلغة تانية، الـ frontend مش هيحس بحاجة.

الـ Vibe coders بيبنوا ملف واحد بيعمل استعلام من الداتا بيز جوة component بتاع React. بيشتغل عندهم على الجهاز. بس بيبوظ بطرق خفية وغير متوقعة لما ترافيك حقيقي يخش عليه. الـ AI بيكتب اللي بيشتغل. مش بيبني هيكل (architect). ومش بيفرض حدود.

الحاجز الرابع: الانضباط في الـ Database Migration

أي تغيير في السكيما (schema) بيتم من خلال ملف migration: بنعمل migrate up عشان نطبقه، و migrate down عشان نرجعه. الـ migration ده بيكون ليه إصدار (versioned)، ومعموله commit، وبيشتغل كجزء من الـ CI/CD. مفيش أوامر ALTER TABLE يدوية. مفيش اختلاف بين البيئات. لو الـ migration فشل في الـ staging، عمره ما يوصل للإنتاج.

الـ Vibe coders بيدخلوا على الداتا بيز دايركت، يضيفوا عواميد (columns)، ويكملوا شغل. بعد تلات أسابيع محدش عارف الداتا بيز بتاعة الإنتاج شغالة على أي إصدار من السكيما. والـ AI مش هيقدر يساعد لأن الـ AI بيشوف الحالة الحالية بس، مش التاريخ، والتاريخ موجود في terminal مقفول من تلات أسابيع بتاع المطور.

الحاجز الخامس: الخدمات المدارة (Managed Services) أحسن من إنك تعملها بنفسك (DIY)

أنا مش بدير Kubernetes clusters إلا لو عندي تيم من 5 أفراد وعندي سبب قوي. بستخدم GCP Cloud Run. بستخدم managed Postgres. بستخدم managed Redis. بدفع فرق سعر عشان حد تاني يشيل هم التحديثات (patching)، والتوسع (scaling)، وحالات الفشل (failover)، والمراقبة (monitoring). المرونة اللي بكسبها من إني مبديرش بنية تحتية بتسوى أكتر من فرق الفلوس بكتير.

الـ Vibe coders ميعرفوش إيه اللي مش محتاجين يديروه. بيسمعوا "المفروض تستخدم Kubernetes" فيروحوا يعملوا cluster لـ prototype مستخدمين اتنين. أو يسمعوا "الـ serverless هو المستقبل" ويبنوا على Lambda من غير ما يفهموا الـ cold starts، ولا الـ concurrency limits، ولا إن الفانكشن بتاعتهم بيحصلها timeout بعد 30 ثانية على الخطط المجانية. وبعدين بيدفعوا تمن التعقيد وفترات انقطاع الخدمة مع بعض.

الخمس حواجز دول هم الحد الأدنى. مش الحد الأقصى. دول الخط الفاصل بين "شغال عندي" و "شغال لواحد غريب بفيزا الساعة 3 الفجر". الـ AI مش هيقترحهم. الـ AI هيبنيلك تطبيق شغال زي الفل بكل بساطة وهو بيسرب الـ credentials في الـ frontend bundle بتاعك.

6. الناس اللي هتحتاجهم (وليه مينفعش تستغنى عنهم)

مفيش زرار configuration بيحول הـ prototype لمنصة. مفيش prompt بتكتبه يخلي التطبيق production grade. مفيش زرار "vibe to production".

لما الـ prototype يجيب مستخدمين بجد، بتعين مهندسين. نقطة ومن أول السطر.

ومش قصدي تعين حد خلص bootcamp تلات شهور وعمل تطبيق to-do بـ Claude. قصدي تعين حد اتصحى الساعة 3 الفجر عشان يصلح داتا بيز للإنتاج كانت مولعة. حد شاف deploy بيتعمله roll back. حد كتب postmortem وكان قاصد كل كلمة فيه. حد عارف هو بيسيب إيه لما بيقرر يتجاهل خطوة معينة.

ده التمن الحقيقي للـ production grade. مش أداة. مش checklist. التمن في الناس اللي عملت ده قبل كده.

الـ Vibe coding وصلنا للـ beta. بس الهندسة هي اللي هتوصلنا للـ production. مفيش طريق مختصر.

7. إيه اللي بتوع "Ship Fast" بيفهموه صح وإيه اللي بيفهموه غلط

كل شركة ناشئة المفروض تـ ship بسرعة. أنا مؤمن بده. أنا طول عمري المهني بـ ship بسرعة. عملت deploys يوم الجمعة ونزلت أتعشى - hot fixes ;).

بس في فرق بين السرعة والتهور، والفرق ده هو إنك تبقى عارف إنت بتعدي إيه بالظبط.

لما بعمل skip لحاجة، ببقى عارف إيه هي. عارف تمنها. عارف الإشارة اللي هتقولي "الخطوة دي مبقاش ينفع نتجاوزها". أنا عارف إن 3 مستخدمين من غير دخل مش محتاجين Redis cluster، وعارف إن 50 عميل دافعين فلوس وعندهم SLA معناها إن الوقت جه عشان أعملها.

الـ Vibe coders بيعدوا حاجات هم أصلاً ميعرفوش إنها موجودة. بيتجاهلوا فصل البيئات. بيتجاهلوا عزل الباك أب. بيتجاهلوا الـ API rate limiting. بيتجاهلوا الحاجة اللي هتحرقهم، لأن الـ AI مجابش سيرتها، وصورتهم الذهنية عن "إيه اللي تطبيق الإنتاج بيحتاجه" معتمدة بالكامل على اللي الـ AI بيطلعهولهم.

مبدأ "move fast and break things" (اتحرك بسرعة واكسر الدنيا) بيفترض إنك عارف إيه اللي ممكن يتكسر. بيفترض إنك شفت طرق الفشل دي قبل كده وأخدت قرار واعي. بيفترض إنك هتعرف تصلح الحاجة لما تتكسر لأنك فاهم هي شغالة إزاي.

الـ Vibe coders معندهمش أي افتراض من دول. هم مبنوش الحاجة دي. هم بس وصفوها. والـ AI هو اللي بناها. ولما بتبوظ، مش بيعرفوا يصلحوها لأنهم مش فاهمين هي شغالة إزاي، ولا بتعتمد على إيه، ولا إيه هي نقط الضعف أصلاً. الـ AI هو الشخص الوحيد اللي فاهم الكود، والـ AI مش بيشتغل on call.

ده مش انتقاد لمبدأ إنك تـ ship بسرعة. ده انتقاد لإنك تـ ship وأنت أعمى.

في لحظة كل مهندس إنتاج بيعرفها. هي اللحظة اللي بين الـ deploy والانتظار. إنت عملت deploy. بتبص على الداشبوردات. وبتسمع. اللحظة دي، لحظة الهدوء دي، إنت اللي كسبتها. كسبتها لأنك عارف إيه اللي ممكن يبوظ وشيَكت على كل حاجة. الـ vibe coder ميعرفش إيه اللي ممكن يبوظ، فمش بيشيّك على حاجة، ومش بيستنى، ومش بيحس بالهدوء ده. هو بس بيقفل اللاب توب وأول علامة إن في مشكلة بتكون تويتة من مستخدم زعلان.

8. إيه اللي لسه بحاول أفهمه

معنديش نهاية مثالية للبوست ده.

إحنا عارفين الـ checklist بتاعة هندسة الإنتاج بقالنا عقود. فصل البيئات. أقل الصلاحيات. عزل الباك أب. إدارة الأسرار. بوابات الـ CI/CD. الانضباط في الـ Migrations. ده مش سر. مش حاجة حصرية. دي مكتوبة في كل كتاب، كل بلوج، كل postmortem من أي شركة ضيعت داتا الساعة 3 الفجر قبل كده.

ورغم كده، في ملايين الناس بتبني سوفت وير دلوقتي وعمرهم ما هيشوفوا الـ checklist دي غير لما يتلسعوا منها. الـ AI مش هيورهالهم. المنصات مش هتورهالهم. الدروس التعليمية (tutorials) مش هتورهالهم. هيـ ship، هيجيبوا مستخدمين، وهيتعلموا بالطريقة الصعبة.

إيه هي طريقة التوصيل؟ إزاي نحط الوعي بتاع الـ production grade في قالب يخلي الـ vibe coder يشوفه قبل ما تحصل المصيبة؟

الـ Documentation مش هيعمل ده. محدش بيقرا وثائق قبل ما يحتاجها. الـ Linters مش هتعمل ده. Cursor مش هيقدر يطلعلك linter error يقولك "إنت اديتني production token". المنصات معندهاش حافز تعمل ده. Anthropic بتحاسبك بالتوكن، مش بالحوادث اللي بتمنعها. Vercel بتعمل فلوس لما إنت بتعمل deploy، مش لما بتعمل deploy بأمان.

يمكن الحل يكون في checklist قبل الـ deploy تمنعه يكمل. بوابة تقولك "أثبت إن الباك أب بتاعك معزول" و "أثبت إن الـ agent بتاعك مش هيقدر يلمس الإنتاج" قبل ما مسار الـ CD يشتغل. يمكن يكون شهادة، أو شارة (badge)، أو معيار في الـ community: حاجة زي "production verified"، شبه العلامة الزرقاء بس للبنية التحتية.

يمكن يكون ده مجرد طقس عبور (rite of passage). يمكن لازم كل واحد يـ ship حاجة وتحرقه مرة، واللي بيعيشوا من الحرق ده هم اللي بيبقوا المهندسين اللي الـ startups بتعينهم بعد كده.

أنا مش عارف. أنا عارف الـ checklist. عارف إنها مش بتوصل للناس. وعارف إن الـ PocketOS الجاية هي مجرد مسألة وقت.

المراجع (References)

PocketOS

Amazon Outages (انقطاع خدمة أمازون)

$6,000 Claude Loop (مشكلة الـ 6,000 دولار)

Veracode GenAI Code Security (أمان الكود من Veracode)

Apiiro (بيانات Fortune 50)

Georgia Tech Vibe Security Radar

Slopsquatting

Lightrun 2026 Report

CSA Research Note (ملاحظات أبحاث CSA)