چگونه از Codex برای ساخت Sora در اندروید در ۲۸ روز استفاده کردیم

از تاریخ ۲۶ آوریل ۲۰۲۶، محصول Sora دیگر در دسترس نیست.

در ماه نوامبر، ما اپلیکیشن Sora برای اندروید را به جهان عرضه کردیم و به هر کسی با دستگاه اندروید این امکان را دادیم که یک درخواست کوتاه را به یک ویدئوی زنده تبدیل کند. در روز راه‌اندازی، اپ به رتبه اول در Play Store رسید. کاربران اندروید در ۲۴ ساعت اول بیش از یک میلیون ویدیو تولید کردند.

پشت این راه‌اندازی یک داستان است: نسخه اولیه اپلیکیشن تولیدی اندروید Sora در ۲۸ روز ساخته شد، به لطف همان عامل که برای هر تیم یا توسعه‌دهنده‌ای در دسترس است: Codex.

از ۸ اکتبر تا ۵ نوامبر ۲۰۲۵، یک تیم مهندسی کوچک که در کنار Codex کار می‌کرد و حدود ۵ میلیارد توکن مصرف می‌کرد، Sora را برای اندروید از نمونه اولیه به عرضه جهانی رساند. با وجود مقیاسش، این اپلیکیشن نرخ بدون کرش ۹۹.۹ درصدی دارد و معماری‌ای که به آن افتخار می‌کنیم. اگر داری فکر می‌کنی که آیا ما از یک مدل مخفی استفاده کردیم، باید بگم که ما از نسخه اولیه GPT‑5.1‑Codex استفاده کردیم مدل - همان نسخه‌ای که هر توسعه‌دهنده یا کسب و کار می‌تواند امروز از طریق CLI، افزونه IDE یا برنامه وب استفاده کند.

وقتی Sora روی iOS عرضه شد، استفاده به شدت افزایش یافت. مردم بلافاصله شروع به تولید ویدیوهای متوالی کردند. در اندروید، برعکس، ما فقط یک نمونه اولیه داخلی کوچک داشتیم و تعداد فزاینده‌ای از کاربران پیش‌ثبت‌نام‌شده در گوگل پلی.

یک واکنش رایج به راه‌اندازی با ریسک بالا و تحت فشار زمانی، افزودن منابع و اضافه کردن فرآیندها است. یک اپلیکیشن تولیدی با این دامنه و کیفیت معمولاً شامل بسیاری از مهندسان می‌شود که برای ماه‌ها کار می‌کنند و به دلیل هماهنگی، سرعت کار کاهش می‌یابد. 

فرد بروکس، معمار کامپیوتر آمریکایی، به‌طور معروف هشدار داد که «افزودن افراد بیشتر به یک پروژه نرم‌افزاری دیرکرده، آن را دیرتر می‌کند.» به عبارت دیگر، وقتی سعی می‌کنی یک پروژه پیچیده را سریع تحویل بدهی، اضافه کردن مهندسان بیشتر می‌تواند با افزایش سربار ارتباطی، پراکندگی وظایف و هزینه‌های یکپارچه‌سازی، کارایی را کاهش دهد. ما به جای نادیده گرفتن این بینش، به آن تکیه کردیم؛ ما یک تیم قوی متشکل از چهار مهندس را گرد هم آوردیم - همه مجهز به Codex برای افزایش چشمگیر تأثیر هر مهندس. 

با این روش کار، ما یک نسخه داخلی از Sora برای اندروید را در ۱۸ روز به کارمندان ارسال کردیم و ۱۰ روز بعد به صورت عمومی منتشر کردیم. ما استاندارد بالایی در شیوه‌های مهندسی اندروید حفظ کردیم، در قابلیت نگهداری سرمایه‌گذاری کردیم و برنامه را به همان سطح اطمینانی که از یک پروژه سنتی‌تر انتظار داشتیم، نگه داشتیم. (ما همچنین امروز به‌طور گسترده از Codex استفاده می‌کنیم تا اپلیکیشن را تکامل دهیم و ویژگی‌های جدیدی به آن اضافه کنیم).

برای اینکه بفهمیم چطور با Codex کار کردیم، خوب است بدانیم در چه زمینه‌هایی می‌درخشد و کجا نیاز به راهنمایی دارد. برخورد با آن مانند یک مهندس ارشد تازه استخدام شده، رویکرد خوبی بود. توانایی Codex به این معنا بود که می‌توانستیم زمان بیشتری را صرف هدایت و بررسی کد کنیم تا اینکه خودمان آن را بنویسیم.

جایی که Codex به راهنمایی نیاز دارد

1. Codex هنوز در استنباط چیزهایی که به آن گفته نشده است (مثل الگوهای معماری مورد علاقه‌ات، استراتژی محصول، رفتار واقعی کاربران و هنجارها یا میانبرهای داخلی) عالی نیست.
2. به‌طور مشابه، Codex نمی‌توانست برنامه را به‌طور واقعی اجراء کند: نمی‌توانست Sora را روی یک دستگاه باز کند، متوجه شود که یک اسکرول نامناسب است یا حس کند که یک جریان گیج‌کننده است. فقط تیم ما می‌توانست این وظایف تجربی را پوشش دهد.
3. هر مورد نیاز به ورود دارد. به اشتراک‌گذاری زمینه با اهداف روشن، محدودیت‌ها و راهنمایی در مورد «چگونه کارها را انجام می‌دهیم» برای اجرای خوب Codex ضروری بود.
4. به همین ترتیب، Codex در قضاوت‌های معماری عمیق دچار مشکل شد: اگر به حال خود رها شود، ممکن است یک مدل نمایشی اضافی معرفی کند، جایی که ما واقعاً می‌خواستیم یک مدل موجود را گسترش دهیم یا منطقی را به لایه UI منتقل کند که به وضوح به یک مخزن تعلق داشت. غریزه‌اش این است که چیزی را راه بیندازد، نه اینکه پاکیزگی بلند مدت را در اولویت بگذارد.

ما دریافتیم که ایجاد و نگهداری تعداد زیادی از فایل‌های AGENT.md توسط Codex در سراسر کد بیس مفید است. این کار استفاده از همان راهنمایی‌ها و بهترین شیوه‌ها را در تمام جلسات آسان کرد. به عنوان مثال، برای اطمینان از اینکه Codex کد را مطابق با دستورالعمل‌های سبک ما نوشته است، موارد زیر را به AGENTS.md سطح بالا اضافه کردیم:

جایی که Codex عالی عمل می‌کند

1. خواندن و درک سریع کدبیس‌های بزرگ: Codex تقریباً تمام زبان‌های برنامه‌نویسی اصلی را می‌شناسد، که این امر استفاده از همان مفاهیم را در بسیاری از پلتفرم‌ها بدون انتزاعات پیچیده آسان‌تر می‌کند.
2. پوشش تست: Codex (به طور منحصر به فردی) مشتاق نوشتن تست‌های واحد برای پوشش انواع مختلفی از موارد است. هر تستی عمیق نبود، اما داشتن گستره پوشش به جلوگیری از بازگشت‌ها کمک می‌کرد. 
3. اعمال بازخورد: به همین ترتیب، Codex به خوبی به بازخورد واکنش نشان می‌دهد. وقتی CI شکست می‌خورد، می‌توانستیم خروجی گزارش را در یک پرامپت قرار دهیم و از Codex بخواهیم که پیشنهاداتی برای رفع مشکلات ارائه کند.
4. اجرای موازی و یک‌بار مصرف: بیشتر افراد به حداکثر تعداد جلساتی که می‌توانند همزمان اجراء کنند، نخواهند رسید. آزمایش چندین ایده به صورت موازی و دیدن کد به عنوان یک مورد مصرفی بسیار ممکن است.
5. ارائه دیدگاه جدید: در بحث‌های طراحی، ما از Codex به عنوان یک ابزار مولد برای بررسی نقاط شکست احتمالی و کشف روش‌های جدید برای حل یک مسئله استفاده کردیم. برای مثال، در حالی که ما بهینه‌سازی‌های حافظه پخش‌کننده ویدیو را طراحی می‌کردیم، Codex از میان چندین SDK جستجو کرد تا روش‌هایی را پیشنهاد دهد که ما زمان کافی برای تحلیل آن‌ها نداشتیم. بینش‌های حاصل از تحقیقات Codex در به حداقل رساندن رد پای حافظه در برنامه نهایی بسیار ارزشمند بودند.
6. فعال‌سازی کارهای با اهرم بالاتر: در عمل، ما بیشتر وقت خود را صرف بررسی و هدایت کد کردیم تا اینکه خودمان آن را بنویسیم. با این حال، Codex در بررسی کد هم بسیار خوب است و اغلب اشکالات را قبل از ادغام شناسایی می‌کند و قابلیت اطمینان را بهبود می‌بخشد.

به محض اینکه این ویژگی‌ها را پذیرفتیم، مدل کاری‌مون ساده‌تر شد. ما به Codex تکیه کردیم تا مقدار زیادی از کارهای سنگین را در الگوهای به‌خوبی درک‌شده و محدوده‌های مشخص انجام دهد، در حالی که Team ما بر روی معماری، تجربه کاربری، تغییرات سیستمی و کیفیت نهایی تمرکز داشت.

حتی بهترین نیروی ارشد جدید هم فوراً دیدگاه مناسبی برای انجام مصالحه‌های بلند مدت ندارد. برای بهره‌برداری از Codex و اطمینان از اینکه کار آن قوی و قابل نگهداری است، مهم بود که خودمان بر طراحی سیستم‌های اپلیکیشن و تصمیم‌گیری‌های کلیدی نظارت داشته باشیم. این موارد شامل شکل‌دهی به معماری اپلیکیشن، ماژولار کردن، تزریق وابستگی و ناوبری بود؛ همچنین احراز هویت و جریان‌های پایه شبکه را پیاده‌سازی کردیم. 

بر اساس این پایه، ما چند ویژگی نماینده را به‌صورت کامل نوشتیم. ما از قوانینی که می‌خواستیم کل کد بیس از آن‌ها پیروی کند استفاده کردیم و الگوهای پروژه را در حین پیشرفت مستند کردیم. با هدایت Codex به ویژگی‌های نماینده، توانست به طور مستقل‌تر در چارچوب استانداردهای ما کار کند. برای پروژه‌ای که تخمین می‌زنیم ۸۵٪ آن توسط Codex نوشته شده است، یک پایه‌ریزی دقیق و برنامه‌ریزی شده از بازگشت‌های پرهزینه و بازسازی جلوگیری کرد. این یکی از مهم‌ترین تصمیم‌هایی بود که گرفتیم. 

ایده این نبود که «چیزی که کار کند» را هر چه سریع‌تر بسازیم، بلکه «چیزی که به نحوی که می‌خواهیم کار کند» را بسازیم. راه‌های «درست» زیادی برای نوشتن کد وجود دارد. ما نیازی نداشتیم که به Codex دقیقاً بگوییم چه کاری انجام دهد؛ ما باید به Codex نشان می‌دادیم که چه چیزی در تیم ما «درست» است. وقتی نقطه شروع و نحوه ساختی که دوست داشتیم را مشخص کردیم، Codex آماده شروع بود.

برای اینکه ببینیم چه اتفاقی می‌افتد، ما درخواست کردیم: «برنامه اندروید Sora را بر اساس کد iOS بسازید.» برو،» اما به سرعت از آن مسیر منصرف شد. در حالی که آنچه Codex ایجاد کرد از نظر فنی کار می‌کرد، تجربه محصول پایین‌تر از حد انتظار بود. و بدون درک واضحی از نقاط انتهایی، داده‌ها و جریان‌های کاربری، کد تک‌مرحله‌ای Codex غیرقابل‌اعتماد بود (حتی بدون استفاده از یک عامل، ادغام هزاران خط کد خطرناک است.) 

ما فرض کردیم که Codex در محیطی با مثال‌های خوب نوشته شده پیشرفت خواهد کرد؛ و حق با ما بود. درخواست از Codex برای «ساخت این صفحه تنظیمات» با تقریباً هیچ زمینه‌ای غیرقابل اعتماد بود. از Codex خواستن که «این صفحه تنظیمات را با همان معماری و الگوهایی که در صفحه دیگری که تازه دیدی استفاده شده، بسازد» خیلی بهتر جواب داد. انسان‌ها تصمیمات ساختاری را گرفتند و ثابت‌ها را تعیین کردند؛ سپس Codex مقدار زیادی کد را درون آن ساختار وارد کرد.

گام بعدی ما در به حداکثر رساندن پتانسیل Codex، پیدا کردن راهی برای توانمندسازی Codex برای کار کردن به مدت طولانی (اخیراً، بیش از ۲۴ ساعت⁠) بدون نظارت بود.

در مراحل اولیه استفاده از Codex، ما به سرعت به سراغ درخواست‌هایی مانند «این ویژگی است» رفتیم. در اینجا چند فایل است. لطفاً آن را بساز. این روش گاهی اوقات جواب می‌داد، اما بیشتر اوقات کدی تولید می‌کرد که از نظر فنی کامپایل می‌شد، در حالی که از معماری و اهداف ما دور می‌شد.

پس ما گردش کار را تغییر دادیم. برای هر تغییری که غیرساده باشد، ابتدا از Codex خواستیم تا به ما کمک کند سیستم و کد را بفهمیم. برای مثال، ازش می‌پرسیم که مجموعه‌ای از فایل‌های مرتبط رو بخونه و خلاصه‌ای از نحوه عملکرد اون ویژگی ارائه بده؛ برای مثال، چطور داده‌ها از API به لایه مخزن، مدل نمایشی و در نهایت به رابط کاربری جریان پیدا می‌کنن. سپس درک آن را اصلاح یا پالایش می‌کردیم. (برای مثال، اشاره می‌کنیم که یک انتزاع خاص واقعاً به لایه دیگری تعلق دارد یا اینکه یک کلاس خاص فقط برای حالت آفلاین وجود دارد و نباید گسترش پیدا کند.)

به‌طور مشابه به نحوی که ممکن است با یک هم‌تیمی جدید و بسیار توانمند همکاری کنی، ما با Codex کار کردیم تا یک برنامه اجرایی محکم ایجاد کنیم. آن طرح اغلب شبیه یک سند طراحی کوچک به نظر می‌رسید که مشخص می‌کرد کدام فایل‌ها باید تغییر کنند، چه حالت‌های جدیدی باید معرفی شوند و منطق چگونه باید جریان پیدا کند. تنها پس از آن از Codex خواستیم که برنامه را مرحله به مرحله اجرا کند. یک نکته مفید: برای وظایف بسیار طولانی که به محدودیت پنجره زمینه خود می‌رسیم، از Codex می‌خواهیم که برنامه‌اش را در یک فایل ذخیره کند تا بتوانیم همان جهت‌گیری را در موارد مختلف اعمال کنیم.

این حلقه اضافی برنامه‌ریزی ارزش وقت را داشت. این به ما اجازه داد که Codex را برای مدت‌های طولانی «بدون نظارت» اجرا کنیم، چون از برنامه‌هایش خبر داشتیم. این کار بازبینی کد را آسان‌تر کرد، چون می‌توانستیم پیاده‌سازی را با برنامه‌مان مقایسه کنیم، به‌جای اینکه یک diff بدون زمینه را بخوانیم. و وقتی مشکلی پیش می‌آمد، می‌توانستیم ابتدا طرح را اشکال‌زدایی کنیم و سپس کد را. 

پویایی مشابه احساسی بود که یک سند طراحی خوب به یک رهبر فناوری در یک پروژه اعتماد به نفس می‌دهد. ما فقط کد تولید نمی‌کردیم: ما کدی تولید می‌کردیم که از یک نقشه راه مشترک پشتیبانی کند.

در اوج پروژه، اغلب چندین جلسه Codex را به‌طور همزمان اجرا می‌کردیم. یکی روی پخش کار می‌کرد، دیگری روی جستجو، دیگری روی مدیریت خطا، و گاهی دیگری روی تست‌ها یا بازسازی‌ها. این کمتر شبیه استفاده از یک ابزار و بیشتر شبیه مدیریت یک تیم بود.

هر جلسه به طور دوره‌ای پیشرفت را به ما گزارش می‌کرد. ممکن است کسی بگوید: «من برنامه‌ریزی این ماژول را تمام کرده‌ام؛ این پیشنهادی است که دارم»، در حالی که دیگری یک diff بزرگ برای یک ویژگی جدید ارائه می‌دهد. هر کدام نیاز به توجه، بازخورد و بررسی داشت. این وضعیت به طرز عجیبی شبیه به رهبری فنی با چندین مهندس جدید بود که همگی در حال پیشرفت بودند و همگی به راهنمایی نیاز داشتند.

نتیجه یک جریان همکارانه بود. قابلیت‌های خام کد نویسی Codex ما را از تایپ دستی فراوانی آزاد کرد. ما زمان بیشتری برای فکر کردن به معماری، بررسی دقیق درخواست‌های pull و آزمایش برنامه داشتیم. 

در عین حال، آن سرعت اضافی باعث می‌شد که همیشه چیزی در صف بررسی ما منتظر باشد. Codex با تغییر زمینه مسدود نشد، اما ما مسدود شدیم. گلوگاه ما در توسعه از نوشتن کد به تصمیم‌گیری، بازخورد دادن و ادغام تغییرات تغییر کرده است.

اینجاست که بینش‌های بروکس به شکلی جدید اثر می‌گذارند. تو نمی‌تونی به سادگی جلسات Codex رو اضافه کنی و انتظار داشته باشی که سرعت به صورت خطی افزایش پیدا کنه، همون‌طور که نمی‌تونی با اضافه کردن مهندسان به یک پروژه انتظار داشته باشی که زمان‌بندی به صورت خطی کاهش پیدا کنه. هر «جفت دست» اضافی، حتی اگر مجازی باشد، سربار هماهنگی را افزایش می‌دهد. ما به جای اینکه فقط نوازندگان انفرادی سریع‌تری باشیم، به رهبر یک ارکستر تبدیل شده بودیم.

ما پروژه‌مون رو با یک گام بزرگ شروع کردیم: Sora قبلاً روی iOS عرضه شده بود. ما به طور مکرر Codex را به پایگاه‌های کد iOS و بک‌اند هدایت می‌کردیم تا به آن کمک کنیم نیازها و محدودیت‌های کلیدی را درک کند. در طول پروژه، به شوخی می‌گفتیم که ایده یک چارچوب چند سکویی را دوباره اختراع کرده‌ایم. React Native یا Flutter را فراموش کن؛ آینده‌ی پلتفرم‌های چند گانه فقط Codex است.

در پس شوخی، دو اصل نهفته است:.

1. منطق قابل حمل است. چه کد به زبان Swift نوشته شده باشد یا Kotlin، منطق برنامه زیربنایی - مدل‌های داده، تماس‌های شبکه، قوانین اعتبارسنجی، منطق کسب و کار - یکسان است. Codex در خواندن پیاده‌سازی Swift و تولید معادل آن در Kotlin که معنای اصلی را حفظ کند، بسیار خوب است.
2. مثال‌های عینی زمینه‌ای قدرتمند فراهم می‌کنند. یک جلسه جدید Codex که می‌تواند «اینجا دقیقاً نحوه کارکرد آن در iOS» و «اینجا معماری Android» را ببیند، بسیار مؤثرتر از جلسه‌ای است که فقط از توضیحات زبان طبیعی استفاده می‌کند.

با به‌کارگیری این اصول، مخازن iOS، بک‌اند و اندروید را در یک محیط مشترک در دسترس قرار دادیم. ما به Codex درخواست‌هایی مانند زیر دادیم:

این مدل‌ها و نقاط پایانی را در کد iOS بخوان و سپس یک برنامه برای پیاده‌سازی رفتار معادل در اندروید با استفاده از کلاینت API و کلاس‌های مدل موجود ما پیشنهاد بده.

یک ترفند کوچک اما مفید این بود که در  ~/.codex/AGENTS.md مشخص کنید که مخازن محلی کجا قرار دارند و چه محتوایی دارند. این کار باعث شد Codex بتواند به‌راحتی کدهای مرتبط را کشف و پیمایش کند.

ما به جای استفاده از انتزاع مشترک، به طور مؤثر توسعه چند سکویی را از طریق ترجمه انجام می‌دادیم. چون Codex بیشتر ترجمه را انجام داد، از دو برابر شدن هزینه‌های پیاده‌سازی جلوگیری کردیم.

درس کلی‌تر این است که برای Codex، زمینه همه چیز است. Codex بهترین عملکرد خود را زمانی داشت که نحوه عملکرد ویژگی در iOS را درک می‌کرد و با درک ساختار اپلیکیشن اندروید ما همراه بود. وقتی Codex آن زمینه را نداشت، به معنای «امتناع از همکاری» نبود؛ بلکه داشت حدس می‌زد. هر چه بیشتر با آن مثل یک هم‌تیمی جدید رفتار کردیم و در دادن ورودی‌های درست به آن سرمایه‌گذاری کردیم، بهتر عمل کرد.

تا پایان دوره چهار هفته‌ای ما، استفاده از Codex دیگر حس یک آزمایش را نداشت و به حلقه پیش‌فرض توسعه ما تبدیل شد. ما از آن برای درک کد موجود، برنامه‌ریزی تغییرات و پیاده‌سازی ویژگی‌ها استفاده کردیم. ما خروجی آن را به همان روشی که کار یک هم‌تیمی را بررسی می‌کنیم، بررسی کردیم. این به سادگی نحوه ارسال نرم‌افزار ما بود.

مشخص شد که توسعه با کمک هوش مصنوعی نیاز به دقت را کاهش نمی‌دهد؛ بلکه آن را افزایش می‌دهد. Codex به همان اندازه که توانمند است، هدفش این است که در حال حاضر از نقطه A به نقطه B برسد. به همین دلیل است که کد نویسی با کمک هوش مصنوعی بدون انسان‌ها کار نمی‌کند. مهندسان نرم‌افزار می‌توانند محدودیت‌های واقعی سیستم‌ها را درک کرده و به کار ببرند، بهترین روش‌ها برای معماری نرم‌افزار را بشناسند و با در نظر گرفتن برنامه‌های توسعه و محصول آینده، نرم‌افزار بسازند. قدرت‌های فوق‌العاده مهندس نرم‌افزار آینده، درک عمیق از سیستم‌ها و توانایی همکاری با هوش مصنوعی در بازه‌های زمانی طولانی خواهد بود. 

جذاب‌ترین بخش‌های مهندسی نرم‌افزار شامل ساخت محصولات جذاب، طراحی سیستم‌های مقیاس‌پذیر، نوشتن الگوریتم‌های پیچیده و آزمایش با داده‌ها، الگوها و کدها است. با این حال، واقعیت‌های مهندسی نرم‌افزار در گذشته و حال اغلب به کارهای عادی‌تر متمایل می‌شوند: متمرکز کردن دکمه‌ها، اتصال نقاط انتهایی، و نوشتن کدهای تکراری. حالا، Codex این امکان را فراهم می‌کند که روی بخش‌های معنا دارتر مهندسی نرم‌افزار و دلایلی که به خاطرشان به حرفه‌مان عشق می‌ورزیم، تمرکز کنیم.

به محض اینکه Codex در یک محیط غنی از زمینه تنظیم شود که اهداف شما و نحوه ساخت شما را درک کند، هر تیم می‌تواند قابلیت‌های خود را چند برابر کند. بازنگری ما در مورد راه‌اندازی، یک دستورالعمل یکسان برای همه نیست و ما ادعا نمی‌کنیم که توسعه با کمک هوش مصنوعی را حل کرده‌ایم. اما امیدواریم که تجربه ما یافتن بهترین راه‌ها برای توانمند ساختن Codex به منظور توانمند کردن تو را آسان‌تر کند. 

وقتی Codex هفت ماه پیش در یک پیش‌نمایش تحقیقاتی راه‌اندازی شد، مهندسی نرم‌افزار بسیار متفاوت به نظر می‌آمد. از طریق Sora، ما توانستیم به فصل بعدی مهندسی بپردازیم. همان‌طور که مدل‌ها و ابزارهای ما بهبود می‌یابند، هوش مصنوعی به بخش جدایی‌ناپذیری از ساخت‌وساز تبدیل خواهد شد. 

با Team خود از Codex چه چیزی می‌سازی؟