Cult.fit تنقل التطوير إلى Codex: شبكة اجتماعية داخل التطبيق في شهرين بدلًا من عام

مشهد مألوف: فريق يعتمد على مساعد، وآخر على مساعد مختلف، ولكل منهما قواعده الخاصة للمستودعات وأوامره الخاصة (prompts). المعرفة لا تنتقل، والمراجعة تختلف من فريق لآخر. أما Cult.fit، إحدى أكبر شركات اللياقة البدنية في الهند (708 مراكز في 77 مدينة، وما يقرب من مليون عضو مدفوع)، فقد عالجت المشكلة بشكل جذري: اختارت Codex منصةً موحدة.

من المهم التنبيه منذ البداية: هذه دراسة حالة منشورة على موقع OpenAI، والأرقام من الشركة نفسها، ولم يتحقق منها أحد بشكل مستقل. لكن مجموعة الممارسات الواردة فيها محددة ومفيدة.

أداة واحدة بدلًا من مزيج متنافر

قبل التوحيد، كان المطورون يستخدمون خليطًا من الوكلاء والمساعدين. ولذلك كان لكل فريق اتفاقياته الخاصة: بنية المستودعات، وتعليمات الوكلاء، والمهارات، والعمليات. أما الآن فكل شيء مشترك: البنية، والمهارات (skills)، والاختبار، ومراجعة الشيفرة، وحلقات التغذية الراجعة.

وبُني فوق ذلك وكلاء متخصصون. يجمع وكيل SRE البيانات من أنظمة المراقبة والسجلات، ويحقق في الحادثة، وفي حالات كثيرة ينشئ بنفسه طلب سحب (pull request) يتضمن الإصلاح المقترح، ثم يراجعه المهندس. وهناك وكلاء أمن يبحثون عن الثغرات، ووكلاء مناوبة للمشكلات المتكررة في بيئة الإنتاج.

كما تتجه الشركة نحو التطوير القائم على المواصفات (spec-driven): فالمواصفة ترافق المهمة عبر دورة حياتها كاملة حتى طلب الدمج الذي يراجعه إنسان. مثال ذلك الخلاصة الاجتماعية في التطبيق. يقدّر المدير التقني سانتوش كومار أنها كانت ستستغرق أكثر من عام، أما الآن فقد أطلقها الفريق في شهرين. وهذا تقديره وليس قياسًا فعليًا.

تطوير لغير المهندسين

الخطوة الثانية أكثر إثارة. فقد جُعلت بيانات الشركة ملائمة لـ Codex، وبدأت الفرق تجيب بنفسها عن الأسئلة الروتينية دون الوقوف في طابور لدى المحللين المركزيين. وبنت الموارد البشرية لنفسها سير عمل (workflow) لتقييم الأداء: الجدولة، وجمع الملاحظات، وتجميع النتائج. وخلال الأشهر الأخيرة بنى غير المهندسين أكثر من 20 تطبيقًا داخليًا.

وقصة لوحات المعلومات مستقلة: فعندما ارتفع سعر خدمة داخلية فجأة، أعاد أحد المهندسين في عطلة نهاية أسبوع بناء الوظائف المطلوبة باستخدام Codex. وهي تعمل الآن على تطبيق خاص، بتوفير يتجاوز 100 ألف دولار سنويًا.

انتبهوا إلى طريقة التطبيق. لم تُمنح الصلاحيات ببساطة. أُقيم هاكاثون كبير، ثم جلسة ليوم واحد للإدارة العليا، بنى فيها كل مدير شيئًا لوظيفته. وتُعقد ساعات مكتبية (office hours) مرتين في الأسبوع، ودُمج مهندسون في أقسام محددة لتقديم الدعم التقني والمتخصص في المجال.

الذكاء الاصطناعي في المنتج والدعم

تطوّر الشركة عبر واجهة OpenAI البرمجية (API) خدمة AI Trainer، ويستخدمها نحو 20% من زوار الصالات. والنسخة الجديدة صوتية: فعلى GPT Realtime يقدّم المدرب نصائح أثناء التمارين ويساعد في تدوين سجل التدريب. وبما أن أكثر من 45% من الأعضاء جاؤوا إلى الصالة للمرة الأولى، فإن الرهان على المرافقة منطقي.

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

ما الذي يمكن الاستفادة منه

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

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