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

المشكلة التي لم يرغب أحد في حلها

لقد شاهدت مؤسسين يُحاصرون في نفس الحلقة المؤلمة عشرات المرات. يسأل رأس المال المغامر سؤالاً بريئاً—“ماذا لو انخفض معدل ترك العملاء بمقدار 2%؟”—وفجأة يتوقف الاجتماع. جواب المؤسس يكون في مكان ما مدفوناً في كابوس إكسل يتكون من 47 تبويباً. ثلاث ساعات من البحث عن الصيغ. مراجع معطوبة. أخطاء دائرية تتسبب في تعطل النموذج بأكمله.

كان النمط واضحاً: المؤسسون كانوا يغرقون في جداول البيانات عندما كان ينبغي عليهم التفكير في النمو.

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

ما اكتشفته خلال 30 يوماً سيغير كل شيء كنت أعتقد أنني أعرفه عن النمذجة السريعة.

الحلم مقابل الواقع

اليوم الأول كان مشحوناً بالطاقة. تخيلت قمرة قيادة مالية أنيقة: مدعومة بالذكاء الاصطناعي، متزامنة مع QuickBooks، تشمل تخطيط السيناريوهات، وتصديرات جاهزة للمستثمرين في ثوانٍ. تقديري للجدول الزمني؟ ثلاثة أسابيع للوصول إلى الحد الأدنى من المنتج القابل للتطبيق (MVP). كنت واثقاً.

لكنني كنت مخطئاً تماماً.

الدروس الأولى جاءت بسرعة وبثمن غالٍ. عندما أمددت الذكاء الاصطناعي بعدة تعليمات في آن واحد—“أضف الوضع الليلي”، “صلح الخطأ”، “حسن الأداء”—لم يعالجها بشكل متسلسل. بدلاً من ذلك، تجمد، وارتبك، ثم أنشأ نسخة فرانكنشتاين لم تحقق أي من المهام الثلاثة. هذا الخطأ الواحد كلفني ست عمليات استرجاع، وثلاث ساعات ضائعة، و$23 في أرصدة الحوسبة.

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

الاختراق الحقيقي جاء عندما توقفت عن قول أشياء غامضة مثل “اجعله أكثر بديهية” وبدأت أكون دقيقاً في التعليمات. بدلاً من “حسن لوحة القيادة”، تعلمت أن أقول: “غير لون زر الحساب إلى #0066CC، زِد حجم الخط إلى 16px، أضف حشوة 8px.” الدقة ألغت الهدر.

الرحلة المكلفة: عندما التقى الذكاء الاصطناعي بالرياضيات المالية

بحلول الأسبوع الثاني، أنفقت $93 في أرصدة Replit. كان الإنفاق يتسارع، وليس يتباطأ. كل تكرار كان يحترق بمبلغ 2-5 دولارات حسب التعقيد. النمط كان واضحاً: التكرار السريع كان يلتهم ميزانيتي على قيد الحياة.

لكن الأزمة الحقيقية جاءت عندما اكتشفت أن حسابات الذكاء الاصطناعي المالية كانت خاطئة بنسبة 20%. تكلفة اكتساب العميل ظهرت $47 عندما كان من المفترض أن تكون 58.75 دولار. هذا الخطأ كان يمكن أن يطيح بعرض Series A.

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

قضيت ست ساعات في تصحيح صيغة واحدة. الحل استلزم التخلي عن اللغة الطبيعية واستخدام دقة جراحية:

بدلاً من: “احسب LTV”

كان علي أن أكتب: “احسب LTV كـ (متوسط الإيرادات لكل مستخدم × الهامش الإجمالي) / معدل ترك العملاء الشهري حيث ARPU = إجمالي MRR / العملاء النشطين؛ الهامش الإجمالي = (الإيرادات - COGS) / الإيرادات؛ معدل ترك العملاء الشهري = العملاء الذين تركوا هذا الشهر / العملاء النشطين في بداية الشهر. أظهر عملك خطوة بخطوة.”

هذه الدقة غيرت كل شيء. بعد ذلك، فهمه الذكاء الاصطناعي بشكل صحيح في كل مرة.

نقطة التحول: الاستماع للمستخدمين فعلاً يعمل

بعد ثلاثة أسابيع، كان لدي ثلاثة مختبرين ونموذجان ماليان مكتملان. كانت الملاحظات مرهقة ومتواضعة.

قام مؤسس واحد بتبسيط كل التعقيد بجملة واحدة: “لا أريد منشئ نموذج مالي آخر. أريد فقط أن أسأل ‘كيف أمدد فترة التشغيل بثلاثة أشهر؟’ وأحصل على إجابة.”

كنت أطور منتجاً خاطئاً.

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

وصلت هذه الرؤية في اليوم 21. بقي لي تسعة أيام لإعادة البناء.

مشكلة التوسع: عندما تصل حدود الترميز بالاهتزاز

ليس كل شيء ينجو من هذا النهج. عندما سأل المؤسسون “هل يمكنك التزامن مع QuickBooks؟”، اكتشفت الحقيقة القاسية: تدفقات OAuth 2.0، والتحقق من webhook، وتخطيط البيانات، ومعالجة حدود المعدل، ومنطق تحديث الرموز—هذه ليست من مجال الترميز بالاهتزاز. إنها عمل تطوير محترف.

اخترت TypeScript معتقداً أنه أفضل الممارسات الحديثة. اتضح أنه عندما لا تعرف لغة برمجة فعلاً، تدفع ضريبة التعلم في وقت التصحيح. قضيت ساعتين في تصحيح مشكلة نوع في TypeScript (نوع ‘number | undefined’ غير قابل للتعيين إلى نوع ‘number’)، وذكّرني ذلك أن اختيار لغة تفهمها يتفوق على اختيار اللغة الرائجة.

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

أحياناً، أفضل كود هو الكود الذي لا تكتبه.

الأرقام: التحقق في أصفى صوره

بعد 30 يوماً:

مقاييس التطوير: $127 أنفقت، 3500 سطر من الكود (معظمها مولد بواسطة الذكاء الاصطناعي)، 73 عملية استرجاع، لغة برمجة واحدة تعلمتها من الألم

اكتساب المستخدمين: 23 مؤسس مهتم، 12 سجلوا فعلياً، 3 أكملوا الانضمام، 1 دفع فعلياً

ذلك المؤسس الذي عرض 50 دولاراً شهرياً؟ أصبح هو المقياس الوحيد الذي يهم.

الواقع القاسي: إنشاء شيء يراه الناس مثيراً يختلف تماماً عن إنشاء شيء يستخدمه الناس. قناتي للتحويل كانت: 23 مهتم → 2 منخرط → 0 أكملوا الانضمام. حتى ذلك التحول النهائي، الذي جذب المؤسس الذي قال: “هذه المرة الأولى التي فهمت فيها اقتصاد وحدتي بدون شهادة مالية.”

ما يفعله الترميز بالاهتزاز فعلاً (وما لا يفعله)

حيث يتفوق:

• النمذجة السريعة (فكرة إلى MVP قابل للاختبار خلال أسبوعين)
• متطلبات رأس مال منخفضة ($127 مقابل $20K للمطورين)
• دورات فشل سريعة (حاول، اكسر، استرجع، تعلم خلال دقائق)
• توليد القوالب وأنماط قياسية
• عدم تعقيد التوظيف

حيث يتدهور:

• الحسابات الدقيقة التي تتطلب منهجية متسقة
• تكاملات API للمؤسسات مع OAuth وwebhooks
• بنية أمان متعددة المستأجرين
• معالجة الوظائف الخلفية لمزامنة البيانات
• الصيغ المالية المعقدة (تحليل المجموعات، حساب NPV)
• ميزات التعاون في الوقت الحقيقي

لحظة التخرج تأتي عندما يكون لديك أكثر من 10 عملاء يدفعون يطلبون ميزات لا يمكن للترميز بالاهتزاز توفيرها أساساً.

ما سأفعله بشكل مختلف (وما سأتجاوزه)

لو بدأت من جديد غداً، سأجري مقابلات مع 50 مؤسساً قبل أن أكتب سطراً واحداً من الكود. ليس 5، وليس 10، بل خمسين. سأطرح عليهم ما يستغرق وقتاً أطول للتحديث، وما الأسئلة التي يطرحها المستثمرون دائماً، وما الذي سيدفعون مقابله فعلاً. هذا كان ليجنبني أسبوعين من الجهد الضائع.

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

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

الطريق المتبقي

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

المرحلة 1 $200 أسابيع 5-8(: منشئ نماذج مالية يدوي + مستشار AI للتحقق من الافتراضات + تخطيط سيناريوهات أساسي + وظيفة التصدير. الهدف: 10 عملاء يدفعون.

المرحلة 2 )أسابيع 9-24(: إذا نجحت عملية التحقق، استئجار مطورين ماليين محترفين لبناء تكاملات حقيقية، وأمان للمؤسسات، وبنية تحتية للتوسع. الميزانية: 50-100 ألف دولار.

المهمة تظل كما هي: القضاء على نموذج Excel المالي المكون من 47 تبويباً. كل مؤسس يستحق لوحات تحكم في الوقت الحقيقي، وتفسيرات AI للأرقام، وتخطيط سيناريوهات خلال ثوانٍ، وتصديرات جاهزة للمستثمرين على الفور.

الرحلة مستمرة. لكن هذه المرة، مع مؤسسين حقيقيين يوجهون الاتجاه بدلاً من افتراضاتي التي تقود المنتج.

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