ประเด็นที่ Iris ten Teije ชวนคิดในคลิปนี้คือ AI อาจเปลี่ยนสมมติฐานเก่าของวงการซอฟต์แวร์ นั่นคือการสร้างซอฟต์แวร์หนึ่งเวอร์ชันที่เครื่องหนึ่ง แล้วส่งไปใช้อีกเครื่องโดยคงโค้ดชุดเดิมไว้
ในคลิป The Pipeline Is Dead จากช่อง AI Engineer เธอเสนอว่าอนาคตของการส่งซอฟต์แวร์ให้ผู้ใช้อาจไม่ใช่การส่งของชิ้นเดียวให้ทุกคน แต่เป็นการปล่อยแกนกลางหนึ่งชุด แล้วให้ระบบแตกแขนงเป็นเวอร์ชันที่เหมาะกับแต่ละคนระหว่างใช้งาน นี่เป็นวิสัยทัศน์ที่เธอและทีมกำลังทำงานต่อ ยังมีโจทย์ยากที่เธอยอมรับว่ายังแก้ไม่ครบ
สำหรับคนทำผลิตภัณฑ์ แนวคิดนี้ชวนให้ถามทั้งเรื่องความเหมาะสมกับผู้ใช้และวิธีวัดผล Iris ยกอัตราการกลับมาใช้ การเลิกใช้ และจำนวนคำขอช่วยเหลือเป็นตัวอย่างเป้าหมายที่ต้องติดตาม ไม่ใช่ผลลัพธ์ที่เกิดขึ้นแน่นอนจากการใช้ AI
ทำไม pipeline แบบเดิมถึงเคยเหมาะกับต้นทุนการพัฒนา
Iris เริ่มจากแนวคิด one version for everyone หรือซอฟต์แวร์เวอร์ชันเดียวสำหรับทุกคน เราสร้าง artifact ซึ่งหมายถึงชุดซอฟต์แวร์ที่พร้อมนำไปใช้งาน แล้วคงสภาพนั้นไว้ก่อนส่งจากเครื่องที่สร้างไปยังเครื่องที่รัน ผ่านกระบวนการอย่าง CI pipeline ที่ตรวจและเตรียมโค้ดอัตโนมัติ ที่เก็บแพ็กเกจ อิมเมจคอนเทนเนอร์ หรือการตรวจแอปในแอปสโตร์
เธออธิบายว่าโมเดลนี้เกิดจากต้นทุน เมื่อการเปลี่ยนโค้ดหนึ่งครั้งแพง เสี่ยง และใช้เวลาของคนที่มีทักษะ การเปลี่ยนแปลงจึงเป็นเหตุการณ์ที่ทำไม่บ่อย ต้องตรวจสอบให้ดี จากนั้นค่อยคงสภาพแล้วส่งให้ผู้ใช้
ข้อดีที่เธอยกมาคือ
- ย้อนกลับเวอร์ชันได้
- ตรวจสอบได้
- ทำซ้ำได้
ในมุมมองของ Iris ความน่าเชื่อถือนี้แลกมากับข้อจำกัดเรื่องการปรับให้เหมาะกับแต่ละคน ซอฟต์แวร์จึงมุ่งเป็นเวอร์ชันที่ใช้ได้กับคนจำนวนมาก มากกว่าเวอร์ชันที่เหมาะกับผู้ใช้แต่ละราย
Iris ตั้งข้อสังเกตว่าเราไม่ได้เลือกซอฟต์แวร์เวอร์ชันเดียวสำหรับทุกคนเพราะมันชนะการถกเถียง แต่เพราะการดูแลเวอร์ชันแยกตามผู้ใช้ยังมีต้นทุนสูงเกินไป นี่เป็นคำอธิบายของเธอต่อที่มาของโมเดลเดิม
ข้อเสนอเรื่องต้นทุนและการเปลี่ยนซอฟต์แวร์ระหว่างใช้งาน
ใจความสำคัญของคลิปไม่ใช่แค่ “AI เขียนโค้ดได้” Iris มองว่าต้นทุนในการสร้างการเปลี่ยนแปลงที่ถูกต้องและมีขอบเขตกำลังลดลงมาก เธอใช้คำว่าเข้าใกล้ศูนย์เพื่ออธิบายทิศทางนี้ แต่ไม่ได้แสดงผลทดสอบต้นทุนที่ยืนยันว่าเกิดขึ้นกับซอฟต์แวร์ทุกชนิด
ในข้อเสนอของเธอ เมื่อการแก้ซอฟต์แวร์ถูกลง การตัดสินใจว่าจะคงทุกอย่างไว้ตั้งแต่ขั้นสร้างซอฟต์แวร์ก็อาจเปลี่ยนไป บางส่วนอาจถูกกำหนดบนเซิร์ฟเวอร์ บางส่วนบนเครื่องผู้ใช้ และบางส่วนอาจเปลี่ยนได้ระหว่างการใช้งานของผู้ใช้คนนั้น
นี่คือจุดที่เธอมองว่าเส้นแบ่งระหว่างการพัฒนากับการส่งซอฟต์แวร์ให้ผู้ใช้เริ่มจางลง ถ้าการเปลี่ยนแปลงเกิดขึ้นได้ใกล้จุดใช้งานจริงมากขึ้น การพัฒนาและการปล่อยซอฟต์แวร์ก็อาจไม่ต้องแยกเป็นสองช่วงเสมอไป
ความต้องการซอฟต์แวร์ที่เหมาะกับผู้ใช้แต่ละคน
อีกมุมที่ Iris ยกขึ้นมาคือความต้องการของลูกค้าไม่ได้เพิ่งเกิด คนต้องการซอฟต์แวร์ที่เข้ากับงานตัวเองมานานแล้ว เธอมองว่าข้อจำกัดที่ผ่านมาอยู่ที่ต้นทุนในการปรับให้แต่ละคน
ตัวอย่างที่ยกมาในคลิปชัดมาก
- ซอฟต์แวร์องค์กรมีบริการจากผู้เชี่ยวชาญหรือที่ปรึกษาไว้ปรับระบบให้ลูกค้ารายใหญ่
- เครื่องมือทำงานส่วนตัว เช่น การตั้งค่าโปรแกรมแก้ไขโค้ดหรือปุ่มลัด คนก็มักปรับให้เข้ามือ
- Excel เป็นอีกตัวอย่างที่เธอยกมา เพราะผู้ใช้สร้างโปรแกรมและลำดับงานของตัวเองบนเครื่องมือเดียวกัน
เธอใช้ตัวอย่างเหล่านี้สนับสนุนความต้องการซอฟต์แวร์ที่ปรับตามผู้ใช้ และเปรียบเทียบกับวิธีแบ่งกลุ่มล่วงหน้า เช่น feature flags ที่เปิดปิดฟีเจอร์ตามเงื่อนไข การแบ่งกลุ่มผู้ใช้ และ A/B testing ที่ทดสอบตัวเลือกต่างกันระหว่างกลุ่ม
ทำความเข้าใจกับแนวคิด stem และ divergence
ข้อเสนอหลักของ Iris คือ แทนที่จะส่งโค้ดชุดเดียวที่คุมด้วยการเปิดปิดฟีเจอร์ให้ทุกคน ให้ปล่อย canonical stem หรือแกนกลางร่วมหนึ่งชุด แล้วให้ผู้ใช้แต่ละคนรัน divergence ซึ่งหมายถึงส่วนที่แตกต่างและปรับเฉพาะราย
พูดให้ง่ายขึ้น คือมี “แกน” ร่วมกัน แต่แต่ละคนเห็นหน้าตาและลำดับการทำงานที่ต่างกันได้แบบสดๆ
เป้าหมายที่เธออธิบายคือขยับจากเวอร์ชันเดียวที่พอใช้ได้กับทุกคน ไปสู่เวอร์ชันที่เหมาะกับผู้ใช้แต่ละราย
ตัวอย่างที่เธอยกเพื่ออธิบายแนวคิดเป็น CRM หรือระบบจัดการความสัมพันธ์กับลูกค้า ซึ่งมักออกแบบโดยมีพนักงานขายเป็นผู้ใช้หลัก แต่ถ้าผู้ใช้เป็นนักลงทุน พฤติกรรมอาจต่างออกไป เช่น
- บันทึกว่าใครแนะนำผู้ก่อตั้งเข้ามาในดีลลงทุน
- ข้ามบางช่องกรอกข้อมูลเป็นประจำ
- สนใจดีลบางประเภทมากกว่าที่ระบบจัดลำดับไว้
ในตัวอย่างนี้ ระบบที่ปรับตามผู้ใช้ควรเรียนรู้ว่าช่องข้อมูลใดควรซ่อน ช่องใดควรแสดงให้เด่นขึ้น และข้อมูลแบบไหนควรขึ้นก่อน โดยยังอยู่ภายในขอบเขตและจุดประสงค์ของผลิตภัณฑ์เดิม ผู้ใช้ยังอาจเป็นฝ่ายขอให้ปรับเองได้ด้วย ตัวอย่างนี้อธิบายแนวคิด ไม่ใช่ผลทดสอบว่าระบบทำได้ถูกต้องทุกครั้ง
เป้าหมายของการจำกัดขอบเขตและย้อนกลับรายกรณี
Iris เล่าถึง CTO คนหนึ่งที่กังวลว่า แค่ดูแลโค้ดที่ AI สร้างชุดเดียวก็ยากอยู่แล้ว แล้วจะดูแลเป็นล้านเวอร์ชันได้อย่างไร เรื่องนี้เป็นบทสนทนาที่เธอรายงาน ไม่ใช่การสำรวจความเห็นของ CTO
คำตอบของ Iris ไม่ได้บอกให้เชื่อว่า AI จะจัดการทุกอย่างได้เอง แต่ชี้ไปที่ unmanaged divergence หรือความแตกต่างของโค้ดที่ไม่มีขอบเขตควบคุม
ในคำอธิบายของเธอ ถ้าโค้ดทุกส่วนแตะกันได้หมดและไฟล์ยาวพันบรรทัดพันกันเป็นก้อนเดียว ความเปราะบางก็เกิดจากการขาดโครงสร้างแบ่งส่วน ไม่ใช่เพียงจากการที่ AI สร้างโค้ด
แนวคิดแกนกลางและส่วนที่แตกต่างเฉพาะผู้ใช้พยายามแก้เรื่องนี้ด้วยเป้าหมายให้แต่ละส่วน
- มีขอบเขต
- แยกจากกัน
- ย้อนกลับได้รายกรณี
- จำกัดผลกระทบไว้ในบริบทของผู้ใช้รายนั้น
Iris มองว่าถ้าออกแบบโครงสร้างได้ตามเป้าหมาย ความเสียหายจากการเปลี่ยนแปลงอาจจำกัดอยู่ในบริบทของผู้ใช้รายเดียว และย้อนกลับได้โดยไม่ต้องปล่อยซอฟต์แวร์ทั้งระบบใหม่ นี่เป็นคุณสมบัติที่สถาปัตยกรรมนี้มุ่งให้ได้ ยังไม่ใช่คำรับรองว่าทำสำเร็จแล้วในทุกกรณี
ข้อควรคิดตามคือความท้าทายไม่ได้หายไป แม้จะจำกัดผลกระทบได้ ก็ยังต้องออกแบบขอบเขตที่แต่ละส่วนแก้ไขได้ให้ชัด และตรวจสอบว่าขอบเขตนั้นทำงานจริง
ตั้งขอบเขตให้ชัดว่าระบบปรับอะไรได้ และอะไรห้ามแตะ
Iris เสนอว่านักพัฒนายังต้องกำหนดว่าระบบปรับอะไรได้และห้ามแตะอะไร เธอยกตัวอย่างฟอร์มที่อาจปรับเพื่อเพิ่มอัตราการทำรายการสำเร็จ แต่ช่องข้อมูลบางช่องต้องถูกกำหนดว่าห้ามลบ
ส่วนการชำระเงินเป็นตัวอย่างที่เธอเสนอให้กันออกจากการปรับอัตโนมัติ
หากใช้แนวคิดนี้เป็นคำถามในการออกแบบผลิตภัณฑ์ เราอาจแบ่งพื้นที่เป็นสามชั้น ตัวอย่างต่อไปนี้เป็นข้อเสนอของ VibeSolo ไม่ใช่รายการที่ผู้พูดแจกแจงไว้
- ส่วนที่อาจอนุญาตให้ปรับ เช่น คำอธิบายและลำดับข้อมูล
- ส่วนที่ปรับได้ภายใต้ข้อจำกัด เช่น ฟอร์มที่ต้องคงช่องข้อมูลสำคัญไว้
- ส่วนที่กันออกจากการปรับอัตโนมัติ เช่น การชำระเงิน
ห้าโจทย์ที่ยังต้องแก้เมื่อไม่มีซอฟต์แวร์ชุดเดียว
Iris ยอมรับตรงๆ ว่าทีมยังแก้โจทย์ยากทั้งหมดไม่ได้ แต่มีมุมมองต่อแต่ละข้อ และกำลังทำงานอยู่ เธอแบ่งความท้าทายหลักเป็นห้าเรื่อง
1. จะตรวจสอบสถานะซอฟต์แวร์จากอะไร
ถ้าไม่มีชุดซอฟต์แวร์เดียว เราจะตอบอย่างไรว่าผู้ใช้กำลังใช้ซอฟต์แวร์อะไร ในแนวคิดของเธอคำตอบคือแกนกลางรวมกับส่วนแตกต่างทั้งหมดที่มีบันทึกคงสภาพไว้ให้ตรวจสอบ
การถามว่า “ผู้ใช้นี้กำลังรันเวอร์ชันไหน” จึงต้องตามความสัมพันธ์ให้ได้ว่า สัญญาณใดนำไปสู่คำแนะนำใด และเกิดการปรับแบบไหน Iris ระบุว่าการติดตามที่มานี้เป็นหนึ่งในส่วนที่ทีมกำลังทำงานอยู่
2. จะทดสอบความถูกต้องอย่างไร
เธอชี้ว่าต้องทดสอบทั้งแกนกลางและส่วนแตกต่างที่อาจเกิดขึ้น รวมถึงตรวจว่าการเปลี่ยนโค้ดและหน้าจอทำงานถูกต้อง
3. เปลี่ยนแล้วดีต่อผู้ใช้และธุรกิจจริงหรือไม่
โค้ดถูกต้องไม่ได้แปลว่าการเปลี่ยนนั้นเป็นสิ่งที่ต้องการ Iris ยกตัวอย่างเป้าหมายอย่างการกลับมาใช้ การลดการเลิกใช้ หรือการลดจำนวนคำขอช่วยเหลือ แล้วถามว่าการปรับทำให้ตัวชี้วัดที่สำคัญดีขึ้นจริงหรือไม่
4. จะให้ระบบตัดสินใจเองแค่ไหน
เธอกล่าวว่าการเริ่มจากคำแนะนำโดยยังไม่ให้ระบบเปลี่ยนเองเป็นทางเลือกที่สมเหตุสมผล แต่เป้าหมายของทีมคือทำให้ระบบน่าเชื่อถือพอจนไม่ต้องขอให้นักพัฒนาอนุมัติทุกครั้ง เธอย้ำว่าการสร้างความไว้วางใจนี้ยังเป็นโจทย์ยาก
5. จะประสานการเปลี่ยนแปลงระหว่างหลายเวอร์ชันอย่างไร
ถ้าทุกคนใช้เวอร์ชันต่างกัน การส่งอัปเดตจะไม่ใช่การให้ทุกคนรันโค้ดชุดเดียวกัน แนวคิดที่เธอเสนอคือประสานเจตนาและผลลัพธ์ เพื่อให้แต่ละเวอร์ชันไปถึงเป้าหมายเดียวกันผ่านเส้นทางของตัวเอง
การสร้างโค้ดกับการดูแลการเปลี่ยนแปลง
Iris ใช้วลี “generation is the easy 80%” เพื่อเน้นว่าการเรียกโมเดลให้เขียนโค้ดเป็นส่วนที่ง่าย ตัวเลข 80% เป็นการประเมินเชิงถ้อยคำของผู้พูด ไม่มีวิธีวัดหรือผลทดสอบให้ตรวจสอบในคลิป
ส่วนที่เธอมองว่ายากคือ
- การมองเห็นว่าเกิดอะไรขึ้นในระบบ
- การตรวจสอบว่าการเปลี่ยนแปลงใช้ได้จริง
- การตามที่มาและเหตุผลของแต่ละเวอร์ชัน
- การประสานการเปลี่ยนแปลงให้ไปถึงเป้าหมายร่วม
- การวัดผลว่าการเปลี่ยนทำให้ตัวชี้วัดที่ต้องการดีขึ้นหรือไม่
หากใช้เป็นคำถามในการตัดสินใจทำผลิตภัณฑ์ เราไม่ควรถามแค่ว่า “จะใช้ AI ทำฟีเจอร์อะไร” แต่ควรถามต่อว่า
- จะรู้ได้ยังไงว่า AI ปรับอะไรไปบ้าง
- ถ้าผลลัพธ์แย่ จะย้อนกลับอย่างไร
- จะวัดผลกับตัวชี้วัดไหน
- ใครมีสิทธิ์กำหนดขอบเขตที่ระบบปรับได้
สารหลักของคลิปนี้เป็นข้อเสนอว่าเงื่อนไขที่เคยทำให้ pipeline แบบเดิมจำเป็นอาจเปลี่ยนไป เมื่อการสร้างซอฟต์แวร์ถูกลงและเกิดใกล้จุดใช้งานจริงมากขึ้น เราอาจไม่ได้ส่งซอฟต์แวร์ชุดเดียวให้ทุกคนอีกต่อไป ขณะเดียวกัน การจำกัดผลกระทบ การตรวจสอบที่มา และการวัดว่าการเปลี่ยนแปลงดีจริงยังเป็นโจทย์หลักที่ต้องแก้
สำหรับคนทำผลิตภัณฑ์ คำถามที่ตามมาคือส่วนไหนควรปรับเฉพาะผู้ใช้ และเราจะตรวจสอบความถูกต้อง ที่มา และผลลัพธ์ได้อย่างไร ก่อนจะเพิ่มอิสระให้ระบบตัดสินใจเอง
ที่มา: The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing จากช่อง AI Engineer อัปโหลดวันที่ 7 กรกฎาคม 2026 เวลา 03:46:29 UTC บทความนี้สรุปข้อเสนอจากคำบรรยายที่บันทึกไว้ ไม่ได้ยืนยันความพร้อมใช้งานของผลิตภัณฑ์หรือประสิทธิภาพจากการทดสอบอิสระ วันอัปโหลดเป็นวันของแหล่งข้อมูล ไม่ใช่วันเผยแพร่บทความนี้
