Tools: แค่มีโค้ดก็พอแล้ว - Code Is All You Need

• มีการอ้างว่าวิธีเชื่อมต่อเครื่องมือแบบ MCP คือ “อนาคต” แต่ในความเป็นจริงกลับมีข้อจำกัดเรื่อง การประกอบต่อยอดร่วมกันได้ไม่ดีและการใช้คอนเท็กซ์มากเกินไป ทำให้ การเขียนโค้ดโดยตรงยังมีประสิทธิภาพมากกว่า
• แม้อยู่ในยุค LLM การสร้าง/ใช้โค้ดก็ยังได้เปรียบด้านความน่าเชื่อถือและการตรวจสอบได้ สำหรับ งานอัตโนมัติและงานที่ทำซ้ำ
• LLM มีจุดแข็งด้าน การสร้างโค้ดและรันซ้ำ มากกว่าการทำอัตโนมัติแบบอาศัยการอนุมาน และกระบวนการที่อิงโค้ดก็ยอดเยี่ยมกว่าในด้านการระบุปัญหา การตรวจสอบ และการขยายระบบ
• เครื่องมือบางประเภทอย่าง Playwright (แนวทาง MCP) ทำให้ความไม่แน่นอนและความยากในการดีบักเพิ่มขึ้นในทุกขั้นตอนที่เป็น “การอนุมาน” ขณะที่การ สร้าง/แก้สคริปต์ด้วยโค้ดโดยตรง ช่วยเพิ่มทั้งความทำซ้ำได้ ความเร็ว และความน่าเชื่อถือ
• เวิร์กโฟลว์ “โค้ด-ตรวจทาน-ทำซ้ำ” ที่ LLM หนึ่งตัวสร้างโค้ด และอีกตัวตรวจสอบ/อธิบายโค้ดนั้น คือกระบวนการอัตโนมัติที่ทรงพลังที่สุดในทางปฏิบัติ

---

แค่มีโค้ดก็พอแล้ว

• ถ้าคุณติดตามผมบนทวิตเตอร์อยู่ ก็น่าจะรู้ว่าช่วงหลังมานี้ผมไม่ได้มอง Model Context Protocol (MCP) ในแง่บวกนัก
• เหตุผลไม่ใช่เพราะผมไม่ชอบไอเดียนี้ แต่เพราะ MCP ไม่ได้มีประสิทธิภาพอย่างที่โฆษณาไว้
• MCP มีข้อบกพร่องหลักอยู่สองอย่าง
  • มันไม่ได้ให้ ความสามารถในการประกอบต่อยอด (composable) อย่างแท้จริง
  • มัน ต้องการคอนเท็กซ์มากเกินไป จนกินคอนเท็กซ์มากกว่าการเขียนและรันโค้ดโดยตรงเสียอีก
• เราสามารถยืนยันเรื่องนี้ได้ด้วยการทดลองง่ายๆ
  • ตัวอย่างเช่น ลองใช้ GitHub MCP ทำงานสักอย่าง แล้วลองทำงานเดียวกันด้วยเครื่องมือ gh CLI จะพบว่าแบบหลังใช้คอนเท็กซ์ได้มีประสิทธิภาพกว่ามาก และไปถึงผลลัพธ์ที่ต้องการได้เร็วกว่า

But MCP is the Future! : แต่ MCP คืออนาคตไม่ใช่หรือ?

• ผมอยากพูดถึงฟีดแบ็กที่ได้รับต่อจุดยืนนี้ของผม (แนวคิดที่ว่าโค้ดดีกว่า)
• ผมได้ทดลอง MCP อย่างจริงจังในบริบทของ agentic coding และประเมินมันตรงจุดที่ ข้อจำกัดของมันแสดงออกชัดที่สุด
• ฟีดแบ็กอย่างหนึ่งคือ “MCP ไม่จำเป็นนักสำหรับการสร้างโค้ดทั่วไป เพราะตอนนี้โมเดลก็เก่งเรื่องการสร้างโค้ดอยู่แล้ว” ขณะเดียวกันก็มีความเห็นว่า MCP อาจมีความหมายสำหรับ แอปพลิเคชันที่มุ่งไปที่ผู้ใช้ปลายทาง ใน โดเมนเฉพาะ (เช่น งานอัตโนมัติในบริษัทการเงิน)
• อีกความเห็นหนึ่งคือ ในอนาคตโมเดลจะเข้าถึงเครื่องมือได้หลากหลายขึ้นและจัดการงานที่ซับซ้อนขึ้นได้ ดังนั้นเราควรให้ความสำคัญกับศักยภาพนั้น

• แต่ข้อสรุปของผมในตอนนี้คือ: จากข้อมูลที่ผมทดลองและประสบการณ์จริง MCP ในปัจจุบันใช้งานยากกว่าการเขียนโค้ดโดยตรงเสมอ
  • เหตุผลใหญ่ที่สุดคือ MCP พึ่งพาการอนุมาน (inference)
  • ถ้ามองความพยายามทุกแบบในทุกวันนี้ที่ต้องการ “เชื่อมเครื่องมือให้ LLM มากขึ้น” สุดท้ายมันก็มักจะมีเลเยอร์ที่ให้ LLM รับเครื่องมือทั้งหมดแล้ว กรองให้เหมาะกับงาน
  • จนถึงตอนนี้ยังไม่เคยมีใครเสนอรูปแบบหรือแนวทางที่ดีกว่านี้ได้จริง

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

Replace Yourself With A Shellscript

• วิธีหนึ่งในการมองปัญหานี้คือ: ถ้าไม่มี AI เครื่องมือที่นักพัฒนาใช้แก้ปัญหาก็คือโค้ด
• สำหรับคนที่ไม่ใช่นักพัฒนา โค้ดอาจเป็นเรื่องยาก และงานหลายอย่างที่คนทำด้วยมืออยู่จริงๆ นั้น ในความเป็นจริงสามารถทำให้เป็นซอฟต์แวร์อัตโนมัติได้
• ปัญหาในโลกจริงคือ ใครจะเป็นคนเขียนโค้ดนั้นให้ หากคุณอยู่ในสภาพแวดล้อมเฉพาะและเขียนโปรแกรมเองไม่ได้ การจะไปเริ่มเรียนเขียนโค้ดใหม่ก็ยาก และก็ยากที่จะหวังว่าจะมีใครมาเขียนโค้ดแบบปรับแต่งให้
• แน่นอนว่างานบางประเภทอาจ ต้องพึ่งการอนุมาน (การตัดสินใจ/ความยืดหยุ่นแบบมนุษย์) จริงๆ แต่ในทางปฏิบัติ งานส่วนใหญ่ที่ชัดเจนและทำซ้ำได้ ล้วนทำให้เป็นอัตโนมัติด้วยโค้ดได้

• มีสำนวนเก่าในหมู่นักพัฒนาว่า “แทนที่ตัวเองด้วย shell script” และในความเป็นจริง งานอัตโนมัติแบบนี้ก็มีมาอย่างต่อเนื่องตั้งแต่ก่อนหน้านี้แล้ว
• แต่ในยุคของ LLM และการเขียนโปรแกรม เรากลับพยายาม แทนที่ตัวเองด้วย LLM แทน shell script ซึ่งตรงนี้ทำให้เกิด ปัญหาสามอย่าง (ต้นทุน ความเร็ว ความน่าเชื่อถือ)
• ก่อนจะแก้สามปัญหานี้ได้ ก็ยังไม่ใช่ขั้นที่จะไปคิดเรื่องการใช้เครื่องมือ (เช่น MCP) เสียด้วยซ้ำ
• กล่าวคือ หัวใจสำคัญคือต้องรับประกันให้ได้ก่อนว่า ระบบอัตโนมัตินั้นทำงานได้จริงในรูปแบบที่ขยายได้

Automation at Scale : แก่นแท้ของระบบอัตโนมัติขนาดใหญ่

• หัวใจของระบบอัตโนมัติคือการจัดการงานที่ทำซ้ำและนำกลับมาใช้ซ้ำได้ด้วยโค้ด
• ถ้าเป็นงานที่ทำครั้งเดียวแล้วจบ ก็ไม่จำเป็นต้องทำอัตโนมัติ การทำอัตโนมัติเริ่มต้นจาก งานที่จะต้องทำหลายครั้ง และงานที่เครื่องจักรให้ประโยชน์ด้านผลิตภาพได้จริง
• ในทางปฏิบัติ แก่นแท้ของระบบอัตโนมัติคือ ลองทำด้วยมือสัก 1-2 ครั้ง สรุปวิธีการทำงาน แล้ว ทำให้เครื่องทำซ้ำได้เป็นพันครั้ง

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

• ตรรกะนี้ไม่ได้ใช้ได้แค่กับการคำนวณง่ายๆ แต่ยังใช้ได้กับ งานพัฒนาซอฟต์แวร์จริง ด้วย
  • ตัวอย่างเช่น เมื่อไม่นานมานี้ผมได้แปลงฟอร์แมตทั้งบล็อกนี้จาก reStructuredText ไปเป็น Markdown
  • ผัดวันประกันพรุ่งเรื่องนี้มานานพอสมควร เพราะมันน่ารำคาญ และผมก็ไม่ไว้ใจให้ LLM แปลงให้ตรงๆ เนื่องจากกลัวว่าจะมี การตกหล่นหรือความผิดพลาดเล็กๆ น้อยๆ หรือการบิดเบือนคอนเท็กซ์
  • สุดท้ายผมเลย ไม่ได้ใช้ LLM เพื่อ “ลงมือแปลงโดยตรง” แต่ให้มันสร้างโค้ดสำหรับการแปลง แล้วใช้โค้ดจัดการแทน

LLM → โค้ด → LLM: ภาพจริงของระบบอัตโนมัติแบบตรวจสอบซ้ำเป็นรอบ

• ขั้นแรก ผมขอให้ LLM สร้าง ลอจิกแกนกลางสำหรับแปลง reStructuredText เป็น Markdown
  • ไม่ใช่แค่การแปลงแบบตรงๆ แต่ให้ ใช้ AST (abstract syntax tree) โดยตรง
    • parse reStructuredText เป็น AST → แปลงเป็น Markdown AST → render เป็น HTML
    • วิธีนี้ทำให้ได้ ขั้นตอนการแปลงระหว่างทาง และตรวจเทียบ/ตรวจสอบผลลัพธ์ได้ง่ายขึ้น

• ขั้นที่สอง ผมยังให้ LLM เขียน สคริปต์เปรียบเทียบ HTML เดิมกับ HTML ใหม่ ด้วย
  • โดยออกแบบให้วิเคราะห์ diff ของ HTML หลังการแปลง พร้อมปรับแก้ความแตกต่างเล็กน้อยโดยอัตโนมัติก่อนเปรียบเทียบ (เช่น ช่องว่าง วิธีจัดการ footnote ฯลฯ)
  • ทำให้ LLM คำนึงถึงประเภทของข้อผิดพลาดที่ยอมรับได้ในการแปลงด้วยตัวเอง
  • ตัวอย่างเช่น ถึงแม้การแสดงผล HTML ของไลบรารี Markdown/reStructuredText จะแตกต่างกันเล็กน้อย ก็ให้ สะท้อนในสคริปต์เพื่อกรองเฉพาะความเสียหาย/ข้อผิดพลาดที่เป็นสาระสำคัญ

• ขั้นที่สาม ผมขอให้ LLM เพิ่ม สคริปต์สำหรับรันแบบแบตช์เพื่อวิเคราะห์ผลลัพธ์ของไฟล์หลายร้อยไฟล์
  • ด้วยสคริปต์นี้ ผมสามารถรันกับไฟล์ทั้งหมดและทำ การปรับปรุงซ้ำเป็นรอบ (agentic loop) ไปเรื่อยๆ จนความแตกต่างลดลง

• กระบวนการทั้งหมดมีดังนี้:
  • เริ่มจากทดลองกับตัวอย่างราว 10 ไฟล์ก่อน แล้ววนซ้ำจนความแตกต่างลดลงอย่างมาก
  • เมื่อได้สภาพที่น่าพอใจแล้วจึงนำไปใช้กับโพสต์ทั้งหมด และประมวลผลอัตโนมัติได้ภายในประมาณ 30 นาที
  • ประเด็นสำคัญคือ สิ่งที่ทำให้ผมเชื่อถือได้ไม่ใช่เพราะ LLM “แปลงสำเร็จ” จริงๆ แต่เพราะผมสามารถตรวจสอบและรีวิวกระบวนการทั้งหมดได้ในรูปของ “โค้ด”

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

• อีกประเด็นสำคัญคือ วิธีนี้มีต้นทุน inference คงที่ ทำให้ภาระไม่ต่างกันมากนักไม่ว่าจำนวนไฟล์ทั้งหมดจะเป็น 15 ไฟล์หรือ 150 ไฟล์
  • ในขั้นวิเคราะห์สุดท้าย ระบบได้ข้ามความแตกต่างเล็กๆ น้อยๆ ไปโดยอัตโนมัติอยู่แล้ว จึงไม่เกิดภาระการตรวจสอบซ้ำมากนักแม้จะแปลงข้อมูลจำนวนมาก

MCP ทำแบบนั้นไม่ได้

• ใจความของคำอธิบายอันยาวนี้คือ พายป์ไลน์การแปลงและระบบอัตโนมัติทั้งหมดทำงานด้วย “โค้ด”
  • โครงสร้างแบบ อินพุตจากมนุษย์ → สร้างโค้ด → LLM ตรวจทาน → ปรับปรุงซ้ำ สามารถ นำไปใช้กับงานทั่วไปอื่นๆ ได้เหมือนกัน
• ตัวอย่างเช่น มี Playwright ซึ่งเป็นกรณีตัวแทนของแนวทาง MCP
  • มันเป็นเครื่องมืออัตโนมัติสำหรับควบคุมเบราว์เซอร์จากระยะไกล โดยต้องอ่านหน้า ทำความเข้าใจ และกดปุ่มต่างๆ ซึ่งเป็น การอนุมานที่เกิดซ้ำในทุกขั้นตอน
  • งานลักษณะนี้ในความเป็นจริงก็ยากที่จะทดแทนด้วย “แนวทางแบบโค้ด” ได้อย่างสมบูรณ์

• แต่ถ้า เรารู้โครงสร้างของหน้าอยู่แล้ว (เช่น การทดสอบแอปของตัวเองที่กำลังพัฒนา)
  • การให้ LLM สร้าง สคริปต์ Playwright ภาษา Python แล้วนำมันไปรัน จะทั้งเร็วกว่าและน่าเชื่อถือกว่ามาก
  • วิธีนี้ เมื่อสร้างสคริปต์ครั้งเดียวแล้ว ก็รันซ้ำได้เป็นสิบเป็นร้อยครั้ง โดยไม่ต้องมีการอนุมานเพิ่มเติม
  • ไม่ต้องตีความหน้าจอใหม่ทุกครั้งแบบเรียลไทม์หรือคอยหาตำแหน่งปุ่ม และสามารถรันเวิร์กโฟลว์อัตโนมัติทั้งชุดได้ในครั้งเดียว

• แนวทาง MCP นั้น ต้องมีการเรียกใช้เครื่องมือเชิงนามธรรมและการอนุมานในทุกขั้นตอน ทำให้การทำให้ LLM ทำงานได้ถูกต้องเสมอเป็นเรื่องยากมาก และดีบักก็ลำบาก
  • ตัวอย่างเช่น แม้อยากฝัง MCP client ลงใน shell script เพื่อเรียกใช้บริการระยะไกลอย่างมีประสิทธิภาพ แต่ในทางปฏิบัติกลับรู้สึกได้ว่าวิธีนี้ไม่มีประสิทธิภาพเอามากๆ และยังทำได้ยากด้วย

• สุดท้ายแล้ว ผมเป็นมนุษย์ ไม่ใช่ MCP client
  • โค้ดนั้นรันและดีบักได้ง่าย แต่การเรียก MCP นั้นเต็มไปด้วยความไม่แน่นอนทุกครั้ง และไม่น่าเชื่อถือ
  • ในทางปฏิบัติ ผมกลับเอาเครื่องมือเล็กๆ ที่ LLM สร้างขึ้นระหว่างการสร้างโค้ด (เช่น snippets ของ Claude Code) มาใช้เป็นเครื่องมือระยะยาวในกระบวนการพัฒนาของผมมากกว่า

แล้วข้อสรุปนี้จะพาไปทางไหน?

• พูดตรงๆ คือผมเองก็ไม่รู้ว่ากระแสนี้จะพาไปทางไหน แต่ ตอนนี้คือช่วงเวลาที่ดีมากในการคิดว่าจะปรับปรุงแนวทางสร้างโค้ดสำหรับ “agentic coding แบบมีเจตนา” ให้ดีขึ้นได้อย่างไร
• มันอาจฟังดูแปลก แต่ MCP ก็มีบางครั้งที่ทำงานได้ดีจริงๆ ทว่าโครงสร้างปัจจุบันพึ่งพา “การอนุมาน” มากเกินไป และให้ความรู้สึกเหมือนเป็น ทางตันที่ไม่เหมาะกับระบบอัตโนมัติขนาดใหญ่ที่ขยายได้

• เพราะฉะนั้น เราอาจต้องหาวิธี แยกและทำให้นามธรรมขึ้นอย่างชัดเจนยิ่งขึ้นว่า พื้นที่ไหนคือจุดแข็งของ MCP และบทบาทของแนวทางสร้างโค้ดอยู่ตรงไหน
  • เพื่อไปถึงจุดนั้น ก็จำเป็นต้องสร้าง sandbox (สภาพแวดล้อมการรันอย่างปลอดภัย) ที่ดีกว่าเดิม และลองเปลี่ยนการออกแบบ API เพื่อให้เอเจนต์สามารถทำการอนุมานแบบ fan out/fan in กับ API ได้อย่างอิสระ
  • ผมมองว่าโครงสร้างที่เหมาะสมคือ “อะไรที่ทำด้วยโค้ดได้ ก็ให้ทำด้วยโค้ดให้มากที่สุด” แล้วหลังจากรันจำนวนมากค่อยให้ LLM มาตัดสินและรีวิวผลลัพธ์ทั้งหมด

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

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

เอกสารอ้างอิง

• Agentic Coding Talk ของผม (วิดีโอ)
• How to fix your context (บทความ) โดย Drew Breunig
• MCPs are Boring (วิดีโอ) โดย Manuel Odendahl

[bluems]

เห็นด้วยนะ แต่ดูเหมือนว่ามันจะเป็นเรื่องการปรับทิศทางการออกแบบของตัวผู้สร้างมากกว่าปัญหาของ MCP เอง ถึงจะทำฟังก์ชันเหมือนกัน แต่ขึ้นอยู่กับว่าเป็น MCP แบบไหน มันจะสร้างโค้ดและสร้างคำสั่งภายในต่างกัน เพื่อลดงานที่ไม่จำเป็น ถ้าใช้ gh cli mcp หรือ terminal mcp แทน Github mcp ก็ยังใช้โทเค็นอยู่เหมือนกัน แต่ใช้น้อยกว่ามาก และได้ผลลัพธ์แบบเดียวกัน ตรงจุดนี้เหมือนจะถูกมองข้ามไปนะ

[GN⁺]

ความเห็นจาก Hacker News

• โดยรวมเห็นด้วยว่าทิศทางนี้น่าจะถูกต้อง การใช้งาน LLM ขนาดใหญ่ส่วนมากมักถูกใช้เพื่ออุดช่องว่างระหว่าง อินเทอร์เฟซที่แข็งแรงสองตัว แกนของความน่าเชื่อถือไม่ได้มาจากผลลัพธ์ของ LLM แต่จริง ๆ มาจากการที่ตัวอินเทอร์เฟซเองอนุญาตเฉพาะค่าตั้งบางแบบเท่านั้น
  เอาต์พุตของ LLM มักถูกบังคับแปลงให้เป็นค่าที่กำหนดได้แน่นอนมากขึ้น เช่น type หรือ primary key ของ DB คุณค่าของ LLM จะแตกต่างกันมากตามว่าโค้ดและทูลที่มีอยู่เดิมสามารถโมเดลข้อมูล ลอจิก และพฤติกรรมในโดเมนของเราได้ดีแค่ไหน
  ส่วนตัวช่วงนี้รู้สึกว่า LLM คล้าย 3D printer มาก ทั้งคู่ช่วยต่อชิ้นส่วนให้กันได้เร็วในงาน ทำต้นแบบอย่างรวดเร็ว แต่ถ้าต้องการความขยายได้และความแข็งแรง สุดท้าย วิศวกรหรือ LLM ก็ต้องแทนที่จุดเชื่อมชั่วคราวนั้นด้วยโครงรองรับแบบกำหนดได้แน่นอน เช่น โลหะ/โค้ด
  เหมือนกับความคาดหวังเกินจริงในอดีตต่อ 3D printer, LLM ก็ดูเหมือนจะมาแทนที่ความจริงทั้งหมดของการปฏิบัติการได้ แต่ความจริงคือมันมีประโยชน์จริงก็ต่อเมื่อมีการทำ digital modeling เดิมที่แข็งแรงเป็นฐานอยู่แล้ว

  • วงจร hype cycle ที่เกินจริงของโดรนหรือ VR ก็คล้ายกัน ทุกคนเคยบอกว่าจะส่งของด้วยโดรนกันหมด และใช้ชีวิตทั้งวันใน VR แต่กรณีใช้งานจริงกลับแคบกว่านั้นมาก
  • เป็นความเห็นที่น่าสนใจ แต่ดูจะมอง LLM แบบ อนุรักษ์นิยม เกินไปหน่อย ในความเป็นจริง LLM ถูกใช้งานในสเกลใหญ่แล้วในด้านอย่าง งานวิจัยเชิงลึกหรือการแปลภาษา และแพร่หลายแบบอเนกประสงค์มากกว่า 3D printer ไปแล้ว
  • เห็นด้วยกับคำว่า "ทิศทางโดยรวมถูกต้อง" ที่บริษัทผมเองก็ใช้คำว่า 'directionally accurate' บ่อยแม้จะไม่ตรงเป๊ะ หมายถึงว่าคร่าว ๆ แล้วไปในทิศที่ถูก

• มีอย่างหนึ่งที่ผมเพิ่งตระหนักเวลาใช้ทูล LLM คือถ้าคุณ ลดรูปปัญหาให้อยู่ในแบบที่ LLM ใช้ทูลแก้ได้ภายใน sandbox แบบวนซ้ำได้ คุณก็สามารถแก้ปัญหานั้นด้วย brute force ได้ สิ่งสำคัญคือการระบุปัญหาแบบนั้นให้เจอ แล้วกำหนด sandbox, ทูลที่จะใช้ และเกณฑ์ความสำเร็จให้เหมาะสม
  กระบวนการนี้ก็ยังต้องใช้ทักษะและประสบการณ์มาก แต่ก็เป็นงานในระดับที่สูงกว่าการลองผิดลองถูกด้วยมือทีละอย่างมาก
  ผมเพิ่งเข้าใจเรื่องนี้ตอนทำ 'การทดลอง Mandelbrot ด้วย assembly'
  (ลิงก์การทดลอง: https://simonwillison.net/2025/Jul/…)

  • การ "นิยามเกณฑ์ความสำเร็จ" สำคัญมากจริง ๆ โดยเฉพาะในตอนท้าย ถ้าไม่รู้ คณิตศาสตร์ fractal หรือ x86 assembly ก็จะตรวจสอบได้แค่ว่า "ภาพมันดูเหมือน Mandelbrot ไหม?" ซึ่งเป็นแค่ การตรวจด้วยสายตา
    ในอุดมคติควรมีเกณฑ์ประเมินแบบฟังก์ชันต่อเนื่อง หรืออย่างน้อยก็มีอินพุตที่หลากหลายพร้อมเอาต์พุตคาดหวังที่วัดเชิงปริมาณได้ จึงจะทำ automation ได้จริง
  • การทดลองนี้น่าสนใจมาก ผมเองก็กำลังคิดเรื่องใช้ LLM brute force แก้ปัญหาอยู่เหมือนกัน
    ตัวอย่างเช่น LLM มักไม่เก่งกับ generic ของ TypeScript แต่ถ้าปล่อยให้รัน TSC จริง มันก็สามารถทดสอบวนไปเรื่อย ๆ จนกว่าจะถูกได้ แม้ความดูแลรักษาโค้ดอาจแย่ลง แต่เชิงทฤษฎีก็เป็นโครงสร้างที่น่าทึ่งมาก
    แถม Cursor ยังมองเห็น TypeScript error ได้ ดังนั้นถ้าสร้างแค่ utility type tests, Cursor ก็อาจเขียนเทสต์เองและแก้ปัญหาด้วย brute force แบบวนซ้ำง่าย ๆ ได้
  • จากประสบการณ์ของผม การทำให้ LLM ใช้ทูลที่เหมาะกับงาน ยังเป็นความท้าทายใหญ่มาก เหมือนสอนเด็กซักผ้า จนหลายครั้งรู้สึกว่าเดี๋ยวทำเองยังง่ายกว่า
  • การให้ บริบทที่ถูกต้อง กับ LLM สำคัญมาก ตัวอย่างเช่น ถ้าใช้ "เครื่องมือทางความคิด" ที่นิยามไว้ล่วงหน้าเพื่อเพิ่มบริบทให้รวยขึ้น ประสิทธิภาพก็ดีขึ้นอย่างชัดเจน
    มีรีโปที่น่าดู: https://github.com/davidkimai/Context-Engineering/…
    ผมยังดูไม่ครบทั้งหมด แต่ค่อนข้างน่าประทับใจ
  • ผมสงสัยว่าวิธีวนลูปทูลใน sandbox แบบนี้ จำเป็นต้องใช้ Cloud API ที่กินโทเคนเยอะหรือเปล่า
    ทำได้ด้วยโมเดลโลคัลไหม หรือใช้แค่ subscription อย่าง Claude Code Pro ก็พอ
    การทดลอง Mandelbrot สนุกดี แต่ระดับความยากก็ยังต่างจาก codebase เชิงพาณิชย์ที่ซับซ้อนจริงอยู่บ้าง

• ผมไม่คิดว่านี่เป็นปัญหาของ MCP เอง ที่ระดับ AI ตอนนี้ โครงสร้างที่มีมนุษย์คั่นกลาง ยังดีกว่ามาก
  LLM เก่งกับบางงาน แต่ก็มักติดอยู่ใน local minima ได้ ดังนั้นถ้าวนลูปผ่านเว็บอินเทอร์เฟซแบบ "ช่วยเขียนโปรแกรม → ตรวจสอบและให้ hint → ทดสอบ" คุณภาพจะดีขึ้นชัดเจน
  คุณสามารถเปลี่ยนโค้ดเละ ๆ 10,000 บรรทัดให้กลายเป็นโค้ดชัดเจน 400 บรรทัดได้ ณ ตอนนี้นี่แหละคือความจริง
  แน่นอนว่าหลายบริษัทหรือหลายคนอาจพยายาม "แทนที่โปรแกรมเมอร์ด้วย LLM" แต่ในโลกจริงตอนนี้ยังทำไม่ได้
  ผลลัพธ์ที่แท้จริงคือการ เพิ่มความเร็วการทำงานของโปรแกรมเมอร์ได้หลายเท่า หรือทำให้มือใหม่ใช้ LLM เพื่อทำงานที่มีประสิทธิผลได้รวดเร็วขึ้น แต่ "agentic coding" ยังทำงานได้ไม่ดี
  ในสถานการณ์ปัจจุบัน วิธีที่ถูกต้องคือใช้ LLM เป็น เพื่อนร่วมงานหรือผู้ช่วย ความจริงตอนนี้คือมันยังไม่ใช่ "AI agent" ที่มี feedback อัตโนมัติด้วยตัวเอง

  • ผมเองเป็น นักพัฒนาผลิตภัณฑ์ ที่ทำทุกอย่างเองคนเดียว และใช้ claude-code เป็นเครื่องมือ หวังว่าสักวัน Claude จะมาแทนงานเขียนโค้ดทั้งหมดได้ แต่ตอนนี้ยังไม่ถึงจุดนั้น
    ผมทำงานด้วยภาษาที่ type-safe, เป็นแบบ functional และเป็นภาษา compiled ดังนั้นก็ยังต้องอ่านผลลัพธ์เองทุกครั้ง ถ้าเป็นภาษาที่เข้มน้อยกว่านี้คงยิ่งกังวล
    ถึงอย่างนั้นผลด้าน การประหยัดเวลา ก็ใหญ่มาก โดยเฉพาะการที่มันช่วยแตกงานออกเป็นส่วน ๆ ทำให้รับมือเป้าหมายใหญ่ได้ง่ายขึ้น

• ผมลองทำงานจริงด้วย GitHub MCP แล้วพบว่าถ้าทำงานเดียวกันด้วย gh CLI มันใช้บริบทได้มีประสิทธิภาพกว่ามากและเร็วกว่าเยอะ
  ผมมีไฟล์ CLAUDE.md อยู่ในโฟลเดอร์ "devops" (รวมคำสั่ง bash ส่วนกลาง)
  พอทำงานใหม่เสร็จ ผมก็ให้ Claude เพิ่มตัวอย่างลงไป แล้วครั้งถัดไปที่มีคำถามคล้ายกัน Claude ก็แก้ได้ในครั้งเดียว
  เนื้อหาเริ่มต้นของ CLAUDE.md ที่ผมแชร์:

  • ไฟล์นี้ให้คำแนะนำแก่ Claude Code เวลาเขียนโค้ด
  • โดยเฉพาะการบันทึก คำสั่ง DevOps ที่เกี่ยวกับ GCP (Cloud Composer, Logging, Kubernetes, Cloud Run)
  • ตัวอย่างคำสั่งหลัก: ดูรายละเอียด environment, จัดการ DAG, ตรวจ Airflow logs ฯลฯ
    (สรุปคำสั่งเฉพาะ)
  • บางทีก็รู้สึกสับสนเหมือนกัน มีไฟล์รวมคำสั่งที่ต้องใช้อยู่แล้ว แต่ต้องมานั่งรอให้ AI เป็นคนรันให้ มันดูไม่มีประสิทธิภาพอยู่บ้าง
  • อ้างอิงเพิ่มเติม ถ้าเอา section คำสั่งเหล่านั้นไปทำเป็น stdio MCP server แบบง่าย ๆ แล้วต่อเข้ากับ Claude Code ก็จะทำให้แต่ละงานกลายเป็นทูลได้ และยังนิยาม input schema ของอาร์กิวเมนต์ได้ด้วย ตอนนี้ก็มีโอเพนซอร์ส MCPServer ที่รองรับลักษณะนี้อยู่แล้ว (ตัวอย่าง: https://github.com/inercia/MCPShell)
  • ผมเองก็ใช้ไฟล์รวมคำสั่งคล้ายกันโดยเขียนตรง ๆ ใน Emacs org-mode พับ/ขยายได้ง่ายเลยมีประสิทธิภาพดี และยังรัน code snippet (shell, elisp ฯลฯ) ได้ทันที
  • ผมสงสัยว่าคุณให้สิทธิ์ LLM เรียก privileged API กับ production/test environment ไปตรง ๆ เลยหรือเปล่า หรือว่าแค่รับคำสั่งตัวอย่างที่ตรวจ sanity check ได้เท่านั้น อยากรู้ use case ที่ใช้งานจริงมากกว่านี้
  • ผมก็เคยทำแนวคล้ายกัน แต่พอ claude.md ใหญ่ขึ้นเรื่อย ๆ ก็เริ่มใช้งานลำบาก เลยแก้ด้วยการ ทำ custom prompt ให้กลายเป็นแอป ซึ่งช่วยได้บ้าง แต่แอปมีความเป็น deterministic เลยรับมือกับสถานการณ์ที่ไม่รู้ล่วงหน้าได้ยาก ตรงข้ามกับ CC ที่แม้จะช้าแต่ก็ยังจัดการสถานการณ์ไม่คาดคิดได้
    สุดท้ายเลยกลายเป็น ซอฟต์แวร์ self-healing ที่พอเกิดปัญหาก็สั่งเพิ่มให้แอปทดสอบและแก้ไขตัวเอง

• จากการใช้งาน MCP ทั้งหมดที่ผมเห็นมา สิ่งที่น่าประทับใจที่สุดคือ clojure-mcp ของ Bruce Hauman
  มันให้ LLM เข้าถึง (a) bash, (b) persistent Clojure REPL, และ (c) เครื่องมือแก้ไขแบบเชิงโครงสร้าง
  ทำให้ตอนแก้ไขโค้ด Clojure มันทำงานมีประสิทธิภาพกว่าวิธีที่อิง pure text diff มาก
  ถ้ามี test suite ที่ดีพอ การแก้ไฟล์, reload, และรันทดสอบซ้ำจะวนได้ใกล้เคียงการทำงานของคนมากจนผมทึ่ง

  • ผมเองก็คิดว่า clojure-mcp คือ การใช้งาน MCP ที่เจ๋งที่สุด เท่าที่เคยเห็น
    มันรองรับความสามารถหลักอย่าง debug โค้ด, ประเมิน expression ทีละตัว, จัดทำเอกสารประเภทค่าที่ฟังก์ชันส่งกลับ ฯลฯ
    ผมยิ่งรู้สึกว่าภาษาที่มี REPL ทรงพลัง เหนือกว่าในความสามารถลักษณะนี้ และพอเห็นศักยภาพของ clojure-mcp ก็ทำให้มุมมองที่ผมมีต่อ AI เปลี่ยนไปมาก
  • สำหรับคนที่สนใจ นี่คือลิงก์รีโปทางการ: https://github.com/bhauman/clojure-mcp

• ตัวอย่าง GitHub CLI ยังไม่ได้แสดงจุดแข็งของ MCP ทั้งหมด
  ทูลอย่าง gh CLI ที่เข้าถึงเอกสารได้ดีอยู่แล้ว แน่นอนว่า LLM จะสร้างโค้ดมาใช้งานได้ง่ายกว่า
  แต่ ข้อได้เปรียบที่แท้จริงของ MCP จะชัดกับทูลภายในองค์กร หรือ API เฉพาะทาง ที่แทบไม่มีเอกสารออนไลน์
  จะเลือกเอาเอกสารทั้งหมดใส่เป็นบริบทก็ได้ แต่ในกรณีแบบนี้ MCP กลับมีประสิทธิภาพกว่า
  ถ้าใช้ MCP tool ที่ออกแบบมาดีร่วมกับอินพุตที่ถูกต้อง ภาระของ LLM ในการเข้าใจ API, authentication, และการจัดการ edge cases จะลดลงมาก
  สำหรับ GitHub อาจไม่จำเป็นต้องมี MCP แต่ในสภาพแวดล้อมอย่าง API ภายในหรือ API ที่ไม่สมบูรณ์ ทูล MCP ที่เตรียมไว้ล่วงหน้าจะทรงพลังกว่า

  • ท้ายที่สุดแล้ว MCP ก็เป็นแนวทางแบบ ฉีดเอกสารเข้าไปในบริบทอินพุตของ LLM นั่นเอง ในสภาพแวดล้อมที่ LLM คุ้นเคยดีอยู่แล้ว (Python, JavaScript, bash ฯลฯ) การใช้วิธีที่มันรู้อยู่แล้วจะดีกว่าการเรียก MCP tool และนิยามทูลกลับยิ่งกินบริบท
    ตัวอย่างเช่นใน sonnet4 พอมีทูลเกิน 15 ตัวก็เริ่มชนข้อจำกัดแล้ว ใช้แค่ official playwright MCP ก็เปลืองบริบทของทูลไปมากแล้ว
  • แม้ MCP server จะช่วยทำให้เรื่องอย่าง authentication ง่ายขึ้น แต่ก็มีคนโต้แย้งว่าจริง ๆ แล้วน่าจะออกแบบ internal API ให้เป็นแบบนั้นตั้งแต่แรกได้ไม่ใช่หรือ
    สุดท้ายข้อดีเพียงอย่างเดียวของ MCP อาจเป็นแค่การยืนยันซ้ำว่าเวลา API ดูยากมากนั้น ความจริงคือ "มันซับซ้อนเกินไปตั้งแต่ต้น"

• เรื่องตัวอย่าง Playwright
  สัปดาห์นี้ผมเองก็เพิ่งสร้าง agent โดยใช้ Playwright MCP server แล้วพบว่ามันช้า ใช้โทเคนไม่มีประสิทธิภาพ และความน่าเชื่อถือต่ำ เลยย้อนกลับไปใช้ เรียก Playwright ตรง ๆ แทน
  MCP server เหมาะสำหรับทดสอบว่าทำอะไรได้บ้าง แต่ในงานจริง การเรียก API มีประสิทธิภาพและเสถียรกว่า
  แชร์ตัวอย่างและเดโมของ personal LinkedIn agent ที่ผมทำไว้:

  • โปรเจกต์: https://github.com/pamelafox/personal-linkedin-agent
  • เดโม: https://www.youtube.com/live/ue8D7Hi4nGs
  • สำหรับผม implementation ของ Playwright MCP ก็เป็น วิธีแก้ปัญหาที่เกินจำเป็น เหมือนกัน ผมมองว่ามันคล้าย implementation อ้างอิงที่คัดเอาแค่บางส่วนของ Playwright API มาอย่างจำกัดมากกว่า
    LinkedIn ขึ้นชื่อว่าเป็น แพลตฟอร์มที่ทำ automation ยากมาก เลยอยากรู้ว่าตอนทำ personal LinkedIn agent คุณเจอความยากหรือข้อจำกัดอะไรบ้างไหม

• จริง ๆ ผมรู้สึกว่าแค่มี เทอร์มินัล ก็พอแล้ว
  ผมใช้ MCP ทุกวันมาหลายเดือน แต่ตอนนี้ใช้แค่ iTerm2-based MCP server (เทอร์มินัล) ตัวเดียว
  แม้จะมี OpenAPI spec ให้ใช้เมื่อจำเป็น แต่ในทางปฏิบัติ เกือบทุกอย่างทำได้ด้วย shell command กับ curl

  • ผมเองก็เพิ่งตระหนักเป็นครั้งแรกว่า ขอบเขตที่ทำได้ด้วย bash ไปได้ไกลแค่ไหน หลังจากเห็น LLM ใช้ทูลที่มีอยู่ใน bash shell

• คำวิจารณ์เรื่อง "ต้องใช้บริบทมากเกินไป" จริง ๆ จัดการได้ถ้าตั้งค่า ค่าเริ่มต้นของ initial prompt ให้ดี
  ทูลหลัก ๆ รวมถึง Claude Code และ Gemini CLI ต่างก็รองรับ
  แม้การส่งรายชื่อทูลทั้งหมดให้ LLM แล้วปล่อยให้มันคัดเองจะไม่ใช่วิธีที่ดีที่สุด
  แต่ LLM รุ่นใหม่ก็ดีขึ้นเรื่อย ๆ และโดยส่วนตัวผมแทบไม่เคยเจอปัญหาใหญ่กับการ เลือกฟังก์ชัน MCP ที่เหมาะสม
  ส่วนเรื่องต้นทุน ความเร็ว และความน่าเชื่อถือก็มีประเด็นว่า

  • ต้นทุน: ช่วงนี้ราคาถูกลงเรื่อย ๆ จริง ๆ แล้วคุ้มอย่างน่าทึ่ง
  • ความเร็ว: สั่งหลายงานพร้อมกันได้ เลยไม่ได้ไม่มีประสิทธิภาพนัก
    คุณไม่จำเป็นต้องใช้เวลาตรงหน้าจอกับบทสนทนาด้วยตัวเอง
  • ความน่าเชื่อถือ: ขึ้นอยู่กับคุณภาพของ prompt มาก
    ตัวอย่างล่าสุดคือให้ LLM จัดการ external tools จำนวนมากอย่าง Notion, Linear, git, GitHub PR/CI logs โดยอัตโนมัติ
    ส่วนผมทำแค่รีวิว PR ครั้งเดียวเท่านั้น
    ค่าใช้จ่ายยังต่ำกว่า 1 ดอลลาร์ด้วย
  • ยิ่งมี MCP tool มากเท่าไร บริบทที่ initial prompt ต้องใช้ก็ยิ่งมากขึ้น
    กลับกันยิ่งเพิ่มทูล ก็ยิ่งต้องมีข้อมูลตั้งต้นมากขึ้น และอาจกลายเป็นข้อจำกัดรุนแรงได้
  • เรื่องต้นทุนอาจไม่ได้ถูกลงจริง แต่เป็นแค่ยัง ถูกซ่อนต้นทุนไว้ และโครงสร้างโปรโมชันแบบฟรีหรือราคาต่ำก็คงอยู่ได้ไม่นาน
    เช่น Cursor เองก็เริ่มมีแพ็กเกจเดือนละ $200 แล้ว และคุณภาพบริการของแพ็กเกจราคาถูกก็แย่ลง
    พอโปรโมชันฟรีหมด ก็น่าจะกลับไปสู่ระดับต้นทุนเดิม

• ผมทำงานด้วย Julia และได้ประโยชน์จากสภาพแวดล้อมแบบเซสชันรันยาว
  เพราะฟังก์ชันจะถูกคอมไพล์ตอนรันครั้งแรก ผมเลย สร้าง MCP ให้ Claude Code ส่งโค้ดเข้าไปยัง persistent Julia kernel (Jupyter)
  ทำให้รันโค้ดทดสอบได้เร็วขึ้นมาก และ CC ก็ใช้ ฟังก์ชันที่มีอยู่เดิมใน codebase ได้ดีขึ้นแทนการเขียน bespoke bash
  ปริมาณการใช้โทเคนตาม CCUsage ก็ลดลงเกือบ 50%
  มันอาจไม่จำเป็นต้องเป็น MCP ก็ได้ แต่ประเด็นคือการต่อ 'ความสามารถเฉพาะ' เข้ากับ codebase นั้นง่ายกว่าการเขียน custom code ให้ Claude ทีละอย่างมาก

  • ผมสงสัยว่าการที่ "Claude เลือกเรียกใช้ฟังก์ชันในโค้ดโดยตรงแทน bespoke bash" นั้น เป็นเพราะ สามารถส่งโค้ดเข้า kernel ได้โดยตรง เพียงอย่างเดียวหรือเปล่า