Coding Agent មិនត្រឹមតែបរាជ័យទេ — វា Rot៖ លទ្ធផល SlopCodeBench

នេះជាលេខដែលគួរកំណត់ឡើងវិញនូវរបៀបដែលអ្នកគិតអំពី coding agent ដែលដំណើរការយូរ៖ ឆ្លងកាត់ model ១១ និង checkpoint ៩៣ គ្មាន agent ណាដោះស្រាយបញ្ហាតែមួយ end-to-end ហើយ checkpoint solve rate ល្អបំផុតគឺ 17.2%។ ហើយនេះជាលេខដែលពន្យល់ថា ហេតុអ្វី៖ កូដដែល agent សរសេរមាន ពាក្យច្រើនជាង 2.2x ជាងកូដ open-source ដែលមនុស្សដឹកចេញពិតប្រាកដ។ ការផ្គូផ្គងនោះ — agent ដែលមិនអាចបញ្ចប់ ផលិតកូដដែលហើមតាមផ្លូវ — ជាបេះដូងនៃ SlopCodeBench (Orlanski et al., arXiv 2603.24755, ខែមីនា ២០២៦) ហើយវាដាក់ទិន្នន័យរឹងមាំក្រោមនិក្ខេបបទដែលយើងបានអះអាងជាគុណភាពមួយរយៈ។

យើងបានសរសេរពីមុនអំពីរបៀបដែល agent កាន់តែអាក្រក់ ពេលវាដំណើរការកាន់តែយូរ។ អត្ថបទនោះពិពណ៌នា ឥរិយាបថ។ SlopCodeBench ផ្ដល់ឱ្យយើងនូវ យន្តការ — វាស់ស្ទង់ ធ្វើឡើងវិញបាន និងជាក់លាក់គួរឱ្យមិនស្រួល។ Coding agent មិនត្រឹមតែបរាជ័យទេ។ វា rot កូដនៅខាងក្រោមខ្លួនវា ម្ដងមួយវេន ហើយ rot នោះភាគច្រើនមើលមិនឃើញរហូតដល់អ្នកអាន diff។

ការពិសោធ៖ ធ្វើឱ្យ agent រស់នៅជាមួយកូដផ្ទាល់របស់វា

ការវាស់ស្ទង់ coding ភាគច្រើនជា one-shot។ បញ្ហាមកដល់ agent បញ្ចេញដំណោះស្រាយ អ្នកដាក់ពិន្ទុ អ្នកបន្តទៅមុខ។ ការរចនានោះមិនអាចមើលឃើញ rot បានទេ ព្រោះ rot ជា function នៃ ពេលវេលា — នៃ agent ដែលទទួលមរតក និងពង្រីកការសម្រេចចិត្តដំបូងផ្ទាល់របស់វា។

SlopCodeBench សាងសង់ឡើងដើម្បីបង្ហាញរឿងនោះច្បាស់។ វាយក បញ្ហា 20 problems ហើយប្រែក្លាយនីមួយៗទៅជាខ្សែ specification ដែលវិវត្ត៖ agent សរសេរកូដ បន្ទាប់មក spec ផ្លាស់ប្ដូរ ហើយ agent ត្រូវ ពង្រីកដំណោះស្រាយដំបូងផ្ទាល់របស់វា ជាជាងចាប់ផ្ដើមស្រស់។ ឆ្លងកាត់បញ្ហាទាំងនោះ ការវាស់ស្ទង់កំណត់ 93 checkpoints ហើយវាដំណើរការ 11 models ឆ្លងកាត់ការប្រកួតទាំងមូល។ សំខាន់ រចនាសម្ព័ន្ធខាងក្នុងនៃកូដត្រូវបានទុកទាំងស្រុងឱ្យ agent — គ្មានអ្វីក្នុង harness បង្ខំស្ថាបត្យកម្មស្អាត ដូច្នេះការវាស់ស្ទង់អាចមើល agent ផ្លូវកាត់ដំបូងកកកុញទៅជាការរញ៉េរញ៉ៃក្រោយៗ។

អ្វីដែលវារកឃើញជាការចោទប្រកាន់ពីរផ្នែក៖

Agent មិនអាចបញ្ចប់ពិតប្រាកដ។ គ្មាន model ណាដោះស្រាយបញ្ហាណាមួយឆ្លងកាត់ spec វិវត្តរបស់វាពេញលេញ។ Checkpoint solve rate ល្អបំផុតតែមួយ ឆ្លងកាត់ model ទាំង 11 គឺ 17.2%។ ទាំងនេះមិនមែនជាបញ្ហា edge-case ទេ ពួកវាជាភារកិច្ច iterative ទ្រទ្រង់ ប្រភេទពិតប្រាកដដែលការងារ software ពិតធ្វើពី។
កូដ decay តាមផ្លូវ។ SlopCodeBench តាមដាន decay សញ្ញាពីរផ្សេងគ្នា — ការសឹករិចរិលរចនាសម្ព័ន្ធ (ភាពស្មុគស្មាញកកកុញនៅកន្លែងខុស) និង ភាពច្រើនពាក្យ (កូដច្រំដែល ហើម)។ ការសឹករិចរិលរចនាសម្ព័ន្ធកើនឡើងឆ្លងកាត់ run ក្នុង 80% នៃគន្លង។ ភាពច្រើនពាក្យកើនឡើងក្នុង 89.8%។ វាស់ប្រៀបធៀបនឹង repository open-source ពិតប្រាកដ កូដ agent ចេញមក ពាក្យច្រើនជាង 2.2x។

ការគ្រប់គ្រងគឺជាអ្វីដែលធ្វើឱ្យវាគួរបន្ទោស។ ពេលអ្នកនិពន្ធមើលរបៀបដែលកូដ មនុស្ស វិវត្តឆ្លងកាត់ប្រវត្តិកំណែផ្ទាល់របស់វា វាស្ថិតនៅរាបស្មើជាមូលដ្ឋាន — មនុស្ស refactor កាត់ផ្ដាច់ និងរក្សាភាពស្មុគស្មាញឱ្យនឹងនរប្រហែលៗ ពេលគម្រោងធំឡើង។ កូដ agent ធ្វើផ្ទុយ។ រាល់វេនបន្ថែមលើសពីដែលគួរ លើគ្រឹះដែលរាល់វេនមុនបានសឹករិចរិលរួចហើយ។ Agent ឆ្លងកាត់ checkpoint ហើយ degrade codebase ក្នុងចលនាដូចគ្នា។

នោះជានិយមន័យនៃ rot៖ មិនមែនការបរាជ័យមហន្តរាយតែមួយទេ ប៉ុន្តែការធ្លាក់ចុះ monotonic ដែលរាល់ជំហានឯករាជ្យអាចសម្រួលហេតុផល។

ហេតុអ្វី rot គុណជំនួសឱ្យការមធ្យម

បើការបរាជ័យឯករាជ្យ អ្នកអាចវែកញែកវាដោយប្រូបាប៊ីលីតេធម្មតា — ដំណើរការច្រើនជាង ព្យាយាមឡើងវិញអ្នកអាក្រក់ រំពឹងថាច្បាប់នៃលេខធំជួយសង្គ្រោះអ្នក។ ការស្រាវជ្រាវដៃគូថា សភាវគតិនោះខុស។

ភាពជឿជាក់ជាគុណភាពពីរវិមាត្រ (Khanal et al., arXiv 2603.29231, ខែមីនា ២០២៦) វាស់ model 10 ឆ្លងកាត់ task-duration bucket បួន ហើយរកឃើញ pass@1 សរុបធ្លាក់ពី 76.3% លើភារកិច្ច short-horizon ទៅ 52.1% លើភារកិច្ចវែងខ្លាំង — ការធ្លាក់ចុះ 24.3 ពិន្ទុ។ រូបរាងនៃការធ្លាក់នោះជាផ្នែកសំខាន់៖ វា super-linear ប្រៀបធៀបនឹង baseline i.i.d. Bernoulli ដែលអ្នកនឹងទទួលបាន បើរាល់ជំហានបរាជ័យឯករាជ្យ។ ជាពាក្យសាមញ្ញ ការបរាជ័យ correlate។ ការសម្រេចចិត្តអាក្រក់មួយលើកឱកាសនៃរបស់បន្ទាប់។ Agent ដែលវែកញែកលើ codebase ដែលវេនដំបូងរបស់វាធ្វើឱ្យពិបាកវែកញែកជាង គឺ ទំនងជាង ធ្វើឱ្យវេនបន្ទាប់អាក្រក់ មិនមែនទំនងស្មើគ្នាទេ។

នេះជាហេតុអ្វីគណិតវិទ្យា retry សាមញ្ញ undercount ហានិភ័យ ហើយវាជាឆ្អឹងខ្នងបរិមាណវិស័យនៃអ្វីដែលយើងហៅថា គម្លាតភាពជឿជាក់៖ metric per-step ដែលវាស់លើភារកិច្ចខ្លី កុហកជាប្រព័ន្ធអំពីឥរិយាបថ long-horizon ព្រោះវាសន្មតភាពឯករាជ្យដែលទិន្នន័យបដិសេធមិនផ្ដល់។ Rot មិនមែនជាសំឡេងរំខានដែលអ្នកអាចមធ្យមឱ្យបាត់ទេ។ វាជានិន្នាការ ហើយនិន្នាការចង្អុលចុះក្រោម។

ការរក កន្លែង ដែល loop ខូចផ្លូវ

ការដឹងថា run វែង rot ជារឿងមួយ ការកំណត់ទីតាំងវេនដែល rot ចូលគឺមួយផ្សេង — ហើយអ្នកមិនអាចជួសជុលអ្វីដែលអ្នកមិនអាចបញ្ជាក់ប្រភពបាន។ នោះជាការរួមចំណែករបស់ HORIZON (Wang et al., arXiv 2604.11978, ខែមេសា ២០២៦) ការវាស់ស្ទង់វិនិច្ឆ័យឆ្លងដែន ផ្គូផ្គងជាមួយ pipeline LLM-as-a-Judge ដែលចាក់គ្រឹះលើ trajectory សម្រាប់ ការបញ្ជាក់ប្រភពការបរាជ័យ ជាជាងការដាក់ពិន្ទុ pass/fail ធម្មតា។

សាងសង់លើ trajectory 3,100+ ឆ្លងកាត់ដែន agentic បួន judge របស់ HORIZON ត្រូវបាន human-validated ឈានដល់ κ = 0.84 ការព្រមព្រៀងជាមួយ annotator មនុស្ស (ធៀបនឹង inter-annotator κ 0.61 — machine judge ព្រមព្រៀងជាមួយមនុស្សច្រើនជាងមនុស្សព្រមព្រៀងគ្នាទៅវិញទៅមក)។ វាបញ្ជាក់រូបរាងដែលធ្លាប់ស្គាល់ — agent គ្រប់គ្រងភារកិច្ច short និង mid-horizon បានល្អ បន្ទាប់មកដួលរលំលើ long-horizon — ប៉ុន្តែតម្លៃពិតរបស់វាគឺការប្រែការដួលរលំនោះទៅជាអ្វីដែល វិនិច្ឆ័យបាន។ ជំនួសឱ្យ “run បរាជ័យ” អ្នកទទួល “run ខូចផ្លូវនៅជំហាននេះ ក្នុងរបៀបនេះ”។

នោះកំណត់ការវាយតម្លៃឡើងវិញពីពិន្ទុទៅជាឧបករណ៍។ យើងបានអះអាងក្នុង អ្នកណាវិនិច្ឆ័យអ្នកវិនិច្ឆ័យ ថា LLM evaluator ខ្លួនវាជាសមាសភាគ loop ដែលអ្នកត្រូវផ្ទៀងផ្ទាត់ មិនមែន oracle អព្យាក្រឹតទេ។ HORIZON ជាគំនិតនោះចង្អុលទៅ trajectory៖ judge ដែលផ្ទៀងផ្ទាត់ ដែលកំណត់ទីតាំង rot ខាងក្នុង run គឺជាភាពខុសគ្នារវាងការដឹងថា agent របស់អ្នក decay និងការដឹង វេនណា ចាប់ផ្ដើម decay — ដែលជាចំណេះតែមួយដែលអ្នកអាចធ្វើសកម្មភាពពិតប្រាកដ។

ហេតុអ្វីនេះប៉ះអាស៊ីអាគ្នេយ៍ខុសគ្នា

ក្នុង org វិស្វកម្មធំ មានបុគ្គលិកគ្រប់គ្រាន់ code rot មាន backstop ធ្វើពីមនុស្ស៖ reviewer ជាន់ខ្ពស់ QA ឧទ្ទិស ភាពធូររលុងក្នុងការបោះវិស្វករពីរបីនាក់ទៅ refactor ពេល module ក្លាយជាអាក្រក់។ Rot នៅតែចំណាយអ្នក ប៉ុន្តែ bench ស៊ីជម្រៅស្រូបវា។

ក្រុមពីរ ឬប្រាំនាក់នៅភ្នំពេញ ឬ Da Nang មិនមាន bench នោះទេ។ គ្មាន reviewer រង់ចាំខាងក្រោមដើម្បីចាប់ slop វេនទីម្ភៃរបស់ agent មុនវាចុះ។ សម្រាប់ក្រុមដែលមានដើមទុនស្រាល rot របស់ agent ចុះ ត្រង់ៗ ក្នុងផលិតផល ហើយវិស្វករដែលត្រូវរស់នៅជាមួយវាគឺជាមនុស្សដូចគ្នាដែលដឹកវាចេញ។ នោះស្ដាប់ទៅដូចជាគុណវិបត្តិ — ហើយវានឹងជា បើដំណោះស្រាយតែមួយគឺ headcount ច្រើនជាង។

ប៉ុន្តែដំណោះស្រាយមិនមែន headcount ទេ។ វាជា ការរចនា loop ហើយការរចនា loop ដំណើរការលើ laptop។ ក្រុមដែលធ្វើលទ្ធផល SlopCodeBench ឱ្យក្លាយជារបស់ខ្លួន ឈប់ចង្អុល frontier agent ទៅភារកិច្ចធំ ហើយឱ្យវាដំណើរការច្រើនម៉ោង — របបពិតប្រាកដដែល rot អាក្រក់បំផុត និងវិក្កយបត្រ token ខ្ពស់បំផុត។ ផ្ទុយទៅវិញ វាវិស្វកម្ម loop ដូច្នេះ rot មិនដែលទទួលជើងទម្រ។ នោះមិនមែនជាចលនាថវិកាធំជាង វាជាចលនាការវិនិច្ឆ័យល្អជាង ហើយការវិនិច្ឆ័យជា input តែមួយដែលក្រុមតូចអាចប្រកួតប្រជែងឈ្នះពិតប្រាកដ។

Parameter loop ដែលបញ្ឈប់ rot

SlopCodeBench សាកល្បងការជួសជុលពាក្យសំដីច្បាស់ — ប្រាប់ agent ឱ្យសរសេរកូដស្អាត — ហើយរកឃើញថាវាកែលម្អ ចំណុចចាប់ផ្ដើម ដោយមិនផ្លាស់ប្ដូរ អត្រា decay។ Prompt ធ្វើឱ្យវេនទីមួយរៀបរយជាង វាមិនធ្វើអ្វីចំពោះជម្រាល។ ការប្រឆាំងដែលដំណើរការគឺរចនាសម្ព័ន្ធ ហើយវាផ្គូផ្គងស្អាតទៅនឹង checkpoint ក្នុង model ភាពចាស់ទុំនៃវិស្វកម្ម loop របស់យើង៖

Token budget ជាមួយលក្ខណៈ kill រឹង។ កំណត់ពិដាន per unit នៃការងារ និងដែនកំណត់ max-iteration ហើយ អនុវត្ត វា។ ព្រោះការបរាជ័យ correlate super-linear វេន marginal ស៊ីជម្រៅក្នុង run វែងគឺទំនងជាង rot — ដូច្នេះ run ដែលកំពុងតស៊ូរួចហើយ គឺពិតប្រាកដជា run ដែលត្រូវបញ្ឈប់ មិនមែនពង្រីក។ លក្ខណៈ kill (“ផ្ដល់ឱ្យឡើងវិញបន្ទាប់ពី N iteration ជាប់គាំង”) ជា circuit-breaker rot។
Checkpoint reset / refactor តាមកាល។ ខ្សែកោង decay ជា function នៃចំនួនវេនដែលជិះលើគ្រឹះសឹករិចរិលដដែល។ បញ្ចូលវេន refactor ច្បាស់ដែលការងារតែមួយរបស់វាគឺកាត់បន្ថយការសឹករិចរិលរចនាសម្ព័ន្ធ និងភាពច្រើនពាក្យ ហើយ reset context window រវាងឯកតាដែលកំណត់វិសាលភាព ដូច្នេះ state គង់វង្សរស់នៅក្នុង artifact ដែលបាន commit មិនមែនក្នុងប្រតិចារិកដែលរីកធំជានិច្ច។ Window ស្រស់បដិសេធ rot នូវកន្លែងកកកុញ។
កំណត់វិសាលភាពតូច ផ្ទៀងផ្ទាត់ខ្លាំង commit ស្អាត។ បំបែកការងារ ដូច្នេះឯកតានីមួយៗចាប់ផ្ដើមពី baseline ស្អាត ជាជាងទទួលមរតក slop ម្ភៃវេន ផ្ទៀងផ្ទាត់ឯកតានីមួយៗ end-to-end ហើយ commit state ដែលដំណើរការ ដូច្នេះ branch ដែល rot អាចបោះបង់ ជាជាងពង្រីក។ នេះជាវិន័យ feature មួយក្នុងពេលតែមួយ ដែលយើងតែងតែត្រឡប់មកវិញ — ហើយ SlopCodeBench ជាទិន្នន័យដែលពន្យល់ហេតុអ្វីវាដំណើរការ។
Instrument សម្រាប់ការបញ្ជាក់ប្រភព មិនមែនត្រឹម pass/fail។ ខ្ចីឥរិយាបថរបស់ HORIZON៖ តាមដាន កន្លែង ដែល trajectory ខូចផ្លូវ ដូច្នេះលក្ខណៈ kill និង checkpoint refactor របស់អ្នកចុះកន្លែងដែល rot ចាប់ផ្ដើមពិតប្រាកដ ជាជាងកន្លែងដែលអ្នកស្មាន។

ចំណុចរួបរួមគឺចំណុចដែលការស្រាវជ្រាវទាំងមូលនេះបន្តបញ្ជាក់៖ degradation ជាគុណភាពនៃរូបរាងរបស់ loop មិនមែន IQ របស់ model ទេ។ Frontier model ក្នុង run វែងស្មោកគ្រោកនឹង rot ការងារផ្ទាល់របស់វា។ Model មធ្យមក្នុង loop ដែលកំណត់វិសាលភាពតឹង budget ម៉ឺងម៉ាត់ reset ញឹកញាប់ និងបញ្ជាក់ប្រភពការបរាជ័យរបស់វា នឹងរក្សាគុណភាពយូរជាងច្រើន — សម្រាប់ token តិចជាង។ Lab នឹងបន្តដឹក agent ដែល អាច ដំណើរការយូរជាង។ វិន័យក្នុងការដំណើរការពួកវា ឱ្យបានល្អ ជាផ្នែកដែលគ្មានការចេញ model ណាធ្វើឱ្យលែងប្រើ ហើយវាមានសម្រាប់នរណាម្នាក់ដែលសុខចិត្តរចនា loop ជាជាងទុកចិត្ត run។