أدوات

مراجعة Lovable

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

  • Review
  • 25.09.2026
  • 5 د للقراءة

Lovable هي أداة بناء التطبيقات التي حوّلت البرمجة بالإيحاء (vibe coding) إلى تجارة. تصفون تطبيقًا في محادثة، فتكتب Lovable الشيفرة، وتُعدّ قاعدة البيانات وتسجيل الدخول، وتنشر النتيجة على الإنترنت. أُطلقت الشركة التي تتخذ من ستوكهولم مقرًا لها في نوفمبر 2024. وفي أغسطس جمعت 400 مليون دولار بتقييم بلغ 13.3 مليار دولار، وفي سبتمبر قال أحد مؤسسيها، فابيان هيدين، إن إيراداتها السنوية المحسوبة على أساس الوتيرة الحالية تجاوزت 600 مليون دولار.

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

ما الذي تجيده

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

وكثيرون يريدون ذلك تحديدًا. تقول Lovable إن مستخدميها أنشأوا أكثر من 60 مليون مشروع منذ الإطلاق، وإن التطبيقات المبنية عليها تحظى بأكثر من 900 مليون زيارة شهريًا، وإن موظفين في نحو ثلثي شركات Fortune 500 يستخدمونها. وفي استطلاع أجرته بين مستخدميها، قال نحو ثمانية من كل عشرة إنهم يبنون مشروعًا تجاريًا أو جانبيًا يأملون أن يكسبوا منه.

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

كل شيء يتشابه

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

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

مَن يتحمّل مسؤولية الأمان

السؤال الأخطر هو الأمان. في مارس 2025 اكتشف مات بالمر، الذي كان يعمل آنذاك لدى المنافس Replit، أن موقعًا مبنيًا بـLovable يكشف بيانات مستخدميه، لأن قواعد قاعدة البيانات التي تحدد من يحق له قراءة أي صفوف كانت مفقودة أو خاطئة. وعند فحص 1,645 مشروعًا من واجهة العرض الخاصة بـLovable، وجد هو وزملاؤه الباحثون 303 نقاط وصول معرّضة للخطر في 170 مشروعًا منها، كشفت أسماء وعناوين بريد إلكتروني وتفاصيل دفع ومفاتيح API خاصة بالمطورين. وسُجّلت الثغرة باسم CVE-2025-48757، بدرجة خطورة 9.3 من 10. وتعترض Lovable عليها، بحجة أن كل عميل مسؤول عن حماية بيانات تطبيقه.

وفي أبريل 2026 أظهر باحث أن أي حساب على Lovable يستطيع قراءة الشيفرة المصدرية وسجل محادثات الذكاء الاصطناعي في المشاريع العامة التي يملكها مستخدمون آخرون. كتبت Lovable أولًا على X: «لنكن واضحين: لم نتعرض لاختراق للبيانات». وبعد يومين نشرت رواية أكمل: تغيير أُجري في فبراير أعاد فتح وصول كانت قد أغلقته في 2025، وبلاغات وصلت إلى برنامج مكافآت الثغرات لديها أُغلقت من دون تصعيد، وقصّر كل من منتجها وردّها الأول. ووصفت The Register ما جرى بأنه «درس في كيف لا ينبغي الرد على بلاغات الثغرات».

والنمط يتجاوز Lovable. ففي سبتمبر وجدت شركة الأمن UpGuard نحو 16,000 قاعدة بيانات على Supabase، خدمة قواعد البيانات التي تقف وراء تطبيقات Lovable، فيها جداول يستطيع أي شخص قراءتها، وكثير منها يحوي بيانات شخصية، وربطت TechCrunch هذه الموجة بتطبيقات بُنيت على عجل بالذكاء الاصطناعي. وتقول Supabase إن مشاريعها آمنة افتراضيًا وإن العملاء يتحكمون في إعداداتهم. والأمران قد يصحّان معًا. وبينهما يقف في الغالب مؤسس لم يحتج قط إلى تعلّم ما هي قاعدة الوصول في قاعدة البيانات.

الارتهان للمنصة والتكلفة

الشيفرة نفسها يمكن أن تغادر. تقول وثائق Lovable إن التطبيقات والشيفرة والمحتوى الذي تنشئونه ملك لكم، وإن كل الخطط تتيح المزامنة مع مستودع على GitHub، وإن الواجهة الأمامية يمكن استضافتها في أي مكان. أما الخادم الخلفي فمسألة أخرى. فإذا كان التطبيق يعمل على Lovable Cloud، فإن طرق الخروج المدعومة هي Supabase المُدارة أو Supabase المستضافة ذاتيًا. ونقل قاعدة البيانات وحدها لا ينقل تسجيل الدخول ولا تخزين الملفات ولا التحديثات الفورية ولا وظائف الحافة (edge functions)، وبالنسبة إلى PostgreSQL المجردة أو مزود آخر تقول Lovable إنها لا تدعم الانتقال. أما المحرر ووكيله فلا يمكن استضافتهما ذاتيًا على الإطلاق.

التكلفة تقوم على الأرصدة (credits). تبدأ خطة Pro بـ25 دولارًا شهريًا مقابل 100 رصيد، وخطة Business بـ50 دولارًا، وكلتاهما تتدرج حتى 10,000 رصيد؛ و1,200 رصيد على Pro تكلف 294 دولارًا شهريًا. وما دام التطبيق باقيًا على Lovable، فإن استضافته وميزات الذكاء الاصطناعي فيه وموصلاته تستهلك من الأرصدة نفسها التي يستهلكها البناء.

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

حكمنا

Lovable من أسرع الطرق لوضع فكرة أمام الناس، واستخدامها متعة. استخدموها للنماذج الأولية والعروض التقديمية والأدوات الداخلية التي لا تحمل بيانات حساسة. وقبل أن يصل عملاء حقيقيون ببياناتهم، اربطوا GitHub من اليوم الأول، واطلبوا من شخص يفهم في الأمان أن يراجع كل قاعدة في قاعدة البيانات، وقرروا هل ينبغي أن يبقى التطبيق على Lovable Cloud.

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