การเติบโตของผู้ช่วยเขียนโค้ด AI อย่าง Claude Code และ Windsurf ได้จุดประกายการโต้เถียงอย่างรุนแรงในชุมชนนักพัฒนาเกี่ยวกับว่าโปรแกรมเมอร์ควรอ่านและตรวจสอบโค้ดที่ AI สร้างขึ้นก่อนนำไปใช้งานจริงหรือไม่ การอภิปรายนี้มีจุดศูนย์กลางอยู่ที่คำถามพื้นฐาน: AI มีความสามารถมากพอที่จะทำให้การตรวจสอบโค้ดเป็นเรื่องที่เลือกได้หรือไม่ หรือการข้ามขั้นตอนนี้จะสร้างความเสี่ยงด้านความปลอดภัยและสถาปัตยกรรมที่อันตราย
ความแตกต่างในคำนิยาม: Vibe Coding คืออะไร
ชุมชนยังคงแบ่งแยกเกี่ยวกับความหมายที่แท้จริงของ vibe coding คำนิยามเดิมที่ได้รับความนิยมจากนักวิจัย AI Andrej Karpathy อธิบายว่าเป็นการเขียนโค้ดโดยไม่อ่านโค้ดที่สร้างขึ้นเลย - โดยพื้นฐานแล้วคือการปฏิบัติต่อ AI เหมือนกล่องดำที่ผลิตผลลัพธ์ที่ใช้งานได้ อย่างไรก็ตาม นักพัฒนาหลายคนในปัจจุบันโต้แย้งเพื่อคำนิยามที่พัฒนาแล้ว ซึ่งรวมถึงการเขียนโค้ดแบบมีการแนะนำและเป็นบทสนทนา โดยมนุษย์ตรวจสอบผลลัพธ์จาก AI
ความไม่เห็นด้วยในคำนิยามนี้สะท้อนความตึงเครียดที่ลึกซึ้งเกี่ยวกับมาตรฐานทางวิชาชีพ นักพัฒนาบางคนสนับสนุนให้ปฏิบัติต่อ AI เหมือนระบบอัตโนมัติ ในขณะที่คนอื่นยืนยันว่าควรจัดการเหมือนนักพัฒนาระดับเริ่มต้นที่ผลงานต้องการการดูแลและตรวจสอบอย่างต่อเนื่อง
ช่องโหว่ด้านความปลอดภัย: อันตรายที่ซ่อนอยู่
หนึ่งในข้อโต้แย้งที่น่าสนใจที่สุดสำหรับการอ่านโค้ดที่ AI สร้างขึ้นมาจากความกังวลด้านความปลอดภัย ระบบ AI แม้จะน่าประทับใจ แต่มักพลาดการใช้งานความปลอดภัยที่สำคัญ เช่น การควบคุมการเข้าถึงที่เหมาะสมและการตรวจสอบการยืนยันตัวตนของผู้ใช้ นักพัฒนาคนหนึ่งเพิ่งแบ่งปันตัวอย่างที่ AI สร้าง API endpoint ที่ส่งคืนโปรเจ็กต์ใดก็ได้ตาม ID โดยไม่ตรวจสอบว่าผู้ใช้ที่ร้องขอเป็นเจ้าของโปรเจ็กต์นั้นจริงหรือไม่ - ซึ่งเป็นช่องโหว่ด้านการอนุญาตแบบคลาสสิก
ช่องว่างด้านความปลอดภัยเหล่านี้เกิดขึ้นเพราะ AI มุ่งเน้นที่การตอบสนองคำขอทันทีมากกว่าการพิจารณาผลกระทบด้านความปลอดภัยในวงกว้าง ไม่เหมือนนักพัฒนามนุษย์ที่อาจหยุดกลางการใช้งานเพื่อพิจารณา edge cases ระบบ AI สร้างโค้ดตามรูปแบบโดยไม่มีความตระหนักด้านความปลอดภัยตามบริบทที่มาจากประสบการณ์
รายการตรวจสอบการรีวิวโค้ด AI
ก่อนที่จะ Push โค้ดที่สร้างโดย AI :
- ตรวจสอบสถาปัตยกรรม: โค้ดนี้เป็นไปตามรูปแบบที่กำหนดไว้หรือไม่?
- รีวิวด้านความปลอดภัย: ทรัพยากรทั้งหมดถูกจำกัดขอบเขตให้กับผู้ใช้อย่างเหมาะสมหรือไม่?
- การทดสอบ: การทดสอบเหล่านี้ทดสอบพฤติกรรมที่มีความหมายจริงหรือไม่?
- เอกสารประกอบ: คุณจะเข้าใจโค้ดนี้ในอีก 6 เดือนข้างหน้าหรือไม่?
- การจัดการข้อผิดพลาด: กรณีขอบเขตต่างๆ ได้รับการครอบคลุมหรือไม่?
- ประสิทธิภาพ: มี N+1 queries หรือความไม่มีประสิทธิภาพที่เห็นได้ชัดหรือไม่?
- การถ่ายทอดความรู้: คุณเข้าใจโค้ดใหม่นี้หรือไม่?
ปัญหาสถาปัตยกรรม: เมื่อ AI หลุดจากสคริปต์
แม้แต่ระบบ AI ที่กำหนดค่าได้ดีก็สามารถค่อย ๆ กัดกร่อนสถาปัตยกรรมโค้ดผ่านความไม่สอดคล้องเล็ก ๆ ที่สะสมเมื่อเวลาผ่านไป นักพัฒนารายงานว่าผู้ช่วย AI บางครั้งเบี่ยงเบนจากรูปแบบที่กำหนดไว้ โดยวางตรรกะทางธุรกิจใน controllers แทนที่จะเป็น service layers หรือสร้างฟังก์ชันการทำงานที่ซ้ำซ้อนที่ทำให้ codebase บวม
หากคุณไม่จับได้ตั้งแต่เนิ่น ๆ ความไม่สอดคล้องเล็ก ๆ เหล่านั้นจะกลายเป็นส่วนหนึ่งของ codebase และผู้ช่วยตัวโปรดของคุณจะถูกล่อลวงให้ทำตามตัวอย่างที่ไม่ดีเหล่านั้นในอนาคต
ความท้าทายกลายเป็นวงจร: AI เรียนรู้จากรูปแบบโค้ดที่มีอยู่ ดังนั้นข้อผิดพลาดทางสถาปัตยกรรมจึงได้รับการเสริมแรงและทำซ้ำตลอดทั้งโปรเจ็กต์ สิ่งนี้สร้าง technical debt ที่กลายเป็นเรื่องแพงขึ้นเรื่อย ๆ ในการแก้ไขเมื่อ codebase เติบโต
ความขัดแย้งของผลิตภาพ
การโต้เถียงยังสัมผัสคำถามพื้นฐานเกี่ยวกับผลิตภาพของนักพัฒนาและการเรียนรู้ บางคนโต้แย้งว่าการอ่านโค้ดนั้นช้ากว่าการเขียนจริง ๆ โดยชี้ให้เห็นว่าการตรวจสอบผลลัพธ์ของ AI ไม่ได้ให้ผลตอบแทนด้านผลิตภาพที่ทำให้เครื่องมือเหล่านี้น่าสนใจ คนอื่น ๆ โต้กลับว่าการเข้าใจโค้ดยังคงเป็นสิ่งสำคัญสำหรับสถาปัตยกรรมซอฟต์แวร์ที่มีประสิทธิภาพและความสามารถในการบำรุงรักษาระยะยาว
น่าสนใจที่การอภิปรายเผยให้เห็นแนวทางที่แตกต่างกันตามความซับซ้อนของโปรเจ็กต์ นักพัฒนาหลายคนรายงานความสำเร็จในการใช้ AI ในโหมด auto-accept สำหรับฟีเจอร์รอบนอกและการสร้างต้นแบบ ในขณะที่รักษากระบวนการตรวจสอบที่เข้มงวดสำหรับตรรกะทางธุรกิจหลักและส่วนประกอบที่สำคัญด้านความปลอดภัย
สองแนวทางในการพัฒนาด้วยความช่วยเหลือจาก AI
การสร้างต้นแบบอย่างรวดเร็วด้วยโหมดยอมรับอัตโนมัติ:
- ใช้สำหรับหัวข้อที่ไม่คุ้นเคยและการสำรวจ
- เหมาะสำหรับการสร้างโครงสร้างการทดสอบและการสำรวจไลบรารี
- ต้องมีการทบทวนและปรับแต่งเมื่อจบเซสชัน
- เหมาะที่สุดสำหรับฟีเจอร์รอง ๆ และส่วนประกอบที่ไม่สำคัญ
การเขียนโค้ดแบบซิงโครนัสสำหรับฟีเจอร์หลัก:
- รูปแบบการเขียนโปรแกรมเป็นคู่โดยไม่มีการยอมรับอัตโนมัติ
- ทุกข้อเสนอแนะจาก AI จะถูกทบทวนก่อนนำไปใช้
- ใช้สำหรับตรรกะทางธุรกิจหลักและขั้นตอนที่สำคัญ
- รักษาความสอดคล้องของสถาปัตยกรรมผ่านการดูแลอย่างต่อเนื่อง
อนาคตของการตรวจสอบโค้ด
เมื่อเครื่องมือเขียนโค้ด AI ยังคงพัฒนาต่อไป ชุมชนเผชิญกับทางเลือกระหว่างการยอมรับการพัฒนาแบบอัตโนมัติเต็มรูปแบบหรือการรักษาการดูแลของมนุษย์ นักพัฒนาบางคนคาดการณ์ว่าการตรวจสอบโค้ดที่ AI สร้างขึ้นจะกลายเป็นสิ่งที่ไม่จำเป็นในที่สุด เหมือนกับการอ่านโค้ด assembly ที่ compiler สร้างขึ้น คนอื่น ๆ โต้แย้งว่าการพัฒนาซอฟต์แวร์เกี่ยวข้องกับการพิจารณาเฉพาะโดเมนและข้อกำหนดด้านความปลอดภัยมากเกินไปที่จะทำให้เป็นอัตโนมัติได้อย่างสมบูรณ์
การโต้เถียงนี้สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับบทบาทของความเชี่ยวชาญของมนุษย์ในโลกที่ AI เสริมแรง ในขณะที่ AI สามารถสร้างโค้ดที่ใช้งานได้เร็วกว่าที่เคย ความรับผิดชอบด้านสถาปัตยกรรม ความปลอดภัย และความสามารถในการบำรุงรักษาระยะยาวยังคงต้องการการตัดสินใจของมนุษย์และความรู้เฉพาะโดเมน
ฉันทามติที่ดูเหมือนจะเกิดขึ้นรอบ ๆ แนวทางแบบผสม: ใช้ AI เพื่อเร่งการพัฒนาในขณะที่รักษาการดูแลของมนุษย์สำหรับการตัดสินใจที่สำคัญ ความสมดุลนี้จะคงอยู่หรือไม่เมื่อความสามารถของ AI ยังคงก้าวหน้าต่อไป ยังคงเป็นคำถามเปิดที่น่าจะกำหนดอนาคตของการพัฒนาซอฟต์แวร์
อ้างอิง: Read That F*cking Code!