เวิร์กโฟลว์การเขียนโค้ดด้วย LLM ของฉันสำหรับปี 2026 (Addy Osmani)
(addyosmani.com)Addy Osmani วิศวกรจากทีม Google Chrome สรุปเวิร์กโฟลว์การใช้ LLM จากประสบการณ์เขียนโค้ดด้วย AI ตลอด 1 ปี
หลักการสำคัญ:
- เริ่มจากสเปกก่อนโค้ด: เขียน
spec.mdร่วมกับ LLM ก่อน แล้วค่อยเริ่มเขียนโค้ดหลังจากยืนยันข้อกำหนด สถาปัตยกรรม และกลยุทธ์การทดสอบแล้ว โดยเขาเรียกสิ่งนี้ว่า "waterfall 15 นาที" - ทำซ้ำเป็นหน่วยเล็ก: อย่าขอผลลัพธ์ก้อนใหญ่ในครั้งเดียว แต่ให้แยกทำเป็นระดับฟีเจอร์/ฟังก์ชัน/บั๊ก หากโยนงานก้อนใหญ่ให้ จะได้ผลลัพธ์ที่เหมือน "คน 10 คนที่ไม่เคยคุยกันมาช่วยกันทำ"
- ให้คอนเท็กซ์อย่างเพียงพอ: ส่งต่อโค้ดที่เกี่ยวข้อง เอกสาร API และข้อจำกัดต่าง ๆ ให้มากพอ ใช้เครื่องมืออย่าง gitingest, repo2txt เพื่อป้อนโค้ดเบสเข้าไปให้ LLM
- เลือกโมเดลและใช้ควบคู่กัน: ถ้าโมเดลหนึ่งตัน ให้สลับไปใช้อีกโมเดล เช่น ให้ Gemini รีวิวโค้ดที่ Claude เขียน เพื่อทำ cross-check
- มนุษย์ต้องอยู่ในลูปเสมอ: ปฏิบัติต่อ LLM เหมือนนักพัฒนารุ่นจูเนียร์ที่ "มั่นใจสูงแต่พลาดบ่อย" ตรวจรีวิวและทดสอบโค้ดที่สร้างขึ้นทั้งหมด และอย่าคอมมิตโค้ดที่อธิบายไม่ได้
- จัดการเวอร์ชันแบบละเอียดมาก: คอมมิตทุกครั้งที่ทำงานเพื่อเก็บ "save point" และใช้
git worktreeเพื่อรันหลาย AI session แบบขนาน - ตั้งกฎด้วย
CLAUDE.md/GEMINI.md: เขียนแนวทางสไตล์ของโปรเจกต์ แพตเทิร์นที่ต้องการ กฎ lint ฯลฯ เป็นไฟล์เพื่อป้อนให้ AI - เชื่อมกับ CI/CD: ให้การทดสอบอัตโนมัติและ linter ทำหน้าที่เป็น quality gate ของโค้ดจาก AI แล้วนำล็อกความล้มเหลวส่งกลับไปเป็นฟีดแบ็กให้ AI ในลูปต่อเนื่อง
จุดที่น่าสนใจ:
- ที่ Anthropic โค้ดประมาณ 90% ของ Claude Code ถูกเขียนโดย Claude Code เอง
- AI ให้รางวัลกับ best practices ที่มีอยู่เดิม เมื่อความสามารถของวิศวกรซีเนียร์ (การออกแบบ การจัดการความซับซ้อน การตัดสินใจเรื่องอัตโนมัติ) ผสานกับ AI จะเกิดผลสูงสุด
- เครื่องมือ AI ช่วยขยายความสามารถ ไม่ได้มาแทนที่ หากใช้ AI โดยไม่มีพื้นฐาน อาจกลายเป็น "Dunning-Kruger effect เวอร์ชันสเตียรอยด์"
ยังไม่มีความคิดเห็น