26 اپریل، 2026 سے، Sora پروڈکٹ اب دستیاب نہیں ہے.
نومبر میں، ہم نے Sora Android ایپ کو دنیا بھر میں لانچ کیا، جس سے کسی بھی Android آلہ کے حامل کو یہ صلاحیت ملی کہ وہ ایک مختصر پرامپٹ کو ایک جاندار ویڈیو میں تبدیل کر سکے۔ لانچ کے دن، یہ ایپ پلے اسٹور میں نمبر 1 پر پہنچ گئی۔ اینڈرائیڈ صارفین نے پہلے 24 گھنٹوں میں ایک ملین سے زیادہ ویڈیوز بنائے۔
لانچ کے پیچھے ایک کہانی ہے: Sora کی پروڈکشن اینڈرائیڈ ایپ کا ابتدائی ورژن 28 دنوں میں تیار کیا گیا، اسی ایجنٹ Codex کی بدولت جو کسی بھی ٹیم یا ڈویلپر کے لیے دستیاب ہے۔
8 اکتوبر سے 5 نومبر، 2025 تک، ایک مختصر انجینئرنگ ٹیم نے Codex کے ساتھ کام کرتے ہوئے اور تقریباً 5 بلین ٹوکن استعمال کرتے ہوئے، Sora کو اینڈرائیڈ کے لیے پروٹوٹائپ سے عالمی لانچ تک پہنچایا۔ اتنے بڑے پیمانے پر استعمال کے باوجود، ایپ کا کریش فری ریٹ 99.9 فیصد ہے اوریہ ایک ایسا آرکیٹیکچر ہے جس پر ہمیں فخر ہے۔ اگر آپ سوچ رہے ہیں کہ آیا ہم نے کوئی خفیہ ماڈل استعمال کیا، تو ہم نے GPT‑5.1‑Codex ماڈل کا ابتدائی ورژن استعمال کیاہے– وہی ورژن جو آج کسی بھی ڈویلپر یا بزنس کے ذریعے CLI، IDE ایکسٹینشن، یا ویب ایپ کے ذریعے استعمال کیا جا سکتا ہے۔
Prompt: figure skater performs a triple axle with a cat on her head
جب Sora کو iOS پر لانچ کیا گیا، تو استعمال میں بے حد اضافہ ہوا۔ لوگوں نے فوراً سلسلہ وار ویڈیوز بنانا شروع کر دیا۔ Android پر، اس کے برعکس، ہمارے پاس صرف ایک چھوٹا سا داخلی پروٹوٹائپ تھا اور Google Play پر پہلے سے رجسٹرڈ صارفین کی بڑھتی ہوئی تعداد تھی۔
جب کوئی بڑا اور دباؤ والا لانچ ہو، تو عام طور پر ردِعمل یہ ہوتا ہے کہ مزید لوگ شامل کر دیے جائیں اور اضافی پروسیس لگا دیے جائیں۔ عام طور پر اس پیمانے اور معیار کی ایک پروڈکشن ایپ کے لیے کئی انجینئرز کو کئی مہینے تک کام کرنا پڑتا ہے، اور ٹیموں کے آپس میں ہم آہنگی کی وجہ سے رفتار بھی سست ہو جاتی ہے۔
امریکی کمپیوٹر آرکیٹیکٹ فریڈ بروکس نے مشہور طور پر خبردار کیا کہ "کسی تاخیر شدہ سافٹ ویئر منصوبے میں مزید لوگوں کا اضافہ اسے مزید تاخیر کا شکار بناتا ہے۔" دوسرے الفاظ میں، جب کسی پیچیدہ منصوبے کو جلدی مکمل کرنے کی کوشش کی جاتی ہے، تو زیادہ انجینئرز شامل کرنے سے اکثر مواصلاتی بوجھ، ٹاسک کی تقسیم، اور انضمام کے اخراجات میں اضافہ سے کارکردگی میں کمی آ سکتی ہے۔ ہم نے اس فراست کو نظرانداز کرنے کے بجائے اس کو مکمل طور پر مانا؛ ہم نے چار انجینئروں کی ایک مضبوط ٹیم تشکیل دی – سب کے سب Codex سے لیس تھے تاکہ ہر انجینئر کے اثر کو نمایاں طور پر بڑھایا جا سکے۔
اس طریقے سے کام کرتے ہوئے، ہم نے Sora کا انٹرنل بلڈ 18 دنوں میں اینڈرائیڈ کے لیے ملازمین کو بھیجا اور 10 دن بعد عوامی طور پر لانچ کیا۔ ہم نے اینڈرائیڈ انجینئرنگ کے طریقوں پر ایک اعلیٰ معیار برقرار رکھا، پائیداری میں سرمایہ کاری کی، اور ایپ کو اسی قابل اعتماد معیار پر رکھا جس کی ہم کسی مزید روایتی منصوبے سے توقع کرتے ہیں۔ (ہم آج بھی Codex کا وسیع پیمانے پر استعمال جاری رکھے ہوئے ہیں تاکہ ایپ میں نئی خصوصیات کو ترقی دے سکیں اور شامل کر سکیں۔)
یہ سمجھنے کے لیے کہ ہم Codex کے ساتھ کیسے کام کرتے ہیں، یہ جاننا معاون ہوتا ہے کہ یہ کہاں بہترین کارکردگی دکھاتا ہے اور کہاں اسے رہنمائی کی ضرورت ہوتی ہے۔ اسے بھرتی کیے گئے ایک نئے سینئر انجینئر کی طرح سمجھنا ایک اچھا طریقہ تھا۔ Codex کی صلاحیت کا مطلب یہ تھا کہ ہم کوڈ لکھنے کے بجائے اس کی ہدایت اور نظر ثانی میں زیادہ وقت صرف کر سکتے تھے۔
جہاں Codex کو رہنمائی کی ضرورت ہوتی ہے
- Codex ابھی تک ان چیزوں کو خود سمجھنے میں بہت اچھا نہیں ہے جنہیں آپ نے واضح طور پر نہیں بتایا (جیسے آپ کے پسندیدہ آرکیٹیکچر پیٹرنز، پروڈکٹ اسٹریٹیجی، اصل صارف کا رویہ، یا اندرونی اصول اور شارٹ کٹس)۔
- اسی طرح، Codex ایپ کو حقیقت میں چلتے ہوئے نہیں دیکھ سکتا تھا: یہ کسی آلہ پر Sora کو نہیں کھول سکتا تھا، یہ محسوس نہیں کر سکتا تھا کہ سکرول میں کچھ غلط ہے، یا یہ نہیں سمجھ سکتا تھا کہ فلو الجھا ہوا ہے۔ صرف ہماری ٹیم ہی ان تجرباتی ٹاسکوں کو مکمل کر سکتی تھی۔
- ہر مثال کے لیے آن بورڈنگ کی ضرورت ہوتی ہے۔ ایک ایسا سیاق و سباق فراہم کرنا جس میں واضح مقاصد، حدود، اور "ہم چیزیں کیسے کرتے ہیں" سے متعلق ہدایات شامل ہوں، Codex کو مؤثر طریقے سے چلانے کے لیے ضروری تھا۔
- اسی طرح، Codex کو گہرے ساخت سے متعلق فیصلوں میں بھی مشکل پیش آتی تھی: اگر اسے خود پر چھوڑ دیا جائے تو یہ ایک اضافی ویو ماڈل بنا دیتا، جبکہ ہمیں موجودہ ویو ماڈل کو بڑھانا ہوتا، یا پھر یہ وہ لاجک UI لیئر میں ڈال دیتا جو واضح طور پر ریپوزٹری میں ہونی چاہیے تھی۔ اس کا اصل مقصد چیز کو فوراً چلانا ہوتا ہے، نہ کہ اس بات کو ترجیح دینا کہ کوڈ طویل‑مدت میں صاف ستھرا رہے۔
ہم نے Codex کو کوڈ بیس میں وافر AGENT.md فائلیں بنانے اور برقرار رکھنے میں مفید پایا۔ اس سے مختلف سیشنز میں ایک ہی رہنمائی اور بہترین عملی طریقے لاگو کرنا آسان ہو گیا۔ مثال کے طور پر، یہ یقینی بنانے کے لیے کہ Codex نے ہمارے اسٹائل گائیڈ لائنز کے مطابق کوڈ لکھا ہے، ہم نے اپنے اعلیٰ سطحی AGENTS.md میں مندرجہ ذیل کو شامل کیا:
جہاں Codex بہترین کارکردگی دکھاتا ہے
- بڑے کوڈ بیسز کو تیزی سے پڑھنا اور سمجھنا: Codex بنیادی طور پر تمام اہم پروگرامنگ زبانوں کو جانتا ہے، اور یہ مختلف پلیٹ فارمز پر یکساں تصورات کو پیچیدہ ایبسٹریکشنزکے بغیر استعمال کرنا آسان بناتا ہے۔
- ٹیسٹنگ کوریج: Codex (منفرد طور پر) یونٹ ٹیسٹس زبردست انداز میں لکھتا ہے جو بہت سی نوعیت کے کیسز کو جامع ہے۔ ہر ٹیسٹ گہرا نہیں تھا، لیکن اس کی جامیعت کی وسعت ریگریشن کو روکنے میں مددگار ثابت ہوئی۔
- فیڈبیک کا اطلاق: اسی طرح، Codex فیڈبیک پر ردعمل دینے میں ماہر ہے۔ جب CI ناکام ہو جاتا، تو ہم لاگ آؤٹ پٹ کو ایک پرامپٹ کی شکل میں دے کر Codex سے اصلاحات کی تجاویز طلب کر سکتے تھے۔
- وسیع پیمانے پر متوازی اور عارضی ایگزیکیوشن: زیادہ تر لوگ ایک وقت میں جتنی سیشنز چل سکتی ہیں، ان کی حد تک کبھی نہیں پہنچ پاتے۔ یہ بہت ممکن ہے کہ متعدد خیالات کو متوازی طور پر آزمایا جائے اور کوڈ کو عارضی سمجھا جائے۔
- نئے نقطہ نظر کی پیشکش: ڈیزائن کی گفتگو میں، ہم نے Codex کو ایک تخلیقی ٹول کے طور پر استعمال کیا تاکہ ممکنہ ناکامی کے نکات کو دریافت کریں اور مسئلہ حل کرنے کے نئے طریقے دریافت کریں۔ مثال کے طور پر، جب ہم نے ویڈیو پلیئر میموری کی آپٹیمائزیشنز کو ڈیزائن کیا، Codex نے متعدد SDKs کا جائزہ لیا تاکہ ایسے طریقے تجویز کیے جا سکیں جنہیں ہم وقت کی کمی کی وجہ سے خود نہیں دیکھ پاتے۔ Codex کی تحقیق سے حاصل کردہ اہم معلومات حتمی ایپ میں میموری کے استعمال کو کم کرنے میں بے حد قیمتی ثابت ہوئیں۔
- زیادہ‑مؤثر کام کو فعال کرنا: عملی طور پر، ہم نے خود کوڈ لکھنے کے بجائے نظر ثانی کرنے اور ہدایت دینے میں زیادہ وقت صرف کیا۔ یہ کہا جا سکتا ہے کہ Codex کوڈ پر نظر ثانی کرنے میں بھی بہت اچھا ہے، اکثر و بیشتر خطاؤوں کو ضم کرنے سے پہلے پکڑ لیتا ہے، جس سے اعتماد میں بہتری آتی ہے۔
جب ہم نے ان خصوصیات کو سمجھ لیا، تو ہمارا کام کرنے کا طریقہ کہیں زیادہ سادہ ہو گیا۔ ہم نے Codex پر انحصار کیا تاکہ اچھی طرح سمجھے جانے والے نمونوں اور محدود دائرہ کار کے اندر بھاری بھرکم کام کو انجام دیا جا سکے، جبکہ ہماری ٹیم نے مجموعی ساخت، صارف کے تجربے، نظامی تبدیلیوں، اور حتمی معیار پر توجہ مرکوز کی۔
حتیٰ کہ سب سے تجربہ کار نئے سینئر ملازم کے پاس بھی ایسا کامل نقطہ نظر نہیں ہوتا جس کی بنیاد پر طویل مدتی تبادلوں سے متعلق بر وقت فیصلہ لیا جا سکے۔ Codex کا فائدہ اٹھانے اور اس کے کام میں نظم و ضبط بنائے رکھنے کے لیے، یہ کلیدی تھا کہ ہم ایپ کے نظام کی ڈیزائن اور اہم تبادلوں کی خود نگرانی کریں۔ اس میں ایپ کی مجموعی ساخت تیار کرنا، اسے واضح ماڈیولز میں تقسیم کرنا، مختلف حصوں کے درمیان انحصار کو منظم کرنا، اور نیویگیشن ترتیب دینا شامل تھا؛ اس کے علاوہ، ہم نے لاگ اِن سسٹم اور بنیادی نیٹ ورکنگ فلو بھی خود نافذ کیے۔
اس بنیاد سے شروع کر کے، ہم نے چند نمائندہ فیچرز مکمل طور پر شروع‑سے‑آخر تک تیار کیے۔ ہم نے ان قواعد کا استعمال کیا جنہیں ہم چاہتے تھے کہ پورا کوڈبیس پیروی کرے اور جیسے جیسے ہم آگے بڑھے، پروجیکٹ کی سطح پر پیٹرنز کو دستاویزی شکل دی۔ جب Codex کو نمائندہ فیچرز کو دکھایا گیا، تو وہ ہمارے معیارات کے اندر زیادہ خود مختاری سے کام کرنے کے قابل ہو گیا۔ اس پروجیکٹ میں، جہاں ہمارا اندازہ ہے کہ تقریباً 85٪ کوڈ Codex نے لکھا، ایک سوچ سمجھ کر بنائی گئی مضبوط بنیاد نے ہمیں بعد میں مہنگی دوبارہ محنت اور بڑے پیمانے پر کوڈ بدلنے سے بچا لیا۔ یہ ہمارے کیے گئے سب سے اہم فیصلوں میں سے ایک تھا۔
خیال یہ نہیں تھا کہ "کچھ ایسا بنائیں جو جلدی سے کام کرے"، بلکہ یہ تھا کہ "کچھ ایسا بنائیں جو اس طرح کام کرے جیسا ہم چاہتے ہیں۔" کوڈ لکھنے کے کئی "صحیح" طریقے موجود ہیں۔ ہمیں Codex کو ایک ایک قدم کی ہدایات دینے کی ضرورت نہیں تھی؛ بلکہ ہمیں اسے یہ دکھانا تھا کہ ہماری ٹیم میں "درست" کام کس طرح کیا جاتا ہے۔ جب ہم نے اپنا نقطہ آغاز اور تعمیر کا طریقہ کار طے کر لیا، تو Codex شروع کرنے کے لیے تیار تھا۔
آزمائش کے طور پر، ہم نے ایک سادہ پرامپٹ دیا: "iOS کوڈ کی بنیاد پر Sora کی اینڈرائیڈ ایپ بنا دو۔ Go" کلک کیا لیکن فورا ہی ہم نے اسے روک دیا۔ اگرچہ Codex نے جو بنائیں وہ تکنیکی طور پر کام کر رہا تھا، لیکن اس پروڈکٹ کا تجربہ معیاری نہیں تھا۔ جب تک اینڈ پوائنٹس، ڈیٹا، اور صارف کے استعمال کے مراحل واضح نہ ہوں، Codex کا ایک ہی بار میں لکھا گیا کوڈ قابلِ اعتماد نہیں رہتا۔ (ویسے بھی، ایجنٹ استعمال کیے بغیر ہزاروں لائنز کا کوڈ ایک ساتھ ضم کرنا خطرناک ہوتا ہے۔)
ہم نے یہ مفروضہ پیش کیا تھا کہ Codex واضح اور اچھی طرح لکھے گئے نمونوں پر مشتمل ایک محفوظ ماحول میں بہترین کام کرے گا؛ اور ہمارا یہ مفروضہ درست ثابت ہوا۔ Codex سے بغیر مناسب سیاق و سباق دیے صرف یہ کہنا کہ "یہ سیٹنگز اسکرین بنا دو" قابلِ اعتماد نتائج نہیں دیتا تھا۔ Codex سے یہ درخواست کرنا کہ "اس سیٹنگز اسکرین کو اسی ساخت اور طرز پر بنائیں جیسے آپ نے ابھی دیکھی ہے" زیادہ مؤثر ثابت ہوا۔ انسانوں نے بنیادی ساخت سے متعلق فیصلے کیے اور مستقل اصول طے کیے، اس کے بعد Codex نے اسی فریم ورک کے اندر بڑی مقدار میں کوڈ لکھا۔
Codex کی صلاحیت کو زیادہ سے زیادہ کرنے کے لیے ہمارا اگلا قدم یہ معلوم کرنا تھا کہ Codex سے طویل مدت تک (فی الحال، 24 گھنٹے سے زیادہ) بغیر نگرانی کے کام کیسے کرائیں.
Codex استعمال کرنے کے ابتدائی دنوں میں، ہم نے سادہ پرامپٹس استعمال کیے، جیسے: "یہ فیچر ہے۔ یہ کچھ فائلیں ہیں۔ براہِ کرم اسے بنا دیں۔" یہ طریقہ کبھی کبھار کام کر جاتا تھا، لیکن زیادہ تر اوقات ایسا کوڈ بنتا تھا جو تکنیکی طور پر تو چل جاتا تھا، مگر ہماری طے شدہ ساخت اور مقاصد سے ہٹ جاتا تھا۔
لہذا ہم نے ورک فلو کو تبدیل کر دیا۔ کسی بھی غیر معمولی تبدیلی کے لیے، ہم نے پہلے Codex سے مدد طلب کی تاکہ ہم نظام اور کوڈ کے کام کرنے کے طریقے کو سمجھ سکیں۔ مثال کے طور پر، ہم Codex سے کہتے تھے کہ وہ باہم متعلقہ فائلوں کو پڑھے اور یہ بتائے کہ کوئی فیچر کیسے کام کرتا ہے، مثلاً ڈیٹا API سے ریپوزٹری لیئر، پھر ویو ماڈل کے ذریعے گزرتا ہوا آخر میں UI تک کیسے پہنچتا ہے۔ اس کے بعد ہم اس کی سمجھ کو درست یا بہتر کرتے تھے۔ (مثال کے طور پر، ہم بتاتے تھے کہ کوئی خاص ایبسٹریکشن دراصل کسی اور لیئر میں ہونی چاہیے، یا یہ کہ کوئی مخصوص کلاس صرف آف لائن موڈ کے لیے ہے اور اسے آگے نہیں بڑھانا چاہیے۔)
بالکل اسی طرح جیسے آپ کسی نئے مگر باصلاحیت ٹیم ممبر کے ساتھ کام کرتے ہیں، ہم نے Codex کے ساتھ مل کر ایک واضح اور مضبوط امپلیمنٹیشن پلان تیار کیا۔ یہ منصوبہ اکثر ایک چھوٹے ڈیزائن ڈاکیومنٹ جیسا ہوتا تھا، جس میں یہ بتایا جاتا تھا کہ کون سی فائلوں میں تبدیلی ہونی ہے، کون سی نئی اسٹیٹس شامل کی جانی ہیں، اور منطق کیسے چلنی چاہیے۔ تب ہی ہم نے Codex سے کہا کہ وہ منصوبے پر عمل درآمد کرنا شروع کرے اور ایک وقت پر ایک ہی اقدام کرے۔ ایک مفید مشورہ یہ تھا کہ جب کام بہت لمبا ہو جاتا اور سیاق و سباق کی حد پوری ہو جاتی، تو ہم Codex سے کہتے تھے کہ اپنا منصوبہ ایک فائل میں محفوظ کر لے۔ اس طرح ہم مختلف سیشنز میں بھی وہی رہنمائی دوبارہ استعمال کر سکتے تھے۔
یہ اضافی منصوبہ بندی کا مرحلہ آخرکار وقت اور محنت کے قابل ثابت ہوا۔ اس کی وجہ سے ہم Codex کو طویل عرصے تک "بغیر نگرانی" کے کام کرنے دے سکے، کیونکہ ہمیں اس کے منصوبے معلوم تھے۔ اس سے کوڈ پر نظر ثانی کرنا بہت آسان ہو گیا، کیونکہ ہم بغیر سیاق و سباق کے تبدیلیاں پڑھنے کے بجائے کوڈ کو براہ راست اپنے منصوبے سے ملا کر دیکھ سکتے تھے۔ اور جب کچھ غلط ہو جاتا، تو ہم پہلے منصوبہ میں پھر کوڈ میں خطا کا ازالہ کرتے۔
یہ احساس بالکل ویسا ہی تھا جیسے ایک اچھی طرح تیار کیا گیا ڈیزائن ڈاکیومنٹ کسی ٹیک لیڈ کو پروجیکٹ کے بارے میں اعتماد دے دیتا ہے۔ ہم صرف کوڈ نہیں بنا رہے تھے؛ بلکہ ایسا کوڈ تیار کر رہے تھے جو ایک مشترکہ روڈ میپ اور مستقبل کے منصوبے کے لیے معاون تھا۔
منصوبے کے عروج پر، ہم اکثر متعدد Codex سیشنز کو متوازی طور پر چلا رہے تھے۔ ایک پلے بیک پر کام کر رہا تھا، دوسرا تلاش پر، ایک اور خرابیوں کو سنبھالنے پر، اور کبھی کبھار کوئی اور ٹیسٹ یا ریفیکٹرز پر۔ یہ کسی ٹول کے استعمال سے زیادہ ایک پوری ٹیم کو مینیج کرنے جیسا محسوس ہوتا تھا۔
ہر سیشن وقتاً فوقتاً ہمیں پیشرفت کے ساتھ رپورٹ کرے گا۔ کوئی کہہ سکتا ہے، "میں نے اس ماڈیول کی منصوبہ بندی مکمل کر لی ہے اور یہ رہی میری تجویز" جبکہ دوسرا کسی نئے فیچر کے لیے بڑی مقدار میں کوڈ میں تبدیلیاں پیش کر دیتا۔ ہر ایک کو توجہ، فیڈبیک، اور نظر ثانی درکار تھا۔ یہ حیرت انگیز طور پر ایسا محسوس ہوتا تھا جیسے کوئی ٹیک لیڈ کئی نئے انجینئرز کو مینیج کر رہا ہو، سب گامزن ہیں اور سبھی کو رہنمائی کی ضرورت ہے۔
نتیجہ یہ تھا کہ سب باہمی تعاون کے ساتھ ایک ہی رخ پر گامزن تھے Codex کی خام کوڈنگ کی صلاحیتوں نے ہمیں بہت زیادہ دستی ٹائپنگ سے آزاد کر دیا۔ ہمارے پاس مجموعی ساخت کے بارے میں سوچنے، پل ریکویسٹز کو غور سے پڑھنے، اور ایپ کو آزمانے کے لیے زیادہ وقت تھا۔
اسی وقت، اس اضافی رفتار کا مطلب یہ بھی تھا کہ ہمارے نظر ثانی کی قطار میں ہمیشہ کچھ نہ کچھ نیا کام موجود رہتا تھا۔ Codex کو سیاق و سباق کی تبدیلی سے کوئی رکاوٹ نہیں ہوئی، لیکن ہمیں ہوئی۔ ڈیولپمنٹ میں ہماری اصل رکاوٹ کوڈ لکھنے سے ہٹ کر فیصلے کرنے، فیڈبیک دینے، اور تبدیلیوں کو آپس میں جوڑنے کی طرف منتقل ہو گئی۔
یہ وہ مقام ہے جہاں بروکس کی بصیرتیں ایک نئے انداز میں سامنے آتی ہیں۔ آپ صرف Codex کے مزید سیشنز شامل کر کے یہ توقع نہیں کر سکتے کہ کام سیدھی رفتار سے تیز ہو جائے، بالکل اسی طرح جیسے کسی پروجیکٹ میں مزید انجینئرز شامل کرنے سے شیڈول خود بخود تیز نہیں ہو جاتا۔ ہر اضافی "ہاتھ" چاہے وہ ورچوئل ہی کیوں نہ ہوں، ہم آہنگی اور مینجمنٹ کی محنت مزید بڑھا دیتے ہیں۔ ہم صرف اکیلے تیزی سے کام کرنے والے لوگ نہیں رہے تھے؛ بلکہ ہم ایک آرکسٹرا کے کنڈکٹر بن گئے تھے، جو مختلف حصوں کو ایک ساتھ ہم آہنگ کر کے چلاتا ہے۔
ہم نے اپنے منصوبے کا آغاز ایک بڑے سنگ میل کے حصول ساتھ کیا: Sora پہلے ہی iOS پر جاری کیا جا چکا تھا۔ ہم نے اکثر Codex کو iOS اور بیک اینڈ کوڈ بیسزدکھاتے تھے تاکہ یہ کلیدی ضروریات اور حدود کو سمجھ سکے۔ پورے پروجیکٹ کے دوران ہم مذاق میں کہتے رہے کہ ہم نے کراس پلیٹ فارم فریم ورک کا اپنا ہی ایک نیا تصور ایجاد کر لیا ہے۔ React Native یا Flutter کو بھول جائیں؛ کراس پلیٹ فارم کا مستقبل صرف Codex ہے۔
اس لطیفے کے پیچھے دو اصول ہیں:
- منطق قابلِ منتقلی ہے۔ چاہے کوڈ Swift میں لکھا گیا ہو یا Kotlin میں، ایپ کی بنیادی لاجک—جیسے ڈیٹا ماڈلز، نیٹ ورک کالز، ویلیڈیشن رولز، اور بزنس لاجک—ایک جیسی ہی رہتی ہے۔ Codex Swift میں لکھے گئے کوڈ کو پڑھ کر اسے Kotlin میں تبدیل کرنے میں بہت ماہر ہے، اور اس دوران کوڈ کے مطلب اور کام کرنے کے طریقے کو ویسا ہی برقرار رکھتا ہے۔
- ٹھوس مثالیں طاقتور سیاق و سباق فراہم کرتی ہیں۔ Codex کا ایک نیا سیشن جو یہ دیکھ سکتا ہو کہ "iOS پر یہ کیسے کام کرتا ہے" اور "یہ اینڈرائیڈ کی ساخت ہے"، اُس سیشن کے مقابلے میں کہیں زیادہ مؤثر ہوتا ہے جو صرف تحریری وضاحتوں پر انحصار کرتا ہو۔
ان اصولوں کو عملی طور پر لاگو کرتے ہوئے، ہم نے iOS، بیک اینڈ، اور اینڈرائیڈ کے کوڈ ریپوز کو ایک ہی ماحول میں اکٹھا دستیاب کر دیا۔ ہم نے Codex کو پرامپٹ دیے جیسے:
"iOS کے کوڈ میں موجود ڈیٹا ماڈلز اور API اینڈ پوائنٹس دیکھو، پھر ہماری موجودہ API کلائنٹ اور ماڈل کلاسز استعمال کرتے ہوئے اینڈرائیڈ پر وہی رویہ بنانے کا منصوبہ تجویز کرو۔"
ایک چھوٹی مگر مفید ترکیب یہ تھی کہ ہم ~/.codex/AGENTS.md میں واضح طور پر لکھ دیتے تھے کہ لوکل کوڈ ریپوز کہاں موجود ہیں اور ہر ریپو میں کیا شامل ہے۔ اس سے Codex کے لیے متعلقہ کوڈ کو دریافت کرنا اور اس میں نیویگیٹ کرنا آسان ہو گیا۔
عملی طور پر، ہم کراس پلیٹ فارم ڈیولپمنٹ مشترکہ ایبسٹریکشن بنانے کے بجائے پلیٹ فارمز کے درمیان ترجمے کے ذریعے کر رہے تھے۔ چونکہ زیادہ تر ترجمے کا کام Codex نے سنبھال لیا، اس لیے ہم ایک ہی چیز دوبارہ بنانے کی لاگت سے بچ گئے۔
وسیع تر سبق یہ ہے کہ Codex کے لیے، سیاق و سباق سب کچھ ہے۔ Codex نے بہترین کام اس وقت کیا جب اسے یہ سمجھ آیا کہ iOS میں فیچر کیسے کام کرتا ہے، اور ساتھ ہی یہ بھی سمجھا کہ ہماری Android ایپ کی ساخت کیسی ہے۔ جب Codex کے پاس وہ سیاق و سباق نہیں تھا، تو یہ "تعاون سے انکار" نہیں کر رہا تھا؛ یہ اندازہ لگا رہا تھا۔ جتنا زیادہ ہم نے اسے ایک نئے ساتھی کی طرح سمجھا اور اسے صحیح ان پٹ دینے میں سرمایہ کاری کی، اتنا ہی بہتر اس نے کارکردگی دکھائی۔
چار ہفتوں کے اسپرنٹ کے اختتام تک، Codex کا استعمال کسی تجربے جیسا نہیں رہا۔ یہ ہمارا معمول کا ڈیولپمنٹ طریقہ بن گیا۔ ہم نے اسے موجودہ کوڈ سمجھنے، تبدیلیوں کی منصوبہ بندی کرنے، اور نئے فیچرز بنانے کے لیے استعمال کیا۔ ہم اس کے آؤٹ پٹ پر بالکل ویسے ہی نظر ثانی کرتے تھے جیسے کسی ٹیم ممبر کے کام کو کرتے ہیں۔ یہ بس وہ طریقہ بن گیا جس سے ہم سافٹ ویئر ڈیلیور کرتے تھے۔
یہ بات واضح ہو گئی کہ اے آئی کی مدد سے ڈیولپمنٹ کرنے سے نظم و ضبط کی ضرورت کم نہیں ہوتی، بلکہ بڑھ جاتی ہے۔ Codex جتنا بھی طاقتور ہو، اس کا مقصد زیادہ تر یہ ہوتا ہے کہ A سے B تک فوراً پہنچ جائے۔ اسی لیے انسانوں کے بغیر اے آئی پر مبنی کوڈنگ کام نہیں کر سکتی۔ سافٹ ویئر انجینئرز حقیقی دنیا کی حدود کو سمجھتے ہیں، سسٹمز کو درست طریقے سے ڈیزائن کرنا جانتے ہیں، اور یہ بھی جانتے ہیں کہ مستقبل کی ڈیولپمنٹ اور پروڈکٹ منصوبوں کو ذہن میں رکھ کر کیسے تعمیر کیا جائے۔ مستقبل کے سافٹ ویئر انجینئرز کی اصل طاقت گہرے سسٹمز کی سمجھ اور اے آئی کے ساتھ طویل عرصے تک مؤثر انداز میں مل کر کام کرنے کی صلاحیت ہوگی۔
سافٹ ویئر انجینئرنگ کے سب سے دلچسپ پہلو شاندار پروڈکٹس بنانا، قابلِ توسیع سسٹمز ڈیزائن کرنا، مشکل مسائل حل کرنا، اور ڈیٹا و کوڈ کے ساتھ تجربات کرنا ہیں۔ لیکن حقیقت یہ ہے کہ ماضی اور حال میں سافٹ ویئر انجینئرنگ کا بڑا حصہ معمولی کاموں پر مشتمل رہا ہے، جیسے بٹن سیدھے کرنا، APIs جوڑنا، اور بار بار لکھا جانے والا کوڈ تیار کرنا۔ اب Codex کی بدولت انجینئرز ان کاموں پر زیادہ توجہ دے سکتے ہیں جو واقعی معنی رکھتے ہیں، اور جن کی وجہ سے ہم اس فن سے محبت کرتے ہیں۔
جب Codex کو ایسے ماحول میں ترتیب دیا جائے جہاں اسے آپ کے مقاصد اور کام کرنے کے طریقے کی پوری سمجھ ہو، تو کوئی بھی ٹیم اپنی صلاحیتوں کو کئی گنا بڑھا سکتی ہے۔ ہمارا لانچ ریٹرو کوئی ایک‑ہی‑فارمولہ‑نہیں، اور ہم یہ دعویٰ بھی نہیں کرتے کہ ہم نے اے آئی کی مدد سے ڈیولپمنٹ کا مسئلہ مکمل طور پر حل کر لیا ہے۔ لیکن ہمیں امید ہے کہ ہمارا تجربہ دوسروں کے لیے Codex کو بہتر طریقے سے استعمال کرنے کے راستے آسان بنائے گا, تاکہ Codex آپ کو مزید مؤثر طریقے سے طاقت دے سکے۔
جب سات ماہ پہلے Codex کو ریسرچ پریویو میں لانچ کیا گیا تھا، تو سافٹ ویئر انجینئرنگ بہت مختلف نظر آتی تھی۔ Sora پر کام کرتے ہوئے ہمیں انجینئرنگ کے اگلے مرحلے کو عملی طور پر دیکھنے کا موقع ملا۔ جیسے جیسے ہمارے اے آئی ماڈلز اور انہیں استعمال کرنے والے ٹولز بہتر ہوتے جائیں گے، اے آئی سافٹ ویئر بنانے کا ایک لازمی حصہ بنتا جائے گا۔
آپ اپنی Codex کی ٹیم کے ساتھ کیا بنائیں گے؟
