- AI สามารถสร้างต้นแบบที่มีทั้ง UI และฐานข้อมูลได้ภายในไม่กี่นาที แต่ยังไม่สามารถลดช่องว่างจากเวอร์ชันแรกที่ใช้งานได้ไปสู่ ผลิตภัณฑ์ระดับโปรดักชัน ได้
- ในผลิตภัณฑ์จริงยังมีปัญหาที่ต้องใช้ วิจารณญาณเชิงวิศวกรรม มากกว่าการเขียนไวยากรณ์ เช่น การขยายระบบ การจัดการข้อผิดพลาด การสังเกตการณ์ระบบ ความปลอดภัย การยืนยันตัวตน และโครงสร้างข้อมูล
- คุณค่าของวิทยาการคอมพิวเตอร์ไม่ได้อยู่ที่การผลิตโค้ด แต่อยู่ที่ mental model สำหรับเข้าใจว่าระบบทำงานและล้มเหลวอย่างไร ซึ่งเป็นสิ่งจำเป็นต่อการพบ query ที่ไม่มีประสิทธิภาพหรือ race condition
- แม้ความต้องการงานที่แปลงข้อกำหนดเป็นโค้ดแบบกลไกจะลดลง แต่วิศวกรที่มีทักษะสามารถมอบงานซ้ำๆ ให้ AI และโฟกัสกับปัญหาที่ต้องใช้ความเชี่ยวชาญ ทำให้ทำงานได้เร็วขึ้นมาก
- หากใช้ AI เป็นตัวแทนของความเข้าใจ จะทำให้ยากต่อการแก้ไข ขยาย หรือส่งต่องานของระบบที่พัง ดังนั้นควร เรียนรู้พื้นฐานก่อน แล้วค่อยใช้เครื่องมือ AI
ช่องว่างระหว่างต้นแบบกับผลิตภัณฑ์
- หากอธิบายไอเดียด้วยภาษาธรรมชาติ คุณสามารถได้ ต้นแบบที่ใช้งานได้จริง พร้อม UI และฐานข้อมูล และทำฟังก์ชันตามที่ตั้งใจไว้ ภายในไม่กี่นาที
- แต่ต้นแบบที่รันอยู่บนโน้ตบุ๊กอาจเผยให้เห็นปัญหาหลายอย่างเมื่ออยู่ในสภาพแวดล้อมจริง
- รับโหลดไม่ไหวและไม่มีการจัดการข้อผิดพลาด
- API token อาจรั่วไหล
- data model สำหรับเดโมอาจพังทันทีที่เพิ่มผู้ใช้คนที่สอง
- การยืนยันตัวตนอาศัยสมมติฐานที่ยังไม่ได้ตรวจสอบ และไม่แน่ชัดว่าปลอดภัยหรือไม่
- เมื่อถึงขั้นตอน deploy จะเห็น ช่องว่างสู่โปรดักชัน ขนาดใหญ่ระหว่างคำว่า “ใช้งานได้” กับ “พร้อมใช้งานจริง”
งานยากเริ่มหลังจากเขียนโค้ด
- ก่อนหน้านี้วิศวกรซอฟต์แวร์ก็สามารถทำให้บางอย่างรันได้อย่างรวดเร็วอยู่แล้ว และส่วนที่ใช้เวลาจริงก็คือหลังจากนั้น
- ออกแบบระบบที่ยังรับมือได้แม้ขนาดจะโตขึ้น
- จัดการข้อยกเว้นเมื่อผู้ใช้เข้ามาตามเส้นทางที่ไม่คาดคิด
- สร้าง observability เพื่อให้รู้ได้ว่าเกิดเหตุขัดข้องขึ้น
- ตัดสินใจเรื่อง data architecture เพื่อลดความเสียใจในอีก 3 ปีข้างหน้า
- AI ช่วยลดเวลาไปถึงเวอร์ชันแรกที่ใช้งานได้อย่างมาก แต่ไม่ได้ลดระยะทางจากเวอร์ชันนั้นไปสู่ระบบระดับโปรดักชัน
- วงจรที่รวดเร็วของการขอผลลัพธ์ รับคำตอบ และตรวจผล อาจทำให้รู้สึกว่ากระบวนการพัฒนาที่เหลือก็ถูกบีบอัดตามไปด้วย แต่ปัญหาที่ยากของซอฟต์แวร์ไม่เคยอยู่ที่การเขียนไวยากรณ์ตั้งแต่แรก
- วิจารณญาณ ในการตัดสินใจว่าจะสร้างอะไร จะวางโครงสร้างอย่างไร จะเลื่อนอะไรออกไป และเมื่อไรควรปฏิเสธ คือสิ่งที่แยกต้นแบบออกจากระบบโปรดักชัน
ทำไมวิทยาการคอมพิวเตอร์ยังจำเป็น
- เมื่อเข้าถึงโค้ดที่ AI สร้างได้ง่ายขึ้น ผู้เริ่มต้นจำนวนมากจึงตั้งคำถามว่าจำเป็นต้องเรียน algorithm, data structure, operating system และทฤษฎีเป็นเวลาหลายปีหรือไม่
- คุณค่าของการศึกษาวิทยาการคอมพิวเตอร์ไม่ได้อยู่แค่ความสามารถในการเขียนโค้ด แต่คือการสร้าง mental model เพื่อเข้าใจว่าระบบทำงาน ล้มเหลว และให้ผลลัพธ์เช่นนั้นได้อย่างไร
- ต้องมีพื้นฐานนี้ก่อนจึงจะระบุความล้มเหลวที่อาจเกิดขึ้นในโค้ดที่ AI สร้างได้
- query ที่ทำให้เกิด full table scan บนตารางที่มี 50 ล้านแถว
- กลยุทธ์ cache ที่สร้าง race condition ภายใต้โหลดพร้อมกัน
- สถาปัตยกรรมที่แก้โจทย์ปัจจุบันได้ แต่ทำให้ปัญหาถัดไปยากขึ้นมาก
- หากไม่มีความรู้พื้นฐาน ก็จะต้องพึ่งพาการตัดสินของโมเดลทั้งหมด
- โมเดลไม่ได้มีวิจารณญาณ แต่สร้างโค้ดอย่างมั่นใจจากการจับคู่แพตเทิร์นตามที่มันคิดว่าตรงกับเจตนา
- โค้ดที่สร้างขึ้นอาจดูถูกต้องและเป็นไปตามธรรมเนียม แต่ล้มเหลวได้ในโปรดักชัน
- หากไม่มีความรู้พอจะสังเกตปัญหา การวินิจฉัยอาจกินเวลาหลายวัน
- ตอนนี้ที่ระยะห่างระหว่างความเข้าใจกับผลลัพธ์สั้นลง เป็นช่วงเวลาที่ดีในการเรียนวิทยาการคอมพิวเตอร์ และนักศึกษาที่เข้าใจ distributed systems อย่างถ่องแท้สามารถสร้างมันได้ในเวลาสั้นกว่าที่เคยเมื่อ 10 ปีก่อนมาก
งานที่ถูกทำให้เป็นอัตโนมัติและผลิตภาพที่ขยายขึ้น
- ความต้องการ งานเขียนโค้ดเชิงกลไก ที่แปลงข้อกำหนดทีละบรรทัดไปเป็น implementation กำลังลดลงจริง และงานส่วนนั้นกำลังถูกทำให้เป็นอัตโนมัติ
- ขอบล่างของการกระจายด้านผลิตภาพถูกบีบอัดลง ขณะที่ขีดจำกัดด้านบนขยายออก
- วิศวกรที่มีทักษะและใช้เครื่องมือ AI สมัยใหม่สามารถทำงานได้เร็วในระดับที่เมื่อ 5 ปีก่อนแทบจินตนาการไม่ถึง
- ไม่ใช่ว่าปัญหายากหายไป แต่เป็นเพราะงานเชิงกลไกที่เคยกินเวลาและความสนใจถูกจัดการไปเป็นส่วนใหญ่
- เวลาที่ได้คืนมานี้จึงนำไปใช้กับงานที่ต้องการความเชี่ยวชาญจริงได้
- วิศวกรที่จะตามไม่ทันไม่ใช่คนที่ไม่รู้วิธีใช้ AI แต่คือ คนที่ใช้ AI แทนความเข้าใจ
- สร้างระบบที่ตัวเองอธิบายเหตุผลไม่ได้ด้วย vibe coding
- แก้ปัญหาเหตุขัดข้องหรือขยายระบบที่เติบโตขึ้นไม่ได้
- อธิบายสิ่งที่ตัวเองสร้างให้ผู้ดูแลต่อไม่ได้
ทำงานในระดับ abstraction ที่สูงขึ้น
- การเปลี่ยนแปลงที่จำเป็นไม่ใช่แค่การรับเครื่องมือใหม่มาใช้ แต่คือการทำงานใน ระดับ abstraction ที่สูงขึ้นโดยยังยึดโยงกับพื้นฐาน
- วิศวกรที่ใช้ AI เป็นตัวขยายพลัง ไม่ใช่ตัวแทนของความรู้เชิงลึก จะก้าวนำเพื่อนร่วมงานได้เร็วกว่า
- เข้าใจว่าตัวเองกำลังขอให้โมเดลสร้างอะไร
- ตรวจโค้ดที่สร้างขึ้นอย่างมีวิจารณญาณ เหมือนรีวิว pull request ของวิศวกรจูเนียร์
- พูดคุยในมุมมองเชิงสถาปัตยกรรม ไม่ได้แค่โยนคำอธิบายฟีเจอร์ให้
- ตัดสินได้ว่าเมื่อไรควรคัดค้านข้อเสนอของโมเดล
- นี่ไม่ใช่การแทนที่ทักษะเดิมด้วยความสามารถใหม่ แต่เป็นการนำทักษะเดิมไปใช้ในสภาพแวดล้อมใหม่เพื่อให้ได้ leverage ที่สูงขึ้นมาก
- หลังจากต้นแบบแล้วก็ยังต้องมีวิจารณญาณเชิงวิศวกรรมจริงอยู่ดี และความสามารถนี้เองที่แยกนักพัฒนาที่ปล่อยซอฟต์แวร์ที่เชื่อถือได้ ออกจากนักพัฒนาที่ปล่อยได้แค่เดโม
- ลำดับการเรียนรู้ควรเป็น พื้นฐานมาก่อน แล้วค่อยตามด้วยเครื่องมือ AI
1 ความคิดเห็น
ความเห็นจาก Hacker News
กำลังจะทิ้งโค้ดที่สร้างด้วย LLM ตลอดหลายเดือนใน side project แม้จะเขียนสเปกการออกแบบอย่างละเอียดและทำงานบนโค้ดเบสเดิมแล้วก็ตาม การเปลี่ยนแปลงแต่ละจุดดูมีเหตุผล แต่เมื่อรวมกันทั้งระบบกลับกลายเป็น ก้อนความซับซ้อน ที่หลายส่วนคลาดเคลื่อนกันแบบละเอียดอ่อน
รายงานหรือบทความวิชาการก็คล้ายกัน แต่ละส่วนดูน่าเชื่อถือ แต่ทั้งเอกสารกลับให้ความรู้สึกแปลก ๆ มนุษย์ดูเหมือนยังทำ การให้เหตุผลระดับสูง ที่ LLM ยังทำไม่ได้ แม้จะช้ากว่าในงานรายละเอียดก็ตาม ถ้าบอกข้อบกพร่องให้ มันจะตอบว่า “ถูกต้องทั้งหมด” แต่ตอนตรวจเองกลับหาไม่เจอ
งานสร้างแอป CRUD ง่าย ๆ ด้วย JS framework ทั่วไป, Tailwind, ORM น่าจะทำได้สบาย แต่ก่อนหน้านี้ก็มี SaaS template ให้ซื้ออยู่แล้ว และ boilerplate เชิงพาณิชย์ที่ทำด้วยมืออย่างดีมีแนวโน้มจะดีกว่าผลลัพธ์จาก vibe coding มาก
ใน PR ของคนอื่นก็เห็นบ่อยว่าปัญหาในพรอมป์ต์ถูกแก้แค่ผิวเผิน แต่ได้ implementation ที่ดูแลรักษาระยะยาวยาก ดังนั้นขั้นตอนการ implement และการออกแบบจึงตัดสินใจเอง แล้วทำงานเป็นขั้น ๆ กับโมเดลโอเพนซอร์สขนาดเล็กหรือ Claude 4.5·4.6 การสำรวจ API และการเขียน boilerplate เร็วขึ้นจนไวกว่าเขียนมือหลายเท่า โดยที่ความรู้ไม่เสื่อมและโค้ดเบสไม่พัง
AI เป็นชั้นใหม่ที่ซ้อนเพิ่มบน tech stack เหมือนที่ภาษาโปรแกรมระดับสูงอยู่เหนือภาษาเครื่อง ดังนั้นคงต้องปล่อยวางบ้าง
ไม่ได้แปลว่า AI ไม่มีประโยชน์ แต่ควรคิดเรื่อง requirement และการตรวจสอบขั้นสุดท้ายให้ลึกขึ้น และลดความเชื่อว่ากระบวนการจะรับประกันผลลัพธ์ที่มีคุณค่าได้เอง
อาจไม่ชอบเรื่องสีสันหรือ business logic ที่ยืดยาวและฟุ่มเฟือยเกินจำเป็น แต่ตอนนี้สิ่งสำคัญคือคู่สามีภรรยาใช้งานแล้วมีประโยชน์จริงหรือไม่ และผลลัพธ์ก็ค่อนข้างดี หลังจากนั้นค่อยออกแบบ UI ใหม่ตามรสนิยม ยืนยัน requirement ของ backend แล้วจึงเขียนใหม่ทั้งหมดตั้งแต่ต้นเพื่อให้ง่ายต่อการดูแลรักษาและขยายต่อ
ตระกูล Claude เด่นมากในการทำ prototype และค้นหา requirement และช่วยให้การกลับมาทำใหม่อย่างถูกต้องภายหลังง่ายขึ้น
เกณฑ์ตรวจสอบง่าย ๆ คือในช่วง 12·24·36 เดือน ที่ผ่านมา คุณได้เห็นผลิตภัณฑ์ใหม่ที่ยอดเยี่ยมหรือการปรับปรุงครั้งใหญ่ของผลิตภัณฑ์เดิมจริงหรือไม่ ผลิตภัณฑ์ใหม่ที่ยอดเยี่ยมที่ฉันได้ใช้มีแค่ LLM ที่ชอบเท่านั้น และห้องแล็บเหล่านั้นกลับยิ่งจ้างคนเพิ่มด้วย
ถ้าอีก 12 เดือนข้างหน้ายังไม่มีการปรับปรุง ก็คงจะยังมีคนพูดซ้ำว่า “LLM เพิ่งดีพอในเดือนกุมภาพันธ์ 2027 เอง ยังประเมินตอนนี้ไม่ได้”
https://news.ycombinator.com/item?id=49120097
อัปเดตความปลอดภัยล่าสุดของ Apple และประกาศความปลอดภัย Android เดือนมิถุนายนก็แก้ช่องโหว่จำนวนมหาศาลเช่นกัน หลายจุดเกิดจากภาษาไม่ปลอดภัยอย่าง C/C++ แต่ LLM เก่งกับงานแปลงที่นิยามชัดและมีโอกาสหลุดกรอบน้อย จึงมีประโยชน์ต่อการย้ายไปใช้ภาษาแบบปลอดภัยอย่าง Rust ด้วย
ในวงการแพทย์ จำนวนผลิตภัณฑ์ก็พุ่งขึ้นมากเช่นกัน คุณภาพมีทั้งดีและไม่ดีปะปนกัน แต่จะบอกว่าไม่มีผลลัพธ์อะไรเลยนั้นผิดอย่างเป็นกลาง
ถ้าผลิตภัณฑ์ทำงานได้แล้ว แนะนำให้ลองขอว่า “ช่วยตรวจดูว่าโค้ดเบสนี้พร้อมสำหรับ production หรือยัง และ ถึงมาตรฐานที่จะขายได้ในราคา 1 ล้านดอลลาร์หรือไม่” แล้วมันจะเผยให้เห็นว่า AI ยังห่างไกลจากระดับที่อ้างไว้ก่อนหน้า กลายเป็น ‘million-dollar prompt’ ที่ทำให้รู้ว่าถูกหลอกไปมากแค่ไหน
https://news.ycombinator.com/item?id=18442941
ได้ลองใช้ LLM สองแบบ แบบแรกคือทำ vibe coding ด้วย Opus 4.6 และแบ็กเอนด์ Node เพื่อสร้างปลั๊กอินที่ส่งการแจ้งเตือนไปยังช่อง Slack ตามลำดับเวรของคน และตัวจับเวลาเวลาพูดแยกตามผู้เข้าร่วม Google Meet เป็นเครื่องมือภายในจึงแม้จะไม่ได้เข้าใจการทำงานทั้งหมดก็ยังรันบน GCP ได้ไม่มีปัญหา และลดค่าเครื่องมือ Slack จากเดิมคนละ 20 ดอลลาร์ต่อเดือนเหลือค่าโครงสร้างพื้นฐานรวมเพียง 0.07 ดอลลาร์ต่อเดือน
ไม่ได้ทำเสร็จในครั้งเดียว แต่ผ่านการวางแผนละเอียด การลงมือทำทีละขั้น และการเพิ่มการทดสอบ แบบที่สอง สำหรับผลิตภัณฑ์ระยะยาว ทีมจะออกแบบและทบทวนสถาปัตยกรรมก่อน แล้วสร้างตั๋ว JIRA แบบละเอียดส่งให้ Opus
ให้โมเดลจัดทำแผนการพัฒนา และอนุญาตให้เขียนโค้ดได้ก็ต่อเมื่อวิศวกรอนุมัติแล้วเท่านั้น
วิธีแรกเหมาะกับ MVP หรือ proof of concept ที่ต้องทำเร็ว แต่ถ้าเป็นผลิตภัณฑ์ระยะยาว ควรทิ้ง MVP ไป วางแผนเรื่องการขยายระบบและสถาปัตยกรรมที่สะอาดตั้งแต่ต้น แล้วใช้ LLM เป็น ผู้ปฏิบัติงานเขียนโค้ด เท่านั้น LLM ยังอ่อนในการตัดสินสถาปัตยกรรมที่มนุษย์จะดูแลรักษาระยะยาวได้ และการตัดสินว่าโค้ดสะอาดหรือไม่
เกณฑ์ตัดสินคือ การเสพสิ่งที่ AI สร้างขึ้นนั้นน่าเพลิดเพลินหรือไม่ ไม่ว่าจะเป็นบทความ วิดีโอ เสียง เมนูร้านอาหาร รูปเสื้อผ้า เอกสาร การควบคุมการบินโฆษณา ล้วนไม่น่าเพลิดเพลิน และมองว่า LLM มีคุณค่าในฐานะเสิร์ชเอนจินที่ดีขึ้นหรือเครื่องมือถามตอบ
หากท้ายที่สุด AI ทำได้ถึงเกณฑ์นั้น สิ่งที่มันสร้างจะครองตลาดเหนือของทำมือ และสินค้า-บริการที่มนุษย์ทำเองอาจเหลือให้ซื้อได้เฉพาะในราคาที่แพงกว่ามาก เหมือนงานหัตถกรรมในปัจจุบัน
จะมีงานจำนวนมากที่ต้องมาจัดระเบียบผลลัพธ์จาก vibe coding ของบริษัทอื่นแล้วทำให้กลายเป็นระบบที่ใช้งานได้จริง มูลค่าของแต่ละโปรเจกต์อาจลดลง แต่จำนวนจะเพิ่มขึ้น และมีโอกาสสูงที่จะทำงานไม่ถูกต้องหากไม่มีคนช่วย
มีบริษัทที่ไม่มีวิศวกรซอฟต์แวร์ ใช้ Claude Code ทำงานนอกเหนือจากธุรกิจหลัก แต่ก็ยังอยากให้พนักงานทำงานที่จ้างมา มากกว่าจะมานั่งง่วนกับโค้ด
เมื่อการทำของเฉพาะทางง่ายขึ้น ผลิตภัณฑ์แบบพิมพ์เดียวกันหมด จะยิ่งขายยาก แต่การส่งมอบผลลัพธ์ที่ปรับให้เหมาะจริงยังต้องใช้แรงงานอีกมาก คนที่มีทั้งประสบการณ์สร้างเองโดยตรงและมีความรู้ในโดเมนงานนั้นจะได้เปรียบเป็นสองเท่า
โดยทั่วไปคนไม่รู้ว่าตัวเองต้องการอะไร ดังนั้นแก่นของงานที่ปรึกษาในการค้นหาความต้องการและส่งมอบสิ่งนั้นยังคงเดิม และเมื่อซอฟต์แวร์ราคาถูกลง ก็สามารถรับลูกค้าได้มากขึ้น
ตรรกะพื้นฐานของบทความนี้มีข้อบกพร่อง ถ้ายังมีงานต้องทำต่อหลังจากสร้างต้นแบบแล้ว ก็แค่ทำงานนั้นต่อไปได้ ดูเหมือนกำลังเหมารวมการใช้ AI ว่าเท่ากับการสร้างทุกอย่างในครั้งเดียวด้วยพรอมป์ต์สี่บรรทัด และใกล้เคียงกับการหาเหตุผลเข้าข้างตัวเองแบบไม่วิจารณ์มากกว่าจะเป็นข้อสังเกตเชิงลึก
ต่อให้ไม่มีพื้นฐานวิศวกรรมก็รู้สึกได้โดยสัญชาตญาณว่ามันจริง และเคยเจอหลายครั้งตอนทำเกมไพ่ ตอนแรกทำได้ดี แต่เพราะดึงไลบรารีไพ่มาตรฐาน 52 ใบมาใช้ จึงเพิ่ม ไพ่เหตุการณ์พิเศษ ไม่ได้ และสุดท้ายต้องการโมเดลข้อมูลที่ยืดหยุ่นซึ่งอิงกับออบเจ็กต์การ์ด
ถ้ารู้ตั้งแต่แรกก็คงแก้ได้ แต่ถ้ามองซอฟต์แวร์เป็นของใช้แล้วทิ้ง และไม่ได้คิดลึกเรื่องการพัฒนาแบบวิศวกรมากประสบการณ์ ก็จะนึกไม่ถึงความต้องการแบบนั้น ปัญหาของบทความและโค้ดที่ AI สร้างคือมันดึงเอากระบวนการคิดที่ฝังอยู่ในขั้นตอนการสร้างออกไป
อย่างไรก็ตาม ไม่ใช่ว่าซอฟต์แวร์ทุกชิ้นต้องมีการขยายระบบ ความเร็ว และการบำรุงรักษาได้ดี มันจำเป็นกับโครงสร้างพื้นฐานและแอปที่คนหลายล้านจะใช้ แต่แอปวางแผนมื้ออาหารสำหรับครอบครัวไม่จำเป็นต้องรองรับการตั้งค่าภูมิแพ้ของพนักงาน Google หลายหมื่นคน
AI ทำให้ซอฟต์แวร์กลายเป็น เครื่องมือแบบกับข้าวทำเองที่บ้าน ได้ กับข้าวทำเองไม่จำเป็นต้องเป็นอาหารที่สมบูรณ์แบบ แค่เลี้ยงคนในครอบครัวได้ และเป็นของขวัญแห่งความใส่ใจจากใครสักคนก็พอ
ถ้าผลิตภัณฑ์สร้างได้จากการขอเพียงครั้งเดียว บริษัทเอาต์ซอร์สก็คงครองตลาดบริษัทผลิตภัณฑ์ไปนานแล้ว ส่วนสำคัญของการพัฒนาผลิตภัณฑ์เกิดขึ้นใน งานวนซ้ำหลังต้นแบบ·MVP ช่วงแรก
ไม่ใช่แค่เรื่องเทคนิค แต่ต้องขุดปัญหาเดิมอยู่นานพอจนเข้าใจรากของความเจ็บปวด และแก้มันทั้งในด้านประสบการณ์ผู้ใช้และด้านเทคนิค สมัยก่อนก็สามารถ “พรอมป์ต์” บริษัทเอาต์ซอร์สให้ทำผลิตภัณฑ์ได้เหมือนกัน แต่เหตุผลที่ยังยอมจ่ายให้บริษัทผลิตภัณฑ์ซึ่งคุยกับลูกค้ามาหลายปีและสั่งสมความเชี่ยวชาญ ก็อยู่ตรงนี้
ชื่อบทความที่สรุปประเด็นได้ดีกว่าคือ The Prototype Isn't the Product งานประเภทต้นแบบใช้แล้วทิ้งและแอปใช้ส่วนตัวที่แค่ “พอใช้ได้เป็นส่วนใหญ่” สามารถทำด้วย AI ได้เร็วอย่างน่าทึ่ง แต่ซอฟต์แวร์วิศวกรรมที่คุณภาพและการบำรุงรักษาสำคัญยังคงยากและช้า
มีเดโม vibe coding หวือหวาอยู่มาก แต่มีการพูดถึงน้อยว่า AI มีประโยชน์แค่ไหนกับ legacy codebase ขนาดใหญ่ หรืองานวิชาชีพทั่วไปที่ไม่หวือหวาในชีวิตประจำวัน
เราไม่โดนโทรปลุกตอนหกโมงเช้าวันอาทิตย์เพราะต้นแบบเกม 3D ที่ vibe coding ไว้หยุดทำงาน แต่ถ้าเกิดบั๊กใน ระบบที่ต้องเดินตลอด 24 ชั่วโมง ซึ่งเพิ่งอัปเดตไป ก็ต้องรับโทรศัพท์แน่นอน