Spec-Driven Development៖ នៅពេលអ្នកកែ Spec មិនមែនកូដ

មានសំណួរមួយដែលអ្នកអភិវឌ្ឍគ្រប់រូបដែលធ្វើការជាមួយ agents ទីបំផុតប៉ះ៖ បើ agent សរសេរកូដ តើ ខ្ញុំ កំពុងសរសេរអ្វីពិតប្រាកដ? អស់រយៈពេលមួយឆ្នាំ ចម្លើយដ៏ស្មោះគឺ “prompts និងការកែតម្រូវជាច្រើន”។ ក្នុងឆ្នាំ ២០២៦ ចម្លើយច្បាស់ជាងបានលេចចេញ ហើយវាមានឈ្មោះ៖ spec-driven development។ អ្នកសរសេរការបញ្ជាក់ — ច្បាស់លាស់ គង់វង្ស គ្រប់គ្រងជា version — ហើយ agent បង្កើតកូដពីវា។ Artifact ដែលអ្នកជាម្ចាស់ផ្លាស់ឡើងមួយកម្រិត ពីការអនុវត្តទៅចេតនា។

នេះមិនមែនជាគំនិតចំហៀងទៀតទេ។ ជាមួយប្រហែល ៨៤% នៃអ្នកអភិវឌ្ឍប្រើឧបករណ៍ AI ហើយចំណែកធំនៃកូដថ្មីឥឡូវនេះបង្កើតដោយម៉ាស៊ីន វិន័យបានផ្លាស់ពីជម្រើសទៅជាការទ្រទ្រង់ទម្ងន់។ មូលហេតុជាការសង្កេតមុតស្រួចមួយ៖ “កូដដែលបង្កើតដោយ AI គឺសមហេតុផលដោយការសាងសង់ មិនមែនត្រឹមត្រូវដោយការសាងសង់ទេ។” វាចងក្រងបាន វាអានស្រួល វាឆ្លងកាត់ tests ច្បាស់ — ហើយវានៅតែអាចរអិលដោយស្ងាត់ៗចេញពីអ្វីដែលអ្នកពិតជាមានន័យ។ Spec គឺជារបៀបដែលអ្នកដៅ “អ្វីដែលអ្នកពិតជាមានន័យ” ក្នុងទម្រង់ដែលទាំងមនុស្ស និង agent អាចពិនិត្យធៀបបាន។

ដំណាក់កាលបី ដោយបញ្ចប់នៅកន្លែងរ៉ាឌីកាល់

ការដាក់ស៊ុមរបស់ Martin Fowler ជាផែនទីច្បាស់បំផុតនៃកន្លែងដែលរឿងនេះទៅ ជាគំរូភាពចាស់ទុំបីកម្រិត៖

• Spec-first — អ្នកសរសេរ spec សម្រាប់ភារកិច្ច ប្រើវាដើម្បីដឹកនាំ agent ហើយនៅពេលការងារ ship ហើយ spec ត្រូវបានបោះចោល។ Spec ជា scaffolding។ ក្រុមភាគច្រើនចាប់ផ្ដើមនៅទីនេះ។
• Spec-anchored — spec ក្លាយជា ឯកសាររស់ ដែលរក្សាឆ្លងកាត់អាយុកាលរបស់មុខងារ។ ការផ្លាស់ប្ដូរចាប់ផ្ដើមក្នុង spec ឯ agent បង្កើតកូដឡើងវិញឱ្យត្រូវគ្នា។ ឧបករណ៍ spec-driven ធ្ងន់ធ្ងរបំផុតតម្រង់ទៅកម្រិតនេះថ្ងៃនេះ។
• Spec-as-source — ចំណុចបញ្ចប់រ៉ាឌីកាល់៖ spec ជា artifact តែមួយគត់ ដែលមនុស្សកែ ហើយកូដក្លាយជា output បណ្ដោះអាសន្ន ចងក្រង ដែលគ្មានមនុស្សប៉ះដោយដៃ។ ប្រភពនៃការពិតរបស់ repository ផ្លាស់ឡើងមួយជាន់។

វាមានតម្លៃក្នុងការពិចារណាថា spec-as-source ចម្លែកប៉ុណ្ណា។ យើងបានចំណាយរាប់ទសវត្សរ៍ចាត់ទុក source code ជា artifact នោះ — របស់ក្រោម version control របស់ដែលយើងពិនិត្យ របស់ដែលយើងជាម្ចាស់។ Spec-as-source បន្ទាបកូដទៅឋានៈ build output ដូច binary ដែលចងក្រង។ អ្នកនឹងមិនកែ executable ដោយដៃ ក្នុងចក្ខុវិស័យនេះ អ្នកក៏មិនកែកូដដែលបង្កើតដោយដៃដែរ។ អ្នកកែ spec ហើយចងក្រងឡើងវិញ។

Spec ជាឥទ្ធិពល

នេះផ្គូផ្គងលើអ្វីដែលយើងបានសរសេរក្នុង វង់តន្ត្រី Code Agent៖ នៅពេលអ្នកដឹកនាំក្រុម agent spec របស់អ្នកជាឥទ្ធិពល — ហើយ spec មិនច្បាស់មិនគ្រាន់តែធ្វើឱ្យអ្នកយឺត វា គុណ ឆ្លងកាត់រាល់ agent ដែលធ្វើសកម្មភាពលើវា។ Spec-driven development គឺការយល់ដឹងនោះប្រែទៅជា workflow។ Loop ស្តង់ដារជាបួនដំណាក់កាល៖ specify (បញ្ជាក់) អ្វីដែលសូហ្វវែរគួរធ្វើ plan (រៀបផែនការ) របៀបសាងសង់ implement (អនុវត្ត) ជាការបន្ថែមដែលផ្ទៀងផ្ទាត់ validate (ធ្វើសុពលកម្ម) ថាកូដត្រូវនឹង spec។ ដំណាក់កាលនីមួយៗផលិត artifact ដែលកំណត់ដំណាក់កាលបន្ទាប់ ដូច្នេះកំហុសមានកន្លែងលាក់ខ្លួនតិចជាង។

ហើយសំខាន់ spec ឈប់ជាឯកសារដែលអ្នកសរសេរម្ដង ហើយទុក។ វាក្លាយជា កិច្ចព្រមព្រៀងប្រតិបត្តិការរស់ដែល agent អានរាល់ការដំណើរការ — តួនាទីដូចគ្នាដែលយើងបានពណ៌នាសម្រាប់ AGENTS.md ដែលរៀបចំដោយមនុស្ស។ Frameworks ឈានមុខធ្វើឱ្យវាច្បាស់៖ Spec Kit របស់ GitHub រក្សា constitution.md នៃគោលការណ៍មិនអាចចរចារដែលអង្គុយខាងលើរាល់ spec; OpenSpec រៀបចំការងារទៅជា change folders នៃសំណើ specs និងភារកិច្ច; BMAD ផ្ដល់ personas ដែលមានឈ្មោះជាមួយច្បាប់ domain ផ្ទាល់ខ្លួន។ រូបរាងផ្សេងគ្នា គំនិតមួយ៖ spec ជា artifact គង់វង្ស គ្រប់គ្រង ឯកូដនៅខាងក្រោមវា។

ការរិះគន់ដែលគួរយកមកពិចារណាយ៉ាងម៉ត់ចត់

វានឹងមិនស្មោះក្នុងការលក់រឿងនេះថាបានដោះស្រាយ។ ការរុញច្រានមុតស្រួចបំផុតមកពី Matt Pocock ហើយវាសមនឹងការស្ដាប់ដោយយុត្តិធម៌៖ ដោយការដឹកនាំអ្វីៗគ្រប់យ៉ាងឆ្លងកាត់ “specs ទៅកូដ” គាត់អះអាងថា “យើងមិនកំពុងវិនិយោគលើការរចនាប្រព័ន្ធទេ។ យើងកំពុងដកការវិនិយោគចេញពីវា។” ការព្រួយបារម្ភគឺថា spec ស្អាតអាចបិទបាំងអវត្តមាននៃការគិតស្ថាបត្យកម្មពិតប្រាកដ — ថាអ្នកអាចបង្កើតកូដសមហេតុផលជាច្រើនពី spec ខណៈការរចនាមូលដ្ឋានរលួយដោយស្ងាត់ៗ។

ទិន្នន័យផ្ដល់ធ្មេញដល់ការរិះគន់។ អ្នកអភិវឌ្ឍមានបទពិសោធន៍ធ្វើការលើ codebases ចាស់ទុំត្រូវបានវាស់ថា ~១៩% យឺតជាង ជាមួយជំនួយ AI ដែលបង្ហាញថាលើប្រព័ន្ធពិតប្រាកដ គុណភាព codebase និងវិន័យរចនាសំខាន់ជាងភាពរលោងនៃការបញ្ជាក់។ Spec មិនមែនជាការជំនួសសម្រាប់គំរូផ្លូវចិត្តរួម ស្ថាបត្យកម្មស្អាត ឬរសជាតិដើម្បីដឹងថាអ្វី មិន ត្រូវសាងសង់។ ការអានត្រឹមត្រូវមិនមែន “specs ជំនួសការរចនា” — វាជា “specs ជាកន្លែងដែលការរចនាត្រូវបានសរសេរចុះ ដូច្នេះ agents មិនអាចរអិលចេញ”។ Spec ដែលគ្មានការរចនាពិតប្រាកដនៅពីក្រោយ គ្រាន់តែឱ្យអ្នក ship របស់ខុសលឿនជាង ដែលជា បញ្ហា loop អាក្រក់ មួយកម្រិតខាងលើ។

ហេតុអ្វីនេះជាការភ្នាល់ត្រឹមត្រូវសម្រាប់អាស៊ីអាគ្នេយ៍

នេះជាកន្លែងដែលវាធ្លាក់ចុះសម្រាប់តំបន់ ហើយវាជាកន្លែងដូចគ្នាដែលតក្កយើងតែងតែធ្លាក់ចុះ។ Spec-driven development ផ្លាស់ទីការងារដ៏មានតម្លៃ គង់វង្ស ទៅ ការសរសេរចុះថាអ្វីដែលត្រឹមត្រូវមានន័យ — ហើយនោះជាចំណេះដឹង domain និងការគិតច្បាស់លាស់ មិនមែនការចំណាយ GPU ទេ។

Agent ទូទៅអាចបង្កើតកូដសមហេតុផលពេញមួយថ្ងៃ។ អ្វីដែលវាមិនអាចធ្វើគឺដឹងថា payroll កម្ពុជាត្រូវដោះស្រាយច្បាប់ប្រាក់រង្វាន់អតីតភាពជាក់លាក់ ឬថាទម្រង់ភាសាខ្មែរមាន field ដែល template បរទេសលុបចោល ឬរបៀបដែលសហករណ៍ក្នុងស្រុកពិតជាកត់ត្រាការប្រមូលផល។ ការដាក់បញ្ចូលច្បាប់ទាំងនោះទៅក្នុង spec រស់ គឺជារបៀបដែលចំណេះដឹងក្នុងស្រុកក្លាយជា IP គង់វង្ស អាចកាន់កាប់បាន — spec ជាទម្រង់ដែលអាចចល័ត និងជាប់បានបំផុតដែលចំណេះដឹងនោះអាចយក។ Frontier lab នឹងបង្កើតកូដពី spec របស់អ្នកក្នុងតម្លៃប៉ុន្មានកាក់។ វានឹងមិនដែលសរសេរ spec ព្រោះវាមិនស្គាល់ domain របស់អ្នក។ ភាពមិនស្មើគ្នានោះជាកៅអីនៅតុ ហើយវាជាកៅអីសរសេរ-និង-គិត ដែលពិតជាប្រភេទ ដែលយើងតែងតែអះអាងថាតំបន់គួរយក។

អ្វីដែលត្រូវយកពីរឿងនេះ

ចាប់ផ្ដើមចាត់ទុក spec ជា artifact ថ្នាក់ទីមួយ មិនមែន prompt បោះចោល។ ផ្លាស់ពី spec-first ទៅ spec-anchored៖ រក្សា spec ឱ្យរស់ ផ្លាស់ប្ដូរវាមុនពេលអ្នកផ្លាស់ប្ដូរកូដ ឱ្យ agent បង្កើតឡើងវិញ។ វិនិយោគកិច្ចខិតខំពិតប្រាកដរបស់អ្នកលើការរចនា នៅពីក្រោយ spec — ព្រោះ spec ល្អត្រឹមតែការគិតដែលវាចាប់យក។ ហើយដាក់បញ្ចូលច្បាប់ដែលលំបាកទទួលបានរបស់ domain អ្នកទៅក្នុង specs និង skills ដែល agent អានរាល់ការដំណើរការ ព្រោះនោះជាកន្លែងដែលគុណសម្បត្តិរបស់អ្នកប្រមូលផ្ដុំ។

Agent សរសេរកូដឥឡូវនេះ។ ការងាររបស់អ្នកគឺសរសេរ — ហើយបន្តសរសេរ — អ្វីដែលកូដគួរតែជា។ កែ spec មិនមែនកូដ។