ไวบ์เอนจิเนียริง

• "Vibe Engineering" คือชื่อเรียกใหม่ของแนวทางการพัฒนาระดับมืออาชีพที่ใช้ เครื่องมือ AI สำหรับการเขียนโค้ด โดยต่างจาก 'vibe coding' ที่รวดเร็วแต่ขาดความรับผิดชอบ แนวทางนี้หมายถึง การที่วิศวกรผู้ชำนาญใช้ LLM โดยยังคงรักษาคุณภาพโค้ดและความรับผิดชอบ
• การมาถึงของ coding agent อย่าง Claude Code, OpenAI Codex CLI และ Gemini CLI ทำให้การใช้ LLM ในโปรเจกต์งานจริงเพิ่มขึ้นอย่างมาก และวิศวกรบางคนถึงกับ รันหลายเอเจนต์พร้อมกันเพื่อทำงานแบบขนาน
• หากต้องการใช้ LLM อย่างมีประสิทธิภาพ จำเป็นต้องมีแนวปฏิบัติด้านซอฟต์แวร์เอนจิเนียริงระดับสูงที่วางรากฐานไว้แล้ว เช่น การทดสอบอัตโนมัติ การวางแผนล่วงหน้า เอกสารที่ครอบคลุม การควบคุมเวอร์ชัน และวัฒนธรรม code review
• เครื่องมือ AI มีคุณสมบัติในการ ขยายศักยภาพของความเชี่ยวชาญที่มีอยู่เดิม ยิ่งวิศวกรระดับอาวุโสมีทักษะและประสบการณ์มากเท่าไร ก็ยิ่งใช้ LLM เพื่อให้ได้ผลลัพธ์ที่เร็วและดีกว่าเดิมได้มากขึ้น
• คำนี้เน้นให้เห็นว่าเป็น วิธีใช้ AI เพื่อพัฒนาซอฟต์แวร์ production ที่ยากและซับซ้อนกว่า ผ่านการแยกความหมายจาก 'vibe coding' อย่างชัดเจน และการจับคู่คำที่ดูขัดแย้งกันระหว่าง engineering กับ vibe ก็กลับช่วยให้จดจำได้ง่าย (ตอกย้ำการเปลี่ยนแปลงของกระบวนการพัฒนาจากความก้าวหน้าของเครื่องมือ AI และความสำคัญของความเชี่ยวชาญ)

---

การแยกความต่างระหว่าง vibe coding กับ vibe engineering

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

การมาถึงและผลกระทบของ coding agent

• การปรากฏตัวของ เครื่องมือ coding agent อย่าง Claude Code ที่ออกในเดือนกุมภาพันธ์ 2025, OpenAI Codex CLI ที่ออกในเดือนเมษายน และ Gemini CLI ที่ออกในเดือนมิถุนายน ทำให้ประโยชน์ของ LLM ต่อปัญหาการเขียนโค้ดจริงเพิ่มขึ้นอย่างมาก
  • เครื่องมือเหล่านี้ทำงานโดยแก้ไขโค้ดซ้ำ ๆ และทดสอบอย่างจริงจังจนกว่าจะบรรลุเป้าหมายที่กำหนด
• วิศวกรซอฟต์แวร์ที่มีประสบการณ์สูงและเชื่อถือได้กำลัง รันหลายเอเจนต์พร้อมกัน เพื่อจัดการหลายปัญหาแบบขนานและขยายขอบเขตของงาน
  • ผู้เขียนเองตอนแรกก็สงสัย แต่หลังจากลองรัน parallel coding agent ด้วยตัวเองแล้วก็พบว่า แม้จะทำให้ล้าทางความคิด แต่ได้ผลอย่างน่าทึ่ง
• แม้คอลเลกชันส่วนใหญ่ใน tools.simonwillison.net จะถูกสร้างขึ้นด้วยแนวทาง vibe coding แบบดั้งเดิม แต่การทำงานวนซ้ำร่วมกับ coding agent เพื่อสร้าง โค้ดคุณภาพระดับ production ที่ดูแลรักษาได้ในอนาคต ให้ความรู้สึกว่าเป็นกระบวนการที่ต่างออกไปโดยสิ้นเชิง

แนวปฏิบัติด้านซอฟต์แวร์เอนจิเนียริงเดิมที่ LLM ช่วยเสริมพลัง

• การทดสอบอัตโนมัติ: หากมี test suite ที่แข็งแรง ครอบคลุม และเสถียร เครื่องมือ agent coding ก็จะทำงานได้อย่างรวดเร็ว แต่หากไม่มีการทดสอบ เอเจนต์อาจอ้างว่าทดสอบแล้วทั้งที่จริงไม่ได้ทดสอบ หรือการเปลี่ยนแปลงใหม่อาจไปทำให้ฟังก์ชันที่ไม่เกี่ยวข้องพังได้
  • การพัฒนาแบบ test-first มีประสิทธิภาพเป็นพิเศษกับเอเจนต์ที่สามารถทำงานวนซ้ำในลูปได้
• การวางแผนล่วงหน้า: การเริ่มต้นด้วยแผนระดับสูงก่อนลงมือประกอบบางอย่างเข้าด้วยกันช่วยให้งานเดินได้ดีกว่ามาก และสิ่งนี้ยิ่งสำคัญขึ้นเมื่อทำงานกับเอเจนต์
  • สามารถทำซ้ำแผนก่อน แล้วค่อยส่งต่อให้เอเจนต์ไปเขียนโค้ดได้
• เอกสารที่ครอบคลุม: เช่นเดียวกับโปรแกรมเมอร์มนุษย์ LLM ก็สามารถเก็บบริบทของ codebase ได้เพียงบางส่วนในแต่ละครั้ง หากมีเอกสารที่เกี่ยวข้องให้ ก็สามารถใช้ API ของส่วนอื่นได้โดยไม่ต้องอ่านโค้ดก่อน
  • หากเขียนเอกสารที่ดีตั้งแต่แรก โมเดลก็อาจสร้าง implementation ที่สอดคล้องกับข้อมูลอินพุตนั้นได้โดยตรง
• นิสัยการควบคุมเวอร์ชันที่ดี: เมื่อ coding agent อาจเป็นผู้เปลี่ยนแปลงโค้ด ความสามารถในการย้อนความผิดพลาด และเข้าใจว่าสิ่งใดถูกเปลี่ยนเมื่อไรและอย่างไร ยิ่งสำคัญกว่าเดิม
  • LLM เก่งเรื่อง Git มาก ถึงขั้นสามารถไล่ดูประวัติเพื่อตามหาต้นตอของบั๊กได้ด้วยตัวเอง และใช้ git bisect ได้ดีกว่านักพัฒนาส่วนใหญ่
• ระบบอัตโนมัติที่มีประสิทธิภาพ: continuous integration, การจัดรูปแบบและ linting อัตโนมัติ, รวมถึง continuous deployment ไปยังสภาพแวดล้อม preview ต่างก็ช่วยเครื่องมือ agent coding ได้เช่นกัน
  • LLM ทำให้การเขียนสคริปต์อัตโนมัติแบบรวดเร็วเป็นเรื่องง่ายขึ้น ช่วยให้ทำงานเดิมซ้ำได้อย่างถูกต้องและสม่ำเสมอในครั้งถัดไป
• วัฒนธรรม code review: หากทำ code review ได้รวดเร็วและมีประสิทธิภาพ คุณจะมีประสบการณ์ที่ดีกว่ามากเมื่อทำงานกับ LLM
  • ถ้าคุณอยากเขียนโค้ดเองมากกว่าตรวจทานสิ่งเดิมที่คนอื่น (หรือบางสิ่งบางอย่าง) เขียนไว้ เรื่องนี้ก็คงยาก
• เทคนิคการบริหารจัดการในรูปแบบที่ประหลาดมาก: การจะได้ผลลัพธ์ที่ดีจาก coding agent นั้นมีความคล้ายอย่างน่าอึดอัดกับการจะได้ผลลัพธ์ที่ดีจากผู้ร่วมงานที่เป็นมนุษย์
  • ต้องให้คำสั่งที่ชัดเจน จัดให้มีบริบทที่จำเป็น และให้ feedback ที่นำไปลงมือทำได้กับผลงานที่ได้ออกมา
  • เหตุผลที่ง่ายกว่าการทำงานกับคนจริงมาก ก็คือไม่ต้องกังวลว่าจะไปดูหมิ่นหรือทำให้พวกเขาท้อใจ แต่ประสบการณ์ด้านการบริหารจัดการที่มีอยู่เดิมกลับมีประโยชน์อย่างน่าประหลาด
• manual QA ที่ยอดเยี่ยมจริง ๆ: นอกเหนือจากการทดสอบอัตโนมัติแล้ว ยังต้อง เก่งมากในการทดสอบซอฟต์แวร์ด้วยมือ รวมถึงการคาดการณ์และเจาะลึก edge case
• ทักษะการวิจัยที่แข็งแกร่ง: ปัญหาการเขียนโค้ดหนึ่ง ๆ มักมีวิธีแก้ได้เป็นสิบแบบ การระบุตัวเลือกที่ดีที่สุดและพิสูจน์แนวทางนั้นเป็นสิ่งสำคัญมาโดยตลอด และยังคงเป็นอุปสรรคก่อนจะปล่อยเอเจนต์ไปเขียนโค้ดจริง
• ความสามารถในการ deploy ไปยังสภาพแวดล้อม preview: เมื่อเอเจนต์สร้างฟีเจอร์เสร็จ หากมีวิธี preview ฟีเจอร์นั้นได้อย่างปลอดภัย (โดยไม่ต้อง deploy ขึ้น production ทันที) การรีวิวก็จะมีประสิทธิภาพขึ้นมาก และลดความเสี่ยงในการปล่อยของพังออกไปอย่างมาก
• สัญชาตญาณว่าอะไรควร outsource ให้ AI และอะไรควรทำเองด้วยมือ: สิ่งนี้ยังคงพัฒนาไปเรื่อย ๆ ตามที่โมเดลและเครื่องมือมีประสิทธิภาพมากขึ้น
  • ส่วนสำคัญของการทำงานกับ LLM อย่างมีประสิทธิภาพคือ การรักษาสัญชาตญาณที่แม่นยำว่าเมื่อใดมันเหมาะจะถูกนำมาใช้มากที่สุด
• ความสามารถในการประเมินเวลาที่อัปเดตแล้ว: การประเมินว่าโปรเจกต์จะใช้เวลานานเท่าไรเป็นหนึ่งในส่วนที่ยากที่สุดแต่สำคัญที่สุดของการเป็นวิศวกรอาวุโสมาโดยตลอด โดยเฉพาะในองค์กรที่การตัดสินใจด้านงบประมาณและกลยุทธ์ตั้งอยู่บนการประเมินเหล่านี้
  • การเขียนโค้ดด้วย AI ทำให้เรื่องนี้ยากขึ้นไปอีก เพราะสิ่งที่เคยใช้เวลานานกลับเร็วขึ้นมาก แต่ตอนนี้การประเมินต้องพึ่งพาปัจจัยใหม่ที่เราทุกคนยังพยายามทำความเข้าใจ

แก่นแท้และความหมายของ vibe engineering

• หากต้องการใช้ความสามารถของเครื่องมือใหม่เหล่านี้อย่างแท้จริง จำเป็นต้อง ทำงานในระดับสูงสุดของเกมนี้ ซึ่งรวมถึง
  • รับผิดชอบไม่ใช่แค่การเขียนโค้ด
  • การวิจัยแนวทาง
  • การตัดสินใจเชิงสถาปัตยกรรมระดับสูง
  • การเขียนสเปก
  • การกำหนดเกณฑ์ความสำเร็จ
  • การออกแบบ agent loop
  • การวางแผน QA
  • การบริหารกองทัพของเด็กฝึกงานดิจิทัลประหลาดที่ชอบพยายามหลอกเมื่อมีโอกาส และเพิ่มจำนวนขึ้นเรื่อย ๆ
  • รวมถึงการใช้เวลากับ code review อย่างมาก
• เกือบทั้งหมดนี้คือ คุณลักษณะที่เป็นของวิศวกรซอฟต์แวร์อาวุโสอยู่แล้ว
• เครื่องมือ AI ทำหน้าที่ ขยายศักยภาพของความเชี่ยวชาญเดิม และยิ่งคุณมีทักษะและประสบการณ์ในฐานะวิศวกรซอฟต์แวร์มากเท่าไร คุณก็ยิ่งทำงานกับ LLM และ coding agent เพื่อให้ได้ผลลัพธ์ที่เร็วและดีกว่าเดิมได้มากขึ้น

“Vibe engineering”, really? : ข้อคิดเกี่ยวกับการเลือกคำ

• ชื่อว่า "vibe engineering" ฟังดูงี่เง่าหรือไม่: ก็น่าจะใช่ และคำว่า "vibe" ในโลก AI ณ จุดนี้ก็ดูเริ่มน่าเหนื่อยหน่ายอยู่บ้าง ขณะที่ "vibe coding" เองก็ถูกใช้ในเชิงดูแคลนโดยนักพัฒนาหลายคน
  • แต่ฉัน พร้อมจะทวงคำว่า vibe กลับมาใช้กับสิ่งที่สร้างสรรค์กว่าเดิม
• ฉันไม่เคยชอบการแบ่งแยกระหว่าง "coder" กับ "engineer" แบบประดิษฐ์ขึ้นมา เพราะมันให้ความรู้สึกเหมือนเป็นกำแพงกีดกันเล็ก ๆ เสมอ แต่ในกรณีนี้ กำแพงกีดกันเล็กน้อยนี่แหละคือสิ่งที่ต้องการอย่างพอดี
  • vibe engineering สร้างเส้นแบ่งที่ชัดเจนจาก vibe coding และส่งสัญญาณว่านี่คือ อีกวิธีหนึ่งที่ต่างออกไป ยากกว่า และซับซ้อนกว่าของการทำงานกับเครื่องมือ AI เพื่อสร้างซอฟต์แวร์ production
• ฉันชอบที่มันอาจฟังดูทะลึ่งและชวนถกเถียง และพื้นที่ทั้งหมดนี้ก็ยังคงมีความไร้สาระอยู่หลายแบบ
  • ระหว่างที่เรากำลังหาวิธีใช้เครื่องมือใหม่เหล่านี้ให้เกิดประสิทธิผลสูงสุด เราก็ไม่ควรจริงจังกับตัวเองมากเกินไป
• ก่อนหน้านี้ฉันเคยพยายามผลักดันคำอย่าง AI-assisted programming ให้ติด แต่แทบไม่ประสบความสำเร็จเลย ดังนั้นครั้งนี้การลองถูคำว่า vibe ดูแล้วดูว่าจะเกิดอะไรขึ้นก็คงไม่เสียหาย
• ฉันชอบความไม่เข้ากันอย่างชัดเจนระหว่างคำว่า "vibe" กับ "engineering" มาก และมันทำให้คำผสมนี้ มีความย้อนแย้งในตัวเองอย่างขี้เล่นและ (หวังว่า) จดจำได้ง่าย

[m00nlygreat]

เมื่อไม่นานมานี้ก็เหมือนเคยตั้งชื่อประมาณว่า “โค้ดอะไรนะ?” แล้วล้มเหลวมาแล้ว เท่าที่รู้ ดูเหมือนว่า AI pair programming จะเป็นคำที่เหมาะสมที่สุดนะครับ

การตั้งชื่อก็เพื่อจะได้อ้างว่า “ชื่อนี้ฉันเป็นคนคิด”

[m00nlygreat]

เคยมีคนเรียกมันว่า Augmented Coding แต่ก็หายไปอย่างรวดเร็ว

[GN⁺]

ความเห็นจาก Hacker News

• ช่วงนี้พออ่านหัวข้อแบบนี้ทีไรก็รู้สึกหดหู่แปลก ๆ สมัยก่อนฉันมีทักษะการเขียนโปรแกรมที่หายาก เป็นที่ต้องการ และค่าตอบแทนดี และถึงภาษา বাเฟรมเวิร์กจะเปลี่ยนเร็วก็ยังรู้สึกว่าตัวเองฉลาดพอจะตามทันได้ แต่พอเห็นคนอย่าง Simon Willison บอกว่าวิธีเขียนโค้ดแบบใช้เอเจนต์และเวิร์กโฟลว์ทำหลายงานพร้อมกันแบบใหม่นี้คืออนาคต ก็รู้สึกว่ามันต้องใช้ความพยายามมหาศาลจนใจมันล้า ลองใช้ coding agent มาแล้วแต่กลับมีเวลาที่ต้องนั่งรอมากขึ้น และการจัดการหลายงานพร้อมกันก็ทำให้จับจังหวะการทำงานยากขึ้นจนสนุกน้อยลง เลยเริ่มคิดว่าอยากย้ายไปทำงานอีกสายแบบเซลส์แทน
  • ฉันก็เห็นด้วยกับความรู้สึกนั้นจากใจจริง อันที่จริงหนึ่งในเป้าหมายของฉันคือการโต้แย้งแนวคิดที่ว่า "ทักษะการเขียนโปรแกรมจะหมดความหมายและใคร ๆ ก็เขียนโค้ดด้วย LLM ได้" ฉันเชื่อว่าคนที่มีประสบการณ์พัฒนาซอฟต์แวร์อยู่แล้วจะยิ่งมีมูลค่าสูงขึ้นมากเมื่อทำงานร่วมกับ coding agent หรือ LLM เราสามารถเอาสิ่งที่เรียนรู้มาทั้งหมดไปใช้กับเครื่องมือใหม่เพื่อสร้างอิมแพ็กต์ที่ใหญ่กว่าได้ อย่างที่พูดไว้ในโพสต์ เครื่องมือ AI ทำหน้าที่ขยายศักยภาพของผู้เชี่ยวชาญเดิม ผู้เริ่มต้นอาจสร้าง UI เท่ ๆ ด้วย ChatGPT ได้ แต่เรื่องอย่างการออกแบบสถาปัตยกรรม การทดสอบอัตโนมัติ CI/CD การดีพลอยบน Kubernetes หรือการเดินระบบหลายเอเจนต์พร้อมกันนั้นทำไม่ได้ ดังนั้นบทบาทของวิศวกรที่มีประสบการณ์จึงยิ่งสำคัญขึ้นมาก
  • ฉันเองก็รู้สึกว่าการ "บริหารเอเจนต์จำนวนมากที่ทำงานแบบขนานขนาดใหญ่" เป็นภาระหนัก ภายนอกมันอาจดูทรงพลังมากจนมีนักพัฒนาหลายคนสนใจ แต่จริง ๆ แล้วกลับให้ความรู้สึกเครียดมหาศาลและเต็มไปด้วยงานเชิงบริหาร ตอนที่ฉันตกหลุมรักการพัฒนาใหม่ ๆ ความสนุกอยู่ที่การเขียนโค้ดเองล้วน ๆ ฉันเขียนโค้ดทั้งวันและเรียนรู้ไปเยอะมาก แต่พอมีประสบการณ์เกิน 10 ปี วิธีคิดก็กลายเป็นเชิงธุรกิจมากขึ้นแบบว่า "แต่แรกเราจะเขียนโค้ดสิ่งนี้ไปทำไม?" ในที่ประชุมพอแต่ละแผนกถามว่า "ทำอันนี้ได้ไหม" คำตอบก็แทบจะเป็น "YES" เสมอ ในทางเทคนิคมันเกือบทำได้หมด แต่คำถามที่สำคัญจริง ๆ คือ "มันยากแค่ไหน" หรือ "ทำไมเราต้องทำสิ่งนี้" ฉันยังคิดว่าสิ่งสำคัญไม่ใช่ความสามารถในการทำซ้ำและปล่อยของได้หลากหลาย แต่อยู่ที่การมองแก่นแท้ของปัญหา
  • คุณพูดแทนใจฉันมาก ฉันเองก็ไม่ชอบงานแบบคอยเฝ้าดูแลและจัดการ AI เลย อีกทั้งยังน่ากลัวที่การเขียนโค้ดด้วย AI แบบนี้กำลังทำให้สภาพที่ต้องพึ่งบัญชีจากบริษัทยักษ์ใหญ่ลึกลับซึ่งไร้การตรวจสอบใด ๆ เพื่อจะทำงานได้ กลายเป็นเรื่องปกติ
  • ไม่ต้องกังวลไป ฉันกำลังเมนเทอร์วิศวกรใหม่ในทีมอยู่ คนนี้ลำบากมากกับการปรับปรุงโค้ด เพราะพอมันทำงานได้ก็พอใจแล้ว โครงสร้างก็ไม่ดี แถมยังมีปัญหาเล็ก ๆ และประเด็นด้านความปลอดภัยซ่อนอยู่เต็มไปหมด ทั้งหมดนี้เกิดขึ้นได้แม้มีแค่ไฟล์ Python 3 ไฟล์ ในทีมเรามีนักพัฒนา 10 คน และถ้าใช้ LLM ร่วมกัน ความต่างด้านคุณภาพโค้ดจะยิ่งถ่างออกตามระดับประสบการณ์ จากที่สังเกตมาในช่วง 6 เดือนก่อนจะเปิดใช้ LLM อย่างเป็นทางการ ช่องว่างระหว่างจูเนียร์กับซีเนียร์หรือคนที่มีประสบการณ์มากนั้นจริง ๆ แล้วยิ่งกว้างขึ้น ฉันเห็นคล้ายกับความเห็นของ Simon
  • แค่จำไว้ว่าคนที่มีความรู้โดยเนื้อแท้จะยิ่งได้รับพลังจากเครื่องมือมากขึ้น ไม่ใช่ตรงกันข้าม
• ช่วงต้นปี 2023 ตอน GPT-4 ออก วงการแปลก็เจอความเปลี่ยนแปลงคล้ายกัน ในการแปลอังกฤษ-ญี่ปุ่นซึ่งเป็นสายงานที่ฉันทำอยู่เป็นครั้งแรกที่ machine translation เข้าใกล้ระดับมนุษย์ ตอนนั้นฉันถกกับนักแปลมืออาชีพหลายคนมาก และก็มีการถกเถียงหลายแบบเหมือนที่นี่ ทุกคนแสดงความผิดหวังว่าทักษะการแปลยาก ๆ อาจหมดความหมายไป ปฏิกิริยาส่วนใหญ่คือพอใช้ LLM เป็นผู้ช่วยแล้ว ความสนุกท้าทายในกระบวนการก็หายไปด้วย นักแปลที่ฉันเจอส่วนใหญ่เป็นฟรีแลนซ์และเป็นประเภทที่ค่อย ๆ แปลทีละประโยคอย่างระมัดระวัง พวกเขาไม่ได้อยากเป็นผู้จัดการโครงการแปลขนาดใหญ่เท่าไรนัก และถึงจะใช้ทักษะการสื่อสารเชิงวัฒนธรรม/บริบทขั้นสูงได้ก็ยังมีแรงจูงใจต่ำ ตอนนี้ฉันไม่ได้ทำงานแปลมากนัก แต่ยังติดตามพัฒนาการของ AI อย่างต่อเนื่อง และบางครั้งก็ใช้โจทย์แปลมาทดสอบเปรียบเทียบโมเดล ช่วงนี้ฉันลองระบบแปลแบบ multi-LLM ที่เอาหลาย LLM มาซ้อนกันให้ตรวจทานและปรับปรุงคำแปลของกันและกัน ในเอกสารบางประเภทผลลัพธ์ออกมาใกล้เคียงงานแปลระดับมนุษย์ชั้นยอดมาก ค่า API ไม่ได้ถูก แต่สำหรับงานแปลสำคัญก็ยังคุ้มที่จะจ่าย ตอนออกแบบระบบ "vibe translation" แบบนั้น ประสบการณ์การเป็นนักแปลของฉันช่วยได้ชัดเจนมาก ซึ่งคล้ายกับ vibe engineering ที่ Simon พูดถึง ในวัยตอนนี้ของฉัน (68 ปี) มันโอเค แต่ถ้า LLM และสิ่งพวกนี้เกิดขึ้นตอนต้นอาชีพของฉัน (ช่วงปีที่ 5~10) ฉันคิดว่าตัวเองอาจเลิกเป็นนักแปลไปแล้วก็ได้
  • เรื่องการแปลเป็นวัตถุดิบที่ดีมากสำหรับการคุยเรื่อง LLM ขอบคุณที่แบ่งปันประสบการณ์ อีกด้านหนึ่ง คนส่วนใหญ่ไม่ได้เห็นคุณค่าลึกซึ้งของนักแปลนัก เช่น แทบไม่มีใครจำได้ว่าใครเป็นคนแปลหนังสือ และทุกวันนี้คนก็อ่านหนังสือน้อยลงกว่าเมื่อก่อนด้วย ยิ่งทำให้เป็นแบบนั้น อีกทั้งด้วยเหตุนี้ งานแปลจึงมีแนวโน้มถูกทำสัญญา/จ่ายเงินตามจำนวนคำหรือจำนวนบรรทัดมาโดยตลอด คล้ายกับการตรวจขั้นสุดท้ายในซอฟต์แวร์ซีเคียวริตี สายงานแปลที่น่าจะมีความสามารถแข่งขันในอนาคตจริง ๆ อาจเหลือแค่ด้านกฎหมาย (เพราะต้องมีคนรับผิดในคดีหรือความรับผิดชอบทางกฎหมาย) หรือการล่ามพร้อมกัน/ล่ามภาคสนาม (เพราะต้องเจอหน้ากันและมีการพบปะจริง)
• ช่วงนี้ในคอมมูนิตี้เทคโนโลยีดูเหมือนจะขายแนวคิดว่า "การเขียนโค้ดเร็วขึ้นและผลิตภาพสูงขึ้น" เกินไปจนรู้สึกงง ๆ เป็นบรรยากาศที่ยกความสำคัญของผลลัพธ์ที่เร็วเข้าไว้ก่อน จากประสบการณ์จริงของฉัน LLM มักสร้างโค้ดที่ฟุ่มเฟือยและยุ่งเหยิงออกมาบ่อย แน่นอนว่ามันอาจเร็วกว่าฉัน แต่ฉันกลับรู้สึกว่าโค้ดที่ฉันค่อย ๆ เขียนเองนั้นดีกว่ามาก ทุกวันนี้เหมือนทุกอย่างต้องคุยให้เร็ว ได้ผลลัพธ์เร็ว และขึ้นโปรดักชันให้เร็ว ซึ่งบรรยากาศแบบนี้เองที่เคยเป็นต้นเหตุให้มีเว็บโปรดักต์หละหลวมออกมามากมาย แทนที่จะเล่นคำเท่ ๆ อย่าง vibe coding/engineering เราควรถกกันจริงจังว่าทำไมถึงต้องการความเร็วแบบยอมรับคุณภาพต่ำได้ และทำไมตัวระบบอัตโนมัติ/กระบวนการเองถึงพัฒนาให้ดีกว่านี้ไม่ได้ ยกตัวอย่างเช่น เราอาจสร้าง unit test ได้เร็วมาก แต่ก็ควรถามด้วยว่าทำไมตั้งแต่แรกเราถึงต้องการ unit test มากขนาดนี้ แน่นอนว่ามันจำเป็น แต่เหมือน abstraction หรือมุมมองระดับบนกำลังก้าวหน้า ขณะที่เครื่องมือระดับล่างหรือเครื่องมือรายละเอียดกลับพัฒนาได้ช้า
  • ปัญหาเชิงแก่นของข้อถกเถียงเรื่อง software engineering คือ แม้เครื่องมือและภาษาจะดูเหมือนกัน แต่ในความเป็นจริง ระดับการยอมรับความเสี่ยง ความปลอดภัย คอมพลายแอนซ์ และมาตรฐานการบำรุงรักษานั้นต่างกันมหาศาล บางคนกำลังทำแค่ต้นแบบง่าย ๆ ให้เสร็จเร็ว บางคนกำลังดูโรดแมประยะยาว 10 ปีหรือข้อมูลอ่อนไหว พอสองมุมมองนี้ปะปนกัน จึงเกิดทั้งแนวคิดว่าใครทำได้เร็วคือคนเก่ง และความกังวลว่าทำแบบนี้แล้วผลลัพธ์จะเลวร้ายมาก ทั้งสองฝ่ายไม่ได้ผิด แต่ดูเหมือนการสนทนาจะละเลยบริบทงานจริงและระดับความเสี่ยงไปทุกครั้ง
  • ในทางปฏิบัติ LLM ช่วยเพิ่มความเร็วการพัฒนาได้มหาศาลจริง ฉันเขียนโค้ดมาตั้งแต่ ป.5 และทำมาเกิน 20 ปี คนรอบตัวก็ยอมรับเรื่องความเร็วของฉันอยู่แล้ว แต่หลังเอา LLM เข้ามา สเกลที่ฉันทำได้ขยายขึ้นอย่างมาก เกมมันเปลี่ยนไปแล้ว และตอนนี้เป็นเรื่องว่าจะปรับตัวได้หรือไม่ได้ ฉันเองก็ไม่พอใจกับความไม่แน่นอนของอนาคตอยู่มาก แต่ถ้าเป็นวิศวกรที่อยู่ในสถานการณ์คล้ายกันก็คงเข้าใจดี
  • ฉันจะลองอธิบายตรรกะว่าทำไมความเร็วถึงสำคัญมากในงานพัฒนาซอฟต์แวร์ ไม่ได้บอกว่าข้ออ้างของฉันต้องถูกต้อง หรือมีข้อมูลจริงรองรับ และนิยามคำก็อาจไม่ชัดนัก ก่อนอื่น "ซอฟต์แวร์แบบ trivial" อาจมองได้ว่าเป็นสิ่งที่ทุกคนรู้ชัดทั้งคุณค่าและวิธีแก้ มีการตรวจสอบอัตโนมัติได้ หรือมีวิธี implement อยู่เพียงแบบเดียว แต่ซอฟต์แวร์ส่วนใหญ่ในโลกจริงไม่ trivial ที่นี่จะมีทั้งบั๊ก ความต้องการที่ตกหล่น abstraction ที่รั่ว ฟีเจอร์ไร้ประโยชน์ ปัญหาการเชื่อมต่อ ปัญหาประสิทธิภาพ ปัญหาความปลอดภัย ความซับซ้อน และภาระการบำรุงรักษาให้ปวดหัว ไม่ว่านักพัฒนาจะเก่งแค่ไหนหรือเขียนโค้ดดีแค่ไหน ปัญหาเหล่านี้ก็หลีกเลี่ยงไม่ได้ และมันจะเผยตัวออกมาและค่อย ๆ ดีขึ้นได้ก็ผ่านฟีดแบ็กซ้ำ ๆ การใช้งานจริง การบำรุงรักษา และการทดลองจำนวนมากเท่านั้น กล่าวคือเราไม่สามารถสร้างโค้ดที่สมบูรณ์แบบได้ในครั้งเดียว คุณภาพจะดีขึ้นจากการทำซ้ำหลายรอบ คุณภาพซอฟต์แวร์โดยรวมจึงถูกกำหนดโดยปริมาณของ "feedback loop" นี้ เวลาที่ใช้ในการหมุนหนึ่งลูปจะจำกัดจำนวนรอบทั้งหมดด้วย สุดท้ายยิ่งผลิตได้เร็ว ก็ยิ่งได้เจอฟีดแบ็กมากลูป และนั่นทำให้ซอฟต์แวร์พัฒนาไปสู่สิ่งที่ดีกว่าได้มากขึ้น โค้ดช้าแต่คุณภาพสูงถ้าหมุนได้แค่รอบเดียวก็มีข้อจำกัด ในทางกลับกัน ต่อให้คุณภาพต่ำกว่า แต่ถ้าทำซ้ำได้ไม่สิ้นสุดก็อาจไปถึงผลลัพธ์ที่ดีกว่าได้
  • อีก 5 ปีข้างหน้าน่าจะกลายเป็นตัวอย่างของ sunk cost fallacy ที่ดีที่สุดในโลก
• ฉันคิดว่าคำว่า "vibe coding" ยังไม่เหมาะเท่า "agentic coding" หรือ "agentic software engineering" เวิร์กโฟลว์การพัฒนาของฉันเริ่มจาก code plan ของ Claude แล้วขั้นแรกจะทำสเปกให้ชัดเจนเสมอ ใช้ TDD และบังคับใช้กฎคุณภาพโค้ดลับที่ฉันตั้งไว้ผ่านเครื่องมืออัตโนมัติด้วย เช่น ถ้าผิดจาก design system ก็จะ commit โค้ดไม่ได้ และมีการตรวจการแยกชั้นให้ HTTP handler ต้องผ่าน service layer เสมอ ฉันจะคอยย้ำโมเดลเป็นระยะให้รักษา TDD ให้ดี ซึ่ง Claude 4.5 จำได้ดีกว่า 4.1 มาก พอมีฐานเป็น TDD การรีวิวโค้ดใน PR ก็ง่ายมหาศาล ฉันยังทำเครื่องมือง่าย ๆ ที่เอา PR กับสเปกส่งให้ Gemini เพื่อชี้ความไม่ตรงกัน สิ่งที่ตกหล่น หรือข้อผิดพลาดแบบอัตโนมัติ เป็นเครื่องมือสำรองที่ดี แต่สุดท้ายสิ่งสำคัญคือความสามารถของฉันเองที่จะตัดสินว่าอยากได้ผลลัพธ์แบบไหน และเอเจนต์เริ่มออกนอกลู่นอกทางตรงไหน สรุปคือ "input คุณภาพต่ำ ก็ได้ output คุณภาพต่ำ input คุณภาพสูง ก็ได้ output คุณภาพสูง"
  • ที่บอกว่าเตือนโมเดลเรื่อง TDD นี่ ใน vibe coding เอเจนต์ได้วนลูป red-green-refactor ของ TDD ซ้ำ ๆ จริงหรือเปล่า? หรือว่ามันสร้างผลลัพธ์ยาวรวดเดียวออกมาทีเดียว
  • แทนที่จะเรียกแบบ vibe based ฉันคิดว่าคำว่า "slop-coding" เหมาะกว่า
• ฉันสงสัยว่าคำว่า "vibe engineering" มันใช่จริงหรือไม่ เพราะของจริงคือการใส่ข้อจำกัดสารพัดให้เอเจนต์ ทั้งการทดสอบอัตโนมัติ การวางแผนล่วงหน้า การทำเอกสารอย่างละเอียด code formatting/lint และ manual QA ฉันเองก็อ่านโพสต์ของ Karpathy แล้วลองเริ่ม vibe coding ดู ตอนแรกก็สัมผัสได้ถึงฟีลที่แม้โค้ดจะหยุดก็แค่รันซ้ำหลายครั้งและเชื่อใจกระบวนการโดยรวม แต่พอมีประสบการณ์มากขึ้นก็พบว่าสุดท้ายต้องควบคุมโมเดลอยู่ดี การเดินระบบเอเจนต์คล้ายคาร์ตเรซซิง ต้องมีข้อจำกัดหลายชั้นเหมือนยางกั้นรอบสนาม Constraint Harness ต่างหากที่เป็นหัวใจ ส่วนโค้ดเองจะสร้างหรือสร้างใหม่ก็ง่ายขึ้น ต่อไปสิ่งสำคัญคือการสะสมชุดทดสอบและข้อจำกัดสำหรับงานที่ AI ผลิตออกมา
  • คำว่า "vibe engineering" ฟังดูเบาเกินไปและไม่ค่อยจริงจัง ใช้คำเป็นกลางที่อธิบายหน้าที่จริงอย่าง "LLM-assisted programming" น่าจะดีกว่าไหม ถึงจะไม่ค่อยมีอิมแพ็กต์ก็เถอะ
• "การวางแผนล่วงหน้า" จะเรียกว่า spec-driven development ก็ได้ จริง ๆ แล้วการพัฒนาทุกอย่างอาจพูดง่าย ๆ ว่าอิงสเปกมาก่อนอยู่แล้ว แต่แก่นแท้จริง ๆ คือ "การบริหารในรูปแบบที่ประหลาดมาก" นั่นคือการให้คำสั่งที่ชัดเจน ให้บริบทเพียงพอ และให้ฟีดแบ็กที่นำไปลงมือทำต่อได้ ถ้ามองผ่านตัวอักษรล้วน ๆ มันใกล้เคียง waterfall มากกว่า agile
• ตอนนี้คำว่า vibe-coding ดูเหมือนความหมายจะขยายจนกลายเป็นคำครอบการเขียนโค้ดด้วย AI ทั้งหมดแล้ว เวลาใช้งานจริงฉันเองก็รู้สึกว่าใกล้กับการ pair programming กับ AI และคิดว่า "นี่มันกำลัง vibe-ing จริง ๆ" แต่ vibe-coding แบบต้นฉบับที่ปล่อยหมดแบบ "Take the wheel, LLama of God" ก็น่าจะยังถูกใช้บ่อยอยู่ จึงคิดว่าควรมีคำใหม่แยกต่างหาก ฉันอยากเสนอคำว่า “Yolo-Coding” ซึ่งก็เข้ากับสาย no-code, low-code, yolo-code ด้วย
  • ฉันคิดว่าคงดีกว่าถ้าภาพลักษณ์เชิงลบของ vibe coder ยังคล้าย no-code ต่อไป คำว่า vibe engineer อาจไม่ค่อยดี แต่ยังไงในอนาคตคำว่าวิศวกร/นักพัฒนาก็อาจตั้งอยู่บนสมมติฐานว่าต้องใช้เอเจนต์เป็นพื้นฐาน และคนที่พัฒนาแบบ "ทำมือ" ต่างหากที่อาจกลายเป็นข้อยกเว้น
  • ในโลก $enterprise เราพยายามหาคำใหม่เพื่อแยก "responsible vibing" ออกจาก "YOLO vibe coding" แล้วสุดท้ายก็มาจบที่คำว่า "agent assisted coding" เพราะจำเป็นต้องมีตัวย่อสามตัวอักษร
  • ความหมายดั้งเดิมของ "vibe coding" ตามที่ Ilya Sutskever โพสต์ใน Twitter คือแค่พิมพ์พรอมป์ต์แล้วเอาผลลัพธ์ไปแปะรันเลยโดยไม่รีวิว ไม่วิเคราะห์ ไม่ตรวจสอบ
  • ส่วนตัวฉันมองว่า AI-assisted coding อยู่ในระดับ autocomplete หรือช่วยอ่านเอกสารที่อ่านยาก แต่ vibe coding คือ
  • นักพัฒนาไม่เข้าใจโค้ดที่ LLM เขียนเลย
  • เกิดหนี้ทางเทคนิคทันทีโดยไม่มี code review
  • ในทางกฎหมายเปราะบางมากใน EU/US เพราะปัญหาการคุ้มครองลิขสิทธิ์ และจุดอันตรายถึงตายที่สุดของ vibe coding คือ โค้ดที่ LLM สร้างขึ้นโดยเนื้อแท้แล้วไม่สามารถรับความคุ้มครอง/จดลิขสิทธิ์ได้ แม้จะมีข้อยกเว้นบางแห่งอย่างสหราชอาณาจักร แต่ในประเทศส่วนใหญ่ก็แทบไม่มีทางออก
  • ฉันเองก็ทำ slash command อย่าง /yolo ให้ claude แล้วลองสั่งให้มันรันไปเลยแบบแทบไม่มีไกด์อะไร
• มีการทดลองที่เวลาให้นกพิราบโต้ตอบกับอุปกรณ์ที่ปล่อยอาหารออกมาแบบสุ่ม มันจะคิดว่ารางวัลนั้นเกิดจากพฤติกรรมของตัวเอง เลยทำท่าแปลก ๆ สนุก ๆ ซ้ำไปซ้ำมา
  • ท่าเต้นสนุก ๆ นั่นอาจคล้ายกับ "การเขียนเทสต์" หรือ "การวางแผน" ก็ได้
  • มีใครพอมีบทความวิจัยอ้างอิงไหม? ลองค้นคำว่า "นกพิราบตลก" แล้วเจอแต่คลิปในโซเชียล หาไม่ค่อยเจอ
• ฉันว่าชื่อ "Augmented Engineering" (AE) ดีกว่า เพราะมันขยายขีดความสามารถด้วยพลังของ AI และทำให้ได้ผลลัพธ์ดีที่สุด จึงเป็น "วิศวกรรมแบบเสริมพลัง" และ AE ยังตีความเป็น "Advanced Engineering" ได้ด้วย เพราะ AI ช่วยให้เข้าถึงความรู้เทคโนโลยีล่าสุดได้ทันที จึงย่อมเป็นวิศวกรรมที่ก้าวหน้ากว่า ส่วน vibe นั้นไม่ค่อยเวิร์ก
  • ไม่จำเป็นต้องใส่ใจกับคำเรียกขนาดนั้นก็ได้ และการตั้งชื่อแยกอาจยิ่งทำให้รู้สึกว่า AI coding เป็นเรื่องของนักพัฒนาบางกลุ่มเท่านั้น ทั้งที่อนาคตการเขียนโค้ดแบบดั้งเดิมต่างหากที่จะกลายเป็นข้อยกเว้น และคำว่า vibe ที่ใช้กันตอนนี้ก็น่าจะหายไปเองในไม่ช้า
  • ฉันขอแย้งประโยคสุดท้าย AI ไม่ได้แค่ช่วยให้เข้าใจความรู้วิศวกรรมล่าสุดได้ทันทีเท่านั้น แต่มันยังอาจดูดซึมความผิดพลาด ข้อบกพร่อง ความเข้าใจผิด และดีไซน์ที่พังซ้ำ ๆ ตลอด 1~10 ปีที่ผ่านมาได้แบบ "ทันที" เช่นกัน ดังนั้นห้ามเชื่อข้อมูลจาก AI แบบไม่วิจารณ์เด็ดขาด ต้องตรวจสอบแหล่งที่มาเสมอ และยังต้องเช็กด้วยว่าแหล่งนั้นเองไม่ได้ถูก AI สร้างขึ้นมาอีกที เพราะชุดข้อมูลกำลังปนเปื้อนมากขึ้นเรื่อย ๆ จึงยิ่งต้องระวัง
  • ฉันอยากถามว่า "Augmented Engineering" จำเป็นต้องเป็นชื่อเฉพาะแยกต่างหากจริงหรือ? ความจริงมันก็แค่ "engineering" นั่นแหละ เหมือนเราไม่ได้เรียกการทำงานโดยเปิดหนังสืออ้างอิงว่า "book-assisted engineering" vibe ก็เหมือนกัน จะเรียกขำ ๆ ว่า "Yolo engineering" หรือ "Machine Outsourced Irresponsible LMAO Engineering" ก็ยังได้ และคำว่า “Advanced Engineering” ตอนท้ายก็ดูเว่อร์ไปหน่อย
• Simon มักชี้แก่นประเด็นได้แม่นเสมอ แต่ปัญหาจริง ๆ น่าจะอยู่ที่คำว่า "vibe" มากกว่าคำว่า "coding" ต่อให้เปลี่ยนเป็น vibe engineering มันก็ยังให้ความหมายทำนองว่า "ลุยไปทั้งที่ไม่รู้ว่ากำลังทำอะไรอยู่" อย่างมากที่สุดฉันคิดว่าคำอย่าง "AI-assisted software engineering" จะดีกว่า เพราะแยกขอบเขตปลายทั้งสองด้านได้ชัดกว่า

[kimjoin2]

ตั้งชื่อที่ไม่มีความหมาย;