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 เวอร์ชันสเตียรอยด์"

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น