AI Coding သည် CI ကို Bottleneck ဖြစ်စေခဲ့သည်- Linear Cut Pull Request စောင့်ဆိုင်းချိန်

Linear အင်ဂျင်နီယာ Mufeez Amjad သည် AI coding အေးဂျင့်များသည် CI ကို အဆိုးရွားဆုံး ပိတ်ဆို့မှုအဖြစ် ပြောင်းလဲပြီးနောက် ကုမ္ပဏီသည် ၎င်း၏ စဉ်ဆက်မပြတ် ပေါင်းစပ်ပိုက်လိုင်းကို မည်သို့ပြန်လည်လုပ်ဆောင်ကြောင်း အသေးစိတ်အကောင့်ကို ထုတ်ပြန်ခဲ့သည် — ၎င်း၏စမ်းသပ်ခန်းများသည် ယခုနှစ်အစပိုင်းကတည်းက လေးဆနီးပါး စောင့်ဆိုင်းချိန်ကို ခြောက်မိနစ်ကျော်မှ ငါးပုံအထိ ဖြတ်တောက်ထားသည်။

စက်တင်ဘာလ 21 ရက်နေ့တွင် Linear ၏အင်ဂျင်နီယာဘလော့ဂ်တွင်ထုတ်ဝေခဲ့သည်, ဤအရာများမကြာခဏလုပ်ဆောင်သကဲ့သို့, အထက်မှ terse လက်မှတ်ဖြင့်ဤအရာများစတင်ခဲ့သည်။ ယခုနှစ်အစောပိုင်းတွင် Amjad သည် ကုမ္ပဏီ၏ CTO မှ Tuomas မှ "CI ကုန်ကျစရိတ်များမြင့်မားသည်" ဟူသောခေါင်းစဉ်ဖြင့် ပြဿနာတစ်ခုအား သူ့အား တာဝန်ပေးအပ်ကြောင်းတွေ့ရှိရန် Linear ကိုဖွင့်ခဲ့ပြီး ၎င်းတွင်ရှိနေစဉ်တွင် CI ကိုပိုမိုမြန်ဆန်စေရန်တောင်းဆိုခဲ့သည်။ ဤဇာတ်လမ်းနှင့်ပတ်သက်သည့် နောက်ထပ်အကြောင်းအရာအတွက်၊ ကျွန်ုပ်တို့၏လုပ်ဆောင်နေသော AI လုပ်ငန်းလွှမ်းခြုံမှု ကို ကြည့်ပါ။

Agents Outpace Validation လုပ်တဲ့အခါ

ပြဿနာက ဖွဲ့စည်းတည်ဆောက်ပုံအရ၊ မတော်တဆမှုမဟုတ်ပါ။ "အေးဂျင့်များသည် ကုဒ်ကို ပေးပို့ရန် အဆပိုမြန်အောင် ပြုလုပ်ထားပါသည်" ဟု Amjad က ရေးသားခဲ့သည်၊ သို့သော် အဆိုပါ ပြောင်းလဲမှုများအား မှန်ကန်ကြောင်း အတည်ပြုခြင်းမှာ တူညီသောနှုန်းထားဖြင့် မပြောင်းလဲသေးပါ။ ဆွဲငင်မှုတိုင်းသည် CI မှတစ်ဆင့် ဖြတ်သန်းနေရဆဲဖြစ်သောကြောင့် ဖွံ့ဖြိုးတိုးတက်မှု အရှိန်မြှင့်လာသည်နှင့်အမျှ CI သည် အခြေခံအဆောက်အအုံကုန်ကျစရိတ်များကို မြှင့်တင်ပေးပြီး developer များနှင့် ၎င်းတို့၏ အေးဂျင့်များ တုံ့ပြန်ချက်အတွက် အချိန်ပိုကြာအောင် စောင့်ဆိုင်းနေပါသည်။

မက်ထရစ်နှစ်ခုအတွက် တစ်ပြေးညီပြုလုပ်ထားသည်- PR တစ်ဦးသည် CI တွင်စောင့်ရသည့်ကြာချိန်နှင့် အပြေးသမားအချိန်မည်မျှသုံးစွဲသည်။ လပေါင်းများစွာ အလုပ်လုပ်ပြီးနောက် ရလဒ်များ- ဇန်နဝါရီလကတည်းက စမ်းသပ်ခန်းများ လေးပုံတစ်ပုံနီးပါး တိုးလာခဲ့သော်လည်း၊ ဆွဲတင်ရန် တောင်းဆိုချက်စောင့်ဆိုင်းချိန်သည် ခြောက်မိနစ်ကျော်မှ ငါးကျော်အထိ ကျဆင်းသွားပြီး စာမေးပွဲတစ်ခုလျှင် အပြေးသမားအချိန်ကို ထက်ဝက်ခန့် ဖြတ်တောက်ခဲ့သည်။

လုပ်ငန်းကို အဆင့်မြှင့်ထားသော အခြေခံအဆောက်အအုံနှင့် ကိရိယာတန်ဆာပလာများကို အဆင့်မြှင့်တင်ခြင်း၊ အခြားအလုပ်များကို တံခါးပိတ်ပြုလုပ်ခြင်း၊ ထပ်ခါတလဲလဲ ထည့်သွင်းခြင်းကို လျှော့ချခြင်းနှင့် စမ်းသပ်လုပ်ဆောင်မှုကို ပိုမိုထိရောက်အောင် လုပ်ဆောင်ခြင်းတို့ကို အမျိုးအစား လေးမျိုးအဖြစ် ကျယ်ပြန့်စွာ ခွဲခြားထားသည်။ Linear ၏ codebase သည် အဓိကအားဖြင့် TypeScript ဖြစ်သည်၊ သို့သော် ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုများသည် ဘာသာစကားများနှင့် toolchains များပေါ်တွင် သက်ရောက်ပါသည်။

ပိုမြန်သော စက်များနှင့် Native Compiler တစ်ခု

အစောဆုံးသော အမြတ်အချို့သည် CI ကိုယ်တိုင် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ရန် မလိုအပ်ပါ။ ပိုမိုမြန်ဆန်သော CPU များ၊ စွမ်းဆောင်ရည်မြင့်မားသောသိုလှောင်မှုနှင့် ပိုမိုကောင်းမွန်သော ကက်ရှ်အခြေခံအဆောက်အဦများပါရှိသော ပြင်ပအပြေးသမားများထံသို့ GitHub လုပ်ဆောင်ချက်များမှ အလုပ်များကို ရွှေ့လိုက်သည်- ခလုတ်၏တစ်ဖက်တစ်ချက်စီ၏ နှစ်ရက်တာနှင့်တူသော နှိုင်းယှဉ်ချက်အရ၊ `tsc` ကဲ့သို့ အချို့သောအလုပ်ပမာဏသည် 52% ကျဆင်းသွားသဖြင့် ပျမ်းမျှအားဖြင့် 34% ပိုမြန်လာသည်။

Toolchain ကို ခေတ်မီအောင်ပြုလုပ်ခြင်းက အနိုင်ရမှုကို ပေါင်းစပ်စေသည်။ မူရင်း TypeScript compiler ဖြစ်သော `tsgo` သို့ပြောင်းခြင်းဖြင့် စာရိုက်စစ်ဆေးခြင်း၏ အပတ်စဉ် အလယ်အလတ်ကို 73% ဖြတ်ထားသည် — စာရိုက်စစ်ဆေးခြင်းကို လုံးလုံးလျားလျား ရွှေ့ရန် လုံလောက်သော ကြီးမားသော ပိတ်ဆို့မှုကို ဖြတ်ပါ။

ဂရပ်ဖရိုက်မပါတဲ့ Linting

Linting သည် အစောပိုင်းပစ်မှတ်ဖြစ်သည်။ လက်တစ်ဆုပ်စာ Linear ၏ စိတ်ကြိုက် ESLint စည်းမျဉ်းများသည် TypeScript အမျိုးအစားအချက်အလက်အပေါ် မူတည်ပြီး ၎င်းတို့ကို အကဲဖြတ်ခြင်းမပြုမီ အမျိုးအစားဂရပ်အပြည့်အစုံကို တည်ဆောက်ရန် တွန်းအားပေးသည့် TypeScript အမျိုးအစား အချက်အလက်ပေါ်တွင် မူတည်သည် — ၎င်းတို့ကို အကဲဖြတ်ခြင်းမပြုမီ - မှတ်ဉာဏ်အထူထပ်ဆုံး CI အလုပ်များထဲမှ တစ်ခုကို ဖန်တီးပေးပါသည်။

အဖွဲ့သည် စိတ္တဇအထားအသိုသစ်ပင်ပေါ်တွင် တည်ငြိမ်သောခွဲခြမ်းစိတ်ဖြာမှုကို အသုံးပြုရန်အတွက် စည်းမျဉ်းများကို ပြန်လည်ရေးသားကာ၊ လုပ်ဆောင်ချက်နှင့်တူသော တည်ဆောက်မှုများနှင့် အမျိုးအစားအချက်အလက်မပါဘဲ အကာအကွယ်ပုံစံများကို ခွဲခြားသတ်မှတ်သည်။ ESLint သည် TypeScript ကို လုံးလုံးလျားလျား ချနိုင်စေပြီး မှတ်ဉာဏ်အသုံးပြုမှု သိသိသာသာ ကျဆင်းသွားသဖြင့် API lint အချိန်ကို 68% နှင့် full-repository lint time ကို 55% လျှော့ချနိုင်စေပါသည်။ ၎င်းသည် နောက်ပိုင်းတွင် Oxlint သို့ ရွှေ့ပြောင်းခြင်းကိုလည်း ဖြေလျှော့ပေးသည်၊ ၎င်းသည် linting တွင်အသုံးပြုသည့် CI ပြိုင်ပွဲဝင်မိနစ်များကို ပိုမိုလျှော့ချပေးသည်။

အရေးကြီးသောလမ်းကို ကျုံ့စေခြင်း။

တစ်ဦးချင်းစစ်ဆေးမှုများ ပိုမိုမြန်ဆန်ခြင်းဖြင့်၊ Linear သည် ချဲ့ထွင်ပြီး CI ကို စနစ်တစ်ခုအဖြစ် သတ်မှတ်သည်။ ၎င်းသည် အခြားအရာအားလုံး၏ရှေ့တွင် ထိုင်နေသော အလုပ်ငယ်များကို အာရုံစိုက်စေသည် — လမ်းကြောင်းပြောင်းလဲမှု ထောက်လှမ်းခြင်းနှင့် စမ်းသပ်မှုရလဒ် ကက်ရှ်စစ်ဆေးခြင်းများသည် အလုပ်အဆင့်ရှိ ဂိတ်ပေါက်တွင် API စမ်းသပ်မှုရှစ်ခုမှ တစ်ခုမျှ မပြီးမချင်း မစတင်နိုင်ဟု ဆိုလိုသည်။

ပြုပြင်မှုများသည် အသေးစိပ်ဖြစ်သော်လည်း ပေါင်းထည့်ထားသည်။ ထုတ်ယူမှုအတိမ်အနက်သည် ၉၄ စက္ကန့်မှ ၂၀ အထိ အနှေးဆုံးတံခါးပေါက်ကို ယူသည်။ အလုပ်သစ်ပင်မလိုအပ်သော အလုပ်များမှ ငွေရှင်းခြင်းကို ၂၇ စက္ကန့်မှ ၇ စက္ကန့်အထိ ဖြတ်ပစ်လိုက်သည်။ အကန့်အသတ်ရှိသော မှတ်တမ်းပါသော ကျဲပါးသော ငွေပေးချေမှုတစ်ခုသည် တွန်းအားပေးခြင်းနှင့် တန်းစီခြင်းကို ပေါင်းစည်းခြင်းအတွက် နောက်ထပ် ၁၁ စက္ကန့်ကို သိမ်းဆည်းထားသည်။ စုစုပေါင်းအားဖြင့်၊ ပြောင်းလဲမှု-ထောက်လှမ်းခြင်းအလုပ်၏ ပျမ်းမျှကြာချိန်သည် ၂၆ စက္ကန့်မှ ၈၊ ၎င်း၏ p90 မှ ၃၁ မှ ၁၂ သို့ ကျဆင်းသွားပြီး ၎င်း၏အနှေးဆုံးပြေးချိန်မှာ ၁၃၈ စက္ကန့်မှ ၃၇ စက္ကန့်အထိဖြစ်သည်။

ငွေရှင်းရန် ယုံကြည်စိတ်ချရမှုလည်း လိုအပ်ပါသည်- ပြင်ပမှ အပြေးသမားများသည် GitHub ၏ ကွန်ရက်အပြင်ဘက်တွင် ထိုင်ကာ တိုက်ရိုက် IP လင့်ခ်ကို အားကိုးသောကြောင့်၊ အဆက်မပြတ် လင့်ခ်များ ဆုတ်ယုတ်ခြင်းမှာ ရံဖန်ရံခါ ရပ်တန့်သွားသောကြောင့် ဖြစ်သည်။ တစ်ကြောင်းတည်းဖြင့် 'လုပ်ဆောင်ချက်/ငွေရှင်းခြင်း' ကို နောက်ပြန်ပိတ်ခြင်းဖြင့် ပြန်လည်ကြိုးစားသည့် ၎င်း၏ပေါင်းစပ်လုပ်ဆောင်မှုဖြင့် တစ်ပြေးညီ အစားထိုးခဲ့ပြီး `GIT_HTTP_LOW_SPEED_LIMIT` နှင့် `GIT_HTTP_LOW_SPEED_TIME` ကို သတ်မှတ်ပေးသောကြောင့် ရပ်တန့်နေသော ချိတ်ဆက်မှုတစ်ခုသည် စက္ကန့် 30 ခန့်အကြာတွင် ပျက်သွားကာ တွဲဆိုင်းထားမည့်အစား ကြေးမုံတစ်ခုပေါ်တွင် ငွေရှင်းသည့်ကက်ရှ်တစ်ခုကို အသုံးပြုသည်။

သိမ်မွေ့သော ပြုပြင်မှုတစ်ခုသည် ပေါင်းစည်းခြင်းအချိန်ကို ဖြုန်းတီးခြင်းကို ဖယ်ရှားလိုက်သည်- ပေါင်းစည်းခြင်းမပြုမီ နောက်ဆုံးစစ်ဆေးချက်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ကက်ရှ်အမှတ်အသားများကို ရေးမှတ်ထားသောကြောင့် PR တစ်ဦးသည် စမ်းသပ်မှုများပြီးသည်နှင့်ပင် တန်းစီနေနိုင်သည်။ API ဆွဲထုတ်သည့် တောင်းဆိုချက်တိုင်းအတွက် ပေါင်းစည်းမှုလမ်းကြောင်းမှ 42 စက္ကန့်ကြာ ခြစ်ရာမဟုတ်သော အလုပ်အဖြစ်သို့ ရွှေ့ကာ API ဆွဲထုတ်သည့် တောင်းဆိုချက်နှင့် တန်းစီစာရင်း ပေါင်းစည်းခြင်း အတူတူ၊ ဤပြောင်းလဲမှုများသည် အပြေးစတင်ခြင်းကို လျှော့ချနေစဉ်အတွင်း ကက်ရှ်မလွတ်ခြင်းရှိ API PR များအတွက် လိုအပ်သောစစ်ဆေးမှုများမှ တစ်မိနစ်ခန့်ကြာပါသည်။

အလုပ်တစ်ခုလျှင် စက္ကန့်အနည်းငယ် ဖြုန်းတီးခြင်း။

အလုပ်တိုင်းတွင် တပ်ဆင်မှုကုန်ကျစရိတ်ကို တိုက်ခိုက်ခဲ့သည့် နောက်ဆုံးအမျိုးအစား။ API test shard တစ်ခုစီသည် run တိုင်းတွင် apt ဖြင့် တူညီသော Postgres client ကို install လုပ်ရန် 7 မှ 8 စက္ကန့်ကြာသည်။ ၎င်းကို Node နှင့်အတူ CI အခြေခံပုံငယ်တစ်ခုအဖြစ်သို့ ရွှေ့လိုက်ခြင်းကြောင့် shard များသည် စတင်လည်ပတ်ရန် အသင့်ဖြစ်နေပြီဖြစ်သည်။ စဖွင့်သတ်မှတ်မှုအတွင်း ၎င်းတို့ကို ဒေါင်းလုဒ်ဆွဲခြင်းသည် ရံဖန်ရံခါ ချိတ်ထားနိုင်ကြောင်း တွေ့ရှိပြီးနောက်တွင် အဖွဲ့သည် မူရင်းတည်ဆောက်မှု ခေါင်းစီးများကို ပုံတွင် ထည့်သွင်းခဲ့သည်။

##ဘာလို့ အသံထွက်တာလဲ။

အဆိုပါ ပို့စ်သည် ဆော့ဖ်ဝဲရေးသားသူများကို စိတ်အနှောင့်အယှက်ဖြစ်စေခဲ့သည်- ၎င်းသည် တစ်နေ့လျှင် အကြမ်းဖျင်းအချက် 250 နှင့် မှတ်ချက်ပေါင်း 280 ခန့်ကို Hacker News ၏ ရှေ့ဆုံးစာမျက်နှာသို့ရောက်ရှိခဲ့သည်။ တုံ့ပြန်မှုသည် ရှင်းပြရန် လွယ်ကူသည် — Linear ၏ အတွေ့အကြုံသည် အင်ဂျင်နီယာ အဖွဲ့အစည်း အများစု ရင်ဆိုင်နေရသော AI-အကူအညီဖြင့် ဖွံ့ဖြိုးတိုးတက်မှု ကုန်ကျစရိတ်ကို နာမည်ပေးသည်။ မိနစ်ပိုင်းအတွင်း ဆွဲယူတောင်းဆိုမှုများကို ထုတ်ပေးသည့် အေးဂျင့်များသည် လူသား၏ပုံစံအတွက် ဒီဇိုင်းထုတ်ထားသော ပိုက်လိုင်းများပေါ်တွင် စောင့်ဆိုင်းနေဆဲဖြစ်ပြီး ထိုစောင့်ဆိုင်းမှု၏ မိနစ်တိုင်းသည် အပြိုင်အလုပ်လုပ်နေသော အေးဂျင့်တိုင်းတွင် များပြားနေသည်။

Linear ၏ ပြန်လည်လုပ်ဆောင်မှုမှ သင်ခန်းစာမှာ လည်ပင်းပိတ်ဆို့မှုသည် ရွေ့လျားနိုင်သော်လည်း၊ သေးငယ်သောပြင်ဆင်မှုများ၏ ဆိုးရွားစွာ စုဆောင်းခြင်းမှသာလျှင် - ပိုမြန်သော အပြေးသမားများ၊ စျေးသက်သာသော စာစီစာကုံးများ၊ အထားအသို-အဆင့် ဖျာပုံစည်းနည်းဥပဒေများ၊ ထုပ်ပိုးထားသော ထုတ်ယူမှုများ၊ ခံနိုင်ရည်ရှိသော ငွေရှင်းခြင်းများ၊ ကြိုတင်တည်ဆောက်ထားသော ရုပ်ပုံများ—ငွေကျည်ဆန်တစ်ခုတည်းထက်—

---

AI ၏ရှေ့တွင်နေရန်

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

AI သတင်းအပြည့်အစုံကို ဖတ်ရှုရန် →