اعتبارًا من 26 أبريل 2026، لم يعد منتج Sora متاحًا.
شهد شهر نوفمبر إطلاقنا العالمي لتطبيق Sora على نظام التشغيل Android، مما أتاح لكل مستخدم يمتلك جهازًا يعمل بهذا النظام القدرة على تحويل طلب قصير إلى مقطع فيديو نابض بالحياة. وفي يوم الإطلاق، تصدّر التطبيق قائمة الترتيب في متجر Play Store، وتمكّن مستخدمو نظام التشغيل Android من إنشاء ما يزيد عن مليون مقطع فيديو خلال الأربع وعشرين ساعة الأولى.
خلف عملية الإطلاق هذه هناك قصة إنجاز مذهلة: فقد جرى تطوير النسخة الإنتاجية الأولية لتطبيق Sora على نظام التشغيل Android في غضون 28 يومًا فقط، ويرجع الفضل في تحقيق هذا الإنجاز إلى الأداة المتاحة للجميع من فرق تطوير ومطورين: ألا وهي Codex.
خلال الفترة من 8 أكتوبر إلى 5 نوفمبر 2025، عمل فريق هندسي مصغَّر مستخدمًا أداة Codex، وتمكّن من الانتقال بتطبيق Sora على نظام التشغيل Android من نموذج تجريبي إلى الإطلاق العالمي، مستخدمًا ما يقارب 5 مليارات رمز (Token) في هذه العملية. وعلى الرغم من ضيق نطاق العمل، حقّق التطبيق معدل ثبات قياسيًا بلغ 99.9 بالمئة، ويتمتع بهيكلية تقنية نفخر بجودتها. ولمن يتساءل عن النموذج المستخدم، فقد اعتمدنا على إصدار مبكر من نموذج GPT‑5.1‑Codex المتاح اليوم ليستخدمه أي مطور أو شركة سواء عبر واجهة الأوامر النصية أو كإضافة ضمن بيئة التطوير (IDE) أو من خلال تطبيق الويب.
Prompt: figure skater performs a triple axle with a cat on her head
عندما أطلقنا تطبيق Sora على نظام التشغيل iOS، شهدنا تضاعفًا كبيرًا في الاستخدام، حيث بدأ الأفراد على الفور في إنشاء عدد ضخم من مقاطع الفيديو. في المقابل، كنا نمتلك على نظام التشغيل Android نموذجًا تجريبيًا داخليًا محدودًا فقط، وقاعدة متزايدة من المستخدمين الذين سجلوا مسبقًا عبر Google Play.
عادةً ما يكون رد الفعل المعتاد عند مواجهة إطلاق منتج عالي المخاطر وتحت ضغط زمني هو زيادة الموارد البشرية وتكديس العمليات التشغيلية. يتطلب تطبيق إنتاجي بهذا النطاق والجودة عادةً أشهرًا من العمل لعدد كبير من المهندسين، وهو ما يؤدي غالبًا إلى إبطاء وتيرة العمل بسبب تزايد الحاجة إلى التنسيق.
لطالما اشتهر مهندس الحاسوب الأمريكي "فريد بروكس" بتحذيره الشهير: "زيادة عدد الأشخاص في مشروع برمجي متأخر تؤدي إلى مزيد من التأخير." بعبارة أخرى، عند السعي لتسليم مشروع معقد بسرعة، فإن ضم مهندسين إضافيين قد يقلل الكفاءة عبر زيادة حالات التواصل وتقسيم المهام وارتفاع تكاليف دمج الأكواد البرمجية. لذلك، تبنّينا هذه الفكرة بدلاً من تجاهلها؛ حيث شكّلنا فريقًا قويًا مؤلفًا من أربعة مهندسين فقط، وأتحنا لكل واحد منهم استخدام أداة Codex لرفع إنتاجيته بشكل كبير ومضاعف.
بفضل هذه المنهجية، نجحنا في تسليم إصدار داخلي من تطبيق Sora لنظام التشغيل Android للموظفين خلال 18 يومًا فقط، ليتم الإطلاق العام بعدها بعشرة أيام. لقد حافظنا على مستوى عالٍ من ممارسات الهندسة البرمجية الخاصة بنظام التشغيل Android، واستثمرنا في قابلية الصيانة، وحققنا للتطبيق مستوى الاستقرار ذاته المتوقع من أي مشروع تقليدي. (وما زلنا نُوظف أداة Codex بشكل مكثف لمواصلة تطوير التطبيق وإضافة ميزات جديدة إليه).
لفهم آلية عملنا مع أداة Codex، كان من الضروري تحديد نقاط قوة الأداة ومواطن حاجتها إلى التوجيه والإرشاد. كان اعتباره مهندسًا خبيرًا تم تعيينه حديثًا هي الأسلوب الأكثر ملاءمة. وأدى تمكين أداة Codex إلى تحويل تركيزنا؛ حيث أصبحنا نقضي وقتًا أطول في إصدار التوجيهات ومراجعة الأكواد البرمجية بدلًا من تكريس الوقت لكتابتها بأنفسنا.
مواطن التوجيه والإرشاد التي تتطلّبها أداة Codex
- لا تزال Codex غير بارعة في استنتاج المعرفة الضمنية أو السياقية التي لم تُزوَّد بها، وتشمل هذه الجوانب: أنماط الهندسة البرمجية المُفضلة واستراتيجية المنتجات وتحليل السلوك الفعلي للمستخدمين والمعايير الداخلية أو الاختصارات المعتمدة في المؤسسة.
- وبالمثل، افتقرت أداة Codex إلى القدرة على "مشاهدة" التطبيق وهو قيد التشغيل: فهي لا تستطيع فتح تطبيق Sora على جهاز، ولا ملاحظة أن الانتقال بين الشاشات كان غير مريح، ولا استشعار أن التسلسل كان غير واضح. كان فريقنا وحده هو القادر على تغطية هذه المهام الحساسة المتعلقة بالتجربة العملية للمستخدمين.
- تتطلب كل أداة تقنية عملية مُحكمة لبدء التعريف بالتطبيق. ولضمان الأداء الفعّال لأداة Codex، كان من الضروري توفير السياق الشامل، مُرفقًا بأهداف واضحة، وضوابط وإرشادات محددة حول "منهجية العمل الداخلية" للفريق.
- وبالمثل، واجه Codex تحديًا في مسألة تقدير التصميم المعماري العميق: فإذا تُرِك دون إشراف، قد يقترح إنشاء نموذج عرض إضافي بدلًا من توسيع النموذج الحالي، أو قد يضع المنطق البرمجي داخل طبقة العرض بدلًا من موقعه الواضح والمناسب داخل طبقة البيانات أو المخزَن. فدافع الأداة الفطري هو تحقيق مهمة التشغيل المباشر، وليس إعطاء الأولوية للنظافة والاستدامة الهيكلية طويلة الأمد.
وجدنا أنه من المجدي استثمار جهد أداة Codex في إنشاء وإدامة عدد كبير من ملفات AGENT.md عبر كامل قاعدة الأكواد البرمجية. سهّل هذا الإجراء تطبيق نفس الإرشادات والممارسات الفضلى بشكل موحد وثابت عبر جميع جلسات العمل. على سبيل المثال، لضمان أن تكتب أداة Codex الكود البرمجي بما يتوافق مع معايير الأسلوب المعتمدة لدينا، أضفنا الإرشادات التالية إلى ملف AGENT.md الأصلي:
المجالات التي يتفوق فيها Codex
- القدرة على قراءة وفهم قواعد الأكواد البرمجية الكبيرة بسرعة: تتمتع أداة Codex بمعرفة شاملة تقريبًا بجميع لغات البرمجة الرئيسية، مما يسهل الاستفادة من نفس المفاهيم الأساسية عبر منصات متعددة دون الحاجة إلى اللجوء لتعقيدات التجريد.
- تغطية شاملة للاختبارات: تتميز أداة Codex بإتقانها الفريد لكتابة اختبارات الوحدات لتغطية مجموعة واسعة ومتنوعة من الحالات التشغيلية. لم تكن جميع الاختبارات عميقة بالضرورة، لكن اتساع نطاق التغطية كان ذا قيمة كبيرة في منع حالات الانحدار المستقبلي.
- تطبيق الملاحظات: بطريقة مماثلة، أثبتت أداة Codex براعةً في الاستجابة الفورية للملاحظات الواردة. عندما يتعطل CI، يمكن للفريق أن يطلب من أداة Codex اقتراح حلول فورية للمشكلة بتقديم مخرجات السجل مباشرةً إليها.
- التنفيذ المتوازي القابل للتجاهل وعلى نطاق واسع: لن يصل معظم المستخدمين إلى الحد الأقصى لعدد الجلسات التي يمكنهم تشغيلها في وقت واحد. وهذا يتيح عمليًا اختبار أفكار متعددة بالتوازي والنظر إلى الكود البرمجي الناتج على أنه قابل للتجاهل.
- توفير رؤى جديدة: في نقاشات التصميم، وظفنا أداة Codex لأغراض الإنشاء لاستقصاء مواضع القصور المحتملة وابتكار أساليب جديدة لمعالجة المشكلات. على سبيل المثال، أثناء التخطيط لتحسين الذاكرة لمشغل الفيديو، قامت أداة Codex بتحليل حزم SDK مختلفة واقترحت مقاربات لم تكن ضمن خيارات الدراسة الأولية لدينا. وكانت الرؤى الناتجة عن البحث التي أجرته أداة Codex ذات قيمة لا تُعوَّض في تقليل "بصمة الذاكرة" للتطبيق النهائي.
- تمكين العمل ذي الأثر الاستراتيجي: في الممارسة العملية، ركّزنا على قضاء المزيد من الوقت في مراجعة الأكواد البرمجية وتقديم إرشادات بشأنها بدلًا من تكريس الوقت لكتابتها بأنفسنا. ومع ذلك، فإن أداة Codex كانت بارعة في مراجعة الأكواد البرمجية أيضًًا، وغالبًا ما تكتشف الأخطاء قبل دمجها، وهو ما يعزز بشكل كبير من موثوقية الكود.
بمجرد إدراك هذه الميزات، أصبح نموذج عملنا أكثر انسيابية وتركيزًا. لقد اعتمدنا على أداة Codex لتحمّل جزء كبير جدًا من العبء الثقيل داخل أُطر عمل محددة ونماذج مفهومة؛ وفي المقابل، كرّس فريقنا تركيزه على الهندسة المعمارية، وتجربة المستخدم، والتعديلات الهيكلية، وضمان الجودة النهائية.
حتى أفضل الموظفين الجدد من ذوي الخبرة لا يمتلكون المنظور الكافي لاتخاذ قرارات المقايضة بعيدة المدى بشكل فوري. لذلك، ولضمان قوة واستدامة العمل الناتج من أداة Codex، كان من الحاسم أن نشرف بأنفسنا على تصميم أنظمة التطبيق والمقايضات الأساسية. وقد شمل ذلك تحديد معمارية التطبيق، وتقسيم الوحدات، وإدخال التبعيات، وإدارة جوانب التنقل؛ بالإضافة إلى تنفيذ التصديق وآليات الشبكات الأساسية.
انطلاقًا من هذا الأساس المتين، كتبنا بعض الميزات النموذجية من البداية إلى النهاية بشكل يدوي. وطبقنا القواعد التي أردنا أن تتبعها قاعدة الأكواد البرمجية بأكملها، ووثّقنا الأنماط على مستوى المشروع بالتزامن مع كل تقدم نحرزه. وعبر توجيه أداة Codex بناءً على هذه الميزات النموذجية، أصبحت قادرة على العمل باستقلالية أكبر ضمن معاييرنا المحددة. وبالنظر إلى أن 85% من المشروع قُدِّر أنه كُتب بواسطة أداة Codex، فإن هذا الأساس المخطط بعناية جنّبنا التراجع وإعادة الهيكلة المكلفين. لقد كان هذا القرار من أهم القرارات الاستراتيجية التي اتخذناها.
لم يكن هدفنا الأساسي هو ابتكار "شيء فعّال" بأقصى سرعة، بل ابتكار "شيء يتوافق مع طريقتنا المنهجية في العمل". على الرغم من وجود العديد من الأساليب "الصحيحة" لكتابة الكود البرمجي، لم يكن مطلوبًا أن نُملي على أداة Codex ما ستفعله بالتفصيل؛ بل كنا بحاجة إلى توضيح ما هو "الصحيح والمُعتمد" داخل فريقنا تحديدًا. وبمجرد أن رسّخنا منهجيتنا وأسلوبنا المُفضل في الإنشاء، أصبحت أداة Codex مستعدة للانطلاق بكفاءة.
لتقييم النتائج، قمنا بتجربة الطلب التالي: "أنشئ تطبيق Sora لنظام التشغيل Android مستندًا إلى الكود البرمجي لنظام التشغيل iOS. ابدأ". لكننا أوقفنا هذا المسار فورًا. على الرغم من أن الكود البرمجي المُنشأ من أداة Codex كان يعمل من الناحية الفنية، إلا أن تجربة المستخدم للمنتج كانت رديئة للغاية. وبسبب الافتقار إلى إدراك واضح لنقاط الوصول، والمعطيات، وسير عمل المستخدمين، كان الكود البرمجي الذي أنشأته أداة Codex من أول مرة غير جدير بالثقة (فحتى بدون وكيل، يُشكّل دمج آلاف الأسطر من الكود البرمجي مجازفة كبيرة).
لقد افترضنا أن أداة Codex ستتفوق في بيئة اختبار محكمة مزوّدة بأمثلة مكتوبة بشكل جيد؛ ولقد أثبتت التجربة صحة هذا الافتراض. فمطالبة أداة Codex بـ "تصميم شاشة الإعدادات هذه" دون توفير أي سياق تقريبًا كانت غير موثوقة. في المقابل، جاءت نتائج مطالبتها بـ "تصميم شاشة الإعدادات هذه باستخدام نفس الهيكلية والأنماط الموجودة في الشاشة الأخرى التي رأيتها للتو" أفضل بكثير. لقد تولى أعضاء الفريق اتخاذ القرارات الهيكلية وتحديد الثوابت، ومن ثم قامت أداة Codex بملء كميات كبيرة من الكود البرمجي داخل ذلك الهيكل المُحدد.
كانت خطوتنا التالية لتعظيم إمكانات أداة Codex هي استكشاف كيفية تمكينها من العمل لفترات طويلة (مؤخرًا، تجاوزت 24 ساعة) دون الحاجة لإشراف بشري مباشر.
في المراحل الأولى لاستخدام أداة Codex، كنا نعتمد على طلبات عامة مثل: "إليك الخاصية. وإليك بعض الملفات. يرجى البدء في التصميم". على الرغم من أن هذا الأسلوب نجح في بعض الأحيان، إلا أنه في الأغلب أنتج كودًا برمجيًا يمكن تجميعه فنيًا، لكنه يبتعد عن الهيكلية المعمارية والأهداف المحددة.
لذلك، قمنا بتغيير إجراءات العمل. لأي تعديل جوهري، أصبحنا نطلب من أداة Codex أولًا المساعدة في فهم كيفية تشغيل النظام والكود البرمجي ذي الصلة. على سبيل المثال، كنا نطلب منها قراءة مجموعة من الملفات ذات الصلة وتلخيص آلية عمل الميزة؛ مثل كيفية انتقال البيانات من واجهة API عبر طبقة المخزن، إلى نموذج العرض، وصولًا إلى واجهة المستخدم. وبعد ذلك، كنا نصحح أو نحسن إدراكها. كنا نوضح، على سبيل المثال، أن عملية تجريد معينة تخص طبقة أخرى، أو أن فئة محددة موجودة لوضع عدم الاتصال فقط ولا ينبغي توسيعها).
على غرار التعامل مع زميل جديد يتمتع بقدرات عالية، عملنا مع أداة Codex لإنشاء خطة تنفيذ محكمة. كانت هذه الخطة غالبًا ما تتخذ شكل وثيقة تصميم مُصغّرة تُحدّد الملفات المراد تغييرها، والحالات الجديدة الواجب تقديمها، وما ينبغي أن يكون عليه المنطق البرمجي. وعندها فقط، كنا نطلب من أداة Codex البدء بتطبيق الخطة، خطوة بخطوة. نصيحة مهمة: للمهام الطويلة جدًا التي كنا نصل فيها إلى قيود نافذة السياق، كنا نطلب من أداة Codex حفظ خطتها في ملف، مما أتاح لنا تطبيق نفس الإرشادات عبر مثيلات مختلفة.
لقد اتضح أن العملية التخطيطية الإضافية كانت تستحق الجهد المبذول. فقد مكنتنا من ترك أداة Codex تعمل "بشكل مستقل" لفترات زمنية طويلة، وذلك لمعرفتنا المسبقة بخططها. كما سهّلت هذه العملية مراجعة الكود البرمجي، حيث أصبح بإمكاننا التحقق من التطبيق بمقارنته بالخطة الموضوعة، بدلًا من قراءة الكود البرمجي المُقارَن بدون سياق. وعندما يحدث أي عطل، يمكننا كشف أخطاء الخطة أولًا ثم الانتقال إلى الكود ثانيًا.
يشبه هذا التفاعل الطريقة التي يغرس بها مستند التصميم الجيد الثقة لدى قائد التكنولوجيا بخصوص نجاح المشروع. ولم نقتصر على إنشاء الكود البرمجي وحسب، بل كنا ننتج كودًا يدعم خطة عمل مشتركة ومُتفق عليها.
في أوج المشروع، كنا ندير في كثير من الأحيان جلسات Codex متعددة بالتوازي. كانت إحدى الجلسات تعمل على طبقة العرض، وأخرى على البحث، وثالثة على معالجة الأخطاء، بينما كانت جلسات أخرى مخصصة للاختبارات أو إعادة البناء. جعل هذا الأمر يبدو أقل شبهًا باستخدام أداة تقنية وأكثر شبهًا بقيادة فريق عمل هندسي.
كنا نحصل خلال كل جلسة على تقارير دورية وموجزة بشأن التقدم المحرز. تفيد إحدى التقارير: "انتهيت من تخطيط هذه الوحدة، وإليك ما أقترحه"، بينما يقدم تقرير آخر ملف فروقات كبيرًا لميزة جديدة. كان كل تقرير يتطلب الانتباه والنظر في الملاحظات وإتمام المراجعة. كان الأمر مشابهًا بشكل لافت لدور قائد الفريق التقني الذي يعمل مع العديد من المهندسين الجدد، حيث يحقق الجميع تقدمًا، وفي نفس الوقت يحتاجون إلى توجيه مستمر.
كانت النتيجة النهائية هي تأسيس منهجية عمل تعاونية وفعالة. إن قدرة أداة Codex على إنشاء كود برمجي قد أعفتنا من جزء كبير من الكتابة بأنفسنا، وهذا منحنا متسعًا من الوقت للتفكير العميق في بنية النظام ومراجعة طلبات السحب بحرص، واختبار تجربة استخدام التطبيق.
في الوقت نفسه، عنت هذه السرعة الزائدة أن هناك مهامًا تنتظرنا دائمًا في قائمة التدقيق. لم تتأثّر أداة Codex بالانتقال بين المهام، لكننا نحن من تأثرنا. وقد تحوّل التحدي الرئيسي في عملية التطوير من كتابة الكود البرمجي إلى اتخاذ القرارات، وتقديم الملاحظات، ودمج التعديلات.
وهنا تتجلى رؤية بروكس في سياق مختلف: فمجرد إضافة جلسات Codex لن يزيد السرعة بشكل خطّي، تمامًا مثلما لا يمكن إضافة مهندسين إلى مشروع ثم تتوقع تقلص المدة الزمنية بتناسب خطّي. ذلك لأن كل "يد عاملة" إضافية، حتى الرقمية منها، تزيد من أعباء التنسيق. لقد تحوّل دورنا إلى إدارة التنسيق المعماري عوضًا عن الاقتصار على التسريع الفردي لعمليات كتابة الأكواد البرمجية.
انطلق مشروعنا بمرتكز قوي: أن تطبيق Sora كان متاحًا بالفعل على نظام التشغيل iOS. وكنا نوضح باستمرار لأداة Codex مجموعة الأكواد البرمجية المستخدمة في نظام التشغيل iOS ومجموعات الأكواد البرمجية الخلفية (Backend) لتمكين الأداة من فهم المتطلبات والضوابط الرئيسية. وخلال المشروع، كنا نتهكّم بأننا أعدنا اكتشاف مفهوم الإطار البرمجي متعدد المنصات. لم تعد هناك حاجة إلى React Native أو Flutter؛ فالمستقبل للعمل متعدد المنصات يكمن في Codex وحدها.
يرتكز الأمر على مبدأين أساسيين:
- المنطق قابل للنقل: بغض النظر عما إذا كُتب الكود البرمجي بلغة Swift أو Kotlin، يبقى المنطق الأساسي للتطبيق، مثل نماذج البيانات واستدعاءات الشبكة وقواعد التحقق من الصحة ومنطق الأعمال، ثابتًا. تتفوق أداة Codex في قراءة تطبيق مكتوب بلغة Swift وإنتاج مكافئ له بلغة Kotlin مع الحفاظ على الدلالات البرمجية.
- تُقدِّم الأمثلة الواقعية سياقًا ذا قوة عالية: فجلسة أداة Codex التي تستطيع رؤية "كيف يعمل هذا بالتحديد على نظام التشغيل iOS" إلى جانب "هيكل معمارية نظام التشغيل Android" تكون أكثر كفاءة بكثير من الجلسة التي تعمل فقط بناءً على شروحات لغوية عادية.
لوضع هذه المبادئ موضع التنفيذ، قمنا بإتاحة مستودعات الأكواد البرمجية الخاصة بنظام التشغيل iOS والواجهة الخلفية ونظام التشغيل Android في البيئة ذاتها. ثم قدمنا إلى Codex طلبات، مثل:
"اقرأ هذه النماذج ونقاط النهاية في الكود البرمجي من نظام التشغيل iOS، ثم اقترح خطة لتنفيذ السلوك المكافئ على نظام التشغيل Android باستخدام عميل واجهة API الحالي وفئات النماذج الخاصة بنا."
كانت إحدى الحيل البسيطة والمجدية هي إدراج تفاصيل موقع المستودعات المحلية وما تحتويه في ملف ~/.codex/AGENTS.md. وقد ساعد هذا الإجراء أداة Codex في العثور على الكود البرمجي ذي الصلة والتنقل بداخله بسهولة أكبر بكثير.
كنا نقوم بالتطوير متعدد المنصات بشكل فعّال عبر "الترجمة" بدلًا من الاعتماد على "التجريد المشترك". ونظرًا لأن Codex تتولى معظم عملية الترجمة، فقد تجنبنا مضاعفة تكاليف التنفيذ.
العبرة الأهم هي أن السياق هو مفتاح النجاح بالنسبة لأداة Codex. لقد قدَّمت Codex أفضل النتائج عندما أدركت كيفية عمل الميزة بالفعل في نظام التشغيل iOS، إلى جانب فهمها لطريقة تصميم تطبيقنا على نظام التشغيل Android. وعندما افتقرت Codex إلى هذا السياق، لم "تمتنع عن المساعدة"، بل كان تقدِّر الأمور تقديرًا؛ فكلما زاد تعاملنا معها كزميل جديد واستثمرنا في إعطائها المُدخلات الملائمة، تحسَّن إنجازها بشكل ملحوظ.
مع نهاية فترة الأربعة أسابيع المحددة، لم يعد استخدام أداة Codex للتجربة والاختبار فحسب، بل أصبح منهجيتنا التنموية المُتبعة. فقد استخدمناه لفهم الكود البرمجي الحالي، وتخطيط التعديلات، وتطبيق الميزات. فضلًا عن أننا أجرينا تدقيقًا لنتائجه بنفس أسلوب تدقيقنا لعمل أي زميل آخر. وقد أصبح هذا هو الأسلوب المُعتمد لإطلاق البرامج.
لقد بات جليًا أن التطوير المدعوم بالذكاء الاصطناعي لا يقلل من متطلبات الصرامة؛ بل يرفعها. فبرغم كفاءة أداة Codex، يبقى هدفها الأساسي هو إيصالك من "أ" إلى "ب" فقط في الوقت الحالي. ولهذا السبب لا يفلح الكود البرمجي المدعوم بالذكاء الاصطناعي دون تدخل البشر: فمهندسو البرمجيات هم القادرون على استيعاب وتطبيق ضوابط الأنظمة الفعلية، وتحديد أفضل السبل لتصميم البرامج، وكيفية البناء مع أخذ خطط التطوير والمنتجات المستقبلية بعين الاعتبار. إن القدرات العظيمة لمهندس البرمجيات القادم ستكون هي: الفهم المتعمق للأنظمة والقدرة على التعاون بفاعلية مع الذكاء الاصطناعي على امتداد أزمنة طويلة.
إن الأمور الأكثر جاذبية في هندسة البرمجيات هي تصميم منتجات آسرة، وأنظمة قابلة للتوسع، وكتابة خوارزميات صعبة، والتجريب بالبيانات والأنماط والأكواد البرمجية. ومع ذلك، غالبًا ما تميل حقائق هندسة البرمجيات السابقة والحالية نحو المهام المملة: مثل تثبيت موقع الأزرار، وربط نقاط النهاية، وكتابة الأكواد البرمجية المكررة. الآن، تتيح Codex إمكانية التركيز على أهم أجزاء هندسة البرمجيات والأسباب الحقيقية التي تجعلنا نعشق مهنتنا.
عندما يتم وضع Codex في بيئة ذات سياق شامل يفهم فيها أهدافك وطريقة التصميم المُفضلة لديك، يمكن لأي فريق أن يضاعف كفاءته التشغيلية. إن مراجعتنا للمشروع ليست قاعدة ثابتة للجميع، ولا نزعم أننا أنهينا مشكلة التطوير بمساعدة الذكاء الاصطناعي بشكل نهائي. لكننا نأمل أن تساعد تجربتنا في العثور على أفضل الطرق لتوظيف Codex لتمكين قدراتك.
عندما أُطلقت أداة Codex في معاينة بحثية قبل سبعة أشهر، كانت هندسة البرمجيات تبدو مختلفة تمامًا. من خلال مشروع Sora، أتيحت لنا الفرصة لاستكشاف المرحلة التالية في الهندسة البرمجية. ومع استمرار تحسين نماذجنا وأدواتنا، سيصبح الذكاء الاصطناعي جزءًا لا غنى عنه بشكل متزايد في عملية تصميم البرامج.
ما المهام التي ستتركها لأداة Codex لتتفرغ أنت وفريقك للإبداع؟
