الدرس 11. إنقاذ تطبيق Vibe Coding الفاشل

الدرس 11

نصائح ذهبية — هذا كل ما تحتاج معرفته

انهار تطبيقك. تسجيل الدخول الذي كان يعمل أمس لم يعد يعمل. الدفع يُخصم مرتين. كلما لمست الكود انكسر شيء آخر. حين تطلب من الذكاء الاصطناعي “أصلح” يزداد الأمر سوءاً.

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

ثمة ثلاثة أدوات هيكلية:

codistill — التشخيص. يستخرج تلقائياً نقاط API، ومخطط قاعدة البيانات، وتدفق المصادقة من الكود الحالي.
huma — الإقفال. يضع اختبارات الانحدار على كل نقطة نهاية لحماية السلوك الحالي.
yongol — التحويل. يولّد backend جديداً من SSOT ويُثبت التطابق عبر الاختبارات القائمة.

تسير من اليسار إلى اليمين: تشخص بـ codistill، تُقفل بـ huma، وحين تكون جاهزاً تتحول بـ yongol.

للوكيل: “شغّل codist scan لاستخراج نقاط النهاية، ومخطط قاعدة البيانات، وتدفق المصادقة لهذا المشروع.”

تظهر الصورة الحالية. ترى من بين 25 نقطة نهاية كم هي حية وكم هي ميتة.

للوكيل: “شغّل huma verify للتحقق من حالة جميع نقاط النهاية، واكتب اختبار Hurl لكل واحدة حية.”

هذه هي اختبارات الانحدار. تُقفل ما يعمل الآن. طالما تجتاز هذه الاختبارات، لن ينكسر السلوك القائم حتى لو عدّل الوكيل الكود.

للوكيل: “أصلح الآن خطأ تسجيل الدخول، لكن يجب أن تجتاز جميع اختبارات Hurl.”

تُصلح الخطأ دون أن تكسر شيئاً آخر. الإصلاح يتم والرّاتشيت مُشبَّك.

التجربة التمهيدية

يمكنك التجربة حتى بدون تطبيق منهار. عِش عملية “البناء ← الكسر ← الإنقاذ” في 3 دقائق.

الخطوة 1 — ابنِ التطبيق

في Claude Code:

“أنشئ واجهة API بسيطة لقائمة المهام. 5 نقاط نهاية: استعراض المهام، إضافة مهمة، تعديل مهمة، حذف مهمة، تحديد مهمة كمنجزة. شغّل الخادم.”

الخطوة 2 — شخّص بـ codist

“شغّل codist scan لاستخراج قائمة نقاط النهاية من هذا المشروع.”

يستخرج codist تلقائياً المسار والمنهج والمعاملات لكل من نقاط النهاية الخمس. هذه هي الخريطة الحالية.

الخطوة 3 — أقفل بـ huma

“شغّل huma verify واكتب اختبارات Hurl لجميع نقاط النهاية.”

يُنشأ ملف Hurl لكل نقطة من النقاط الخمس. السلوك الحالي محمي.

الخطوة 4 — اكسر عمداً

“غيّر تنسيق استجابة نقطة نهاية تعديل المهمة. أعد تسمية حقل title إلى name.”

بعد التغيير:

“شغّل اختبارات Hurl.”

يفشل الاختبار. “كان متوقعاً title لكن جاء name.” رُصد الانجراف. الرّاتشيت يعمل.

الخطوة 5 — أصلح والرّاتشيت مُشبَّك

“عدّل الكود ليجتاز جميع اختبارات Hurl، لكن احتفظ بالميزة الجديدة التي تستخدم حقل name.”

يحافظ الوكيل على التوافق مع الإصدارات السابقة أثناء التعديل. اجتياز Hurl يعني الحفاظ على السلوك القائم.

هذا هو النموذج المصغر لـ codistill → huma → إصلاح. في التطبيقات المنهارة فعلاً، تتسع هذه العملية لتشمل 25 أو 50 أو 200 نقطة نهاية، لكن المبدأ واحد.

لماذا يجب أن تعمل بهذه الطريقة

مقدمة: السبب الحقيقي لانهيار تطبيقك

في 2025، انكشفت قواعد بيانات 170 تطبيقاً مبنياً بـ Lovable على الإنترنت. بريد إلكتروني، مفاتيح API، بيانات الدفع. لم يكن السبب خطأً برمجياً. أنشأ الذكاء الاصطناعي التطبيقات دون سياسات أمان، ولم يتحقق أحد.

في يناير 2026، سُرِّب 1.5 مليون رمز API من شبكة التواصل الاجتماعي Moltbook. نفس السبب. الذكاء الاصطناعي بنى ولم يتحقق الإنسان.

هذا ليس حديثاً عن الآخرين. كل من بنى تطبيقاً بـ vibe coding يجلس فوق نفس البنية.

“أنشئ تسجيل دخول” — 30 ثانية. “أضف الدفع” — دقيقتان. “أضف لوحة المشرف” — 5 دقائق. بعد 3 أشهر “ينظّف” الذكاء الاصطناعي منطق الدفع فيغيّر حساب الخصم، وإضافة ميزة جديدة يكسر المصادقة، والصفحة التي كانت تعمل أمس تُعيد اليوم خطأ 500.

أمامك خياران:

إعادة البناء
الإنقاذ

الإعادة كانت ممكنة قبل 3 أشهر. المشكلة أن النمط يتكرر مع الإعادة. الانجراف مشكلة هيكلية لا برمجية.

يجب أن تتعلم الإنقاذ.

طريقة الإنقاذ الذاتي للناجي — 5 خطوات

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

الخطوة 1. التشخيص — ما الذي لا يزال حياً؟

أولى الأولويات ليست إصلاح الكود. بل فهم الوضع الحالي.

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

إذا أعادت 18 من أصل 25 نقطة نهاية 200، و4 أعادت 401، و3 أعادت 500 — فهذه هي الخريطة الحالية. البدء بالإصلاح بدون خريطة يُعرّض الأجزاء المُصلَحة لكسر أجزاء أخرى.

codist scan من codistill يُؤتمت هذه المهمة. يستخرج من الكود الحالي نقاط النهاية، ونماذج البيانات، وتدفقات المصادقة.

الخطوة 2. الإقفال — احمِ الحي أولاً

بعد التشخيص، أقفل نقاط النهاية الحية.

للوكيل: "اكتب اختبار Hurl لكل من
الـ 18 نقطة نهاية التي تُعيد 200.
استخدم الاستجابة الحالية كقيم متوقعة.
لما يتطلب مصادقة، شغّل تسلسل تسجيل الدخول أولاً
للحصول على رمز الوصول."

هذه الـ 18 ملفات Hurl هي شبكة الأمان. أياً كانت التعديلات اللاحقة، اجتياز هذه الاختبارات يعني الحفاظ على السلوك القائم.

huma verify من huma يُنظّم هذه العملية. يتتبع الحالة لكل نقطة نهاية ويحكم بـ PASS/IMPROVE/FAIL.

مهم: لا يجوز الإقفال الجزئي. إقفال 10 من أصل 18 يعني أن الـ 8 المتبقية قد تنكسر أثناء الإصلاح دون أن تعلم. الإقفال الكامل مبدأ لا تحيد عنه.

الخطوة 3. الإصلاح — أصلح والرّاتشيت مُشبَّك

شبكة الأمان جاهزة، حان وقت إصلاح الأخطاء.

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

هذا هو التطبيق العملي لـ Ratchet Pattern الذي تعلمته في الدرس 6. تُصلح دون أن تكسر. تُشغّل Hurl بعد كل إصلاح. إذا اجتاز تنتقل للخطأ التالي. إذا فشل تتراجع.

الـ 3 نقاط نهاية التي تُعيد 500 تُعالَج بنفس الطريقة. بعد الإصلاح تُضيف اختبارات Hurl جديدة. الرّاتشيت يُحكم قفلة إضافية.

الخطوة 4. الاستخراج — أخرج المنطق من الصندوق الأسود

هنا جوهر المسألة. السبب الجذري لانهيار التطبيق عادةً هنا.

إذا كنت تستخدم Supabase:

سياسات RLS موجودة في لوحة التحكم فقط، غائبة عن الكود
منطق الأعمال مدفون في Edge Functions
منطق المصادقة مقيّد بـ Supabase Auth

إذا كنت تستخدم Firebase:

Security Rules موجودة في الكونسول فقط
المنطق موزّع عبر Cloud Functions

مهما كان BaaS المستخدم، البنية واحدة. منطق الأعمال خارج قاعدة الكود.

للوكيل: "استخرج جميع سياسات RLS من Supabase.
احفظ سياسات SELECT وINSERT وUPDATE وDELETE
لكل جدول في ملفات SQL. ارتكب في git."

للوكيل: "حلّل منطق الأعمال في Edge Functions.
وثّق أي دالة تنفّذ أي قاعدة عمل."

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

codist ddl من codistill يستخرج DDL من قاعدة البيانات الحالية. codist scan يستخرج SSOT من الكود. هذه أدوات تُحوّل من الصندوق الأسود إلى طبقة تصريحية.

الخطوة 5. التحويل — فقط حين تكون جاهزاً

بعد اكتمال الخطوات 1-4، يكون التطبيق في هذه الحالة:

جميع نقاط النهاية لديها اختبارات انحدار Hurl
الأخطاء مُصلَحة
منطق الصندوق الأسود موثَّق في قاعدة الكود
الرّاتشيت مُشبَّك بحيث لا تكسر التعديلات الجديدة السلوك القائم

في هذه الحالة تقرر التحويل. من Supabase إلى backend خاص، من Deno إلى Go، أياً كان.

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

للوكيل: "شغّل yongol generate لإنشاء Go+Gin backend.
اجتز جميع اختبارات Hurl القائمة."

التحويل هو الخطوة 5 وليس الخطوة 1. محاولة التحويل في الخطوة 1 ستفشل. هذا درس مؤكد من حوادث الإعداد الفعلية.

الخروج من Supabase

الحالة الأكثر شيوعاً في الدرس 11 هي Supabase. يبدأ المستخدمون بـ vibe coding، يُركّزون كل شيء في Supabase، وبعد 3 أشهر ينهار كل شيء.

ترتيب الخروج:

1. أبقِ قاعدة البيانات وضع الرّاتشيت فقط

استخدم PostgreSQL من Supabase كما هو. تغيير قاعدة البيانات يأتي في النهاية.

codist ddl → استخرج DDL من الجداول الحالية
huma verify → استوعب الوضع الحالي لنقاط النهاية
hurl → أقفل جميع API الحية

2. انقل المنطق إلى الكود

سياسات RLS → ملفات Rego. Edge Functions → تعليقات SSaC. من لوحة التحكم إلى قاعدة الكود.

3. افصل المصادقة

Supabase Auth هو آخر ما تفصله. لا يمكن استخراج تجزئات كلمات مرور auth.users، لذا إذا كنت في المرحلة الأولى (بدون عملاء) انتقل فوراً، وإذا كان لديك عملاء شغّل فترة مصادقة مزدوجة.

4. ارفع الخادم الجديد وتحقق بـ Hurl

yongol generate → أنشئ Go+Gin backend
شغّل Hurl كاملاً → أثبت تطابق السلوك مع النظام القديم

إذا اجتازت Hurl كلها حوّل حركة المرور.

لماذا لا تُعيد البناء من الصفر

“أليس من الأسهل إعادة البناء؟”

لا. ثلاثة أسباب:

1. النمط يتكرر

الانجراف مشكلة هيكلية لا برمجية. إعادة البناء بدون رّاتشيت ستُنهار عند نفس النقطة بعد 3 أشهر.

2. المعرفة مدفونة في النظام القديم

قواعد الأعمال المتراكمة خلال 3 أشهر من vibe coding موجودة في الكود. إعادة البناء تعني إعادة بناء هذه القواعد من الذاكرة. والذاكرة مخطئة.

3. ربما يوجد عملاء بالفعل

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

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

علاقة الدرس 11 بما تعلمته في الدروس 1-10

الدرس	طريقة البناء الصحيح من البداية	الدرس 11: إنقاذ ما فشل
الدرس 3 Hurl	إعلان عقد API	إقفال السلوك الحالي باختبارات الانحدار
الدرس 4 yongol	التوليد من SSOT	استخراج SSOT من الكود الحالي
الدرس 6 Ratchet	الإقفال عند الاجتياز	الإصلاح دون الكسر
الدرس 8 filefunc	هيكلة الكود	تنظيم الكود القديم
الدرس 10 DDL	إعلان المخطط	استخراج DDL من قاعدة البيانات الحالية

نفس الأدوات، اتجاه معاكس. إذا كانت الدروس 1-10 “من الأعلى للأسفل” (إعلان → توليد)، فالدرس 11 هو “من الأسفل للأعلى” (كود حالي → استخراج → إعلان).

codistill يُؤتمت هذا “من الأسفل للأعلى”. يعصر SSOT من الكود الحالي.

من ناجٍ إلى منقذ

بعد اكتمال هذه العملية تمتلك قدرتين:

البناء من الصفر (الدروس 1-10) — إعلان، تحقق، إقفال، ترسيخ
إنقاذ الفاشل (الدرس 11) — تشخيص، إقفال، إصلاح، استخراج، تحويل

معظم الكود في العالم هو نظام قديم. مشاريع البناء من الصفر نادرة. قدرة الإنقاذ تُستخدم أكثر.

vibe coding لم ينته. لقد تعلمت كيف تُمسك بزمامه.

المقالات ذات الصلة

Supabase هو فخ vibe coding — الخلفية النظرية للدرس 11. لماذا ينهار كل شيء مع BaaS؟
Hurl يمنع انجراف vibe coding — تفاصيل خطوة الإقفال في الخطوة 2.
codistill — عصر SSOT من الكود الحالي — أداة التشخيص في الخطوة 1 والاستخراج في الخطوة 4.
huma — رّاتشيت لا يُفوّت نقطة نهاية واحدة — أداة الإقفال في الخطوة 2.
yongol — عمود فقري SaaS للكود الذكاء الاصطناعي — أداة التحويل في الخطوة 5. توليد fullstack من SSOT.
قاعدة كود يستطيع الوكيل العمل بها — مبدأ تحويل الصندوق الأسود إلى مصنع.
tsma — خط الدفاع للانحدار في الكود القديم — الإصلاح وهو مُقفَل بالرّاتشيت.
بناء أنظمة يمكن للوكيل تشغيلها — جعل النظام القديم المُقفَل في متناول الوكيل.

كل دروس Reins Engineering

الدرس	العنوان
الدرس 1	كيف تُكلّف الذكاء الاصطناعي
الدرس 2	كيف لا تثق بالذكاء الاصطناعي
الدرس 3	تطبيق لا ينكسر
الدرس 4	القرارات خارج الكود
الدرس 5	ذكاء اصطناعي بزمام
الدرس 6	أقفل عند الاجتياز
الدرس 7	عكس المجاملة
الدرس 8	مصنع الوكيل
الدرس 9	الأتمتة ما وراء الكود
الدرس 10	قانون البيانات
الدرس 11	إنقاذ تطبيق Vibe Coding الفاشل

المصادر

Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.