วิธีสร้างด้วย AI 2 แบบ
ตอนนี้ทุกทีมที่สร้างด้วย AI มักมี “ข้อถกเถียง” แบบเงียบๆ แฝงอยู่ และโดยมากมันไม่ได้ปรากฏเป็นการโต้เถียง แต่เป็นความรู้สึกมากกว่า คนหนึ่งส่งแอปที่ใช้งานได้จริงในเวลาแค่บ่ายวันเดียว โดยแค่บอกว่าต้องการอะไรและยอมรับทุกอย่างที่โมเดลผลิตออกมา อีกคนยืนยันที่จะอ่านทุกบรรทัด เขียนเทสต์ และทำความเข้าใจว่าของสิ่งนั้นทำงานอย่างไร ทั้งสองกำลังใช้เครื่องมือชุดเดียวกัน เพียงแต่กำลังเล่นเกมคนละแบบอย่างมากเท่านั้น
ตอนนี้เกมทั้งสองมีชื่อแล้ว สไตล์ที่เร็ว ยืดหยุ่น แบบบรรยายแล้วรับมาเลย เรียกว่า vibe coding ส่วนสไตล์ที่รอบคอบ เป็นระบบ และสร้างระบบที่เชื่อถือได้รอบตัวโมเดล ใกล้เคียงกับสิ่งที่ผู้คนหมายถึงเมื่อพูดถึง agentic engineering มันชวนให้มองว่าเป็นการต่อสู้ โดยฝ่ายหนึ่งแทนความเร็ว อีกฝ่ายแทนความเคร่งครัด และคอยเลือกทีม แต่กรอบแบบนั้นพลาดประเด็น พวกมันไม่ใช่คู่แข่งกัน พวกมันคือเครื่องมือคนละแบบสำหรับช่วงเวลาที่ต่างกัน และทักษะที่แท้จริงคือการรู้ว่าคุณกำลังถือ “อันไหน” อยู่
ความสับสนนี้คุ้มค่าแก่การเคลียร์ เพราะเดิมพันกำลังเพิ่มขึ้นอย่างรวดเร็ว ซอฟต์แวร์จำนวนมากขึ้นเรื่อยๆ ถูกเขียนด้วยความช่วยเหลือหนักจากโมเดล และนิสัยที่คนเราสร้างขึ้นตอนนี้จะเป็นตัวกำหนดว่าเราจะต่อยอดซอฟต์แวร์นั้นได้ หรือมันจะกลายเป็นกองโค้ดที่ไม่มีใครเข้าใจ ด้วยการแยกให้ถูก AI จะทำให้คุณเร็วขึ้นในทุกอย่าง ทั้งการทดลองแบบโยนทิ้ง และระบบจริงจังด้วย ถ้าแยกผิด คุณจะได้แต่ไต่คลำไปตามโปรโตไทป์ที่ไม่ควรได้รับความใส่ใจ หรือสุดท้ายก็ “ปล่อย” ระบบโปรดักชันที่ถูกประกอบไว้ด้วยการเดา
บทความนี้พาไล่ไปตั้งแต่ต้นจนจบ: โหมดแต่ละแบบจริงๆ คืออะไร ทำไม vibe coding ถึงชวนหลงใหล แต่ละแบบเหมาะอยู่ตรงไหน วิธีแยกพวกมันออกจากกันในขณะนั้น และวิธีใช้ทั้งสองแบบโดยไม่หลอกตัวเองว่างานที่กำลังทำเรียกร้องให้ใช้แบบไหน ระหว่างทางมีตารางเปรียบเทียบ มีเช็กลิสต์ตัดสินใจแบบเร็วไม่กี่ขั้น มีสถานการณ์จริงหลายแบบ และเช็กลิสต์อีกสองชุดที่คุณเก็บไว้ใช้ได้
Vibe coding คืออะไร
คำว่า vibe coding มาจาก Andrej Karpathy ผู้เล่าวิธีทำงานแบบใหม่ ที่คุณเอนตัวเข้าไปหาโมเดลเต็มที่ คุยกับมันด้วยภาษาธรรมดา ยอมรับข้อเสนอของมันโดยไม่ไปกังวลกับรายละเอียดมากนัก และแทบลืมไปเสียด้วยซ้ำว่าโค้ดนั้นมีอยู่ คุณไม่ได้อ่าน diff คุณแค่ “ขี่” อารมณ์ (vibe)
ลองนึกภาพว่าหนึ่งเซสชันหน้าตาเป็นอย่างไร คุณเปิดแชทหรือเปิดเอเจนต์ คุณอธิบายสิ่งที่ต้องการ แล้วโค้ดก็ปรากฏ คุณรันมัน มีบางอย่างผิดไป จึงวางข้อความ error กลับไปหาโมเดล แล้วขอให้แก้ไข โค้ดชุดใหม่ก็ปรากฏ คุณไม่ได้อ่านมันอย่างละเอียด อาจไม่ได้อ่านเลยด้วยซ้ำ คุณรันมันอีกครั้ง มันได้ผล หรือได้ผลพอ แล้วคุณไปทำฟีเจอร์ถัดไป ทำแบบเดิม วนลูปนี้เร็วมากและเหมือนคุยกันไปมาแทบตลอดเวลา และในทุกจังหวะคุณไม่ได้หยุดเพื่อสร้างภาพในหัวว่ามันเชื่อมเข้าด้วยกันอย่างไร โมเดล “ถือ” แบบนั้นไว้ หรือพูดให้ตรงกว่า ไม่มีใครถือมันอยู่
ใครก็ตามที่เคยทำแบบนี้ย่อมรู้ว่าทำไมมันถึงติดใจคน มันสนุกและน่าพึงพอใจจริงๆ คุณขยับได้ด้วยความเร็วของความคิด แรงเสียดทานระหว่างไอเดียกับโปรโตไทป์ที่กำลังรันแทบหายไป และคุณสร้างสิ่งที่คุณคงไม่มีความอดทนจะทำด้วยมือได้เลย คนที่แทบจะเขียนสคริปต์ไม่ได้เลย ตอนนี้ลุกขึ้นมายืนทำแอปเว็บที่ใช้งานได้แล้ว วิศวกรที่มีประสบการณ์สามารถลองได้ห้าวิธีภายในเวลาที่เมื่อก่อนใช้แค่เตรียมระบบหนึ่งอย่าง สำหรับโปรเจกต์วันหยุด การทดลองเร็วๆ หรือเครื่องมือที่คุณจะไปแตะเพียงคนเดียว มันให้ความรู้สึกเหมือนมีพลังพิเศษ และก็เกือบจะเป็นจริง
แต่คุณสมบัติที่กำหนดไม่ใช่แค่ความเร็ว มันคือการยอมแพ้ ใน vibe coding คุณยกมอบทั้ง “การพิมพ์” และ “ความเข้าใจ” คุณเชื่อว่าโค้ดทำงานได้เพราะมันดูเหมือนจะทำงาน และคุณไม่ได้แคร์มากนักว่าทำงานยังไง นี่คือการแลกที่ทำให้มันเร็ว และนี่แหละคือจุดเริ่มต้นของปัญหา ถือคำว่า “การยอมแพ้” ไว้ให้ดี เพราะเกือบทุกอย่างที่ดีหรือไม่ดีเกี่ยวกับ vibe coding ล้วนไหลมาจากมัน
ทำไมมันถึงรู้สึกดีเหลือเกิน
ก่อนจะไปถึงจุดที่ vibe coding ไปผิดทาง มันควรพิจารณาอย่างจริงจังว่าทำไมคนที่มีความสามารถจำนวนมากถึงตกลงไปในนั้น เพราะแรงดึงดูดมันมีจริง และการแกล้งทำเป็นไม่จริงนั้นไร้ประโยชน์
เหตุผลข้อแรกก็แค่ความเร็ว และความเร็วก็เสพติดได้ มีความสุขแบบเฉพาะตัวในการบรรยายอะไรสักอย่างแล้วเห็นมันเกิดขึ้นเพียงชั่วครู่ และความสุขนั้นไปขูดเหมือน “อาการคัน” แบบเดียวกับที่ทำให้งานครั้งก่อนๆ สนุกอยู่แล้ว การเขียนโค้ดด้วยมือมีช่วงที่เสียดสีกันยาวๆ เสมอ: boilerplate, การตั้งค่า, การไปค้นหาอินเทอร์เฟซที่คุณใช้มาร้อยครั้งแล้ว Vibe coding ทำให้แรงเสียดสีแทบหายไป และการไม่มีแรงเสียดสีให้ความรู้สึกเหมือนบินได้
เหตุผลข้อที่สองคือ “ลูปการตอบกลับ” ขอเล็กๆ แต่ได้ผลลัพธ์ที่มองเห็นได้เร็ว และผลลัพธ์ที่เห็นได้เร็วคือสิ่งที่กระตุ้นสมองได้มากที่สุดแบบหนึ่ง มันเป็นลูปเดียวกับที่ทำให้เกมติดขึ้น และเติมเชื้อให้การเสพติดแบบบังคับ You ask, you receive แล้วคุณก็ ask อีก แล้วหนึ่งชั่วโมงก็หายไป ลูปนี้น่าพึงพอใจจนการหยุดเพื่ออ่านโค้ดเหมือนเป็นการขัดจังหวะ เหมือนหยุดวิ่งที่กำลังดีเพื่อไปเช็กฟอร์มของตัวเอง
เหตุผลข้อที่สามคือเดโม ซอฟต์แวร์ส่วนใหญ่มีแรงกดดันหลักๆ ที่ต้อง “โชว์ความคืบหน้า” และโปรโตไทป์ที่ทำด้วย vibe coding โชว์ความคืบหน้าได้สวยงามมาก มันดูเหมือนเสร็จแล้ว มันคลิกและตอบสนอง และทำให้คนประทับใจในที่ประชุม ช่องว่างระหว่าง “ดูเหมือนเสร็จ” กับ “เสร็จจริงๆ” มองไม่เห็นจากภายนอก และปัญหาที่มองไม่เห็นก็ไม่สร้างความเร่งด่วน ดังนั้นแรงจูงใจจึงให้รางวัลอย่างเงียบๆ กับสิ่งที่ดูเสร็จ มากกว่าสิ่งที่ทำงานได้อย่างถูกต้อง และทีมก็ไหลไปทาง vibe coding โดยไม่เคยตัดสินใจอย่างชัดเจน
ทั้งหมดนี้ไม่ได้เป็นข้อบกพร่องด้านนิสัยของตัวละคร มันเป็นผลตอบสนองแบบมีเหตุผลต่อแรงจูงใจที่เป็นจริง และเป็นประสบการณ์ที่ดีกว่าจริงๆ เป้าหมายของการตั้งชื่อมันไม่ใช่เพื่อรู้สึกเหนือกว่า มันคือการสังเกตแรงดึงดูดเพื่อจะได้ตัดสินใจต่อต้านเมื่อถึงเวลา แทนที่จะถูกพาไปด้วยความรู้สึกที่คุณไม่เคยตรวจสอบ
Agentic engineering คืออะไร
Agentic engineering คือท่าทีอีกแบบ มันก็พึ่ง AI อย่างหนักเช่นกัน บ่อยครั้งมากกว่า vibe coding เพราะมันเอาโมเดลเข้าไปอยู่ในระบบจริงที่สามารถลงมือทำได้ด้วยตัวเอง ความต่างไม่ใช่ว่าคุณใช้ AI มากแค่ไหน แต่คือคุณ “ยังคุม” ได้มากน้อยแค่ไหนในสิ่งที่ AI ผลิตออกมา
วิศวกรปฏิบัติต่อผลลัพธ์ที่ได้จากโมเดลในแบบเดียวกับที่ผู้ตรวจงานอย่างรอบคอบปฏิบัติต่อ pull request ที่มั่นใจของจูเนียร์ งานอาจจะยอดเยี่ยม แต่เป็นเพียงฉบับร่างที่ต้องตรวจสอบ ไม่ใช่ความจริงที่ควรยอมรับ ในทางปฏิบัติ นี่จะกลายเป็นชุดนิสัยที่เป็นรูปธรรมไม่กี่อย่าง มีการทดสอบ เพื่อพฤติกรรมที่คุณใส่ใจถูกล็อกไว้ และการเปลี่ยนแปลงในอนาคตจะไม่ทำให้มันพังอย่างเงียบๆ มีวิธีดูว่า “ระบบทำอะไรไปและทำไม” เพื่อเวลามีอะไรผิดพลาด คุณจะตามรอยได้แทนที่จะต้องเดา มีข้อจำกัดว่าระบบแตะต้องอะไรได้บ้าง และมีจุดที่ชัดเจนว่ามนุษย์จะลงนามรับรองก่อนที่จะเกิดอะไรที่แพงหรือย้อนกลับไม่ได้ และเมื่อสิ่งนั้นเกี่ยวข้องกับ autonomous agent ก็จะมีการ evals ซึ่งเป็นชุดเทสต์ที่ทำซ้ำได้เพื่อพิสูจน์ว่าทั้งหมดยังทำหน้าที่ได้จริงในเคสที่สำคัญ เพราะเอเจนต์ที่ทำได้ครั้งเดียวในการเดโม บอกคุณได้เกือบไม่มีอะไรเลยว่ามันจะทำได้จริงหรือไม่
เหนือสิ่งอื่นใดคือความเข้าใจ มีคนที่รู้ว่าสิ่งนั้นทำงานอย่างไร และแก้ได้เมื่อมันพัง เข้าใจขอบเขตของมันได้ อธิบายให้เพื่อนร่วมงานได้ว่าทำไมมันถูกสร้างแบบนี้ ความเข้าใจถูกมองเป็น “เดลิเวอริเอเบิล” ในตัวของมันเองพอๆ กับโค้ดที่กำลังรัน เพราะระบบที่ไม่มีใครเข้าใจคือระบบที่ล้มเหลวอยู่แล้ว เพียงแต่ยังไม่ทันสังเกต มันยังไม่ “เห็น” เท่านั้น
ถ้า vibe coding คือการยอมตาม vibe วิศวกรรมก็คือการปฏิเสธมัน มันรักษานิสัยเดียวที่ vibe coding โยนทิ้งไป นั่นคือการตรวจสอบและทำความเข้าใจก่อนจะเชื่อ นิสัยเดียวนี้คือความต่างทั้งหมด และคุ้มค่าที่จะมองตรงๆ
มันเป็นสเปกตรัม ไม่ใช่ไบนารี
ก่อนจะไปต่อ มันช่วยทิ้งความคิดที่ว่ามีแค่สองตัวเลือก Vibe coding และ full engineering คือปลายสุดของช่วง และงานจริงส่วนใหญ่ไปอยู่ที่ไหนสักแห่งระหว่างนั้น
ที่ปลายสุดด้านซ้ายคือ vibe coding แบบล้วนๆ คุณรับสิ่งที่โมเดลให้มาและไม่อ่านมันเลย ขั้นถัดจากนั้นคือสิ่งที่คนส่วนใหญ่ทำกันแทบตลอดเวลา AI-assisted ที่โมเดลเขียน แล้วคุณตรวจดู diff ทุกส่วนก่อนจะยอมรับ มันคล้ายกับการทบทานานานานานานานานานานานานานานาผลงานของเพื่อนร่วมทีม ต่อไปอีกก็คือแนวทางที่เป็นระเบียบกว่า Spec-driven คุณเขียนให้ชัดว่าโค้ดต้องทำอะไร ปล่อยให้โมเดลไปลงมือ แล้วค่อยตรวจการทำงานเทียบกับสเปกด้วยเทสต์ และที่ปลายสุดด้านขวาคือ agentic engineering แบบเต็มรูปแบบที่โมเดลถูกถักทอเข้าไปในระบบพร้อม evals การมองเห็นสถานะ (observability) และ guardrails ทั้งระบบถูกปฏิบัติเป็นซอฟต์แวร์โปรดักชันที่ “ทำด้วย AI หนักๆ”
เมื่อคุณขยับจากซ้ายไปขวา คุณแลกความเร็วดิบๆ กับการคุมได้ ความเข้าใจ และความทนทาน ทุกข้อไม่ใช่คำตอบที่ถูกต้อง “โดยทั่วไป” ความผิดพลาดของคนส่วนใหญ่ไม่ใช่การเลือกจุดผิด แต่ไม่ใช
