Codex ကိုသုံးပြီး Sora for Android ကို ၂၈ ရက်အတွင်း ဘယ်လိုတည်ဆောက်ခဲ့သလဲ

၂၀၂၆ ခုနှစ်၊ ဧပြီ ၂၆ ရက်နေ့မှစ၍ Sora ထုတ်ကုန်ကို မရရှိနိုင်တော့ပါ။

နိုဝင်ဘာလတွင် ကျွန်ုပ်တို့သည် Sora Android app ကို ကမ္ဘာတစ်ဝန်း ဖြန့်ချိခဲ့ပြီး Android စက်ရှိသူမည်သူမဆို တိုတောင်းသော တုံ့ပြန်ညွှန်ကြားချက်တစ်ခုကို အသက်ဝင်သော ဗီဒီယိုအဖြစ် ပြောင်းလဲနိုင်ရန် လုပ်ဆောင်ပေးခဲ့သည်။ ဖြန့်ချိသည့်နေ့တွင် app သည် Play Store တွင် နံပါတ် ၁ နေရာသို့ ရောက်ရှိခဲ့သည်။ Android အသုံးပြုသူများက ပထမ ၂၄ နာရီအတွင်း ဗီဒီယို တစ်သန်းကျော် ဖန်တီးခဲ့ကြသည်။

ဤဖြန့်ချိမှု၏ နောက်ကွယ်တွင် ဇာတ်လမ်းတစ်ပုဒ်ရှိသည်။ Sora ၏ production Android app အစောပိုင်းဗားရှင်းကို ၂၈ ရက်အတွင်း တည်ဆောက်ခဲ့ပြီး၊ ထိုအရာသည် မည်သည့်အဖွဲ့ သို့မဟုတ် developer မဆို အသုံးပြုနိုင်သော အလားတူ အေးဂျင့်တစ်ခုဖြစ်သည့် Codex ကြောင့် ဖြစ်သည်။

၂၀၂၅ ခုနှစ် အောက်တိုဘာ ၈ ရက်မှ နိုဝင်ဘာ ၅ ရက်အတွင်း Codex နှင့်အတူ အလုပ်လုပ်ပြီး တိုကင်ပေါင်း ခန့်မှန်းခြေ ၅ ဘီလျံခန့် အသုံးပြုခဲ့သည့် အင်ဂျင်နီယာအဖွဲ့ငယ်တစ်ဖွဲ့သည် prototype အဆင့်မှ ကမ္ဘာလုံးဆိုင်ရာ ဖြန့်ချိမှုအထိ Sora for Android ကို ထုတ်ပေးနိုင်ခဲ့သည်။ အတိုင်းအတာကြီးမားသော်လည်း app တွင် crash-free rate ၉၉.၉ ရာခိုင်နှုန်းရှိပြီး ကျွန်ုပ်တို့ ဂုဏ်ယူသော architecture တစ်ခုလည်း ရှိသည်။ သင်က ကျွန်ုပ်တို့ လျှို့ဝှက်မော်ဒယ်တစ်ခုကို သုံးခဲ့သလားဟု စဉ်းစားနေပါက၊ ကျွန်ုပ်တို့သည် GPT‑5.1‑Codex မော်ဒယ်၏ အစောပိုင်းဗားရှင်းတစ်ခုကို သုံးခဲ့သည် — ယနေ့တွင် developer မည်သူမဆို သို့မဟုတ် စီးပွားရေးလုပ်ငန်းမည်သည့်အဖွဲ့အစည်းမဆို CLI, IDE extension, သို့မဟုတ် web app မှတစ်ဆင့် အသုံးပြုနိုင်သည့် အလားတူဗားရှင်းဖြစ်သည်။

Sora ကို iOS တွင် ဖြန့်ချိသောအခါ အသုံးပြုမှုက အလွန်မြန်ဆန်စွာ တက်လာခဲ့သည်။ လူများက ချက်ချင်းပင် ဗီဒီယိုများ ဆက်တိုက်ဖန်တီးလာကြသည်။ သို့သော် Android ဘက်တွင်မူ ကျွန်ုပ်တို့တွင် အတွင်းပိုင်း prototype သေးသေးလေးတစ်ခုနှင့် Google Play တွင် ကြိုတင်စာရင်းသွင်းထားသူများ တိုးလာနေခြင်းသာ ရှိခဲ့သည်။

အရေးကြီးပြီး အချိန်ဖိအားများသော ဖြန့်ချိမှုတစ်ခုအတွက် ပုံမှန်တုံ့ပြန်မှုမှာ အရင်းအမြစ်များကို ပိုထည့်ခြင်းနှင့် လုပ်ငန်းစဉ်များကို ပိုထည့်ခြင်း ဖြစ်တတ်သည်။ ဤအတိုင်းအတာနှင့် အရည်အသွေးရှိသော production app တစ်ခုကို ပုံမှန်အားဖြင့် အင်ဂျင်နီယာအများအပြားက လများစွာကြာ လုပ်ဆောင်ရပြီး ညှိနှိုင်းမှုများကြောင့် နှေးကွေးတတ်သည်။

အမေရိကန် ကွန်ပျူတာဗိသုကာပညာရှင် Fred Brooks က “နောက်ကျနေသော software project တစ်ခုထဲသို့ လူများ ပိုထည့်လျှင် ပိုနောက်ကျသွားမည်” ဟု ကျော်ကြားစွာ သတိပေးခဲ့သည်။ တစ်နည်းအားဖြင့် ရှုပ်ထွေးသော project တစ်ခုကို မြန်မြန် ဖြန့်ချိရန် ကြိုးစားရာတွင် အင်ဂျင်နီယာများ ပိုထည့်ခြင်းသည် ဆက်သွယ်ရေးဝန်ထုပ်ဝန်ပိုး၊ တာဝန်ခွဲပြားမှုနှင့် ပေါင်းစည်းမှုကုန်ကျစရိတ်များ တိုးစေသောကြောင့် ထိရောက်မှုကို နှေးကွေးစေနိုင်သည်။ ကျွန်ုပ်တို့သည် ဤအယူအဆကို လျစ်လျူမရှုဘဲ လက်ခံအသုံးချခဲ့သည်။ ထို့ကြောင့် အင်ဂျင်နီယာတစ်ဦးချင်းစီ၏ သက်ရောက်မှုကို အလွန်တိုးစေမည့် Codex တပ်ဆင်ထားသော အင်ဂျင်နီယာ ၄ ဦးပါဝင်သည့် အားကောင်းသောအဖွဲ့တစ်ဖွဲ့ကို စုဖွဲ့ခဲ့သည်။

ဤသို့ အလုပ်လုပ်ခြင်းဖြင့် Sora for Android ၏ အတွင်းသုံး build ကို ဝန်ထမ်းများအတွက် ၁၈ ရက်အတွင်း ထုတ်ပေးနိုင်ခဲ့ပြီး၊ ၁၀ ရက်အကြာတွင် အများပြည်သူအတွက် ဖြန့်ချိခဲ့သည်။ ကျွန်ုပ်တို့သည် Android engineering practices များတွင် မြင့်မားသော စံနှုန်းကို ထိန်းသိမ်းခဲ့ပြီး maintainability တွင် ရင်းနှီးမြှုပ်နှံခဲ့ကာ၊ ပိုမိုရိုးရာနည်းလမ်းဖြင့် လုပ်ဆောင်သော project တစ်ခုမှ မျှော်မှန်းမည့် reliability စံနှုန်းအတိုင်း app ကို ထိန်းသိမ်းခဲ့သည်။ (ယနေ့တွင်လည်း app ကို ဆက်လက်ဖွံ့ဖြိုးတိုးတက်စေရန်နှင့် feature အသစ်များ ထည့်သွင်းရန် Codex ကို အကျယ်တဝင့် ဆက်လက်အသုံးပြုနေပါသည်။)

Codex နှင့် ကျွန်ုပ်တို့ မည်သို့ အလုပ်လုပ်ခဲ့သည်ကို နားလည်ရန်၊ ၎င်း အကောင်းဆုံး လုပ်ဆောင်နိုင်သောနေရာနှင့် ညွှန်ကြားမှုလိုအပ်သောနေရာကို သိထားရန် အထောက်အကူပြုသည်။ ၎င်းကို အသစ်ခန့်အပ်ထားသော အတွေ့အကြုံမြင့် အင်ဂျင်နီယာတစ်ဦးကဲ့သို့ ဆက်ဆံခြင်းသည် ကောင်းမွန်သော နည်းလမ်းတစ်ခု ဖြစ်ခဲ့သည်။ Codex ၏စွမ်းရည်ကြောင့် ကျွန်ုပ်တို့သည် ကိုယ်တိုင် code ရေးခြင်းထက် code ကို ဦးတည်ညွှန်ကြားခြင်းနှင့် ပြန်လည်သုံးသပ်ခြင်းတွင် အချိန်ပိုအသုံးပြုနိုင်ခဲ့သည်။

Codex အတွက် လမ်းညွှန်မှုလိုအပ်သည့်နေရာများ

1. Codex သည် ၎င်းအား မပြောထားသေးသောအရာများကို (ဥပမာ - သင်နှစ်သက်သော architecture pattern များ၊ product strategy၊ အမှန်တကယ် အသုံးပြုသူ အပြုအမူများ၊ အတွင်းပိုင်း စံနှုန်းများ သို့မဟုတ် shortcut များ) ခန့်မှန်းနားလည်ရာတွင် မပြည့်စုံသေးပါ။
2. အလားတူပင် Codex သည် app အမှန်တကယ် လည်ပတ်နေပုံကို မမြင်နိုင်ခဲ့ပါ။ ၎င်းသည် စက်တစ်လုံးပေါ်တွင် Sora ကို ဖွင့်ကြည့်၍ scroll လုပ်ရတာ မသင့်တော်ကြောင်း သတိမထားနိုင်သလို၊ flow တစ်ခု ရှုပ်ထွေးနေကြောင်းလည်း မခံစားနိုင်ပါ။ ဤအတွေ့အကြုံဆိုင်ရာ အလုပ်များကို ကျွန်ုပ်တို့၏အဖွဲ့မှသာ ကိုင်တွယ်နိုင်ခဲ့သည်။
3. instance တစ်ခုချင်းစီသည် onboarding လိုအပ်သည်။ ရည်မှန်းချက်များ၊ ကန့်သတ်ချက်များနှင့် “ကျွန်ုပ်တို့ အလုပ်လုပ်ပုံ” ဆိုင်ရာ လမ်းညွှန်ချက်များ ပါဝင်သော context ကို မျှဝေပေးခြင်းသည် Codex က ကောင်းစွာ အကောင်အထည်ဖော်နိုင်ရန် မဖြစ်မနေ လိုအပ်ခဲ့သည်။
4. ထိုနည်းတူ Codex သည် architecture ဆိုင်ရာ အနက်ရှိုင်းဆုံး စီရင်ဆုံးဖြတ်မှုများတွင် အားနည်းခဲ့သည်။ ၎င်းကို ကိုယ့်ဘာသာထားလိုက်လျှင် ရှိပြီးသား view model ကို တိုးချဲ့လိုသောနေရာတွင် view model အပိုတစ်ခု ထည့်သွင်းနိုင်သကဲ့သို့၊ repository ထဲတွင် ရှိသင့်သော logic ကို UI layer ထဲသို့ ထည့်နိုင်သည်။ ၎င်း၏ ပင်ကိုစိတ်က အလုပ်လုပ်သွားအောင် လုပ်ရန်ဖြစ်ပြီး ရေရှည်သန့်ရှင်းမှုကို ဦးစားပေးရန် မဟုတ်ပါ။

ကျွန်ုပ်တို့သည် codebase တစ်လျှောက် AGENT.md file များကို Codex ဖြင့် ဖန်တီးခိုင်းပြီး ထိန်းသိမ်းခိုင်းခြင်းကို အလွန်အသုံးဝင်ကြောင်း တွေ့ရှိခဲ့သည်။ ၎င်းကြောင့် session များတစ်လျှောက် အတူတူသော လမ်းညွှန်ချက်များနှင့် အကောင်းဆုံး လုပ်ထုံးလုပ်နည်းများကို လွယ်ကူစွာ အသုံးချနိုင်ခဲ့သည်။ ဥပမာအားဖြင့် Codex က ကျွန်ုပ်တို့၏ style guideline များအတိုင်း code ရေးစေရန်၊ ကျွန်ုပ်တို့၏ top-level AGENTS.md တွင် အောက်ပါအတိုင်း ထည့်ခဲ့သည် -

Codex က အထူးကောင်းမွန်သည့်နေရာများ

1. codebase ကြီးများကို လျင်မြန်စွာ ဖတ်ရှုနားလည်နိုင်ခြင်း - Codex သည် အဓိက programming language အားလုံးနီးပါးကို သိရှိထားသောကြောင့် ရှုပ်ထွေးသော abstraction များ မလိုဘဲ platform များစွာတစ်လျှောက် တူညီသော အယူအဆများကို အသုံးချရန် ပိုမိုလွယ်ကူစေသည်။
2. testing coverage - Codex သည် case အမျိုးမျိုးကို လွှမ်းခြုံနိုင်သော unit test များ ရေးရန် ထူးခြားစွာ စိတ်အားထက်သန်သည်။ test တိုင်းက နက်ရှိုင်းမှု မရှိခဲ့သော်လည်း လွှမ်းခြုံမှုကျယ်ပြန့်ခြင်းသည် regression များကို ကာကွယ်ရာတွင် အထောက်အကူပြုခဲ့သည်။
3. feedback ကို လိုက်နာအသုံးချနိုင်ခြင်း - ထိုနည်းတူ Codex သည် feedback ကို တုံ့ပြန်ရာတွင် ကောင်းမွန်သည်။ CI fail ဖြစ်သည့်အခါ log output ကို တုံ့ပြန်ညွှန်ကြားချက်ထဲသို့ ကူးထည့်ပြီး ပြင်ဆင်ရန် နည်းလမ်းများကို Codex အား အဆိုပြုခိုင်းနိုင်ခဲ့သည်။
4. အလွန်အမင်း parallel ဖြစ်ပြီး စွန့်ပစ်နိုင်သော execution - လူအများစုသည် တစ်ချိန်တည်းတွင် session အရေအတွက် မည်မျှအထိ အမှန်တကယ် လည်ပတ်စေနိုင်သည်ကို ကန့်သတ်ချက်အဆုံးထိ မတွန်းကြပါ။ အယူအဆများစွာကို တစ်ပြိုင်နက် စမ်းသပ်ပြီး code ကို စွန့်ပစ်နိုင်သောအရာအဖြစ် မြင်ရန် အလွန်ဖြစ်နိုင်သည်။
5. အမြင်သစ် ပေးနိုင်ခြင်း - design ဆွေးနွေးမှုများတွင် ကျွန်ုပ်တို့သည် Codex ကို ဖြစ်နိုင်သော failure point များကို စူးစမ်းရန်နှင့် ပြဿနာတစ်ခုကို ဖြေရှင်းရန် နည်းလမ်းအသစ်များ ရှာဖွေရန် generative tool တစ်ခုအဖြစ် အသုံးပြုခဲ့သည်။ ဥပမာအားဖြင့် video player memory optimization များကို ဒီဇိုင်းဆွဲနေစဉ် Codex သည် SDK များစွာကို စစ်ထုတ်လေ့လာကာ ကျွန်ုပ်တို့ အချိန်မရ၍ ခွဲခြမ်းမစိတ်ဖြာနိုင်သည့် နည်းလမ်းများကို အဆိုပြုခဲ့သည်။ Codex ၏ သုတေသနမှ ရရှိသော insight များသည် နောက်ဆုံး app တွင် memory footprint ကို အနည်းဆုံးဖြစ်စေရန် အလွန်တန်ဖိုးရှိခဲ့သည်။
6. အကျိုးသက်ရောက်မှုမြင့်သော အလုပ်များကို လုပ်နိုင်စေခြင်း - လက်တွေ့တွင် ကျွန်ုပ်တို့သည် ကိုယ်တိုင်ရေးခြင်းထက် code ကို ပြန်လည်သုံးသပ်ခြင်းနှင့် ဦးတည်ညွှန်ကြားခြင်းတွင် အချိန်ပိုကုန်ခဲ့သည်။ ထို့အပြင် Codex သည် code review တွင်လည်း အလွန်ကောင်းမွန်ပြီး merge မလုပ်မီ bug များကို မကြာခဏ ဖမ်းမိကာ reliability ကို မြှင့်တင်ပေးသည်။

ဤလက္ခဏာရပ်များကို လက်ခံသိရှိပြီးနောက် ကျွန်ုပ်တို့၏ အလုပ်လုပ်ပုံက ပိုမိုရှင်းလင်းလာသည်။ ကျွန်ုပ်တို့သည် ကောင်းစွာနားလည်ထားသော pattern များနှင့် ကန့်သတ်ထားသော scope များအတွင်း လေးလံသောအလုပ်အများစုကို Codex အား မှီခိုထားခဲ့ပြီး၊ အဖွဲ့က architecture၊ user experience၊ systemic change များနှင့် နောက်ဆုံးအရည်အသွေးအပေါ် အာရုံစိုက်ခဲ့သည်။

အကောင်းဆုံး အသစ်ခန့် senior hire တစ်ဦးတောင်မှ ရေရှည် trade-off များကို ချက်ချင်း ဆုံးဖြတ်ရန် မှန်ကန်သော မြင်ကွင်းအနေအထား မရှိပါ။ Codex ကို အကျိုးရှိစွာ အသုံးချပြီး ၎င်း၏အလုပ်ကို ခိုင်မာ၍ ထိန်းသိမ်းရလွယ်ကူစေရန် app ၏ system design နှင့် အဓိက trade-off များကို ကျွန်ုပ်တို့ကိုယ်တိုင် ကြီးကြပ်ခဲ့ခြင်းသည် အရေးကြီးခဲ့သည်။ ထိုအရာများတွင် app ၏ architecture၊ modularization၊ dependency injection နှင့် navigation ကို ပုံဖော်ခြင်းတို့ ပါဝင်ပြီး authentication နှင့် အခြေခံ networking flow များကိုလည်း ကျွန်ုပ်တို့ အကောင်အထည်ဖော်ခဲ့သည်။

ဤအခြေခံအုတ်မြစ်ပေါ်မှ ကျွန်ုပ်တို့သည် ကိုယ်စားပြု feature အချို့ကို အစမှအဆုံး ရေးသားခဲ့သည်။ codebase တစ်ခုလုံး လိုက်နာစေလိုသော စည်းမျဉ်းများကို အသုံးပြုခဲ့ပြီး project တစ်လျှောက် pattern များကို သွားရင်း မှတ်တမ်းတင်ခဲ့သည်။ Codex ကို ကိုယ်စားပြု feature များထံ ညွှန်ပြခြင်းဖြင့် ၎င်းသည် ကျွန်ုပ်တို့၏ စံနှုန်းများအတွင်း ပိုမိုလွတ်လပ်စွာ အလုပ်လုပ်နိုင်ခဲ့သည်။ ကျွန်ုပ်တို့ ခန့်မှန်းသည့်အတိုင်း Codex က ၈၅% ခန့် ရေးသားခဲ့သော project တစ်ခုအတွက် ဂရုတစိုက် စီစဉ်ထားသော အခြေခံအုတ်မြစ်သည် ကုန်ကျစရိတ်မြင့်သော နောက်ပြန်လှည့်ခြင်းနှင့် refactor လုပ်ခြင်းကို ရှောင်ရှားနိုင်စေခဲ့သည်။ ၎င်းသည် ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သမျှအနက် အရေးအကြီးဆုံးတစ်ခုဖြစ်ခဲ့သည်။

အယူအဆမှာ “အလုပ်လုပ်သွားမည့်အရာ” ကို အမြန်ဆုံး ဖန်တီးရန် မဟုတ်ဘဲ “ကျွန်ုပ်တို့ လိုချင်သည့်အတိုင်း အရာများ အလုပ်လုပ်ပုံကို နားလည်သော အရာ” ကို ဖန်တီးရန် ဖြစ်သည်။ code ရေးရာတွင် “မှန်ကန်သော” နည်းလမ်းများစွာ ရှိသည်။ Codex ကို ဘာလုပ်ရမည်ဟု တိတိကျကျ ပြောရန် မလိုအပ်ခဲ့ပါ။ ကျွန်ုပ်တို့အဖွဲ့အတွက် ဘာက “မှန်ကန်” သည်ကို Codex အား ပြသရန် လိုအပ်ခဲ့သည်။ စတင်မည့်အခြေခံနှင့် တည်ဆောက်လိုသောပုံစံကို သတ်မှတ်ပြီးနောက် Codex သည် စတင်ရန် အသင့်ဖြစ်နေခဲ့သည်။

ဘာဖြစ်မလဲကြည့်ရန် ကျွန်ုပ်တို့ “iOS code ကို အခြေခံပြီး Sora Android app ကို တည်ဆောက်ပါ။ စပါ” ဟု တုံ့ပြန်ညွှန်ကြားချက်ပေးကြည့်ခဲ့သော်လည်း မကြာမီ ထိုလမ်းကြောင်းကို ရပ်တန့်ခဲ့သည်။ Codex ဖန်တီးခဲ့သော အရာသည် နည်းပညာပိုင်းအရ အလုပ်လုပ်ခဲ့သော်လည်း product experience မှာ မကျေနပ်စရာကောင်းခဲ့သည်။ ထို့အပြင် အဆုံးမှတ်များ၊ data နှင့် user flow များကို ရှင်းလင်းစွာ နားမလည်ဘဲ Codex ၏ single-shot code သည် ယုံကြည်စိတ်ချရမှု နည်းခဲ့သည်။ (အေးဂျင့် မသုံးဘဲတောင် code လိုင်းထောင်ပေါင်းများစွာကို merge လုပ်ခြင်းမှာ အန္တရာယ်ရှိသည်။)

ကောင်းစွာရေးထားသော ဥပမာများပါဝင်သည့် sandbox တစ်ခုအတွင်း Codex က အကောင်းဆုံး လုပ်ဆောင်မည်ဟု ကျွန်ုပ်တို့ ခန့်မှန်းခဲ့ပြီး၊ အမှန်လည်း ထိုသို့ ဖြစ်ခဲ့သည်။ context မရှိသလောက်ဖြင့် “ဒီ settings screen ကို တည်ဆောက်ပါ” ဟု Codex အား ပြောခြင်းမှာ ယုံကြည်စိတ်ချရမှု နည်းခဲ့သည်။ “သင်刚刚မြင်ခဲ့သော အခြား screen ၏ architecture နှင့် pattern များကို အသုံးပြုပြီး ဒီ settings screen ကို တည်ဆောက်ပါ” ဟု တောင်းဆိုခြင်းက ပိုမိုကောင်းမွန်စွာ အလုပ်လုပ်ခဲ့သည်။ လူသားများက ဖွဲ့စည်းပုံဆိုင်ရာ ဆုံးဖြတ်ချက်များ ချမှတ်ပြီး invariants များကို သတ်မှတ်ခဲ့ကြသည်။ ထို့နောက် Codex က ထိုဖွဲ့စည်းပုံအတွင်း code ပမာဏများစွာကို ဖြည့်ဆည်းပေးခဲ့သည်။

Codex ၏ အလားအလာကို အများဆုံး အသုံးချရန် ကျွန်ုပ်တို့၏ နောက်တစ်ဆင့်မှာ Codex ကို ကြီးကြပ်မှုမရှိဘဲ အချိန်ရှည်ကြာ အလုပ်လုပ်စေရန် (မကြာသေးမီက ၂၄ နာရီကျော်⁠) မည်သို့ စွမ်းဆောင်နိုင်စေမလဲကို ရှာဖွေရန် ဖြစ်ခဲ့သည်။

Codex ကို စတင်အသုံးပြုစဉ် အစောပိုင်းတွင် “ဒီမှာ feature ပါ။ ဒီမှာ file အချို့ပါ။ ကျေးဇူးပြု၍ တည်ဆောက်ပေးပါ” ဟုသော တုံ့ပြန်ညွှန်ကြားချက်များသို့ တိုက်ရိုက် သွားခဲ့ကြသည်။ တစ်ခါတစ်ရံ အလုပ်ဖြစ်ခဲ့သော်လည်း များသောအားဖြင့် compile တက်သော်လည်း ကျွန်ုပ်တို့၏ architecture နှင့် ရည်မှန်းချက်များမှ လွဲချော်သည့် code ကို ထုတ်ပေးခဲ့သည်။

ထို့ကြောင့် workflow ကို ပြောင်းလဲခဲ့သည်။ အလွယ်တကူ မဖြစ်နိုင်သော ပြောင်းလဲမှုမည်သည့်အတွက်မဆို ပထမဦးစွာ system နှင့် code မည်သို့ အလုပ်လုပ်သည်ကို နားလည်နိုင်ရန် Codex ၏ အကူအညီကို တောင်းခဲ့သည်။ ဥပမာအားဖြင့် ဆက်စပ် file များအစုကို ဖတ်ရှုပြီး ထို feature မည်သို့ အလုပ်လုပ်သည်ကို အကျဉ်းချုပ်ရန် တောင်းမည်ဖြစ်သည်။ ဥပမာ API မှ repository layer၊ view model နှင့် UI အထိ data မည်သို့ စီးဆင်းသည်ကို ဖော်ပြခိုင်းသည်။ ထို့နောက် ၎င်း၏ နားလည်မှုကို ကျွန်ုပ်တို့ ပြင်ဆင် သို့မဟုတ် ပိုမိုတိကျစေခဲ့သည်။ (ဥပမာ abstraction တစ်ခုသည် အခြား layer တစ်ခုတွင် ရှိသင့်ကြောင်း၊ သို့မဟုတ် class တစ်ခုသည် offline mode အတွက်သာ ရှိနေပြီး တိုးချဲ့မသင့်ကြောင်းကို ညွှန်ပြမည်ဖြစ်သည်။)

စွမ်းရည်မြင့် အသင်းဖော်အသစ်တစ်ဦးနှင့် သင် ဆက်ဆံသကဲ့သို့ပင် ကျွန်ုပ်တို့သည် Codex နှင့်အတူ ခိုင်မာသော implementation plan တစ်ခု ဖန်တီးခဲ့သည်။ ထို plan သည် မည်သည့် file များ ပြောင်းရမည်၊ state အသစ်များကို ဘာတွေ မိတ်ဆက်ရမည်၊ logic မည်သို့ စီးဆင်းရမည် ဆိုသည်တို့ကို ညွှန်ကြားသော design document အတိုလေးတစ်ခုနှင့် မကြာခဏ ဆင်တူခဲ့သည်။ ထို့နောက်မှသာ Codex ကို တစ်ဆင့်ချင်းစီ plan ကို စတင်အကောင်အထည်ဖော်ခိုင်းခဲ့သည်။ အထောက်အကူပြု အကြံပြုချက်တစ်ခုမှာ context window ၏ ကန့်သတ်ချက်ကို ထိမိသော အလွန်ရှည်လျားသည့် task များအတွက် Codex ကို ၎င်း၏ plan ကို file တစ်ခုသို့ သိမ်းဆည်းခိုင်းခြင်းဖြစ်ပြီး၊ ၎င်းကြောင့် instance များတစ်လျှောက် တူညီသော ဦးတည်ချက်ကို အသုံးချနိုင်ခဲ့သည်။

ဤအပိုအစီအစဉ်ချသော loop သည် အချိန်ပေးရကျိုးနပ်ကြောင်း နောက်ဆုံးတွင် ထင်ရှားလာသည်။ ကျွန်ုပ်တို့သည် Codex ၏ plan များကို သိထားသောကြောင့် ၎င်းကို အချိန်ကြာကြာ “ကြီးကြပ်မှုမရှိဘဲ” အလုပ်လုပ်စေနိုင်ခဲ့သည်။ context မရှိဘဲ diff ကို ဖတ်ရှုရခြင်းထက် implementation ကို plan နှင့် နှိုင်းယှဉ်စစ်ဆေးနိုင်သဖြင့် code review လည်း ပိုလွယ်ကူလာသည်။ တစ်ခုခု မှားယွင်းသွားသည့်အခါ code ကို ဒုတိယဦးစားပေးအဖြစ် ထားပြီး plan ကို ပထမဦးစားပေး debug လုပ်နိုင်ခဲ့သည်။

ဤ dynamic သည် ကောင်းမွန်သော design document တစ်ခုက tech lead တစ်ဦးကို project တစ်ခုအပေါ် ယုံကြည်မှု ပေးသည့်နည်းလမ်းနှင့် ဆင်တူသည်။ ကျွန်ုပ်တို့သည် code ကိုသာ ဖန်တီးနေခြင်း မဟုတ်ဘဲ မျှဝေထားသော roadmap ကို အထောက်အပံ့ပေးသည့် code ကို ထုတ်လုပ်နေခြင်း ဖြစ်သည်။

project ၏ အမြင့်ဆုံးအချိန်တွင် ကျွန်ုပ်တို့သည် Codex session များစွာကို တစ်ပြိုင်နက် လည်ပတ်စေခဲ့သည်။ တစ်ခုက playback ကို လုပ်နေသည်၊ တစ်ခုက search ကို၊ တစ်ခုက error handling ကို၊ တစ်ခါတစ်ရံ အခြားတစ်ခုက test များ သို့မဟုတ် refactor များကို လုပ်နေသည်။ ၎င်းသည် tool တစ်ခုကို အသုံးပြုနေခြင်းထက် အဖွဲ့တစ်ဖွဲ့ကို စီမံခန့်ခွဲနေသလို ပိုမို ခံစားရစေခဲ့သည်။

session တစ်ခုချင်းစီက အချိန်အလိုက် တိုးတက်မှုများကို ကျွန်ုပ်တို့ထံ ပြန်တင်ပြမည်ဖြစ်သည်။ တစ်ခုက “ဒီ module အတွက် planning ပြီးပါပြီ၊ ဒီလို အဆိုပြုပါတယ်” ဟု ပြောနိုင်ပြီး၊ အခြားတစ်ခုက feature အသစ်တစ်ခုအတွက် ကြီးမားသော diff တစ်ခုကို တင်ပြမည်ဖြစ်သည်။ တစ်ခုချင်းစီသည် အာရုံစိုက်မှု၊ feedback နှင့် review လိုအပ်ခဲ့သည်။ ၎င်းသည် တိုးတက်နေသော engineer အသစ်များ အများအပြားကို ဦးဆောင်နေသည့် tech lead တစ်ဦးဖြစ်နေရသလို အံ့အားသင့်ဖွယ် ဆင်တူခဲ့သည်။

ရလဒ်မှာ ပူးပေါင်းဆောင်ရွက်သည့် flow တစ်ခု ဖြစ်လာခဲ့သည်။ Codex ၏ အခြေခံ coding စွမ်းရည်သည် ကျွန်ုပ်တို့ကို manual typing အများအပြားမှ လွတ်မြောက်စေခဲ့သည်။ ထို့ကြောင့် architecture ကို စဉ်းစားရန်၊ pull request များကို ဂရုတစိုက် ဖတ်ရှုရန်နှင့် app ကို စမ်းသပ်ရန် အချိန်ပို ရရှိခဲ့သည်။

တစ်ချိန်တည်းမှာပင် ထိုအမြန်နှုန်းတိုးလာခြင်းကြောင့် review queue တွင် ကျွန်ုပ်တို့ကို စောင့်နေသည့်အရာတစ်ခုခု အမြဲရှိနေခဲ့သည်။ Codex သည် context switching ကြောင့် မပိတ်မိသော်လည်း ကျွန်ုပ်တို့က မလွတ်နိုင်ခဲ့ပါ။ ဖွံ့ဖြိုးတိုးတက်ရေးတွင် ကျွန်ုပ်တို့၏ bottleneck သည် code ရေးခြင်းမှ ဆုံးဖြတ်ချက်ချခြင်း၊ feedback ပေးခြင်းနှင့် အပြောင်းအလဲများ ပေါင်းစည်းခြင်းသို့ ရွှေ့ပြောင်းသွားခဲ့သည်။

ဤနေရာတွင် Brooks ၏ insight များသည် နည်းလမ်းအသစ်ဖြင့် သက်ရောက်လာသည်။ project တစ်ခုတွင် engineer များ ထပ်ပေါင်းထည့်သလို အချိန်ဇယားသည် တန်းတူအချိုးဖြင့် မလျှော့ချနိုင်သကဲ့သို့ Codex session များကိုလည်း ပေါင်းထည့်ရုံဖြင့် linear speedup ကို မျှော်လင့်၍ မရပါ။ virtual ဖြစ်သည့် “လက်အပိုတစ်စုံ” တစ်ခုချင်းစီတောင် ညှိနှိုင်းရေး overhead ကို တိုးစေသည်။ ကျွန်ုပ်တို့သည် အမြန်ပိုသော solo player များ မဟုတ်တော့ဘဲ orchestra conductor များ ဖြစ်လာခဲ့သည်။

ကျွန်ုပ်တို့၏ project ကို စတင်ရာတွင် အလွန်အရေးပါသော အခြေခံတစ်ခု ရှိခဲ့သည်။ Sora ကို iOS တွင် အပြီးသတ် ဖြန့်ချိထားပြီးသား ဖြစ်သည်။ အဓိကလိုအပ်ချက်များနှင့် ကန့်သတ်ချက်များကို နားလည်စေရန် iOS နှင့် backend codebase များကို Codex အား မကြာခဏ ညွှန်ပြခဲ့သည်။ project တစ်လျှောက်လုံး “cross-platform framework” ဆိုသည့် အယူအဆကို ကျွန်ုပ်တို့ ပြန်လည်တီထွင်နေသလို ရယ်မောပြောဆိုခဲ့ကြသည်။ React Native သို့မဟုတ် Flutter ကို မေ့လိုက်ပါ — cross-platform ၏ အနာဂတ်မှာ Codex ပဲ ဖြစ်သည်။

ဤဟာသဆန်သည့် စကားအောက်တွင် အခြေခံမူ နှစ်ရပ် ရှိသည် -

1. logic သည် ရွှေ့ပြောင်းအသုံးချနိုင်သည်။ code ကို Swift ဖြင့်ရေးသည်ဖြစ်စေ Kotlin ဖြင့်ရေးသည်ဖြစ်စေ အခြေခံ application logic — data model များ၊ network call များ၊ validation rule များ၊ business logic — တူညီနေသည်။ Codex သည် Swift implementation တစ်ခုကို ဖတ်ရှုပြီး အဓိပ္ပာယ်မပြောင်းလဲဘဲ Kotlin ဖြင့် ညီမျှသော implementation တစ်ခု ဖန်တီးရာတွင် အလွန်ကောင်းမွန်သည်။
2. တိကျသော ဥပမာများက အားကောင်းသော context ကို ပေးသည်။ “ဒီအရာ iOS တွင် အတိအကျ ဘယ်လို အလုပ်လုပ်တယ်” နှင့် “ဒီမှာ Android architecture ပါ” ကို မြင်နိုင်သော Codex session အသစ်တစ်ခုသည် natural language ဖော်ပြချက်များသာ ရှိသော session ထက် များစွာ ပိုမိုထိရောက်သည်။

ဤအခြေခံမူများကို လက်တွေ့အသုံးချရန် iOS, backend နှင့် Android repository များကို တူညီသော environment ထဲတွင် ရရှိနိုင်အောင် လုပ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် Codex အား ဤကဲ့သို့သော တုံ့ပြန်ညွှန်ကြားချက်များ ပေးခဲ့သည် -

“iOS code ထဲရှိ ဒီ model များနှင့် အဆုံးမှတ်များကို ဖတ်ပြီးနောက် ကျွန်ုပ်တို့၏ ရှိပြီးသား API client နှင့် model class များကို အသုံးပြုကာ Android တွင် အလားတူ အပြုအမူကို အကောင်အထည်ဖော်ရန် plan တစ်ခု အဆိုပြုပါ။”

အသေးစားသော်လည်း အသုံးဝင်သော လှည့်ကွက်တစ်ခုမှာ local repository များ ဘယ်နေရာတွင် ရှိပြီး ၎င်းတို့တွင် ဘာများ ပါဝင်သည်ကို ~/.codex/AGENTS.md တွင် အသေးစိတ် ဖော်ပြထားခြင်းဖြစ်သည်။ ထို့ကြောင့် Codex သည် သက်ဆိုင်ရာ code ကို ပိုမိုလွယ်ကူစွာ ရှာဖွေ၍ လမ်းညွှန်နိုင်ခဲ့သည်။

အမှန်တကယ်အားဖြင့် ကျွန်ုပ်တို့သည် shared abstraction အစား translation မှတစ်ဆင့် cross-platform development ကို လုပ်ဆောင်နေခဲ့သည်။ Codex က translation အများစုကို ကိုင်တွယ်ပေးခဲ့သောကြောင့် implementation cost ကို နှစ်ဆတိုးရခြင်းကို ရှောင်ရှားနိုင်ခဲ့သည်။

ပိုမိုကျယ်ပြန့်သော သင်ခန်းစာမှာ Codex အတွက် context သည် အရာအားလုံးဖြစ်သည် ဆိုခြင်းဖြစ်သည်။ Codex သည် feature တစ်ခု iOS တွင် မည်သို့ အလုပ်လုပ်နေပြီး ကျွန်ုပ်တို့၏ Android app ကို မည်သို့ ဖွဲ့စည်းထားသည်ကို နားလည်ထားသောအခါ အကောင်းဆုံး လုပ်ဆောင်နိုင်ခဲ့သည်။ ထို context မရှိသောအခါ Codex သည် “ပူးပေါင်းဆောင်ရွက်ရန် ငြင်းဆန်နေသည်” မဟုတ်ဘဲ ခန့်မှန်းနေခြင်းသာ ဖြစ်သည်။ ၎င်းကို အသင်းဖော်အသစ်တစ်ဦးကဲ့သို့ ဆက်ဆံပြီး မှန်ကန်သော input များ ပေးရာတွင် ပိုမိုရင်းနှီးမြှုပ်နှံလေလေ ၎င်း၏ စွမ်းဆောင်ရည် ပိုကောင်းလေလေ ဖြစ်သည်။

လေးပတ်ကြာ sprint ၏ အဆုံးတွင် Codex ကို အသုံးပြုခြင်းသည် စမ်းသပ်မှုတစ်ခုလို မထင်တော့ဘဲ ကျွန်ုပ်တို့၏ ပုံမှန် development loop ဖြစ်လာခဲ့သည်။ ၎င်းကို ရှိပြီးသား code ကို နားလည်ရန်၊ ပြောင်းလဲမှုများကို အစီအစဉ်ချရန်နှင့် feature များကို အကောင်အထည်ဖော်ရန် အသုံးပြုခဲ့သည်။ ၎င်း၏ output ကို အသင်းဖော်တစ်ဦး၏ output ကို review လုပ်သကဲ့သို့ review လုပ်ခဲ့သည်။ ၎င်းမှာ software ကို ကျွန်ုပ်တို့ ဖြန့်ချိသည့် နည်းလမ်းပဲ ဖြစ်လာခဲ့သည်။

AI အကူအညီဖြင့် development လုပ်ခြင်းသည် တိကျခိုင်မာမှုလိုအပ်ချက်ကို မလျှော့ချပေးဘဲ တိုးမြှင့်ပေးကြောင်း ထင်ရှားလာသည်။ Codex သည် စွမ်းရည်ရှိသလောက် ၎င်း၏ ရည်မှန်းချက်မှာ A မှ B သို့ ယခုပင် ရောက်အောင် လုပ်ပေးရန် ဖြစ်သည်။ ထို့ကြောင့် လူသားများ မပါဘဲ AI-assisted coding သည် အလုပ်မဖြစ်ပါ။ software engineer များသည် system များ၏ လက်တွေ့ကမ္ဘာ ကန့်သတ်ချက်များ၊ software ကို architecture ဆွဲရန် အကောင်းဆုံးနည်းလမ်းများနှင့် အနာဂတ် development နှင့် product plan များကို စိတ်ထဲထားကာ တည်ဆောက်ပုံကို နားလည်ပြီး အသုံးချနိုင်ကြသည်။ မနက်ဖြန်၏ software engineer ၏ superpower များမှာ system များကို နက်နက်ရှိုင်းရှိုင်း နားလည်ခြင်းနှင့် AI နှင့်အတူ ရေရှည်အချိန်ကာလများတစ်လျှောက် ပူးပေါင်းလုပ်ကိုင်နိုင်ခြင်း ဖြစ်လာမည်။

software engineering ၏ စိတ်ဝင်စားစရာအကောင်းဆုံး အစိတ်အပိုင်းများမှာ စွဲဆောင်မှုရှိသော product များကို တည်ဆောက်ခြင်း၊ scalable system များကို ဒီဇိုင်းဆွဲခြင်း၊ ရှုပ်ထွေးသော algorithm များ ရေးသားခြင်းနှင့် data၊ pattern နှင့် code တို့ဖြင့် စမ်းသပ်ခြင်းတို့ ဖြစ်သည်။ သို့သော် အတိတ်နှင့် ယနေ့ခေတ် software engineering ၏ အမှန်တရားများမှာ ပိုမို ရိုးရိုးရှင်းရှင်း ဖြစ်လေ့ရှိသည် - button များကို အလယ်တည့်တည့်ထားခြင်း၊ အဆုံးမှတ်များကို ချိတ်ဆက်ခြင်းနှင့် boilerplate ကို ရေးခြင်းတို့ ဖြစ်သည်။ ယခုအခါ Codex ကြောင့် software engineering ၏ အဓိပ္ပာယ်အရှိဆုံး အပိုင်းများနှင့် ကျွန်ုပ်တို့၏ အလုပ်အပေါ် ချစ်မြတ်နိုးရခြင်း၏ အကြောင်းရင်းများအပေါ် အာရုံစိုက်နိုင်ပြီ ဖြစ်သည်။

Codex ကို context ကြွယ်ဝသော environment တစ်ခုတွင် သင့်ရည်မှန်းချက်များနှင့် သင် တည်ဆောက်လိုသည့်ပုံစံကို နားလည်အောင် စနစ်တကျ ပြင်ဆင်ထားပြီးနောက် မည်သည့်အဖွဲ့မဆို ၎င်းတို့၏ စွမ်းဆောင်ရည်ကို များစွာ တိုးမြှင့်နိုင်သည်။ ကျွန်ုပ်တို့၏ launch retrospective သည် အားလုံးအတွက် ကိုက်ညီသော recipe မဟုတ်သကဲ့သို့ AI-assisted development ကို အပြည့်အဝ ဖြေရှင်းပြီးပြီဟုလည်း မဆိုလိုပါ။ သို့သော် Codex ကို သင့်အား စွမ်းဆောင်ရည်မြှင့်တင်ပေးနိုင်ရန် အကောင်းဆုံး နည်းလမ်းများကို ရှာဖွေရေးမှာ ကျွန်ုပ်တို့၏ အတွေ့အကြုံက သင့်အတွက် ပိုမိုလွယ်ကူစေမည်ဟု မျှော်လင့်ပါသည်။

Codex ကို သုတေသန preview အဖြစ် လွန်ခဲ့သော ၇ လက စတင်ဖြန့်ချိခဲ့စဉ် software engineering သည် ယခုနှင့် အလွန် ကွဲပြားနေခဲ့သည်။ Sora မှတစ်ဆင့် ကျွန်ုပ်တို့သည် engineering ၏ နောက်အခန်းကို စူးစမ်းလေ့လာခွင့် ရခဲ့သည်။ ကျွန်ုပ်တို့၏ မော်ဒယ်များနှင့် harness တို့ ဆက်လက်တိုးတက်ကောင်းမွန်လာသည်နှင့်အမျှ AI သည် တည်ဆောက်ရေးလုပ်ငန်း၏ မရှိမဖြစ် အစိတ်အပိုင်းတစ်ခုအဖြစ် ပိုမိုဖြစ်လာမည်။

သင့်ကိုယ်ပိုင် Codex အဖွဲ့နှင့်အတူ သင် ဘာကို ဖန်တီးမည်နည်း။