Код бичилт 30% өссөн ч бүтээгдэхүүн гарсангүй: Харвардын судалгаа AI агентуудын "Code Review гацаа"-г илчиллээ

Сүүлийн хоёр жилд програм хангамжийн салбар бүхэлдээ Claude Code, Cursor, GitHub Copilot болон Devin зэрэг бие даасан AI coding agent-уудыг хүч түрэн нэвтрүүлсэн билээ. Компаниудын удирдлагууд хөгжүүлэлтийн хурд 2–3 дахин өснө гэж найдаж, хөгжүүлэгчид ч гар хуруугаа амрааж эхэлсэн гэж ярьж буй. Гэвч бодит байдал дээр бүтээгдэхүүн яагаад илүү хурдан хэрэглэгчдэд хүрэхгүй байна вэ?

Энэхүү асуултад Харвардын их сургуулийн эдийн засагчид болох Фиона Чен, Жэймс Страттон нар өргөн цар хүрээтэй эмпирик судалгаагаар хариулт өглөө. Тэд инженерингийн аналитикийн Jellyfish платформын өгөгдөлд үндэслэн 718 технологийн компанийн 725,000 гаруй инженерийн 300 сая гаруй ажлын үйл явцыг (telemetry events) задлан шинжилсэн байна.

Судалгааны дүгнэлт нь өнгөц харвал бүтээмж мэт боловч гүндээ маш том системийн гацаа үүссэнийг илчиллээ.

"Хий хоосон бүтээмж": Код бичих хурд ба шийдэгдсэн ажлын зөрүү

Судалгааны баримтаас харвал инженерүүд ажлын урсгалдаа AI coding agent-уудыг нэвтрүүлснээр:

• Нэг хөгжүүлэгчийн сард бичих кодын мөр (LOC): +30% өссөн (сард дунджаар 1,500 орчим мөр нэмэгдсэн).
• Commit хийх давтамж: +20% нэмэгдсэн.
• Үүсгэсэн Pull Request (PR)-ийн тоо: +23% өссөн.

Харахад багууд гайхалтай бүтээмжтэй ажиллаж, өдөр бүр асар их хэмжээний код үйлдвэрлэж байгаа мэт. Гэвч хэрэглэгчид очих бодит үр дүн буюу хаагдсан Jira issue болон шийдэгдсэн epic-үүдийн тоог харахад ямар ч статистикийн ач холбогдол бүхий өсөлт гараагүй (0%-ийн өөрчлөлт).

Энэ юу гэсэн үг вэ? Компаниуд гурав дахин их код бичиж байгаа мөртлөө өмнөхтэйгөө яг ижил хэмжээний бүтээгдэхүүнийг л зах зээлд гаргаж (ship хийж) байна гэсэн үг юм.

Бүх ачаалал Code Review дээр нуран унав

AI үүсгэсэн асар их хэмжээний кодууд чухам хаана гацаж, хаашаа шингээд байна вэ? Судлаачид шалтгааныг програм хангамжийн хамгийн эмзэг цэг болох Code Review буюу кодын хяналтын процесс руу шилжсэнийг нотоллоо.

1. PR батлагдах хугацаа (Lead Time) 49% сунав: Өмнө нь дунджаар 7 хоногт merge хийгддэг байсан PR одоо дунджаар 10.5 хоног буюу даруй 3.5 өдрөөр илүү урт хугацаанд хүлээгдэж байна.
2. Буцаах хүсэлт (Changes Requested) хоёр дахин өссөн: Шалгагч нар өмнө нь нийт PR-ийн 13%-ийг засварт буцаадаг байсан бол энэ үзүүлэлт 25% болж бараг 2 дахин өсчээ.
3. PR дээр бичигдэх коммент 35% нэмэгдэв: Хиймэл оюуны бичсэн код өнгөн дээрээ зөв ажиллаж буй мэт боловч context-ийн гүн ойлголт дутмаг, legacy системтэй зөрчилдөх далд logic bug агуулдаг тул ахлах инженерүүд коммент бичиж, нягтлахад бүх цагаа барж байна.

Байдлыг бүр дордуулж байгаа нэг баримт нь: Судалгаанд хамрагдсан компаниудын 80% нь автомат AI Code Review хэрэгслүүдийг нэвтрүүлсэн боловч эдгээр нь нийт review комментийн дөнгөж 23%-ийг л гүйцэтгэж чадаж байна. Үлдсэн 77% нь хүний шууд оролцоо, туршлагатай инженерүүдийн анхаарал шаардсан хэвээр байгаа аж.

Яагаад "Хямд код" дарамт үүсгэв?

Технологийн салбарын нэрт архитектор Мартин Фаулер болон Forbes сэтгүүлийн шинжээчид энэ талаар тайлбарлахдаа програм хангамж хөгжүүлэлтийн мөн чанарыг сануулжээ.

Код бичих (implementation) нь програм хангамжийн амьдралын мөчлөгийн (SDLC) ердөө багахан хэсэг юм. Хамгийн хүнд, хариуцлагатай хэсэг нь:

• Шаардлагыг зөв тодорхойлох
• Архитектурын урт хугацааны шийдвэр гаргах
• Системийн аюулгүй байдал, scalability болон regression-ийг нягтлах
• Production орчинд унахгүй байх баталгааг гаргах.

AI агентууд код бичих зардлыг бараг тэглэсэн боловч, бичигдсэн кодыг унших, ойлгох, production-д бэлэн эсэхийг батлах хүний танин мэдэхүйн чадвар (cognitive bandwidth) хэвээрээ үлдсэн. Хөгжүүлэгч нэг товч дараад 500 мөр код үүсгэж чадах ч, хамтран ажиллагч нь тэр 500 мөрийн edge-case бүрийг нэг бүрчлэн уншиж шалгахаас өөр аргагүй юм.

Инженерингийн багууд одоо юуг өөрчлөх ёстой вэ?

Харвардын энэхүү судалгаа нь engineering lead болон хөгжүүлэгчдэд хэд хэдэн чухал дохиог өгч байна:

• LOC (Lines of Code) болон PR тоо бол үнэ цэнгүй үзүүлэлт (vanity metric): Багийнхаа бүтээмжийг бичсэн кодын хэмжээгээр үнэлэх нь AI-ийн эрин үед утгаа бүрэн алдлаа. Бодит бүтээмж гэдэг нь production дээр гарч буй feature-ийн чанар болон lead time юм.
• PR-ийн хэмжээг хязгаарлах: 500-аас дээш мөртэй, бүхэл бүтэн шийдлийг нэг дор шидсэн AI үүсгэсэн PR-уудыг хүлээн авахгүй байх дүрэм (size gates) багтаа тавих. Агентуудад ажлыг жижиг, тусдаа atomic task болгон хуваах даалгавар өгөх хэрэгтэй.
• "Verification Ownership"-ийг шаардах: AI-аар код бичүүлсэн инженер өөрөө тухайн код ажиллаж байгааг батлах unit/integration test, snapshot болон ажиллаж буй log-ийг PR дээрээ хавсаргаж илгээх үүрэг хүлээх ёстой. Шалгах ажлыг review хийгч рүү шууд шидэх нь багийн хурдыг 50% сааруулдаг нь тодорхой болов.

Хиймэл оюун ухаан код бичилтийг хурдасгасан ч, инженерийн гол үнэ цэн "код бичих"-д бус харин "батлан шалгах, шүүн тунгаах"-д шилжиж байна. Code Review-ийн процессоо AI эринд тохируулан шинэчлээгүй цагт хичнээн олон AI агент ашиглаад ч багийн тань release хурдсахгүй гэдгийг энэхүү томоохон судалгаа тод харууллаа.

---

Эх сурвалж: Harvard University working paper: "Artificial Intelligence in the Firm: Bottlenecks in Software Production" (Chen & Stratton), Ars Technica, Jellyfish Engineering Analytics.