การออกแบบคือโค้ด

ตรรกะของเซลลูลาร์ออโตมาตาจะกำหนดรูปแบบใหม่ให้ระบบออกแบบเชิงเอเจนต์อย่างไร และเหตุใดอนาคตของการพัฒนาเว็บอาจถูกเขียนไว้แล้วในกฎง่ายๆ

กำลังมีการเปลี่ยนแปลงครั้งใหญ่เกิดขึ้นตรงจุดที่ระบบออกแบบ ปัญญาประดิษฐ์ และทฤษฎีการคำนวณมาบรรจบกัน เป็นการเปลี่ยนที่ลึกซึ้งถึงขั้นท้าทายความเข้าใจของเราว่า "การออกแบบ" หมายถึงอะไรในยุคของเอเจนต์อัตโนมัติ

หลายสิบปีที่ผ่านมา เรามองการออกแบบกับโค้ดเป็นศาสตร์คนละสาย การออกแบบคือพื้นที่ของความคิดสร้างสรรค์และวิจารณญาณทางสุนทรียะของมนุษย์ ส่วนโค้ดคือการแปลงความคิดเหล่านั้นให้เป็นรูปแบบที่รันได้ตามกลไก แต่เมื่อเอเจนต์ AI ประกอบส่วนติดต่อผู้ใช้ด้วยตัวเองมากขึ้นเรื่อยๆ ใช้ระบบออกแบบเป็นโครงสร้างพื้นฐานที่เครื่องอ่านได้ และสร้างโค้ดจากโทเคนเชิงความหมาย เราก็กำลังเข้าใกล้จุดบรรจบที่สะท้อนแนวคิดที่เก่าแก่กว่ามากจากทฤษฎีการคำนวณ

แนวคิดนั้นคืออะไร? การออกแบบคือโค้ด

นี่ไม่ใช่แค่วลีติดหู แต่เป็นการยอมรับว่าเรากำลังมุ่งสู่โลกที่ระบบออกแบบทำงานเหมือนเซลลูลาร์ออโตมาตา คือกฎง่ายๆ ที่ก่อให้เกิดพฤติกรรมซับซ้อนแบบอุบัติ โลกที่เส้นแบ่งระหว่างการ "ออกแบบ" สิ่งหนึ่งกับการ "เขียนโปรแกรม" มันสลายหายไปจนหมด โลกที่เอเจนต์อัตโนมัติไม่ได้แค่ ใช้ระบบออกแบบ แต่ เป็นระบบออกแบบที่กำลังทำงานอยู่

บล็อกโพสต์นี้สำรวจความเชื่อมโยงเชิงลึกระหว่างเซลลูลาร์ออโตมาตา พฤติกรรมอุบัติ และอนาคตของระบบออกแบบเชิงเอเจนต์ เราจะไล่ดูรากฐานทางทฤษฎีตั้งแต่เครื่องจักรที่ทำซ้ำตัวเองของ von Neumann มาจนถึงฝูงเอเจนต์ AI ในปัจจุบัน

เราจะพิจารณาว่า Drupal และแพลตฟอร์ม CMS สมัยใหม่กำลังผสานรวม AI ผ่านโมดูลอย่าง Schema.org Blueprints และ Drupal AI อย่างไร และจะลองคิดว่าทั้งหมดนี้มีความหมายอย่างไรต่อนักออกแบบ นักพัฒนา และอนาคตของการสร้างผลิตภัณฑ์ดิจิทัล

เซลลูลาร์ออโตมาตากับตรรกะของการอุบัติ

ความงามของกฎง่ายๆ

ในปี 1970 John Conway นักคณิตศาสตร์ได้เสนอเกมชีวิต (Game of Life) ซึ่งเป็น "เกมที่ไม่มีผู้เล่น" และกลายเป็นหนึ่งในระบบที่ถูกศึกษามากที่สุดในทฤษฎีการคำนวณ กฎของมันเรียบง่ายอย่างน่าทึ่ง:

1. เซลล์ที่มีชีวิตและมีเซลล์เพื่อนบ้านที่มีชีวิตน้อยกว่าสองเซลล์ จะตาย (ประชากรน้อยเกินไป)
2. เซลล์ที่มีชีวิตและมีเซลล์เพื่อนบ้านที่มีชีวิตสองหรือสามเซลล์ จะอยู่รอดต่อไป
3. เซลล์ที่มีชีวิตและมีเซลล์เพื่อนบ้านที่มีชีวิตมากกว่าสามเซลล์ จะตาย (ประชากรหนาแน่นเกินไป)
4. เซลล์ที่ตายแล้วและมีเซลล์เพื่อนบ้านที่มีชีวิตสามเซลล์พอดี จะกลับมามีชีวิต (การสืบพันธุ์)

จากกฎสี่ข้อนี้ ซึ่งเขียนได้ด้วยเงื่อนไขแบบไบนารีเพียงไม่กี่ข้อ ได้ก่อกำเนิดจักรวาลแห่งความซับซ้อนอันน่าอัศจรรย์ เกลเดอร์เคลื่อนข้ามตารางไร้ขอบเขต ออสซิลเลเตอร์เต้นเป็นจังหวะไม่รู้จบ กันส์ยิงสายธารรูปแบบพุ่งผ่านปริภูมิของเซลล์ และที่น่าทึ่งที่สุดคือ มีการพิสูจน์แล้วว่าเกมชีวิต สมบูรณ์แบบทัวริง กล่าวคือ สิ่งใดก็ตามที่คำนวณได้ด้วยอัลกอริทึม ก็สามารถคำนวณได้ในตารางเรียบง่ายของ Conway ในทางหลักการ

รูปที่ 1: ปืนร่อน (Glider Gun) ของ Gosper ใน Game of Life ของ Conway แพตเทิร์นนี้ผลิตกลุ่มไกลเดอร์ออกมาไม่หยุด แสดงให้เห็นว่ากฎง่าย ๆ สามารถก่อให้เกิดความซับซ้อนที่ไม่มีที่สิ้นสุดและสืบทอดตัวเองต่อไปได้

นี่คือบทเรียนแรกของเซลลูลาร์ออโตมาตา: พฤติกรรมที่ซับซ้อนไม่จำเป็นต้องมีความซับซ้อนเป็นจุดตั้งต้น กฎง่าย ๆ ที่ใช้อย่างสม่ำเสมอบนพื้นผิวเดียวกัน สามารถให้กำเนิดแพตเทิร์นและพฤติกรรมที่ไม่มีใครเขียนโปรแกรมไว้อย่างชัดเจนได้

Langton's Loops กับการจำลองตัวเอง

ในปี 1984 คริสโตเฟอร์ แลงตัน (Christopher Langton) ต่อยอดหลักการนี้ไปอีกขั้นด้วยลูปที่จำลองตัวเองได้ ซึ่งเป็นเซลลูลาร์ออโตมาตาที่แสดงหลักการของชีวิตเทียมอย่างแท้จริง ต่างจาก Game of Life ของ Conway ที่แสดงความซับซ้อนที่ผุดบังเกิดขึ้นเอง Langton's Loops แสดงให้เห็นการสืบพันธุ์.

ที่ผุดบังเกิดขึ้นเอง ลูปแต่ละอันประกอบด้วยขอบเขตวนรอบที่ล้อม "จีโนม" ซึ่งเข้ารหัสไว้ในสถานะของเซลล์ จีโนมนี้ไหลวนรอบลูปอย่างต่อเนื่องและออกไปตามแขนก่อสร้าง ซึ่งสร้างลูปลูกขึ้นมาในเวลา 151 ขั้น เมื่อสร้างเสร็จ ลูปลูกจะแยกตัวออกจากลูปแม่ แล้วทั้งสองก็จำลองตัวเองต่อไป

รูปที่ 2: Langton's Loop ในรูปแบบเริ่มต้น ข้อมูลทางพันธุกรรมไหลเวียนอยู่ในลูปและสั่งการให้สร้างลูปลูกผ่านแขนที่ยื่นออกไป

"หากเครื่องจักรที่สืบพันธุ์ตัวเองได้เป็นไปได้ภายในเซลลูลาร์ออโตมาตา ชีวิตเองก็อาจเกิดขึ้นได้ด้วยเครื่องจักร"

- คริสโตเฟอร์ แลงตัน (Christopher Langton), "Studying Artificial Life with Cellular Automata" (1986)

นัยของมันลึกซึ้งมาก Langton's Loops แสดงให้เห็นว่าการจำลองตัวเองไม่จำเป็นต้องอาศัยความซับซ้อนของเซลล์ชีวภาพ หรือความสามารถในการสร้างแบบสากลตามแบบเดิมของฟอน นอยมันน์ (von Neumann) แต่ต้องการเพียง:

• ชุดกฎท้องถิ่นง่าย ๆ
• กลไกสำหรับเข้ารหัสคำสั่ง
• กระบวนการที่ทำให้คำสั่งเหล่านั้นถูกดำเนินการ

กฎคือ ตัวสิ่งมีชีวิตนั้นเอง การออกแบบคือ โค้ด

ในปี 1999 ฮิโรกิ ซายามะ (Hiroki Sayama) เสนอ evoloops ซึ่งเป็นรูปแบบต่อยอดที่รวมความสามารถในการสลายโครงสร้างและปฏิสัมพันธ์ของฟีโนไทป์ ทำให้เกิดการกลายพันธุ์เองและพลวัตเชิงวิวัฒนาการได้ ลูปเหล่านี้วิวัฒนาการผ่านการชนกันทางกายภาพโดยตรงระหว่างการจำลองตัวเอง นำไปสู่ความแปรผันของจีโนไทป์ ความหลากหลายทางสัณฐานที่เพิ่มขึ้น และความซับซ้อนที่เติบโตขึ้นข้ามรุ่น ต่างจากการจำลองตัวเองแบบตายตัวของ Langton, evoloops แสดงให้เห็นการกลายพันธุ์ที่ถ่ายทอดได้โดยไม่ต้องมีปัจจัยภายนอกเข้ามาแทรกแซง

Rule 110 กับการคำนวณสากล

การสำรวจเซลลูลาร์ออโตมาตาแบบพื้นฐานของสตีเฟน วอลแฟรม (Stephen Wolfram) นำไปสู่การค้นพบที่น่าทึ่ง: Rule 110 ซึ่งเป็นหนึ่งในกฎที่เป็นไปได้เพียง 256 กฎสำหรับเซลลูลาร์ออโตมาตามิติเดียวแบบง่ายที่สุด สามารถทำการคำนวณสากลได้

กฎ 110 สามารถกำหนดได้ครบถ้วนเพียงระบุผลลัพธ์สำหรับแต่ละกรณีจากทั้งหมดแปดกรณีที่เป็นไปได้ของเซลล์หนึ่งกับเซลล์ข้างเคียงสองเซลล์ ทว่ากฎที่เรียบง่ายอย่างยิ่งนี้ ซึ่งมีเพียงการตัดสินใจแบบไบนารีแปดข้อ ก็สามารถจำลองเครื่องจักรทัวริงสากลได้

รูปที่ 3: ออโตมาตาเซลลูลาร์กฎ 110 แม้นิยามจะเรียบง่าย แต่กฎ 110 แสดงพฤติกรรมคลาส 4 คือรูปแบบซับซ้อนที่ไม่นิ่งสนิทและไม่วุ่นวายเต็มที่ และได้รับการพิสูจน์แล้วว่าทัวริงสมบูรณ์

"เราไม่จำเป็นต้องมีอะไรที่ใกล้เคียงซีพียูของคอมพิวเตอร์ทั้งเครื่องเลยเพื่อทำการคำนวณสากล เราต้องการเพียงกฎเล็ก ๆ ข้อนี้เท่านั้น"

- Stephen Wolfram, "A New Kind of Science"

ในปี 2004 Matthew Cook ได้เผยแพร่บทพิสูจน์ว่ากฎ 110 ที่มีรูปแบบพื้นหลังซ้ำเฉพาะแบบหนึ่งนั้นทัวริงสมบูรณ์ บทพิสูจน์แสดงให้เห็นว่ากฎ 110 สามารถจำลองระบบแท็กแบบวนรอบ (cyclic tag system) ซึ่งสามารถจำลองเครื่องจักรทัวริงใด ๆ ได้อีกทอดหนึ่ง ในบรรดาออโตมาตาเซลลูลาร์พื้นฐานที่ไม่ซ้ำกัน 88 แบบ กฎ 110 เป็นกฎเดียวที่ได้รับการพิสูจน์โดยตรงว่าทัวริงสมบูรณ์

หลักความเท่าเทียมเชิงการคำนวณ ที่ Wolfram เสนอนั้นสื่อถึงสิ่งที่รุนแรงยิ่งกว่า คือระบบที่มีความซับซ้อนเกินเกณฑ์ขั้นต่ำระดับหนึ่งล้วนมีความสามารถในการคำนวณเทียบเท่ากันโดยพื้นฐาน สมองมนุษย์ ระบบสภาพอากาศ และกฎ 110 ต่างก็เทียบเท่ากันในเชิงการคำนวณ ในความหมายที่ลึกซึ้งอย่างหนึ่ง

0E0P เมตาเซลล์: การจำลองตัวเองที่แท้จริง

ในเดือนตุลาคม 2018 Adam P. Goucher สร้าง 0E0P เมตาเซลล์ สำเร็จ ซึ่งเป็นรูปแบบในเกมชีวิตของ Conway ที่สามารถจำลองตัวเองได้อย่างแท้จริง ต่างจากเมตาเซลล์รุ่นก่อน ๆ ที่ต้องมีสำเนาอยู่ใกล้เคียงมาก่อน 0E0P เมตาเซลล์สามารถสร้างสำเนาของตัวเองขึ้นมาจากศูนย์ได้ รวมถึงเทปคำสั่งของมันเองด้วย

ความสำเร็จนี้เป็นหมุดหมายสำคัญของชีวิตเทียม คือระบบที่แพร่พันธุ์ตัวเองผ่านสารตั้งต้นเชิงการคำนวณได้โดยใช้เพียงกฎเฉพาะที่ เมื่อวันที่ 23 พฤศจิกายน 2013 Dave Greene สร้างตัวจำลองตัวแรกในเกมชีวิตที่สร้างสำเนาสมบูรณ์ของตัวเองได้ รวมถึงเทปคำสั่ง ซึ่งแสดงให้เห็นว่าแม้ออโตมาตาสองสถานะอย่างง่ายของ Conway ก็รองรับการสืบพันธุ์ตัวเองได้อย่างไม่มีขีดจำกัด

ระบบการออกแบบในฐานะสารตั้งต้นเชิงการคำนวณ

จาก Atomic Design สู่ Agentic Design

วิธีการ Atomic Design ของ Brad Frost ซึ่งเปิดตัวในปี 2013 ได้ปฏิวัติวิธีคิดของเราเกี่ยวกับระบบการออกแบบ ด้วยการแบ่งอินเทอร์เฟซออกเป็นอะตอม (องค์ประกอบพื้นฐานอย่างปุ่มและช่องกรอกข้อมูล) โมเลกุล (การรวมกันอย่างง่าย) ออร์แกนิซึม (ส่วนต่าง ๆ ของ UI ที่ซับซ้อน) เทมเพลต (เลย์เอาต์ของหน้า) และหน้า (การนำไปใช้จริงขั้นสุดท้าย) Atomic Design จึงให้โครงสร้างแบบลำดับชั้นสำหรับจัดการความซับซ้อน

แต่สิ่งที่น่าทึ่งเมื่อมองย้อนกลับไปคือ Atomic Design แฝงหลักการของออโตมาตาเซลลูลาร์อยู่แล้ว โดยที่ไม่ได้ตั้งใจระบุไว้อย่างชัดเจน

"เมื่อระบบการออกแบบเป็นเรื่องน่าเบื่อ นักออกแบบและนักพัฒนาก็เป็นอิสระที่จะไปทำสิ่งใหม่ ๆ และแก้ปัญหาใหม่ ๆ ระบบการออกแบบแบกรับภาระของความน่าเบื่อไว้ เพื่อที่นักออกแบบและนักพัฒนาจะได้ไม่ต้องแบกเอง"

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

ในเดือนกุมภาพันธ์ 2023 Brad Frost เขียนเรื่อง "Design Systems in the Time of AI" ไว้ว่า:

"AI เป็นผู้ใช้ระบบการออกแบบโดยธรรมชาติ... ความจริงก็คือ งานคอมโพเนนต์ของระบบการออกแบบจำนวนมากนั้นเป็นงานเชิงกลไกและคาดเดาได้ เราใช้เครื่องมืออย่าง PlopJS สร้างโครงคอมโพเนนต์ที่หน้าตาตรงกับส่วนอื่นของไลบรารีอยู่แล้ว ผมยินดีให้ AI ช่วยสร้างโค้ดโครงพื้นฐานทั่วไปเหล่านี้แทนผมเป็นอย่างยิ่ง"

- Brad Frost

ลักษณะเชิงกลไกและคาดเดาได้ของระบบการออกแบบนี้เอง ที่ทำให้มันเหมาะกับการทำงานแบบเซลลูลาร์ออโตมาตา เมื่อกฎชัดเจน เป็นระดับท้องถิ่น และถูกใช้อย่างสม่ำเสมอ เอเจนต์ก็ทำงานได้อย่างอิสระ เหมือนกับที่เซลล์ใน Game of Life ของ Conway ไม่ต้องมีตัวควบคุมกลางก็สร้างไกลเดอร์และออสซิลเลเตอร์ขึ้นมาได้

ความจำเป็นของการอ่านได้ด้วยเครื่อง

โครงการ Storybook MCP (Model Context Protocol) ถือเป็นวิวัฒนาการสำคัญในทิศทางนี้ Storybook MCP ซึ่งประกาศเมื่อปลายปี 2025 มอบเมทาดาทาของคอมโพเนนต์ที่เครื่องอ่านได้จากการตั้งค่า Storybook เดิมให้แก่เอเจนต์เขียนโค้ดด้วย AI

ข้อสังเกตสำคัญคือ เอเจนต์ไม่ต้องการโค้ดดิบหรือเอกสารเชิงภาพ สิ่งที่พวกมันต้องการคือ:

• Component manifest: เมทาดาทาที่มีโครงสร้างของทุกคอมโพเนนต์ ทั้ง props, ตัวแปรต่าง ๆ (variants), การผูกกับ design token และตัวอย่างการใช้งาน
• การตั้งชื่อที่มีความหมาย: โทเคนที่สื่อเจตนาชัดเจน เช่น action.primary.confirm ซึ่งบอกความหมายให้เอเจนต์เข้าใจ ไม่ใช่แค่ค่าเฉย ๆ
• วงจรตรวจสอบ: ความสามารถในการรันเทสต์ ดูว่าอะไรล้มเหลว แล้วแก้ไขตัวเอง

"Storybook MCP ช่วยให้เอเจนต์ทำตามรูปแบบของคุณและผ่านเทสต์ของคุณ มันมอบสองสิ่งที่เอเจนต์ไม่เคยมีมาก่อน คือเมทาดาทาของคอมโพเนนต์ที่เครื่องอ่านได้ และวงจรวนซ้ำที่ใช้แก้ข้อผิดพลาดด้วยตัวเอง"

- ทีม Storybook

Storybook MCP มีวงจรแก้ไขอัตโนมัติรวมอยู่ด้วย มันให้เอเจนต์รันเทสต์คอมโพเนนต์ของคุณ (ทั้งการโต้ตอบและการเข้าถึง) ดูว่าอะไรไม่ผ่าน แล้วแก้บั๊กของตัวเอง นักพัฒนาเพียงเข้ามาดูหลังจากเทสต์ผ่านแล้วเท่านั้น ไม่ต้องคอยป้อนพรอมต์เฝ้าเอเจนต์อีกต่อไป

นี่คือสถาปัตยกรรมของเซลลูลาร์ออโตมาตาที่นำมาใช้กับงานออกแบบอย่างแท้จริง คือกฎระดับท้องถิ่น (สเปกของคอมโพเนนต์) การโต้ตอบกับเพื่อนบ้าน (รูปแบบการประกอบ) และการอัปเดตแบบวนซ้ำ (การตรวจสอบและการแก้ไขตัวเอง)

Component Manifest ของผมในฐานะจีโนม

การเปรียบเทียบกับ Langton's Loops ยิ่งเข้าที่เมื่อเราดูว่า component manifest ทำงานอย่างไร ในระบบของ Langton "จีโนม" ที่เข้ารหัสอยู่ในเซลล์ที่หมุนเวียนอยู่นั้นบรรจุคำสั่งสำหรับสร้างลูปใหม่ ส่วนในระบบการออกแบบที่เครื่องอ่านได้ 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 นี้เป็นทั้งข้อกำหนดการออกแบบและโค้ดที่รันได้ในเวลาเดียวกัน หรือจะพูดให้ถูกก็คือเป็นชุดคำสั่งที่ใช้สร้างโค้ดที่รันได้ได้ เอเจนต์ที่อ่าน 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

การออกแบบคือ โค้ด

• Variants
• Tokens
• Props

• Constraints (เราเพิ่มให้ components ได้)

• กฎของ Slots (อะไรวางลงใน slot อื่นได้บ้าง หรืออะไรที่อนุญาตให้วางลงใน slot ของฉัน)

• กฎ

• ตัวอย่าง 

• Animations  ( อนุญาตหรือแนะนำให้ใช้ )

จากนั้นลองสังเกตและทดลองดูพฤติกรรมของมัน

เช่นใน https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Design Tokens ในฐานะตัวแปรสภาพแวดล้อม

Design tokens เป็นอีกชิ้นส่วนสำคัญของภาพรวม ในออโตมาตาเซลลูลาร์ แต่ละเซลล์ตอบสนองต่อสภาพแวดล้อมใกล้ตัว คือสถานะของเซลล์ข้างเคียง ในระบบการออกแบบ คอมโพเนนต์ก็ตอบสนองต่อ 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

เมื่อเอเจนต์สร้างคอมโพเนนต์ Button ขึ้นมา มันไม่จำเป็นต้องรู้ว่า "primary" หมายถึงสีน้ำเงิน แค่อ้างอิงถึง button.background.primary แล้วเชื่อใจว่าระบบ token จะแปลงเป็นค่าที่ถูกต้องเอง สภาพแวดล้อม (ชั้น token) เก็บข้อมูลไว้ ส่วนคอมโพเนนต์ (เซลล์) ก็แค่ตอบสนองต่อมัน

เครื่องมืออย่าง Tokens Studio พัฒนาไปถึงขั้นมอง design tokens เป็นกราฟการคำนวณที่มี resolver คือโหนดที่ตัดสินใจเชิงความหมายว่าจะใช้ base token ตัวไหนตามบริบท สิ่งนี้เปลี่ยน design tokens จากค่าคงที่ให้กลายเป็นระบบไดนามิกที่ขับเคลื่อนด้วยกฎ

ระบบนิเวศ Drupal และการผสาน AI

การนำ AI เข้ามาอยู่ในระบบจัดการเนื้อหา (CMS) ถือเป็นห้องทดลองที่สมบูรณ์แบบสำหรับสำรวจหลักการ "การออกแบบคือโค้ด" CMS อย่าง Drupal มีแนวคิดหลักเหล่านี้อยู่แล้ว ทั้งชนิดเนื้อหาแบบมีโครงสร้าง การนิยามฟิลด์ ความสัมพันธ์ และกฎการประกอบเข้าด้วยกัน

ผมไม่เคยคิดเลยว่าเราจะพูดอะไรแบบนี้ได้ สำหรับผมมันเคยเป็นแค่ความฝันที่ไกลเกินเอื้อม

 ชุดคอมพิวเตอร์ขั้นสุดยอดที่เราน่าจะมีได้ นักพัฒนาบางคนที่ดูเหมือนมาจาก Star Trek ในอนาคต พูดคุยกับคอมพิวเตอร์ให้เขียนโปรแกรมแทนพวกเขา

ประสบการณ์ของเอเจนต์ (AX) และผู้ใช้ยุคใหม่

การออกแบบเพื่อเครื่องจักร

ในช่วงต้นปี 2025 Mathias Biilmann ซีอีโอของ Netlify ได้เสนอแนวคิด "Agent Experience" (AX) ศาสตร์แขนงใหม่ที่มุ่งเน้นว่าเอเจนต์ AI โต้ตอบกับผลิตภัณฑ์และแพลตฟอร์มอย่างไร

การเปลี่ยนแปลงนี้เป็นเรื่องพื้นฐาน หลายสิบปีที่ผ่านมา UX (ประสบการณ์ผู้ใช้) ถูกปรับให้เหมาะกับการรับรู้ ความเข้าใจ และพฤติกรรมของมนุษย์ ส่วน DX (ประสบการณ์นักพัฒนา) ถูกปรับให้เหมาะกับนักพัฒนาที่เป็นมนุษย์ซึ่งสร้างซอฟต์แวร์ AX ตระหนักว่าเอเจนต์กำลังกลายเป็นผู้ใช้หลักของระบบดิจิทัล และพวกมันมีความต้องการที่แตกต่างออกไปโดยสิ้นเชิง:

• พวกมันไม่สนใจความงามด้านภาพมีแต่ข้อมูลที่มีโครงสร้างและแยกวิเคราะห์ได้
• พวกมันไม่ได้เลื่อนดูอินเทอร์เฟซแต่เรียกใช้ API และอ่าน manifest
• พวกมันไม่ได้อ่านเอกสารแบบมนุษย์แต่ต้องการบริบทที่เครื่องอ่านได้
• พวกมันไม่ตัดสินใจเชิงอัตวิสัยแต่ทำตามกฎและข้อจำกัด

"เอเจนต์ AI ไม่ใช่มนุษย์ พวกมันไม่สนใจขนาดของปุ่ม ความอ่านง่ายของตัวอักษร จานสีสวยๆ บนเว็บไซต์ หรือแอนิเมชันหวือหวาในแอปของคุณ แล้วเอเจนต์ AI 'ใส่ใจ' อะไรกันแน่? คำถามนี้ยังไม่มีคำตอบที่ชัดเจนในวันนี้ แต่จะยิ่งสำคัญขึ้นเรื่อยๆ ในอีกไม่กี่ปีข้างหน้า"

- งานวิจัย AX

คำตอบคือ กฎที่ชัดเจน พฤติกรรมที่คาดเดาได้ ข้อมูลที่มีโครงสร้างดี และวงจรป้อนกลับที่ช่วยให้เอเจนต์ตรวจสอบและแก้ไขการกระทำของตัวเองได้

ความท้าทายของอินเทอร์เฟซคู่

การออกแบบเพื่อ AX หมายถึงการสร้างอินเทอร์เฟซสองแบบไปพร้อมกัน:

1. อินเทอร์เฟซระหว่างมนุษย์กับเอเจนต์: ที่ซึ่งมนุษย์กำกับดูแล อนุมัติ แก้ไข และชี้นำพฤติกรรมของเอเจนต์ ซึ่งก็คือชั้น "ศูนย์บัญชาการ" ลองนึกถึงแดชบอร์ดและคิวรออนุมัติ มากกว่าแบบฟอร์มและปุ่มกด
2. อินเทอร์เฟซระหว่างเอเจนต์กับระบบ: ที่ซึ่งเอเจนต์ทำงานร่วมกับ API ฐานข้อมูล และเครื่องมือต่างๆ ซึ่งก็คือชั้น "ปฏิบัติการ" ต้องแข็งแกร่ง มีเอกสารประกอบครบถ้วน และปรับให้เหมาะกับประสิทธิภาพของเครื่อง

สิ่งนี้สะท้อนสถาปัตยกรรมของเซลลูลาร์ออโตมาตา ซึ่งมีสองมุมมองที่ดำรงอยู่ร่วมกัน:

• มุมมองระดับท้องถิ่น: แต่ละเซลล์ (เอเจนต์) ทำตามกฎง่ายๆ ที่อิงกับเพื่อนบ้านที่อยู่ติดกัน
• มุมมองระดับภาพรวม: รูปแบบที่ซับซ้อนปรากฏขึ้นและมองเห็นได้เฉพาะเมื่อดูในระดับใหญ่

"การออกแบบประสบการณ์ของเอเจนต์ (AX) ควรทำให้เอเจนต์ใช้งานได้ดีและเป็นมิตรต่อเอเจนต์ ดังนั้น AX ที่ดีจึงนำไปสู่ประสบการณ์ผู้ใช้ (UX) ที่ดี หากเอเจนต์ AI พบกระบวนการที่พัง โปรโตคอลที่ใช้ไม่ได้ หรือแม้แต่ถ้อยคำที่ไม่สอดคล้องกันระหว่างระบบ มันก็จะทำงานนั้นไม่ได้ นั่นคือประสบการณ์ที่แย่สำหรับเอเจนต์ ซึ่งส่งผลต่อไปเป็นประสบการณ์ที่แย่ของลูกค้าหรือพนักงาน"

- Kat Holmes, Chief Experience Officer, Salesforce

จาก UX สู่ AX: วิวัฒนาการของการออกแบบดิจิทัล

สติกเมอร์จีและการสื่อสารทางอ้อม

หนึ่งในแนวคิดที่ทรงพลังที่สุดจากปัญญาฝูง (swarm intelligence) คือ สติกเมอร์จี (stigmergy) หรือการประสานงานทางอ้อมผ่านร่องรอยในสภาพแวดล้อม มดไม่ได้บอกกันตรงๆ ว่าอาหารอยู่ที่ไหน แต่ทิ้งทางเดินฟีโรโมนให้มดตัวอื่นตามไป สภาพแวดล้อมจึงกลายเป็นสื่อกลางในการสื่อสาร

ในระบบการออกแบบเชิงเอเจนต์ สติกเมอร์จีปรากฏในรูปแบบของ:

• คลังคอมโพเนนต์ที่ใช้ร่วมกัน: เอเจนต์ "เห็น" ว่ามีคอมโพเนนต์อะไรบ้างและเคยถูกใช้อย่างไร
• ดีไซน์โทเคน: ค่าเชิงความหมายที่เก็บการตัดสินใจด้านการออกแบบไว้เป็นข้อเท็จจริงในสภาพแวดล้อม
• เอกสารรูปแบบการใช้งาน: ตัวอย่างการใช้งานที่ทำหน้าที่เป็นทางเดินฟีโรโมนให้เอเจนต์รุ่นถัดไป
• ชุดทดสอบ: กฎการตรวจสอบที่กำหนดขอบเขตของผลลัพธ์ที่ถูกต้อง
• ประวัติ Git: บันทึกการตัดสินใจในอดีตที่เอเจนต์อ้างอิงได้

เมื่อเอเจนต์สร้าง UI ด้วยคอมโพเนนต์ มันทิ้งร่องรอยไว้ ทั้งในโค้ดเบส ในเอกสารประกอบ และในรูปแบบที่มันวางไว้ เอเจนต์รุ่นต่อไปที่พบงานคล้ายกันจะได้รับอิทธิพลจากร่องรอยเหล่านี้ เกิดเป็นปัญญารวมหมู่ที่ไม่มีเอเจนต์ตัวใดตัวหนึ่งครอบครองอยู่เพียงลำพัง

รูปแบบการออกแบบเชิงเอเจนต์

Andrew Ng และผู้เชี่ยวชาญท่านอื่นๆ ได้ระบุรูปแบบหลักสี่ประการสำหรับระบบ AI เชิงเอเจนต์:

1. การไตร่ตรองตนเอง (Reflection): AI ประเมินผลลัพธ์ของตัวเองและปรับปรุงให้ดีขึ้นซ้ำแล้วซ้ำเล่า
2. การใช้เครื่องมือ (Tool Use): AI ทำงานร่วมกับเครื่องมือภายนอก API และระบบต่างๆ
3. การวางแผน (Planning):AI แบ่งงานที่ซับซ้อนออกเป็นงานย่อยแล้วลงมือทำทีละขั้นตามลำดับ
4. มัลติเอเจนต์: เอเจนต์เฉพาะทางหลายตัวร่วมมือกันทำงานที่ซับซ้อน

รูปแบบเหล่านี้สอดคล้องโดยตรงกับแนวคิดของเซลลูลาร์ออโตมาตา:

ดีไซน์คือโค้ด: อ่านให้ลึกขึ้น

"ดีไซน์คือโค้ด" แท้จริงแล้วหมายความว่าอย่างไร

เมื่อเราบอกว่า "ดีไซน์คือโค้ด" เรากำลังยืนยันหลายเรื่องพร้อมกัน:

1. ความหมายที่เทียบเท่ากัน

การตัดสินใจด้านการออกแบบ เมื่อเข้ารหัสไว้อย่างถูกต้อง ก็กลายเป็นสิ่งที่รันได้ ดีไซน์โทเค็นไม่ได้เป็นแค่ค่าหนึ่งค่า แต่เป็นคำสั่ง สเปกของคอมโพเนนต์ไม่ได้เป็นแค่เอกสาร แต่เป็นโปรแกรม เมื่อเอเจนต์นำอาร์ติแฟกต์เหล่านี้ไปใช้ ก็เท่ากับว่าพวกมันกำลังรันดีไซน์ไม่ต่างจากการนำไปพัฒนาเป็นผลงาน

2. ศักยภาพในการสร้างสรรค์

เช่นเดียวกับที่ Rule 110 คำนวณได้ทุกสิ่งที่คำนวณได้ ดีไซน์ซิสเต็มที่สมบูรณ์เพียงพอก็สามารถสร้างอินเทอร์เฟซที่ถูกต้องได้ทุกแบบ ระบบนั้นบรรจุศักยภาพของทุกรูปแบบที่ใช้ได้ไว้ สิ่งที่เกิดขึ้นจริงขึ้นอยู่กับเงื่อนไขเริ่มต้น (ความต้องการ) และกฎ (ข้อจำกัด) เท่านั้น

3. ความซับซ้อนที่เกิดขึ้นเอง

อินเทอร์เฟซที่ซับซ้อนล้ำลึกที่สุดไม่ได้เกิดจากการออกแบบจากบนลงล่าง แต่ผุดขึ้นจากการใช้กฎง่ายๆ อย่างสม่ำเสมอ ปุ่มที่ออกแบบมาดี เมื่อใช้อย่างสม่ำเสมอ ก็สร้างภาษาภาพที่ลงตัวขึ้นมาได้ โดยไม่มีใครต้องวางแผนความลงตัวนั้นไว้อย่างชัดเจน

4. ความไม่อาจย่นย่อทางการคำนวณ

ผลลัพธ์ด้านการออกแบบบางอย่างไม่อาจทำนายได้เลยหากไม่รันระบบจริง คุณไม่มีทางรู้ว่าอินเทอร์เฟซที่เอเจนต์ประกอบขึ้นจะหน้าตาเป็นอย่างไร จนกว่าจะปล่อยให้เอเจนต์ประกอบมันขึ้นมา นี่คือหลักการความไม่อาจย่นย่อทางการคำนวณ (computational irreducibility) ของ Wolfram ที่นำมาใช้กับงานออกแบบ

5. การปรับเปลี่ยนตัวเอง

เหมือน evoloops ที่กลายพันธุ์ระหว่างการจำลองตัวเอง ดีไซน์ซิสเต็มที่พร้อมสำหรับเอเจนต์ก็วิวัฒน์ได้ผ่านการใช้งาน คอมโพเนนต์ที่เอเจนต์สร้างขึ้นจะกลายเป็นส่วนหนึ่งของไลบรารีที่เอเจนต์รุ่นถัดไปนำไปใช้ ระบบเรียนรู้ ปรับตัว และเติบโตไปเรื่อยๆ

อุปมาเซลลูลาร์ออโตมาตาที่ขยายความต่อ

เหนือกว่าอุปมา: การหลอมรวมที่เกิดขึ้นจริง

แต่นี่ไม่ใช่แค่อุปมา การหลอมรวมนี้เป็นของจริงและกำลังเกิดขึ้นในตอนนี้:

• Storybook MCP เปลี่ยนไลบรารีคอมโพเนนต์ให้เป็นคำสั่งที่เครื่องอ่านได้ และเอเจนต์นำไปรันได้จริง
• Model Context Protocol กำหนดมาตรฐานวิธีที่เอเจนต์เข้าถึงเครื่องมือและบริบท สร้างพื้นฐานกลางสำหรับการทำงานแบบเอเจนติก
• สถาปัตยกรรมมัลติเอเจนต์ แบ่งงานกันระหว่างเอเจนต์เฉพาะทาง (สถาปนิก โปรแกรมเมอร์ ผู้รีวิว) ที่โต้ตอบกันตามโปรโตคอล เหมือนเซลล์ที่มีหน้าที่แตกต่างกัน
• ลูปการซ่อมแซมตัวเองให้เอเจนต์รันการทดสอบ ตรวจจับข้อผิดพลาด และวนปรับแก้ซ้ำ ซึ่งเป็นกลไกป้อนกลับแบบเดียวกับที่เซลลูลาร์ออโตมาตาใช้พัฒนาไปสู่โครงสร้างที่เสถียร
• Schema.org Blueprints ทำให้โครงสร้างเนื้อหาเครื่องอ่านได้และมีความหมายเชิงความหมาย (semantic)
• Drupal AI วางโครงสร้างพื้นฐานให้เอเจนต์ AI สร้าง แก้ไข และจัดการเนื้อหาได้ด้วยตัวเอง

เราไม่ได้มอง "ดีไซน์คือโค้ด" เป็นจุดยืนเชิงปรัชญา แต่กำลังสร้างมันขึ้นมาเป็นโครงสร้างพื้นฐานทางเทคนิค

ผลที่ตามมาและหนทางข้างหน้า

สำหรับนักออกแบบ

บทบาทของนักออกแบบกำลังเปลี่ยนจาก "ผู้วาดสี่เหลี่ยม" ไปเป็น "ผู้กำหนดกฎ" ดังที่ Brad Frost ได้สังเกตไว้ว่า:

"นักออกแบบและนักพัฒนาที่มองว่างานของตัวเองคือการวาดสี่เหลี่ยม มีเรื่องให้ต้องกังวลมาก แต่ถ้ามองว่างานของตัวเองคือการแก้ปัญหา และบังเอิญต้องสร้างหรือใช้สี่เหลี่ยมบ้างเพื่อแก้ปัญหาเหล่านั้น ก็มีเรื่องให้กลัวน้อยกว่ามาก"

- Brad Frost

ในอนาคตที่ขับเคลื่อนด้วยเอเจนต์ นักออกแบบจะ:

• กำหนดโทเคนเชิงความหมายและความสัมพันธ์ระหว่างโทเคนเหล่านั้น
• วางข้อจำกัดในการประกอบและแพตเทิร์น
• สร้างกฎการตรวจสอบที่เอเจนต์ต้องทำให้ผ่าน
• ดูแลและพัฒนากฎที่กำกับการเกิดขึ้นเองของผลลัพธ์ (emergence)
• ออกแบบกลไกป้อนกลับที่ช่วยให้ระบบแก้ไขตัวเองได้
• กำหนด "ฟังก์ชันความเหมาะสม" (fitness function) ที่ตัดสินว่าผลลัพธ์แบบใดยอมรับได้

นี่คือการออกแบบในระดับนามธรรมที่สูงขึ้น คือออกแบบกฎที่ให้กำเนิดดีไซน์ แทนที่จะออกแบบตัวดีไซน์เอง เหมือนกำหนดกฎของเซลลูลาร์ออโตมาตา แทนที่จะวาดเซลล์ทีละเซลล์

สำหรับนักพัฒนา

นักพัฒนาจะกลายเป็นสถาปนิกของระบบเอเจนต์ ดังที่ Anthropic อธิบายไว้ว่า:

"วงการพัฒนาซอฟต์แวร์แสดงศักยภาพอันน่าทึ่งสำหรับฟีเจอร์ LLM โดยความสามารถได้พัฒนาจากการเติมโค้ดอัตโนมัติไปสู่การแก้ปัญหาได้ด้วยตัวเอง"

นักพัฒนาจะต้อง:

• สร้างอินเทอร์เฟซที่เครื่องอ่านได้ระหว่างเอเจนต์กับระบบต่าง ๆ
• ออกแบบวงจรป้อนกลับและกลไกการตรวจสอบ
• สร้างโครงนั่งร้านที่พฤติกรรมแบบ emergent จะเกิดขึ้นภายใน
• คงการกำกับดูแลโดยมนุษย์ไว้เป็นผู้ตัดสินขั้นสุดท้าย
• กำหนดโปรโตคอลที่เอเจนต์ใช้สื่อสารกัน
• เขียน "โค้ดกาว" (glue code) ที่เชื่อมระบบเอเจนต์ต่าง ๆ เข้าด้วยกัน

สำหรับการพัฒนาเว็บและแพลตฟอร์ม CMS

การนำ AI มาผสานกับแพลตฟอร์มอย่าง Drupal ชี้ไปสู่อนาคตที่:

• โมเดลเนื้อหากลายเป็นสิ่งที่เอเจนต์ใช้งานได้ ผ่านมาตรฐานอย่าง Schema.org
• เวิร์กโฟลว์บรรณาธิการมีเอเจนต์ช่วย ทั้งการร่าง การดูแลเนื้อหา และการปรับให้เหมาะสมด้วย AI
• การค้นหาพัฒนาไป จากการจับคู่คีย์เวิร์ดสู่การเข้าใจเชิงความหมายผ่านเอ็มเบดดิงและฐานข้อมูลเวกเตอร์
• การปรับแต่งเฉพาะบุคคลทำงานได้เอง โดยเอเจนต์เรียนรู้ความชอบของผู้ใช้และปรับเนื้อหาแบบเรียลไทม์
• การพัฒนาเร็วขึ้น เมื่อเอเจนต์สร้างคอมโพเนนต์ การทดสอบ และเอกสารให้

ระบบนิเวศของ Drupal ที่โอบรับ AI ผ่านโมดูลอย่าง Drupal AI, Drupal Canvas, Schema.org Blueprints และการเชื่อมต่อผู้ให้บริการ AI แสดงให้เห็นว่าอนาคตนี้กำลังถูกสร้างขึ้นแล้ว

สำหรับองค์กร

ความได้เปรียบในการแข่งขันจะตกเป็นขององค์กรที่ระบบดีไซน์ "พร้อมสำหรับเอเจนต์" มากที่สุด ระบบที่พร้อมสำหรับเอเจนต์มีลักษณะดังนี้:

• ครอบคลุมสถานะและตัวแปรของคอมโพเนนต์ครบถ้วน
• การตั้งชื่อเชิงความหมายที่สื่อเจตนา
• เอกสารและบริบทที่เครื่องอ่านได้
• โครงสร้างพื้นฐานสำหรับการตรวจสอบและการทดสอบ
• ข้อจำกัดที่ชัดเจนซึ่งกำหนดขอบเขตของผลลัพธ์ที่ถูกต้อง
• API ที่ออกแบบมาให้เอเจนต์ใช้งาน (AX-first)
• สถาปัตยกรรมเนื้อหาแบบ Schema.org-first

เพื่ออนาคตของผลิตภัณฑ์ดิจิทัล

สภาวะปลายทางจะเป็นเหมือนระบบนิเวศดิจิทัล คือเอเจนต์จำนวนนับไม่ถ้วนที่ทำงานตามกฎเฉพาะถิ่น สร้างอินเทอร์เฟซแบบเกิดใหม่ (emergent) ที่ไม่มีนักออกแบบหรือนักพัฒนาคนใดวางแผนไว้ แต่ก็ยังประสานเป็นหนึ่งเดียวได้ เพราะกฎพื้นฐานเบื้องล่างนั้นแข็งแรงมั่นคง

ฟังดูไกลตัวแต่ก็ไม่ถึงกับเพ้อฝัน เพราะนี่คือวิธีเดียวกับที่ระบบชีวภาพทำงาน ที่เมืองเติบโต และที่ตลาดเคลื่อนไหว คำถามไม่ใช่ว่าเราจะไปถึงจุดนั้นหรือไม่ แต่อยู่ที่ว่าเราจะนำพาตัวเองผ่านช่วงเปลี่ยนผ่านนี้อย่างไร

บทสรุป: โค้ดมีชีวิต

จอห์น ฟอน นอยมันน์ ผู้รอบรู้ผู้คิดค้นเซลลูลาร์ออโตมาตา ถูกขับเคลื่อนด้วยคำถามพื้นฐานข้อหนึ่งว่า ความซับซ้อนขั้นต่ำที่สุดที่ทำให้สิ่งหนึ่งสืบพันธุ์ตัวเองได้คืออะไร? คำตอบของเขา คือ ตัวสร้างสากลของฟอน นอยมันน์ (von Neumann universal constructor) ซึ่งแสดงให้เห็นว่าการจำลองตัวเองไม่จำเป็นต้องมีกลไกทางชีววิทยา ขอเพียงมีกฎที่เข้ารหัสวิธีนำตัวเองไปใช้ไว้ในตัวก็พอ

เจ็ดสิบปีให้หลัง เรากำลังค้นพบว่าหลักการเดียวกันนี้ใช้ได้กับระบบการออกแบบ สิ่งที่ขาดไม่ได้สำหรับการสร้าง UI อัตโนมัติไม่ใช่ปัญญาประดิษฐ์ทั่วไป (AGI) หรือความคิดสร้างสรรค์ระดับมนุษย์ แต่คือชุดกฎที่ครบถ้วน สอดคล้องกัน และเครื่องอ่านได้ ซึ่งเอเจนต์นำไปปฏิบัติตามได้

เมื่อ Langton's Loops จำลองตัวเองไปทั่วตารางเซลลูลาร์ เราไม่ได้บอกว่าลูปเหล่านั้น "ออกแบบ" ลูปใหม่ การจำลองก็เป็นเพียงผลที่กฎสร้างขึ้นเท่านั้น แต่ผลลัพธ์ คืออาณานิคมของแพตเทิร์นคล้ายตัวเองที่ขยายตัวไม่หยุด ซึ่งปฏิเสธไม่ได้เลยว่าเป็นการสร้างสรรค์ และมีความคิดสร้างสรรค์ในเชิงหน้าที่อยู่ในนั้น

เมื่อเอเจนต์ AI ประกอบอินเทอร์เฟซจากคอมโพเนนต์ของระบบการออกแบบ โดยทำตามโทเคนเชิงความหมายและข้อจำกัดในการประกอบ ก็เป็นการทำสิ่งที่คล้ายกัน "ความคิดสร้างสรรค์" ไม่ได้อยู่ที่ตัวเอเจนต์ แต่อยู่ที่กฎที่พวกมันปฏิบัติตาม ซึ่งเป็นกฎที่มนุษย์ออกแบบไว้ แต่ตอนนี้ทำงานได้เองโดยอัตโนมัติ

เรายืนอยู่ที่ธรณีประตูของยุคใหม่แห่งการสร้างสรรค์ดิจิทัล เอเจนต์มาถึงแล้ว โปรโตคอลกำลังก่อรูป ระบบการออกแบบกำลังกลายเป็นสารตั้งต้นของชีวิตเทียม

การออกแบบคือโค้ด
และโค้ดกำลังมีชีวิตขึ้นมา

บทความและโปรเจกต์สำคัญ

• 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 - ราว 1,500 รูปแบบ
• 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 ตัวอื่นในลูปอื่นๆ ที่ซ้อนเพิ่มขึ้นไปอีก

การออกแบบคือโค้ด เมื่อระบบทำงานเป็นลูป เหมือนวงจรชีวิตภายในแคนวาสและชุดกฎที่เลือกไว้