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

كيف قام Cursor في ثلاثة أيام و 180 دولار بإنشاء نموذج أولي قسّم فريق التطوير

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

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

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

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

في الطرف الآخر كان هناك الفريق الذي قضى ثلاثة أشهر في بناء وحدتهم وفقاً للقواعد الكلاسيكية. كان لديهم TypeScript و code review و Storybook و JSDoc وحوالي 300 اختبار وحدة بتغطية لا تقل عن 85%. حقق المهندس المعماري في نفس الفترة الزمنية نموذجاً أولياً قابلاً للنقر مع عدد كبير من الميزات، لكن في Vanilla JS ومع حوالي خمسة اختبارات فقط.

عندما تم وضع كلا الخيارين جنباً إلى جنب، لم ير العمل انضباط التطوير، بل سرعتين مختلفتين للتسليم: بطيئة وموثوقة مقابل سريعة وفعّالة.

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

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

"يمكن إضافة الاختبارات لاحقاً، السوق لن ينتظر." أصبحت هذه الحجة نقطة

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

الجانب السلبي لسرعة الذكاء الاصطناعي

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

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

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

ماذا يعني هذا

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