หลังจากที่ตอนที่แล้ว ผมได้เล่าถึงบทเรียนเจ็บแสบบนหน้าจอ LINE จนต้องรื้อวิสัยทัศน์ของผลิตภัณฑ์จาก “Thai Health Buddy” สู่ “SabayJai Buddy” ผู้ช่วยที่เข้าใจบริบทชีวิตมนุษย์ ในตอนนี้ ผมจะพาเลี้ยวกลับมาดูสิ่งที่เกิดขึ้น “หลังบ้าน” ในช่วงเวลาเดียวกัน
ในช่วงเดียวกับที่หน้าจอ LINE ยังมีจุดติดขัด ผมก็เริ่มลองวิธีทำงานกับ AI หลายแบบ ทั้งการใช้ Agent หลายตัวและการสั่งงานผ่านแชท
ตอนนั้นผมลองแนวทางที่เห็นจากตัวอย่างใน YouTube ทั้ง Multi-Agent การวาดผัง Agent Team และการสั่งงานผ่านหน้าต่างแชท เมื่อเอามาลองกับงานของตัวเอง ผมพบว่าความซับซ้อนเพิ่มขึ้น แต่ยังไม่ได้ช่วยให้ผลลัพธ์ดีขึ้นอย่างที่หวัง
ผมจึงหยุดวิ่งตามคนอื่น แล้วเริ่มต้นการทดลองใช้ AI ในแบบของตัวเอง... โดยการเอา “ประสบการณ์การทำงานของผมทั้งชีวิต” มาปรับใช้ให้เข้ากับ AI ความคิดของผม... มันง่ายเท่านี้เองครับ
1. ทดลอง Multi-Agent: จากแผนบนกระดาษสู่ข้อจำกัดในงานจริง
ย้อนกลับไปช่วงปลายของ Walking Skeleton ในตอนที่ 4 พอผมเห็นระบบเล็ก ๆ วิ่งต่อกันได้ครบ ความมั่นใจของผมก็พุ่งทะลุเพดาน
ช่วงนั้นผมเห็นตัวอย่างการใช้ “Multi-Agent” อยู่บ่อย ทั้งการแบ่ง AI หลายตัวให้ทำหน้าที่เหมือนทีม มีตัววางแผน ตัววิเคราะห์ และตัวตรวจสอบ แนวทางนี้ดูน่าสนใจ ผมจึงลองนำมาปรับใช้กับงานของตัวเอง
ด้วยความฮึกเหิม ผมก็เดินตามรอยนั้นทันที เปิดเอกสารสถาปัตยกรรมไฟล์ agent-team-model.md แล้วนั่งวาดผังตาม YouTube อย่างเมามัน:
- AI Orchestration Agent: ทำหน้าที่เป็นผู้จัดการใหญ่ คอยคุมทิศทางและสั่งการ
- QA & Validation Agent: ทำหน้าที่เป็นผู้ตรวจสอบคุณภาพ คอยตรวจสัญญาและความถูกต้องของข้อมูล
- แยก Service ที่ใช้คิด ออกจาก Service ที่ใช้ตอบ และแยก Service คุยกับ Strapi ออกไปอีกชั้น
บนหน้ากระดาษ ทุกอย่างดูเป็นระบบ แต่เมื่อนำมาลองกับงานจริง ความซับซ้อนกลับเพิ่มขึ้นโดยที่ผลลัพธ์ยังไม่ดีขึ้นตามไปด้วย
- บริบทและค่าใช้จ่ายเพิ่มขึ้น: เมื่อให้ Agent ส่งงานต่อกัน ข้อมูลสะสมในแต่ละรอบมากขึ้น ทำให้ใช้ Token และเวลามากขึ้น
- ขอบเขตงานไม่ชัด: ในการทดลองครั้งนั้น การส่งต่องานหลายทอดทำให้ต้องคอยตรวจว่าผลลัพธ์ยังตรงกับโจทย์เดิมหรือไม่
- ประสบการณ์ผู้ใช้ยังไม่ดีขึ้น: แม้จะเพิ่มขั้นตอนของ Agent แล้ว คำตอบที่ผู้ใช้เห็นก็ยังมีปัญหาเดิม
การทดลองครั้งนั้นทำให้ผมเห็นว่า วิธีที่ดูดีในตัวอย่างอาจไม่เหมาะกับโจทย์และข้อจำกัดของงานทุกแบบ
2. กับดักการสั่งงานในแชทลอย ๆ: สลับ AI กี่ตัว ก็ยังเจอ "ตอบเสร็จแบบมั่ว ๆ" เหมือนเดิม
หลังจากที่ช่วงแรก (ตั้งแต่ตอนที่ 3) ผมเริ่มคุ้นเคยกับการสลับเครื่องมือช่วยเขียนโค้ดไปมาระหว่าง Codex, Gemini, และ Cline + DeepSeek เพื่อรับมือกับเรื่อง Limit และคุมต้นทุนได้แล้ว แต่พอมาถึงขั้นตอนนี้ สิ่งที่กลายเป็นบทเรียนราคาแพงที่สุด ไม่ใช่เรื่องการเลือกใช้ตัวไหน หรือการสลับไปใช้อีกตัว... แต่คือ “กับดักของการสั่งงานผ่านหน้าต่างแชทลอย ๆ” ครับ!
เวลาเราสั่ง AI ผ่านหน้าต่างแชทแบบไม่มีเอกสารหรือขอบเขตกำกับ โค้ดรอบแรก (First Code) ที่ AI เขียนขึ้นมา มันถูกสร้างขึ้นมาเพียงเพื่อให้ “ใช้งานได้ตามสั่ง ณ เวลานั้น” อะไรที่สั่งให้ทำ มันก็จับยัดลงไปเรื่อย ๆ โดยไม่มีใครคุมความสัมพันธ์ระหว่างไฟล์
และพอเราเริ่มสั่งให้แก้หรือเพิ่มฟังก์ชันผ่านหน้าต่างแชท ความปวดหัวก็เริ่มต้นขึ้น:
- สั่งให้แก้ตรงนี้ มันกลับไปทำพังตรงโน้น
- พอสั่งให้แก้ตรงโน้น มันก็วนกลับมาลบฟังก์ชันเดิมทิ้ง
- ต่อให้เรามีเครื่องมือ AI ครบมือ หรือสลับค่ายจากตัวหนึ่งไปอีกตัวหนึ่ง แต่ถ้าเรายังคุยผ่านแชทลอย ๆ เหมือนเดิม AI ตัวใหม่ก็พาออกทะเลและเละเทะไม่ต่างกัน
ตอนนั้นมันเหมือนเรากำลังติดอยู่ในหล่มโคลนดูดตอนเช้ามืด ยิ่งพยายามดิ้นสั่งให้ AI แก้ในแชท โค้ดยิ่งพังลึกขึ้นเรื่อย ๆ AI ในหน้าต่างแชทก็ยังคงตอบกลับมาด้วยความมั่นใจอย่างไร้เดียงสาเหมือน เด็ก Junior ที่ไฟแรง เขียนเร็ว แต่ขาดระเบียบ แล้วก็เคลมหน้าตาเฉยว่า: “ผมแก้ไขโค้ดให้เรียบร้อยแล้วครับ คอมไพล์ผ่าน 100% แน่นอน!” แต่พอผมรันจริงตอนหกโมงเช้า หน้าจอกลับมีแต่ความว่างเปล่าและ Error แดงเถือก
วินาทีนั้นเองที่ทำให้ผมตาสว่าง: ปัญหาไม่ได้อยู่ที่ตัว AI หรือการสลับเครื่องมือ... แต่อยู่ที่ 'วิธีสั่งงานและวินัย' ของเราต่างหาก!
3. สั่งปรับกระบวนทัพใหม่: รีดไขมัน 3,700 บรรทัดในเวลา 06:53 น.
เช้ามืดวันที่ 5 มิถุนายน 2026 แสงอาทิตย์เริ่มส่องลอดหน้าต่างเข้ามา ผมนั่งมองโค้ดที่รกรุงรัง เอกสารสถาปัตยกรรมที่เพ้อฝัน และระบบที่คุยไม่รู้เรื่องอยู่ท่ามกลางความเงียบ แล้วบอกตัวเองตรง ๆ ว่า:
เมื่อเอาแนวทางจากตัวอย่างมาลองกับงานของตัวเอง ผมพบว่าความซับซ้อนเพิ่มขึ้น แต่ผลลัพธ์ยังไม่ดีขึ้นอย่างที่หวัง
ขืนปล่อยให้เดินหน้าต่อในสภาพนี้ โปรเจกต์นี้ไม่มีทางไปรอดแน่นอน ผมไม่ได้นั่งหมดอาลัยตายอยากแล้วมากดปุ่ม Delete ทีละไฟล์หรอกครับ แต่ผมตั้งหลักเป็นแม่ทัพ แล้ว “สั่งให้ AI จัดการปรับกระบวนทัพในการทำงานใหม่ทั้งหมด!”
ผมสั่งให้ AI กวาดและรื้อเอกสารสเปกทั้งระบบ:
- อะไรที่เป็นท่ายากเพ้อฝัน ซับซ้อนเกินจำเป็น และยังไม่ถึงเวลาทำ... สั่งตัดทิ้งให้หมด
- แล้วเขียนโครงสร้างใหม่ที่กระชับ รัดกุม และสอดคล้องกับวิสัยทัศน์ใหม่ของ SabayJai Buddy ขึ้นมาแทน
ในบันทึกเช้ามืดเวลา 06:53 น. ผลลัพธ์ของการสั่งปรับทัพครั้งนั้น คือการ รีดไขมันทิ้งไปกว่า 3,700 บรรทัด พร้อมกับสถาปนาโครงสร้างใหม่ที่คลีนขึ้นมากว่า 1,300 บรรทัดในคราวเดียว
นี่ไม่ใช่การยอมแพ้ แต่คือการ “ดึงหางเสือกลับมา” เพื่อตั้งหลักใหม่ในแบบของตัวเอง
4. เอาประสบการณ์ทำงานจริง มาปรับใช้กับ AI: เมื่อผมมอง AI เหมือน "น้องในทีมที่ทำเร็ว... แต่มั่วบ่อย"
หลังจากวันนั้น ผมบอกตัวเองว่า:
“ต่อไปนี้ ผมจะทดลองการใช้ AI ในแบบของผมเองแค่นั้น... โดยการเอาประสบการณ์การทำงานของผม มาปรับใช้ให้เข้ากับ AI”
ความคิดของผม... มันง่ายเท่านี้เองครับ
ในวันนั้น ผมไม่ได้กำลังคิดจะสร้างทฤษฎีเท่ ๆ หรือทำตัวเป็นผู้เชี่ยวชาญ AI อะไรเลยครับ ในหัวของผม ณ เวลานั้น มีเป้าหมายที่เรียบง่ายอยู่เพียงข้อเดียวคือ: “ทำยังไงก็ได้... ไม่ให้ AI มันตอบว่าเสร็จแบบมั่ว ๆ!”
เพราะที่ผ่านมา สั่งอะไรไป หน้าต่างแชท AI ก็จะตอบกลับมาด้วยความมั่นใจเสมอว่า: “เสร็จเรียบร้อยแล้วครับ โค้ดสมบูรณ์แบบ!” แต่พอเอามารันจริงบนเครื่อง มันกลับพังเละเทะและทำงานไม่ได้จริง
แล้วผมแก้ปัญหานี้อย่างไร? คำตอบคือ ผมดึงเอา ประสบการณ์การบริหารทีมซอฟต์แวร์ที่ทำมาทั้งชีวิต บวกกับ วินัยของกระบวนการมาตรฐานซอฟต์แวร์ (อย่าง ISO 29110 ที่ผมเพิ่งได้เรียนรู้มาเมื่อช่วงตุลาคม 2025) มาปรับใช้กับ AI ทันที!
ในมุมมองของผมตอนนั้น ผมมอง AI เป็นหนึ่งใน “ทีมงาน” ของเรา มันเหมือน “น้องจูเนียร์ในทีมที่ไฟแรง ทำงานได้เร็วปานสายฟ้าแลบ... แต่มั่วบ่อยมาก!” ถ้านึกจะสั่งงานลอย ๆ ในแชทแบบไม่มีกรอบ น้องก็จะคิดเองเออเอง ทำมาไม่ตรงสเปก หรือแก้ฟังก์ชันนี้แล้วไปทำอีกฟังก์ชันพัง
คนคุมทีมที่ดีรู้ดีว่า การจะทำงานร่วมกับน้องที่ทำเร็วแต่มั่วบ่อยให้ได้งานที่มีคุณภาพ เราต้องวาง “วินัยและกระบวนการทำงานที่รัดกุม”:
ก. ต้องออก Scope ให้น้องทำงานอย่างชัดเจน (Workboard & Boundary)
งานต้องถูกซอยเป็นก้อนเล็ก ๆ ระบุชัดเจนว่าอะไรคือ In Scope (ที่ต้องทำตอนนี้) และอะไรคือ Deferred (ที่ห้ามแตะเด็ดขาด) เพื่อไม่ให้น้องหลงประเด็นหรือพาโค้ดออกทะเล
ข. จาก API Payload & Response สู่คำว่า "Contract": ไหลไปตามศัพท์ AI เพื่อให้งาน Smooth
จริง ๆ แล้ว คำว่า "Contract" ไม่ใช่คำที่ผมเคยใช้เลยครับ ในโลกคนทำงานสาย .NET ของผม สิ่งนี้คือเรื่องเบสิกที่สุด: “การล็อก API Payload ขาเข้า และ Response ขาออกให้เด็ดขาดตาม Standard .NET”
ตอนแรกผมพยายามทำความเข้าใจกับคำว่า Contract และพยายามจะดึงให้ AI กลับมาคุยภาษาเดียวกับผมด้วยคำว่า Payload กับ Response แต่ทำงานร่วมกันไปสักพัก ผมก็เรียนรู้เคล็ดลับสำคัญข้อหนึ่งว่า: “การยอมไหลไปตามศัพท์ที่ AI คุ้นเคย... ทำให้การทำงานร่วมกันราบรื่น (Smooth) กว่าการไปฝืนมันเยอะมาก!”
ในเมื่อ AI ถูกเทรนมากับคำว่า "Contract" และมันเข้าใจมิติของความหมายนี้ได้ลึกซึ้งที่สุด พอเราปรับตัวมาใช้คำว่า Contract ตามมัน การสั่งงานก็แม่นยำขึ้น การล็อกสเปกก็คมขึ้น โค้ดที่มันเขียนออกมาก็แทบไม่หลุดกรอบ
ก่อนจะปล่อยให้น้อง AI เริ่มลงมือพัฒนาโค้ดแม้แต่บรรทัดเดียว เราจึงต้องตกลง "สัญญา" ให้เสร็จก่อน (ซึ่งตอนนั้นในเอกสาร AI มันตั้งชื่อไฟล์ว่า ai-extraction-json-contract.md) ขาเข้าหน้าตาเป็นอย่างไร ขาออก JSON ต้องมีฟิลด์อะไร ล็อกให้เด็ดขาด เราไม่ปล่อยให้ AI คิดฟิลด์เองเออเอง โค้ดมีหน้าที่เดียวคือวิ่งตามสัญญานี้
ค. นิยามความเสร็จที่พิสูจน์ได้จริง (Done Means)
งานจะเสร็จได้ ไม่ใช่เพราะน้องเดินมาบอกว่า “เสร็จแล้วครับพี่” แต่คำว่า Done Means ต้องพิสูจน์ด้วยผลการทดสอบจริงบนเครื่องเท่านั้น... จะไม่มีการปล่อยให้ตอบว่าเสร็จแบบมั่ว ๆ อีกต่อไป!
ทำไมเราถึงลืมหลักการบริหารงานเหล่านี้ไป เพียงเพราะทีมงานตรงหน้าเราเปลี่ยนร่างเป็น AI?
5. Multi-Agent ในโลกความจริง
และตรงนี้นี่เอง ที่ทำให้ผมเข้าใจความหมายของ Multi-Agent ในโลกความจริง
Multi-Agent ในแบบของผม ไม่ใช่การปล่อยให้บอท AI หลายตัวคุยกันเองในระบบแบบที่ YouTube ชอบโชว์กัน แต่ Multi-Agent ในแบบของผม คือ:
“ตัวเรา (มนุษย์) ที่เป็นผู้กำกับ และใช้ AI Agent สลับกันทำงานจริง เพราะติด Limit!”
ในชีวิตจริง เมื่อเราต้องสลับจากโมเดลค่ายหนึ่งไปใช้อีกค่ายหนึ่งกลางคัน:
- ถ้าเราไม่มีเอกสารกำกับ การสลับ AI คือหายนะ โค้ดจะเละเทะและคุยไม่รู้เรื่อง
- แต่ถ้าเรามีสเปก API Payload และ Response ล็อกหน้าตาข้อมูลและพฤติกรรมไว้อย่างชัดเจน ต่อให้โมเดลตัวเดิมติด Limit เราก็แค่โยนเอกสารสเปกนี้ให้โมเดลตัวใหม่ทำต่อได้ทันที โดยที่หัวใจของงานไม่หลุดเลยแม้แต่นิดเดียว!
ตอนนั้นผมไม่ได้คิดจะประดิษฐ์ Framework เท่ ๆ อะไรเลยครับ แค่กำลังดิ้นรนหาทางเอาตัวรอดไม่ให้ระบบพังคามือจากการทำงานจริงเท่านั้นเอง
6. เมื่อการซ้อมจบลง... ถึงเวลาก้าวสู่โลกจริง
หลังจากเช้ามืดวันที่ 5 มิถุนายน ที่เราสั่งจัดกระบวนทัพใหม่สำเร็จก่อนเริ่มเวลาทำงานประจำ พอเช้ามืดวันที่ 6 มิถุนายน ผมก็ตื่นตั้งแต่ตีสี่ครึ่งมาลุยต่อ ด้วยความที่เป็นวันทำงาน เวลาที่จะแตะต้องโปรเจกต์ส่วนตัวนี้ได้จึงมีแค่ช่วงเช้ามืดก่อนเริ่มงานและช่วงค่ำหลังเลิกงานเท่านั้น
จนกระทั่งในเวลาหนึ่งทุ่มเศษของวันที่ 6 มิถุนายน ผมกับ AI ก็ช่วยกันเก็บงาน Hardening จนกระทั่งผลการทดสอบทุกอย่างบนเครื่องผ่านฉลุยตามนิยาม Done Means เอกสารนิ่ง สเปกคลีน ข้อมูล Payload & Response ล็อกแน่น...
แต่ความสำเร็จบนหน้าจอ Localhost ในตอนนั้น มันเป็นเพียงแค่ “การซ้อมในห้องทดลอง” เพราะคำถามที่แท้จริงที่รออยู่ข้างหน้าไม่ใช่ว่า “บอทตัวนี้รันบนเครื่องเราผ่านไหม?” แต่คือ: “ถ้าเอาขึ้นไปรันบนเซิร์ฟเวอร์จริง ผ่านอินเทอร์เน็ตจริง และมีคนใช้งานจริง... ระบบนี้จะรอดไหม?”
การทดลองเงียบ ๆ ในห้องนอนกำลังจะจบลง... และการเคาท์ดาวน์สู่สมรภูมิที่แท้จริงกำลังเริ่มต้นขึ้น: “First Go-Live” ในเช้ามืดวันที่ 8 มิถุนายน... วันที่ผมต้องพาระบบออกสู่โลกจริงเป็นครั้งแรก!