Harness engineering: agent-first လောကတွင် Codex ကို အသုံးချခြင်း

လွန်ခဲ့သော ငါးလအတွင်း ကျွန်ုပ်တို့အဖွဲ့သည် စမ်းသပ်မှုတစ်ခုကို လုပ်ဆောင်နေခဲ့သည်—လူက လက်ဖြင့်ရေးထားသော code 0 လိုင်း ဖြင့် software product တစ်ခု၏ internal beta ကို တည်ဆောက်ပြီး ထုတ်လွှင့်ခြင်းဖြစ်သည်။

ဤ product တွင် အတွင်းပိုင်းနေ့စဉ်အသုံးပြုသူများနှင့် ပြင်ပ alpha tester များရှိသည်။ ၎င်းကို ထုတ်လွှင့်သည်၊ deploy လုပ်သည်၊ ပျက်သည်၊ ပြီးတော့ ပြန်ပြင်သည်။ ကွာခြားချက်ကတော့ code တစ်ကြောင်းချင်းစီ—application logic၊ tests၊ CI configuration၊ documentation၊ observability နှင့် internal tooling—အားလုံးကို Codex က ရေးထားခြင်းဖြစ်သည်။ ကျွန်ုပ်တို့ခန့်မှန်းရာတွင် ၎င်းကို လက်ဖြင့် code ရေးမည်ဆိုလျှင် လိုအပ်မည့်အချိန်၏ 1/10 ခန့်အတွင်း တည်ဆောက်နိုင်ခဲ့သည်။

လူသားများက လမ်းညွှန်သည်။ အေးဂျင့်များက အကောင်အထည်ဖော်သည်။

ဤကန့်သတ်ချက်ကို ကျွန်ုပ်တို့က ရည်ရွယ်ချက်ရှိရှိ ရွေးချယ်ခဲ့သည်၊ အဘယ်ကြောင့်ဆိုသော် engineering velocity ကို အဆများစွာဖြင့် မြှင့်တင်ရန် လိုအပ်သည့်အရာကို တည်ဆောက်နိုင်ရန် ဖြစ်သည်။ နောက်ဆုံးတွင် code လိုင်းတစ်သန်းအထိ ဖြစ်လာမည့်အရာကို ထုတ်ရန် ကျွန်ုပ်တို့တွင် အပတ်အနည်းငယ်သာ ရှိခဲ့သည်။ ထိုသို့လုပ်နိုင်ရန် software engineering team ၏ အဓိကတာဝန်သည် code ရေးခြင်းမဟုတ်တော့ဘဲ environment များကို ဒီဇိုင်းဆွဲခြင်း၊ ရည်ရွယ်ချက်ကို တိတိကျကျ သတ်မှတ်ခြင်းနှင့် Codex အေးဂျင့်များ ယုံကြည်စိတ်ချရသော အလုပ်ကို လုပ်နိုင်စေမည့် feedback loop များကို တည်ဆောက်ခြင်း ဖြစ်လာသောအခါ ဘာတွေပြောင်းလဲသွားသည်ကို နားလည်ရန် လိုအပ်ခဲ့သည်။

ဤ post သည် အေးဂျင့်အဖွဲ့တစ်ဖွဲ့ဖြင့် အသစ်စက်စက် product တစ်ခုကို တည်ဆောက်ရာမှ ကျွန်ုပ်တို့ သင်ယူခဲ့သည့်အရာများအကြောင်းဖြစ်သည်—ဘာတွေ ချို့ယွင်းခဲ့သလဲ၊ ဘာတွေ တိုးပွားအကျိုးဖြစ်ခဲ့သလဲ၊ နှင့် တကယ်တမ်း ရှားပါးသော အရင်းအမြစ်တစ်ခုတည်းဖြစ်သော လူသားအချိန်နှင့် အာရုံစိုက်မှုကို မည်သို့ အများဆုံးအသုံးချမလဲ ဆိုသည်တို့ဖြစ်သည်။

ဗလာ repository တစ်ခုအတွက် ပထမဆုံး commit သည် 2025 ခုနှစ် သြဂုတ်လနှောင်းပိုင်းတွင် ရောက်ရှိခဲ့သည်။

ကနဦး scaffold—repository structure၊ CI configuration၊ formatting rules၊ package manager setup နှင့် application framework—ကို Codex CLI က GPT‑5 ကို အသုံးပြုပြီး ရှိပြီးသား template အနည်းငယ်၏ လမ်းညွှန်မှုဖြင့် ထုတ်လုပ်ခဲ့သည်။ repository အတွင်းတွင် အေးဂျင့်များ မည်သို့အလုပ်လုပ်ရမည်ကို ညွှန်ကြားသော အစောပိုင်း AGENTS.md ဖိုင်တောင် Codex ကပင် ရေးသားခဲ့သည်။

စနစ်ကို အခြေခံတည်နေရာပေးမည့် ကြိုတင်ရှိပြီးသား လူကရေးထားသော code မရှိခဲ့ပါ။ အစကတည်းက repository ကို အေးဂျင့်က ပုံဖော်ခဲ့သည်။

ငါးလအကြာတွင် repository တွင် application logic၊ infrastructure၊ tooling၊ documentation နှင့် internal developer utility များအနှံ့ code လိုင်းတစ်သန်းဝန်းကျင် ပါဝင်လာသည်။ ထိုကာလအတွင်း Codex ကို မောင်းနှင်သော engineer သုံးယောက်သာပါသည့် အသေးစားအဖွဲ့ဖြင့် pull request 1,500 ခန့်ကို ဖွင့်ပြီး merge လုပ်ခဲ့သည်။ ၎င်းသည် engineer တစ်ယောက်လျှင် တစ်ရက်ပျမ်းမျှ 3.5 PR များအထိ ဆောင်ကြဉ်းပေးမှု ပမာဏ ရှိသည်ဟု ဆိုလိုပြီး အံ့ဩစရာကောင်းသည်မှာ အဖွဲ့သည် ယခု engineer ခုနစ်ယောက်အထိ တိုးလာသည့်အချိန်တွင်ပင် ထို throughput သည် မြင့်တက် လာခဲ့သည်။ အရေးကြီးသည်မှာ ၎င်းသည် output ထုတ်ရန်အတွက်သာ output မဟုတ်ပါ—product ကို အတွင်းပိုင်းအသုံးပြုသူ ရာနှင့်ချီက အသုံးပြုခဲ့ပြီး နေ့စဉ်သုံး power user များပါ ပါဝင်သည်။

တည်ဆောက်မှုလုပ်ငန်းစဉ်တစ်လျှောက်လုံးတွင် လူသားများသည် code မည်သည့်တစ်စိတ်တစ်ပိုင်းကိုမျှ တိုက်ရိုက် မပါဝင်ရေးသားခဲ့ကြပါ။ ၎င်းသည် အဖွဲ့အတွက် အဓိကအတွေးအခေါ်တစ်ခု ဖြစ်လာခဲ့သည်—လက်ဖြင့်ရေးထားသော code မရှိစေရ။

လူသားက ကိုယ်တိုင် code ရေးခြင်း မရှိသလောက်ဖြစ်နေခြင်းသည် system များ၊ scaffold များနှင့် leverage အပေါ် အာရုံစိုက်သည့် engineering အလုပ်အမျိုးအစားသစ်တစ်ခုကို ဖြစ်ပေါ်စေခဲ့သည်။

အစောပိုင်း တိုးတက်မှုသည် မျှော်လင့်ထားသလောက် မြန်ဆန်မနေခဲ့ပါ။ Codex မစွမ်းနိုင်လို့မဟုတ်ဘဲ environment ကို လုံလောက်စွာ မသတ်မှတ်ထားသောကြောင့် ဖြစ်သည်။ အေးဂျင့်တွင် မြင့်မားသော ရည်မှန်းချက်များဆီသို့ တိုးတက်နိုင်ရန် လိုအပ်သော tools၊ abstraction များနှင့် internal structure များ မလုံလောက်ခဲ့သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့ engineering အဖွဲ့၏ အဓိကတာဝန်မှာ အေးဂျင့်များ အသုံးဝင်သော အလုပ်ကို လုပ်နိုင်စေရန် ဖွင့်ပေးခြင်း ဖြစ်လာခဲ့သည်။

လက်တွေ့တွင် ၎င်းမှာ depth-first ပုံစံဖြင့် အလုပ်လုပ်ခြင်းကို ဆိုလိုသည်—ပိုမိုကြီးမားသော ရည်မှန်းချက်များကို ပိုသေးငယ်သော building block များအဖြစ် (design, code, review, test စသည်) ခွဲထုတ်ခြင်း၊ အေးဂျင့်အား ထို block များကို တည်ဆောက်စေခြင်းနှင့် ပိုမိုရှုပ်ထွေးသော task များကို ဖွင့်ပေးရန် ၎င်းတို့ကို အသုံးပြုခြင်း ဖြစ်သည်။ တစ်ခုခု မအောင်မြင်သည့်အခါ ဖြေရှင်းချက်မှာ “ပိုကြိုးစားပါ” မဟုတ်သလောက်ပဲ ဖြစ်သည်။ တိုးတက်နိုင်မည့် တစ်ခုတည်းသောနည်းလမ်းမှာ Codex က အလုပ်ကို လုပ်ပေးရခြင်းဖြစ်သောကြောင့် လူသား engineer များသည် task ထဲသို့ အမြဲဝင်ပြီး “ဘယ် capability က ပျောက်နေသလဲ၊ အဲဒါကို အေးဂျင့်အတွက် ဖတ်လို့နားလည်ရလွယ်ကူပြီး အတည်ပြုထိန်းချုပ်နိုင်အောင် ဘယ်လိုလုပ်မလဲ” ဟု မေးခဲ့ကြသည်။

လူသားများသည် စနစ်နှင့် အပြန်အလှန်ဆက်ဆံရာတွင် အများအားဖြင့် တုံ့ပြန်ညွှန်ကြားချက်များမှတစ်ဆင့်သာ လုပ်ဆောင်ကြသည်—engineer တစ်ယောက်က task ကို ဖော်ပြသည်၊ အေးဂျင့်ကို run သည်၊ ပြီးလျှင် ၎င်းအား pull request ဖွင့်ခွင့်ပေးသည်။ PR တစ်ခုကို အပြီးသတ်ရန် ကျွန်ုပ်တို့သည် Codex အား ၎င်း၏ ကိုယ်ပိုင်ပြောင်းလဲမှုများကို local တွင် review လုပ်ရန်၊ local နှင့် cloud နှစ်နေရာလုံးတွင် ထပ်ဆင့် သီးသန့်အေးဂျင့် review များ တောင်းခံရန်၊ လူသား သို့မဟုတ် အေးဂျင့်မှပေးသော feedback များအား တုံ့ပြန်ရန်၊ အေးဂျင့် reviewer အားလုံး ကျေနပ်သည်အထိ loop အဖြစ် iterate လုပ်ရန် ညွှန်ကြားကြသည် (အကျဉ်းအားဖြင့် ၎င်းသည် Ralph Wiggum Loop⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တစ်ခုဖြစ်သည်)။ Codex သည် လူသားများက CLI ထဲသို့ copy-paste လုပ်ရန်မလိုဘဲ context စုဆောင်းရန် ကျွန်ုပ်တို့၏ စံ development tool များ (gh, local script များနှင့် repository-embedded skill များ) ကို တိုက်ရိုက်အသုံးပြုသည်။

လူသားများသည် pull request များကို review လုပ်နိုင်သော်လည်း မဖြစ်မနေ လုပ်ရမည်မဟုတ်ပါ။ အချိန်ကြာလာသည်နှင့်အမျှ review အားထုတ်မှုအများစုကို အေးဂျင့်မှ အေးဂျင့်သို့ ကိုင်တွယ်စေရန် ကျွန်ုပ်တို့ ပြောင်းရွှေ့လာခဲ့သည်။

Code ထုတ်လုပ်နိုင်မှု မြင့်လာသည်နှင့်အမျှ ကျွန်ုပ်တို့၏ bottleneck သည် လူသား QA စွမ်းရည် ဖြစ်လာခဲ့သည်။ တိတိကျကျ ကန့်သတ်ချက်သည် လူသားအချိန်နှင့် အာရုံစိုက်မှုဖြစ်နေသဖြင့် application UI၊ log များနှင့် app metric များကို Codex အတွက် တိုက်ရိုက်ဖတ်ရှုနားလည်နိုင်အောင် ပြုလုပ်ခြင်းဖြင့် အေးဂျင့်ထဲသို့ စွမ်းရည်များ ထပ်ထည့်ရန် ကျွန်ုပ်တို့ ကြိုးစားခဲ့သည်။

ဥပမာအားဖြင့် app ကို git worktree တစ်ခုချင်းစီအလိုက် boot လုပ်နိုင်အောင် ပြုလုပ်ခဲ့ပြီး၊ ထိုကြောင့် Codex သည် ပြောင်းလဲမှုတစ်ခုချင်းစီအတွက် instance တစ်ခုချင်းစီကို launch လုပ်ပြီး မောင်းနှင်နိုင်ခဲ့သည်။ ထို့အပြင် Chrome DevTools Protocol ကို အေးဂျင့် runtime ထဲသို့ ချိတ်ဆက်ကာ DOM snapshot၊ screenshot နှင့် navigation များနှင့် အလုပ်လုပ်ရန် skill များကို ဖန်တီးခဲ့သည်။ ၎င်းကြောင့် Codex သည် bug များကို ပြန်လည်ဖြစ်ပေါ်စေခြင်း၊ fix များကို အတည်ပြုခြင်းနှင့် UI behavior ကို တိုက်ရိုက် သုံးသပ်နိုင်ခြင်းတို့ လုပ်ဆောင်နိုင်ခဲ့သည်။

Observability tooling အတွက်လည်း အလားတူလုပ်ဆောင်ခဲ့သည်။ Log များ၊ metric များနှင့် trace များကို worktree တစ်ခုချင်းစီအတွက် ယာယီဖြစ်သော local observability stack မှတစ်ဆင့် Codex သို့ ပြသပေးထားသည်။ Codex သည် app ၏ အပြည့်အဝ သီးခြားထားသော version တစ်ခုအပေါ် အလုပ်လုပ်ပြီး—၎င်း၏ log များနှင့် metric များပါ အပါအဝင်—task ပြီးဆုံးသည့်အခါ ၎င်းတို့ကို ဖယ်ရှားပစ်သည်။ အေးဂျင့်များသည် LogQL ဖြင့် log များကို၊ PromQL ဖြင့် metric များကို query လုပ်နိုင်သည်။ ဤ context ရရှိလာသည့်အခါ “service startup ကို 800ms အောက်တွင် ပြီးစီးစေပါ” သို့မဟုတ် “ဤ အရေးကြီးသော user journey လေးခုအတွင်း span တစ်ခုမျှ two seconds ထက် မကျော်ပါစေနှင့်” ကဲ့သို့သော တုံ့ပြန်ညွှန်ကြားချက်များသည် လက်တွေ့ကျလာသည်။

Codex run တစ်ကြိမ်တည်းက task တစ်ခုတည်းအပေါ် ခြောက်နာရီကျော်အထိ အလုပ်လုပ်နေသည်ကို ပုံမှန်မြင်ရသည် (မကြာခဏဆိုသလို လူသားများ အိပ်နေချိန်တွင် ဖြစ်သည်)။

Context management သည် အေးဂျင့်များကို ကြီးမားပြီး ရှုပ်ထွေးသော task များတွင် ထိရောက်စေရာ၌ အကြီးမားဆုံး စိန်ခေါ်မှုတစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့ သင်ယူခဲ့သော အစောပိုင်းသင်ခန်းစာတစ်ခုမှာ ရိုးရှင်းပါသည်—Codex ကို စာမျက်နှာ 1,000 ပါညွှန်ကြားချက်လက်စွဲတစ်အုပ် မပေးဘဲ မြေပုံတစ်ခုပေးပါ။

“ကြီးမားသော AGENTS.md⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ဖိုင်တစ်ခုတည်း” ဆိုသည့် နည်းလမ်းကို စမ်းကြည့်ခဲ့သည်။ မျှော်လင့်ထားသည့် ပုံစံအတိုင်းပင် မအောင်မြင်ခဲ့သည်:

• Context သည် ရှားပါးသော အရင်းအမြစ်တစ်ခုဖြစ်သည်။ ညွှန်ကြားချက်ဖိုင်ကြီးတစ်ခုသည် task၊ code နှင့် သက်ဆိုင်သော docs များကို ဖယ်ထုတ်သလို ဖြစ်စေသဖြင့် အေးဂျင့်သည် အရေးကြီးသော ကန့်သတ်ချက်များကို လွတ်ကျသွားနိုင်သည် သို့မဟုတ် မှားယွင်းသောအရာများအတွက် စတင် optimize လုပ်နိုင်သည်။
• လမ်းညွှန်ချက်များ များလွန်းသွားပါက လမ်းညွှန်မဟုတ်တော့ခြင်း ဖြစ်လာသည်။ အရာအားလုံး “အရေးကြီး” ဖြစ်လာသည့်အခါ ဘာမျှ မအရေးကြီးတော့ပါ။ အေးဂျင့်များသည် ရည်ရွယ်ချက်ရှိရှိ လမ်းကြောင်းရှာခြင်းအစား local pattern-matching ကိုသာ လုပ်တတ်လာသည်။
• ၎င်းသည် ချက်ချင်း ဟောင်းနွမ်းသွားသည်။ လက်စွဲကြီးတစ်အုပ်သည် ခေတ်မမီတော့သော စည်းမျဉ်းများ၏ သင်္ချိုင်းတစ်ခုအဖြစ် ပြောင်းသွားသည်။ အေးဂျင့်များသည် ဘာက ယခုထိ မှန်နေသေးသည်ကို မခွဲနိုင်၊ လူသားများက ထိန်းသိမ်းမှု မလုပ်တော့ဘဲ ဖိုင်သည် တဖြည်းဖြည်း ဆွဲဆောင်မှုရှိသော အန္တရာယ်အဖြစ် ပြောင်းသွားသည်။
• စစ်ဆေးအတည်ပြုရန် ခက်သည်။ blob တစ်ခုတည်းဖြင့် mechanical check များ (coverage, freshness, ownership, cross-links) ကို လွယ်ကူစွာ မလုပ်နိုင်သောကြောင့် drift သည် မလွဲမသွေ ဖြစ်လာသည်။

ထို့ကြောင့် AGENTS.md ကို encyclopedia အဖြစ် မယူဆဘဲ မာတိကာ အဖြစ်သာ သတ်မှတ်သည်။

Repository ၏ knowledge base သည် system of record အဖြစ် ဆက်ဆံထားသော ဖွဲ့စည်းပုံရှိ docs/ directory အတွင်းတွင် နေထိုင်သည်။ တိုတောင်းသော AGENTS.md (လိုင်း 100 ခန့်) ကို context ထဲသို့ ထည့်သွင်းထားပြီး အဓိကအားဖြင့် မြေပုံတစ်ခုအနေဖြင့် အသုံးပြုကာ အခြားနေရာရှိ ပိုမိုနက်ရှိုင်းသော source of truth များသို့ pointer များ ပေးထားသည်။

Design documentation ကို verification status နှင့် agent-first operating principle များကို သတ်မှတ်ပေးသော အခြေခံယုံကြည်ချက်များအစုနှင့်အတူ catalog လုပ်၍ index ပြုလုပ်ထားသည်။ Architecture documentation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) သည် domain များနှင့် package layering များ၏ top-level map ကို ပေးသည်။ Quality document တစ်ခုသည် product domain နှင့် architectural layer တစ်ခုချင်းစီကို အဆင့်သတ်မှတ်ပြီး ကွာဟချက်များကို အချိန်နှင့်အမျှ လိုက်လံမှတ်တမ်းတင်သည်။

Plan များကို first-class artifact များအဖြစ် ဆက်ဆံသည်။ သေးငယ်သော ပြောင်းလဲမှုများအတွက် ယာယီပေါ့ပါးသော plan များကို အသုံးပြုပြီး ရှုပ်ထွေးသော အလုပ်များကိုတော့ progress နှင့် decision log များပါဝင်သော execution plan များ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) အဖြစ် သိမ်းဆည်းကာ repository ထဲသို့ check in လုပ်ထားသည်။ လက်ရှိလုပ်ဆောင်နေသော plan များ၊ ပြီးစီးသော plan များနှင့် သိရှိထားသော technical debt များအားလုံးကို versioning လုပ်ကာ တစ်နေရာတည်းတွင်ထားရှိသဖြင့် အေးဂျင့်များသည် ပြင်ပ context ကို အားမကိုးဘဲ လုပ်ဆောင်နိုင်သည်။

၎င်းကြောင့် progressive disclosure ကို ရရှိစေသည်—အေးဂျင့်များသည် အစပိုင်းတွင် သေးငယ်ပြီး တည်ငြိမ်သော entry point တစ်ခုဖြင့် စတင်ပြီး နောက်တစ်ဆင့် ဘယ်မှာကြည့်ရမည်ကို သင်ကြားပေးခံရသည်၊ မစတင်မီကတည်းက အချက်အလက်ပိမိနေခြင်း မဟုတ်ပါ။

ဤအရာကို mechanical နည်းလမ်းဖြင့် ကျွန်ုပ်တို့ အတည်ပြုထိန်းချုပ်သည်။ Dedicated linter များနှင့် CI job များသည် knowledge base သည် နောက်ဆုံးအခြေအနေဖြစ်နေကြောင်း၊ cross-linked ဖြစ်ကြောင်းနှင့် ဖွဲ့စည်းပုံမှန်ကြောင်းကို validate လုပ်ပေးသည်။ အကြိမ်ကြိမ်ပြန်လုပ်သော “doc-gardening” အေးဂျင့်တစ်ခုက တကယ့် code behavior ကို မထင်ဟပ်တော့သည့် ဟောင်းနွမ်း သို့မဟုတ် အသုံးမဝင်တော့သော documentation များကို scan လုပ်ပြီး ပြင်ဆင်သည့် pull request များကို ဖွင့်ပေးသည်။

Codebase ပြောင်းလဲတိုးတက်လာသည်နှင့်အမျှ design decision များအတွက် Codex ၏ framework သည်လည်း ပြောင်းလဲတိုးတက်ရန် လိုအပ်ခဲ့သည်။

Repository တစ်ခုလုံးကို အေးဂျင့်ကပဲ ထုတ်လုပ်ထားသောကြောင့် ၎င်းကို အဓိကအားဖြင့် Codex ၏ legibility အတွက် optimize လုပ်ထားသည်။ အသင်းများက engineering အလုပ်သမားအသစ်များအတွက် code ၏ navigability ကို တိုးတက်စေရန် ကြိုးစားသကဲ့သို့၊ ကျွန်ုပ်တို့၏ လူသား engineer များ၏ ပန်းတိုင်မှာ အေးဂျင့်တစ်ခုက business domain အပြည့်အစုံကို repository ကိုယ်တိုင်မှ တိုက်ရိုက် သုံးသပ်နားလည်နိုင်စေခြင်း ဖြစ်သည်။

အေးဂျင့်၏ အမြင်အရ ၎င်းက run နေချိန် context အတွင်း မရယူနိုင်သော အရာတိုင်းသည် အမှန်အားဖြင့် မရှိသကဲ့သို့ပင် ဖြစ်သည်။ Google Docs၊ chat thread များ သို့မဟုတ် လူများ၏ ခေါင်းထဲတွင် နေထိုင်သော အသိပညာများကို စနစ်က မရယူနိုင်ပါ။ Repository-local ဖြစ်ပြီး versioned ဖြစ်သော artifact များ (ဥပမာ code၊ markdown၊ schema များ၊ executable plan များ) သာ ၎င်း မြင်နိုင်သည့်အရာများဖြစ်သည်။

အချိန်ကြာလာသည်နှင့်အမျှ context ပိုမိုများပြားစွာကို repo ထဲသို့ ထည့်သွင်းရမည်ဟု ကျွန်ုပ်တို့ သင်ယူခဲ့သည်။ အဖွဲ့ကို architectural pattern တစ်ခုပေါ်တွင် တညီတညွတ်တည်းဖြစ်စေခဲ့သော Slack ဆွေးနွေးမှုကော? ၎င်းကို အေးဂျင့်က ရှာဖွေမတွေ့နိုင်ပါက သုံးလကြာပြီးမှ အဖွဲ့ထဲ ဝင်လာသော ဝန်ထမ်းအသစ်တစ်ယောက်အတွက် မသိရသလိုပင် ၎င်းသည် ဖတ်လို့နားမလည်နိုင်သော အရာ ဖြစ်သွားသည်။

Codex ကို context ပိုပေးခြင်းဆိုသည်မှာ အေးဂျင့်က ၎င်းအပေါ် သုံးသပ်နိုင်စေရန် မှန်ကန်သော အချက်အလက်ကို စုစည်းဖော်ပြပေးခြင်းဖြစ်ပြီး ad-hoc ညွှန်ကြားချက်များဖြင့် ၎င်းကို လွန်ကဲစွာ မဖိစီးစေခြင်း ဖြစ်သည်။ Product principle များ၊ engineering norm များနှင့် team culture (emoji preference များပါ အပါအဝင်) ကို teammate အသစ်တစ်ယောက်အား onboarding လုပ်ပေးသကဲ့သို့ပင်၊ အေးဂျင့်အား ဤအချက်အလက်များ ပေးခြင်းက ပိုမို ကိုက်ညီသော output ကို ရစေသည်။

ဤဖော်ပြချက်က tradeoff များစွာကို ရှင်းလင်းစေခဲ့သည်။ Repo အတွင်း အပြည့်အဝ internalize လုပ်နိုင်ပြီး သုံးသပ်နိုင်သော dependency နှင့် abstraction များကို ကျွန်ုပ်တို့ ဦးစားပေးခဲ့သည်။ မကြာခဏ “boring” ဟု ဖော်ပြလေ့ရှိသော technology များသည် composability၊ api stability နှင့် training set ထဲတွင် ကိုယ်စားပြုမှုရှိခြင်းကြောင့် အေးဂျင့်များအတွက် model လုပ်ရ ပိုလွယ်တတ်သည်။ အချို့ကိစ္စများတွင် public library များ၏ opaque upstream behavior ကို လှည့်ပတ်ဖြေရှင်းရခြင်းထက် functionality အချို့ကို အေးဂျင့်ကိုယ်တိုင် ပြန်လည်အကောင်အထည်ဖော်စေခြင်းက စရိတ်သက်သာခဲ့သည်။ ဥပမာအားဖြင့် generic p-limit ပုံစံ package တစ်ခုကို ထည့်သွင်းယူမည့်အစား concurrency ပါသော map helper ကို ကျွန်ုပ်တို့ကိုယ်တိုင် အကောင်အထည်ဖော်ခဲ့သည်—၎င်းသည် ကျွန်ုပ်တို့၏ OpenTelemetry instrumentation နှင့် တင်းကျပ်စွာ ပေါင်းစည်းထားပြီး test coverage 100% ရှိကာ runtime မျှော်လင့်သည့်အတိုင်း တိတိကျကျ ပြုမူသည်။

အေးဂျင့်က တိုက်ရိုက် စစ်ဆေး၊ validate နှင့် modify လုပ်နိုင်သော ပုံစံထဲသို့ system ၏ ပိုမိုများပြားသော အစိတ်အပိုင်းများကို ဆွဲသွင်းခြင်းက leverage ကို တိုးစေသည်—Codex အတွက်တင်မကဘဲ codebase ပေါ်တွင် အလုပ်လုပ်နေသော အခြား အေးဂျင့်များ (ဥပမာ Aardvark) အတွက်ပါ ဖြစ်သည်။

Documentation တစ်ခုတည်းဖြင့် အပြည့်အဝ အေးဂျင့်ထုတ်လုပ်ထားသော codebase ကို coherent ဖြစ်စေ၍ မရပါ။ Implementation ကို အသေးစိတ်မထိန်းချုပ်ဘဲ invariant များကို အတည်ပြုထိန်းချုပ်ခြင်းဖြင့် အေးဂျင့်များကို အခြေခံဖွဲ့စည်းပုံကို မပျက်စီးစေဘဲ လျင်မြန်စွာ ထုတ်လွှင့်နိုင်စေသည်။ ဥပမာ Codex အား boundary တွင် data shape များကို parse လုပ်စေ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ရန် တောင်းဆိုသော်လည်း ထိုအရာကို ဘယ်လိုလုပ်ရမည်ဆိုသည်ကိုတော့ အတိအကျ မသတ်မှတ်ထားပါ (မော်ဒယ်သည် Zod ကို ကြိုက်ပုံရသော်လည်း ထို library ကို ကျွန်ုပ်တို့ မသတ်မှတ်ခဲ့ပါ)။

အေးဂျင့်များသည် တင်းကျပ်သော boundary များနှင့် ခန့်မှန်းနိုင်သော structure⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ရှိသော environment များတွင် အထိရောက်ဆုံး ဖြစ်ကြသောကြောင့် application ကို တိကျသည့် architectural model တစ်ခုအပေါ် အခြေခံ၍ တည်ဆောက်ခဲ့သည်။ Business domain တစ်ခုချင်းစီကို fixed layer အစုတစ်ခုအဖြစ် ခွဲထားပြီး dependency direction များကို တင်းကျပ်စွာ validate လုပ်ထားကာ ခွင့်ပြုထားသော edge အစုကိုသာ ကန့်သတ်ထားသည်။ ဤကန့်သတ်ချက်များကို custom linter များ (Codex ထုတ်လုပ်ထားသည့်အရာများ ဖြစ်သည်မှာ သေချာပင်!) နှင့် structural test များဖြင့် mechanical နည်းလမ်းဖြင့် အတည်ပြုထားသည်။

အောက်ဖော်ပြပါ ပုံကြမ်းသည် စည်းမျဉ်းကို ပြသသည်- business domain တစ်ခုချင်းစီအတွင်း (ဥပမာ App Settings) code သည် fixed layer အစုတစ်ခု (Types → Config → Repo → Service → Runtime → UI) ကိုလိုက်၍ “ရှေ့ဘက်” သို့သာ မှီခိုနိုင်သည်။ Cross-cutting concern များ (auth, connector, telemetry, feature flag) သည် ရှင်းလင်းစွာ သတ်မှတ်ထားသော interface တစ်ခုတည်းဖြစ်သော Providers မှတစ်ဆင့်သာ ဝင်ရောက်နိုင်သည်။ အခြားအရာအားလုံးကို ခွင့်မပြုဘဲ mechanical နည်းလမ်းဖြင့် အတည်ပြုထားသည်။

ဤသည်မှာ engineer ရာနှင့်ချီ ရှိလာမှသာ ပုံမှန်အားဖြင့် သင်စတင်စဉ်းစားလေ့ရှိသော architecture အမျိုးအစားဖြစ်သည်။ Coding အေးဂျင့်များနှင့်ဆိုလျှင် ၎င်းသည် အစောပိုင်းလိုအပ်ချက်တစ်ခုဖြစ်လာသည်—ဤကန့်သတ်ချက်များကြောင့်သာ ပျက်စီးယိုယွင်းမှု သို့မဟုတ် architectural drift မဖြစ်ဘဲ မြန်နှုန်းကို ရရှိစေနိုင်သည်။

လက်တွေ့တွင် ဤစည်းမျဉ်းများကို custom linter များ၊ structural test များနှင့် “taste invariant” အစုငယ်တစ်ခုဖြင့် အတည်ပြုထားသည်။ ဥပမာ structured logging၊ schema နှင့် type များအတွက် naming convention၊ file size limit များနှင့် platform-specific reliability requirement များကို custom lint များဖြင့် static အနေဖြင့် အတည်ပြုထားသည်။ Lint များသည် custom ဖြစ်သောကြောင့် error message များကို အေးဂျင့် context ထဲသို့ remediation instruction များ ထည့်သွင်းပေးနိုင်ရန် အထူးရေးသားထားသည်။

လူသားဦးစား workflow တွင် ဤစည်းမျဉ်းများသည် အလွန်အသေးစိတ်လိုက်လံစစ်ဆေးနေသလို သို့မဟုတ် ကန့်သတ်နေသလို ခံစားရနိုင်သည်။ အေးဂျင့်များနှင့်ဆိုလျှင် ၎င်းတို့သည် multiplier များ ဖြစ်လာသည်—တစ်ခါ encode လုပ်လိုက်သည်နှင့် နေရာတိုင်းတွင် တစ်ပြိုင်နက် သက်ရောက်သည်။

တစ်ချိန်တည်းတွင် ဘယ်နေရာတွင် ကန့်သတ်ချက် အရေးကြီးသလဲ၊ ဘယ်နေရာတွင် မအရေးကြီးသလဲကို ကျွန်ုပ်တို့ ရှင်းလင်းစွာ သတ်မှတ်ထားသည်။ ဤသည်မှာ engineering platform organization အကြီးတစ်ခုကို ဦးဆောင်ခြင်းနှင့် ဆင်တူသည်—boundary များကို ဗဟိုမှ အတည်ပြုထိန်းချုပ်ပြီး local autonomy ကို ခွင့်ပြုပါ။ Boundary၊ correctness နှင့် reproducibility တို့ကို အလွန်ဂရုစိုက်သည်။ ထို boundary များအတွင်းတွင်တော့ team များ—သို့မဟုတ် အေးဂျင့်များ—အား solution ကို မည်သို့ဖော်ပြမည်ဆိုရာတွင် လွတ်လပ်ခွင့် အတော်အတန် ပေးထားသည်။

ရလဒ်အဖြစ် ထွက်လာသော code သည် လူသား stylistic preference များနှင့် အမြဲမကိုက်ညီနိုင်ပါ၊ ၎င်းမှာ အဆင်ပြေသည်။ Output သည် မှန်ကန်ပြီး၊ ထိန်းသိမ်းနိုင်ကာ၊ အနာဂတ် အေးဂျင့် run များအတွက် ဖတ်လို့နားလည်ရလွယ်ကူနေသရွေ့ ၎င်းသည် လိုအပ်သည့်စံနှုန်းကို ပြည့်မီသည်။

လူသား taste ကို စနစ်ထဲသို့ ဆက်တိုက် ပြန်ထည့်ပေးနေသည်။ Review comment များ၊ refactoring pull request များနှင့် user-facing bug များကို documentation update များအဖြစ် မှတ်တမ်းတင်ခြင်း သို့မဟုတ် tooling ထဲသို့ တိုက်ရိုက် encode လုပ်ခြင်းများ လုပ်ဆောင်သည်။ Documentation မလုံလောက်သည့်အခါ စည်းမျဉ်းကို code အဖြစ် မြှင့်တင်ထည့်သွင်းသည်

Codex ၏ throughput မြင့်တက်လာသည်နှင့်အမျှ သာမန် engineering norm များစွာသည် အကျိုးမရှိတော့ဘဲ ဆန့်ကျင်ဘက်ဖြစ်လာခဲ့သည်။

Repository ကို blocking merge gate အနည်းဆုံးဖြင့် လည်ပတ်စေသည်။ Pull request များသည် အသက်တိုသည်။ Test flake များကို တိုးတက်မှုကို မအဆုံးမဲ့တားဆီးဘဲ follow-up run များဖြင့် မကြာခဏ ဖြေရှင်းတတ်သည်။ အေးဂျင့် throughput သည် လူသားအာရုံစိုက်မှုထက် အလွန်ကျော်လွန်နေသော စနစ်တစ်ခုတွင် ပြင်ဆင်ခြင်းများသည် စျေးသက်သာပြီး စောင့်ဆိုင်းခြင်းက စျေးကြီးသည်။

Throughput နိမ့်သော environment တစ်ခုတွင် ဤနည်းလမ်းသည် တာဝန်မဲ့သလို ဖြစ်မည်။ ဤနေရာတွင်တော့ မကြာခဏ မှန်ကန်သော tradeoff ဖြစ်နေသည်။

Codebase ကို Codex အေးဂျင့်များက ထုတ်လုပ်သည်ဟု ကျွန်ုပ်တို့ ပြောသောအခါ codebase အတွင်းရှိ အရာအားလုံးကို ဆိုလိုသည်။

အေးဂျင့်များသည် အောက်ပါတို့ကို ထုတ်လုပ်သည်:

• Product code နှင့် test များ
• CI configuration နှင့် release tooling
• Internal developer tool များ
• Documentation နှင့် design history
• Evaluation harness များ
• Review comment များနှင့် response များ
• Repository ကိုယ်တိုင်ကို စီမံခန့်ခွဲသော script များ
• Production dashboard definition file များ

လူသားများသည် loop အတွင်းတွင် အမြဲရှိနေဆဲဖြစ်သော်လည်း ယခင်ကထက် abstraction အဆင့်မတူသော အလွှာတစ်ခုတွင် အလုပ်လုပ်နေကြသည်။ ကျွန်ုပ်တို့သည် အလုပ်၏ ဦးစားပေးကို သတ်မှတ်သည်၊ user feedback ကို acceptance criteria အဖြစ် ဘာသာပြန်သည်၊ နှင့် outcome များကို validate လုပ်သည်။ အေးဂျင့် အခက်အခဲကြုံလာသည့်အခါ ၎င်းကို signal တစ်ခုအဖြစ် ဆက်ဆံပြီး—ဘာပျောက်နေသလဲ၊ tool လား၊ guardrail လား၊ documentation လား—ကို ဖော်ထုတ်ကာ repository ထဲသို့ ပြန်ထည့်ပေးသည်၊ fix ကို အမြဲ Codex ကိုယ်တိုင် ရေးစေခြင်းဖြင့်သာ လုပ်ဆောင်သည်။

အေးဂျင့်များသည် ကျွန်ုပ်တို့၏ စံ development tool များကို တိုက်ရိုက် အသုံးပြုသည်။ ၎င်းတို့သည် review feedback ကို ဆွဲယူသည်၊ inline တုံ့ပြန်သည်၊ update များကို push လုပ်သည်၊ မကြာခဏဆိုသလို ၎င်းတို့၏ ကိုယ်ပိုင် pull request များကို squash လုပ်ပြီး merge လုပ်တတ်ကြသည်။

Testing၊ validation၊ review၊ feedback handling နှင့် recovery တို့အပါအဝင် development loop ၏ ပိုမိုများပြားသော အစိတ်အပိုင်းများကို စနစ်ထဲသို့ တိုက်ရိုက် encode လုပ်လာသည်နှင့်အမျှ repository သည် မကြာသေးမီက အဓိပ္ပာယ်ရှိသော အဆင့်တစ်ခုကို ကျော်ဖြတ်ခဲ့ပြီး ယခု Codex က feature အသစ်တစ်ခုကို အဆုံးမှ အဆုံးထိ မောင်းနှင်နိုင်လာသည်။

တုံ့ပြန်ညွှန်ကြားချက်တစ်ခုတည်း ပေးလိုက်ပါက ယခု အေးဂျင့်သည် အောက်ပါတို့ကို လုပ်နိုင်သည်:

• Codebase ၏ လက်ရှိအခြေအနေကို validate လုပ်ခြင်း
• Reported bug တစ်ခုကို ပြန်လည်ဖြစ်ပေါ်စေခြင်း
• ချို့ယွင်းမှုကို ပြသသည့် video တစ်ခုကို မှတ်တမ်းတင်ခြင်း
• Fix တစ်ခုကို အကောင်အထည်ဖော်ခြင်း
• Application ကို မောင်းနှင်ခြင်းဖြင့် fix ကို validate လုပ်ခြင်း
• ဖြေရှင်းပြီးကြောင်း ပြသသည့် ဒုတိယ video တစ်ခုကို မှတ်တမ်းတင်ခြင်း
• Pull request တစ်ခု ဖွင့်ခြင်း
• အေးဂျင့်နှင့် လူသား feedback ကို တုံ့ပြန်ခြင်း
• Build failure များကို detect လုပ်ပြီး remediation လုပ်ခြင်း
• Judgment လိုအပ်သည့်အခါမှသာ လူသားထံ escalate လုပ်ခြင်း
• ပြောင်းလဲမှုကို merge လုပ်ခြင်း

ဤ behavior သည် ဤ repository ၏ အထူးသတ်မှတ်ထားသော structure နှင့် tooling အပေါ် အလွန်အမင်း မူတည်နေပြီး အလားတူ ရင်းနှီးမြှုပ်နှံမှု မရှိဘဲ ယေဘုယျ သုံးနိုင်မည်ဟု မယူဆသင့်ပါ—အနည်းဆုံးတော့ ယခုအချိန်တွင် မဟုတ်သေးပါ။

အပြည့်အဝ အေးဂျင့် autonomy သည် အသစ်သော ပြဿနာများကိုလည်း မိတ်ဆက်ပေးသည်။ Codex သည် repository ထဲတွင် ရှိပြီးသား pattern များကို ပြန်လည်ထုတ်လုပ်တတ်သည်—မညီမညာ သို့မဟုတ် အကောင်းဆုံးမဟုတ်သည့် pattern များပါ အပါအဝင်ဖြစ်သည်။ အချိန်ကြာလာသည်နှင့်အမျှ ၎င်းသည် မလွဲမသွေ drift ကို ဖြစ်စေသည်။

အစပိုင်းတွင် လူသားများက ၎င်းကို လက်ဖြင့် ကိုင်တွယ်ခဲ့သည်။ ကျွန်ုပ်တို့အဖွဲ့သည် သောကြာနေ့တိုင်း (တစ်ပတ်၏ 20%) ကို “AI slop” ရှင်းလင်းရန် အသုံးပြုခဲ့ရသည်။ မျှော်လင့်ထားသလိုပင် ၎င်းသည် scale မလုပ်နိုင်ခဲ့ပါ။

ထို့အစား “golden principle” ဟု ကျွန်ုပ်တို့ ခေါ်သော အရာများကို repository ထဲသို့ တိုက်ရိုက် encode လုပ်ပြီး ထပ်တလဲလဲ cleanup process တစ်ခုကို တည်ဆောက်ခဲ့သည်။ ဤ principle များသည် အနာဂတ် အေးဂျင့် run များအတွက် codebase ကို ဖတ်လို့နားလည်ရလွယ်ကူပြီး တသမတ်တည်းရှိစေသော သဘောထားပါရှိသည့် mechanical rule များဖြစ်သည်။ ဥပမာ- (1) invariant များကို ဗဟိုပြုထားနိုင်ရန် hand-rolled helper များထက် shared utility package များကို ပိုနှစ်သက်သည်၊ နှင့် (2) data ကို “YOLO-style” မစမ်းသပ်ပါ—boundary များကို validate လုပ်သည် သို့မဟုတ် typed SDK များကို အားကိုးသည်၊ ထို့ကြောင့် အေးဂျင့်သည် မှန်းဆထားသော shape များအပေါ် မတော်တဆ အခြေခံမတည်ဆောက်နိုင်တော့ပါ။ ပုံမှန် cadence အတိုင်း deviation များကို scan လုပ်ရန်၊ quality grade များကို update လုပ်ရန်နှင့် တိကျသော refactoring pull request များကို ဖွင့်ရန် background Codex task အစုတစ်ခု ရှိသည်။ ထိုအများစုကို တစ်မိနစ်အောက်တွင် review လုပ်နိုင်ပြီး automerge လုပ်နိုင်သည်။

ဤသည် garbage collection ကဲ့သို့ အလုပ်လုပ်သည်။ Technical debt သည် အတိုးနှုန်းမြင့်သော ချေးငွေတစ်ခုနှင့် ဆင်တူသည်—၎င်းကို တိုးပွားခွင့်ပေးပြီး နာကျင်ဖွယ် burst များဖြင့် နောက်မှ ကိုင်တွယ်ရခြင်းထက် အသေးစားအဆင့်များဖြင့် ဆက်တိုက် လျှော့ချသွားခြင်းက အမြဲလိုလို ပိုကောင်းသည်။ လူသား taste ကို တစ်ကြိမ် capture လုပ်ပြီးနောက် code တစ်ကြောင်းချင်းစီတွင် ဆက်တိုက် အတည်ပြုထိန်းချုပ်နိုင်သည်။ ထို့အပြင် မကောင်းသော pattern များကို နေ့စဉ်အခြေခံဖြင့် ဖမ်းယူဖြေရှင်းနိုင်စေပြီး ၎င်းတို့ကို code base တစ်လျှောက် ရက်များ သို့မဟုတ် အပတ်များကြာ ပြန့်နှံ့သွားခွင့် မပြုတော့ပါ။

ဤနည်းဗျူဟာသည် ယခုအချိန်ထိ OpenAI တွင် internal launch နှင့် adoption အဆင့်အထိ ကောင်းစွာ အလုပ်လုပ်ခဲ့သည်။ တကယ့်အသုံးပြုသူများအတွက် တကယ့် product တစ်ခုကို တည်ဆောက်ခြင်းက ကျွန်ုပ်တို့၏ ရင်းနှီးမြှုပ်နှံမှုများကို လက်တွေ့အခြေအနေနှင့် ချိတ်ဆက်ပေးပြီး ရေရှည် ထိန်းသိမ်းနိုင်စွမ်းဘက်သို့ လမ်းညွှန်ပေးခဲ့သည်။

ကျွန်ုပ်တို့ မသိသေးသည့်အရာမှာ အပြည့်အဝ အေးဂျင့်ထုတ်လုပ်ထားသော စနစ်တစ်ခုတွင် architectural coherence သည် နှစ်များတစ်လျှောက် မည်သို့ ပြောင်းလဲတိုးတက်မလဲ ဆိုသည်ဖြစ်သည်။ လူသား judgement က leverage အများဆုံး ထည့်ပေးနိုင်သည့်နေရာကိုလည်းကောင်း၊ ထို judgement ကို တိုးပွားအကျိုးရှိစေရန် မည်သို့ encode လုပ်ရမည်ကိုလည်းကောင်း ကျွန်ုပ်တို့ ဆက်လက် သင်ယူနေဆဲဖြစ်သည်။ မော်ဒယ်များသည် အချိန်ကြာလာသည်နှင့်အမျှ ပိုမိုစွမ်းရည်ရှိလာသည့်အခါ ဤစနစ်က မည်သို့ ပြောင်းလဲမလဲကိုလည်း မသိသေးပါ။

ရှင်းလင်းလာသောအချက်မှာ software တည်ဆောက်ခြင်းသည် စည်းကမ်းကို လိုအပ်နေဆဲဖြစ်သော်လည်း ထိုစည်းကမ်းသည် code ထဲထက် scaffold ထဲတွင် ပိုမိုထင်ရှားလာသည်။ Codebase ကို coherent ဖြစ်စေသော tooling၊ abstraction များနှင့် feedback loop များသည် ပို၍ အရေးကြီးလာနေသည်။

ယခု ကျွန်ုပ်တို့၏ အခက်ခဲဆုံး စိန်ခေါ်မှုများသည် အေးဂျင့်များက ကျွန်ုပ်တို့၏ ပန်းတိုင်—အရွယ်အစားကြီးမားသော ရှုပ်ထွေးပြီး ယုံကြည်စိတ်ချရသော software ကို တည်ဆောက်ထိန်းသိမ်းရန်—ကို ပြီးမြောက်စေရန် ကူညီမည့် environment များ၊ feedback loop များနှင့် control system များကို ဒီဇိုင်းဆွဲခြင်းအပေါ် ဗဟိုပြုလာသည်။

Codex ကဲ့သို့သော အေးဂျင့်များသည် software lifecycle ၏ ပိုမိုကြီးမားသော အစိတ်အပိုင်းများကို တာဝန်ယူလာသည်နှင့်အမျှ ဤမေးခွန်းများသည် ပို၍ အရေးပါလာမည်ဖြစ်သည်။ အစောပိုင်းသင်ခန်းစာအချို့ကို မျှဝေခြင်းက သင်၏ အားထုတ်မှုကို ဘယ်နေရာတွင် ရင်းနှီးမြှုပ်နှံသင့်သည်ကို သုံးသပ်ရာတွင် ကူညီပေးပြီး သင်က အရာတွေကို တည်ဆောက်ရုံသာ လုပ်နိုင်စေမည် ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။