ماذا حدث؟
بعد قرابة عام من منح ديزني مهندسيها وصولاً لكلود وCursor، نشرت Times of India وBusiness Insider تفاصيل اجتماع داخلي في قسم البث بديزني بقيادة André Rohe، نائب الرئيس التنفيذي لهندسة المنتجات، أبلغ فيه المهندسين بثلاثة أولويات: رفع سرعة التطوير، تتبع استهلاك الـtokens لكشف الاستخدام غير الكفء، والحفاظ على جودة الكود ومرونة المنتج. الكلمة الأبرز في الاجتماع: Rohe نهى الموظفين عن ممارسة ما سُمّي Tokenmaxxing — أي تكديس استهلاك الـtokens بلا هدف إنتاجي حقيقي فقط لاستغلال الاشتراك. ديزني أطلقت لوحة AI Adoption Dashboard تتيح تتبع استهلاك كل موظف، وبعض المديرين تواصلوا مع المهندسين الذين لم يستخدموا الأدوات — ليس لإجبارهم بل لفهم العوائق. السياق الأوسع: شراكة ديزني المليارية مع OpenAI لترخيص شخصياتها لمنصة Sora انهارت في مارس ٢٠٢٦ بعد أن أوقف OpenAI Sora. Paramount Skydance أيضاً تستعد لفرض حدود شهرية لكل مستخدم على إنفاق الـtokens. وقال ساتيا ناديلا علناً إن Tokenmaxxing إدمان.
ماذا يعني؟
ديزني تعيش التوتر الذي ستعيشه كل شركة كبرى خلال ٢٠٢٦: الذكاء الاصطناعي يرفع السرعة، لكنه لا يضمن الجودة. مشكلة ديزني ليست التكلفة فقط — بل أن بعض المنتجات المبنية بالذكاء الاصطناعي تنكسر بعد الإطلاق لأن المهندسين قبلوا الكود المُولَّد دون مراجعة كافية. هذا يعكس بالضبط ما حذّرنا منه في تقرير حالة الفايب كودنج: ٤٥٪ من الكود المُولَّد يحتوي على ثغرات، و٦٣٪ من المطورين يقضون وقتاً أطول في إصلاحه مما لو كتبوه بأنفسهم. الدرس ليس التوقف عن استخدام الذكاء الاصطناعي، بل استخدامه بمراجعة مقصودة.
لماذا يهمك؟
إذا كنت تبني منتجاً مع فريق أو تقدّم خدمات للعملاء، ضع معايير جودة واضحة قبل أي كود مُولَّد يصل إلى prod: على الأقل مراجعة يدوية للـauth وقواعد البيانات وحالات الحافة edge cases. وإذا كنت تعمل مستقلاً على مشاريع مثل Kenz وAyat، قيّم نفسك: هل أنت تُراجع الكود المُولَّد فعلاً أم تقبله مباشرة؟ تتبع معدل الأخطاء في الـprod مقارنةً بالكود الذي كتبته يدوياً — الفجوة إذا وُجدت ستُخبرك أين تحتاج مزيداً من التحقق.