ការរចនាគឺជាកូដ

របៀបដែលតក្កវិជ្ជា Cellular Automata នឹងបង្កើតរូបរាងថ្មីឱ្យប្រព័ន្ធរចនាបែប Agentic ហើយហេតុអ្វីអនាគតនៃការអភិវឌ្ឍវេបអាចត្រូវបានសរសេររួចហើយក្នុងច្បាប់សាមញ្ញៗ

មានការផ្លាស់ប្តូរដ៏ជ្រាលជ្រៅមួយកំពុងកើតឡើងត្រង់ចំណុចប្រសព្វរវាងប្រព័ន្ធរចនា បញ្ញាសិប្បនិម្មិត និងទ្រឹស្តីគណនា។ វាជាការផ្លាស់ប្តូរដ៏ជាមូលដ្ឋានដែលសាកល្បងការយល់ដឹងរបស់យើងអំពីអត្ថន័យនៃពាក្យ "ការរចនា" ក្នុងយុគសម័យនៃភ្នាក់ងារស្វយ័ត។

អស់រយៈពេលជាច្រើនទសវត្សរ៍ហើយ ដែលយើងចាត់ទុកការរចនា និងកូដជាមុខវិជ្ជាពីរដាច់ពីគ្នា គឺការរចនាជាដែនរបស់ភាពច្នៃប្រឌិត និងការវិនិច្ឆ័យសោភ័ណភាពរបស់មនុស្ស ហើយកូដជាការបកប្រែមេកានិកនៃគំនិតទាំងនោះទៅជាទម្រង់ដែលអាចដំណើរការបាន។ ប៉ុន្តែនៅពេលដែលភ្នាក់ងារ AI កាន់តែច្រើនឡើងៗ ប្រមូលផ្គុំចំណុចប្រទាក់អ្នកប្រើដោយស្វយ័ត ប្រើប្រាស់ប្រព័ន្ធរចនាជាហេដ្ឋារចនាសម្ព័ន្ធដែលម៉ាស៊ីនអាចអានបាន និងបង្កើតកូដពីថូខឹនអត្ថន័យ នោះយើងកំពុងខិតជិតចំណុចបូករួមមួយ ដែលបន្លឺឡើងវិញនូវគំនិតមួយចាស់ជាងនេះឆ្ងាយពីទ្រឹស្តីគណនា។

គំនិតនោះឬ? ការរចនាគឺជាកូដ។

នេះមិនមែនគ្រាន់តែជាឃ្លាទាក់ទាញនោះទេ។ វាជាការទទួលស្គាល់ថា យើងប្រហែលជាកំពុងឆ្ពោះទៅរកពិភពមួយដែលប្រព័ន្ធរចនាដំណើរការដូច cellular automata គឺច្បាប់សាមញ្ញៗបង្កើតឱ្យមានឥរិយាបថស្មុគស្មាញដែលលេចចេញដោយខ្លួនឯង។ ជាពិភពដែលព្រំដែនរវាងការ "រចនា" អ្វីមួយ និងការ "សរសេរកម្មវិធី" វា រលាយបាត់ទាំងស្រុង។ ជាពិភពដែលភ្នាក់ងារស្វយ័តមិនត្រឹមតែ ប្រើ ប្រព័ន្ធរចនាប៉ុណ្ណោះទេ តែថែមទាំង ជា ប្រព័ន្ធរចនាដែលកំពុងដំណើរការផងដែរ។

អត្ថបទប្លក់នេះស្វែងយល់អំពីទំនាក់ទំនងជ្រាលជ្រៅរវាង cellular automata ឥរិយាបថដែលលេចចេញដោយខ្លួនឯង និងអនាគតនៃប្រព័ន្ធរចនាបែប Agentic។ យើងនឹងតាមដានមូលដ្ឋានគ្រឹះទ្រឹស្តី ចាប់ពីម៉ាស៊ីនបង្កើតខ្លួនឯងរបស់ von Neumann រហូតដល់ហ្វូងភ្នាក់ងារ AI សព្វថ្ងៃ។

យើងនឹងពិនិត្យមើលរបៀបដែល Drupal និងវេទិកា CMS ទំនើបៗកំពុងរួមបញ្ចូល AI តាមរយៈម៉ូឌុលដូចជា Schema.org Blueprints និង Drupal AI។ ហើយយើងនឹងពិចារណាថា ទាំងអស់នេះមានន័យយ៉ាងណាសម្រាប់អ្នករចនា អ្នកអភិវឌ្ឍ និងអនាគតនៃការបង្កើតផលិតផលឌីជីថល។

Cellular Automata និងតក្កវិជ្ជានៃការលេចចេញដោយខ្លួនឯង

ភាពស្រស់ស្អាតនៃច្បាប់សាមញ្ញៗ

នៅឆ្នាំ១៩៧០ គណិតវិទូ John Conway បានណែនាំ Game of Life ដែលជា "เกมដែលគ្មានអ្នកលេង" ហើយបានក្លាយជាប្រព័ន្ធមួយក្នុងចំណោមប្រព័ន្ធដែលត្រូវបានសិក្សាច្រើនបំផុតក្នុងទ្រឹស្តីគណនា។ ច្បាប់ទាំងនោះសាមញ្ញរហូតគួរឱ្យភ្ញាក់ផ្អើល៖

1. ក្រឡារស់ណាមួយដែលមានអ្នកជិតខាងរស់តិចជាងពីរ នឹងស្លាប់ (ប្រជាជនតិចពេក)
2. ក្រឡារស់ណាមួយដែលមានអ្នកជិតខាងរស់ពីរ ឬបី នឹងនៅរស់
3. ក្រឡារស់ណាមួយដែលមានអ្នកជិតខាងរស់ច្រើនជាងបី នឹងស្លាប់ (ប្រជាជនច្រើនពេក)
4. ក្រឡាស្លាប់ណាមួយដែលមានអ្នកជិតខាងរស់ចំនួនបីយ៉ាងពិតប្រាកដ នឹងក្លាយជារស់ (ការបន្តពូជ)

ពីច្បាប់ទាំងបួននេះ ដែលបង្ហាញជាលក្ខខណ្ឌគោលពីរមួយក្តាប់តូច បានលេចចេញជាសកលលោកដ៏អស្ចារ្យនៃភាពស្មុគស្មាញ។ Glider ធ្វើដំណើរកាត់ក្រឡាចត្រង្គគ្មានទីបញ្ចប់។ Oscillator ញាប់ញ័រតាមចង្វាក់អស់កល្ប។ Gun បាញ់ចេញជាស្ទ្រីមនៃគំរូកាត់លំហក្រឡា។ ហើយគួរឱ្យភ្ញាក់ផ្អើលជាងនេះ Game of Life ត្រូវបានបង្ហាញថា Turing-complete៖ អ្វីៗដែលអាចគណនាបានតាមអាល់ហ្គោរីតអាចត្រូវបានគណនាក្នុងក្រឡាចត្រង្គសាមញ្ញរបស់ Conway តាមគោលការណ៍។

រូបភាពទី ១៖ កាំភ្លើង Glider របស់ Gosper ក្នុងហ្គេមជីវិតរបស់ Conway។ លំនាំនេះបង្កើតចរន្ត glider ជាបន្តបន្ទាប់ដោយមិនឈប់ ដែលបង្ហាញថា ច្បាប់សាមញ្ញៗអាចបង្កើតភាពស្មុគស្មាញគ្មានទីបញ្ចប់ ហើយបន្តកើតឡើងដោយខ្លួនឯង។

នេះជាមេរៀនដំបូងនៃសែលអូតូម៉ាតា (cellular automata)៖ ភាពស្មុគស្មាញមិនមែនជាលក្ខខណ្ឌចាំបាច់សម្រាប់ឥរិយាបថស្មុគស្មាញនោះទេ។ ច្បាប់សាមញ្ញៗ ដែលអនុវត្តជាប់លាប់លើផ្ទៃមួយ អាចបង្កើតលំនាំ និងឥរិយាបថ ដែលគ្មាននរណាម្នាក់បានសរសេរកម្មវិធីឱ្យវាធ្វើយ៉ាងច្បាស់លាស់នោះឡើយ។

Langton's Loops និងការចម្លងខ្លួនឯង

ក្នុងឆ្នាំ ១៩៨៤ Christopher Langton បានដាក់គោលការណ៍នេះឱ្យទៅឆ្ងាយជាងមុន ជាមួយនឹង loop ចម្លងខ្លួនឯងរបស់គាត់ ដែលជាសែលអូតូម៉ាតុងដែលបង្ហាញគោលការណ៍នៃជីវិតសិប្បនិម្មិតពិតប្រាកដ។ ផ្ទុយពីហ្គេមជីវិតរបស់ Conway ដែលបង្ហាញពីភាពស្មុគស្មាញដែលលេចឡើងដោយឯកឯង Langton's Loops បង្ហាញពីការបន្តពូជ.

ដែលលេចឡើងដោយឯកឯង។ loop នីមួយៗមានព្រំដែនរង្វង់មួយ ព័ទ្ធជុំវិញ «ហ្សែន» ដែលអ៊ិនកូដក្នុងស្ថានភាពនៃក្រឡា។ ហ្សែននេះហូរជាបន្តបន្ទាប់ជុំវិញ loop ហើយចេញតាមដៃសាងសង់ ដែលសាងសង់ loop កូនក្នុងរយៈពេល ១៥១ ជំហានពេលវេលា។ ពេលសាងសង់រួច កូនបំបែកចេញពីមេ ហើយទាំងពីរបន្តចម្លងខ្លួនទៀត។

រូបភាពទី ២៖ Langton's Loop ក្នុងការកំណត់រចនាសម្ព័ន្ធចាប់ផ្តើម។ ព័ត៌មានហ្សែនចរាចរក្នុង loop ហើយដឹកនាំការសាងសង់ loop កូនតាមរយៈដៃដែលលាតសន្ធឹងចេញ។

«ប្រសិនបើម៉ាស៊ីនចម្លងខ្លួនឯងអាចមានក្នុងសែលអូតូម៉ាតុង នោះម៉ាស៊ីនក៏អាចសម្រេចបានជីវិតដែរ»។

- Christopher Langton, «Studying Artificial Life with Cellular Automata» (១៩៨៦)

ផលប៉ះពាល់នេះជ្រាលជ្រៅណាស់។ Langton's Loops បង្ហាញថា ការចម្លងខ្លួនឯងមិនត្រូវការភាពស្មុគស្មាញនៃកោសិកាជីវសាស្ត្រ ឬសមត្ថភាពសាងសង់សកលនៃការរចនាដើមរបស់ von Neumann ឡើយ។ វាត្រូវការតែ៖

• សំណុំច្បាប់មូលដ្ឋានសាមញ្ញៗ
• យន្តការសម្រាប់អ៊ិនកូដការណែនាំ
• ដំណើរការមួយសម្រាប់អនុវត្តការណែនាំទាំងនោះ

ច្បាប់ គឺជា សារពាង្គកាយ។ ការរចនា គឺជា កូដ។

ក្នុងឆ្នាំ ១៩៩៩ Hiroki Sayama បានណែនាំ evoloops ដែលជាវ៉ារ្យ៉ង់ដែលរួមបញ្ចូលភាពរលាយនៃរចនាសម្ព័ន្ធ និងអន្តរកម្មផេណូទីប ដែលអនុញ្ញាតឱ្យមានការផ្លាស់ប្តូរហ្សែនដោយឯកឯង និងឌីណាមិកនៃការវិវត្តន៍។ loop ទាំងនេះវិវត្តតាមរយៈការប៉ះទង្គិចរូបវន្តដោយផ្ទាល់ក្នុងអំឡុងពេលចម្លង ដែលនាំឱ្យមានភាពខុសគ្នានៃហ្សែន ភាពចម្រុះរូបសណ្ឋានកើនឡើង និងភាពស្មុគស្មាញលូតលាស់តាមជំនាន់។ ផ្ទុយពីការចម្លងថេររបស់ Langton, evoloops បង្ហាញពីការផ្លាស់ប្តូរដែលអាចបន្តពូជបានដោយគ្មានការជ្រៀតជ្រែកពីខាងក្រៅ។

Rule 110 និងការគណនាសកល

ការស្វែងយល់របស់ Stephen Wolfram អំពីសែលអូតូម៉ាតាបឋម បានឈានដល់ការរកឃើញដ៏ភ្ញាក់ផ្អើលមួយ៖ Rule 110 ដែលជាមួយក្នុងចំណោមច្បាប់ដែលអាចមានតែ ២៥៦ សម្រាប់សែលអូតូម៉ាតុងមួយវិមាត្រប្រភេទសាមញ្ញបំផុត មានសមត្ថភាពគណនាសកល។

ច្បាប់ទី 110 អាចកំណត់បានទាំងស្រុង ដោយគ្រាន់តែបញ្ជាក់លទ្ធផលសម្រាប់ការផ្សំគ្នាទាំងប្រាំបីដែលអាចមាន រវាងក្រឡាមួយ និងអ្នកជិតខាងទាំងពីររបស់វា។ ប៉ុន្តែច្បាប់ដែលសាមញ្ញបំផុតនេះ ដែលមានតែការសម្រេចចិត្តគោលពីរប្រាំបីប៉ុណ្ណោះ អាចក្លែងធ្វើម៉ាស៊ីនទួរីងសកលបាន។

រូបភាពទី 3៖ ស្វ័យប្រវត្តិកម្មក្រឡាច្បាប់ទី 110។ ទោះបីមាននិយមន័យសាមញ្ញក៏ដោយ ច្បាប់ទី 110 បង្ហាញឥរិយាបថថ្នាក់ទី 4 គឺជាលំនាំស្មុគស្មាញដែលមិនស្ថិតស្ថេរទាំងស្រុង ហើយក៏មិនវឹកវរទាំងស្រុងដែរ ហើយត្រូវបានបញ្ជាក់ដោយភស្តុតាងថាមានភាពពេញលេញតាមទួរីង (Turing complete)។

«យើងមិនត្រូវការអ្វីដូចជា CPU កុំព្យូទ័រទាំងមូលដើម្បីធ្វើការគណនាសកលនោះទេ។ យើងត្រូវការតែច្បាប់តូចមួយនេះប៉ុណ្ណោះ។»

- Stephen Wolfram, «A New Kind of Science»

នៅឆ្នាំ 2004 Matthew Cook បានបោះពុម្ពភស្តុតាងមួយថា ច្បាប់ទី 110 ដែលមានលំនាំផ្ទៃខាងក្រោយដដែលៗជាក់លាក់មួយ គឺពេញលេញតាមទួរីង។ ភស្តុតាងនេះបង្ហាញថា ច្បាប់ទី 110 អាចត្រាប់តាមប្រព័ន្ធស្លាកវដ្ត (cyclic tag systems) ដែលបន្ទាប់មកអាចត្រាប់តាមម៉ាស៊ីនទួរីងណាមួយក៏បាន។ ក្នុងចំណោមស្វ័យប្រវត្តិកម្មក្រឡាបឋមតែមួយគត់ចំនួន 88 ដែលអាចមាន ច្បាប់ទី 110 គឺជាច្បាប់តែមួយគត់ដែលភាពពេញលេញតាមទួរីងត្រូវបានបញ្ជាក់ដោយផ្ទាល់។

គោលការណ៍សមមូលនៃការគណនា (Principle of Computational Equivalence) ដែល Wolfram បានស្នើឡើង បង្ហាញពីអ្វីមួយដែលរ៉ាឌីកាល់ជាងនេះទៅទៀត៖ ប្រព័ន្ធណាដែលលើសពីកម្រិតស្មុគស្មាញអប្បបរមា គឺសមមូលគ្នាជាសារវន្តក្នុងសមត្ថភាពគណនា។ ខួរក្បាលមនុស្ស ប្រព័ន្ធអាកាសធាតុ និងច្បាប់ទី 110 គឺសមមូលគ្នាផ្នែកគណនា ក្នុងន័យជ្រាលជ្រៅមួយ។

0E0P Metacell៖ ការចម្លងខ្លួនឯងពិតប្រាកដ

នៅខែតុលា ឆ្នាំ 2018 Adam P. Goucher បានបញ្ចប់ការសាងសង់ 0E0P metacell ដែលជាលំនាំមួយនៅក្នុង Game of Life របស់ Conway ដែលអាចចម្លងខ្លួនឯងបានយ៉ាងពិតប្រាកដ។ មិនដូច metacell មុនៗដែលត្រូវការច្បាប់ចម្លងដែលមានស្រាប់នៅជិតៗ 0E0P metacell អាចសាងសង់ច្បាប់ចម្លងរបស់ខ្លួនពីសូន្យ រួមទាំងខ្សែបន្ទាត់ណែនាំរបស់ខ្លួនផង។

សមិទ្ធផលនេះជាសញ្ញាសម្គាល់ដ៏សំខាន់មួយនៃជីវិតសិប្បនិម្មិត៖ ប្រព័ន្ធមួយដែលអាចផ្សព្វផ្សាយខ្លួនឯងតាមរយៈស្រទាប់ខាងក្រោមនៃការគណនា ដោយប្រើតែច្បាប់មូលដ្ឋានប៉ុណ្ណោះ។ នៅថ្ងៃទី 23 ខែវិច្ឆិកា ឆ្នាំ 2013 Dave Greene បានសាងសង់ឧបករណ៍ចម្លងដំបូងគេនៅក្នុង Game of Life ដែលបង្កើតច្បាប់ចម្លងពេញលេញនៃខ្លួនឯង រួមទាំងខ្សែបន្ទាត់ណែនាំ ដែលបង្ហាញថា សូម្បីតែស្វ័យប្រវត្តិកម្មពីរស្ថានភាពដ៏សាមញ្ញរបស់ Conway ក៏អាចគាំទ្រការបន្តពូជខ្លួនឯងដោយគ្មានដែនកំណត់បានដែរ។

ប្រព័ន្ធរចនាជាស្រទាប់ខាងក្រោមនៃការគណនា

ពី Atomic Design ទៅ Agentic Design

វិធីសាស្ត្រ Atomic Design របស់ Brad Frost ដែលបានណែនាំនៅឆ្នាំ 2013 បានធ្វើបដិវត្តន៍របៀបដែលយើងគិតអំពីប្រព័ន្ធរចនា។ ដោយបំបែកចំណុចប្រទាក់ជាអាតូម (ធាតុមូលដ្ឋានដូចជាប៊ូតុង និងប្រអប់បញ្ចូល) ម៉ូលេគុល (ការផ្សំសាមញ្ញៗ) សារពាង្គកាយ (ផ្នែក UI ស្មុគស្មាញ) ទម្រង់គំរូ (ប្លង់ទំព័រ) និងទំព័រ (ការអនុវត្តចុងក្រោយ) Atomic Design បានផ្តល់រចនាសម្ព័ន្ធតាមឋានានុក្រមសម្រាប់គ្រប់គ្រងភាពស្មុគស្មាញ។

ប៉ុន្តែនេះជាអ្វីដែលគួរឱ្យភ្ញាក់ផ្អើលនៅពេលមើលទៅក្រោយ៖ Atomic Design បានបង្កប់គោលការណ៍ស្វ័យប្រវត្តិកម្មក្រឡារួចទៅហើយ ដោយមិនបានទទួលស្គាល់វាយ៉ាងច្បាស់លាស់។

"នៅពេលដែលប្រព័ន្ធរចនាមើលទៅធម្មតា គ្មានអ្វីអស្ចារ្យ វាបើកផ្លូវឱ្យអ្នករចនា និងអ្នកអភិវឌ្ឍបានធ្វើរឿងថ្មីៗ និងដោះស្រាយបញ្ហាថ្មីៗ។ ប្រព័ន្ធរចនាទទួលបន្ទុកការងារដដែលៗដ៏គួរឱ្យធុញ ដើម្បីកុំឱ្យអ្នករចនា និងអ្នកអភិវឌ្ឍត្រូវធ្វើវាផ្ទាល់។"

- Josh Clark, "The Most Exciting Design Systems Are Boring"

កាលពីខែកុម្ភៈ ឆ្នាំ២០២៣ Brad Frost បានសរសេរអំពី "Design Systems in the Time of AI"៖

"AI គឺជាអ្នកប្រើប្រាស់ប្រព័ន្ធរចនាតាមធម្មជាតិ... តាមការពិត ការងារសមាសភាគនៅក្នុងប្រព័ន្ធរចនាច្រើនណាស់ ពិតជាមានលក្ខណៈមេកានិច និងអាចទាយទុកជាមុនបាន។ យើងប្រើឧបករណ៍ដូចជា PlopJS រួចហើយ ដើម្បីបង្កើតកូដគ្រោងនៃសមាសភាគ (boilerplate) ឱ្យត្រូវនឹងរូបរាងរបស់បណ្ណាល័យទាំងមូល។ ខ្ញុំរីករាយនឹងទទួលជំនួយពី AI ក្នុងការបង្កើតកូដគ្រោងទូទៅៗជាច្រើនឱ្យខ្ញុំ។"

- Brad Frost

លក្ខណៈមេកានិច និងអាចទាយទុកជាមុនបាននៃប្រព័ន្ធរចនា គឺជាអ្វីដែលធ្វើឱ្យវាស័ក្តិសមនឹងការដំណើរការតាមរបៀបស្វ័យប្រតិកម្មកោសិកា (cellular automata)។ នៅពេលដែលច្បាប់មានភាពច្បាស់លាស់ ជាក់លាក់នៅកន្លែង និងអនុវត្តជាប់លាប់ ភ្នាក់ងារអាចធ្វើការដោយឯករាជ្យ ដូចកោសិកានៅក្នុង Game of Life របស់ Conway ដែលមិនត្រូវការឧបករណ៍ត្រួតពិនិត្យកណ្តាល ដើម្បីបង្កើត gliders និង oscillators នោះដែរ។

តម្រូវការចាំបាច់នៃទម្រង់ដែលម៉ាស៊ីនអាចអានបាន

គំនិតផ្តួចផ្តើម Storybook MCP (Model Context Protocol) តំណាងឱ្យការវិវត្តដ៏សំខាន់មួយក្នុងទិសដៅនេះ។ Storybook MCP ត្រូវបានប្រកាសនៅចុងឆ្នាំ២០២៥ ដោយផ្តល់ទៅឱ្យភ្នាក់ងារសរសេរកូដ AI នូវទិន្នន័យមេតា (metadata) របស់សមាសភាគដែលម៉ាស៊ីនអាចអានបាន ពីការដំឡើង Storybook ដែលមានស្រាប់។

ចំណុចសំខាន់គឺថា ភ្នាក់ងារមិនត្រូវការកូដដើម ឬឯកសារបែបរូបភាពទេ។ ពួកគេត្រូវការ៖

• Component manifests៖ ទិន្នន័យមេតាមានរចនាសម្ព័ន្ធអំពីសមាសភាគនីមួយៗ ទាំង props, variants, ការភ្ជាប់ design token និងឧទាហរណ៍នៃការប្រើប្រាស់
• ការដាក់ឈ្មោះតាមន័យ៖ Tokens ដែលសម្បូរបំណងមាននៅក្នុងឈ្មោះ ដូចជា action.primary.confirm ដែលបញ្ជូនអត្ថន័យដល់ភ្នាក់ងារ មិនមែនគ្រាន់តែតម្លៃប៉ុណ្ណោះទេ
• រង្វង់ផ្ទៀងផ្ទាត់៖ សមត្ថភាពក្នុងការដំណើរការតេស្ត មើលការបរាជ័យ និងកែតម្រូវខ្លួនឯង

"Storybook MCP ជួយឱ្យភ្នាក់ងារធ្វើតាមគំរូរបស់អ្នក និងប្រឆាំងនឹងតេស្តរបស់អ្នកបានជោគជ័យ។ វាផ្តល់ឱ្យភ្នាក់ងារនូវរបស់ពីរយ៉ាងដែលពួកគេមិនធ្លាប់មានពីមុន៖ ទិន្នន័យមេតាសមាសភាគដែលម៉ាស៊ីនអាចអានបាន និងរង្វង់ដដែលៗសម្រាប់ព្យាបាលកំហុសដោយខ្លួនឯង។"

- ក្រុម Storybook

Storybook MCP រួមមានរង្វង់កែតម្រូវស្វ័យប្រវត្តិ។ វាអនុញ្ញាតឱ្យភ្នាក់ងារដំណើរការតេស្តសមាសភាគរបស់អ្នក (អន្តរកម្ម និងភាពងាយស្រួលប្រើ) មើលថាអ្វីបរាជ័យ ហើយកែកំហុសរបស់ខ្លួនឯង។ អ្នកអភិវឌ្ឍគ្រាន់តែចូលជួយនៅពេលតេស្តជាប់ប៉ុណ្ណោះ។ លែងមានការមើលថែប្រអប់បញ្ជា (prompt) ដូចមើលថែក្មេងទៀតហើយ។

នេះពិតជាស្ថាបត្យកម្មរបស់ស្វ័យប្រតិកម្មកោសិកាដែលអនុវត្តលើការរចនា៖ ច្បាប់ក្នុងមូលដ្ឋាន (ការបញ្ជាក់លម្អិតរបស់សមាសភាគ) អន្តរកម្មជាមួយអ្នកជិតខាង (គំរូនៃការផ្សំ) និងការធ្វើបច្ចុប្បន្នភាពដដែលៗ (ការផ្ទៀងផ្ទាត់ និងការកែតម្រូវខ្លួនឯង)។

Component Manifest របស់ខ្ញុំជា Genome

ការប្រៀបធៀបជាមួយ Langton's Loops កាន់តែសមស្របថែមទៀត នៅពេលយើងពិចារណាពីរបៀបដែល component manifest ដំណើរការ។ នៅក្នុងប្រព័ន្ធរបស់ Langton "genome" ដែលអ៊ិនកូដនៅក្នុងកោសិកាដែលវិលជុំវិញ មានសេចក្តីណែនាំសម្រាប់បង្កើតរង្វិលជុំថ្មី។ នៅក្នុងប្រព័ន្ធរចនាដែលម៉ាស៊ីនអាចអានបាន component manifest មានសេចក្តីណែនាំសម្រាប់ផ្គុំចំណុចប្រទាក់។

component manifest មួយអាចបញ្ជាក់ថា៖

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

Manifest នេះគឺជាទាំងលក្ខណៈបច្ចេកទេសនៃការរចនា និងជាកូដដែលអាចដំណើរការបាន ក្នុងពេលតែមួយ ឬច្បាស់ជាងនេះ គឺជាសេចក្តីណែនាំដែលអាចបង្កើតកូដដំណើរការបានចេញពីវា។ Agent ដែលប្រើ manifest នេះមិនចាំបាច់យល់ពីសោភ័ណភាព ឬបទពិសោធន៍អ្នកប្រើក្នុងន័យរបស់មនុស្សនោះទេ។ វាគ្រាន់តែត្រូវធ្វើតាមច្បាប់ ផ្សំធាតុតាមដែនកំណត់របស់ពួកវា ហើយបង្កើតលទ្ធផលដែលត្រឹមត្រូវ។

ខ្ញុំយល់ស្របជាមួយ Brad Frost ថាគួរមានទ្រង់ទ្រាយ yaml។

Drupal Components ក៏ប្រើទ្រង់ទ្រាយ yaml ដែរ។ ប្រហែលជាដូចនេះ៖

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

ការរចនា គឺ ជាកូដ។

• វ៉ារ្យ៉ង់
• Tokens
• Props

• ដែនកំណត់ (យើងអាចបន្ថែមទៅ components)

• ច្បាប់ស្លុត (Slots) (អ្វីដែលអាចដាក់ក្នុងស្លុតផ្សេងទៀត ឬអ្វីដែលអនុញ្ញាតឱ្យដាក់ក្នុងស្លុតរបស់ខ្ញុំ)

• ច្បាប់

• ឧទាហរណ៍ 

• ចលនា  ( អនុញ្ញាតឱ្យប្រើ ឬត្រូវបានណែនាំឱ្យប្រើ )

បន្ទាប់មក សង្កេត និងពិសោធន៍មើលឥរិយាបថរបស់វា។

ដូចក្នុង https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Design Tokens ជាអថេរបរិស្ថាន

Design tokens គឺជាបំណែកដ៏សំខាន់មួយទៀតនៃល្បែងផ្គុំរូបនេះ។ ក្នុង cellular automata ក្រឡានីមួយៗឆ្លើយតបនឹងបរិស្ថានជុំវិញខ្លួនភ្លាមៗ គឺស្ថានភាពរបស់ក្រឡាជិតខាង។ ក្នុងប្រព័ន្ធរចនា components ឆ្លើយតបនឹង design tokens ដែលជាតម្លៃតាមបរិបទ ដែលកំណត់រូបរាង និងឥរិយាបថរបស់វា។

ស្ថាបត្យកម្ម token សម័យថ្មីប្រើស្រទាប់ច្រើន៖

• Core tokens៖ តម្លៃដើម ដូចជា color.blue.500: #3B82F6
• Semantic tokens៖ ឯកសារយោងដែលផ្អែកលើចេតនា ដូចជា color.action.primary: color.blue.500
• Component tokens៖ ការអនុវត្តក្នុងវិសាលភាពជាក់លាក់ ដូចជា button.background.primary: color.action.primary

នៅពេល agent បង្កើត Button component វាមិនចាំបាច់ដឹងថា "primary" មានន័យថាពណ៌ខៀវទេ។ វាគ្រាន់តែត្រូវយោងទៅលើ button.background.primary ហើយជឿទុកចិត្តថាប្រព័ន្ធ token នឹងបកស្រាយទៅជាតម្លៃត្រឹមត្រូវ។ បរិស្ថាន (ស្រទាប់ token) ផ្ទុកព័ត៌មាន ចំណែក component (ក្រឡា) គ្រាន់តែឆ្លើយតបនឹងវា។

ឧបករណ៍ដូចជា Tokens Studio បានវិវត្តដើម្បីចាត់ទុក design tokens ជាក្រាហ្វនៃការគណនាដែលមាន resolvers គឺជាថ្នាំង (nodes) ដែលសម្រេចចិត្តតាមន័យ (semantic) ថាត្រូវប្រើ token មូលដ្ឋានមួយណាតាមបរិបទ។ នេះប្តូរ design tokens ពីតម្លៃឋិតិវន្តទៅជាប្រព័ន្ធថាមវន្តដែលផ្អែកលើច្បាប់។

ប្រព័ន្ធអេកូឡូជី Drupal និងការរួមបញ្ចូល AI

ការរួមបញ្ចូល AI ទៅក្នុងប្រព័ន្ធគ្រប់គ្រងមាតិកា (CMS) គឺជាមន្ទីរពិសោធន៍ដ៏ល្អឥតខ្ចោះសម្រាប់ស្វែងយល់ពីគោលការណ៍ "ការរចនាគឺជាកូដ"។ CMS ដូចជា Drupal បានរួមបញ្ចូលគំនិតស្នូលទាំងនេះរួចហើយ៖ ប្រភេទមាតិកាដែលមានរចនាសម្ព័ន្ធ និយមន័យវាល ទំនាក់ទំនង និងច្បាប់សម្រាប់ការផ្សំ។

ខ្ញុំមិនដែលគិតថាយើងអាចនិយាយអ្វីបែបនេះឡើយ។ សម្រាប់ខ្ញុំ នេះជាកម្រិតកំពូលនៃសិល្បៈ។

 ឈុតកុំព្យូទ័រដ៏ល្អបំផុតដែលយើងអាចមាន។ អ្នកអភិវឌ្ឍមួយចំនួនដូចជាមកពី Star Trek នាអនាគត និយាយជាមួយកុំព្យូទ័រឱ្យសរសេរកម្មវិធីជំនួសពួកគេ។

បទពិសោធន៍ Agent (AX) និងអ្នកប្រើប្រាស់ថ្មី

ការរចនាសម្រាប់ម៉ាស៊ីន

នៅដើមឆ្នាំ ២០២៥ Mathias Biilmann ប្រធានប្រតិបត្តិនៃ Netlify បានណែនាំគំនិត "បទពិសោធន៍ Agent" (AX) ជាមុខវិជ្ជាថ្មីដែលផ្តោតលើរបៀបដែល AI agents ធ្វើអន្តរកម្មជាមួយផលិតផល និងវេទិកា។

នេះជាការផ្លាស់ប្តូរជាមូលដ្ឋាន។ អស់ជាច្រើនទសវត្សរ៍ហើយ UX (បទពិសោធន៍អ្នកប្រើ) ត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ការយល់ដឹង ការយល់ឃើញ និងអាកប្បកិរិយារបស់មនុស្ស។ DX (បទពិសោធន៍អ្នកអភិវឌ្ឍ) ត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់អ្នកអភិវឌ្ឍដែលជាមនុស្សបង្កើតកម្មវិធី។ AX ទទួលស្គាល់ថា agents កំពុងក្លាយជាអ្នកប្រើចម្បងនៃប្រព័ន្ធឌីជីថល ហើយពួកវាមានតម្រូវការខុសគ្នាទាំងស្រុង៖

• ពួកវាមិនខ្វល់ពីសោភ័ណភាពរូបរាងទេ ត្រូវការតែទិន្នន័យដែលមានរចនាសម្ព័ន្ធ និងអាចញែកអានបាន
• ពួកវាមិនរុករកតាមចំណុចប្រទាក់ទេ ពួកវាហៅ APIs និងប្រើ manifests
• ពួកវាមិនអានឯកសារបែបមនុស្សទេ ពួកវាត្រូវការបរិបទដែលម៉ាស៊ីនអានបាន
• ពួកវាមិនវិនិច្ឆ័យតាមការយល់ឃើញផ្ទាល់ខ្លួនទេ ពួកវាធ្វើតាមច្បាប់ និងដែនកំណត់

"ភ្នាក់ងារ AI មិនមែនជាមនុស្សទេ៖ ពួកវាមិនខ្វល់ពីទំហំប៊ូតុង ភាពច្បាស់នៃអក្សរ ប្រអប់ពណ៌ដ៏ស្អាតនៅលើគេហទំព័ររបស់អ្នក ឬចលនាភ្លឺចាំងក្នុងកម្មវិធីរបស់អ្នកឡើយ។ ដូច្នេះ តើភ្នាក់ងារ AI «ខ្វល់» ពីអ្វី? នេះជាសំណួរដែលសព្វថ្ងៃនៅមិនទាន់មានចម្លើយច្បាស់លាស់ ប៉ុន្តែនឹងកាន់តែសំខាន់ឡើងៗក្នុងប៉ុន្មានឆ្នាំខាងមុខ។"

- ការស្រាវជ្រាវ AX

ចម្លើយគឺ៖ ច្បាប់ច្បាស់លាស់ អាកប្បកិរិយាដែលអាចទាយទុកបាន ទិន្នន័យដែលមានរចនាសម្ព័ន្ធល្អ និងរង្វិលមតិត្រឡប់ដែលអនុញ្ញាតឱ្យពួកវាផ្ទៀងផ្ទាត់ និងកែតម្រូវសកម្មភាពរបស់ខ្លួន។

បញ្ហាប្រឈមនៃចំណុចប្រទាក់ពីរ

ការរចនាសម្រាប់ AX មានន័យថាត្រូវបង្កើតចំណុចប្រទាក់ពីរក្នុងពេលតែមួយ៖

1. ចំណុចប្រទាក់ពីមនុស្សទៅភ្នាក់ងារ៖ ជាកន្លែងដែលមនុស្សត្រួតពិនិត្យ អនុម័ត កែសម្រួល និងណែនាំអាកប្បកិរិយារបស់ភ្នាក់ងារ ដែលជាស្រទាប់ «មជ្ឈមណ្ឌលបញ្ជាបេសកកម្ម»។ សូមគិតដល់ផ្ទាំងគ្រប់គ្រង និងជួរឡាយរង់ចាំការអនុម័ត មិនមែនទម្រង់បែបបទ និងប៊ូតុងទេ។
2. ចំណុចប្រទាក់ពីភ្នាក់ងារទៅប្រព័ន្ធ៖ ជាកន្លែងដែលភ្នាក់ងារធ្វើអន្តរកម្មជាមួយ API មូលដ្ឋានទិន្នន័យ និងឧបករណ៍ ដែលជាស្រទាប់ «ប្រតិបត្តិការ»។ ត្រូវតែរឹងមាំ មានឯកសារគ្រប់គ្រាន់ និងត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ប្រសិទ្ធភាពរបស់ម៉ាស៊ីន។

នេះឆ្លុះបញ្ចាំងពីស្ថាបត្យកម្មនៃអូតូម៉ាតាក្រឡា (cellular automata) ដែលទស្សនៈពីរខុសគ្នារស់នៅជាមួយគ្នា៖

• ទស្សនៈមូលដ្ឋាន៖ ក្រឡានីមួយៗ (ភ្នាក់ងារ) អនុវត្តតាមច្បាប់សាមញ្ញៗដោយផ្អែកលើអ្នកជិតខាងភ្លាមៗរបស់ខ្លួន
• ទស្សនៈសកល៖ គំរូស្មុគស្មាញលេចឡើង ដែលអាចមើលឃើញតែនៅកម្រិតធំប៉ុណ្ណោះ

"ការរចនាបទពិសោធន៍ភ្នាក់ងារ (AX) គួរតែនាំឱ្យមានភាពងាយស្រួលប្រើដ៏ល្អសម្រាប់ និងរបស់ភ្នាក់ងារ។ ដូច្នេះ AX ល្អនាំទៅរកបទពិសោធន៍អ្នកប្រើ (UX) ល្អ។ ប្រសិនបើភ្នាក់ងារ AI ជួបដំណើរការដែលខូច ពិធីការ ឬសូម្បីតែពាក្យពេចន៍មិនស៊ីសង្វាក់គ្នាតាមប្រព័ន្ធផ្សេងៗ វាមិនអាចបំពេញកិច្ចការនោះបានទេ។ នោះជាបទពិសោធន៍អាក្រក់សម្រាប់ភ្នាក់ងារ ដែលនៅទីបំផុតនាំឱ្យមានបទពិសោធន៍អាក្រក់សម្រាប់អតិថិជន ឬនិយោជិត។"

- Kat Holmes នាយិកាបទពិសោធន៍ជាន់ខ្ពស់ (Chief Experience Officer) នៃ Salesforce

ពី UX ទៅ AX៖ วิវត្តនៃការរចនាឌីជីថល

ស្ទីកមើជី និងទំនាក់ទំនងប្រយោល

គំនិតដ៏មានឥទ្ធិពលបំផុតមួយពីបញ្ញាហ្វូង គឺ ស្ទីកមើជី (stigmergy) ដែលជាការសម្របសម្រួលប្រយោលតាមរយៈស្នាមដានបរិស្ថាន។ ស្រមោចមិនប្រាប់គ្នាដោយផ្ទាល់អំពីកន្លែងមានអាហារទេ ពួកវាទុកផ្លូវផេរ៉ូម៉ូនឱ្យស្រមោចផ្សេងទៀតដើរតាម។ បរិស្ថានក្លាយជាមធ្យោបាយទំនាក់ទំនង។

នៅក្នុងប្រព័ន្ធរចនាភ្នាក់ងារ ស្ទីកមើជីមានទម្រង់ដូចតទៅ៖

• បណ្ណាល័យសមាសភាគរួមគ្នា៖ ភ្នាក់ងារ «មើលឃើញ» ថាមានសមាសភាគអ្វីខ្លះ និងត្រូវបានប្រើយ៉ាងដូចម្តេច
• Design tokens៖ តម្លៃអត្ថន័យដែលកូដការសម្រេចចិត្តរចនាជាអង្គហេតុបរិស្ថាន
• ឯកសារគំរូ៖ ឧទាហរណ៍ប្រើប្រាស់ដែលដើរតួជាផ្លូវផេរ៉ូម៉ូនសម្រាប់ភ្នាក់ងារនាពេលអនាគត
• សំណុំតេស្ត៖ ច្បាប់ផ្ទៀងផ្ទាត់ដែលកម្រិតលំហនៃលទ្ធផលត្រឹមត្រូវ
• ប្រវត្តិ Git៖ កំណត់ត្រានៃការសម្រេចចិត្តពីមុនដែលភ្នាក់ងារអាចយោងបាន

នៅពេលភ្នាក់ងារបង្កើត UI ដោយប្រើសមាសភាគមួយ វាទុកស្នាមដាន ទាំងនៅក្នុងមូលដ្ឋានកូដ នៅក្នុងឯកសារ និងនៅក្នុងគំរូដែលវាបង្កើតឡើង។ ភ្នាក់ងារនាពេលអនាគតដែលជួបកិច្ចការស្រដៀងគ្នានឹងរងឥទ្ធិពលពីស្នាមដានទាំងនេះ ដែលបង្កើតជាទម្រង់នៃបញ្ញារួមមួយ ដែលគ្មានភ្នាក់ងារណាម្នាក់មានតែឯងបានឡើយ។

គំរូរចនាភ្នាក់ងារ

Andrew Ng និងអ្នកផ្សេងទៀតបានកំណត់អត្តសញ្ញាណគំរូសំខាន់ៗចំនួនបួនសម្រាប់ប្រព័ន្ធ AI បែបភ្នាក់ងារ៖

1. ការឆ្លុះបញ្ចាំង (Reflection)៖ AI វាយតម្លៃលទ្ធផលរបស់ខ្លួនឯង ហើយកែលម្អវាម្តងហើយម្តងទៀត
2. ការប្រើឧបករណ៍ (Tool Use)៖ AI ធ្វើអន្តរកម្មជាមួយឧបករណ៍ API និងប្រព័ន្ធខាងក្រៅ
3. ការធ្វើផែនការ (Planning)៖ AI បំបែកកិច្ចការស្មុគស្មាញជាកិច្ចការរងៗ ហើយអនុវត្តតាមលំដាប់លំដោយ
4. ពហុភ្នាក់ងារ (Multi-Agent)៖ ភ្នាក់ងារឯកទេសជាច្រើនសហការគ្នាលើកិច្ចការស្មុគស្មាញ

លំនាំទាំងនេះត្រូវគ្នាដោយផ្ទាល់ជាមួយគំនិតនៃស្វ័យប្រវត្តិកម្មកោសិកា (cellular automata)៖

ការរចនាគឺជាកូដ — ការអានស៊ីជម្រៅ

អ្វីដែល «ការរចនាគឺជាកូដ» មានន័យពិតប្រាកដ

ពេលយើងនិយាយថា «ការរចនាគឺជាកូដ» យើងកំពុងអះអាងរឿងជាច្រើនក្នុងពេលតែមួយ៖

១. សមមូលផ្នែកនិយមន័យ (Semantic Equivalence)

ការសម្រេចចិត្តផ្នែករចនា នៅពេលដែលត្រូវបានអ៊ិនកូដឲ្យត្រឹមត្រូវ នឹងក្លាយជាអ្វីដែលអាចអនុវត្តបាន។ design token មិនមែនគ្រាន់តែជាតម្លៃមួយទេ — វាជាសេចក្តីណែនាំ។ លក្ខណៈបច្ចេកទេសរបស់សមាសភាគមិនមែនគ្រាន់តែជាឯកសារទេ — វាជាកម្មវិធី។ នៅពេលភ្នាក់ងារប្រើប្រាស់វត្ថុទាំងនេះ ពួកវាកំពុងអនុវត្តការរចនា ក៏ដូចជាកំពុងសាងសង់វាដែរ។

២. សមត្ថភាពបង្កើត (Generative Capacity)

ដូចដែល Rule 110 អាចគណនាអ្វីៗទាំងអស់ដែលអាចគណនាបាន ប្រព័ន្ធរចនាដែលពេញលេញគ្រប់គ្រាន់ក៏អាចបង្កើតចំណុចប្រទាក់ត្រឹមត្រូវណាមួយបានដែរ។ ប្រព័ន្ធមានសក្តានុពលសម្រាប់រាល់ទម្រង់ត្រឹមត្រូវទាំងអស់របស់វា។ អ្វីដែលលេចចេញមក អាស្រ័យតែលើលក្ខខណ្ឌដំបូង (តម្រូវការ) និងច្បាប់ (ការកំណត់) ប៉ុណ្ណោះ។

៣. ភាពស្មុគស្មាញដែលលេចចេញដោយខ្លួនឯង (Emergent Complexity)

ចំណុចប្រទាក់ដ៏ទំនើបបំផុតមិនមែនត្រូវបានរចនាពីលើចុះក្រោមទេ ពួកវាលេចចេញពីការអនុវត្តច្បាប់សាមញ្ញៗឲ្យស្របគ្នា។ ប៊ូតុងដែលរចនាបានល្អ នៅពេលប្រើប្រាស់ឲ្យស្របគ្នា បង្កើតភាសាមើលឃើញដែលស្អិតរមួត ដោយគ្មាននរណាម្នាក់ធ្វើផែនការភាពស្អិតរមួតនោះច្បាស់លាស់ឡើយ។

៤. ភាពមិនអាចកាត់បន្ថយបានផ្នែកគណនា (Computational Irreducibility)

លទ្ធផលរចនាខ្លះមិនអាចទស្សន៍ទាយបានទេ ប្រសិនបើមិនបានដំណើរការប្រព័ន្ធពិតប្រាកដ។ អ្នកមិនអាចដឹងថាចំណុចប្រទាក់ដែលភ្នាក់ងារបណ្តុំឡើងនឹងមើលទៅដូចម្តេច ដោយមិនទុកឲ្យភ្នាក់ងារបណ្តុំវាឡើយ។ នេះគឺជាគោលការណ៍ computational irreducibility របស់ Wolfram ដែលអនុវត្តលើការរចនា។

៥. ការកែប្រែខ្លួនឯង (Self-Modification)

ដូច evoloops ដែលផ្លាស់ប្តូរពេលចម្លងខ្លួន ប្រព័ន្ធរចនាដែលរួចរាល់សម្រាប់ភ្នាក់ងារក៏អាចវិវត្តតាមរយៈការប្រើប្រាស់ដែរ។ សមាសភាគដែលភ្នាក់ងារបង្កើតក្លាយជាផ្នែកមួយនៃបណ្ណាល័យ ដែលភ្នាក់ងារនាពេលអនាគតនឹងប្រើប្រាស់។ ប្រព័ន្ធរៀនសូត្រ សម្របខ្លួន និងលូតលាស់។

ការពង្រីកសេចក្តីប្រៀបធៀបស្វ័យប្រវត្តិកម្មកោសិកា

ហួសពីសេចក្តីប្រៀបធៀប៖ ការបញ្ចូលគ្នាពិតប្រាកដ

ប៉ុន្តែនេះមិនមែនគ្រាន់តែជាសេចក្តីប្រៀបធៀបទេ។ ការបញ្ចូលគ្នានេះគឺពិត ហើយកំពុងកើតឡើងឥឡូវនេះ៖

• Storybook MCP បំប្លែងបណ្ណាល័យសមាសភាគទៅជាសេចក្តីណែនាំដែលម៉ាស៊ីនអាចអាន ដែលភ្នាក់ងារអនុវត្តតាម
• Model Context Protocol កំណត់ស្តង់ដារអំពីរបៀបដែលភ្នាក់ងារចូលដំណើរការឧបករណ៍ និងបរិបទ ដោយបង្កើតមូលដ្ឋានសកលសម្រាប់ប្រតិបត្តិការតាមភ្នាក់ងារ
• ស្ថាបត្យកម្មពហុភ្នាក់ងារ បែងចែកការងារក្នុងចំណោមភ្នាក់ងារឯកទេស (ស្ថាបត្យករ អ្នកសរសេរកូដ អ្នកត្រួតពិនិត្យ) ដែលមានអន្តរកម្មតាមពិធីការ ដូចកោសិកាដែលមានមុខងារខុសគ្នា
• រង្វិលជុំព្យាបាលខ្លួនឯងញ៉ាំងឱ្យភ្នាក់ងារអាចដំណើរការតេស្ត រកឃើញកំហុស និងធ្វើឡើងវិញម្ដងហើយម្ដងទៀត ដែលជាយន្តការផ្ដល់ការឆ្លើយតបដូចគ្នាទៅនឹងអ្វីដែលអូតូម៉ាតាសែល្លុយឡែរ (cellular automata) ប្រើដើម្បីវិវត្តទៅជាទម្រង់រចនាសម្ព័ន្ធមានស្ថិរភាព
• Schema.org Blueprints ធ្វើឱ្យរចនាសម្ព័ន្ធមាតិកាអាចឱ្យម៉ាស៊ីនអានបាន និងមានអត្ថន័យតាមន័យវិទ្យា
• Drupal AI ផ្ដល់ហេដ្ឋារចនាសម្ព័ន្ធឱ្យភ្នាក់ងារ AI បង្កើត កែប្រែ និងគ្រប់គ្រងមាតិកាដោយស្វ័យប្រវត្តិ

យើងមិនមែនកំពុងមើលពាក្យថា «ការរចនាគឺជាកូដ» ជាជំហរទស្សនវិជ្ជាទេ។ យើងកំពុងកសាងវាជាហេដ្ឋារចនាសម្ព័ន្ធបច្ចេកទេស។

ផលប៉ះពាល់ និងផ្លូវខាងមុខ

សម្រាប់អ្នករចនា

តួនាទីរបស់អ្នករចនាកំពុងផ្លាស់ប្ដូរពី «អ្នកបង្កើតចតុកោណកែង» ទៅជា «អ្នកកំណត់ច្បាប់»។ ដូចដែល Brad Frost បានសង្កេតឃើញ៖

«អ្នករចនា និងអ្នកអភិវឌ្ឍដែលគិតថាការងាររបស់ខ្លួនគឺជាអ្នកបង្កើតចតុកោណកែង មានមូលហេតុច្រើនដែលត្រូវបារម្ភ។ ប៉ុន្តែអ្នករចនា និងអ្នកអភិវឌ្ឍដែលគិតថាការងាររបស់ខ្លួនគឺដោះស្រាយបញ្ហា ហើយគ្រាន់តែចៃដន្យត្រូវបង្កើត/ប្រើចតុកោណកែងខ្លះដើម្បីដោះស្រាយបញ្ហាទាំងនោះ នឹងមានអ្វីត្រូវភ័យខ្លាចតិចជាង។»

- Brad Frost

នៅអនាគតដែលមានភ្នាក់ងារ អ្នករចនានឹង៖

• កំណត់ថូខឹនតាមន័យវិទ្យា និងទំនាក់ទំនងរវាងថូខឹនទាំងនោះ
• បង្កើតឧបសគ្គនៃការផ្សំ និងគំរូរចនា
• បង្កើតច្បាប់ផ្ទៀងផ្ទាត់ដែលភ្នាក់ងារត្រូវបំពេញ
• ថែរក្សា និងអភិវឌ្ឍច្បាប់ដែលគ្រប់គ្រងការលេចចេញជារូបរាង
• រចនាយន្តការផ្ដល់ការឆ្លើយតបដែលអនុញ្ញាតឱ្យកែតម្រូវខ្លួនឯងបាន
• ជំរុញ «អនុគមន៍សមត្ថភាព» (fitness functions) ដែលកំណត់ថាលទ្ធផលណាអាចទទួលយកបាន

នេះគឺជាការរចនានៅកម្រិតអរូបីខ្ពស់ជាងមុន គឺរចនាច្បាប់ដែលបង្កើតការរចនា ជាជាងរចនាការរចនាខ្លួនឯង។ ដូចជាការកំណត់ច្បាប់របស់អូតូម៉ាតាសែល្លុយឡែរ ជាជាងគូរសែល្លុយឡែមួយៗដោយដៃ។

សម្រាប់អ្នកអភិវឌ្ឍ

អ្នកអភិវឌ្ឍក្លាយជាស្ថាបត្យករនៃប្រព័ន្ធភ្នាក់ងារ។ ដូចដែល Anthropic ពណ៌នា៖

«វិស័យអភិវឌ្ឍកម្មវិធីបានបង្ហាញសក្តានុពលគួរឱ្យកត់សម្គាល់សម្រាប់មុខងារ LLM ដោយសមត្ថភាពវិវត្តពីការបំពេញកូដស្វ័យប្រវត្តិ ទៅជាការដោះស្រាយបញ្ហាដោយស្វ័យភាព។»

អ្នកអភិវឌ្ឍនឹងត្រូវ៖

• បង្កើតចំណុចប្រទាក់ដែលម៉ាស៊ីនអានបាន រវាងភ្នាក់ងារ និងប្រព័ន្ធ
• រចនារង្វិលនៃការឆ្លើយតប និងយន្តការផ្ទៀងផ្ទាត់
• សាងសង់រចនាសម្ព័ន្ធទ្រទ្រង់ ដែលឥរិយាបថលេចចេញជារូបរាងកើតឡើងនៅក្នុងនោះ
• រក្សាការត្រួតពិនិត្យរបស់មនុស្សជាអ្នកសម្រេចចុងក្រោយ
• កំណត់ពិធីការដែលភ្នាក់ងារប្រើដើម្បីទំនាក់ទំនងគ្នា
• អនុវត្ត «កូដស្អិត» (glue code) ដែលតភ្ជាប់ប្រព័ន្ធភ្នាក់ងារផ្សេងៗគ្នា

សម្រាប់ការអភិវឌ្ឍគេហទំព័រ និងវេទិកា CMS

ការរួមបញ្ចូល AI ទៅក្នុងវេទិកាដូចជា Drupal ចង្អុលទៅអនាគតមួយដែល៖

• គំរូមាតិកាក្លាយជាអ្វីដែលភ្នាក់ងារអាចប្រើប្រាស់បាន តាមរយៈស្តង់ដារដូចជា Schema.org
• លំហូរការងារនិពន្ធនាការក្លាយជាអ្វីដែលមានភ្នាក់ងារជួយ ជាមួយការព្រាង ការគ្រប់គ្រង និងការបង្កើនប្រសិទ្ធភាពដោយ AI
• ការស្វែងរកវិវត្ត ពីការផ្គូផ្គងពាក្យគន្លឹះ ទៅការយល់តាមន័យវិទ្យាតាមរយៈ embeddings និងមូលដ្ឋានទិន្នន័យវ៉ិចទ័រ
• ការផ្ទាល់ខ្លួនក្លាយជាស្វ័យភាព ដោយភ្នាក់ងាររៀនពីចំណូលចិត្តរបស់អ្នកប្រើ ហើយកែសម្រួលមាតិកាតាមពេលវេលាជាក់ស្តែង
• ការអភិវឌ្ឍលឿនឡើង ដោយភ្នាក់ងារបង្កើតសមាសធាតុ តេស្ត និងឯកសារ

ការទទួលយក AI របស់ប្រព័ន្ធអេកូឡូស៊ី Drupal តាមរយៈម៉ូឌុលដូចជា Drupal AI, Drupal Canvas, Schema.org Blueprints និងការរួមបញ្ចូលអ្នកផ្ដល់សេវា AI បង្ហាញថាអនាគតនេះកំពុងត្រូវបានកសាងឡើងរួចហើយ។

សម្រាប់អង្គការ

អត្ថប្រយោជន៍ក្នុងការប្រកួតប្រជែងនឹងជារបស់អង្គការដែលប្រព័ន្ធរចនារបស់ខ្លួន «ត្រៀមខ្លួនសម្រាប់ភ្នាក់ងារ» បំផុត។ ប្រព័ន្ធដែលត្រៀមសម្រាប់ភ្នាក់ងារមានលក្ខណៈ៖

• គ្របដណ្តប់ពេញលេញលើស្ថានភាព និងវ៉ារីយ៉ង់នៃសមាសធាតុ
• ការដាក់ឈ្មោះតាមន័យវិទ្យាដែលបង្ហាញពីចេតនា
• ឯកសារ និងបរិបទដែលម៉ាស៊ីនអានបាន
• ហេដ្ឋារចនាសម្ព័ន្ធផ្ទៀងផ្ទាត់ និងតេស្ត
• ឧបសគ្គច្បាស់លាស់ដែលកំណត់ព្រំដែននៃលទ្ធផលត្រឹមត្រូវ
• API ដែលរចនាសម្រាប់ការប្រើប្រាស់ដោយភ្នាក់ងារ (AX-first)
• ស្ថាបត្យកម្មមាតិកាដែលយក Schema.org ជាចម្បង

សម្រាប់អនាគតនៃផលិតផលឌីជីថល

ស្ថានភាពចុងក្រោយគឺប្រៀបដូចជាប្រព័ន្ធអេកូឡូស៊ីឌីជីថល—ភ្នាក់ងារឥតគណនាដែលដំណើរការតាមច្បាប់មូលដ្ឋាន ហើយបង្កើតចេញជាចំណុចប្រទាក់ដែលផុសឡើងដោយខ្លួនឯង ដែលគ្មានអ្នករចនា ឬអ្នកអភិវឌ្ឍន៍ណាម្នាក់ធ្លាប់គ្រោងទុក ប៉ុន្តែយ៉ាងណាក៏ដោយវាភ្ជាប់គ្នាបានយ៉ាងសុសសាច់ ព្រោះច្បាប់ដែលនៅពីក្រោមនោះមានមូលដ្ឋានរឹងមាំ។

រឿងនេះមិនមែនឆ្ងាយពីការពិតដូចដែលស្តាប់ទៅនោះទេ។ វាគឺជារបៀបដែលប្រព័ន្ធជីវសាស្ត្រដំណើរការ របៀបដែលទីក្រុងរីកលូតលាស់ និងរបៀបដែលទីផ្សារដំណើរការយ៉ាងពិតប្រាកដ។ សំណួរមិនមែនថាតើយើងនឹងទៅដល់ស្ថានភាពនេះឬអត់នោះទេ—ប៉ុន្តែគឺថាតើយើងនឹងឆ្លងកាត់ដំណាក់កាលផ្លាស់ប្តូរនេះដោយរបៀបណា។

សេចក្តីសន្និដ្ឋាន៖ កូដមានជីវិត

John von Neumann ជាអ្នកប្រាជ្ញច្រើនផ្នែកដែលបានបង្កើតស៊ែលុយឡារ អូតូម៉ាតា (cellular automata) ត្រូវបានជំរុញដោយសំណួរគ្រឹះមួយថា៖ តើភាពស្មុគស្មាញអប្បបរមាដែលត្រូវការសម្រាប់ការបន្តពូជដោយខ្លួនឯងគឺប៉ុន្មាន? ចម្លើយរបស់គាត់—អ្នកសាងសង់សកលរបស់ von Neumann—បានបង្ហាញថា ការចម្លងខ្លួនឯងមិនត្រូវការយន្តការជីវសាស្ត្រទេ។ វាត្រូវការតែច្បាប់ដែលអ៊ិនកូដការអនុវត្តរបស់ខ្លួនឯងប៉ុណ្ណោះ។

ចិតសិបឆ្នាំក្រោយមក យើងកំពុងរកឃើញថា គោលការណ៍ដូចគ្នានេះក៏អនុវត្តបានចំពោះប្រព័ន្ធរចនាដែរ។ តម្រូវការអប្បបរមាសម្រាប់ការបង្កើត UI ដោយស្វ័យប្រវត្តិ មិនមែនជាបញ្ញាសិប្បនិម្មិតទូទៅ ឬភាពច្នៃប្រឌិតកម្រិតមនុស្សនោះទេ។ វាគឺជាសំណុំច្បាប់ដែលពេញលេញ ស៊ីសង្វាក់គ្នា និងម៉ាស៊ីនអាចអានបាន ដែលភ្នាក់ងារអាចប្រតិបត្តិតាម។

នៅពេលដែល Langton's Loops ចម្លងខ្លួនឯងឆ្លងកាត់ក្រឡាចត្រង្គស៊ែលុយឡារ យើងមិននិយាយថាស្ពៀរទាំងនោះកំពុង "រចនា" ស្ពៀរថ្មីៗនោះទេ។ ការចម្លងគ្រាន់តែជាអ្វីដែលច្បាប់បង្កើតចេញមកប៉ុណ្ណោះ។ ប៉ុន្តែលទ្ធផល—អាណានិគមនៃគំរូស្រដៀងគ្នាដែលរីកធំឥតឈប់ឈរ—គឺបង្កើតថ្មីពិតប្រាកដ និងមានភាពច្នៃប្រឌិតក្នុងន័យមុខងារមួយ។

នៅពេលដែលភ្នាក់ងារ AI ផ្គុំចំណុចប្រទាក់ពីសមាសភាគនៃប្រព័ន្ធរចនា ដោយធ្វើតាមថូខិនន័យ (semantic tokens) និងឧបសគ្គនៃការតភ្ជាប់ពួកគេកំពុងធ្វើអ្វីមួយស្រដៀងគ្នា។ "ភាពច្នៃប្រឌិត" មិននៅក្នុងភ្នាក់ងារទេ ប៉ុន្តែនៅក្នុងច្បាប់ដែលពួកវាប្រតិបត្តិ—ច្បាប់ដែលមនុស្សបានរចនា តែឥឡូវនេះដំណើរការដោយឯករាជ្យ។

យើងកំពុងឈរនៅមាត់ទ្វារនៃយុគសម័យថ្មីក្នុងការបង្កើតឌីជីថល។ ភ្នាក់ងារបានមកដល់ហើយ។ ពិធីសារកំពុងត្រូវបានបង្កើតឡើង។ ប្រព័ន្ធរចនាកំពុងក្លាយជាស្រទាប់ខាងក្រោមសម្រាប់ជីវិតសិប្បនិម្មិត។

ការរចនាគឺជាកូដ។
ហើយកូដកំពុងមានជីវិត។

អត្ថបទ និងគម្រោងសំខាន់ៗ

• Design Systems in the Time of AI - Brad Frost
• Storybook MCP Sneak Peek - Storybook
• Introducing AX: Why Agent Experience Matters - Mathias Biilmann
• Building Effective Agents - Anthropic

ធនធាន Drupal AI

• Drupal AI

• Schema.org Blueprints Module

   

ធនធានស៊ែលុយឡារ អូតូម៉ាតា

• Conway's Game of Life Lexicon - ប្រហែល ១៥០០ រូបរាង
• A Working Turing Machine in Game of Life
• Langton's Loops - Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online - Stephen Wolfram
• Cellular Automata - Nature of Code

បានស្វែងយល់គំនិតនៅចំណុចប្រសព្វរវាងទ្រឹស្តីគណនា ប្រព័ន្ធរចនា បញ្ញាសិប្បនិម្មិត និងការអភិវឌ្ឍវេប។

 ទស្សនៈដែលបានបង្ហាញគឺជាការស្វែងយល់តាមការស្មានអំពីនិន្នាការថ្មីៗ មិនមែនជាការទស្សន៍ទាយអំពីអនាគតដែលប្រាកដនោះទេ។

ខ្ញុំឃើញថា យើងកំពុងបង្កើតភ្នាក់ងារ AI ដែលធ្វើការជាមួយរង្វិលជុំ ហើយទាក់ទងជាមួយភ្នាក់ងារ AI ផ្សេងទៀតក្នុងរង្វិលជុំបន្ថែម។

ការរចនា គឺជា កូដ នៅពេលដែលប្រព័ន្ធដំណើរការជារង្វិលជុំ ដូចរង្វិលជុំនៃអាយុជីវិត ក្នុងផ្ទាំងបង្ហាញ និងសំណុំច្បាប់ដែលបានជ្រើសរើស។