أنشأت منتجًا باستخدام الذكاء الاصطناعي—كيف تُدخل تحسينات دون أن تعطل ما يعمل

تعرّف على المزيد حول العمل مع النماذج في وثائق Ailoot.

لماذا يبدأ العمل الأعلى تكلفة بعد الإطلاق؟#

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

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

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

يشرح دليل «التكلفة الخفية للبرمجة بأسلوب vibe» هذه الأرقام بمزيد من التفصيل. كان السؤال هناك: ما الذي تدفع مقابله؟ أما السؤال هنا فمختلف: 44 سنتًا من كل دولار تذهب لإصلاح الأخطاء—وهذا المقال كله يدور حول منع هذه الحصة من الزيادة. ويُسمى العمل على إبقائها تحت السيطرة بالصيانة.

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

ما الذي يتعطل فعلًا: 5 كوارث بعد الإطلاق#

هذه تقارير ما بعد الحادثة المنشورة عن منتجات حقيقية بُنيت باستخدام الذكاء الاصطناعي، بأرقام وتواريخ. فكّر فيها كخريطة لحقل ألغام—فقد انفجر كل لغم بالفعل لشخص ما، وأصبحت طريقة تجنبه معروفة.

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

ليست المشكلة في عدم كتابة الشفرة باليد—فهناك كثيرون يعملون بهذه الطريقة. المشكلة في عدم السؤال: «هل قاعدة البيانات مؤمّنة؟». سأريك الآن مطالبة تطرح هذا السؤال نيابة عنك.

شبكة الأمان الأولى هي git والعودة إلى «ما كان عليه الحال أمس»#

عندما يعطّل Claude شيئًا، تحتاج إلى زر «أعِده كما كان أمس». يُسمى هذا الزر تقنيًا git، وهو أبسط مما يبدو.

ثلاثة مصطلحات يحتاج غير المبرمج إلى فهمها:

1. المستودع — مجلد مشروعك المحفوظ في السحابة، عادةً على GitHub. نسخة من كل شفرتك لا تقتصر على ما يوجد على حاسوبك.
2. Commit — نقطة رجوع. كأنك تقول للشفرة: «احفظ هذه الحالة». كل commit علامة يمكنك العودة إليها.
3. Deploy — نقل. كانت الشفرة محلية على حاسوبك، ولا تعمل إلا لديك. يرسلها النشر إلى خادم خارجي كي تعمل للجميع.

ما دامت لديك نقاط commit حديثة، يمكنك التراجع عن أي عطل بجملة واحدة. حرفيًا.

لقد عطّلت شيئًا—كان كل شيء يعمل أمس، لكنه لا يعمل اليوم. اعثر على أحدث commit كان كل شيء فيه على ما يرام، وأرني ما الذي تغيّر منذ ذلك الحين، وأعِد المشروع إلى تلك الحالة.

طبّق هاتين القاعدتين فورًا، قبل أن يرى أشخاص آخرون المنتج:

• يجب أن يكون المستودع خاصًا. لا تجعله عامًا. وإلا فسيتمكن أي شخص من قراءة شفرتك وكل ما فيها.
• أضف ملف الأسرار إلى قائمة التجاهل. تحفظ المفاتيح وكلمات المرور وبيانات اعتماد الوصول إلى قاعدة البيانات في ملف منفصل، عادةً .env، ولا يُضاف هذا الملف مطلقًا إلى المستودع. أضف سطرًا لـ .env في .gitignore، وستظل الأسرار لديك.

هناك دليل منفصل حول التراجع الآمن عن التغييرات في Claude Code: كيفية التراجع عن التغييرات في Claude Code. من دون نقاط رجوع، تسير على حبل مشدود من دون شبكة أمان، وستسقط عاجلًا أم آجلًا.

ما الذي يتراجع عنه /rewind، وما الذي لا يتراجع عنه؟#

ينشئ Claude Code لقطة للحالة قبل كل تغيير يجريه. يعيد الأمر /rewind (أو الضغط على Esc مرتين) الملفات والمحادثة إلى نقطة تحددها. وهذا مفيد: إذا عطّلت ميزة قبل خمس دقائق، يمكنك الرجوع خمس دقائق إلى الوراء.

لكن هناك فخًا يتسبب في فقدان المبتدئين لبياناتهم. لا يتراجع /rewind عن كل شيء:

توضح Anthropic الأمر ببساطة: اللقطات زر «تراجع» محلي، بينما git سجل دائم. تكمل اللقطات نظام التحكم في الإصدارات، لكنها لا تحل محله.

الخلاصة العملية لغير المبرمج: سينقذك /rewind من موقف «لقد عطّل Claude ميزة للتو». لكن إذا تمكن من حذف صف من قاعدة البيانات أو رفع الشفرة إلى السحابة، فلن يعيدها إلا git ونسخة احتياطية من قاعدة البيانات. لذا احتفظ بالطبقتين: اللقطات للتراجع السريع، وعمليات commit للسجل الدائم للمشروع.

كيف تُدخل تحسينات دون أن تعطل ما يعمل بالفعل؟#

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

تحدث هذه الحلقة لأن البرمجة بأسلوب vibe غير حتمية. فالطلب نفسه يعطيك شفرة مختلفة في كل مرة. ولهذا يمكن لكل تعديل أن يغيّر المنطق المحيط به من دون أن تلاحظ: ينتقل حد الخصم من 10 إلى 12 percent، أو يتغير سلوك قاعدة تحقق—من دون أي مراجعة منك أو حتى تحذير واحد. يُسمى هذا انحرافًا منطقيًا، وهو يضر بهدوء بالضبط بالأشياء التي تدر المال: الأسعار، والوصول، والمدفوعات.

هناك قاعدة واحدة للوقاية من الانحراف، وهي بسيطة بما يكفي لتعليقها على الحائط: لا تُجرِ commit لشفرة لا تستطيع شرحها لشخص آخر كلمة بكلمة.

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

قبل تغيير الشفرة، نفّذ ما يلي:

احفظ الحالة الحالية العاملة كنقطة رجوع منفصلة (commit).

اشرح بالكلمات بدقة ما الذي تخطط لتغييره وفي أي ملفات.

أجرِ أصغر تغيير ممكن—ما يحل مهمتي فقط، دون أي إضافات.

أرني ما الذي تغيّر واشرح كل تغيير حتى أستطيع شرحه لشخص آخر.
لا تلمس منطق التسعير أو الوصول أو الدفع ما لم أطلب منك ذلك.

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

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

كيف تتحقق من التغيير قبل نشره؟#

بين «يعمل على حاسوبي» و«يعمل للجميع» خطوة وسيطة يتجاوزها المبتدئون: نسخة اختبار. إنها لقطة منفصلة من بيئة الإنتاج تتحقق فيها من التغيير قبل أن يراه أشخاص حقيقيون. وتبدو دورة العمل كما يلي:

1. أنشئ التغيير وتحقق منه بنفسك (development).
2. انشره في staging—نسخة من بيئة الإنتاج، لكن من دون مستخدمين حقيقيين.
3. شغّل السيناريوهات الأساسية وتأكد من عدم تغيّر أي شيء.
4. لا تنشره في بيئة الإنتاج إلا الآن.

لماذا يهم هذا بعد الإطلاق؟ لأن كل إصدار ينطوي على مخاطر. قد يؤدي تغيير بسيط في الشفرة إلى تعطل تسجيل الدخول إلى الحساب. وقد يتسبب إعداد واحد مفقود في توقف المنتج كله. تكشف staging هذه المشكلات من دون عواقب؛ أما في بيئة الإنتاج فتخسر العملاء.

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

أنا على وشك نشر تغيير. راجع السيناريوهات الأساسية للمنتج بالترتيب وتحقق من أن كلًا منها لا يزال يعمل كما كان:

تسجيل مستخدم جديد وتسجيل الدخول.

الدفع ومنح الوصول بعد الدفع.

صلاحيات الوصول—لا يستطيع المستخدم العادي رؤية بيانات شخص آخر أو منطقة الإدارة.

لم تتغير أرقام منطق الأعمال الأساسية (الأسعار والخصومات والحدود).
إذا كان أي شيء يتصرف على نحو مختلف عن الإصدار السابق، فتوقف وأرني ما الذي تغيّر بالضبط.

أين أسرارك؟ أكبر ثغرة لدى المبتدئين#

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

قال المؤسس الذي فُرضت رسوم على عملائه بقيمة $87,500 لاحقًا إن مطالبة واحدة كانت كافية لمنع ذلك. أُلغيت الرسوم في النهاية، لكن الرسوم غير القابلة للاسترداد وراحة البال المفقودة بقيتا. إليك تلك المطالبة.

افحص المشروع بأكمله وتأكد من عدم وصول أي مفتاح سري إلى المتصفح:

اعثر على كل مفاتيح قاعدة البيانات ونظام الدفع والخدمات الخارجية.

تأكد من أن كل مفتاح مخزن على الخادم فقط، داخل متغيرات البيئة، وليس في شفرة الصفحة.

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

ثمة حقل ألغام آخر قريب، وهو التحقق من صلاحيات الوصول في المتصفح فقط. إذا قرر منتجك في شفرة الصفحة ما إذا كان سيُظهر «منطقة الإدارة»، فبوسع أي شخص تجاوز هذا القرار. يجب دائمًا التحقق من صلاحيات الوصول على الخادم. ويجب ألا تعيد قاعدة البيانات البيانات إلا لمن يحق لهم الاطلاع عليها—وهذا هو دور أمن مستوى الصف (RLS)، وينبغي تفعيله على كل جدول.

قبل بيع حق الوصول أو السماح للآخرين بالدخول، أجرِ تدقيقًا أمنيًا عامًا للمنتج.

افحص المشروع بعين مهاجم وابحث عن ثغرات أمنية:

هل توجد مفاتيح سرية مخزنة في الشفرة التي تصل إلى المتصفح أو في سجل المشروع؟

هل أمن مستوى الصف (RLS) مفعّل في كل جدول من جداول قاعدة البيانات؟ وهل يجري التحقق من صلاحيات الوصول على الخادم لا في المتصفح فقط؟

هل توجد نسخة احتياطية تلقائية لقاعدة البيانات؟ وهل تحققت من قبل من قدرتي على الاستعادة منها؟

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

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

أين تستضيف منتجك: سلم الاستضافة#

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

1. استضافة مجانية (مثل Vercel)—لك وللاختبارات والمشروعات الصغيرة. تصلح إذا كانت المنصة متاحة لجمهورك ولم تكن تخزن بيانات شخصية للأشخاص.
2. منصة تتيح النشر بأمر واحد (Railway)—عندما يكون لديك backend وقاعدة بيانات. تنشر بأمر واحد ولا تحتاج إلى إعداد خادم. عائق البدء منخفض.
3. خادم مخصص خاص بك—عندما يكون الحمل مرتفعًا وتحتاج إلى تحكم كامل. انتقل إليه لاحقًا، عندما تبلغ الحد الأقصى للمنصة.

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

متى تفصل التطبيق وقاعدة البيانات والنسخ الاحتياطية؟#

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

• ضع التطبيق وقاعدة البيانات على جهازين مختلفين. الإشارة: في ذروة الحمل، يظل استخدام CPU والذاكرة أعلى من 70–80 percent، وتتباطأ الطلبات، ويتنافس التطبيق وقاعدة البيانات على الموارد نفسها. بعد فصلهما، يمكنك تعزيز قاعدة البيانات من دون المساس بالتطبيق، والعكس صحيح.
• اتبع قاعدة النسخ الاحتياطي 3-2-1. ثلاث نسخ من البيانات على نوعين مختلفين من الوسائط، على أن تكون إحداها خارج الموقع. يحمي ذلك من أعطال الأجهزة وبرامج الفدية. والأهم أن تكون النسخ الاحتياطية تلقائية.

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

ساعدني على تحديد ما إذا كان الوقت قد حان لنقل منتجي إلى بنية تحتية أكثر جدية. تحقّق من كل بند واسألني عنه:

ما مدى حمل CPU والذاكرة في وقت الذروة—هل يظل الاستخدام أعلى من 70–80 percent أم لا؟

هل توجد قاعدة البيانات والتطبيق على الجهاز نفسه أم على جهازين مختلفين؟

هل توجد نسخة احتياطية تلقائية لقاعدة البيانات، وهل اختبرت استعادتها؟

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

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

كيف تجعل الصيانة تعمل تلقائيًا؟#

الصيانة اليدوية مرهقة. ويمكنك إزاحة هذا العبء بطريقتين: المراقبة ووكيل الدورية.

تستخدم المراقبة أداتين مختلفتين لمهمتين مختلفتين:

1. «هل الموقع يعمل؟»—مراقب لوقت التشغيل، مثل UptimeRobot. يرسل إشارة إلى المنتج كل بضع دقائق، وينبهك إذا توقف. وتتوفر له خطة مجانية.
2. «ما الذي تعطل بالتحديد؟»—متتبع للأخطاء، مثل Sentry. يجمع الأخطاء داخل التطبيق ويوضح أين حدث الإخفاق ولماذا.

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

المستوى الثاني من التشغيل التلقائي هو وكيل الدورية. تخيل وكالة عقارات: في السابعة صباحًا، يقرأ وكيل ذكاء اصطناعي استفسارات الموقع، ويلاحظ أن نموذج الحجز معطل، ويجد السبب في الشفرة، ويقدم لك إصلاحًا جاهزًا مع شرح. تراجعه وتقول «نعم»—فيُنشر. والترتيب مهم: عالج مشكلة المستخدم أولًا (امنحه حق الوصول واعتذر)، ثم ابحث في السبب والمال.

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

متى يحين وقت إيقاف منتج؟#

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

يمكنك استخدام الحدود التالية لاتخاذ القرار:

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

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

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

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

خطوتك التالية هي Ailoot.