Агентууд 4 минутад бичээд CI дараалалд 11 минут түгжрэв: Linear код баталгаажуулалтын хоолойгоо хэрхэн шинэчлэв?

Хөгжүүлэгчийн ертөнцөд сүүлийн саруудад нэгэн томоохон парадокс үүсээд байна: AI агентууд (Claude Code, Cursor, GitHub Copilot) код бичих болон алдаа засах ажлыг 4-хөн минутад гүйцэтгэн Pull Request (PR) нээж байгаа ч, уг PR нь автомат шалгалтын систем (CI) дээр 11 минут дараалалд гацаж байна. Код үйлдвэрлэлийн хурд автомат шалгалтын дэд бүтцийнхээ чадлаас хол даваад явчихлаа.

Шилдэг бүтээгдэхүүний соёл, инженерийн хурдаараа салбартаа жишиг болдог Linear компани яг энэ бодит асуудалтай нүүр тулснаа зарлаж, CI/CD дамжуулах хоолойгоо бүхэлд нь шинэчилсэн техникийн шийдлээ дэлгэлээ. Тэдний инженерийн багийн мэдээлснээр, 2026 оны эхнээс хойш тус багийн тест багцын (test suite) хэмжээ 4 дахин томорсон бөгөөд долоо хоног бүр дунджаар 2,000 гаруй шинэ тест нэмэгдэж байна. Үүний дийлэнхийг AI агентууд автоматаар үүсгэж буй аж. Хэрэв дэд бүтцээ гар хөдөлгөлгүй хуучнаар нь үлдээсэн бол PR шалгах хугацаа хамгийн багадаа 11 минут давж, төлбөрийн зардал хяналтаас гарах байжээ.

Linear энэ асуудлыг хэрхэн системчлэн оношилж, хүлээлтийн хугацааг 5 минут хүртэл татаж буулгасан техникийн нарийн шийдлүүдийг авч үзье.

Асуудлын үндэс: Гацаа тестэндээ бус "Setup"-д байв

Linear-ийн ахлах инженерүүд CI-ийн үр ашгийг нэмэхийн тулд юун түрүүнд хоёр үзүүлэлтийг тусад нь ялгаж хэмжсэн байна:

PR Wait Time: PR нээснээс хойш CI "ногоон гэрэл" асаах хүртэлх хөгжүүлэгчийн бодит хүлээлтийн хугацаа.
Runner Compute Time: CI pipeline нийт хэчнээн тооцооллын нөөц (CPU/RAM цаг) шатааж байгааг хэмжих үзүүлэлт буюу сарын төлбөрийн шууд өртөг.

Хамгийн сонирхолтой нь: нийт шатаж буй хугацааны дийлэнх нь кодын логик тестийг гүйцэтгэхэд бус, харин ажлын орчныг бэлтгэх "Setup Tax" дээр алдагдаж байв. Git shallow/deep checkout хийх, pnpm хамаарлуудыг татаж суулгах, тусгаарлагдсан түр container ачаалах, мөн өгөгдлийн сангийн snapshot үүсгэх явц нь нийт хугацааны 60-70 хувийг залгиж байжээ.

Linear-ийн хэрэгжүүлсэн 4 гол оновчлол

1. `tsc`-ээс `tsgo` руу: Төрөл шалгалтыг 73% хурдасгав

TypeScript хөгжүүлэгчдийн хамгийн урт суудаг процесс бол төрөл (type) шалгалт юм. Linear өөрсдийн асар том TypeScript монорепо дээр албан ёсны Node-д суурилсан tsc-ийг хасаж, Go хэлээр бичигдсэн натив компайлер болох tsgo руу шилжүүлжээ. Энэхүү ганц шилжилт нь долоо хоногийн медиан төрөл шалгах хугацааг шууд 73%-иар бууруулсан байна.

2. Type-aware ESLint-ийг халж, Oxlint болон AST-д суурилав

ESLint ашиглан TypeScript-ийн бүтэн type graph үүсгэж lint хийх нь санах ой, CPU-г хамгийн их үрдэг. Linear-ийн баг бүтэн type шаарддаг нүсэр дүрмүүдийг зөвхөн AST (Abstract Syntax Tree) түвшинд шалгадаг болгон өөрчилж, Rust суурьтай Oxlint хэрэгсэл рүү хэсэгчлэн шилжүүлжээ. Үр дүнд нь API түвшний lint шалгалт 68%-иар, нийт репозиторын хэмжээнд 55%-иар хурдассан байна.

3. Setup зардлыг хумьсан нь: Workspace Filter ба Pre-baked Images

Өмнө нь тусдаа job бүр бүх монорепогийн node_modules-ийг татаж, дунджаар 44-73 секунд алддаг байв. Инженерүүд тухайн өөрчлөлт орсон багцыг автоматаар ялган шүүдэг pnpm workspace filter тохируулснаар уг хугацааг 16-18 секунд болгон бууруулжээ. Түүнчлэн, байнга өөрчлөгддөггүй тогтвортой хамаарлуудыг өдөр бүр pre-bake хийж Docker base image-д суулгасан нь хүйтэн эхлүүлэлтийн (cold start) нөлөөг арилгасан байна.

4. Vitest Sharding болон ухаалаг тэнцвэржүүлэлт

CI дээр тестүүдийг олон зэрэгцээ (parallel) runner дээр хувааж ажиллуулахдаа зөвхөн файлын тоогоор хуваах нь хангалтгүй байдаг. Хэрэв нэг файлд 500 тест байвал бусад runner ажлаа дуусгаад сул зогсдог. Linear нүсэр тест файлуудыг жижиглэн хувааж, өмнөх гүйцэтгэлийн түүхэн хугацаанд тулгуурлан runner-уудад жигд хуваарилдаг dynamic sharding горимыг нэвтрүүлсэн байна.

Дүгнэлт: Инженерийн багууд юуг суралцах ёстой вэ?

AI агентууд код бичих хурдыг 10 дахин нэмсэн ч, хэрэв шалгах систем нь хуучнаараа байвал нийт багийн хурд (Velocity) нэмэгдэхгүй. Программ хангамж хөгжүүлэлтийн чанар AI-ийн эринд CI/CD-ийн найдвартай байдлаас шууд хамаарах боллоо.

Linear-ийн тохиолдол нь төлбөртэй том cloud runner худалдаж авахаас өмнө дамжуулах хоолойн архитектурыг нарийн шүүж, дэмий үрэгдэж буй "setup" алхмуудыг хасах нь хөгжүүлэгчийн сэтгэл ханамж болон дэд бүтцийн зардалд хамгийн бодит үр дүн авчирдгийг харуулж байна.

Эх сурвалж: Linear Engineering Blog (Mufeez Amjad), Hacker News.