لقد قمت بترميز MVP الخاص بك. الآن أنت عالق.

لقد بنيت شيئا حقيقيا. لقد فتحت Lovable أو Bolt.new، ووصفت فكرتك بلغة إنجليزية بسيطة، وشاهدت تطبيقًا فعالاً يظهر خلال دقائق. لقد نقرت من خلال الشاشات. لقد أظهرت ذلك للأصدقاء. لقد قمت بنشره على X وحصلت على أول ردودك "هذا مريض". هذا أمر مثير للإعجاب، ويجب أن تشعر بالرضا حيال ذلك.

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

لقد اصطدمت بالحائط. وأنت لست وحدك.

جدار 80/20: حيث ينهار التشفير

تعتبر أدوات البرمجة الحيوية مثل Lovable وBolt.new وReplit Agent وv0 استثنائية في أول 80% من المنتج. إنهم يقومون بإنشاء مكونات واجهة المستخدم، وربط قواعد البيانات، وإنشاء تدفقات المصادقة، وإنتاج شيء يبدو وكأنه تطبيق حقيقي. بالنسبة للنماذج الأولية والتحقق من صحتها، فهي أسرع مسار موجود على الإطلاق من الفكرة إلى العرض التوضيحي.

المشكلة هي الـ 20% الأخيرة. هذا هو المكان الذي تعيش فيه حالات الحافة. هذا هو المكان الذي تحتاج فيه معالجة الدفع إلى التعامل مع الرسوم الفاشلة والمبالغ المستردة الجزئية وإعادة محاولة الرد على الويب. هذا هو المكان الذي يحتاج فيه النموذج متعدد الخطوات إلى حفظ التقدم والتحقق من صحة الخطوات والتعافي من أعطال المتصفح. هذا هو المكان الذي يجب أن يعمل فيه تطبيقك عندما يقوم مستخدمان بتحرير نفس السجل في نفس الوقت.

يتعامل الذكاء الاصطناعي مع المسار السعيد ببراعة. إنها تكافح مع المسارات غير السعيدة، وبرامج الإنتاج هي مسارات غير سعيدة بنسبة 80٪. ماذا يحدث عندما تنقطع الشبكة في منتصف المعاملة؟ عندما يرسل المستخدم نموذجا مرتين؟ عندما يُرجع استعلام قاعدة البيانات الخاصة بك 50000 صفًا بدلاً من 50؟ هذه هي الأسئلة التي تفصل بين العرض التوضيحي والمنتج، وهي الأسئلة التي لا تستطيع أدوات البرمجة الحيوية الإجابة عليها من خلال مطالبة واحدة.

يطلق المطورون على هذا اسم جدار 80/20. أول 80% يأخذ 20% من الجهد. آخر 20% يأخذ 80% من الجهد. تعمل أدوات البرمجة Vibe على ضغط أول 80% من الأسابيع إلى الساعات. لكنهم لا يضغطون نسبة الـ 20% الأخيرة على الإطلاق. إنهم يجعلون الأمر أكثر صعوبة، لأن الكود الذي أنشأوه لم يكن مصممًا للتعامل معه.

المشكلة الأمنية لا أحد يتحدث عنها

إليك الجزء الذي يجب أن يبقيك مستيقظًا في الليل. وجد تحليل أمني للتطبيقات التي تم إنشاؤها بواسطة Lovable ذلك10.3% لديهم عيوب أمنية خطيرة على مستوى الصف (RLS).في قواعد بيانات Supabase الخاصة بهم. وهذا يعني أن واحدًا من كل عشرة تطبيقات يحتوي على جداول قاعدة بيانات حيث يمكن لأي مستخدم مصادق عليه قراءة بيانات المستخدمين الآخرين أو تعديلها أو حذفها. ليست مخاطرة نظرية. استغلال العمل.

هذا لا يقتصر على محبوب. وجد تحليل CodeRabbit لـ 470 طلب سحب أن التعليمات البرمجية التي تم إنشاؤها بواسطة الذكاء الاصطناعي قد تم تنفيذهاارتفاع معدلات الضعف الأمني ​​بمقدار 2.74 مرةمقارنة بالكود المكتوب بواسطة الإنسان. وجد نفس التحليل1.7x المزيد من القضايا الكبرىإجمالي. الذكاء الاصطناعي يكتب الكود الذي يعمل. لا يكتب رمزًا آمنًا.

العواقب في العالم الحقيقي موجودة بالفعل هنا. Moltbook، عبارة عن شبكة اجتماعية مبنية على الذكاء الاصطناعي، تم إطلاقها مع قاعدة بيانات Supabase الخاصة بها والتي يمكن الوصول إليها بشكل عام. النتيجة:تم الكشف عن 1.5 مليون مفتاح API و35000 بريد إلكتروني للمستخدم. وجدت مراجعة مستقلة ذلكتعرض 11% من عناوين URL الخاصة بالتشغيل المستقل بيانات اعتماد Supabase في كود الواجهة الأمامية الخاصة بها. هذه ليست حالات الحافة. إنها أنماط.

أدوات Vibe coding لا تشرح لك الأمان لأنك لم تسأل عن الأمان. لقد طلبت نموذج تسجيل مستخدم، وحصلت على واحد. لم تطلب "التأكد من عدم تمكن المستخدمين من الوصول إلى بيانات بعضهم البعض من خلال استدعاءات واجهة برمجة التطبيقات المباشرة"، لذا لم تقم الأداة بإعداد ذلك. سياسات RLS، نطاق مفتاح API، تعقيم المدخلات، تحديد المعدل؛ هذه هي الأشياء التي يضيفها المهندسون ذوو الخبرة افتراضيًا لأنهم رأوا ما يحدث عندما لا تفعل ذلك.

فخ حرق الائتمان

يتم تحصيل رسوم أدوات ترميز Vibe عن طريق الاعتمادات أو الرموز المميزة أو حساب الوقت. العرض التقديمي بسيط: قم بوصف ما تريده، واحصل على كود العمل، ثم كرره. الواقع مختلف.

تقرير المستخدمين المحبوبينحرق 400 نقطة في أقل من ساعةعند تصحيح ميزة معقدة. يصف مستخدمو Bolt.new الوقوع في فخحلقات خطأ لا نهاية لهاحيث يقوم الذكاء الاصطناعي بكسر شيء واحد أثناء إصلاح شيء آخر. عبر المنصات، يقوم المستخدمون بالإبلاغ عن الإنفاق30-40% من مطالباتهم لإصلاح الأشياء التي عطلها الذكاء الاصطناعيفي المطالبات السابقة.

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

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

دوامة جودة الكود

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

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

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

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

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

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

متى تتوقف عن البرمجة الحماسية وتوظف المهندسين

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

• أنت تقضي وقتًا أطول في تصحيح الأخطاء بدلاً من إنشاء ميزات جديدة
• أنت تتعامل مع بيانات المستخدم الحقيقية (رسائل البريد الإلكتروني والمدفوعات والمعلومات الشخصية)
• You need payment processing, subscription billing, or financial transactions
• يجب أن يعمل تطبيقك بشكل موثوق لأكثر من 100 مستخدم متزامن
• أنت تتكامل مع واجهات برمجة التطبيقات التابعة لجهات خارجية والتي تتطلب خطافات الويب أو OAuth
• لقد استنفدت ميزانيتك الائتمانية مرتين ولم تتغير قائمة الميزات الخاصة بك
• لا يمكنك الإجابة بثقة على "من يمكنه الوصول إلى هذه البيانات؟" لكل جدول في قاعدة البيانات الخاصة بك
• أنت تخطط لجمع التمويل، وسوف يسألك المستثمرون عن بنيتك التقنية
• لقد واجهت خطأً لا يمكنك إصلاحه بعد أكثر من 20 مطالبة

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

ما تفعله الوكالة بشكل مختلف

رد الفعل الشائع على جدار 80/20 هو "سأتعلم البرمجة وإصلاحه بنفسي". احترم تلك الطاقة، لكن فكر في الرياضيات. إن تعلم ما يكفي من React وتصميم قاعدة البيانات والمصادقة والنشر لإنهاء تطبيق الإنتاج يستغرق من 6 إلى 12 شهرًا من الدراسة المركزة. يستغرق تعيين مهندس كبير لإنهاء الأمر من 3 إلى 6 أسابيع. إذا كان لدى شركتك الناشئة نافذة للسوق، فإن مسار التعلم لمدة 6 أشهر يغلق تلك النافذة.

في Savi، يستخدم كبار المهندسين لدينا أدوات الذكاء الاصطناعي أيضًا. نحن نستخدم Cursor وClaude وCopilot يوميًا. الفرق هو أننا نستخدمها كمسرعات بالإضافة إلى 5-10 سنوات من الخبرة الهندسية، وليس كبدائل لها. نحن نعرف ما يجب المطالبة به، والأهم من ذلك، ما يجب مراجعته في المخرجات. نكتشف تكوينات RLS الخاطئة، وحدود الأخطاء المفقودة، ومتجهات حقن SQL، وظروف السباق قبل أن تصل إلى المستخدمين.

إليك ما تبدو عليه العملية عندما يقدم لنا أحد المؤسسين نموذجًا أوليًا مرمزًا:

التدقيق (1-2 أيام).نقوم بمراجعة قاعدة التعليمات البرمجية الموجودة لديك ومخطط قاعدة البيانات والبنية التحتية. نقوم بتحديد الثغرات الأمنية والمشكلات المعمارية والتعليمات البرمجية التي تحتاج إلى الاستبدال. نقدم لك تقييمًا صادقًا: هل يمكن إصلاح ذلك أم يجب أن نبدأ من جديد؟ في بعض الأحيان، يحتوي التطبيق المشفر على مكونات قوية لواجهة المستخدم ومخطط قاعدة بيانات معقول، ويمكننا البناء عليه. وفي أحيان أخرى، يكون لدى الأساس الكثير من المشاكل الهيكلية، ويكون البدء نظيفًا أسرع وأرخص.

الهندسة المعمارية (2-3 أيام).نحن نصمم بنية الإنتاج. مخطط قاعدة البيانات مع الفهارس المناسبة وسياسات RLS واستراتيجية الترحيل. طبقة API مع المصادقة وتحديد المعدل ومعالجة الأخطاء. بنية الواجهة الأمامية مع أنماط جلب البيانات المتسقة، وإدارة الحالة، وتنظيم المكونات. هذه هي أدوات الترميز الخاصة بأجواء العمل التي يتم تخطيها بالكامل.

بناء (2-5 أسابيع).نكتب رمز الإنتاج. تحصل كل ميزة على معالجة الأخطاء وحالات التحميل وتغطية حالة الحافة. يحصل كل جدول قاعدة بيانات على سياسات RLS. يحصل كل مسار API على التحقق من صحة الإدخال. نكتب اختبارات لمنطق الأعمال. لقد قمنا بإعداد خطوط أنابيب CI/CD التي تلتقط الانحدارات قبل النشر. أنت تتحدث مباشرة مع المهندس الذي يقوم ببناء منتجك؛ لا يوجد مديرو مشاريع ينقلون الرسائل، ولا توجد مكالمات حالة أسبوعية يمكن أن تكون رسالة Slack.

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

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

كان النموذج الأولي هو الجزء الصعب. التشطيب هو الجزء الذكي.

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

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

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

الأسئلة المتداولة