دراسة: Cursor يسرّع بداية التطوير، لكنه يراكم لاحقًا ديونًا تقنية على الفريق

تكشف دراسة عن Cursor سيناريو مزعجًا لسوق البرمجة بمساعدة الذكاء الاصطناعي (AI coding): تسرّع الأداة في البداية إنتاج الشيفرة، ثم يلتهم ارتفاع التعقيد والدين التقني المتراكم هذا المكسب. وهذه أخبار سيئة للفرق، لا لأن الذكاء الاصطناعي عديم الفائدة، بل لأن السرعة المحلية تُخفي بسهولة التكاليف المستقبلية.

الدفعة الأولى

قارن مؤلفو الدراسة 807 مستودعات مفتوحة المصدر رصدوا فيها مؤشرات على اعتماد Cursor، مع 1380 مشروعًا مشابهًا لم يعتمده. واستخدموا منهج الفروق في الفروق (difference-in-differences)، ولم ينظروا إلى انطباعات المطورين، بل إلى تطور عدد الـcommits وأسطر الشيفرة ومقاييس الجودة قبل الاعتماد وبعده. وهذا مهم: فالأمر لا يتعلق باختبار مخبري على مهمة واحدة، بل بمحاولة لفهم سلوك مساعد الذكاء الاصطناعي في قواعد شيفرة حية.

في البداية يبدو الأثر مقنعًا. ففي الشهر الأول بعد الاعتماد ارتفع عدد الـcommits بنسبة 55,4%، وحجم الأسطر المضافة بنسبة 281,3%. وفي الشهر الثاني استمرت الزيادة لكنها ضعفت بوضوح: ارتفعت الـcommits بنسبة 14,5%، والأسطر بنسبة 48,4%. وبعد ذلك لم يرصد الباحثون أي أفضلية مستدامة. أي أن Cursor قد يضخّم الإنتاج بسرعة فعلًا، لكن هذا الاندفاع لا يتحول إلى تسارع مستقر في التطوير على المدى البعيد.

ثمن التسارع

بالتوازي مع السرعة، رصدت الدراسة تزايدًا في المشكلات داخل قاعدة الشيفرة. فقد ارتفع عدد تحذيرات التحليل الساكن بعد اعتماد Cursor بنسبة 29,7%، والتعقيد الإجمالي للشيفرة بنسبة 40,7%. في المقابل، لم تُظهر كثافة تكرار الأسطر قفزة ذات دلالة. والاستنتاج هنا مهم: المشكلة ليست في النسخ واللصق وحده، ولا في المقام الأول، بل في أن النظام يصبح أثقل وأكثر تشابكًا وأعلى كلفة في الصيانة.

وعادةً يعني ذلك للفريق عدة أمور:

• تستغرق المراجعة (review) وقتًا أطول مع التغييرات الكبيرة التي يولّدها الذكاء الاصطناعي
• تلتقط الاختبارات وأدوات الـlinter مشكلات أكثر بعد التوليد لا قبله
• تُتخذ القرارات المعمارية بكلفة أقل وبسرعة أكبر، فتصل إلى الفرع الرئيسي (main branch) أسرع
• تصبح الشيفرة المريحة محليًا أصعب قراءةً وأعسر تعديلًا بعد بضعة أسابيع

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

أين تكمن التحفظات

ومع ذلك، لا يمكن قراءة الدراسة بوصفها حكمًا نهائيًا. فقد اعتبر المؤلفون أن المستودع اعتمد Cursor إذا ظهرت في سجله ملفات مثل .cursorrules أو مجلد .cursor. وهذا مؤشر بديل (proxy) مفيد لكنه فجّ. فهو لا يبيّن مدى استخدام الفريق الفعلي للأداة، ولا من استخدمها تحديدًا، ولا ما إذا كان Cursor يُستخدم في التطوير الأساسي لا في تعديلات صغيرة أو في التوثيق. وهذا يحدّ من قوة الاستنتاج السببي.

وثمة تحفظ ثانٍ: قُيّمت الجودة بمقاييس SonarQube، ومنها تحذيرات التحليل الساكن والتعقيد الإدراكي (cognitive complexity). هذه المؤشرات مفيدة، لكنها لا تقيس الواقع الهندسي بكامله. فهي أقل قدرة على رصد الترابط المعماري، وتسرّب منطق المجال (domain logic) عبر الطبقات، والكلفة الفعلية لصيانة النظام. لذلك فالاستنتاج الأمين هو التالي: الدراسة لا تثبت أن كل commit يولّده الذكاء الاصطناعي يجعل الشيفرة أسوأ، لكنها تُظهر بوضوح نمطًا مقلقًا على مستوى المشاريع.

ماذا يعني ذلك

بالنسبة للشركات والفرق الهندسية، ليست هذه حجة ضد البرمجة بمساعدة الذكاء الاصطناعي في ذاتها، بل إشارة إلى ضرورة إعادة بناء العملية حولها. فإذا استُخدم Cursor مجرد مسرّع للتوليد، من دون مراجعة أشد صرامة، وإعادة هيكلة سريعة، وبوابات جودة (quality gates) معززة، فإن قفزة السرعة القصيرة تنقلب بسهولة إلى دين تقني. والدرس الرئيسي بسيط: الذكاء الاصطناعي يزيل الاحتكاك عند كتابة الشيفرة، لكنه لا يلغي كلفة القرارات السيئة، ولا يجعل الصيانة مجانية.