Vibe Coding, ระบบอัตโนมัติ และ MCP

Vibe Coding = การจ้าง AI ทำงานแทน

Vibe Coding โดยแก่นแท้แล้วก็คือการจ้าง AI พัฒนาโปรแกรมแทน

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

1. กำหนดงานเพื่อแก้ปัญหาของตัวเองให้ชัดเจน
2. สื่อสารให้ผู้พัฒนาเข้าใจสิ่งนั้นได้ดี
3. สนับสนุนทรัพยากรที่จำเป็นต่อการสร้างโปรแกรมให้ดี
4. ตรวจสอบว่าโปรแกรมที่สร้างขึ้นมาทำงานแทนได้ตรงตามเจตนาหรือไม่
5. ระหว่างกระบวนการนี้ หากมีเรื่องที่ตัวเองไม่รู้ ก็เรียนรู้จากผู้พัฒนาไปทีละน้อยจนค่อย ๆ ทำเองได้

ถ้านำมาเทียบจากมุมของคนทำ Vibe Coding

1. กำหนด PRD และ user flow
2. ใช้พรอมป์ต์และคำสั่งที่ดี (เช่น Cursor Rules)
3. จับจุดที่เบี่ยงไปจากเจตนาและรัน automated test
4. เรียนรู้ผ่านการโต้ตอบไปมากับ AI ระหว่างกระบวนการ

แล้วข้อ 3 ล่ะ? เรื่องนี้มองได้จาก 2 ด้านของโปรแกรม

• อย่างแรก โปรแกรมต้องถูกรันที่ไหนสักแห่ง → ตัดสินใจเรื่องสภาพแวดล้อมการรันและการ deploy
• อย่างที่สอง โปรแกรมคือก้อนโค้ดที่ 'รับอินพุตแล้วประมวลผลเป็นเอาต์พุต' → จัดเตรียมข้อมูลและ API

โปรแกรมต้องถูกรันได้

• ในการจ้างพัฒนาซอฟต์แวร์ ปกติความรับผิดชอบของนักพัฒนามักจบที่การเขียนโค้ด ส่วนความรับผิดชอบเรื่อง deployment และ operation เป็นของผู้ว่าจ้าง
  • แต่ผู้พัฒนาจะให้คู่มือสำหรับให้ผู้ว่าจ้างสามารถรันโปรแกรมนี้ได้
• ในฐานะผู้ว่าจ้างงานภายนอก หากบอก AI ถึงสภาพแวดล้อมที่ใช้รันและ deploy โค้ด มันจะทำได้ดีมาก
  • โดยเฉพาะถ้าเป็นโค้ดที่ทำงานบนเว็บเบราว์เซอร์ยิ่งเป็นแบบนั้น
• เมื่อก่อน แม้แต่สคริปต์ง่ายมาก ๆ อย่าง 'ลบไวยากรณ์บางส่วนของเอกสาร Markdown ด้วย regular expression' ก็ยังไม่ง่ายสำหรับคนที่ไม่ใช่นักพัฒนาที่จะรันหรือ deploy เอง
• ตอนนี้สามารถใช้ Claude Artifacts, Gemini Canvas สร้างโปรแกรมเล็ก ๆ ของตัวเองแล้วรันได้แทบจะทันที ถ้าอยากให้คนอื่นใช้ด้วย ก็สร้างและ deploy บน Lovable ได้ ทั้งหมดนี้ทำได้ฟรีในเวลาอันสั้น
• ไม่ใช่ว่า Vibe Coding จะต้องสร้างเป็น 'แอป' เสมอไป ขอแค่เป็นโปรแกรมที่แก้ปัญหาให้เราและลดงานซ้ำ ๆ ได้ จะเป็นแอป สคริปต์ GPTs หรือพรอมป์ต์ก็ได้ทั้งนั้น

API ที่ทำให้โปรแกรมมีประโยชน์ยิ่งขึ้น

• แต่โปรแกรมขนาดเล็กก็มีข้อจำกัด
  • Markdown remover ไม่ได้เชื่อมกับ DB, API หรือ LLM
  • เพราะงั้นทั้งการป้อนข้อความและการคัดลอกผลลัพธ์ไปโพสต์ที่อื่นก็ยังต้องให้ผู้ใช้ทำเองทั้งหมด
• ถ้าจุดประสงค์ของผู้ใช้คือ 'ปรับแต่งบทความที่เขียนไว้ใน Notion แล้วเอาไปลง SNS' ล่ะ?
  • อินพุต: ใส่แค่ลิงก์หน้า Notion
  • การประมวลผล: นำข้อความที่ดึงมาใส่ LLM เพื่อสรุปให้เหมาะกับ SNS แล้วลบไวยากรณ์ Markdown
  • เอาต์พุต: ตรวจทานบทความ แล้วถ้าอนุมัติก็โพสต์ไปยังบัญชี SNS ของฉันโดยอัตโนมัติ
• แม้จะต้องแลกกับเวลาในการตอบสนองที่เร็วและความอเนกประสงค์ แต่ก็ช่วยลดเวลาและพลังงานที่ผู้ใช้ต้องใช้กับงานนั้นลงได้มาก กล่าวคือ สำหรับเป้าหมายเฉพาะ มันจึง 'มีประโยชน์' มากขึ้น
• สุดท้ายแล้ว ประโยชน์ของโปรแกรมขึ้นอยู่กับว่ามันลดสิ่งที่ผู้ใช้ต้องทำเองได้มากแค่ไหนในมุมของอินพุต/การประมวลผล/เอาต์พุต
  • ทำอินพุตให้เป็นอัตโนมัติ หรือ
  • ทำการประมวลผลให้ซับซ้อนขึ้น หรือ
  • ทำเอาต์พุตให้เป็นอัตโนมัติ
• ในโปรแกรมทั่วไป API ช่วยให้ทำอินพุตและเอาต์พุตแบบอัตโนมัติ รวมถึงการประมวลผลขั้นสูงได้ (กล่าวคือโดยการเชื่อมต่อกับโปรแกรมอื่น)
  • อินพุต: ขอสิทธิ์ Notion แล้วเรียก Notion API เพื่อดึงเนื้อหาของหน้า
  • การประมวลผล: ส่งเนื้อหาหน้า Notion พร้อม system prompt ไปยัง LLM API เพื่อรับคำตอบที่เหมาะกับ SNS
  • เอาต์พุต: ขอสิทธิ์ Threads แล้วเรียก SNS API เพื่อโพสต์ข้อความ
• แต่การสร้างแบบนี้ไม่ใช่เรื่องง่ายมากนัก แม้แต่สำหรับนักพัฒนาที่มีประสบการณ์ โดยเฉพาะเพราะเรื่อง authorization ที่ยุ่งยาก
• จะทำให้เรื่องนี้ง่ายขึ้นได้ไหม?

เครื่องมืออัตโนมัติและ MCP ที่ช่วยจัดการการเชื่อมต่อ API อันยุ่งยากแทน

• ถ้าใช้เครื่องมืออัตโนมัติอย่าง Zapier, Make ก็ไม่จำเป็นต้องเชื่อมต่อ API ด้วยตัวเอง
  • ตัวอย่าง: เมื่อมีไอเท็มใหม่ใน Notion DB -> รัน ChatGPT -> อัปโหลดไป Instagram เป็น Zap
• ปกติแล้วถ้าจะเรียก Instagram post API ต้องสร้างแอปเฉพาะและผ่านการตรวจสอบด้วย
• แต่ใน Zapier หรือ Make นั้น มีการสร้างแอปสำหรับอัปโหลด Instagram ไว้แล้ว และ flow สำหรับขอสิทธิ์และรับส่งข้อมูลก็ถูกทำไว้ครบหมดแล้ว เราจึงไม่ต้องกังวลกับปัญหาเรื่องสิทธิ์ที่ยุ่งยากเอง
• อย่างไรก็ตาม สำหรับบางคน แม้แต่การประกอบลำดับแบบ 'อันนี้แล้วต่อด้วยอันนั้น' ก็อาจยังยากและน่ารำคาญอยู่ และสิ่งที่ทำให้คนกลุ่มนี้ทำทุกอย่างผ่าน LLM chatbot ได้ก็คือ MCP/A2A
• เหมือนที่โปรแกรมทั่วไปสามารถทำอะไรได้มากกว่า logic ง่าย ๆ ผ่าน API โปรแกรมที่เป็น LLM chatbot ก็สามารถเชื่อมกับโปรแกรมอื่นผ่าน MCP เพื่อทำอะไรได้มากกว่าการส่งออกแบบข้อความ/ภาพ/เสียงธรรมดา
  • นั่นหมายความว่าใน Claude จะสามารถสั่งว่า 'ดึงหน้า Notion ของฉันมาสรุป แล้วโพสต์ลง Instagram ให้หน่อย' ได้
• แน่นอนว่าถ้าจะทำแบบนี้ ก็ต้องเชื่อม MCP server ที่เหมาะสม (Notion, Instagram) เข้ากับ MCP client (Claude)
  • บทบาทสำคัญที่สุดของ MCP server คือการเรียก API แทนผ่าน tool โดย Notion มี official MCP server อยู่แล้ว แต่ Instagram ไม่มี
  • ถ้าอย่างนั้น Claude จะเรียก Instagram API อย่างไร?
• ตรงนี้ Zapier ก็กลับมาอีกครั้ง ผ่าน MCP server ที่ Zapier หรือ Make ให้มา ก็สามารถอัปโหลดไป Instagram ได้
• กล่าวคือ ถ้าเชื่อมเครื่องมืออัตโนมัติที่มี integration จำนวนมากอยู่แล้วเข้ากับ LLM chatbot ผ่าน MCP ก็จะทรงพลังมาก

ศักยภาพและข้อจำกัดของ MCP

• แต่เมื่อมองแบบนี้ บางคนอาจสงสัยว่าทำไมต้องใช้ MCP ด้วย
  • เพราะงานที่ตอนนี้ทำได้ด้วย chatbot + MCP เกือบทั้งหมด เครื่องมืออัตโนมัติก็ทำได้เช่นกัน
• แต่ผู้เขียนรู้สึกว่าศักยภาพของ MCP สูงมากด้วยเหตุผล 3 ข้อ
  1. อินเทอร์เฟซที่สะดวก (ผู้ช่วย chatbot ที่จัดการทุกอย่างให้ทั้งหมดอาจเป็นโปรแกรมในอุดมคติไม่ใช่หรือ?)
  2. ผู้ใช้เข้ามามีส่วนร่วมกับงานที่อ่อนไหวได้สะดวกกว่า
  3. ไม่เพียงทำงานอัตโนมัติในเครื่อง PC ของฉันได้ เช่น การควบคุมไฟล์ระบบและเบราว์เซอร์ แต่ยังให้ข้อมูลเพิ่มเติมได้มากขึ้น เช่น resources, prompt templates เป็นต้น
• เวลาจะใช้ MCP ก็มีเรื่องที่ต้องใส่ใจอยู่มาก
  • ยิ่งมอบอะไรให้ MCP มากเท่าไร ก็ยิ่งต้องใส่ใจเรื่องความปลอดภัยมากขึ้น ดังนั้น official remote MCP server จึงปลอดภัยกว่าแบบ local
  • ถ้าให้ MCP tools กับ LLM มากเกินไป tool ที่เราต้องการอาจไม่ถูกรัน และเพราะคำจำกัดความของ tool ทั้งหมดจะถูกส่งไปเป็น input token ด้วย ค่าใช้จ่ายและเวลาในการเรียก LLM ก็จะเพิ่มขึ้น
  • ความสุ่มแบบเฉพาะตัวของ LLM ก็ยังเป็นสิ่งที่ต้องระวังเสมอในบริการเชิงพาณิชย์
• สุดท้ายแล้ว ไม่ว่าจะเชื่อม API เข้ากับโปรแกรมของฉัน ออกแบบ automation flow หรือผูก MCP เข้ากับ LLM chatbot งานทั้งหมดก็เหมือนกันตรงที่เป็นการ 'ช่วยทำงานแทนฉัน'
• ไม่จำเป็นต้องเครียดเพราะคีย์เวิร์ดอย่าง Make หรือ MCP กำลังมาแรง ขอแค่เลือกวิธีที่เราถนัด ทำความเข้าใจข้อดีข้อเสียของแต่ละแบบ แล้วสร้างโปรแกรมที่ทำงานแทนเราได้ก็พอ

สรุป

• Vibe Coding คือการจ้าง AI พัฒนาโปรแกรมแทน
• ถ้าช่วยทำงานแทนเราได้ดี ไม่ว่าจะเป็นเว็บแอป code snippet หรือพรอมป์ต์ ก็ล้วนเป็นโปรแกรมที่มีประโยชน์ได้
• ถ้าอยากให้โปรแกรมมีประโยชน์มากขึ้น ก็จำเป็นต้องเชื่อม API เพื่อทำอินพุต/เอาต์พุตอัตโนมัติและการประมวลผลขั้นสูง
• เครื่องมืออัตโนมัติช่วยแก้ความยุ่งยากของการเชื่อม API แทนเรา
• โปรแกรมที่เป็น LLM chatbot ก็มีประโยชน์มากขึ้นได้ผ่านการเชื่อม MCP โดยเฉพาะการเชื่อม MCP server ที่เครื่องมืออัตโนมัติเป็นผู้ให้บริการนั้นทรงพลังมาก
• ไม่จำเป็นต้องใช้แค่ API, automation หรือ MCP อย่างใดอย่างหนึ่งเท่านั้น และถ้าผสมกันจะยิ่งง่ายและทรงพลังขึ้น (เช่น ต่อแค่ Notion MCP กับ Claude แล้วตั้งค่า Notion to Instagram บน Zapier เพื่อทำการอัปโหลดอัตโนมัติ)
• โดยพิจารณาทั้งข้อดีข้อเสีย เลือกวิธีที่เหมาะกับตัวเอง แล้วลองสร้างโปรแกรมที่แก้ปัญหาของเรา (ร่วมกับ AI) กันเถอะ

[iolothebard]

แค่ระดับ vibe coding คงยังเรียกว่าเป็นการจ้างเอาต์ซอร์สไม่ได้ครับ งานเอาต์ซอร์สจะตรวจรับกันเป็นระดับโปรเจกต์ แต่ AI coding agent ในตอนนี้ยังต้องตรวจรับกันในระดับงานย่อยที่เล็กกว่านั้น

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

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

หรือบางทีอาจเป็นเพราะผมมี vibe ไม่พอก็ได้…

[ifmkl]

https://tech.kakao.com/posts/700 ผมรู้สึกว่าโพสต์นี้เป็นตัวอย่างที่ดีของ Vibe Coding และดูเหมือนว่าบริบทจะคล้ายกันครับ ผมเองก็เห็นด้วยกับสิ่งที่คุณเขียนไว้ครับ

[spilist2]

ได้อ่านบทความที่น่าสนุกเพราะคุณเลย! ขอบคุณครับ

[spilist2]

แล้วข้อ 3 ล่ะ? -> เป็นเรื่องการรองรับรีซอร์สครับ

ด้านบนผมใส่หมายเลขเป็น 1, 2, 4, 5 แต่ใน Markdown มันเปลี่ยนเป็น 1234 อัตโนมัติเลยครับ