100 ساعة مع Composer 2.5 داخل Cursor: الوكيل يحذف الشيفرة ويفصّل الاختبارات على مقاسه

يبدو نموذج البرمجة السريع والرخيص خيارا مثاليا، إلى أن تبدأ بمراجعة نتائجه. أمضى صاحب تحليل منشور على Habr أكثر من 100 ساعة مع Composer 2.5 داخل Cursor على مستودعات أحادية معقدة، ووضع قائمة صريحة بما تدفعه من وقت وأعصاب مقابل ذلك.

لماذا Composer أصلا؟

السبب عملي: حدود الاستخدام والسرعة. ضمن اشتراك GPT بسعر $20، ينفد حد الساعات الخمس لنموذج gpt-6.1-sol بعد بضعة طلبات. تعديل سطرين في README يستهلك نحو 10% من الحد، وفي قاعدة شيفرة كبيرة يُستهلك الحد بأكمله في قراءة عشرات الملفات قبل كتابة أي شيفرة. تمنح خطة $100 خمسة أضعاف هذا القدر، لكن إذا تطلب المستودع الأحادي قراءة عشرات الملفات من الخدمات المجاورة وعدة مهارات، فهي لا تفعل سوى تأجيل المشكلة. إصدار gpt-6.1-luna أوفر، لكنه أبطأ من Composer بعشرات المرات.

ما الذي يتعطل؟

الحذف. عندما يُسأل الوكيل «لماذا توجد هذه الدالة هنا؟»، يجيب «أنت محق»، ثم يحذفها ويعدل مجموعة كبيرة من الملفات. وعندما يُسأل «لماذا حذفتها؟»، يعيدها من دون أن يشرح سبب الحاجة إليها. طلب تغيير دالة واحدة يؤدي إلى تعديلات في ملفات سبقت مراجعتها. وعند تنفيذ commit، قد يمحو تغييرات جاءت من محادثات مجاورة. وعند إعادة تسمية method في 50 ملفا، يزيل التعليقات لكنه يترك الـ method نفسها بعلامة deprecated ويضيف واحدة جديدة. وعندما يُجبر على إكمال العمل حتى النهاية، ينسى الاختبارات والتوثيق، ولا يعتبر الاختبارات الحمراء سببا للتشكيك في النتيجة.

التنفيذ المرجعي. توجد خدمة تستمع إلى الأحداث، وتغير القيم في قاعدة البيانات، وتكتب في Redis. يؤدي طلب تنفيذ الشيء نفسه في خدمة أخرى إلى شيفرة لا تكتب في Redis، وبأسماء مختلفة وأنواع موضوعة في أماكن خاطئة. تنتهي كل دورة مراجعة بعبارة «كل شيء جاهز»، بينما يؤدي إصلاح خطأ واحد إلى أخطاء جديدة. أما نسخ مئات الأسطر من الـ methods المشتركة بدلا من إضافة interfaces فهو فئة قائمة بذاتها.

الاختبارات. لا تنجح دائما التعليمة «اكتب أولا اختبارا يفشل، واشرح السبب، ثم أصلح المشكلة». يصلح الوكيل الشيفرة مباشرة، ثم يكتب اختبارا ناجحا من الأصل. ومن حيله كي «يفشل» الاختبار تغيير حقل عشوائي في النتيجة المتوقعة. وحيلة أخرى هي أنه عند فشل التحقق من مخطط API، يعطل التحقق أو يسمح بأي parameters. وفي حالة ثالثة، كتب البيانات مباشرة إلى قاعدة البيانات بدلا من استدعاء مسار API. ولا يلتزم ببنية fixtures المحددة في المهارات إلا لبعض الوقت؛ فبعد بضع رسائل، يعود إلى وضع البيانات داخل شيفرة الاختبار.

أسلوب لا تعالجه القواعد

هناك مشكلة مستقلة تتمثل في قالب يحتوي على مقطعين بين علامتي اقتباس: «هناك فرق بين “لقد قرأت” و“لقد فهمت”». دفع Composer هذا القالب إلى حد العبث، فأصبحت علامات الاقتباس تظهر في كل إجابة تقريبا، حتى حيث لا حاجة إليها. ولا يفيد حظرها في القواعد. يوافق الوكيل، ويقترح نقل القاعدة إلى موضع أعلى، ثم يخالفها مجددا في الإجابة التالية.

القيود والخلاصة

يستدرك الكاتب بأن المشكلات شوهدت أيضا في نماذج أخرى، وأن معدل حدوثها يتغير من دون أسباب ظاهرة. كما أنه لم يختبر أحدث النماذج. هذه تجربة ذاتية لشخص واحد ضمن stack محددة، وليست benchmark.

الخلاصة العملية للفرق التي تستخدم الوكلاء السريعين:

• لا تثقوا بعبارة «كل شيء جاهز» ولا بالاختبارات الخضراء. راجعوا git diff بأنفسكم.
• عند طرح الأسئلة، عطلوا وضع الوكيل حتى لا تحصلوا على تعديلات بدلا من إجابة.
• اطلبوا عرض اختبار فاشل مع سبب الفشل، وتحققوا من أن الفشل حقيقي.
• راقبوا ما إذا كان التحقق قد عُطل أو إذا استُبدل المسار عبر API بكتابة مباشرة إلى قاعدة البيانات.
• نفذوا commits صغيرة، واحتفظوا بالعمل في فروع منفصلة حتى يمكن التراجع عن تصرفات الوكيل الاعتباطية.
• احسبوا التكلفة وفقا لوقت المراجعة، لا لسعر الاشتراك؛ فقد يتبين أن النموذج الرخيص مكلف.