- เราเริ่มรู้ได้ง่ายขึ้นว่ามี โค้ดที่สร้างโดย LLM ในทีม
- โค้ดประเภทนี้อาจดูชัดเจนและมีการทดสอบที่ดี แต่ไม่ยึดตาม ขนบการเขียนของโปรเจกต์
- มักจะเมินเฉยต่อ รูปแบบหรือตัวช่วยเดิม ๆ และเขียนการใช้งานใหม่ด้วยตนเอง
- ความกังวลเพิ่มขึ้นว่าการพัฒนาซอฟต์แวร์กำลังมุ่งเน้น เพียงความเร็ว
- สุดท้ายสิ่งที่สำคัญที่สุดคือ คุณภาพและความสอดคล้อง และความสามารถในการดูแลรักษา
ร่องรอยของ "vibe coding"
- ในทีมมีโค้ดบางส่วนที่เพิ่งเขียนขึ้นดู ชัดเจนและทำงานได้ครบถ้วน แต่สามารถรู้ได้ทันทีว่าเป็นโค้ดที่สร้างโดย LLM เพราะไม่ยึดตาม ขนบการเขียนเฉพาะของโปรเจกต์
- ตัวอย่างเช่น แม้โปรเจกต์จะมี ไลบรารีสำหรับดึงข้อมูล อยู่แล้ว ก็ยังเขียนการนำไปใช้เองแบบสมบูรณ์สำหรับ การทำคำขอ HTTP ที่รองรับ กรณีข้อยกเว้นทุกแบบ
- ฟังก์ชัน ยูทิลิตี้ ของโมดูลเดิมถูกสร้างขึ้นใหม่ซ้ำ ๆ และแม้มี กลไกการเปลี่ยนค่าการตั้งคือตามระดับโมดูล ก็ยังเปลี่ยนการตั้งค่าทั่วไป
- แม้ในวัฒนธรรมทีมจะวางแนวทางการเขียนแบบ ฟังก์ชันนัล แล้ว ก็มีการเขียนโค้ดแบบ เชิงคลาส ใหม่อีกครั้ง
- โค้ดเหล่านี้เป็นสไตล์ที่คนเขียนเมื่อหลายปีก่อน ย่อมไม่เคยเขียน
ความสำคัญของการบำรุงรักษาและหลักการซอฟต์แวร์
- ในการพัฒนาซอฟต์แวร์ เราได้ทุ่มเทเวลาสร้าง รูปแบบและมาตรฐาน ที่ดูแลรักษาได้อย่างยั่งยืน
- โค้ดที่ทำงานได้จริง ๆ ใครก็ทำได้ แต่ความท้าทายที่แท้จริงคือการเขียนโค้ดที่ แก้ไขและบำรุงรักษาได้ง่าย เมื่อเวลาผ่านไป
- ประเด็นสำคัญไม่ใช่แค่การทำงานของฟังก์ชัน แต่คือโค้ดเบสที่สามารถดูแลได้เมื่อเวลาผ่านไป
- “vibe coding” อาจทำลาย ปรัชญาและเกณฑ์มาตรฐาน เหล่านี้ได้
เราควรให้ความเร็วเป็นเส้นตรงสูงสุดหรือไม่?
- เปรียบเสมือนบาริสต้าคนใหม่ในร้านกาแฟที่รีบจัดกาแฟจนอาจทำให้กาแฟหก เปรียบเทียบเพื่อเน้นว่าการยึดติดกับ ความเร็ว ไม่ได้นำไปสู่ผลลัพธ์ที่ถูกต้องเสมอไป
- ทีมพัฒนายุคใหม่ก็เช่นกัน บ่อยครั้งเร่งสร้างซอฟต์แวร์ใหม่อย่างเร่งรีบจนเกิดการ ลดคุณภาพ
- คนทั่วไปอยากได้ ผลลัพธ์ที่ถูกต้อง แม้ต้องรอให้นานขึ้นเล็กน้อย
- ก่อนหน้านี้คิดว่าความเร็วเป็นปัญหาของคนในสายอาชีพที่ไม่ใช่การพัฒนา แต่ตอนนี้รู้สึกผิดหวังกับความเป็นจริงที่เพื่อนนักพัฒนาหลายคนก็กำลังละทิ้งหลักการและมุ่งแต่ความเร็ว
สิ่งที่เราต้องการจริง ๆ
- ไม่ว่าใส่โค้ดลงใน IDE แบบไหนก็ไม่สำคัญ
- สิ่งที่สำคัญคือ ทัศนคติของนักพัฒนาที่ใส่ใจคุณภาพ
- ยอมรับว่า LLM เป็นนวัตกรรมด้านเทคโนโลยีที่ยอดเยี่ยม แต่ย้ำเสมอว่าความรับผิดชานในการสร้างซอฟต์แวร์จริงยังคงเป็นหน้าที่ของนักพัฒนา
- แนะนำให้ใช้ หลักการที่มีอยู่แล้ว เช่น “การเขียนพรอมต์ให้ดีขึ้น”, “ระบุไลบรารีที่ถูกต้อง”, “ให้ตัวอย่างประกอบ”, “ทำงานทีละไฟล์เล็ก ๆ”
- ทักท้วงว่าอย่า คุณภาพโค้ดและการบำรุงรักษา ให้เป็นภาระของ “น้ำหนัก” ของโมเดลเพียงอย่างเดียว
ยังไม่มีความคิดเห็น