🎞️ Videos → Vibe Coding โดยไม่ทิ้ง Tech Debt เอาไว้ข้างหลัง

แนะนำตัว: จบโปรเจกต์ใน 3 สัปดาห์ด้วยการใช้ AI เขียนโค้ด 99.99%0:00

โอเคครับ สวัสดีครับ ก็ ธาดา นะครับ เผื่อบางคนอาจจะคุ้นๆ บ้างนะครับ

วันนี้เป็น session AI นะครับ อย่าเพิ่งเบื่อกันนะครับ

โอเคครับ ก็หลักการเนี่ย ก็คือ vibe code เนาะ เรา vibe code กันอยู่แล้ว แต่เรา vibe code แบบมีสุขอนามัยนะครับ ก็คือแบบมีสุขภาพดีนะ ก็ทำยังไงก็มาดูกัน แนะนำตัวนะครับ ผมธาดา นะครับ ก็ชื่อมายนะครับ ปัจจุบันเป็น DevOps lead นะครับ หลักๆ ก็จะอยู่ของบริษัท TT Software และ Itron นะครับ เป็นแอดมินเพจ ThaiType นะครับ แล้วก็ MVP ของ Microsoft นะครับ ThaiType นะครับไปกด follow ได้ หลักๆ ตอนนี้ก็คือจะเป็นคล้ายๆ เหมือนกับว่า ทำอะไรก็ได้ที่แก้ปัญหาหน้างานนะครับ แล้วก็คอขวดนะครับ แล้วก็ใช้ AI เป็นหลัก โปรเจกต์ที่มาแชร์วันนี้เนี่ยครับ จะเป็นโปรเจกต์ที่ผม vibe code นะครับ ก็คือไอเดียเนี่ย โปรเจกต์เนี่ยเป็นโปรเจกต์ support DevOps แล้วก็สเกลน่าจะประมาณ 4-5 เดือนนะครับ และผมก็ vibe จบใน 3 วีก แต่ vibe จบใน 3 วีกเนี่ย เขียนโค้ดจริงเนี่ยประมาณ 9 วัน ที่เหลือคือดีไซน์ ดีไซน์หมดเลย คุยกับ AI ทุกวัน ก็ราวๆ คือ 3 วีก โปรเจกต์ตัวนี้ที่มาคุยวันนี้ เป็นโปรเจกต์ที่ผมไม่แตะโค้ดในโปรเจกต์เลยเนาะ

ก็แตะอาจจะสัก 1-2 บรรทัดอะไรอย่างนี้ ประมาณ 99.99% เขียนด้วย AI หมดเลย ก็เลยอยาก วันนี้ก็เลยอยากจะมาแชร์ว่า ถ้าวันนี้ถ้าเราจะเริ่ม vibe code หรือเรา vibe มาสักพักแล้ว หรือใครบางคนอาจจะเก่งกว่าผม ก็อาจจะมาแบ่งปันความรู้กันได้ แต่วันนี้ผมอยากจะมาแชร์อีกมุมมองนึงว่า เวลาที่เราเริ่มเอา AI เข้ามาใช้เนี่ย หลายๆ อย่างมันไม่ใช่เพราะ AI มันไม่ดี แต่ว่าบางทีมันอาจจะเป็นที่ตัวเราเองรึเปล่าเนาะ

ทำไม Vibe Code ถึงพัง? เพราะงานเร่งสร้าง Tech Debt และเปลี่ยนเป็นความเหนื่อยล้าทางกลยุทธ์ (Strategic Fatigue)1:48

โอเค ผมมาตั้งคำถามแบบนี้

หลักๆ เนี่ย ก็จะมีอยู่ 2 สาเหตุหลักๆ เนาะ ว่าทำไมพอเรา vibe code แล้วเนี่ย ทำไมมันถึงสร้าง technical debt ขึ้นมา ก็หลักการเนี่ย ก็จะมีอยู่ 2 แบบ ก็คือมาจากเชิงเทคนิค และก็จาก mindset นะครับ ซึ่งเชิงเทคนิคเนี่ย จริงๆ ผมมองว่าทุกคนเนี่ย ถ้าเกิดพอเริ่มใช้ AI มาเนาะ ทุกคนรู้หมดแล้วเนาะ ทั้งหมดที่เขียนในนี้หาได้ตามอินเทอร์เน็ตทั่วไปเลยเนาะ ผมจะไม่พูดซ้ำเนาะ ไม่ว่าจะเป็นเรื่องของการไม่มี architecture การไม่มี design pattern การไม่มีเทส ไม่มี doc context overload อะไรก็แล้วแต่ ปัญหาพวกนี้เราหาง่ายมากในอินเทอร์เน็ต

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

หรือในมุมของที่เป็น marketing หรือในมุมของคนที่ถือเงินเนี่ย เขาก็มองว่า การเอา AI เข้ามาเนี่ย มันมีเรื่องของ ROI return of investment ค่อนข้างสูงนะครับ ดังนั้นเนี่ย ในฐานะที่เราเป็นคนทำงาน เราก็ทำมันต่อไป โอเค ทีนี้พออะไรเกิดขึ้น พอเรารู้ว่า AI มันทำงานเร็ว เราก็จะมีความรู้สึกหนึ่ง ก็คือเรามีความรู้สึกว่า เราอยากเสร็จงานไวๆ นะครับ แต่ว่าพอเรายิ่งอยากทำงานให้เสร็จไวๆ มันจะเจอปัญหาว่ามันจะยิ่งเสีย ยิ่งเราอยากเสร็จไวเท่าไหร่ งานเราจะยิ่งเสียมากขนาดนั้นนะครับ ผมจะเรียกคำนี้ว่า brain fatigue ไม่แน่ใจว่าใครรู้จักคำนี้ไหม brain fatigue fatigue ก็คือภาวะเหนื่อยล้าของสมองที่ใช้คิดเรื่องงาน

ก็จะเป็นเรื่องของ brain fatigue ซึ่งเวลาที่เราใช้ AI เนี่ย มันไม่ได้ลดความเหนื่อย ที่เราใช้งานมันเนาะ แต่มันจะเปลี่ยนชนิดจากการเหนื่อย จากในอดีตเนี่ย ที่เรายังไม่มี AI ใช่ไหม เราจะเหนื่อยจากการที่เราเขียน syntax เราคิด algorithm เรา debug โค้ด เราเริ่มเขียนโค้ด มันจะเป็นลักษณะของ routine

แต่ว่าพอเราเริ่มที่จะใช้ AI เนี่ย มันจะเปลี่ยนจากความเหนื่อยที่เป็นลักษณะของ routine กลายเป็น strategic fatigue แทน ก็คือว่า

เลิกคิดว่า 'เดี๋ยวค่อย Refactor' เพราะมันไม่มีอยู่จริง ต้องแก้ Tech Debt และปรับโครงสร้างทันที4:24

การที่เราจะต้องคิดตลอดเวลาว่าเราจะไปทางไหน คิดตลอดเวลาว่า เฮ้ย เดี๋ยวเราจะไปทางนี้ เราจะไปทางนี้ เราจะไปทางนี้เพราะอะไร การคิดแบบนี้ มันทำให้เราเหนื่อยเร็วขึ้นมากๆ เลยเนาะ ทีนี้ ถามว่าแล้วไอ้ write code นี่มันทำให้เราเร็วจริงๆ หรือเปล่าเนาะ ก็จริงๆ เนี่ย ผมมองว่า เวลาที่เราอยากให้มันเร็วเนี่ย มันมาได้จากหลายทางเนาะ อาจจะตัวเองเนาะ หรืออาจจะ deadline บอกว่า PM บอกว่า เฮ้ย พรุ่งนี้ส่งงานแล้ว ทำยังไงเอา AI เข้ามาช่วยเนาะ หรือเราอาจจะมีความคาดหวัง ความกดดันอะไรต่างๆ นานาครับ แต่ว่า ยิ่งเรามีเวลาน้อย ยิ่งเรากดดันตัวเองเยอะ ยิ่ง deadline เข้ามาเนี่ย เราจะยิ่งค่อยๆ ข้ามสิ่งเล็กๆ น้อยๆ

ที่เราใช้ AI ในทุกๆ วันนะครับ ฉะนั้นเนี่ย ผมมองเลยมองว่า อีกมุมมองหนึ่ง ที่อยากชวนทุกคนคุยวันนี้ ไม่ใช่สิ่งที่ทุกคนพูดกันในวงกว้างขวางว่า การใช้ AI คืออะไร แต่ผมมองว่า ในการใช้ AI เนี่ย ทุกๆ ครั้งที่เราแชตคุยกับ AI เนี่ย มันคือการทำ decision direction คือการตัดสินใจตลอดเวลา ว่าเราจะเดินไปทางไหน เราจะเดินไปทางไหน เราจะใช้ pattern ไหน เราจะใช้ design pattern ไหน เราจะวาง structure ยังไง เราจะวาง algorithm แบบไหน เราจะเขียน test ยังไง เราจะทำยังไง ฉะนั้น ยิ่งเรายิ่งรีบเนี่ย เราก็ยิ่งจะใช้เวลาคิด direction น้อยนะครับ และพอเราคิด direction น้อย เราก็ตัดสินใจผิด

พอตัดสินใจผิด ก็เริ่มจะมี technical debt ตามมานะครับ และก็พอมี tech debt ตามมา เราก็เริ่ม แก้นานขึ้น มันก็จะรู้สึกช้า พอช้าก็กดดันตัวเอง มันจะเป็นวงจรแบบนี้ไปเรื่อยๆนะครับ

Okay ทีนี้สำหรับผมเนาะ ก็คือ คำว่าค่อยทีหลังเนี่ย มันง่ายมากเนาะ เดี๋ยวพรุ่งนี้เราจะออกกำลังกายใช่ไหม ใช่ไหมครับ ก็พรุ่งนี้ไม่มีอยู่จริงใช่ไหมครับ เหมือน refactor เหมือนกัน เดี๋ยว deliver ส่งงานไปก่อน ใช่ไหม เดี๋ยว sprint หน้าขอ refactor โค้ด ไม่มีอยู่จริง จริงไหมครับ ดังนั้นเนี่ยเราต้องทำเลยนะครับ สร้างเงื่อนไขทำทันที refactor refactor ทันที และก็ tech debt นะครับ

คือเวลาที่เราใช้ AI เนี่ย ถ้าสังเกตก็คือว่า คนที่มาเป็น junior เนี่ย อาจจะรู้สึกว่า เราอาจจะยังไม่ได้ benefit เยอะ จากการใช้ AI เนาะ แต่คนที่แบบเริ่มชำนาญแล้วจะรู้สึกว่า เราเนี่ยสามารถที่จะได้ benefit จาก AI ค่อนข้างเยอะ แต่ว่านอกเหนือไปจากความถนัด ในเรื่องของ software engineering ของเราแล้วเนี่ย ผมมองว่า tech debt จะเกิด ตอนที่เรายิ่งรีบด้วยเนาะ เรายิ่งรีบเมื่อไหร่เนี่ย เราก็จะเริ่มมีตามมาเนาะ Okay นะครับ ก็วันนี้ผมก็เลยรู้สึกว่าวันนี้เนี่ย

สามเหลี่ยม 'คน-กฎ-AI': ลดภาระในสมองด้วยการโยนการตัดสินใจไปที่การตั้ง Rule6:53

ถ้าเรารู้สึกว่าเราเนี่ยเริ่มเหนื่อยจากการใช้ AI เนาะ เราเริ่มเหนื่อยจากการที่คิดว่า เฮ้ย เดี๋ยวเราจะไปทางนี้ เราจะเขียน clean architecture เราจะใช้ microservice เราจะใช้ API เราจะใช้นู่นนี่นั่นนะครับ เราต้องตัดสินใจตลอดเวลาว่า เราจะทำแบบนี้เพราะอะไร เราจะทำแบบนี้เพราะอะไร สิ่งที่ผมกำลังจะเล่าวันนี้ก็คือว่า การที่ทำให้เราเนี่ย เอาการตัดสินใจออกจากหัว และก็ใช้ระบบช่วยแทนนะครับ

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

มี spec ยังไง context อะไร เป้าหมายคืออะไร จะต้อง verify ยังไง ซึ่งคนเนี่ย ก็คือเราเนาะ เป็นคนกำหนด rule ทั้งหมด แต่จริงๆ แล้วเนี่ยในหลักการเนี่ย เราอาจจะไม่ต้องเขียนเองก็ได้ เราอาจจะใช้ AI ช่วยเขียนก็ได้ แต่ว่าเราเนี่ยก็ควรจะเริ่มจากเป้าหมายก่อนว่า เราจะเริ่มทำมันไปทำไม แล้วก็ค่อยให้ AI เนี่ย ช่วยเขียน ช่วยรีวิว นะครับ ก็ตรงนี้เนี่ย ยิ่งเรามี rule มากขึ้น ยิ่งเรามี template ในการใช้งานมากขึ้น เราก็จะยิ่ง iterate งานได้เร็วขึ้นนะครับ

AI มักตกม้าตายเรื่อง TypeScript การมี Template กฎเหล็กจึงสำคัญที่สุดในการควบคุมทิศทาง8:19

Okay ทีนี้มาพูดถึง template เนาะ

คือการที่ผมสามารถที่จะวิ่งจาก

จาก vibe coding นะครับ ประมาณ เกือบจะ 90 เกือบจะ 100% ได้เนี่ย มันจะต้องมีองค์ประกอบของ rule ที่ค่อนข้างชัด องค์ประกอบของ rule ที่ค่อนข้างชัด ก็คือหมายความว่า เราจะต้องมีการอธิบายกฎว่า ถ้า AI เนี่ย เข้ามาที่โปรเจกต์นี้ มันจะต้องเริ่มเขียนแบบไหน จะต้องตัดสินใจยังไง ถ้าเกิดเจอสถานการณ์แบบนี้ มันต้องตัดสินใจยังไงนะครับ ซึ่งตัว template ตัวนี้ ผมก็อัป public เป็น open source เนาะ ก็ไปกด star ได้ เดี๋ยวผมให้ summary อีกทีตอนจบสไลด์เนาะ stack ที่ใช้เนี่ย ก็คือเป็น tRPC เนาะ เป็น Zod, Next.js, Better Auth, MongoDB, Monguard และก็ Mantine เนาะ ก็อาจจะไม่มี Elysia นะครับ แต่ว่าเป็น kind of type-safe end-to-end เหมือนกันนะครับ แต่ว่าเดี๋ยวพอดีผมยังไม่ชำนาญ Elysia มากนะครับ

ขอไปนั่งอ่านโค้ดอยู่ครับ ตอนนี้เป็นลูกมือ Elysia อยู่ Okay นะครับ ก็ยังถนัด tRPC อยู่ครับ ก็จบงานได้ไวอยู่

ใน stack นี้ก็จะประมาณนี้ครับ ทีนี้เดี๋ยวผมจะมีการเปิดโค้ดให้ดูบ้างนะครับ แต่ว่าผมจะเล่าให้ฟังว่า ก่อนที่จะมาเป็นเวอร์ชัน ที่ให้ทุกคนเห็นใน open source เวอร์ชันเนี้ย ผม vibe โค้ดแล้วแตกตลอดเนาะ คำว่า vibe โค้ดแล้วแตก แปลว่าอะไรเนาะ ก็คือพอทำไปแล้วเนี่ย AI มันเขียนผิดทิศทางเนาะ จากที่เราอยากให้มันทำอย่างหนึ่ง มันทำแบบหนึ่ง จากที่เราอยากให้มันทำอีกแบบหนึ่ง มันก็ดันทำอีกแบบหนึ่งนะครับ ดังนั้นเนี่ย เมื่อไหร่ก็ตามที่กฎเราไม่ชัดนะครับ มันจะทำให้ AI เนี่ย ทำงานผิดทิศทางนะครับ อันนี้ยกตัวอย่างปัญหาที่เคยเกิดขึ้นในอดีตเนาะ แล้วผมก็แก้และก็ใส่เป็น template นะครับ ก็คือเรื่องของการที่เราไม่พยายาม enforce rule ลงไปใน template เรา หรือ ecosystem ของเรานะครับ อย่างยกตัวอย่างเลยเนาะ ตะกี้คุยกับ ออม เนาะ ทำ Elysia มา สิ่งที่ AI ทุกวันนี้ AI เก่งไหม เก่งเนาะ แต่สิ่งที่ AI ตกม้าตายคืออะไร รู้ไหม เขียน TypeScript นะครับ ดังนั้นเนี่ย ใครที่ไม่อยากตกงานนะ เขียน TypeScript นะครับทุกคน โอเคไหม โอเค นะครับ

แยกแยะ Value-level กับ Type-level ใน TypeScript เพื่อประกบและขึ้นโครงให้ AI เดินต่อได้10:37

คืออย่างงี้ ในโลกของการเขียนโปรแกรมเนี่ย มันจะมี ส่วนใหญ่บนโลกใบนี้ ในโลกของ TypeScript มันจะมี การเขียนโปรแกรมอยู่ 2 แบบเนาะ ก็คือเราเรียกว่าเป็น type-level กับ value-level เนาะ ทีนี้เนี่ย ถ้าเกิดใครยังใหม่กับ type-level ใน TypeScript ผมจะอธิบายให้ฟังง่าย ๆ ก็คือว่า เวลาที่เราพูดถึง value-level มันจะเหมือนภาษาโปรแกรมมิ่งทั่วโลกเลย C#, C, C++, Rust อะไรพวกนี้เลยเนาะ

ที่เป็นภาษาโปรแกรมมิ่งที่ให้ผลลัพธ์ออกมาเนาะ ส่วน type-level เนี่ย จะเป็นโปรแกรมมิ่ง ที่อยู่ใน type ของ TypeScript นะครับ ซึ่งเราสามารถที่จะมีการเขียน if else ได้ลงไปใน type มีการเขียน loop ได้ มีการเขียนบวกลบเลข คูณเลข หารเลขได้ ก็คือมันเป็นภาษาโปรแกรมมิ่งภาษาหนึ่งเลย ที่เราสามารถทำได้แบบนั้นนะครับ ใครอยากรู้ว่าทำได้แค่ไหน ก็ไปอ่านโค้ด Elysia ได้ นะครับ แต่ว่าวันนี้ไม่ต้องไปอ่าน คือมันมีหนังสือเล่มหนึ่งนะครับ ชื่อว่า type-level-typescript.com เนาะ เขาก็แจกฟรีประมาณ 4-5 chapter เนาะ เขาก็จะอธิบายความแตกต่างระหว่าง value-level กับ type-level ว่ามันต่างกันยังไงเนาะ แล้วเราจะ treat เวลาที่เราเขียน type เราจะเขียนยังไงเนาะ ซึ่งจากปัญหาที่ผมเล่ามาทั้งหมดเนี่ย ก็คือปัญหาคือว่า AI ไม่ถนัด TypeScript นะครับ ไม่ว่าจะกี่โมเดลทั้งหมดนะครับ ยังแตกนะครับ ยิ่ง TypeScript ยิ่งยาก ยิ่งไม่ไหวนะครับ ดังนั้นเนี่ย เราก็ต้องเขียนเอง มีการกำกับว่า ถ้าเราจะเขียนให้ type-safe

AI เราจะต้องขึ้นโครงบางอย่างให้ AI ก่อน เพื่อให้เขาไปถูกนะครับ

รักษา Clean Architecture โดยการแยก Type ของรหัสโดเมน ไม่ให้ผูกติดตายตัวกับ Validator อย่าง Zod12:08

ไม่งั้นเขาก็จะไปต่อไม่ได้นะครับ

การ enforce... ยกตัวอย่างนะครับ ก็คือเรื่องของการ enforce Clean Architecture เนาะ ตอนนี้ทุกคนรู้จัก Clean Architecture เนาะ แต่ว่าใน Clean Architecture เองเนี่ย มันก็จะมีการแบ่ง layer เนาะ ว่ามันจะมี layer หลาย ๆ layer เนาะ ซึ่งใน template ตัวนี้ของผมเองเนี่ย เป็นแบบ minimal มากเลยนะ ก็คือเป็น clean แบบ simple มีแค่ 2-3 layer อะไรอย่างงี้ นะครับ ทีนี้เนี่ย การที่เราจะ enforce Clean Architecture เพื่อให้ AI เนี่ย ทำตามกฎที่เราวางไว้ได้เนี่ย

มันจะต้องมีกระบวนการ ในการที่เราจะ enforce มันนะครับ ยกตัวอย่างเช่น เหมือนในโปรเจกต์นี้ผมใช้ Zod เนาะ ทุกคนรู้จัก Zod เนาะ เขียน TypeScript มานะครับ Zod เป็น validator ตัวหนึ่ง นะครับ

ซึ่งการที่เราพอเราใช้ Zod เนี่ย มันทำให้เรา คือเวลาเราเขียน Zod เนี่ย Zod เนี่ย มันคือเป็น validation ที่เป็น TypeScript เนาะ แล้วมันสามารถ infer เป็น type ที่เป็น TypeScript ออกมาได้ จริงไหมครับ แต่ว่าจากที่ผมคุย และก็ลองศึกษาในหลาย ๆ คนมาเนี่ย

หลาย ๆ คนอาจจะเข้าใจว่า เวลาที่เราใช้ Zod เนี่ย มันจะทำให้เราไปท่าของ Clean Architecture ยาก เพราะว่าอะไร เพราะว่า type เนี่ย มันจะออกมาจากตัว schema แล้ววิ่งไปหา layer ที่เป็นแบบ controller layer เนาะ ซึ่งมันทำให้เรา ไม่สามารถที่จะเขียน เป็นลักษณะของ Clean Architecture model ได้ ที่เป็นลักษณะของ decouple ของ นะครับ ฉะนั้นเนี่ย ถ้าเราจะพยายามที่จะ enforce type จาก domain ไปยัง repository ไปยัง controller level หรือตัว router level เนี่ย Zod schema จะถูกเขียนที่ไหน นะครับ ถ้าเราเนี่ย สมมติว่าวันนี้เรายึด type จาก Zod schema อยู่ที่สักที่หนึ่งเนาะ แล้วเราพยายาม enforce ทุกที่เนี่ย มันกลายเป็นว่า โค้ดของเราจะผูกอยู่กับตัว Zod schema เนาะ วันดีคืนดีเราอยากจะเปลี่ยน Zod schema เนี่ย ไปเป็นเจ้าอื่นนะครับ

จำชื่อไม่ได้ Elysia ใช้อะไรนะครับ ลองถามดู ชื่ออะไรนะ ใช้อะไรนะตอนนี้? ออม จำไม่ได้แล้ว... ใช่ ใช้ TypeBox ใช่ไหม? TypeBox ครับ เออ โอเค ของ Elysia ใช้ TypeBox เราก็สามารถสลับไปใช้ตัวอื่น อย่าง TypeBox ที่ Elysia ใช้ อะไรอย่างงี้นะครับ ฉะนั้นเนี่ย เราก็ตั้งโจทย์ว่า ทำยังไงที่เราจะ enforce Clean Architecture ลงไปใน TypeScript ได้ นะครับ ฉะนั้นเนี่ย ถ้าเราตั้งโจทย์แบบนี้ หมายความว่า เวลาที่เราเขียน domain ใน Clean Architecture เนี่ย เราจะต้องเขียนเป็น interface อย่างเดียว และเพื่อทำให้มันถอดประกอบของง่าย นะครับ และก็ไม่ผูกกับ validator เจ้าใดเจ้าหนึ่ง นะครับ

ดังนั้นเนี่ย เราจะทำยังไงให้มันสามารถที่จะไปต่อได้

เทคนิคการสร้างฟังก์ชัน Match เพื่อรับประกันว่า Type ขั้น Interface และ Schema ตรงกันเสมอ14:41

สมมติว่าวันนี้เราต้องการเขียน interface ที่ domain เนาะ เราจะรู้ได้ไงว่า source schema เนี่ย type ตรงกันนะครับ ยกตัวอย่างนะครับ อันนี้จะเป็นไฟล์ repository todo นะครับ

ตัวนี้เนี่ย ถ้าเราสังเกตจะเห็นว่า

มันมีการเรียกหลาย ๆ ตัวเข้าไปนะครับ แล้วมันจะมีการ... เราจะมีการ enforce type จากที่เป็น interface

เข้าหาตัว source schema ยังไงนะครับ โดยหลักการ เราก็ต้องเขียน helper ตัวหนึ่ง เป็นฟังก์ชันชื่อว่า match นะครับ ฟังก์ชัน match ตัวนี้จะรับ input 2 อัน ก็คือจะรับ interface ที่มาจาก domain กับรับ source schema ที่เราเขียนไว้นะครับ มันจะเอามา match กันว่า interface ของเรากับ source schema เนี่ย ตรง type กันหรือเปล่า ถ้าตรงกันก็คือ type ผ่าน ถ้าเกิดไม่ตรงกัน type คือไม่ผ่านนะครับ ซึ่งตัวนี้เนี่ย ผมไปเอามาจาก น่าจะเป็นของ Zod ใน GitHub issue สักอันหนึ่ง ผมก็เอามา adopt ให้เป็น Zod V4 เนาะ ซึ่งถ้าเราเอาตัวนี้ไปใส่เนี่ย มันก็จะมีการแกะ ถ้าเกิด type มันไม่ตรงกันเนี่ย มันก็จะเกิด error เกิดขึ้นนะครับ

ตัวอย่างการใช้งานคร่าว ๆ เนาะ สมมติว่าวันนี้เรามี type level ที่เป็น UserUpdate เนาะ เรามี DB มาใช่ไหม DBUser มา แล้วเราก็ pick field name กับ email เป็น union มาถูกไหม

ดังนั้นเนี่ย แปลว่าตัว UserUpdate จะเป็น object ที่มี name กับ email อยู่ถูกป่ะ แล้วเราก็พยายามจะเอา validation เนี่ย มาใส่ตรงนี้ แทนที่ปกติเวลาที่เราเขียน schema ทั่วไป เราจะต้อง infer มาจากก้อนนี้ จาก Zod schema เนี่ย วิ่งไปหา controller ซึ่งการทำแบบนั้น มันจะทำให้มันผูกกันหมด และมันไม่สามารถเป็น Clean Architecture ได้ หลักการก็คือว่า เราก็เขียน Zod schema ขึ้นมานะครับ และก็รับ type UserUpdate เข้าไปที่ฟังก์ชัน match และเราก็รับ object ของ Zod schema ลงไปนะครับ เพื่อให้ว่าเวลาที่เราเช็ค type infer type มาจากตัว Zod schema เนี่ย กับ type ตัวนี้มันตรงกัน ถ้าพอ type มันตรงกันเนี่ย มันก็จะ compile ผ่านนะครับ อันนี้จะเป็นกลไกที่ช่วย enforce ว่า เราจะสามารถ enforce layer ของ Clean Architecture ในระดับของ type level และ code level ลงไปได้นะครับ

ป้องกันการรั่วไหลของ Type Database (เช่น Object ID) สู่เลเยอร์ออฟฟิศด้วย Auto-conversion ที่ชั้น Zod17:04

โอเค อีกอันหนึ่งเนาะ ก็คือว่า

พอเป็นแบบนี้เนี่ย และก็อย่างที่บอก ก็คือผมก็จะได้ architecture ที่ type กับ Zod เนี่ย ไม่ผูกกันแล้วเนาะ อีกอันหนึ่งที่ทำเนาะ ก็คือเรื่องของ object ID เนาะ ถ้าเกิดใครใช้ MongoDB เนี่ย จะรู้ว่าเวลาที่ MongoDB เก็บ index เนี่ย มันจะเก็บเป็น object ตัวหนึ่งที่ชื่อว่า object ID นะครับ ทีนี้ มันจะมีปัญหานิดหนึ่งก็คือว่า เวลาเราเขียน AI เนี่ย ถ้าเราไม่ enforce rule ให้ชัดเจนเนี่ย หลักการเนี่ย ก็คือว่าเวลาที่เราเขียน layer ของ repository repository มันจะยุ่งกับ database เนาะ แต่ว่าเวลาที่ AI เขียนเนี่ย ถ้าเราไม่ enforce rule AI จะเอา object ID เนี่ย ไปถูกเขียนที่ layer ของ

อาจจะเป็น service อาจจะเป็น application อาจจะเป็น controller level อะไรแบบนี้เนาะ มันทำให้เราไม่สามารถที่จะ enforce เรื่องของ Clean Architecture ได้ใช่ไหมครับ ฉะนั้นเนี่ย เราก็ใส่ลงไปในกฎว่า โอเค นะ ถ้าเกิดสมมติจะมีการ conversion เนี่ย เราก็สร้างตัว Zod schema ที่ convert object ID กับ string เนี่ย ลงไปที่ layer ของ Zod เพื่อให้เวลาที่มัน convert เนี่ย มันสามารถทำ auto-conversion ได้ ลักษณะนี้ เราก็สามารถที่จะ enforce

Clean Architecture ลงไปได้นะครับ

เจาะโครงสร้าง End-to-End Type Safety ข้ามเลเยอร์ เมื่อเปลี่ยนจุดเดียว จุดอื่นต้องพังเพื่อส่งสัญญาณ18:11

อ่ะ ทีนี้มาดูตัวอย่างกัน เดี๋ยวออมเนี่ย จะพูดภาพของ end-to-end type safety ที่ชัดกว่าผมเนาะ เพราะว่าออมน่าจะเดโม Elysia นะครับ แต่ว่าของผม จะให้ดูภาพคร่าว ๆ ว่า การ enforce ของผมเนี่ย ที่มันเริ่มต้นจากหน้าบ้านที่เป็น React ไปจนถึงหลังบ้านที่เป็น MongoDB เนี่ย มันจะเริ่มต้นจากการที่มันจะมี React มา React ต่อ tRPC นะครับ และก็ tRPC เนี่ย ก็จะมีฝั่ง client กับฝั่ง server นะครับ และก็ฝั่ง server ก็จะมี Zod กั้นเลเยอร์หนึ่ง วิ่งเข้า service และก็วิ่งเข้า Zod ก่อนเข้า repo นะครับ เพื่อไม่ให้ MongoDB schema เปลี่ยนนะครับ หลักการมันก็จะเบ็นแบบนี้ แปลว่าเราสามารถที่จะทำ end-to-end type safety ตั้งแต่ layer ของ React เนี่ย ยาวไปถึง MongoDB ได้นะครับ โดยที่ไม่มีปัญหาเรื่อง type conversion เพราะว่ามันเป็น type safe หมด หมายความว่า ถ้าเกิดสมมติว่าที่ domain มีการเปลี่ยนแปลงของ field บางอย่างนะครับ ไอ้ chain นี้เนี่ย มันก็จะตายหมดเลยนะครับ ประมาณนี้เนาะ

มีเวลาอยู่ เดี๋ยวผมจะโชว์ code ให้ดูบ้างนะครับ

ตัวโปรเจกต์ตัวนี้เนาะ เดี๋ยวไปดูใน ThaiType ได้นะครับ

อันนี้จะเป็นฟังก์ชัน match ที่ผมบอกเนาะ ก็คือว่าเราจะมีฟังก์ชัน helper ตัวหนึ่งขึ้นมานะครับ เพื่อที่จะบอกว่า เราจะ match ของมันยังไงนะครับ เดี๋ยวไปดูของจริงกัน

บังคับเช็ค Lint และ Type ในการรันทุก Iteration เพื่อสร้าง Feedback Loop ที่ตอบสนองไวที่สุด19:53

โอเค เดี๋ยวให้ดูตัวอย่างเนาะ ก็คือว่า ทางซ้าย เนี่ย มันจะเป็น schema ที่ผมเรียกผ่าน match เนาะ ก็คือเช็ค type ของ RepoTodoContentUpdateData นะครับ แล้วก็ฝั่งขวา เนี่ย จะเป็นเรื่องของการ pick ตัว title กับ description มาเนาะ สมมติว่าผม comment บรรทัดนี้ออกเนาะ schema ผมผิด เนี่ย มันก็จะ error เลย นะครับ เวลาที่เรา vibe code เนี่ย ผมจะบังคับว่าในแต่ละ iteration ของมัน เนี่ย มันจะต้องเช็ค เช็ค type เช็ค lint เช็ค format และก็เช็ค unit test นะครับ แปลว่าถ้าเกิดมันเกิดอาการ ที่ระหว่าง layer ของแต่ละตัว เนี่ย มันมีการเหลื่อมกัน ของ type ไม่ตรงกัน เนี่ย มันจะ error ก่อน แล้วมันก็จะรู้ก่อนว่ามีปัญหา ทำให้ feedback loop เร็วขึ้น ประมาณนี้ นะครับ

อันนี้จะเป็นตัวอย่างคร่าว ๆ ของการทำลักษณะของ type เนาะ

ถ้าเราสังเกต เนี่ย อีกอันหนึ่งเนาะ สมมติว่าผมไปแก้ที่ domain เนาะ ผมมี Todo อยู่ นะครับ แล้วผมก็บอกว่า

ถ้าสังเกตใน domain ของผมเนี่ย ก็จะเป็น interface ธรรมดาเนาะ แปลว่าเราจะสับเปลี่ยน layer อื่น ยังไงก็ได้เนาะ สมมติว่าผมอยากจะเปลี่ยนตัว ID จาก string ให้เป็น number เนาะ มาลองดูกัน

ปุ๊บ นะครับ

แล้วเราก็ลอง

เราก็จะเห็นว่า ทุกจุดเลยนะครับ ของตัวของมันเองเนี่ย มันก็จะเกิด error เพราะว่า type ไม่ตรงกันนะครับ มันก็จะเกิดอาการว่า มันไม่สามารถที่จะ detect type ได้นะครับ

โอเค งั้นกลับไปที่สไลด์ นะครับ

ปลดล็อกความล้าสมองด้วย 'Chief Agent': สั่งให้หยุดแล้วเสนอทางเลือกเมื่อ AI เจอจุดคลุมเครือขัดแย้ง21:56

โอเค นะครับ ฉะนั้นเนี่ย สิ่งที่ผมกำลังพยายามสื่อก็คือว่า วันนี้ถ้าเรามี rule ที่ยังไม่ชัดตั้งแต่แรกอะ เราก็สามารถ refactor ได้แหละ แต่ยิ่งเราทำทีหลัง cost มันยิ่งสูงขึ้นนะครับ แต่วันนี้ถ้าเราเปลี่ยน mindset ใหม่ ว่าวันนี้เราเริ่มจาก template ที่ชัดนะครับ แล้วก็พยายามกำหนด structure ให้ชัด เราจะได้ประหยัดกว่ามากๆ เลยเนาะ กลไกที่สองนะครับ ที่ผมพูดในสามเหลี่ยมเนาะ ก็คือเรื่องแรกก็คือเรื่องของกฎ เราพยายาม enforce rule ลงไปใน AI เพื่อให้ AI เนี่ย ทำตามที่เราต้องการนะครับ เรื่องที่สอง ก็คือเรื่องของ human นะครับ ก็คือกลับมาที่ brain fatigue ก็คือว่า เวลาที่เราใช้ AI มากๆ เนี่ย เราอาจจะเกิดอาการเหนื่อยจากการใช้ AI ภาวะล้าเนาะ เราต้องคิดทุกอย่างเนี่ย ในหัวนะครับ ฉะนั้นเนี่ย goal ก็อยู่ในหัว architecture อยู่ในหัว ทุกอย่างอยู่ในหัวหมดนะครับ เราจะต้องมีการเขียนโค้ดไปด้วยเนาะ ทำให้เราเกิด overload เกิดขึ้นนะครับ สิ่งที่เรา หรือที่ผม suggest ก็คือการ externalize ก็คือการเอา การตัดสินใจทุกอย่าง ออกจากหัวทั้งหมดเลยนะครับ มันคล้ายๆ เหมือนกับการที่เราทำ brain dumping exercise เนาะ ไอ้ตัวนี้ผมก็เลยสร้างตัว framework ขึ้นมาตัวหนึ่งนะครับ ก็คือคล้ายๆ เป็น chief agent นะครับ ตัว chief agent เนี่ยเป็น open source เนาะ เข้าไปดูได้นะครับ หลักการของ chief agent เนี่ย ก็คือทำยังไงก็ได้ ที่เราจะลดภาระสมองให้ได้นะครับ

ลดการตัดสินใจลงนะครับ

อ่ะ เดี๋ยวดูตัวอย่างนะครับ ตัวอย่างของ chief agent คือเวลาทุกครั้ง ที่เวลาผมคุยกับ AI เนี่ย อันนี้จะเป็น prompt พื้นฐานของตัว chief เลยเนาะ คือทุกครั้งเนี่ย ปัญหาที่ผมเคยเจอในอดีต ผมเจอว่า AI มักจะเขียนในทางที่ผมไม่อยากให้เขียนเสมอ ฉะนั้นเนี่ย เวลาที่มันเกิดอาการคลุมเครือเกิดขึ้น ผมจะให้มันบอกว่าเฮ้ย ตอนนี้คลุมเครือนะ เมื่อไหร่คลุมเครือห้ามทำอะไร ให้คุณหยุด และเสนอแนวทางมา สองสามทาง และก็ให้บอกว่า แนวโน้มที่จะเกิดขึ้นต่อจากเนี้ย จะทำอะไรบ้าง ทำให้เราตัดสินใจได้ว่า เราจะทำยังไงต่อ นะครับ อันนี้จะเป็นกลไกคร่าวๆ เนาะ อีกตัวหนึ่งก็คือเรื่องของการทำซ้ำเนาะ

อีกอันหนึ่งที่ผมชอบมากๆ เลยก็คือว่า ของผมเนี่ย มันจะมีเวลาในเวลาที่ผมทำ ในโปรเจกต์ขนาดใหญ่ เนี่ย ผมจะมีการกำหนด hierarchy ของ rule เนาะ ถ้าเกิดสมมติว่าใครใช้ Claude code เนี่ย rule file มันจะมีอันเดียวก็คือ CLAUDE.md ถูกไหม แต่ในโปรเจกต์ขนาดใหญ่ ผมทำเป็น monorepo ผมจะมี layer ของ rule เนี่ย ประมาณ 7 layer นะครับ มันจะมีตั้งแต่ layer ของ Claude ลงไป layer ของ goal แล้วก็ layer ของ รายละเอียดเยอะยิบย่อย ช่างมันนะครับ ฉะนั้นเนี่ย เมื่อไหร่ก็ตาม ที่ AI มันเจอว่า design ของแบบ A กับแบบ B อ่ะ มันขัดแย้งกัน ให้มันปิงหาเราก่อนว่าเราจะเอาแบบไหน ฉะนั้นเนี่ย ตัว AI มันจะเริ่มปิงมาหาเราว่า ตอนนี้ design เรามีปัญหา เราต้องรีบแก้ก่อน เพื่อให้เรามั่นใจว่า ของที่เราจะ deliver ไปอ่ะ มันถูกต้องนะครับ อันนี้เดี๋ยวไปดูในโค้ดได้นะครับ

ใช้ Sub-Agent ดักจับการพัง (Negative Progress) และเทคนิค Grill Me เพื่อจัดระเบียบความคิดคนให้ตรงกับ AI24:37

อันนี้ผมแปลไทยมาให้

ตัวอย่างของ sub agent ของ chief agent นะครับ เวลาผมถาม ผมถามว่า โอเค ผมเพิ่ม goal ให้ละ ลองวิจารณ์ goal หน่อยว่าเป็นยังไงนะครับ สิ่งที่มันตอบมาเนี่ย ก็คือว่า มันก็จะวิจารณ์เราว่า ตอนนี้มีปัญหาอะไร และมันจะ suggest ให้เราทำอะไรออกมา ดังนั้นแปลว่าอะไร แปลว่า เวลาที่เราทำงานกับ AI เนี่ย เวลาที่เรา vibe code เนี่ย เราไม่ต้องคิดทุกอย่างเองก็ได้ครับ แต่ว่าเราทำยังไงก็ได้ ที่เราลดภาระสมองได้ ให้ AI เนี่ย ช่วยเราให้ได้มากที่สุดนะครับ

หรืออีกตัวหนึ่งก็คือเรื่องของ sub agent ที่เป็น builder agent เนาะ ผมก็จะใส่ว่า ทุกครั้งที่มันแก้ปัญหาเนี่ย ให้มันดูว่ามันเป็น positive progress หรือ negative progress นะครับ เวลา positive progress เนี่ย มันก็คือหมายความว่า เวลาที่มันแก้ปัญหาเนี่ย unit test มันจะลดลง ลดลง ลดลง อันนี้เราเรียกว่า positive progress แต่เมื่อไหร่ก็ตามที่มันแก้แล้ว ตัว test case มัน error มากขึ้นนะครับ ผมจะเรียกว่าเป็น negative progress ให้มัน deny ตัวเอง แล้วก็ปิงมาหาคนนะครับ ตรงนี้มันจะทำให้ตัว agent เนี่ย มีความสามารถในการแก้ปัญหาด้วยตัวเองได้ และก็เมื่อไหร่ก็ตามที่มันเจอทางตัน ให้มันวิ่งมาหาคนก่อนนะครับ ประมาณนี้ คร่าวๆ นะครับ

และก็อีกอันหนึ่งที่ผมชอบก็คือ สกิลของ Matt Pocock เนาะ ก็คือเขาพูดถึงเรื่องของสกิล Grill Me เนาะ ก็อันนี้ไปดูตัวอย่างได้ เขาบอกว่าเป็นสกิลที่ทำให้เรากับ AI อะ คุยภาษาเดียวกัน เพราะบางทีอะ เรามีอะไรอยู่ในหัวเยอะ การที่ใช้สกิลช่วย ก็ทำให้เราสามารถที่จะ คุยเป็น message เดียวกันกับ AI ได้นะครับ อันนี้ก็ลองไปเล่นดู ค่อนข้างดีเลยนะครับ ตัว prompt ตัวนี้ โดยคอนเซปต์หลักการของในโหมดของ human เนี่ย ก็คือยังไงก็ได้ ที่เราสามารถลดภาระสมอง โดยการที่ทำให้แต่ละกิ่งก้านของ design ชัดเจนมากพอ

เพื่อให้ AI เนี่ย ไม่เลอะเทอะออกนอกลู่นอกทางนะครับ

สรุป 3 แกนหลักของ AI Engineering (คน-กฎ-AI) และฝากผลงานโปรเจกต์ท้ายคลิป26:26

พาร์ตสุดท้ายเนาะ ก็คือผมจะไม่พูดเยอะ เพราะเราไม่ได้พูดถึง AI เยอะนะครับ แต่ว่าผมจะพูดถึงเรื่องของ AI engineering AI engineering เนี่ย มีผลสำคัญมาก ที่ทำให้เรา vibe code ได้ดีขึ้นนะครับ ไม่ว่าจะเป็นเครื่องมือต่างๆ Claude Code, OpenClaw ทุกอย่างเนี่ยนะครับที่เราใช้ รวมถึงเทคนิคที่เราใช้ ก็ทำให้เราทำงานได้แม่นยำขึ้นนะครับ

โอเค นะครับ สรุปมีสามแกนนะครับ แกนแรกนะครับ คน เตรียมเป้าหมายให้ชัดนะครับ ยิ่งมี template ยิ่งดีนะครับ เราจะได้ลดการตัดสินใจได้ สองนะครับ เรื่อง rule นะครับ เรามี template มี type system enforce rule ให้ชัด สามนะครับ AI นะครับ พยายามเอา AI engineering เข้ามาใช้ ไม่ว่าจะเป็น agentic coding, orchestrator หรือการ automatic feedback จากระบบภายนอกเนาะ ประมาณนั้นนะครับ ก็เวลาเหลืออีกประมาณ 6 นาทีนะครับ ผมก็จะมีโปรเจกต์หลักๆ ตอนนี้จะ active อยู่ 2-3 ตัวนะครับ ก็จะมี Kubricate นะครับ จะเป็น type-safe Kubernetes framework ก็เป็น TypeScript นะครับ ตั้งแต่ติดน้ำท่วมหาดใหญ่มา ก็มีหยุดไปชั่วคราวและ เดี๋ยวจะกลับมาเขียนต่อเพื่อให้ไป version 1 ได้นะครับ อันนี้ก็กำลัง work กับมันอยู่ครับ design หลังบ้าน อีกตัวหนึ่งก็จะเป็นหนังสือ Type-Safe Design Patterns เป็น modern TypeScript ก็เป็นหนังสือนะครับ หลายๆ ครั้งที่ไปดูตามงานมา ฟังออมมาบ้าง ฟังคนนู้นมา ก็เก็บเล็กผสมน้อย เอาไอเดียที่เจอ pattern ที่คนใช้บ่อยๆ นะครับ ก็มาเขียนเป็นหนังสือ ก็ลองไปตามได้นะครับ ประมาณนี้ นะครับ ก็สำหรับวันนี้ก็ประมาณนี้ครับ สวัสดีครับ