บทบาทของนักพัฒนาในยุค AI Coding: จากผู้ลงมือเขียนโค้ดสู่ผู้ออกแบบบริบท การตรวจสอบ และการทำให้เป็นผลิตภัณฑ์

ภาพรวมโดยสรุป

• ประเด็นหลัก

  • เมื่อ AI มาถึงระดับที่สามารถเขียน แก้ไข และทดสอบโค้ดได้โดยตรง บทบาทของนักพัฒนาจึงกำลังย้ายจากการเน้นเขียนโค้ดอย่างเดียวไปสู่ การนิยามปัญหา การออกแบบงาน การตรวจสอบ การจัดการบริบท และการสนับสนุนการทำให้เป็นผลิตภัณฑ์

• สาเหตุเชิงโครงสร้าง

  • AI ช่วยเพิ่มความเร็วในการผลิตโค้ดได้มาก แต่โค้ดไม่ได้กลายเป็นผลิตภัณฑ์ที่ดีได้ทันที
  • ความสำคัญของส่วนที่ไม่ใช่การเขียนโค้ด เช่น requirements, เอกสาร, การทดสอบ, การจัดโครงสร้าง, การตัดสิน UX และความสามารถในการบำรุงรักษา เพิ่มสูงขึ้น

• กรณีตัวอย่างหลัก

  • ประสบการณ์ที่ทำให้ AI สามารถทำการทดสอบเบราว์เซอร์ได้ด้วย Playwright
  • ประสบการณ์การระบุงานซ้ำ ๆ เป็น command, skill และ workflow
  • กรณีที่ frontend prototype ที่สร้างด้วย AI ดูยอดเยี่ยมจากภายนอก แต่โครงสร้างภายในเปราะบาง

• แนวทางแก้ไข

  • ไม่ควรมอบให้ AI ทำแค่โค้ด แต่ต้องออกแบบขั้นตอนและเกณฑ์ของกระบวนการพัฒนาทั้งหมดไปพร้อมกัน
  • นักพัฒนาต้องตรวจทานผลลัพธ์จาก AI ทิ้งบริบทไว้ และจัดระเบียบโครงสร้างเพื่อให้ต่อยอดเป็นผลิตภัณฑ์ที่ยั่งยืนได้

---

บทนำ

การเปลี่ยนผ่านในยุค AI Coding

• โพสต์นี้เริ่มจากคำถามว่า “ในยุคที่มนุษย์ไม่ได้เขียนโค้ดโดยตรง นักพัฒนาควรทำอะไร”
• ผู้เขียนเคยมองว่า ในอดีต AI ยังมี hallucination และทำผิดพลาด ดังนั้นการตัดสินใจขั้นสุดท้ายจึงต้องเป็นมนุษย์
• แต่ด้วยประสิทธิภาพของโมเดล AI ที่ดีขึ้นในช่วงหลัง ผู้เขียนประเมินว่า AI ได้มาถึงระดับที่สามารถเข้าใจ issue, สำรวจไฟล์, แก้โค้ด และทำให้ผ่านการทดสอบได้แล้ว
• การเปลี่ยนแปลงนี้ทำให้นักพัฒนาเริ่มคิดไกลกว่าการใช้ AI เป็นเพียงเครื่องมือช่วย และหันมาพิจารณาว่าจะทำให้ AI ดำเนินกระบวนการพัฒนาเองได้อย่างไร

ประเด็นปัญหาหลัก

• แม้ AI จะเขียนโค้ดได้ดีขึ้น แต่ไม่ได้หมายความว่าบทบาทของนักพัฒนาจะหายไป
• ตรงกันข้าม ยิ่งการเขียนโค้ดถูกทำให้เป็นอัตโนมัติมากเท่าไร องค์ประกอบอื่น ๆ ของการพัฒนาก็ยิ่งเด่นชัดขึ้น
• การจัดระเบียบ requirements, การบันทึกการตัดสินใจ, การออกแบบการทดสอบ, การจัดการโครงสร้างโค้ด และการตรวจประสบการณ์ผลิตภัณฑ์ กำลังกลายเป็นภารกิจหลักของนักพัฒนา

---

เนื้อหา

1. AI เคลื่อนจากเครื่องมือเขียนโค้ดไปเป็นผู้ดำเนินงาน

• ผู้เขียนมองว่า AI ก้าวข้ามระดับการสร้างชิ้นส่วนโค้ดง่าย ๆ และสามารถจัดการ workflow ของงานพัฒนาจริงได้แล้ว
• ในอดีต มนุษย์ต้องคอยเฝ้าดูและแก้ไขผลลัพธ์ของ AI อยู่ตลอด แต่ตอนนี้สามารถมอบงานให้ AI แล้วตรวจทานผลลัพธ์ได้
• การปรับปรุงประสิทธิภาพของ benchmark อย่าง SWE Bench ถูกกล่าวถึงในฐานะตัวชี้วัดที่แสดงให้เห็นการเปลี่ยนแปลงนี้
• การเปลี่ยนแปลงสำคัญคือ คำถามไม่ได้อยู่ที่ “AI เขียนโค้ดได้หรือไม่” อีกต่อไป แต่เปลี่ยนเป็น “เราจะมอบงานให้ AI ได้ถึงขอบเขตไหน”

2. เมื่อ AI ล้มเหลว ปัญหาไม่ได้มีแค่ ‘ความสามารถไม่พอ’

• AI ยังไม่ได้ประสบความสำเร็จเสมอไป
• ยังเกิดกรณีที่ error วนซ้ำ หรือแม้จะบอกว่าแก้แล้ว แต่ปัญหายังคงเหลืออยู่บนหน้าจอจริง
• ตอนแรกผู้เขียนรับมือด้วยการให้มนุษย์คัดลอก error ไปส่งให้ AI
• ต่อมา เมื่อใช้ Playwright เพื่อให้ AI เปิดเบราว์เซอร์และทดสอบเองโดยตรง ผู้เขียนจึงตระหนักว่าขั้นตอนการตรวจสอบที่มนุษย์เคยทำก็สามารถมอบให้ AI ได้
• กรณีนี้แสดงให้เห็นว่า บางส่วนของสิ่งที่เคยคิดว่าเป็นข้อจำกัดของ AI จริง ๆ แล้วเป็นข้อจำกัดที่เกิดจากผู้ใช้ไม่ได้สั่งให้ AI ทำ

3. แนวคิด AI Native คือการมอบหมายทั้งกระบวนการ

• ผู้เขียนออกจากมุมมองที่ใช้ AI เป็นเพียงเครื่องมือช่วย และเปลี่ยนไปสู่แนวทางที่ทำให้ AI ดำเนินกระบวนการทั้งหมดที่ตนเองเคยทำ
• ผู้เขียนสร้างงานซ้ำ ๆ ให้เป็น command, skill และ workflow พร้อมพยายามระบุ tacit knowledge ของตนเองออกมาเป็นสเปก
• ตัวอย่างเช่น การสร้าง flow ของคำสั่งอย่าง /plan, /prd, /debug, /refactor, /verify, /retrospect
• จุดสำคัญไม่ใช่การบอก AI แค่ว่า “เขียนโค้ดให้หน่อย” แต่คือการกำหนดเป็นกฎไปถึงว่าเมื่อไรควรถาม เมื่อไรควรหยุด และเมื่อไรควรตรวจสอบ
• ด้วยวิธีนี้ นักพัฒนาจะเปลี่ยนวิธีทำงานและเกณฑ์การตัดสินของตนเองให้เป็นโครงสร้างที่ AI นำกลับมาใช้ซ้ำได้

4. know-how ส่วนบุคคลถูกดูดซับเป็นฟีเจอร์ของเครื่องมืออย่างรวดเร็ว

• command และ workflow ที่ผู้เขียนเคยสร้างเอง เมื่อเวลาผ่านไปก็ปรากฏเป็นฟีเจอร์และแนวคิดทางการอย่าง Skill, memory, hooks, orchestration
• methodology การใช้ AI ที่แต่ละคนค้นพบ ยิ่งมีประสิทธิภาพมากเท่าไรก็ยิ่งถูกดูดซับเป็นฟีเจอร์ผลิตภัณฑ์หรือ methodology ร่วมกันอย่างรวดเร็ว
• ดังนั้น prompt หรือ tip เฉพาะบางอย่างในการใช้ AI ให้เก่ง จึงสร้างความแตกต่างระยะยาวได้ยาก
• สิ่งสำคัญไม่ใช่ตัว methodology เองเท่านั้น แต่คือได้นำ methodology นั้นไปใช้กับปัญหาจริง สร้างได้ไกลแค่ไหน และเจอข้อจำกัดแบบใด

5. AI เพิ่มขนาดของปัญหาที่นักพัฒนาสามารถรับมือได้

• AI ทำให้ผู้เขียนสามารถทดลองไอเดียขนาดใหญ่ที่ในอดีตไม่กล้าลองเพราะต้นทุนและเวลา
• เช่น ลองสร้างเครื่องมือสำหรับกางโค้ดและเอกสารเหมือน canvas, MD viewer, เครื่องมือวิเคราะห์โค้ด และเครื่องมือช่วยพัฒนาได้อย่างรวดเร็ว
• แก่นสำคัญไม่ใช่ว่า AI สร้างผลิตภัณฑ์สำเร็จรูปให้ได้ทันที แต่คือการลดอุปสรรคในการเริ่มต้น
• นักพัฒนาจึงเปลี่ยนความคิดจาก “เราจะสร้างสิ่งนี้ได้ไหม” ไปเป็น “ลองดูก่อนว่าจะสร้างไปได้ไกลแค่ไหน”

6. เมื่อรับมือกับปัญหาใหญ่ งานพัฒนาที่อยู่นอกเหนือการเขียนโค้ดจะปรากฏชัด

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

7. จำนวน commit และ test ที่เพิ่มขึ้นไม่ได้หมายถึงผลิตภัณฑ์ดีขึ้นเสมอไป

• เมื่อใช้ AI จำนวน commit, ไฟล์, test และเอกสารจะเพิ่มขึ้นอย่างรวดเร็ว
• แต่การที่ตัวเลขเพิ่มขึ้นไม่ได้หมายความว่าผลิตภัณฑ์ดีขึ้นจริง
• เกิดปัญหาเช่นมีการเพิ่มฟีเจอร์ แต่ UX ดูฝืน ๆ หรือ test ผ่านแต่ flow บนหน้าจอจริงไม่เสถียร
• ตอนแรกผู้เขียนพยายามมองสิ่งนี้เป็นแค่ปัญหาคุณภาพโค้ดและโครงสร้าง
• แต่ได้เรียนรู้ว่า แม้จะปรับปรุงโครงสร้างโค้ดแล้ว ประสบการณ์ผลิตภัณฑ์ก็ไม่ได้ดีขึ้นโดยอัตโนมัติ
• สุดท้าย การผลิตโค้ดกับการปรับปรุงผลิตภัณฑ์เป็นคนละปัญหากัน และจำเป็นต้องมีการตัดสินเรื่องความเป็นผลิตภัณฑ์แยกต่างหาก

8. Frontend เป็นพื้นที่ที่ AI สั่นคลอนได้ง่ายเป็นพิเศษ

• AI สามารถสร้าง UI เริ่มต้นที่ดูน่าเชื่อถือได้อย่างรวดเร็ว เช่น dashboard, landing page, admin screen
• แต่ frontend ในระดับผลิตภัณฑ์จริงต้องการเกณฑ์ซับซ้อน เช่น design system, state management, accessibility, keyboard operation, exception state และ user flow
• requirements จำนวนมากของ frontend ถูกอธิบายด้วยภาษากำกวม เช่น “ให้เป็นธรรมชาติ”, “ให้ดูขัดน้อยลง”, “ให้รู้สึกว่าเลือกอยู่”
• AI มักทำให้ผลลัพธ์แตกกระจายได้ง่ายในกระบวนการเปลี่ยน requirements ที่กำกวมเหล่านี้เป็นโค้ด
• ดังนั้น หากต้องการใช้ AI ให้ดีในงาน frontend จำเป็นต้องมีเกณฑ์และวิจารณญาณในการตรึงส่วนที่ออกมาดีไว้ แล้วให้แก้เฉพาะส่วนที่ยังขาด

9. ผลลัพธ์ที่ดีไม่ได้ออกมาในครั้งเดียว แต่เกิดจากกระบวนการค่อย ๆ บรรจบ

• ผู้เขียนเปลี่ยนมุมมองหลังจากเห็น prototype คุณภาพสูงที่ planner คนหนึ่งสร้างด้วย AI
• ผลลัพธ์นั้นไม่ได้เกิดจาก prompt พิเศษเพียงอันเดียว แต่เป็นผลจากการแก้ซ้ำ ๆ “จนกว่าจะได้”
• กรณีนี้แสดงให้เห็นว่า แก่นของการใช้ AI ไม่ใช่การสร้างอัตโนมัติแบบง่าย ๆ แต่คือกระบวนการค่อย ๆ บรรจบที่มองเห็นส่วนที่ยังขาดแล้วร้องขอใหม่อย่างต่อเนื่อง
• คนที่สร้างผลลัพธ์ที่ดีจะตัดสินได้ว่า output ที่ AI สร้างขึ้นยังขาดอะไร และปรับอย่างไม่ลดละจนกว่าจะได้ระดับที่ต้องการ
• แม้ในยุค AI มาตรฐาน สัมผัส และการตรวจทานอย่างต่อเนื่องของมนุษย์ก็ยังสร้างความแตกต่างให้ผลลัพธ์

10. นักพัฒนามีบทบาทเชื่อมผลลัพธ์ที่มีศักยภาพให้ต่อยอดเป็นผลิตภัณฑ์

• ผลลัพธ์ที่สร้างด้วย AI อาจดูดีจากภายนอก แต่โครงสร้างโค้ดภายในอาจเปราะบาง
• อาจเกิดปัญหา เช่น state management ไม่เสถียร, ความรับผิดชอบของ component ไม่ชัดเจน หรือ test ไม่สามารถรับประกัน flow จริงได้
• บทบาทของนักพัฒนาไม่ใช่การประเมินผลลัพธ์เหล่านี้ต่ำหรือทิ้งไปโดยไม่มีเงื่อนไข
• ในขณะเดียวกัน ก็ไม่ควรนำไปทำเป็นผลิตภัณฑ์ตรง ๆ เช่นกัน
• นักพัฒนาต้องจัดโครงสร้าง ทำเครื่องหมายความเสี่ยง สร้างหน่วยที่ทดสอบได้ และทิ้งบริบทไว้ เพื่อให้ผลลัพธ์ที่มีศักยภาพไปต่อได้ไกลขึ้น
• กล่าวคือ บทบาทของนักพัฒนาขยายจาก “คนที่สร้างทุกอย่างคนเดียวจนจบ” ไปเป็น “คนที่เชื่อมผลลัพธ์ที่ AI และมนุษย์สร้างขึ้นให้กลายเป็นผลิตภัณฑ์ที่ยั่งยืน”

11. บทบาทการพัฒนาในยุค AI ไม่ได้บรรจบเป็นแบบเดียว

• เมื่ออุปสรรคในการเขียนโค้ดลดลง ประเภทของคนที่เข้าร่วมการพัฒนาก็หลากหลายขึ้น
• planner, designer, PM และผู้รับผิดชอบหน้างานก็สามารถใช้ AI สร้าง prototype ที่ทำงานได้หรือ internal tool ได้
• สิ่งนี้ไม่ได้หมายความว่าความจำเป็นของนักพัฒนาหายไป แต่หมายความว่าบทบาทที่เกี่ยวข้องกับการพัฒนาจะถูกแยกย่อยมากขึ้น
• ผู้เขียนเปรียบสิ่งนี้กับ ecosystem ของ YouTube
• เช่นเดียวกับที่ YouTube ไม่ได้ทำให้ผู้เชี่ยวชาญวิดีโอหายไป แต่ทำให้บทบาทหลากหลายขึ้น ทั้งผู้ปรากฏตัวในคลิป, editor, planner, channel operator และ platform creator, AI ก็อาจทำให้บทบาทการพัฒนาหลากหลายขึ้นได้เช่นกัน
• ในอนาคต มีความเป็นไปได้สูงที่คนสร้างระบบเชิงลึก, คนขัดเกลา prototype ให้เป็นผลิตภัณฑ์, คนสร้าง layer ที่ช่วยให้ AI ทำงานได้ดี และคนแก้ปัญหาโดยตรง จะอยู่ร่วมกัน

---

สรุป

นักพัฒนาต้องออกแบบการพัฒนาหลังยุคการเขียนโค้ด

• ข้อสรุปของโพสต์นี้ไม่ใช่การแบ่งสองขั้วว่า “ควรเขียนโค้ดต่อไปหรือควรวางมือ”

• เมื่อ AI สามารถทำการเขียนโค้ดได้ นักพัฒนาจึงต้องเรียนรู้จากประสบการณ์ว่าอะไรควรมอบให้ AI และอะไรต้องตัดสินเอง

• โดยเฉพาะทักษะต่อไปนี้จะสำคัญขึ้น

  • ความสามารถในการตั้งปัญหาให้ใหญ่ขึ้น
  • ความสามารถในการเปลี่ยนกระบวนการซ้ำ ๆ ให้เป็น skill และ workflow
  • ความสามารถในการจัดโครงสร้าง requirements, เอกสาร, test และ issue
  • ความสามารถในการตรวจทานผลลัพธ์จาก AI และสั่งแก้ส่วนที่ยังขาด
  • ความสามารถในการขัดเกลาผลลัพธ์ดิบให้เป็นผลิตภัณฑ์ที่ยั่งยืน
  • ความสามารถในการเชื่อม AI เข้ากับเครื่องมือและ workflow นอกโค้ด

ข้อความหลัก

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