អ្នកអភិវឌ្ឍន៍បើក IDE ពិពណ៌នាអំពីអ្វីដែលពួកគេចង់បានជាភាសាអង់គ្លេសសាមញ្ញ ហើយមើលភ្នាក់ងារ AI សរសេរមុខងារក្នុងរយៈពេលដែលត្រូវការដើម្បីទទួលបានកាហ្វេ។ វាចងក្រង។ វាឆ្លងកាត់ការចុចដោយដៃ។ វាដឹកជញ្ជូន។ គ្មាននរណាម្នាក់សួរថាតើវាមានសុវត្ថិភាពឬអត់ទេ ព្រោះគ្មាននរណាម្នាក់សួរអ្វីច្រើនទេ។ ប្រអប់បញ្ចូលបានជំនួស pull requestហើយពាក្យថា "វាដំណើរការ" បានជំនួសពាក្យថា "ខ្ញុំបានពិនិត្យវាឡើងវិញ"។ នោះគឺជាការសរសេរកូដ vibe ហើយវាលែងជាទម្លាប់គ្មានមូលដ្ឋានទៀតហើយ។ វាគឺជារបៀបដែលចំណែកកូដផលិតកម្មកាន់តែច្រើនឡើងត្រូវបានសរសេរដោយក្រុមអ្នកជំនាញ មិនមែនគ្រាន់តែអ្នកចូលចិត្តពិសោធន៍ជាមួយកម្មវិធីចុងសប្តាហ៍នោះទេ។ ហើយវាជាមូលហេតុដែលសន្តិសុខសរសេរកូដ vibe បានក្លាយជាការសន្ទនាដែលអ្នកដឹកនាំផ្នែកវិស្វកម្ម និងសន្តិសុខគ្រប់រូបកំពុងមាន មិនថាពួកគេបានដាក់ឈ្មោះវារួចហើយឬនៅ។
តើ "vibe coding" មានន័យយ៉ាងណា?
ការសរសេរកូដ Vibe គឺជាការអភិវឌ្ឍកម្មវិធីដែលមនុស្សម្នាក់ពិពណ៌នាអំពីលទ្ធផលដែលចង់បានជាភាសាធម្មជាតិ ហើយគំរូ AI ឬភ្នាក់ងារដែលបង្កើតឡើងនៅលើវា បង្កើតកូដដំណើរការ។ មនុស្សម្នាក់ដឹកនាំដោយលទ្ធផល ("បង្កើត login flow,” “បន្ថែមការនាំចេញ CSV”) ជាជាងការសរសេរ ឬការពិនិត្យមើលការអនុវត្តជាជួរៗ។ ពាក្យនេះទទួលបានការចាប់អារម្មណ៍ពីព្រោះវាចាប់យកអ្វីដែលពិតប្រាកដ៖ អ្នកអភិវឌ្ឍន៍កំពុងមានអារម្មណ៍ថាលទ្ធផលគឺត្រឹមត្រូវ មិនមែនអានកូដខ្លួនឯងនោះទេ។
ការផ្លាស់ប្តូរនោះគឺជារឿងរ៉ាវទាំងមូល។ ការពិនិត្យឡើងវិញនូវកូដធ្លាប់ជាចំណុចត្រួតពិនិត្យដែលបង្កើតឡើងនៅក្នុងរបៀបដែលកម្មវិធីត្រូវបានសរសេរ។ ការសរសេរកូដ Vibe ដឹកនាំវាដោយការរចនា។ ល្បឿនកើនឡើង។ ទម្លាប់នៃការសួរថា "តើវាពិតជាធ្វើអ្វី" បានថយចុះ។
ហេតុអ្វីបានជាពាក្យថា "វាដំណើរការ" ជារបារខុស
«វាដំណើរការ» មានន័យថា កូដបានធ្វើអ្វីដែលត្រូវបានសួរ នៅក្នុងសេណារីយ៉ូដែលត្រូវបានសាកល្បង។ វាមិននិយាយអ្វីទាំងអស់អំពីអ្វីដែលកូដធ្វើនៅក្នុងសេណារីយ៉ូដែលគ្មាននរណាម្នាក់សួរអំពី៖ ការបញ្ចូលមិនត្រឹមត្រូវ អ្នកប្រើប្រាស់ដែលមានការផ្ទៀងផ្ទាត់កំពុងស៊ើបអង្កេតចំណុចបញ្ចប់ដែលទុកចិត្តពួកគេច្រើនពេក ការពឹងផ្អែកដែលមិនដែលត្រូវបានត្រួតពិនិត្យ អាថ៌កំបាំងដែលបានអ៊ិនកូដរឹងដែលស្ថិតនៅកន្លែងដែលអាចមើលឃើញយ៉ាងច្បាស់។ នេះជាកន្លែងដែលសុវត្ថិភាពនៃការសរសេរកូដ vibe ខូចមុនពេលនរណាម្នាក់កត់សម្គាល់ថាមានបញ្ហា។
គំរូសរសេរកូដ AI ត្រូវបានបណ្តុះបណ្តាលដើម្បីបង្កើតទិន្នផលមុខងារដែលត្រូវនឹងចេតនានៃប្រអប់បញ្ចូល។ សុវត្ថិភាពមិនមែនជាមុខងារគោលបំណងទេ។ គំរូដែលធ្វើឱ្យប្រសើរឡើងសម្រាប់ "នេះបំពេញតាមសំណើ" នឹងបង្កើតសំណួរដែលបង្កើតឡើងដោយការភ្ជាប់ខ្សែអក្សរជំនួសឱ្យប៉ារ៉ាម៉ែត្រ ចំណុចបញ្ចប់ដែលគ្មានការគ្រប់គ្រងការចូលប្រើ ពីព្រោះប្រអប់បញ្ចូលមិនដែលនិយាយថាអ្នកណាមិនគួរមានសិទ្ធិចូលប្រើ ឬការហៅ API ដែលទុកចិត្តលើការឆ្លើយតបដែលវាគួរតែផ្ទៀងផ្ទាត់។ វាចងក្រង។ វាដំណើរការ។ វាក៏ណែនាំថ្នាក់ងាយរងគ្រោះដូចគ្នាដែលក្រុម AppSec បានចំណាយពេលមួយទសវត្សរ៍ក្នុងការបណ្តុះបណ្តាលអ្នកអភិវឌ្ឍន៍ ដែលបង្កើតឡើងក្នុងល្បឿនដែលគ្មានដំណើរការពិនិត្យដោយដៃត្រូវបានបង្កើតឡើងដើម្បីផ្គូផ្គង។
ការស្រាវជ្រាវផ្ទៃក្នុងលើកូដដែលបង្កើតឡើងដោយ AI ដាក់ចំនួនពិតប្រាកដនៅពីក្រោយវិចារណញាណ៖ ចំណែកដ៏មានអត្ថន័យនៃអ្វីដែលឧបករណ៍សរសេរកូដភ្នាក់ងារផលិតមានចំណុចខ្វះខាតសុវត្ថិភាពដែលអាចកេងប្រវ័ញ្ចបាននៅលើការឆ្លងកាត់លើកដំបូង មុនពេលការពិនិត្យឡើងវិញណាមួយកើតឡើងទាល់តែសោះ។ នោះមិនមែនជាចំណុចខ្វះខាតនៅក្នុងគំរូមួយនោះទេ។ វាគឺជាលទ្ធផលដែលរំពឹងទុកនៃការបង្កើនប្រសិទ្ធភាពសម្រាប់ "វាដំណើរការ" មិនមែន "វាដំណើរការបានល្អ" ទេ ហើយវាគឺជាគម្លាតពិតប្រាកដដែលសុវត្ថិភាពសរសេរកូដត្រូវតែបិទ។
ផ្ទៃហានិភ័យគឺធំជាងកូដខ្លួនឯង
ការសរសេរកូដ Vibe សន្តិសុខជារឿយៗត្រូវបានកំណត់ថាជា បញ្ហាគុណភាពកូដ ប៉ុន្តែការបង្ហាញ ដំណើរការតាមរយៈដំណើរការការងារទាំងមូល ភ្នាក់ងារប៉ះ មិនមែនគ្រាន់តែមុខងាររបស់វាទេ សរសេរ:
ហេតុអ្វីបានជាឧបករណ៍ AppSec បែបប្រពៃណីមានភាពយឺតយ៉ាវនៅទីនេះ?
ឧបករណ៍សុវត្ថិភាពកម្មវិធីភាគច្រើនត្រូវបានបង្កើតឡើងជុំវិញចង្វាក់៖ កូដត្រូវបានសរសេរ បន្ទាប់មកវាត្រូវបានស្កេន នៅក្នុង CI ឬនៅ PR។ ចង្វាក់នោះសន្មតថាមានវត្ថុបុរាណដែលមានស្ថេរភាព និងសរសេរដោយមនុស្សដើម្បីចង្អុលទៅម៉ាស៊ីនស្កេន ហើយថាបរិមាណនៃការផ្លាស់ប្តូរគឺជាអ្វីមួយ pipeline អាចពិនិត្យឡើងវិញដោយចេតនា។
ការសរសេរកូដ Vibe បំបែកពេលវេលា ហើយគម្លាតពេលវេលានោះគឺជាស្នូលនៃបញ្ហាសុវត្ថិភាពការសរសេរកូដ vibe។ កូដផ្លាស់ប្តូរនៅខាងក្នុង IDE ក្នុងរយៈពេលប៉ុន្មានវិនាទី ជារឿយៗមុនពេលវាឈានដល់... pull requestម៉ាស៊ីនស្កេនដែលដំណើរការតែនៅក្នុង CI នឹងចាប់បញ្ហាបន្ទាប់ពីការពិត នៅពេលដែលលំនាំមិនមានសុវត្ថិភាពត្រូវបានបញ្ចូលគ្នារួចហើយ វាជាផ្នែកមួយនៃលក្ខណៈពិសេសបន្ទាប់ដែលអ្នកផ្សេងកំពុងបង្កើត។ ហើយម៉ាស៊ីនស្កេនដែលដោះស្រាយកូដដែលបង្កើតដោយ AI ដូចគ្នានឹងកូដផ្សេងទៀតដែរ ខកខានផ្នែកនៃហានិភ័យដែលជាក់លាក់ចំពោះរបៀបដែលវាត្រូវបានសរសេរ៖ កញ្ចប់ដែលភ្នាក់ងារបានជ្រើសរើសដោយមិនត្រូវបានសួរឱ្យបង្ហាញអំពីភាពត្រឹមត្រូវរបស់វា ឯកសារណែនាំដែលប្រាប់ភ្នាក់ងារពីអ្វីដែលត្រូវធ្វើមុនពេលមនុស្សធ្លាប់ឃើញភាពខុសគ្នា។
អ្វីដែលពិតជាបិទចន្លោះប្រហោង
អង្គការនានាដែលកំពុងឈានទៅមុខនេះមិនបានបន្ថយល្បឿននៃការសរសេរកូដ vibe ទេ។ ពួកគេកំពុងកសាងសុវត្ថិភាពនៃការសរសេរកូដ vibe ពិតប្រាកដទៅក្នុងដំណើរការការងារ៖ ផ្លាស់ទីចំណុចត្រួតពិនិត្យត្រឡប់ទៅកន្លែងដែលកូដត្រូវបានសរសេរ ហើយចាត់ទុកកូដដែលបង្កើតដោយ AI ថាជាធាតុចូលដែលមិនគួរឱ្យទុកចិត្តរហូតដល់មានការបញ្ជាក់ផ្សេងពីនេះ៖
- ស្កេនខាងក្នុង IDE មិនមែនគ្រាន់តែនៅក្នុង CI នោះទេ។ ការចាប់បានលំនាំមិនមានសុវត្ថិភាព ខណៈពេលដែលភ្នាក់ងារនៅតែកំពុងបង្កើតមុខងារ គឺជាបញ្ហាខុសពីការចាប់វាបន្ទាប់ពីមុខងារបីទៀតពឹងផ្អែកលើវា។
- ផ្ទៀងផ្ទាត់រាល់ការពឹងផ្អែកដែលភ្នាក់ងារណែនាំដូចគ្នានឹងវិធីដែលអ្នកនឹងផ្ទៀងផ្ទាត់មួយដែលអ្នកអភិវឌ្ឍន៍បានវាយបញ្ចូលដោយដៃ មុនពេលវាដំឡើង។
- ចាត់ទុកឯកសារកំណត់រចនាសម្ព័ន្ធដែលភ្នាក់ងារអានដូចជាកូដ មិនមែនឯកសារទេ។ ឯកសារច្បាប់ ឯកសារជំនាញ និងការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ MCP អាចមានការណែនាំដែលផ្លាស់ប្តូរអ្វីដែលភ្នាក់ងារធ្វើ ហើយពួកវាសមនឹងទទួលបានការត្រួតពិនិត្យដូចគ្នានឹងកូដដែលភ្នាក់ងារបង្កើតដែរ។
- តាមដានមនុស្សម្នាក់សម្រាប់ការជួសជុល មិនមែនគ្រាន់តែទង់ជាតិនោះទេ។ អ្នកអភិវឌ្ឍន៍ដែលអាចមើលឃើញពីមូលហេតុដែលអ្វីមួយអាចកេងប្រវ័ញ្ចបាន មិនមែនគ្រាន់តែថាវាបានបង្កឱ្យមានច្បាប់នោះទេ តាមពិតរៀនពីរបៀបជំរុញ និងពិនិត្យឡើងវិញតាមរបៀបផ្សេងនៅពេលក្រោយ។
- សន្មតថា "វាដំណើរការ" មិនដែលជារបារសុវត្ថិភាពទេហើយធ្វើឱ្យរបារពិតប្រាកដអាចមើលឃើញនៅក្នុងលំហូរការងារជំនួសឱ្យការទុកវាចោលក្នុងអង្គចងចាំ។
កន្លែងដែល Xygeni សមនឹង
នេះពិតជាថ្នេរមែន DevAI របស់ Xygeni ត្រូវបានបង្កើតឡើងដើម្បីបិទ។ DevAI ដំណើរការជាស្រទាប់សុវត្ថិភាពជាបន្តបន្ទាប់នៅក្នុង IDE ដោយមើលកូដដែលសរសេរដោយមនុស្ស និងកូដដែលបង្កើតដោយ AI នៅពេលដែលវាត្រូវបានផលិត មិនមែនបន្ទាប់ពីវាចុះចតនៅក្នុង... pull requestវាមិនរង់ចាំការជំរុញទេ៖ វាសម្គាល់លំនាំដែលអាចកេងប្រវ័ញ្ចបាន ពន្យល់ពីផ្លូវវាយប្រហារពិតប្រាកដជាភាសាសាមញ្ញ និងស្នើការជួសជុលដែលអ្នកអភិវឌ្ឍន៍អាចពិនិត្យ និងអនុវត្តដោយមិនចាំបាច់ចាកចេញពីលំហូររបស់ពួកគេ។ នៅផ្នែកខ្សែសង្វាក់ផ្គត់ផ្គង់ MEW (ការព្រមានជាមុនអំពីមេរោគ) ចាប់កញ្ចប់ព្យាបាទមុនពេលមានហត្ថលេខា ដែលសំខាន់នៅទីនេះ ដោយសារភ្នាក់ងារដែលជ្រើសរើសការពឹងផ្អែកក្នុងនាមអ្នក គឺជាពេលដែលកញ្ចប់ដែលមានបញ្ហា ឬសម្របសម្រួលអាចចូលបាន។
នៅពីក្រោមទាំងពីរ CoreAI ភ្ជាប់ទំនាក់ទំនងគ្នានូវអ្វីដែលមាននៅទូទាំងមូលដ្ឋានកូដ ការពឹងផ្អែក និង pipeline ទៅជាទស្សនៈហានិភ័យដែលមានអាទិភាពមួយ ហើយទស្សនៈនោះមិនត្រូវបានកំណត់ចំពោះ ស៊ីហ្គេនី ការស្កេនផ្ទាល់ខ្លួន។ វាអនុវត្តដូចគ្នា ការជ្រើសរើស AI, ការពន្យល់ និង ការព្យាបាល ចំពោះការរកឃើញពីម៉ាស៊ីនស្កេនផ្សេងទៀតដែលមានរួចហើយ ដូច្នេះការធានាសុវត្ថិភាពការសរសេរកូដ vibe មិនមានន័យថាហែកចេញនូវជង់ដែលដំណើរការរួចហើយនោះទេ។ វាមានន័យថាដាក់ស្រទាប់មួយពីលើវា ដែលទីបំផុតផ្លាស់ទីក្នុងល្បឿនដែលកូដកំពុងត្រូវបានសរសេរឥឡូវនេះ។
សំណួរដែលត្រូវបានសួរជាញឹកញាប់
តើការសរសេរកូដ vibe មិនមានសុវត្ថិភាពដោយធម្មជាតិទេ?
ទេ។ ការសរសេរកូដ Vibe គឺជាវិធីសាស្ត្រអភិវឌ្ឍន៍ មិនមែនជាភាពងាយរងគ្រោះនោះទេ។ ហានិភ័យកើតចេញពីការរំលងជំហានពិនិត្យឡើងវិញដែលធ្លាប់ចាប់លំនាំមិនមានសុវត្ថិភាព មិនមែនមកពីការប្រើប្រាស់ AI ដើម្បីសរសេរកូដតាំងពីដំបូងឡើយ។ នោះហើយជាមូលហេតុដែលសុវត្ថិភាពនៃការសរសេរកូដ vibe គឺជាវិន័យនៃលំហូរការងារ មិនមែនជាហេតុផលដើម្បីជៀសវាងការអនុវត្តនោះទេ។
អាចមានស្រាប់ SAST or SCA ឧបករណ៍ចាប់បានហានិភ័យសុវត្ថិភាពនៃការសរសេរកូដ vibe?
ពួកគេចាប់យកវាខ្លះ ប៉ុន្តែជាធម្មតាបន្ទាប់ពីកូដបានបញ្ចូលគ្នារួចហើយ ព្រោះភាគច្រើនដំណើរការនៅក្នុង CI ជាជាងនៅក្នុង IDE ដែលកូដត្រូវបានបង្កើត។ ជាធម្មតាពួកគេក៏មិនវាយតម្លៃឥរិយាបថរបស់ភ្នាក់ងារ AI ដែរ ដូចជាកញ្ចប់ដែលវាជ្រើសរើស ឬឯកសារកំណត់រចនាសម្ព័ន្ធដែលវាអាន។
តើអ្វីទៅជាការជួសជុលដែលមានអានុភាពខ្ពស់បំផុតតែមួយគត់សម្រាប់សុវត្ថិភាពកូដ vibe?
ផ្លាស់ទីការត្រួតពិនិត្យសុវត្ថិភាពទៅក្នុង IDE នៅចំណុចនៃការបង្កើត ជាជាងពឹងផ្អែកតែលើកំណែក្រោយៗទៀត pipeline ស្កេន។ ការរកឃើញបញ្ហាមុនពេលវាក្លាយជាផ្នែកមួយនៃលក្ខណៈពិសេសបីបន្ទាប់ដែលបង្កើតឡើងនៅលើវាគឺជាបញ្ហាខុសពីការរកឃើញវានៅពេលក្រោយ។
តើការធានាសុវត្ថិភាពការសរសេរកូដ vibe មានន័យថាធ្វើឱ្យអ្នកអភិវឌ្ឍន៍យឺតទេ?
មិនមែនប្រសិនបើការត្រួតពិនិត្យកើតឡើងក្នុងជួរ នៅក្នុង IDE ជាមួយនឹងការពន្យល់ និងការជួសជុលដែលត្រៀមរួចជាស្រេចនោះទេ។ គោលដៅគឺដើម្បីរក្សាល្បឿនដែលការសរសេរកូដផ្តល់ជូន ខណៈពេលដែលស្តារការវិនិច្ឆ័យដែលការពិនិត្យដោយដៃធ្លាប់ផ្តល់ជូន។
