สรุปจากคลิป ดูคลิปต้นฉบับ
ปัญหาของ AI วันนี้อาจไม่ใช่เรื่องว่า “มันเก่งพอหรือยัง” แต่เป็นเรื่องว่าเราเริ่มปล่อยให้มันทำอะไรแทนเรามากเกินไปหรือเปล่า คลิป Building pi in a World of Slop ของ Mario Zechner จากเวทีที่เผยแพร่โดยช่อง AI Engineer พูดเรื่องนี้ได้คมมาก เพราะมันไม่ได้เป็นแค่เรื่องการสร้าง coding agent ตัวหนึ่งชื่อ Pi แต่มันลากไปถึงปัญหาใหญ่กว่า คือเครื่องมือ AI กำลังทำให้ซอฟต์แวร์แย่ลง, ทำลาย open source, และทำให้คนทำงานหลงคิดว่า “เร็วขึ้น” เท่ากับ “ดีขึ้น”
แม้เนื้อหาจะเริ่มจากโลก developer แต่สารสำคัญกลับตรงกับโลกธุรกิจมากกว่าที่คิด เจ้าของกิจการและทีมงานที่กำลังเอา AI มาใช้ ควรฟังประโยคนี้ให้ชัด: ถ้าเราไม่คุมเครื่องมือ สุดท้ายเครื่องมือจะคุม workflow ของเราแทน และถ้าเราเร่งให้ AI ผลิตงานเยอะเกิน โดยไม่ได้สร้างระบบตรวจทานที่ดี เราอาจได้ “งานปริมาณมาก” ที่ซ่อนต้นทุนมหาศาลเอาไว้ข้างหลัง
สารบัญ
- Pi ไม่ได้เกิดจากความอยากสร้างของใหม่ แต่มาจากความเบื่อของเดิม
- บทเรียนแรกสำหรับธุรกิจ: อย่าหลงกับ feature ถ้ายังคุมระบบไม่ได้
- ทำไม Pi ถึงตั้งใจเรียบง่ายมาก
- ความน่าสนใจของ Pi คือ “แก้ตัวเองได้”
- Mario ไม่ได้บอกให้ทุกคนใช้ Pi เขากำลังบอกให้ทุกคน “เอาอำนาจกลับมา”
- Act 2: เมื่อ AI agents เริ่มทำลาย open source
- Act 3: ช้าลงหน่อย เพราะทุกอย่างเริ่มพัง
- แล้วควรใช้ AI แบบไหนถึงจะไม่พัง
- จุดที่เห็นด้วยมาก และจุดที่ควรเผื่อใจไว้
- Actionable Insights
- Troubleshooting
- การต่อยอด
- สรุป Checklist ทั้งหมด
Pi ไม่ได้เกิดจากความอยากสร้างของใหม่ แต่มาจากความเบื่อของเดิม
Mario เล่าว่าเขาเคยใช้ Claude Code ช่วงแรกแล้วชอบมาก มันเรียบง่าย คาดเดาได้ และเข้ากับ workflow ของเขา แต่พอเวลาผ่านไป เครื่องมือเริ่มมี feature เยอะขึ้น ทีมโตขึ้น และระบบเริ่มเปลี่ยนไปในทางที่เขาไม่ได้ต้องการ
ปัญหาไม่ได้อยู่ที่ feature เยอะอย่างเดียว แต่อยู่ที่เครื่องมือเริ่ม “จัดการ” context ให้เองแบบที่ผู้ใช้ไม่เห็น เช่น เปลี่ยน system prompt ตาม release, ปรับ tool definitions, แทรก system reminders ในจังหวะที่ไม่เหมาะ และแทบไม่มี observability ให้ตรวจสอบว่า agent กำลังคิดหรือทำอะไรอยู่
สำหรับคนทำธุรกิจ ประเด็นนี้แปลได้ง่ายมาก ถ้าเราใช้ AI platform ที่เป็นกล่องดำเกินไป เราอาจได้ผลลัพธ์ที่ไม่เสถียรโดยไม่รู้ต้นเหตุ วันหนึ่งตอบดี อีกวันตอบแปลก ทั้งที่ใช้ prompt เดิม นี่คือความเสี่ยงที่หลายทีมมักมองข้าม โดยเฉพาะเวลานำ AI ไปใช้กับงานขาย งานบริการลูกค้า หรือการสร้างเอกสารสำคัญ
Mario เลือกไม่เดินต่อกับเครื่องมือที่เขาคุมไม่ได้ เขาเลยสร้าง Pi ขึ้นมา โดยมีแนวคิดหลักง่ายมาก คือ agent ควรปรับเข้ากับ workflow ของเรา ไม่ใช่ให้เราปรับตัวเข้าหา agent
บทเรียนแรกสำหรับธุรกิจ: อย่าหลงกับ feature ถ้ายังคุมระบบไม่ได้
หลายบริษัทเวลาเลือก AI tool มักดูจากสิ่งที่ขายง่ายที่สุด เช่น ทำได้กี่อย่าง, มี agent กี่ตัว, ต่อ integration ได้กี่ระบบ แต่สิ่งที่ Mario สนใจกลับเป็นเรื่องพื้นฐานกว่านั้นมาก ได้แก่
- คุม context ได้ไหม
- มองเห็นการทำงานภายในได้ไหม
- ขยายหรือแก้ไขได้ไหม
- มันพังบ่อยไหม
นี่เป็นมุมคิดที่ธุรกิจไทยเอาไปใช้ได้ทันที เพราะเวลาซื้อ AI มาใช้ในองค์กร เรามักถามว่า “ทำอะไรได้บ้าง” แต่ควรถามเพิ่มว่า “เวลาไม่เวิร์ก เราแก้เองได้แค่ไหน” และ “เราอธิบายผลลัพธ์ให้ทีมเข้าใจได้ไหม”
ในโลกจริง งานที่มีผลกับรายได้หรือความเชื่อมั่นลูกค้า ไม่ควรถูกผูกไว้กับระบบที่เปลี่ยน behavior เองอยู่ตลอด โดยที่เราไม่มีเครื่องมือมองเห็น
ทำไม Pi ถึงตั้งใจเรียบง่ายมาก
สิ่งที่น่าสนใจที่สุดใน Pi คือ Mario ไม่ได้พยายามทำ agent ที่อลังการที่สุด เขากลับตัดทุกอย่างที่ไม่จำเป็นออก แล้วเก็บไว้แค่แกนที่ยืดหยุ่นพอให้ต่อยอดได้ภายหลัง
Pi มีแค่ไม่กี่ส่วนหลัก เช่น abstraction สำหรับหลาย provider, agent core แบบ while loop กับ tool calling, UI framework และตัว coding agent เอง ส่วน system prompt ก็สั้นมาก เครื่องมือพื้นฐานมีแค่ read, write, edit, bash
เหตุผลคือเขาเชื่อว่า model รุ่นใหม่ถูกฝึกมาให้เข้าใจงานแบบ coding agent อยู่แล้ว ไม่จำเป็นต้องเขียนคำสั่งยาวหลายพัน token เพื่อย้ำสิ่งที่ model รู้อยู่แล้ว
สำหรับคนทำงานนอกสายเทคนิค นี่มีนัยสำคัญมาก เพราะมันเตือนเราว่า AI workflow ที่ดี ไม่จำเป็นต้องซับซ้อนเสมอไป หลายองค์กรเสียเวลาทำ prompt ซ้อน prompt, chain ซ้อน chain, agent ต่อ agent ทั้งที่ปัญหาอาจแก้ได้ด้วย flow ที่สั้นกว่าและชัดกว่า
ความน่าสนใจของ Pi คือ “แก้ตัวเองได้”
Pi ถูกออกแบบให้ agent ปรับตัวเองได้ผ่าน extension โดย extension เป็นแค่ TypeScript module ธรรมดา จะเก็บบน disk, ลง NPM หรือแชร์ผ่าน GitHub ก็ได้ และระบบรองรับ hot reload ทำให้แก้แล้วเห็นผลทันทีใน session เดิม
Mario ย้ำแรงมากว่า วิธีสร้าง Pi extension ที่ดีที่สุดคือ ไม่ต้องสร้างเอง แต่ให้ Pi ช่วยสร้างจากสเปกที่เราบอก แล้วค่อยไล่ปรับร่วมกัน
จุดนี้ถ้ามองในมุมธุรกิจ มันสะท้อนแนวคิดที่ใหญ่กว่า software development คือเราไม่จำเป็นต้องซื้อ platform ที่บอกว่าทำได้ทุกอย่าง แต่ควรมีระบบแกนกลางที่ดัดแปลงตามงานจริงของบริษัทได้ เช่น
- ทีมเซลส์ใช้ AI ช่วยเตรียมสรุปลูกค้าแบบหนึ่ง
- ทีมบริการลูกค้าใช้ AI สร้าง draft ตอบคำถามอีกแบบหนึ่ง
- ทีมปฏิบัติการใช้ AI สรุปรายงานหรือหาความผิดปกติอีกแบบหนึ่ง
ถ้าระบบยืดหยุ่น เราจะไม่ถูกบังคับให้ทุกทีมใช้ workflow แบบเดียวกัน ซึ่งมักเป็นต้นเหตุของการใช้ AI แล้ว “เหมือนไม่เวิร์ก” ทั้งที่จริงคือ workflow ไม่เข้ากับงาน
Mario ไม่ได้บอกให้ทุกคนใช้ Pi เขากำลังบอกให้ทุกคน “เอาอำนาจกลับมา”
ประโยคสำคัญช่วงกลางเรื่องคือ ทั้งหมดนี้ไม่ได้เกี่ยวกับ Pi อย่างเดียว แก่นจริงคือ คนทำงานควรเอาการควบคุมเครื่องมือและ workflow กลับมาอยู่ในมือ
นี่เป็นข้อคิดที่สำคัญมากสำหรับเจ้าของธุรกิจไทย ตอนนี้หลายองค์กรกำลังซื้อ AI แบบเร่งด่วนเพราะกลัวตกขบวน แต่ยิ่งรีบโดยไม่รู้ว่าตัวเองต้องการอะไร ก็ยิ่งเสี่ยงซื้อของที่ดูเก่งแต่ใช้จริงไม่เข้ากับทีม
AI ที่ดีสำหรับธุรกิจไม่ใช่ตัวที่เดโมแล้วว้าวที่สุด แต่คือตัวที่ตอบคำถามนี้ได้:
- เราแก้ไข flow ได้เองไหม
- เรากำหนดขอบเขตงานให้มันได้ไหม
- เราตรวจผลงานมันได้ง่ายไหม
- วันหนึ่งถ้าต้องเปลี่ยน model หรือ provider เราย้ายได้ไหม
Act 2: เมื่อ AI agents เริ่มทำลาย open source
เรื่องเริ่มหนักขึ้นเมื่อ Pi ถูกนำไปใช้เป็นแกนของ OpenClaw แล้ว project open source ของ Mario กลายเป็นเป้าของ bot และ agent จำนวนมากที่ยิง issue หรือ pull request คุณภาพต่ำเข้ามาแบบไม่รู้จบ เขาเรียกสิ่งเหล่านี้ว่า clankers
ผลคือ issue tracker ของ open source เริ่มเต็มไปด้วยขยะ คนดูแลโครงการเสียเวลาไปกับการกรอง noise มากกว่าการพัฒนางานจริง Mario เลยสร้างวิธีรับมือแบบตรงไปตรงมา เช่น
- ปิด pull request อัตโนมัติ แล้วขอให้กลับมาเขียน issue ด้วย “เสียงมนุษย์” แบบสั้นและชัด
- ใครทำตามได้ จึงค่อย whitelist ให้ส่งรอบต่อไป
- ติด label แยกพวกที่มาจากระบบ agent
- ปิด tracker ชั่วคราวเมื่ออยากพัก เขาเรียกว่า OSS vacation
มุมนี้ดูไกลจากธุรกิจทั่วไป แต่จริงๆ ใกล้มาก เพราะบริษัทจำนวนมากกำลังเจอปัญหาเดียวกันในรูปแบบอื่น เช่น AI สร้าง lead ปลอม, AI สร้างคอนเทนต์ปริมาณมากแต่คุณภาพต่ำ, AI ตอบลูกค้าแบบดูเหมือนช่วยแต่จริงๆ เพิ่มงานให้ทีมหลังบ้าน
บทเรียนคือ automation ที่ไม่มีตัวกรองที่ดี จะเปลี่ยนเวลางานให้กลายเป็นเวลาคัดขยะ และในหลายกรณี ต้นทุนส่วนนี้สูงกว่าประโยชน์ที่ได้จากความเร็วเสียอีก
Act 3: ช้าลงหน่อย เพราะทุกอย่างเริ่มพัง
ช่วงท้ายคือส่วนที่แรงและน่าจดที่สุด Mario วิจารณ์วัฒนธรรมที่ชอบพูดว่า “product นี้สร้างด้วย agents 100%” ด้วยน้ำเสียงประชดชัดเจน เพราะสำหรับเขา สิ่งที่ตามมามักไม่ใช่ความภูมิใจ แต่คือ software ที่พังง่าย รกขึ้น และไม่มีใครเข้าใจมันแล้ว
เหตุผลหลักมีหลายชั้น
1) Agents เพิ่มความผิดพลาดแบบทบต้น
ถ้ามีคน 1 คนเขียนโค้ด เราพอเดาได้ว่าความผิดพลาดต่อวันมีเท่าไร แต่ถ้าเอา agent 10 ตัวมาช่วย ความเร็วเพิ่มขึ้นจริง ทว่า “booboos” หรือข้อผิดพลาดก็เพิ่มแบบคูณ และไม่ใช่ทุกอันจะถูกเจอในทันที
2) ความเจ็บปวดถูกเลื่อนออกไป
มนุษย์พอทำระบบรกมาก จะเริ่มรู้สึกทรมานและอยากแก้ แต่ agent ไม่มีความรู้สึกนั้น มันพร้อมสร้าง complexity ต่อไปเรื่อยๆ ถ้าเรายังปล่อยให้มันทำ
3) AI เรียนจากโค้ดเก่าบนอินเทอร์เน็ต
Mario พูดตรงมากว่า code บนอินเทอร์เน็ตส่วนใหญ่คือของเก่าคุณภาพปานกลางถึงแย่ เมื่อสเปกไม่ชัด AI ก็จะเติมช่องว่างด้วยสิ่งที่มันเรียนมา นั่นแปลว่าถ้าเราไม่คิดให้ชัด มันจะเติมความธรรมดาและความรกกลับเข้ามาเอง
4) รีวิวด้วย agent ก็ไม่ได้ช่วยเสมอไป
หลายทีมชอบตอบว่า “ไม่เป็นไร เรามี review agent” แต่เขามองว่านี่คือวงจร Ouroboros คือ agent ผลิตงาน แล้วเอา agent อีกตัวมาตรวจงานนั้น มันพอช่วยจับบางอย่างได้ แต่ไม่ได้แก้ปัญหาราก เพราะทั้งคู่ยังคิดจากข้อจำกัดชุดเดียวกัน
ถ้าแปลเป็นภาษาธุรกิจง่ายๆ คือ อย่าเพิ่งภูมิใจกับการใช้ AI ให้ทำงานแทนทีมเยอะๆ ถ้าเราไม่มีระบบคัดกรอง ความเร็ววันนี้อาจกลายเป็นภาระของทีมปฏิบัติการในอีก 3 เดือนข้างหน้า เช่น
- AI ทำ proposal ได้เร็ว แต่เงื่อนไขผิด
- AI เขียน FAQ ได้เยอะ แต่ตอบไม่ตรงนโยบายบริษัท
- AI สรุปรายงานได้ไว แต่ตก insight สำคัญที่กระทบการตัดสินใจ
- AI ช่วยทำ content จำนวนมาก แต่ภาพลักษณ์แบรนด์เริ่มเพี้ยน
แล้วควรใช้ AI แบบไหนถึงจะไม่พัง
Mario ไม่ได้ต่อต้าน AI เขาแค่ต่อต้านการใช้แบบไม่คิด เขาเสนอหลักง่ายๆ ว่า งานที่เหมาะกับ agent คืองานที่มี ขอบเขตชัด, มีวิธีประเมินได้, ไม่ mission critical, หรือเป็นงานน่าเบื่อที่กินเวลา
ตัวอย่างที่เขายกแล้วน่าเอาไปใช้ต่อคือ ให้ agent ช่วยทำ reproduction cases จาก user issues หรือใช้เป็น rubber duck เวลาคิดงานไม่ออก พอ agent ทำร่างมาแล้ว มนุษย์ค่อยประเมิน เลือกเฉพาะสิ่งที่ใช้ได้ และค่อย finalize เอง
สำหรับธุรกิจไทย เราว่านี่คือแนวใช้ AI ที่ปลอดภัยและคุ้มกว่า เช่น
- ให้ AI ร่างอีเมลขาย แต่คนเลือกและปรับน้ำเสียงเอง
- ให้ AI สรุปประชุม แต่หัวหน้าทีมเป็นคนยืนยันประเด็นสำคัญ
- ให้ AI ช่วยจัดหมวดหมู่ feedback ลูกค้า แต่ทีมบริการวิเคราะห์ root cause เอง
- ให้ AI สร้าง draft SOP แต่เจ้าของกระบวนการเป็นคนอนุมัติ
หลักคิดสั้นๆ คือ ใช้ AI ทำงานเตรียม Use AI for draft, not for final judgment แม้ Mario พูดจากโลกโค้ด แต่หลักนี้ใช้กับเอกสาร การตลาด การขาย และงานปฏิบัติการได้ครบ
จุดที่เห็นด้วยมาก และจุดที่ควรเผื่อใจไว้
สิ่งที่เห็นด้วยมากคือคำเตือนเรื่อง “อ่านงานที่สำคัญเอง” เพราะหลายทีมเริ่มติดนิสัยไม่อ่านของที่ AI สร้างแล้ว เดาว่าเดี๋ยวมันแก้ตัวเองได้ สุดท้ายพอปัญหาเกิดจริง กลับไม่มีใครเข้าใจระบบพอจะจัดการ
อีกจุดที่คมคือเรื่อง friction มีคุณค่า การทำเองบางส่วนไม่ได้แปลว่าช้าแบบเสียเปล่า แต่มันสร้างความเข้าใจในระบบ ซึ่งจำเป็นมากเวลาต้องตัดสินใจหรือแก้ปัญหา
ส่วนจุดที่ควรเผื่อใจไว้คือ มุมของ Mario ค่อนข้างมาจากโลกที่ต้องคุมเครื่องมือระดับลึก ธุรกิจทั่วไปอาจไม่จำเป็นต้อง “สร้างของเอง” แบบ Pi แต่หลักคิดเบื้องหลังยังใช้ได้เต็มๆ คืออย่าฝากระยะถัดไปของกระบวนการสำคัญไว้กับระบบที่เราแก้ไม่ได้ มองไม่เห็น และตรวจยาก
Actionable Insights
- เริ่มจากงานที่มีขอบเขตชัด เช่น สรุปประชุม, ร่างอีเมล, จัดหมวดหมู่คำถามลูกค้า อย่าเริ่มจากงานที่ต้องใช้ judgment สูง
- แยกงาน draft ออกจากงานตัดสินใจ ให้ AI ช่วยร่าง แต่คนเป็นคนอนุมัติ โดยเฉพาะเรื่องราคา ข้อเสนอ และนโยบาย
- วัดต้นทุนการตรวจทานด้วย อย่าวัดแค่ว่า AI ทำเสร็จเร็วขึ้น ต้องดูด้วยว่าทีมเสียเวลาไล่แก้ตามหลังแค่ไหน
- อย่าซื้อเพราะ feature เยอะ เลือกเครื่องมือที่ทีมเข้าใจ flow และแก้ไขได้มากกว่าเครื่องมือที่ดูหวือหวา
- อ่านงานสำคัญทุกครั้ง ถ้างานกระทบรายได้ กฎหมาย หรือความเชื่อมั่นลูกค้า อย่าปล่อยผ่านแบบไม่ตรวจ
Troubleshooting
ปัญหา: ใช้ AI แล้วทีมเหมือนทำงานเร็วขึ้น แต่ข้อผิดพลาดเพิ่ม
สาเหตุ: ให้ AI ทำงานปลายทางมากเกินไป โดยไม่มีจุดตรวจที่ชัด
วิธีแก้: แยกเป็น 2 ชั้น คือให้ AI ทำ draft และให้คนตรวจเฉพาะส่วนตัดสินใจสำคัญ
ปัญหา: ผลลัพธ์จาก AI แกว่ง ใช้ prompt เดิมแต่ได้คำตอบไม่เหมือนกัน
สาเหตุ: ใช้ platform ที่จัดการ context หรือ system behavior เองมากเกินไป
วิธีแก้: ลดความซับซ้อนของ workflow, เก็บ prompt มาตรฐาน, ทดสอบซ้ำกับงานเดิม และเลือกเครื่องมือที่ตรวจสอบย้อนหลังได้
ปัญหา: ทีมเริ่มไม่เข้าใจงานที่ AI สร้างเองแล้ว
สาเหตุ: พึ่ง AI เร็วเกิน จนเลิกอ่านและเลิกทำความเข้าใจโครงสร้างงาน
วิธีแก้: กำหนดว่าเอกสารหรือกระบวนการสำคัญต้องมีเจ้าของที่อ่านจริงและอธิบายได้
ปัญหา: AI สร้างงานได้เยอะ แต่คุณภาพแบรนด์เริ่มเพี้ยน
สาเหตุ: สเปกไม่ชัด AI เลยเติมจากข้อมูลทั่วไปที่มันเคยเรียนมา
วิธีแก้: สร้าง guideline ที่ชัดเรื่องน้ำเสียง, ข้อห้าม, ตัวอย่างงานที่ดี และใช้คนรีวิวงานชุดแรกเสมอ
ปัญหา: ทีมเผลอเชื่อว่า “มี AI ตรวจ AI” แล้วจะปลอดภัย
สาเหตุ: คิดว่า review automation แทน human judgment ได้ทั้งหมด
วิธีแก้: ใช้ AI review เป็นตัวช่วยคัดกรอง ไม่ใช่ผู้ตัดสินคนสุดท้าย
การต่อยอด
- ทำแผนที่งานในบริษัทว่า งานไหนเหมาะให้ AI ช่วยร่าง และงานไหนห้ามปล่อยอัตโนมัติ
- สร้าง “AI workflow ฉบับบริษัท” ที่ระบุจุดเริ่ม จุดตรวจ และคนรับผิดชอบให้ชัด
- ทดลองใช้ AI แบบ modular กับทีมเล็กก่อน แล้วค่อยขยาย แทนการ rollout ใหญ่ทั้งองค์กรในครั้งเดียว
สรุป Checklist ทั้งหมด
- ☐ ระบุงานที่อยากให้ AI ช่วยแบบชัดเจน ไม่กว้างเกินไป
- ☐ แยกงานร่างออกจากงานตัดสินใจ
- ☐ เลือกเครื่องมือที่คุม flow และตรวจสอบได้
- ☐ วางจุด review สำหรับงานที่กระทบลูกค้า รายได้ หรือกฎหมาย
- ☐ วัดต้นทุนการแก้งาน ไม่ใช่วัดแค่ความเร็วตอนสร้าง
- ☐ ตั้ง guideline สำหรับแบรนด์ น้ำเสียง และข้อห้าม
- ☐ อย่าปล่อยให้ AI สร้างงานปริมาณมากโดยไม่มีตัวกรอง
- ☐ ให้คนในทีมอย่างน้อย 1 คนอธิบายงานหรือระบบที่ AI ช่วยทำได้
- ☐ ใช้ AI กับงานที่ประเมินผลได้ง่ายก่อน
- ☐ ถ้างานสำคัญ ให้อ่านทุกบรรทัดก่อนปล่อยใช้งาน
สรุปแล้ว คลิปของ Mario Zechner ไม่ได้เป็นแค่เรื่องการสร้าง Pi หรือการบ่นว่า agent tools พังบ่อย แต่มันคือคำเตือนที่ตรงมากสำหรับทุกองค์กรที่กำลังเห่อ AI ถ้าเราปล่อยให้ความเร็วชนะความเข้าใจ เราจะได้ “โลกของ slop” ที่เต็มไปด้วยงานจำนวนมาก แต่ไว้ใจไม่ได้
ทางออกไม่ใช่หยุดใช้ AI แต่คือ ช้าลงให้พอคิด เลือกงานให้เหมาะ วางขอบเขตให้ชัด และรักษาสิทธิ์ในการตัดสินใจไว้กับคน ถ้าทำได้แบบนี้ AI จะไม่กลายเป็นภาระก้อนใหม่ แต่น่าจะกลายเป็นแรงช่วยที่ใช้ได้จริงกับธุรกิจมากกว่า