အင်ဂျင်နီယာအသိုက်အဝန်း၏ အမြင်မှတစ်ဆင့် AI အခြေပြု ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး၏ လက်ရှိအခြေအနေကို နားလည်သဘောပေါက်ခြင်း

■ SDD ပြန့်နှံ့လာရခြင်းမှာ ၎င်း၏ သီအိုရီက ပိုမိုကောင်းမွန်နေ၍တင် မဟုတ်ပါ။

မည်မျှပင် ကောင်းမွန်လှပသော စိတ်ကူးစိတ်သန်းဖြစ်ပါစေ၊ လက်တွေ့လုပ်ငန်းခွင်ရှိ အရေးတကြီးလိုအပ်နေသော ပြဿနာများကို မဖြေရှင်းနိုင်ပါက ပြန့်နှံ့သွားမည်မဟုတ်ပါ။ SDD ကို လူသိများလာရခြင်း၏ အကြောင်းရင်းတစ်စိတ်တစ်ပိုင်းမှာ Vibe Coding (စိတ်ခံစားချက်အခြေပြု ကုဒ်ရေးခြင်း) ကျယ်ပြန့်လာခြင်းကြောင့် ဖြစ်သည်။ AI သည် အရာရာကို အလွန်မြန်ဆန်စွာ ဖန်တီးပေးနိုင်သောကြောင့်၊ ပုံစံတူစမ်းသပ်မှု (Prototype) မှသည် လက်တွေ့အသုံးပြုမည့် (Production) အဆင့်သို့ ကူးပြောင်းသည့်အခါ 'ဒီအတိုင်း ဆက်သွားရင်တော့ အန္တရာယ်ရှိနိုင်တယ်' ဆိုသည့် စိုးရိမ်စိတ်များ တိုးပွားလာကြသည်။ ဤသည်မှာ အလွန်အရေးကြီးသော အမြင်တစ်ခု ဖြစ်သည်။ နည်းပညာအသစ်တစ်ခုသည် ကုမ္ပဏီများအတွင်း အခြေကျရယူနိုင်ခြင်းမှာ ၎င်းနည်းပညာက 'မှန်ကန်ကြောင်း' ရှင်းပြနိုင်၍မဟုတ်ဘဲ၊ 'ဒါမရှိရင်တော့ မဖြစ်တော့ဘူး' ဟု လူများက လက်တွေ့သိနားလည်လာကြသည့်အခါမှသာ ဖြစ်သည်။ ယခုအခါ SDD သည် ထိုအဆင့်သို့ အသေအချာ ရောက်ရှိလို့နေပြီ ဖြစ်သည်။

■ ပုံစံတူစမ်းသပ်မှု (Prototype) အောင်မြင်ခြင်းသည် လက်တွေ့အသုံးပြုမည့် ဗားရှင်း (Production) သို့ ကူးပြောင်းရာတွင် ကြုံတွေ့ရမည့် အခက်အခဲများကို ပေါ်လွင်စေသည်။

AI ကို အသုံးပြု၍ ပုံစံတူစမ်းသပ်မှုများ (Prototypes) ဖန်တီးခြင်းသည် ယခင်ကထက် များစွာ ပိုမိုလွယ်ကူလာသည်။ သို့သော် အလုပ်လုပ်နိုင်သော ပုံစံတူများကို ပိုမိုမြန်ဆန်စွာ ဖန်တီးနိုင်လေလေ၊ စနစ်၏ အရည်အသွေး (Quality)၊ တိုးချဲ့နိုင်စွမ်း (Scalability)၊ ရေရှည်ထိန်းသိမ်းနိုင်စွမ်း (Maintainability) နှင့် ပြန်လည်စစ်ဆေးနိုင်စွမ်း (Auditability) တို့သည် ပိုမိုအရေးကြီးသော အချက်များ ဖြစ်လာလေလေ ဖြစ်သည်။ စမ်းသပ်မှုအဆင့် (PoC phase) တွင် ထင်ရှားစွာမမြင်ရသော ပြဿနာများသည် လက်တွေ့လုပ်ငန်းခွင် (Production) သို့ ကူးပြောင်းသည့်အခါ ရုတ်တရက် ပေါ်ပေါက်လာတတ်သည်။ ဤနေရာတွင်ပင် လုပ်ငန်းသတ်မှတ်ချက်များ (Specifications)၊ ချိတ်ဆက်မှုစနစ်များ (Hooks) နှင့် စည်းမျဉ်းစည်းကမ်းများ (Rules) ရှိရန် လိုအပ်ကြောင်းကို ပိုမိုပြင်းထန်စွာ သတိပြုမိလာကြခြင်း ဖြစ်သည်။

■ ကိရိယာများနှင့် မော်ဒယ်များ၏ တိုးတက်ပြောင်းလဲလာမှုသည် SDD ကို 'လက်တွေ့ကျကျ အသုံးပြုနိုင်စွမ်း' ရှိစေခဲ့သည်။

လုပ်ငန်းသတ်မှတ်ချက်များကို အလေးထားခြင်းဟူသော အတွေးအခေါ်မှာ ကြာမြင့်စွာကတည်းက ရှိခဲ့ဖူးသည်။ သို့သော် ၂၀၂၅ ခုနှစ် ဒုတိယနှစ်ဝက်တွင်မူ ၎င်းကို လက်တွေ့အကောင်အထည်ဖော်ရန် ပတ်ဝန်းကျင်ကောင်းများ စတင်ပုံပေါ်လာခဲ့သည်။ အဘယ်ကြောင့်ဆိုသော် လုပ်ငန်းသတ်မှတ်ချက် အမျိုးအစားများကို သတ်မှတ်ပေးနိုင်မည့် ကိရိယာစုများ ထွက်ပေါ်လာခြင်းနှင့် AI မော်ဒယ်များသည် သတ်မှတ်ချက်အခြေပြု လုပ်ငန်းစဉ်များကို လက်တွေ့ကျသော တိကျမှုနှုန်းဖြင့် လုပ်ဆောင်ပေးနိုင်သည့် အဆင့်သို့ ရောက်ရှိလာခြင်းကြောင့် ဖြစ်သည်။ ဤနေရာတွင် အရေးကြီးသည်မှာ အတွေးအခေါ် (Philosophy) နှင့် အကောင်အထည်ဖော်မှုစနစ် (Implementation methods) နှစ်ခုစလုံးသည် တစ်ချိန်တည်းမှာပင် ရင့်ကျက်အခြေကျလာခြင်း ဖြစ်သည်။ အတွေးအခေါ် သက်သက်ဖြင့်လည်း မပြန့်နှံ့နိုင်သလို၊ ကိရိယာ သက်သက်ဖြင့်လည်း အမြစ်တွယ်မလာနိုင်ပါ။ စိတ်ဓာတ်ပိုင်းဆိုင်ရာ၊ မူဘောင် (Framework) နှင့် လုပ်ဆောင်နိုင်စွမ်း အားလုံး ကိုက်ညီမှုရှိလာသည့် အခါမှသာ ကုမ္ပဏီများအနေဖြင့် တစ်ခုခုကို စတင်လက်ခံအသုံးပြုရန် စဉ်းစားကြခြင်း ဖြစ်သည်။ စီမံခန့်ခွဲမှုပိုင်းအနေဖြင့် သတိပြုရန်မှာ စျေးကွက်အတွင်း လက်တွေ့အကောင်အထည်ဖော်နိုင်စွမ်း (Feasibility) ပြောင်းလဲသွားပြီ ဖြစ်သည်ဟူသော အချက်ပင်။ စောစီးစွာ ရင်းနှီးမြှုပ်နှံလွန်းပါက စမ်းသပ်မှုအဆင့်တွင်သာ လည်ပတ်နေမည်ဖြစ်ပြီး၊ နောက်ကျမှ ရင်းနှီးမြှုပ်နှံပါက ပြိုင်ဆိုင်မှုတွင် အားနည်းချက်အဖြစ် ပြန်လည်သက်ရောက်လာမည် ဖြစ်သည်။ ယခုအချိန်သည် စမ်းသပ်မှုအဆင့်မှသည် လက်တွေ့အသုံးချမှုအဆင့်သို့ ကူးပြောင်းရန် ဆုံးဖြတ်ရမည့် အရေးကြီးသော အချိန်အခါပင် ဖြစ်သည်။

■ သတ်မှတ်ချက်ကန့်သတ်ချက်များကို ဖယ်ရှားလိုက်ခြင်းနှင့် လေ့လာလိုစိတ် လိုအပ်ချက်များကို မြင်သာစေခြင်းတို့က ၎င်းကို လူမှုရေးရာဖြစ်စဉ်တစ်ခု (Social phenomenon) အဖြစ်သို့ ပြောင်းလဲတွန်းအားပေးခဲ့သည်။

မည်မျှပင် ကောင်းမွန်သော နည်းပညာဖြစ်ပါစေ၊ လူနည်းစုသာ အသုံးပြုနိုင်မည်ဆိုပါက လူကြိုက်များလာမည်မဟုတ်ပါ။ စောင့်ဆိုင်းရမည့် ကန့်သတ်ချက်များကို ဖယ်ရှားပေးပြီး အသုံးပြုသူအခြေခံကို ချဲ့ထွင်လိုက်ခြင်းက ကျရှုံးမှုများနှင့် အောင်မြင်မှုများကို ချက်ချင်း မြင်သာစေသည်။ ရလဒ်အနေဖြင့် လူများသည် 'ဒါကို ဘယ်လိုအောင်မြင်အောင် သုံးမလဲ' ဆိုသည်ကို မျှဝေနိုင်ရုံတင်မကဘဲ 'ဘယ်လို ဘေးကင်းအောင် သုံးမလဲ' ဆိုသည်ကိုပါ လေ့လာသင်ယူနိုင်ကြမည် ဖြစ်သည်။ ထို့အပြင်၊ လေ့လာရေးပွဲများနှင့် စာဖတ်ဝိုင်း (Study groups) များအပေါ် စိတ်ဝင်စားမှု မြင့်တက်လာခြင်းသည် လက်တွေ့ကွင်းဆင်းလုပ်ဆောင်နေသူများက ၎င်းကို စိတ်ဝင်စားစရာအဆင့်မျှသာမဟုတ်ဘဲ လက်တွေ့ကျကျ လိုအပ်ချက်တစ်ခုအဖြစ် စတင်မြင်မလာကြခြင်း၏ လက္ခဏာဖြစ်သည်။ ၎င်းသည် နည်းပညာတစ်ခုအား 'နားလည်တတ်ကျွမ်းသူများအတွက် သီးသန့်' အဆင့်မှသည် 'အဖွဲ့အစည်းတစ်ခုလုံး ကိုင်တွယ်ဖြေရှင်းရမည့် အဓိကအကြောင်းအရာ' အဖြစ်သို့ မြှင့်တင်လိုက်ခြင်းဖြစ်သောကြောင့်၊ လက်တွေ့အသုံးချရန် စဉ်းစားနေသော ကုမ္ပဏီများအနေဖြင့် လျစ်လျူမရှုသင့်သည့် အညွှန်းကိန်းတစ်ခု ပင် ဖြစ်သည်။

■ Vibe Coding ပြန့်နှံ့လာခြင်းကြောင့် SDD ဆိုင်ရာ လိုအပ်ချက်များ ထွက်ပေါ်လာစေသည့် ပြောင်းပြန်အကျိုးသက်ရောက်မှု (Paradox)

ဤနေရာတွင် ရရှိနိုင်သည့် အရေးကြီးဆုံး အမြင်မှာ Vibe Coding (စိတ်ခံစားချက်အခြေပြု ကုဒ်ရေးခြင်း) နှင့် SDD (သတ်မှတ်ချက်အခြေပြု ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး) တို့သည် ဆန့်ကျင်ဘက် အယူအဆများ မဟုတ်ကြဘဲ၊ အကြောင်းနှင့် အကျိုး ဆက်စပ်နေခြင်းသာ ဖြစ်သည်။ အလွန် စိတ်ကြိုက်ပြောင်းလဲလွယ်သော AI ဖွံ့ဖြိုးရေးစနစ်များ ကျယ်ပြန့်လာသောကြောင့်သာ ၎င်း၏ ကန့်သတ်ချက်များနှင့် အန္တရာယ်များကို မြင်သာလာစေပြီး၊ ထိန်းချုပ်မှုစနစ် (Control) လိုအပ်ကြောင်း ထင်ရှားလာခြင်း ဖြစ်သည်။ တစ်နည်းအားဖြင့်ဆိုရသော် Vibe Coding ထွန်းကားလာခြင်းသည် SDD ကို ပျက်ပြားစေသည့် အကြောင်းရင်းမဟုတ်ဘဲ၊ SDD ကို မရှိမဖြစ် လိုအပ်လာအောင် ဖန်တီးပေးလိုက်သည့် ကနဦး အခြေအနေတစ်ရပ် ဖြစ်နေပါသည်။

■ AI အေးဂျင့်တစ်ခုတည်း သုံးစွဲခြင်းမှသည် အဖွဲ့လိုက် ပူးပေါင်းအသုံးပြုခြင်း (Team-based AI) ဆီသို့

ယခုအချိန်အထိ ကုမ္ပဏီအများစုသည် AI ကိရိယာတစ်ခုတည်း သို့မဟုတ် AI အေးဂျင့် (Agent) တစ်ခုတည်းကို မည်သို့အသုံးပြုရမည်ဆိုသည့်အချက်ပေါ်၌သာ အာရုံစိုက်ခဲ့ကြသည်။ သို့သော် ရှေ့ဆက်သွားမည့် အနာဂတ်တွင်မူ အကောင်အထည်ဖော်ခြင်း (Implementation)၊ ရှာဖွေလေ့လာခြင်း (Research)၊ ပြန်လည်စစ်ဆေးခြင်း (Review) နှင့် စမ်းသပ်ခြင်း (Testing) စသဖြင့် မိမိတို့ကဏ္ဍအလိုက် တာဝန်ကိုယ်စီယူထားသည့် AI အေးဂျင့်အမြောက်အမြား စနစ်တကျ ပူးပေါင်းလုပ်ဆောင်ကြမည့် ပုံစံမျိုးသည် ပိုမိုလက်တွေ့ကျလာနေပြီ ဖြစ်သည်။ ဤပြောင်းလဲမှုသည် ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေးအဖွဲ့အစည်းများ၏ အတွေးအခေါ်ကို အခြေခံကျကျ ပြောင်းလဲပစ်လိမ့်မည်။ လူသားများက အရာရာတိုင်းအတွက် အသေးစိတ်ညွှန်ကြားချက်များ ပေးနေမည့်အစား၊ လုပ်ငန်းများကို အစိတ်အပိုင်းများအဖြစ် ခွဲခြမ်းစိတ်ဖြာပြီး အေးဂျင့်တစ်ခုချင်းစီထံ သင့်လျော်သလို ခွဲဝေပေးကာ ထွက်ပေါ်လာသည့် ရလဒ်များကို ပြန်လည်ပေါင်းစပ်ခြင်းမျိုး ပြုလုပ်လာကြမည် ဖြစ်သည်။ တစ်နည်းအားဖြင့်ဆိုရသော် လူသားတို့၏ အခန်းကဏ္ဍသည် အခြားသူများအတွက် 'ဝင်ရောက်အကောင်အထည်ဖော်ပေးခြင်း' မှသည် လုပ်ငန်းစဉ်တစ်ခုလုံးကို 'လမ်းညွှန်ခြင်းနှင့် ထိန်းချုပ်ခြင်း (Direction and control)' ဆီသို့ ပိုမိုရွေ့လျားပြောင်းလဲသွားမည် ဖြစ်သည်။

■ အရေးကြီးသောအချက်မှာ AI အရေအတွက်ကို တိုးမြှင့်ရန်မဟုတ်ဘဲ ၎င်းတို့၏ အခန်းကဏ္ဍများကို ပုံစံထုတ်ရန် ဖြစ်သည်။

'Multi-agent' ဟူသော ဝေါဟာရတစ်ခုတည်းကပင် AI အရေအတွက် ပိုများလာပါက စနစ်သည် ပိုမိုအားကောင်းလာလိမ့်မည်ဟူသော အထင်အမြင်မျိုးကို ပေးနိုင်ပါသည်။ သို့သော် အမှန်တကယ်တွင်မူ ၎င်း၏ ပြောင်းပြန်သာ ဖြစ်သည်။ ရှင်းလင်းပြတ်သားစွာ သတ်မှတ်ထားသော အခန်းကဏ္ဍများ မရှိဘဲ အေးဂျင့်အရေအတွက်ကိုသာ တိုးမြှင့်လိုက်ပါက ၎င်းတို့၏ တာဝန်ယူမှုအပိုင်းများ ထပ်နေတတ်ပြီး၊ ရလဒ်ထွက်ကုန်များ၏ တသမတ်တည်းဖြစ်မှု ပျက်ပြားသွားကာ၊ လုပ်ငန်းစဉ်မှတ်တမ်း (Audit trail) များကို စီမံခန့်ခွဲရန် ခက်ခဲလာပါလိမ့်မည်။ အဓိကသော့ချက်မှာ မည်သည့်အေးဂျင့်က မည်သည့်အရာကို တာဝန်ယူမည်နည်း၊ မည်သည့်အစီအစဉ်အတိုင်း ပူးပေါင်းဆောင်ရွက်မည်နည်းနှင့် မည်သည့်နေရာတွင် လူသားတို့၏ အတည်ပြုချက် လိုအပ်မည်နည်း ဆိုသည်ကို ပုံစံထုတ်ရန် (Design) ဖြစ်သည်။ ဤနေရာတွင်ပင် ပိုမိုအဆင့်မြင့်သော SDD (ဆော့ဖ်ဝဲလ်အခြေပြု ပုံစံထုတ်ခြင်း) ရန် လိုအပ်လာခြင်း ဖြစ်သည်။

■ A2A နှင့် MCP စနစ်များ ပိုမိုအခြေကျလာသည်နှင့်အမျှ နည်းပညာဆိုင်ရာ စိန်ခေါ်မှုများသည် 'ချိတ်ဆက်မှု' မှသည် 'ထိန်းချုပ်မှု' ဆီသို့ ရွေ့လျားလာသည်။

Multi-agent ခေတ်ကို ပံ့ပိုးပေးမည့် နည်းပညာဆိုင်ရာ အခြေခံအုတ်မြစ်တစ်ခုအနေဖြင့် အေးဂျင့်အချင်းချင်း ပူးပေါင်းဆောင်ရွက်မှု (Inter-agent cooperation) နှင့် ကိရိယာများ ချိတ်ဆက်မှုစနစ် (Tool connectivity) များကို စံနှုန်းသတ်မှတ်ခြင်း (Standardization) များသည် တိုးတက်လာနေပြီ ဖြစ်သည်။ ၎င်းသည် AI တစ်ခုတည်းကိုသာ အသုံးပြုခြင်းနှင့် နှိုင်းယှဉ်ပါက ပိုမိုရှုပ်ထွေးသော ပူးပေါင်းဆောင်ရွက်မှု လုပ်ငန်းစဉ်များကို လက်တွေ့လုပ်ဆောင်နိုင်စေသည်။ သို့သော် စံနှုန်းသတ်မှတ်ထားသော ပရိုတိုကော (Protocols) များ အခြေကျလာခြင်းသည် အကောင်အထည်ဖော်မှုကို ပိုမိုလွယ်ကူစေနိုင်သော်လည်း လက်တွေ့လည်ပတ်မှုကိုမူ ပိုမိုလွယ်ကူလာစေမည်ဟု အာမမခံနိုင်ပါ။ အမှန်တကယ်တွင် ချိတ်ဆက်မှုစနစ်က ပိုမိုလွယ်ကူလာလေလေ၊ ကုမ္ပဏီများအနေဖြင့် ထိန်းချုပ်မှုစနစ် (Controls) များကို ပုံစံထုတ်ရန် ပိုမိုလိုအပ်လာလေလေ ဖြစ်သည်။ ဘာတွေကို ချိတ်ဆက်ခွင့်ပြုမှာလဲ။ ဘယ်အချက်အလက်တွေကို ရယူခွင့်ပြုမှာလဲ။ ဘယ်လို ဆုံးဖြတ်ချက်မျိုးတွေကို AI ထံ လွှဲအပ်ပြီး ဘယ်နေရာမှာတော့ ရပ်တန့်ထားရမလဲ။ ဤအရာများကို တိတိကျကျ မသတ်မှတ်ဘဲ ချိတ်ဆက်မှုကိုသာ တိုးမြှင့်လိုက်ပါက ရရှိလာမည့် အဆင်ပြေချောမွေ့မှုများသည် တိုးပွားလာမည့် အန္တရာယ် (Risks) များကြောင့် ပြယ်လွင့်သွားပါလိမ့်မည်။ စီမံခန့်ခွဲမှုပိုင်းအတွက်မူ ဤနေရာသည် အုပ်ချုပ်မှုစနစ် (Governance) ကို ပုံစံထုတ်ရန် အလွန်အရေးကြီးသော နေရာဖြစ်လာသည်။ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး မန်နေဂျာများအတွက်မူ လုပ်ငန်းလည်ပတ်မှု စံနှုန်းများနှင့် ပြန်လည်စစ်ဆေးနိုင်စွမ်း (Auditability) ကို ပုံစံထုတ်ခြင်းသည် အဓိကသော့ချက် ဖြစ်လာသည်။ လက်တွေ့ကွင်းဆင်း လုပ်ဆောင်နေကြသော အင်ဂျင်နီယာများအတွက်မူ ကိရိယာတစ်ခုချင်းစီကို ကျွမ်းကျင်ပိုင်နိုင်စွာ အသုံးပြုတတ်ရန်ထက် စနစ်တစ်ခုလုံး၏ ဗိသုကာပုံစံ (Overall architecture) ကို နားလည်သဘောပေါက်ထားရန်က ပိုမိုအရေးကြီးလာမည် ဖြစ်သည်။

■ အဆင့်မြင့် SDD ခေတ်တွင် အမှန်တကယ် လိုအပ်သည်မှာ 'AI ကို စနစ်တကျ လည်ပတ်စေနိုင်မည့် အဖွဲ့အစည်းဆိုင်ရာ စွမ်းဆောင်ရည်' ဖြစ်သည်။

Multi-agent စနစ်များ ထွန်းကားလာသော ခေတ်တွင် လုပ်ငန်းသတ်မှတ်ချက်များ (Specifications) သည် ပိုမိုနက်ရှိုင်းပြီး အသေးစိတ်ကျသော အဆင့်အတန်း (Higher level of granularity) ရှိရန် လိုအပ်လာသည်။ လုပ်ဆောင်ချက်ဆိုင်ရာ လိုအပ်ချက်များ (Functional requirements) ကို ပေးရုံမျှဖြင့် မလုံလောက်တော့ဘဲ လုပ်ငန်းများကို အစိတ်အပိုင်းများအဖြစ် ခွဲခြမ်းစိတ်ဖြာမှု အသေးစိတ်နှုန်း၊ တစ်ဆင့်လွှဲပြောင်းပေးရမည့် အခြေအနေများ (Handover conditions)၊ ထွက်ပေါ်လာမည့် ရလဒ်ထွက်ကုန်၏ ပုံစံ (Deliverable format)၊ အကဲဖြတ်မှု စံနှုန်းများနှင့် အမှားအယွင်းဖြစ်ပါက ပြန်လည်လုပ်ဆောင်ရမည့် စည်းမျဉ်းများ (Retry rules) တို့ကိုပါ စနစ်တကျ ပုံစံထုတ်ရန် လိုအပ်လာသည်။ ဤအချက်သည် အဖွဲ့အစည်းများအတွက် ကြီးမားသော သက်ရောက်မှုများ ရှိစေပါသည်။ AI ကို အောင်မြင်စွာ အသုံးပြုနိုင်ခြင်း ရှိမရှိ ဆိုသည်မှာ အင်ဂျင်နီယာတစ်ဦးချင်းစီ၏ တစ်ကိုယ်ရေ အရည်အချင်း သို့မဟုတ် ကိရိယာ (Tools) များ ရွေးချယ်မှုအပေါ်၌သာ မူတည်တော့မည်မဟုတ်ဘဲ AI ကို စနစ်တကျ လည်ပတ်စေနိုင်မည့် အဖွဲ့အစည်းဆိုင်ရာ စွမ်းဆောင်ရည် (Organizational capabilities) အပေါ်တွင်သာ မူတည်လာမည် ဖြစ်သည်။ တစ်နည်းအားဖြင့်ဆိုရသော် နောင်အနာဂတ်တွင် ကွာဟချက် ဖြစ်လာမည့်အချက်မှာ 'AI ကို ဝယ်ယူနိုင်ခြင်း ရှိမရှိ' မဟုတ်ဘဲ 'AI ကို မည်မျှ ထိရောက်စွာ ပုံစံထုတ်ပြီး လည်ပတ်စေနိုင်သလဲ' ဆိုသည့် အချက်ပင် ဖြစ်သည်။

■ နောက်ထပ်ဖြစ်လာမည့် ပြိုင်ဆိုင်မှုသည် ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေး၏ 'မြန်နှုန်း' ပေါ်တွင် မဟုတ်ဘဲ 'ထိန်းချုပ်မှုရှိသော မြန်နှုန်း (Governed speed of development)' ပေါ်တွင်သာ ဖြစ်လိမ့်မည်။

AI ကို အသုံးပြုပြီး အရာရာကို မြန်ဆန်စွာ ဖန်တီးနိုင်စွမ်းရှိခြင်းဆိုသည်မှာ အနာဂတ်တွင် လူတိုင်းလုပ်နိုင်မည့် သာမန်အခြေအနေတစ်ခု (A given) ဖြစ်လာပါလိမ့်မည်။ ထိုအဆင့်ကို ကျော်လွန်ပြီးနောက် ထွက်ပေါ်လာမည့် မေးခွန်းမှာ မိမိတို့အနေဖြင့် အဆိုပါ မြန်ဆန်မှုကို မည်မျှအထိ ဘေးကင်းလုံခြုံစွာ၊ အကြောင်းပြချက် ခိုင်လုံစွာ (Explainably) နှင့် ထပ်ခါတလဲလဲ လုပ်ဆောင်သော်လည်း တသမတ်တည်းဖြစ်အောင် (Reproducibly) ဖန်တီးနိုင်သလဲ ဆိုသည့်အချက်ပင် ဖြစ်သည်။ ဤသည်မှာ ရိုးရိုးရှင်းရှင်း မြန်နှုန်းပြိုင်ပွဲ မဟုတ်ဘဲ ထိန်းချုပ်မှုစနစ်ပါဝင်သော မြန်နှုန်းပြိုင်ပွဲ (Competition of controlled speed) သာ ဖြစ်သည်။ ယခုအချိန်တွင် ကုမ္ပဏီများ ကြိုတင်ပြင်ဆင်ထားသင့်သည်မှာ ကိရိယာ (Tools) ချဉ်းကပ်နှိုင်းယှဉ်ချက်ဇယားများကို လိုက်လံပြင်ဆင်နေခြင်းမျိုး မဟုတ်ဘဲ လုပ်ငန်းသတ်မှတ်ချက် မူဘောင်များ (Specification frameworks)၊ အရည်အသွေးစစ်ဆေးရေးဂိတ်များ (Quality gates)၊ အခန်းကဏ္ဍ ခွဲဝေမှုများနှင့် အေးဂျင့်များ ပူးပေါင်းဆောင်ရွက်မှုဆိုင်ရာ စည်းမျဉ်းစည်းကမ်းများကို စနစ်တကျ တည်ဆောက်ခြင်းသာ ဖြစ်ပါသည်။