Building Pi in a World of Slop: บทเรียน AI ที่ธุรกิจควรฟัง

สรุปจากคลิป ดูคลิปต้นฉบับ

ปัญหาของ 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 จะไม่กลายเป็นภาระก้อนใหม่ แต่น่าจะกลายเป็นแรงช่วยที่ใช้ได้จริงกับธุรกิจมากกว่า