فجوة التحقق التي لا يتحدث عنها أحد
صاغ Andrej Karpathy مصطلح “vibe coding” في منشور على X في فبراير 2025، واصفاً ممارسة يقوم فيها المطورون بـ”الاستسلام الكامل للأجواء” وترك الذكاء الاصطناعي يكتب كودهم. في غضون عام، انتقل vibe coding من عبارة جذابة — اختيرت كلمة العام 2025 من قاموس Collins — إلى النمط الافتراضي لحصة هائلة من تطوير البرمجيات.
تؤكد الأرقام عمق اختراق الذكاء الاصطناعي لهذه الحرفة. وجد بحث DX الذي شمل 121,000 مطور في أكثر من 450 شركة أن 92.6% يستخدمون مساعد برمجة بالذكاء الاصطناعي مرة واحدة على الأقل شهرياً، مع استخدام حوالي 75% له أسبوعياً. وفقاً لـاستطلاع State of Code 2026 من Sonar، يمثل الذكاء الاصطناعي 42% من كل الكود المُرسَل — حجم يتوقع المطورون أن يصل إلى 65% بحلول 2027.
لكن هنا تصبح الأرقام مثيرة للقلق. كشف استطلاع Sonar نفسه أن 96% من المطورين لا يثقون بالكامل في الكود المُولَّد بالذكاء الاصطناعي، ومع ذلك فإن 48% فقط يتحققون منه دائماً قبل إرساله. فجوة التحقق هذه — اعتماد عالٍ ورقابة منخفضة — هي المحرك الذي يدفع أزمة أمنية عبر صناعة البرمجيات.
ما مدى ضعف الكود المُولَّد بالذكاء الاصطناعي؟
وجد تقرير State of AI vs Human Code Generation من CodeRabbit، الذي حلل 470 طلب سحب حقيقي، أن الكود المُولَّد بالذكاء الاصطناعي ينتج 1.7 ضعف المشاكل مقارنة بالكود البشري عبر فئات المنطق والصيانة والأمن والأداء. في أنواع الثغرات المحددة، تتسع الفجوات أكثر: كود الذكاء الاصطناعي أكثر عرضة بـ2.74 ضعف لإدخال ثغرات البرمجة النصية عبر المواقع (XSS)، و1.91 ضعف لإنشاء مراجع كائنات غير آمنة، و1.88 ضعف لسوء التعامل مع كلمات المرور.
وجد بحث مستقل من Apiiro، يفحص شركات Fortune 50، أن الثغرات ذات درجة CVSS 7.0 أو أعلى تظهر بمعدل 2.5 ضعف في الكود المُولَّد بالذكاء الاصطناعي مقارنة بالكود البشري.
وضع فريق أمان Escape.tech هذه المخاطر في صورة ملموسة. بعد مسح أكثر من 5,600 تطبيق vibe-coded منشور علنياً مبني على منصات مثل Lovable وBolt.new وBase44، حددوا أكثر من 2,000 ثغرة عالية التأثير، وأكثر من 400 سر مكشوف — مفاتيح API وبيانات اعتماد قواعد البيانات ورموز المصادقة — و175 حالة كانت فيها البيانات الشخصية بما في ذلك السجلات الطبية والتفاصيل المالية متاحة للعموم.
تجسد منصة Lovable هذا النمط. عندما فحص الباحثون 1,645 تطبيقاً مبنياً بـLovable، كان لدى 170 منها — أي 10.3% — قواعد بيانات مكشوفة بالكامل دون أي Row-Level Security مُفعَّل، مما أكسبها CVE-2025-48757. بحلول فبراير 2026، اكتشف باحث آخر 16 ثغرة في تطبيق عرض واحد من Lovable كشفت البيانات الشخصية لأكثر من 18,000 مستخدم.
لماذا تنتج نماذج الذكاء الاصطناعي كوداً غير آمن
يتطلب فهم السبب الجذري فحص كيفية تعامل النماذج اللغوية الكبيرة مع توليد الكود. تتدرب هذه النماذج على مجموعات ضخمة مستمدة من المستودعات العامة والدروس التعليمية وإجابات Stack Overflow — كود يعطي الأولوية للوضوح والتوضيح على حساب الأمان الدفاعي.
عادةً ما تستخدم إجابة Stack Overflow التي توضح استعلامات قواعد البيانات تسلسل السلاسل النصية بدلاً من الاستعلامات المعلمة لأنها أسهل في الفهم. يستوعب النموذج، المُدرَّب على آلاف الأمثلة المشابهة، هذا النمط كالأسلوب الافتراضي. تعتمد تكوينات الأمان على السياق — تعتمد ضوابط الوصول والتشفير المناسبة على بيئات النشر ونماذج التهديد المحددة التي لا يمكن لموجه عام التقاطها.
والأهم من ذلك، تفتقر نماذج الذكاء الاصطناعي إلى التفكير العدائي. فهي تولد كوداً يعالج المدخلات المتوقعة وينتج المخرجات المتوقعة. لا تتوقع ما يحدث عندما يرسل مهاجم بيانات مشوهة أو يستغل حالات السباق أو يربط ثغرات صغيرة لتحقيق تصعيد الامتيازات. هذه العقلية العدائية — التفكير كمهاجم — هي بالتحديد ما يقدمه مهندسو الأمان لمراجعة الكود، وبالتحديد ما يتجاوزه سير عمل vibe coding.
إعلان
إنذار Moltbook
أصبحت المخاطر النظرية واقعاً ملموساً في فبراير 2026 عندما فحص باحثو أمان Wiz منصة Moltbook، وهي منصة تواصل اجتماعي لوكلاء الذكاء الاصطناعي بُنيت بالكامل بأسلوب vibe coding. مفتاح API لـSupabase مكشوف في JavaScript على جانب العميل، مقترناً بغياب تام لـRow-Level Security، منح المستخدمين غير المصادق عليهم وصولاً كاملاً للقراءة والكتابة لكامل قاعدة بيانات الإنتاج.
شملت البيانات المكشوفة 1.5 مليون رمز مصادقة API، و35,000 عنوان بريد إلكتروني، ورسائل خاصة بين الوكلاء، ومفاتيح API لـOpenAI بنص واضح مشاركة في المحادثات. كان بالإمكان اختطاف أي حساب على المنصة باستدعاء API واحد. أظهر الحادث كيف يمكن للثغرة الجوهرية في vibe coding — شحن كود وظيفي دون مراجعة أمنية — أن تحول مفتاح API عاماً قياسياً إلى باب خلفي على مستوى المسؤول.
مفارقة الثقة
وثق استطلاع مطوري Stack Overflow تحولاً لافتاً: انخفضت النظرة الإيجابية لأدوات البرمجة بالذكاء الاصطناعي من 72% إلى 60% في عام واحد. بيانات Sonar أكثر حدة — 61% من المطورين يوافقون على أن “الذكاء الاصطناعي غالباً ما ينتج كوداً يبدو صحيحاً لكنه غير موثوق”، و38% يقولون إن مراجعة الكود المُولَّد بالذكاء الاصطناعي تتطلب جهداً أكبر من مراجعة الكود المكتوب من الزملاء.
لكن السلوك لم يلحق بالوعي. يعلن المطورون ثقة أقل لكنهم يستمرون في شحن الكود المُولَّد بالذكاء الاصطناعي بنفس المعدلات أو أعلى. حوافز الإنتاجية — التسليم الأسرع، والمزيد من الميزات في كل سباق تطوير، والضغط التنافسي من الشركات الناشئة القائمة على الذكاء الاصطناعي — تتغلب على المخاوف الأمنية. تعلم المؤسسات أن المخاطر موجودة لكنها لم تعد هيكلة سير عمل التطوير أو عمليات المراجعة الأمنية لتتناسب مع ملف المخاطر المختلف جوهرياً للكود المُولَّد بالذكاء الاصطناعي.
ما تفعله الفرق الناضجة بشكل مختلف
تتعامل المؤسسات التي تدير هذه الأزمة بفعالية مع مساعدي البرمجة بالذكاء الاصطناعي كمضاعفات قوة لمطورين أكفاء، وليس كبدائل لممارسات تطوير كفؤة. تبرز عدة أنماط.
عمليات مراجعة متعددة الطبقات. يمر الكود المُولَّد بالذكاء الاصطناعي عبر مسح أمني آلي، وتوليد اختبارات آلي، ومراجعة الأقران مع اهتمام خاص بأنماط الأمان، ومراجعة فريق الأمان للمكونات الحساسة. هذا أبطأ من vibe coding الخام لكنه أسرع بكثير من كتابة كل شيء يدوياً.
موجهات موجهة أمنياً. بدلاً من قبول مخرجات الذكاء الاصطناعي الافتراضية، يضمّن المطورون متطلبات الأمان صراحة. يتحول “ابنِ نظام تسجيل دخول” إلى “ابنِ نظام تسجيل دخول مع استعلامات معلمة وتجزئة bcrypt وتحديد معدل الطلبات وحماية CSRF وإدارة جلسات آمنة”. النتائج أفضل بشكل ملموس، وإن كانت لا تزال غير مثالية.
ضوابط على مستوى البنية. بدلاً من الاعتماد كلياً على كود التطبيق للأمان، تنشر المؤسسات بوابات API مع تحديد معدل مدمج، وشبكات عدم الثقة، وضوابط وصول على مستوى قاعدة البيانات مستقلة عن كود التطبيق، وقوالب البنية التحتية ككود التي تفرض خطوط أساس أمنية بغض النظر عن جودة الكود.
مقاييس أمنية خاصة بالذكاء الاصطناعي. بعيداً عن سرعة التسليم، تتتبع الفرق الناضجة كثافة الثغرات لكل وحدة مولدة بالذكاء الاصطناعي، ووقت اكتشاف العيوب المُدخلة بالذكاء الاصطناعي، ونسبة الكود المُولَّد بالذكاء الاصطناعي الذي يجتاز المراجعة الأمنية دون تعديل.
مسألة المسؤولية القانونية
مع تكاثر الكود المُولَّد بالذكاء الاصطناعي في أنظمة الإنتاج، يتطور المشهد القانوني. قانون الذكاء الاصطناعي الأوروبي، الذي تدخل التزامات الأنظمة عالية المخاطر فيه حيز التنفيذ في 2 أغسطس 2026، يصنف نماذج الذكاء الاصطناعي العامة ضمن متطلبات الشفافية والتوثيق. تصل غرامات عدم الامتثال إلى 35 مليون يورو أو 7% من الإيرادات العالمية، مع مواجهة المديرين لمسؤولية شخصية محتملة.
لم تُصمَّم الأطر القانونية الحالية لكود لم يكتبه مطور بشري ولا منتج برمجي تقليدي. تفترض مسؤولية المنتج صانعاً بشرياً. يفترض الإهمال المهني حكماً بشرياً. يقع الكود المُولَّد بالذكاء الاصطناعي في فجوة بين هذه الأطر — فجوة بدأ المنظمون وشركات التأمين والمحاكم في معالجتها.
الدلالة العملية واضحة: الافتراض بأن الكود المُولَّد بالذكاء الاصطناعي يمكن نشره بنفس حوكمة الكود البشري أصبح غير قابل للدفاع قانونياً. تحتاج المؤسسات إلى توثيق ومسارات مراجعة والتحقق الأمني لإثبات العناية الواجبة.
الأسئلة الشائعة
ما هو vibe coding ولماذا أصبح مصدر قلق أمني؟
Vibe coding هو ممارسة استخدام مساعدي البرمجة بالذكاء الاصطناعي لتوليد أجزاء كبيرة من كود التطبيقات من موجهات بلغة طبيعية، غالباً دون مراجعة شاملة سطراً بسطر. صاغه Andrej Karpathy في فبراير 2025، ويصف المصطلح المطورين الذين “يستسلمون للأجواء” ويشحنون مخرجات الذكاء الاصطناعي بأقل قدر من التدقيق. أصبح مصدر قلق أمني لأن تحليل CodeRabbit لـ470 طلب سحب أثبت أن الكود المُولَّد بالذكاء الاصطناعي ينتج 1.7 ضعف المشاكل مقارنة بالكود البشري، مع ظهور أنواع ثغرات محددة مثل البرمجة النصية عبر المواقع بمعدل 2.74 ضعف. كشف مسح Escape.tech لـ5,600 تطبيق vibe-coded عن أكثر من 2,000 ثغرة و400+ سر مكشوف في أنظمة إنتاج حية.
هل يمكن للمؤسسات استخدام أدوات البرمجة بالذكاء الاصطناعي بأمان، أم يجب تجنبها كلياً؟
يمكن استخدام أدوات البرمجة بالذكاء الاصطناعي بأمان، لكنها تتطلب حوكمة مختلفة عن التطوير التقليدي. المفتاح هو التعامل مع مخرجات الذكاء الاصطناعي كمسودة أولى تحتاج مراجعة أمنية، وليس ككود جاهز للإنتاج. المؤسسات التي تطبق عمليات متعددة الطبقات — مسح أمني آلي في CI/CD، ومراجعة أقران واعية بالذكاء الاصطناعي، وإشراف بشري إلزامي على المكونات الأمنية الحرجة مثل المصادقة والوصول إلى البيانات — يمكنها الاستفادة من مكاسب الإنتاجية مع إدارة مخاطر الثغرات. وجد استطلاع Sonar 2026 أن الفرق التي تتحقق دائماً من كود الذكاء الاصطناعي قبل إرساله تقلل بشكل كبير من تعرضها مقارنة بالـ52% الذين لا يفعلون ذلك.
من يتحمل المسؤولية القانونية عندما يتسبب كود مُولَّد بالذكاء الاصطناعي في اختراق بيانات؟
تتحمل المؤسسة التي تنشر الكود المسؤولية الأساسية بموجب لوائح حماية البيانات مثل GDPR والأطر التنظيمية القطاعية. يضيف قانون الذكاء الاصطناعي الأوروبي، الذي تدخل التزامات الأنظمة عالية المخاطر فيه حيز التنفيذ في 2 أغسطس 2026، طبقات جديدة: تصل غرامات عدم الامتثال إلى 35 مليون يورو أو 7% من الإيرادات العالمية، ويواجه المديرون مسؤولية شخصية محتملة. يتمتع مزودو أدوات الذكاء الاصطناعي حالياً بمسؤولية محدودة بموجب اتفاقيات الترخيص، رغم أن هذا يتطور. الدرس العملي هو أنه يجب على المؤسسات توثيق عمليات مراجعة كود الذكاء الاصطناعي لإثبات العناية الواجبة — فالافتراض بأن الكود المُولَّد بالذكاء الاصطناعي يمكن حوكمته مثل الكود البشري أصبح غير قابل للدفاع قانونياً.
—
المصادر والقراءات الإضافية
- Escape.tech — Methodology: 2K+ Vulnerabilities in Vibe-Coded Apps
- CodeRabbit — State of AI vs Human Code Generation Report
- Sonar — State of Code Developer Survey Report 2026
- Wiz — Exposed Moltbook Database Reveals Millions of API Keys
- Stack Overflow — Closing the Developer AI Trust Gap
- Superblocks — Lovable Vulnerability Explained: How 170+ Apps Were Exposed
- DX — Measuring AI Code Assistants and Agents
- The Register — AI-Authored Code Needs More Attention, Contains Worse Bugs
