دقة الـ Vibe Coding: كيف تعرف ذلك فعلًا؟

دقة الـ Vibe Coding قياس، لا خاصية في النموذج

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

وبهذه الصياغة، يتوقف السؤال عن كونه «أي نموذج هو الأدق» ليصبح «ما حلقة التغذية الراجعة لديّ»، وهي أمر تتحكم فيه أنت.

ما الذي يستحق القياس

الفخّ: اختبارات كتبها المؤلف نفسه

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

يحتاج قياس الدقة إلى تحقّق مستقل؛ شيء يشغّل المنتج في مواجهة السلوك المقصود، لا في مواجهة تصوّر الشيفرة عن نفسها.

إعداد القياس

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

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

معطى يستحق أن تعرفه

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

ما الغرض الحقيقي من هذا الرقم

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

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

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

اجعل القياس مستمرًا

القياس لمرة واحدة يخبرك عن لحظة واحدة. والدقة خاصية لعملية مستمرة، ولذلك فإن مكان عمليات التحقق هو كل تغيير.

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

تحويل الدقة إلى شيء تقيسه

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

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

وهذا يمنحك الرقمين الجديرين بالتتبع: معدل الانحدار لكل تغيير، وعدد المحاولات اللازمة للعودة إلى الحالة الخضراء. كلاهما يتحرك كلما ضاقت الحلقة، ولا يمكن تضخيم أي منهما بكتابة مزيد من الاختبارات.