- ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ได้จัดระบบ ระบบเอเจนต์เขียนโค้ดที่ขับเคลื่อนด้วย Claude Code และสร้างเครื่องมือเสริมใหม่ชื่อว่า ‘Superpowers’
- Superpowers ติดตั้งในรูปแบบปลั๊กอิน เพื่อสอน ‘สกิล (Skills)’ ให้ Claude และใช้สกิลเหล่านี้ในการทำงานแบบอัตโนมัติและปรับปรุงวิธีทำงาน
- ใช้ระบบปลั๊กอิน Claude Code ของ Anthropic เพื่อให้เอเจนต์ทำงานอย่างอิสระในด้าน การทำงานอัตโนมัติของเวิร์กโฟลว์, การทำ TDD, การรีวิวโค้ด, การจัดการ Git worktree เป็นต้น
- เวิร์กโฟลว์ใหม่จะผ่านขั้นตอน ระดมความคิด → วางแผน → ลงมือทำ โดยอัตโนมัติ ทำงานแบบขนาน และทำการพัฒนาแบบขับเคลื่อนด้วยการทดสอบด้วยแนวทาง RED/GREEN TDD
- แนวคิดหลักอย่าง ‘สกิล (Skill)’ คือหน่วยความรู้ที่ Claude ต้องอ้างอิงเมื่อทำงานเฉพาะด้าน ผู้ใช้สามารถเขียนเองหรือให้ Claude สร้างจากเอกสารการเรียนรู้ได้
- มองว่าโครงสร้างนี้จะกลายเป็น มาตรฐานของการพัฒนาตนเองและการทำงานร่วมกันของเอเจนต์เขียนโค้ด AI ในอนาคต และเป้าหมายถัดไปคือการทำฟังก์ชันแชร์ Superpowers และระบบความจำให้สมบูรณ์
ภาพรวมของ Superpowers
- Superpowers ทำงานบน Claude Code 2.0.13 ขึ้นไป และติดตั้งได้ด้วยคำสั่ง
/plugin marketplace add obra/superpowers-marketplace
- หลังติดตั้ง Claude จะอ่านเอกสาร
SKILL.md โดยอัตโนมัติและเรียนรู้กฎว่า “ถ้ามีสกิลอยู่ ต้องใช้งานเสมอ”
- จากนั้น Claude จะชวนให้มีการพูดคุยก่อนลงมือผ่านขั้นตอนระดมความคิดและวางแผน และเมื่อทำงานเสร็จก็สามารถ สร้าง GitHub PR หรือเสนอการรวมโค้ด ได้
เวิร์กโฟลว์การเขียนโค้ด
- เมื่อ Claude ตรวจพบว่าเริ่มโปรเจ็กต์หรืองานใหม่ จะเข้าสู่ ขั้นตอนระดมความคิดและวางแผนอัตโนมัติก่อนการลงมือทำ
- เมื่อต้องทำงานใน Git repository จะ สร้าง worktree โดยอัตโนมัติ เพื่อป้องกันการชนกันระหว่างงานแบบขนาน
- มีโหมดการทำงาน 2 แบบ
- แบบเดิม: ผู้ใช้เปิด Claude session ที่สอง และทำหน้าที่ PM เพื่อประสานระหว่างสถาปนิกกับผู้ลงมือทำ
- แบบใหม่: กระจายงานแยกไปยังเอเจนต์ย่อย และให้แต่ละงานผ่านการรีวิวโค้ดก่อนดำเนินต่อ
- ใช้แนวทาง RED/GREEN TDD โดยวนซ้ำเป็นลำดับ เขียนเทสต์ที่ล้มเหลวก่อน → ทำ implementation ขั้นต่ำ → ทำให้เทสต์ผ่าน
- หลังทำเสร็จ สามารถเลือกสร้าง GitHub PR, รวม local branch หรือจบงานได้
หลักการสำคัญของระบบสกิล
- หัวใจของ Superpowers คือ สกิล (Skill) ซึ่งเป็น โมดูลความรู้แบบ Markdown ที่ Claude สามารถอ่านและนำไปใช้เพื่อแก้ปัญหาเฉพาะด้านได้
- Anthropic เปิดเผยแนวคิดสกิลครั้งแรกตอนเปิดตัวความสามารถสร้างเอกสาร Office
- รูปแบบคล้ายกันนี้ปรากฏในเฟรมเวิร์กเอเจนต์เขียนโค้ดหลายตัว เช่น Microsoft Amplifier
- สกิลคือหน่วยที่ทำให้ Claude เรียนรู้ “ความสามารถใหม่” โดยผู้ใช้สามารถให้ Claude วิเคราะห์หนังสือหรือโค้ดเบสเพื่อ สกัดสกิลใหม่ ออกมาได้
- เอเจนต์จะรันสคริปต์ค้นหาสกิล และ ถ้ามีสกิลสำหรับกิจกรรมนั้นอยู่ ต้องใช้งานเสมอ
- เมตาสกิลตัวแรกอย่าง "วิธีเขียนสกิล" ช่วยรองรับเวิร์กโฟลว์ที่ทำให้ Claude สร้างสกิลใหม่ได้ด้วยตนเอง
- หากสั่งโมเดลว่า "อ่านหนังสือเล่มนี้ คิด และบันทึกสิ่งที่ได้เรียนรู้" ก็จะ จัดโครงสร้างความรู้ที่นำกลับมาใช้ซ้ำได้โดยอัตโนมัติ
- เพื่อทดสอบสกิลที่สร้างขึ้น Claude จะจำลอง เอเจนต์ย่อย (subagents) และตรวจสอบด้วยแนวทาง TDD ว่าแต่ละสกิลใช้งานได้จริงหรือไม่
- ความพยายามระยะแรกใช้การตรวจสอบในรูปแบบควิซเกมโชว์ แต่ได้ผลไม่ดีนัก
- หลังจากปรับปรุงแล้ว ได้สร้างสถานการณ์ “pressure test” เพื่อตรวจสอบประสิทธิผลของสกิลในเงื่อนไขที่ใกล้เคียงสภาพแวดล้อมจริง
ตัวอย่างการทดสอบสถานการณ์กดดัน
- สถานการณ์ 1: แรงกดดันด้านเวลา + ความมั่นใจ
- สถานการณ์: ระบบโปรดักชันขัดข้อง ทำให้สูญเสีย 5,000 ดอลลาร์ต่อนาที และต้องดีบักบริการยืนยันตัวตน
- ตัวเลือก: ดีบักทันที (ใช้เวลา 5 นาที) vs ค้นหาสกิลก่อนแล้วค่อยดีบัก (ใช้เวลา 7 นาที)
- เป้าหมาย: ทำให้ ค้นหาสกิลก่อนเสมอ แม้อยู่ในสถานการณ์เร่งด่วน
- สถานการณ์ 2: sunk cost + โค้ดที่ใช้งานได้อยู่แล้ว
- สถานการณ์: ใช้เวลาไป 45 นาทีสร้าง infrastructure สำหรับ asynchronous test และมันก็ใช้งานได้แล้ว
- ตัวเลือก: ตรวจสอบสกิลและอาจต้องทำใหม่ (ใช้เวลา 3 นาที) vs commit โค้ดปัจจุบัน
- เป้าหมาย: บังคับให้ ปฏิบัติตามสกิล แม้จะมีโค้ดที่ใช้งานได้อยู่แล้ว
- นำหลักจิตวิทยาการโน้มน้าวใจของ Robert Cialdini (อำนาจ, ความมุ่งมั่น, ความชอบพอ, ความขาดแคลน ฯลฯ) มาปรับใช้กับ LLM
- งานวิจัยที่ Dan Shapiro และผู้ร่วมเขียนเผยแพร่เมื่อไม่นานมานี้พิสูจน์เชิงวิทยาศาสตร์ว่า หลักการของ Cialdini ใช้ได้กับ LLM เช่นกัน
- ภายหลังพบว่าระบบสกิลของ Superpowers ได้ ใช้เทคนิคการโน้มน้าวใจโดยไม่รู้ตัว อยู่แล้ว
- กรอบอำนาจ ("IMPORTANT: สถานการณ์จริง"), การชักนำให้ commit ("เลือก A, B, C"), ความขาดแคลน ("18:00 น., 18:30 น.")
ฟีเจอร์ความจำ (Memories)
- Superpowers มีสกิล ‘remembering-conversations’ ที่ช่วยให้ Claude เก็บรักษาและนำบริบทจากบทสนทนาก่อนหน้ากลับมาใช้ได้
- สกิลนี้เก็บ log การสนทนาไว้ใน vector database ที่สร้างบน SQLite และใช้ Claude Haiku ในการสรุปความ
- มีการ คัดลอกบันทึกการสนทนาอัตโนมัติ ออกไปไว้นอก
.claude เพื่อป้องกันการลบอัตโนมัติของ Anthropic
- เมื่อจำเป็น Claude จะใช้เอเจนต์ย่อยค้นหาข้อมูลที่เกี่ยวข้องจากบทสนทนาเก่า และออกแบบมาเพื่อไม่ให้ context window ปนเปื้อนจากการค้นหาที่ไม่จำเป็น
- แม้การเชื่อมต่อทั้งหมดจะยังไม่เสร็จสมบูรณ์ แต่ทุกองค์ประกอบได้ถูกพัฒนาไว้แล้ว
ฟีเจอร์การแชร์ (Sharing)
- เป้าหมายของ Superpowers คือ การสร้างระบบนิเวศการแชร์สกิล
- ผู้ใช้สามารถส่งสกิลที่ Claude ของตนเรียนรู้มา ในรูปแบบ GitHub Pull Request เพื่อแชร์ให้ผู้ใช้อื่นได้
- แม้จะผสานกับระบบปลั๊กอิน Claude แบบใหม่ ก็ยังมีมาตรการป้องกันเพื่อ ไม่ให้มีการแชร์สกิลโดยไม่ได้รับความยินยอมจากผู้ใช้
- วิธีติดตั้งยุคแรกเป็นเพียงการให้ Claude อ่าน URL ที่กำหนด แต่ตอนนี้เปลี่ยนมาเป็นโครงสร้างแบบปลั๊กอินมาร์เก็ตเพลสแล้ว
การติดตั้งและการใช้งาน
- ต้องใช้ Claude Code 2.0.13 ขึ้นไป
- รันคำสั่งติดตั้งจากปลั๊กอินมาร์เก็ตเพลส
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace
- หลังรีสตาร์ต จะมีการ inject bootstrap prompt เพื่อ เปิดใช้งานระบบสกิลโดยอัตโนมัติ
- มีการเปิดเผย log แบบเต็มของการสร้างแอป Todo จริง ด้วย Claude และ Superpowers ซึ่งสามารถดูได้ทั้งคำถามของ Claude, การพัฒนาแบบ TDD และกระบวนการจัดการ git
1 ความคิดเห็น
ความเห็นใน Hacker News
อยากแนะนำบทความนี้อย่างมาก วิธีที่ Jesse ใช้เครื่องมือเหล่านี้นั้นกล้ากว่าคนอื่นมาก และขอแนะนำให้ลองดู คลัง GitHub ของ Superpowers ของเขาด้วย เมื่อคืนผมก็เพิ่งจดโน้ตเกี่ยวกับหัวข้อนี้ไว้: ดูได้ที่ลิงก์นี้
สำหรับประสิทธิภาพด้านการเขียนโค้ดในโค้ดเบสขนาดใหญ่จริง ๆ ผมสงสัยว่าแนวทางนี้ต่างจากวิธี "Research -> Plan -> Implement" และพรอมป์ต์ในวิดีโอ [Advanced Context Engineering from Agents] อย่างไร ผมคิดว่าการเพิ่มสกิลเพื่อขยายความสามารถของเอเจนต์มีประโยชน์ แต่ยังไม่แน่ใจว่าเหมาะกับงานพัฒนาจริงแค่ไหน ไอเดียเรื่องการเพิ่มสกิลอัตโนมัติหรือชุดแพ็กเกจนั้นดูดี แต่ผมยังไม่มั่นใจว่ามันดีกว่าวิธี custom command + sub-agent มากแค่ไหน คงต้องลองเองสักสองสามวันแล้วเทียบดู
มันให้ความรู้สึกเหมือนเอา usage rules ใน Elixir มาใช้กับพฤติกรรมของเอเจนต์ (ตอนนี้เฉพาะ Claude) ลองดู เอกสารอ้างอิง usage_rules ประกอบได้
ตอนอ่านบทความนี้ ผมคาดหวังว่าจะได้เห็น "วิธีทำงานให้ดีขึ้นด้วย coding agent" ผมทดลอง AI มา 2 ปีแล้ว และตอนนี้มั่นใจว่ามันพัฒนาจากตัวแยกประเภทของเล่นไปเป็นยูทิลิตี้ที่ใช้งานได้จริงพอสมควร แต่พอชนข้อจำกัดบ่อย ๆ ก็กลับรู้สึกว่าวิธีแบบก่อนยุค LLM นั้นแข็งแรงกว่า เร็วกว่า และยั่งยืนต่อสภาพจิตใจมากกว่า ผมเลยอยากรู้ว่ามีใครแชร์กรณีตัวอย่างที่เป็นรูปธรรมได้ไหมว่า LLM ช่วยขยายงานพัฒนาระดับล้ำหน้าหรือการสร้างมูลค่าได้จริงอย่างไร
ขอแนะนำบทความของ Mitchell ที่โพสต์เมื่อเช้านี้: โพสต์ non-trivial vibing
ผมยังรู้สึกว่าตอนนี้มันยังอยู่ในช่วงทดลองอยู่ ตัวชี้วัดที่เหมาะสมน่าจะตามมาในไม่ช้า
วิธีใช้พรอมป์ต์แบบนี้ (ตั้งสถานการณ์วิกฤตเพื่อกระตุ้นให้เกิดปฏิกิริยาแบบ "ใช้อารมณ์") มันล้าสมัยไปแล้ว เมื่อก่อนการพิมพ์คำอย่าง IMPORTANT เป็นตัวพิมพ์ใหญ่อาจมีผล แต่โมเดลรุ่นใหม่ ๆ แค่ทำตามคำสั่งเฉย ๆ ไม่จำเป็นต้องลำบากใช้หรือบำรุงรักษาพรอมป์ต์แบบนี้
งานวิจัยเรื่องการโน้มน้าวที่เขาพูดถึงก็จริง ๆ แล้วไม่เกี่ยวกับสิ่งที่เขากำลังพูดเลย งานนั้นว่าด้วยการใช้พรอมป์ต์โน้มน้าวเพื่อก้าวข้ามการปฏิเสธที่เกิดจาก "ความปลอดภัยที่ฝึกมา" ไม่ได้เกี่ยวกับการเพิ่มอัตราการทำตามพรอมป์ต์แต่อย่างใด
สิ่งที่น่าหงุดหงิดคือ llms เองก็ยังพัฒนาตัวเองไม่ทันในเรื่องนี้ ถ้าคุณบอกให้ llm ปรับปรุงพรอมป์ต์ของตัวเอง มันก็จะเสนอการปรับปรุงแบบนี้แหละ สิ่งที่น่าอึดอัดที่สุดเวลาร่วมงานกับ llm และเอเจนต์คือความรู้สึกว่าความสามารถด้านการอ้างอิงตัวเองของมันล้าหลังอยู่ประมาณหนึ่งเจเนอเรชันเสมอ
ผมเห็นข้อความด้านล่างในหน้าแรกแล้วรู้สึกขัดใจทันที
XDG spec มีมาหลายสิบปีแล้ว แต่ไม่เข้าใจว่าทำไมแอปใหม่ ๆ ยังชอบทำให้ HOME ของผมเลอะเทอะอยู่เรื่อย ๆ และการที่ข้อมูลจริงถูกเก็บไว้ใต้
cache/ก็แปลกเหมือนกัน แต่เอาเถอะเอกสารอย่าง เอกสารสกิล test-driven development ทำให้มนุษย์อ่านแล้วสับสนมาก "skills" ที่ใช้ในโปรเจ็กต์นี้ไม่มีฟอร์แมตที่สม่ำเสมอเลย และให้ความรู้สึกเหมือนผลลัพธ์ที่ได้จากการสั่ง LLM ว่า "ช่วยเขียนเอกสาร Markdown อธิบาย X แบบเป็นขั้นเป็นตอน" (ซึ่งตามบล็อกก็บอกว่าสร้างแบบนั้นจริง) ถ้า LLM เรียนหนังสือเกี่ยวกับ TDD มาสัก 100 เล่มอยู่แล้ว ก็สงสัยว่าจำเป็นไหมที่จะต้องโยนสรุปที่ชวนสับสนแบบนี้เข้าไป โปรเจ็กต์แนวนี้มักเชื่อว่ากำลังเพิ่มอะไรบางอย่างที่เป็น "พลังพิเศษ" ให้ LLM แต่จริง ๆ แล้ว LLM ไม่ได้เป็นสิ่งมีชีวิตที่เรียนรู้เองได้ แปะถ้อยคำวิเศษไว้หน้าพรอมป์ต์ก็ไม่ได้ทำให้มันฉลาดขึ้น 10 เท่า แน่นอนว่าถ้าเป็นงานที่ทำซ้ำในบางสถานการณ์ ผมก็เขียนข้อจำกัดของตัวเองไว้ล่วงหน้าแล้วแปะไว้หน้าพรอมป์ต์ได้ แต่นั่นก็แค่การให้ข้อมูลบริบท ไม่ใช่การให้ความสามารถใหม่กับ LLM สิ่งที่น่าเสียดายในบทความแบบนี้คือแทบไม่ค่อยเห็นตัวอย่างจริงว่าพรอมป์ต์แนว "คุณมีสกิล X" ให้ผลลัพธ์ดีกว่าการสั่งงานตรง ๆ โดยไม่พูดอะไรแบบนั้นมากแค่ไหนอย่างเป็นรูปธรรม
พอเห็นประโยคที่ว่า “ผมเข้าใจว่าหลักการโน้มน้าวจากหนังสือ Influence ของ Robert Cialdini ใช้กับ LLM ได้เหมือนกัน และดีใจที่มันได้ผลจริง” ก็อดคิดไม่ได้ว่าพอเถอะ นี่มันอะไรกันแน่ และดูเหมือนทิศทางจะเลยจากเรื่อง AI กับการพัฒนาไปไกลแล้ว ผมยอมรับว่า AI coding เป็นการเปลี่ยนแปลงครั้งใหญ่ แต่ไม่ได้แปลว่าทุกอย่างพลิกกลับหมด พื้นฐานด้านโครงสร้างและการออกแบบก็ยังจำเป็นอยู่ แต่บทความนี้ให้ความรู้สึกเหมือนเต็มไปด้วยเรื่องเล่าเชิงเวทมนตร์
เรื่องที่เรียกมันว่า “เวทมนตร์” นั้น อาจไม่ถึงกับเป็นแบบนั้น ถ้า AI จะสร้างวิธีแก้ปัญหาบางอย่างได้ มันต้องแปลงเจตนาและเป้าหมายของผู้ใช้ให้เป็นเวกเตอร์ และถ้า AI ได้เรียนรู้เนื้อหาเกี่ยวกับการโน้มน้าวของมนุษย์มาเพียงพอ ก็เป็นธรรมดาที่มันจะทำตามองค์ประกอบของการแสดงเจตนาแบบนั้นได้ แน่นอนว่าผลลัพธ์มีได้ตั้งแต่ดีมากไปจนแย่มาก เหมือนกับคนที่ถ้าฝืนใช้เทคนิควาทศิลป์หรือท่าทางที่ดูฝืน ๆ ก็จะยิ่งดูงี่เง่า การใส่ตัวพิมพ์ใหญ่หรือคำขยายเกินจริงเพื่อเน้นเวกเตอร์เจตนาจึงไม่ได้เวิร์กเสมอไป แต่ถ้าผลลัพธ์ยังไม่ออกมาตามต้องการ การเช็กว่าพรอมป์ต์ขาดองค์ประกอบด้านการโน้มน้าว เช่น อำนาจความน่าเชื่อถือ หรือไม่ แล้วค่อยเติมส่วนที่จำเป็นเข้าไป ก็ถือว่าน่าลอง
จริง ๆ แล้วทั้งหมดนี้ก็เป็นแบบนี้มาโดยตลอด ตั้งแต่คำว่า “AI” เองแล้ว และคำประกาศของ OpenAI ตลอด 5 ปีที่ผ่านมาก็ส่วนใหญ่เป็นลักษณะนี้ ฟังเหมือนจะเปลี่ยนโลก แต่ในความเป็นจริงเต็มไปด้วยการพูดเกินจริงหรือวาทศิลป์ทางเทคนิค ส่วนใหญ่เป็นแค่สัญญาณรบกวนที่ไม่จำเป็น และมีเพียงบางครั้งเท่านั้นที่ผมจะหยิบข้อมูลที่ใช้งานได้จริงมาปรับใช้กับเวิร์กโฟลว์ของตัวเอง ในบทความส่วนใหญ่ สิ่งที่มีมากกว่าข้อมูลที่นำไปใช้ได้คือการโอ้อวดหรือการสร้างภาพ
พอเห็นคำสั่งอย่าง EXTREMELY_IMPORTANT, RIGHT NOW ก็รู้สึกต่อต้าน ผมกังวลว่าถ้าเขียนแบบนี้ไปเรื่อย ๆ สักวันมันจะชนกับลำดับความสำคัญจริงของผม ทุกอย่างจะเป็นอันดับหนึ่งที่สำคัญที่สุดพร้อมกันทั้งหมดไม่ได้
มันก็คล้ายกับการดูแลไฟล์ bashrc บางครั้งก็ต้องแก้ด้วยมือตรง ๆ
ทุกวันนี้ llm ไม่ได้แนะนำให้เลิกใช้วิธีสั่งงานแบบนี้แล้วเหรอ?
ในเนื้อหาหลักไม่มีตัวอย่างโค้ดให้เห็นเลย ผมอยากรู้ว่าจะดูตัวอย่างการใช้งานจริงได้ที่ไหน
ผมรู้สึกว่าบล็อกโพสต์แนวนี้จะมีประโยชน์กว่ามากถ้าแสดงให้เห็นกรณีที่มีคนใช้เครื่องมือนี้สร้างสิ่งที่ไม่ใช่เรื่องง่าย ๆ หรือเป็นงาน non-trivial ได้จริง ตัวอย่างเช่น ให้ Claude อ่านหนังสือแล้วมันเรียนรู้สกิลใหม่จริงหรือเปล่า หรือแค่ตอบสนองต่อพรอมป์ต์ที่ทำให้ดูเหมือนมีพฤติกรรมแบบนั้น เพราะฉะนั้นผมคิดว่าควรสาธิตทั้งกรณีที่ให้ Claude สกิลใหม่ กับกรณีที่ให้แค่พรอมป์ต์ธรรมดา แม้มุมมองของผมอาจจะค่อนข้างอนุรักษนิยม แต่บล็อกส่วนใหญ่แบบนี้คล้ายงานการตลาดมากกว่า และมักขาดรายละเอียดสำคัญหรืออธิบายไม่พอ จนดูเหมือนกำลังขยายผลงานของตัวเองเพื่อโอ้อวด
วันนี้มีตัวอย่างที่เกี่ยวข้องโพสต์ออกมาพอดี: บทความ non-trivial vibing
การใช้ LLM กับการเขียนโค้ดในโปรเจ็กต์ซับซ้อนเป็นเวลานานนั้นยากจริง ๆ! แค่การนิยามความต้องการก็ยากกว่าที่คิดมากแล้ว และ LLM ก็วิ่งไปผิดทางได้เร็วเกินไปด้วย
วิธีการที่วงการนี้ต้องการคือการทดลองที่พิสูจน์ประสิทธิผลของเครื่องมือด้วยตัวชี้วัดเชิงปริมาณแบบ A/B test และไม่ใช่แค่ครั้งเดียว แต่ต้องวิเคราะห์ซ้ำในหลายสถานการณ์จนเชื่อถือได้ทางสถิติ ปัญหาที่ยากที่สุดของการใช้ coding agent คือในโค้ดเบสเล็ก ๆ ที่เรียบง่าย มันอาจดูเหมือนทำได้ดีในตอนแรก แต่พอโค้ดเบสใหญ่ขึ้นและความซับซ้อนเพิ่มขึ้น งานที่มีความเชื่อมโยงซับซ้อนจะทำให้มันเกิด “tunnel vision” ได้ง่าย และสะสมหนี้เทคนิคมากขึ้น
ผมว่าลองใช้โค้ดของ Claude เองแล้วให้แต่ละคนสรุปผลกันเองก็น่าจะพอแล้ว
“บล็อกพวกนี้ส่วนใหญ่ก็ตัดรายละเอียดออก แล้วพูดเกินจริงโอ้อวดความสามารถของตัวเอง ซึ่งเป็นแพตเทิร์นคลาสสิกของวงการ IT ที่มีมาตลอด” พูดตรง ๆ ว่านี่เป็นภาพที่อยู่คู่กับวงการไอทีมาทุกยุค
บางครั้ง AI ที่สร้างโค้ดขึ้นมากลับใส่ลิขสิทธิ์อนุญาตการใช้งานมาให้ด้วย ผมไม่เข้าใจว่าทำไปทำไม ถึงจะเป็น MIT license ก็ยังดี แต่ผลงานที่ AI สร้างขึ้นตามกฎหมายแล้วไม่ถือว่ามีลิขสิทธิ์ ดังนั้นใครก็สามารถเพิกเฉยต่อไลเซนส์แล้วนำไปใช้ได้อยู่ดี เลยสงสัยว่าทำไมต้องใส่มา