أخطاء Vibe Coding: ما الذي يجب فحصه عندما لا تقرأ الكود

لماذا تتجمّع أخطاء Vibe Coding

يُحسِّن الوكيل عمله بما يخدم المسار الذي وصفته. أنت تصف ما تريد حدوثه، فيُبنى المسار المثالي بعناية ويُبنى كل ما حوله بصورة معقولة في ظاهرها. وكلمة «معقولة» هي بيت القصيد: الكود يُصرَّف، والشاشة تُعرض، والافتراضات لم تُختبر قط أمام الواقع.

لهذا السبب تكون الإخفاقات قابلة للتوقّع؛ فهي دائمًا عند حواف الوصف.

المجموعات الأربع، بالترتيب الذي تُفاجئك به

• حفظ البيانات. الشاشة تتحدّث، وقاعدة البيانات لا. وإعادة التحميل تكشف ذلك فورًا. أعِد التحميل بعد كل عملية كتابة قبل أن تصدّق أي شيء.

• الحالات الفارغة وحالات الخطأ. نتائج صفرية، وطلب فاشل، ومدخل مرفوض. لم يرد أيٌّ منها في موجّهك. جرّب كلًّا منها عن قصد؛ فهي تتعطّل أكثر من المسار المثالي.

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

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

الفحص الذي يتوسّع مع تزايد الموجّهات

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

يضع الإعداد ذلك بين يدي الوكيل، فيجري الفحص جنبًا إلى جنب مع البناء بدلًا من أن يكون مهمة منفصلة.

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

عشر دقائق تكشف معظمها

• سجّل حسابًا جديدًا، ثم سجّل الخروج، ثم عُد وسجّل الدخول. أكثر أشكال الفشل الكامل شيوعًا، وأول ما يفعله المستخدم الحقيقي.

• أنشئ عنصرًا، وأعد التحميل، وتأكّد من بقائه. يكشف مباشرةً مجموعة حفظ البيانات.

• أرسل مدخلًا غير صالح. أنت تتحقّق من أنه يفشل بوضوح بدلًا من أن ينجح بصمت.

• نفّذ المسار الرئيسي بحساب جديد تمامًا. يكشف مجموعة الصلاحيات.

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

لماذا يعود الخطأ نفسه مرارًا

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

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

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

قبل أن ينتقل إلى أي بيئة حقيقية

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

• GitHub App هو webhook تُعدّه في لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي ينتجه خط التسليم لديك أصلًا، فلا يتغيّر شيء في مستودعك.

• GitHub Actions يضع هذه الخطوة داخل سير عملك الخاص، ويُضبط من الطرفية.

دع الفحوصات تعمل من تلقاء نفسها

TestSprite هو ما يجعل دقائق الفحص العشر الواردة في هذه الصفحة تتوقّف عن كونها عملًا تؤدّيه بيدك. تصف كل مسار مرة واحدة بلغة بسيطة، ثم يشغّلها على تطبيقك بعد كل تغيير.

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

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