كيف بنى Cursor في ثلاثة أيام وبكلفة 180 دولارًا نموذجًا أوليًا شقّ صفّ فريق التطوير

في شركة تقنية كبرى، تحولت تجربة Cursor سريعًا إلى جدل حول الأهم: سرعة التسليم أم قابلية إدارة الشيفرة. أنفق مهندس معماري للأنظمة 180 دولارًا خلال ثلاثة أيام وعرض على الإدارة نتيجة قابلة للنقر، بينما أمضى الفريق ثلاثة أشهر في بناء وحدة مكتوبة بأنواع محددة (typed) ومغطاة بالاختبارات.

ثلاثة أيام مقابل ثلاثة أشهر

بدأت القصة كتجربة تجريبية عادية لأداة ذكاء اصطناعي. كان في الفريق خمسة مطورين، ووافقت الشركة على تعويض كل منهم عن اشتراك Cursor بقيمة 20 دولارًا شهريًا. وبعد شهر بدت الأرقام هادئة: أنفق ثلاثة موظفين معًا 60 دولارًا. لكن تبيّن لاحقًا أن مهندس الأنظمة المعماري أنفق 180 دولارًا في ثلاثة أيام فقط. فقد استخدم وضع Agent، وحمّل في المحرر تصميمًا من Figma ومكوّنًا قديمًا ونص أمر نصيًا (prompt)، ثم لم يكتب بعد ذلك شيفرة يدويًا تقريبًا. كان Cursor يولّد الواجهات بنفسه، ويقرأ الأخطاء في الطرفية (terminal)، ويصلحها، ويعيد تشغيل البناء.

وعلى الطرف الآخر كان الفريق الذي أمضى ثلاثة أشهر في بناء وحدته وفق القواعد الكلاسيكية. استخدم TypeScript ومراجعة الشيفرة (code review) وStorybook وJSDoc، وكتب نحو 300 اختبار وحدة (unit tests) بتغطية لا تقل عن 85%. أما المهندس المعماري فحصل في الفترة نفسها على نموذج أولي قابل للنقر بوظائف أكثر، لكنه مكتوب بـ Vanilla JS ويضم نحو خمسة اختبارات فقط. وعندما وُضع الحلان جنبًا إلى جنب، لم ترَ الإدارة انضباط التطوير، بل وتيرتين مختلفتين للتسليم: بطيئة وموثوقة مقابل سريعة ولافتة.

لماذا فاز النموذج الأولي

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

«الاختبارات يمكن استكمالها لاحقًا، والسوق لن ينتظر».

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

الوجه الآخر لسرعة الذكاء الاصطناعي

الخطر الرئيسي في هذه القصة ليس مجرد دَين تقني، بل ما يسميه أصحاب الحالة «دين الذكاء الاصطناعي» (AI-debt). ففي حالات التسرع المعتادة يدرك الفريق على الأقل ما سيضطر إلى إعادة كتابته لاحقًا. أما هنا فالمشكلة أعمق: تُولَّد الشيفرة بسرعة كبيرة إلى حد أن مؤلفها نفسه قد لا يفهم تفاصيل التنفيذ. وإذا ظهر خلل لاحقًا أو تغيرت قاعدة عمل، فسيتعين تفويض الصيانة إلى النموذج من جديد، على أمل أن يستعيد السياق بشكل صحيح وألا يبدأ بالهلوسة فوق شيفرة مولَّدة أصلًا.

• لا توجد حزمة تقنيات موحدة ولا أنواع محددة، وهما ما يعتمد عليه الفريق
• تكاد الاختبارات والتوثيق تنعدم، وبالتالي تنخفض إمكانية التنبؤ بنتائج التعديلات
• يقترب عامل الحافلة (bus factor) من واحد: فالصيانة تعتمد على مؤلف واحد وعلى الأداة نفسها
• أي متطلب جديد يرفع خطر كسر شيفرة لا يفهمها أحد فهمًا حقيقيًا

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

ماذا يعني ذلك

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