วิธีทำ Vibe coding อย่างมีความรับผิดชอบในสภาพแวดล้อมโปรดักชัน - Vibe coding in prod | Code w/ Claude

นี่คือการบรรยายที่ Eric นักวิจัยด้าน coding agent ของ Anthropic อธิบายว่าควรนำ vibe coding (แนวทางที่มอบหมายให้ AI เขียนโค้ดแทบทั้งหมด) ไปใช้ในสภาพแวดล้อมของบริการจริงอย่างปลอดภัยได้อย่างไร โดยชี้ว่า vibe coding นั้นต่างจากการใช้ AI สร้างโค้ดจำนวนมากแบบผิวเผิน และตามคำนิยามของ Andrej Karpathy แก่นสำคัญคือ “ลืมไปเลยว่ามีโค้ดอยู่” สถานการณ์ตอนนี้คือขนาดของงานที่ AI จัดการได้กำลังเพิ่มขึ้นเป็นสองเท่าทุก 7 เดือน และถ้าใช้กระแสนี้ไม่เป็นก็มีแต่จะตามการแข่งขันไม่ทัน

ข้อเสนอหลัก

• หลักการของ vibe coding คือ “ลืมโค้ด แต่อย่าลืมผลิตภัณฑ์” เช่นเดียวกับที่เราไม่ได้อ่าน assembly ที่คอมไพเลอร์สร้างขึ้นทีละบรรทัด เขามองว่าควรโฟกัสที่การตรวจสอบคุณภาพและความถูกต้องของผลลัพธ์ มากกว่าตัวโค้ดที่ AI เขียน
• บทบาทของนักพัฒนาควรเปลี่ยนจากผู้ลงมือ implement เอง ไปเป็น product manager (PM) ของ Claude เหมือนเวลามอบงานให้วิศวกรมือใหม่ การรวบรวม requirement บริบทของ codebase และข้อจำกัดต่าง ๆ เพื่อส่งต่อให้ AI แม้จะใช้เวลา 15–20 นาทีขึ้นไป ก็เป็นการลงทุนที่ช่วยเพิ่มโอกาสสำเร็จได้มาก
• vibe coding ควรโฟกัสกับ leaf node ของ codebase (ฟังก์ชันปลายทางที่ไม่มีโค้ดอื่นพึ่งพา) ส่วนโค้ดแกนหลักอย่างสถาปัตยกรรมสำคัญหรือโค้ดฐานที่โมดูลอื่นต้องพึ่งพา ยังจำเป็นต้องให้มนุษย์เข้าใจเชิงลึกและดูแลเอง
• การออกแบบให้ตรวจสอบได้เป็นสิ่งจำเป็น จากกรณีภายใน Anthropic ที่ใช้ Claude เขียนโค้ด reinforcement learning ขนาด 22,000 บรรทัดแล้ว merge เข้าสู่โปรดักชันจริง พวกเขาออกแบบ stress test และ checkpoint สำหรับการตรวจสอบตามอินพุต/เอาต์พุต เพื่อยืนยันเสถียรภาพและความถูกต้องได้โดยไม่ต้องอ่านโค้ดทั้งหมด

ข้อจำกัดในปัจจุบัน

• หนี้เทคนิค (tech debt) ยังไม่มีวิธีที่ดีพอในการวัดหรือยืนยันโดยไม่อ่านโค้ดโดยตรง นี่คือเหตุผลใหญ่ที่สุดที่ทำให้ vibe coding ควรถูกจำกัดไว้กับ leaf node
• การที่คนที่ไม่ใช่นักพัฒนาใช้ vibe coding สร้างระบบโปรดักชันในส่วนที่อ่อนไหวอย่าง security หรือ payment นั้นมีความเสี่ยง จำเป็นต้องมีวิจารณญาณทางเทคนิคเพื่อจะตั้งคำถามที่ถูกต้องได้

จุดที่แตกต่าง

• เนื้อหานี้วางกรอบให้ vibe coding ไม่ใช่แค่กระแสชั่วคราว แต่เป็นการเปลี่ยนผ่านเชิงโครงสร้างของอุตสาหกรรมซอฟต์แวร์ และชี้ให้เห็นว่าปัญหาแบบ “ไม่รู้รายละเอียดการ implement แต่ยังต้องตรวจสอบผลลัพธ์ให้ได้” เป็นโจทย์ที่มีมานานพอ ๆ กับอารยธรรม ไม่ต่างจาก CTO ที่ต้องบริหารผู้เชี่ยวชาญ หรือ CEO ที่ต้องตรวจสอบงานของนักบัญชี

นัยสำคัญ

• ทักษะที่คาดหวังจากวิศวกรซอฟต์แวร์กำลังเปลี่ยนจากความสามารถในการเขียนโค้ดทีละบรรทัด ไปสู่ความสามารถในการกำหนด requirement ให้แม่นยำและตรวจสอบผลลัพธ์อย่างเป็นระบบ เมื่อพิจารณาความเร็วในการพัฒนาความสามารถของเครื่องมือ AI ยิ่งปรับตัวกับการเปลี่ยนผ่านนี้ได้เร็วเท่าไร ก็ยิ่งได้เปรียบมากขึ้นเท่านั้น

[iolothebard]

อย่าไปพูดเรื่องนั้นกับนักพัฒนาระดับล่างเลย ไปพูดกับพวกผู้บริหารระดับ C โน่น~~~

[supermaxi]

ตอนนี้พวกเราทุกคนก็เป็น PM กันหมดแล้ว