Review Bottleneck៖ AI សរសេរ code ច្រើនជាងមុន ហើយយើងអនុម័តរបស់អាក្រក់ជាង

រឿងដែលគ្រប់គ្នានិយាយអំពី AI coding ជារឿងអំពី ការ generate៖ agent សរសេរ code លឿនជាង ដូច្នេះអ្នក ship លឿនជាង។ វាពិតពាក់កណ្ដាល ហើយពាក់កណ្ដាលដែលបាត់ជាកន្លែងដែលបញ្ហាទាំងអស់រស់នៅ។ Code ត្រូវតែ review មុនពេលវា ship — ហើយ review ត្រូវបានធ្វើដោយមនុស្ស តាមល្បឿនមនុស្ស ជាមួយការយកចិត្តទុកដាក់របស់មនុស្ស។ ការ generate ថោកជាង 2–5x។ ការ review មិនទេ។ ដូច្នេះ bottleneck មិនបាត់ទេ វាបានផ្លាស់ទៅ downstream ហើយកាន់តែអាក្រក់។ ហើយការរកឃើញដ៏មិនស្រួលបំផុតនៃឆ្នាំ ២០២៦ គឺនៅពេលជាក់លាក់ដែល review សំខាន់បំផុត វាកំពុងបរាជ័យស្ងាត់ៗ — ព្រោះយើងអនុម័ត code ដែលសរសេរដោយ AI ងាយ ជាងបើទោះបីជាវា អាក្រក់ ជាង។

Bottleneck បានផ្លាស់ទៅ downstream

ចាប់ផ្ដើមជាមួយបរិមាណ ព្រោះ scale ពិតជាថ្មី។ GitHub រាយការណ៍ថា Copilot code review បាន process លើស 60 million reviews កើនឡើង 10x ក្នុងរយៈពេលតិចជាងមួយឆ្នាំ ហើយ ច្រើនជាង one in five code reviews លើ GitHub ឥឡូវនេះពាក់ព័ន្ធ agent។ Pull request ដែលនិពន្ធដោយ agent មិនមែនជារឿងចម្លែកទៀតទេ វាជាសមាមាត្រដ៏មានន័យនៃអ្វីៗគ្រប់យ៉ាងដែលហូរកាត់ review។

ពេលការ generate បង្កើនល្បឿន ហើយ review មិនទេ queue កកស្ទះ — ហើយទិន្នន័យនិយាយថាវាកើតឡើងខ្លាំង។ Faros AI’s 2026 engineering study ដែលវាបានរាយការណ៍លើ developer ប្រហែល 22,000 នាក់ បានរកឃើញថាពេល AI adoption កើនឡើង PR review time កើនឡើង 91% ហើយ PR size កើនឡើង 154% បើទោះបីជាការបញ្ចប់ task និងបរិមាណ merge ឡើង — ដោយគ្មានការកែលម្អត្រូវគ្នាក្នុង delivery metrics។ (ទាំងនេះជាតួលេខដែល Faros រាយការណ៍ ជាជាងតួលេខដែលយើងអាចបញ្ជាក់ប្រឆាំងនឹង primary dataset ប៉ុន្តែទិសដៅគឺច្បាស់លាស់ និងស៊ីសង្វាក់គ្នាទូទាំងឧស្សាហកម្ម។) Code ច្រើនជាង PR ធំជាង review វែងជាង លទ្ធផលរាប។ ការបង្កើនល្បឿនពិត វាគ្រាន់តែគរឡើងប្រឆាំងនឹងផ្នែកតែមួយនៃ pipeline ដែល run តាមល្បឿនមនុស្ស។

នោះជាបញ្ហាមេកានិច៖ ប្រព័ន្ធដែលសាងសង់សម្រាប់ output ល្បឿនមនុស្សកំពុងត្រូវជន់លិចដោយ output ល្បឿនម៉ាស៊ីន។ Code review តែងតែជា governor ស្ងាត់លើល្បឿនដែលក្រុមអាចផ្លាស់ដោយសុវត្ថិភាព ឥឡូវការ generate បានរំលង governor នោះ ហើយ queue ជាកន្លែងដែលតម្លៃលេចឡើង។ ប៉ុន្តែមានបញ្ហាទីពីរនៅខាងក្រោម queue ដែលអាក្រក់ជាង ព្រោះវាមើលមិនឃើញ — វាមិនលេចជា delay ដែលអ្នកអាចវាស់ ប៉ុន្តែជា quality leak ដែលអ្នកមិនអាច។

ផ្នែកដែលគួរធ្វើឱ្យអ្នកព្រួយបារម្ភ៖ យើងចូលចិត្ត code អាក្រក់ជាង

Study ដែលបាន peer-review ឆ្នាំ ២០២៦ មួយ — More Code, Less Reuse (arXiv 2601.21276) ដែលបង្ហាញនៅសន្និសីទ MSR mining-software-repositories — បានហួសពី pass rate ដើម្បីមើលអ្វីដែល AI pull request ពិតជាធ្វើទៅ codebase និងរបៀបដែល reviewer ប្រតិកម្មចំពោះវា។ ការរកឃើញ objective គឺអ្វីដែលអ្នកនឹងភ័យ៖ “LLM Agents frequently disregard code reuse opportunities, resulting in higher levels of redundancy compared to human developers។” Agent ភ្ជាប់ code ថ្មីជាជាង reuse អ្វីដែលមាន ដូច្នេះការផ្លាស់ប្ដូរនីមួយៗផ្ទុក duplication ច្រើនជាង និងបន្ទុកថែទាំរយៈពេលវែងច្រើនជាងការផ្លាស់ប្ដូររបស់មនុស្សស្មើគ្នា។

នេះជាការបង្វិលដែលធ្វើឱ្យវាគ្រោះថ្នាក់។ Sentiment analysis របស់ study បានរកឃើញថា “reviewers tend to express more neutral or positive emotions towards AI-generated contributions than human ones។” អានការរកឃើញទាំងពីរនោះជាមួយគ្នា៖ AI code មាន redundancy និងផ្ទុក debt ច្រើនជាង objective ហើយ reviewer មានអារម្មណ៍ល្អជាងអំពីការអនុម័តវា។ អ្នកនិពន្ធដាក់ឈ្មោះយន្តការច្បាស់លាស់ — “the surface-level plausibility of AI code masks redundancy, leading to the silent accumulation of technical debt in real-world development environments។”

នោះជា review gate បរាជ័យតាមរបៀបអាក្រក់បំផុតដែលអាចកើតមាន៖ មិនមែនដោយយឺត ប៉ុន្តែដោយត្រូវ បោក។ Slop មិនត្រូវបានចាប់ ព្រោះវាមើលមិនដូច slop។

ហេតុអ្វីភាពទំនងឈ្នះ correctness នៅ gate

វាសមនឹងការត្រឹមត្រូវអំពីហេតុអ្វី reviewer ប្រុងប្រយ័ត្នអនុម័ត code អាក្រក់ជាងជាមួយមនសិការច្បាស់ជាង ព្រោះការបរាជ័យជារចនាសម្ព័ន្ធ មិនមែនជារឿងវិស្វករខ្ជិល។ Code ដែលបង្កើតដោយ AI គឺ fluent។ វា format ល្អ ដាក់ឈ្មោះតាម idiom comment ដោយជឿជាក់ និងស្អាតតាម syntax។ រាល់សញ្ញាលើផ្ទៃដែល reviewer ជាមនុស្សបានរៀនអានជា “អ្នកនិពន្ធនេះដឹងអ្វីដែលគេធ្វើ” មានវត្តមាន — ហើយគ្មានសញ្ញាមួយណានោះតាមដានរបស់ដែលពិតជាសំខាន់នៅទីនេះ៖ ថាតើការផ្លាស់ប្ដូរ reuse អ្វីដែលវាគួរ ថាតើវាបន្ថែមរបៀបទីបួនធ្វើអ្វីដែល codebase ធ្វើរួចហើយបីរបៀប ថាតើវាបានពង្រីក maintenance surface ស្ងាត់ៗ។

ដូច្នេះការត្រួតពិនិត្យរបស់ reviewer ចុះ ពិតពេលដែលវាគួរ ឡើង។ Human PR ដែលមើលទៅ scrappy និងឆ្គង អញ្ជើញសំណួរ AI PR ដែលរលោងអញ្ជើញ thumbs-up។

ស្រមៃករណីជាក់ស្ដែង។ Agent ត្រូវបានសុំឱ្យបន្ថែម date-formatting helper។ Codebase មានរួចហើយពីរ កប់ក្នុង utils module ដែល agent មិនដែលមើល។ Agent សរសេរទីបី — ស្អាត ដាក់ឈ្មោះល្អ ជាមួយ docstring រៀបរយ និង test ដែលជាប់។ Diff ជាការរីករាយក្នុងការអាន។ Reviewer ឃើញគ្មានអ្វីខុស ក្នុង diff អនុម័តវាក្នុងសាមសិបវិនាទី។ គ្មានអ្វីខុសក្នុង diff។ ភាពខុសនៅក្នុងអ្វីដែល diff មិនដឹង៖ ថា function នោះមិនគួរមាន។ គុណវានឹងរាល់ PR ទូទាំងក្រុមដែល merge pull request ច្រើនជាង 98% ជាងមុន ហើយអ្នកទទួលបានការគរ debt ស្ងាត់ដែល study ពិពណ៌នា — មិនមែនតាមរយៈការសម្រេចចិត្តអាក្រក់តែមួយណាមួយ ប៉ុន្តែតាមរយៈរាប់ពាន់ការសម្រេចចិត្តដែលទំនងតាមតំបន់ដែលគ្មាន review កម្រិត diff ណាមួយនឹងចាប់។ នេះជា root failure ដូចគ្នាដែលយើងបានសរសេរពីពីរមុំផ្សេង។ វាជាមូលហេតុដែល agent កាន់តែអាក្រក់ពេលវា run យូរ — redundancy ផ្សំ turn over turn — ហើយវាជាភស្តុតាងជាក់ស្ដែងនៃមូលហេតុដែល loop អាក្រក់ ship code អាក្រក់លឿនជាង៖ បង្កើនល្បឿន generation ទុក verification gate ឱ្យ intuition របស់មនុស្ស ហើយអ្នកមិនត្រឹមតែ ship លឿនជាង អ្នក ship អាក្រក់ ជាងលឿនជាង ដោយគ្រប់គ្នាមានអារម្មណ៍ល្អអំពីវា។

ការជួសជុល gate

បើបញ្ហាគឺថាភាពទំនងបោកការវិនិច្ឆ័យរបស់មនុស្ស ការជួសជុលគឺឈប់ពឹងលើការវិនិច្ឆ័យរបស់មនុស្សសម្រាប់របស់ដែលវាមិនពូកែ ហើយរក្សាវាសម្រាប់របស់ដែលវាពូកែ។ ជាក់ស្ដែង review gate ត្រូវតែក្លាយជា robust ចំពោះ surface polish៖

• Automate structural check។ Duplication detection, complexity metrics, dependency និង dead-code analysis, real test-coverage delta — redundancy ដែលបោក reviewer ជាមនុស្សពិតជាអ្វីដែល tool ចាប់បានដោយ deterministic។ ទាំងនេះគួរ run មុនពេល មនុស្សឃើញ PR ដូច្នេះមនុស្សមិនមែនជា line of defense ដំបូងប្រឆាំងនឹង slop។
• បង្ខំ PR តូច មាន scope។ PR ធំជាង 154% មិនអាច review បានក្នុងជម្រៅដូចគ្នា កាន់តែ diff ធំ កាន់តែភាពទំនងជំនួសការត្រួតពិនិត្យ។ ការ scope ការងារតូច — វិន័យដូចគ្នាដែលរក្សា harness ដែល run យូរពីការរលួយ — រក្សាការផ្លាស់ប្ដូរនីមួយៗ review បានពិតប្រាកដ។
• Review ប្រឆាំងនឹង code ដែលមាន មិនមែនត្រឹម diff។ ការបរាជ័យ reuse មើលមិនឃើញក្នុង diff ដាច់ដោយឡែក ហើយជាក់ច្បាស់ក្នុងបរិបទ។ ការងាររបស់ reviewer សម្រាប់ AI PR គឺតិចជា “តើ code នេះត្រឹមត្រូវទេ?” ហើយច្រើនជា “តើ code នេះគួរមានទេ ឬវា duplicate អ្វីដែលយើងមាន?”
• ធ្វើឱ្យ agent ដែល generate បង្ហាញ reuse។ រុញ check upstream៖ តម្រូវឱ្យ agent ស្វែងរក និងដកស្រង់ implementation ដែលមានមុនពេលសរសេររបស់ថ្មី និងធ្វើឱ្យ helper ថ្មីណាមួយមានហេតុផលប្រឆាំងនឹងអ្វីដែលមានរួចហើយ។ Slop ថោកបំផុតក្នុងការចាប់គឺ slop ដែលមិនដែលសរសេរ — generation loop ដែលត្រូវបានប្រាប់ឱ្យ reuse មុនផលិតតិចជាងច្រើនសម្រាប់ gate បដិសេធ។

គំនិតបង្រួប៖ verification gate មិនអាចជា vibe។ ពេលការ generate ល្បឿនម៉ាស៊ីន និងទំនងម៉ាស៊ីន gate ត្រូវតែធ្វើវិស្វកម្មជាមួយភាពម៉ត់ចត់ដូចគ្នានឹងការ generate — automate កន្លែងដែលអាច scope ឱ្យនៅ human-reviewable កន្លែងដែលមិនអាច ហើយ skeptical ច្បាស់លាស់ចំពោះ polish។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជា version មុតស្រួចបំផុតនៃអំណះអំណាងដែលយើងតែងតែធ្វើ។ ក្រុមដែលឈ្នះក្នុង agentic era នឹងមិនមែនជាក្រុមដែល generate code ច្រើនបំផុតទេ — ការ generate ជា commodity ឥឡូវនេះ មានសម្រាប់គ្រប់គ្នាក្នុងតម្លៃដូចគ្នា។ ពួកគេនឹងជាក្រុមដែលមាន verification discipline ល្អបំផុត៖ ការវិនិច្ឆ័យដើម្បីមិនជឿ diff ដែលទំនង ភាពម៉ត់ចត់ដើម្បី gate លើរចនាសម្ព័ន្ធជាជាង sentiment ការទប់ខ្លួនដើម្បីរក្សា PR តូច។ គ្មានមួយណានោះត្រូវការ GPU, frontier model, ឬដើមទុនទេ។ វាត្រូវការ engineering culture — ហើយ culture ជាអ្វីដែលក្រុមផ្ដោតអារម្មណ៍នៅភ្នំពេញ ឬ Da Nang អាចសាងសង់ដោយចេតនា លឿនជាង org ធំទូលាយដែលលង់ក្នុង AI PR ដែលអនុម័តស្វ័យប្រវត្តិអាចជួសជុល។

នេះជា loop-engineering discipline នៅចំណុចដែលវាផ្ដល់ផលដោយផ្ទាល់បំផុត។ ក្រុមតូចដែលចាត់ទុក review ជា gate ពិតប្រាកដ ធ្វើវិស្វកម្ម — ហើយបដិសេធមិនឱ្យភាពទំនងឈរជំនួស correctness — ផលិត codebase ស្អាតជាង ថែទាំបានជាងគូប្រកួតដែលមានមូលនិធិល្អជាង ដែល ship បរិមាណ slop ដែលអនុម័ត 2–5x។ ក្នុងពិភពលោកដែលគ្រប់គ្នាអាច generate ការប្រៀបធៀបធន់គឺការដឹងអ្វីដែល មិន ត្រូវ merge។ នោះជាជំនាញដែលត្រូវបានវាយតម្លៃទាបបំផុតក្នុង agentic stack ហើយវាជាជំនាញថោកបំផុតក្នុងការសាងសង់។