- เมื่อผู้ช่วยเขียนโค้ดแบบเอเจนต์มีความสามารถมากขึ้น ปฏิกิริยาตอบรับก็มีความหลากหลายมาก โดยบางคนถึงกับอ้างว่า "ภายใน 1 ปี นักพัฒนาจะไม่จำเป็นอีกต่อไป"
- ขณะที่อีกหลายคนกังวลเกี่ยวกับ คุณภาพของโค้ด ที่ AI สร้างขึ้น และ วิธีเตรียมนักพัฒนารุ่นจูเนียร์ให้พร้อมกับสภาพแวดล้อมที่กำลังเปลี่ยนไปนี้
- ในช่วงหลายเดือนที่ผ่านมา ผู้เขียนได้ใช้ผู้ช่วยเขียนโค้ดแบบเอเจนต์อย่าง Cursor, Windsurf, Cline และพบว่ามันมีประสิทธิภาพมากในการแก้ไข codebase เดิม
- ผู้เขียนประทับใจมากกับการผสานเข้ากับ IDE ซึ่งรวมถึงการรันทดสอบและแก้ข้อผิดพลาดอัตโนมัติ การตรวจจับและแก้ lint/compile error การค้นหาเว็บ และฟีเจอร์ browser preview
- ประสบการณ์การทำงานร่วมกันระหว่างนักพัฒนากับ AI น่าประทับใจมาก และช่วยให้แก้ปัญหาและพัฒนาฟีเจอร์ได้รวดเร็ว
- อย่างไรก็ตาม ก็ยังต้องการการแทรกแซง การแก้ไข และการกำหนดทิศทางจากนักพัฒนาอย่างต่อเนื่อง
- หลายกรณีก็ไม่ได้ไปถึงขั้น commit จริง และ AI ยังไม่ดีพอที่จะเขียนโค้ดสำหรับงานที่ไม่เล็กน้อยได้อย่างอัตโนมัติ
- ดังนั้น ทักษะและประสบการณ์ของนักพัฒนาจึงยังคงสำคัญ และต้องได้รับการฝึกฝนต่อไปในอนาคต
ช่วงเวลาที่นักพัฒนาต้องเข้าไปแทรกแซงด้วยตนเอง
- เครื่องมือ AI แสดงให้เห็นถึง จุดอ่อนอย่างสม่ำเสมอ ในบางด้าน และสิ่งนี้ถูกยืนยันซ้ำแล้วซ้ำเล่า
- บางกรณี บรรเทาได้บางส่วน ด้วยการเพิ่มพรอมป์หรือกฎเฉพาะทาง แต่ ไม่สามารถควบคุมได้อย่างสมบูรณ์
- LLM มักจะ ไม่ทำตามคำสั่งในพรอมป์อย่างแม่นยำ
- ยิ่ง session การเขียนโค้ดยาวขึ้น ความสม่ำเสมอของผลลัพธ์ก็ยิ่งลดลง
- ดังนั้น กรณีตัวอย่างที่จะแนะนำต่อไปนี้จึงเป็น ปัญหาที่สามารถเกิดขึ้นได้มากพอ โดยไม่ขึ้นกับพรอมป์หรือการตั้งค่า
- ผู้เขียนจัดหมวดหมู่ความผิดพลาดของ AI ออกเป็น 3 กลุ่มตาม ขอบเขตผลกระทบ
- a. ความเร็วในการพัฒนาลดลงและเวลาไปถึง commit นานขึ้น
- AI กลับทำให้ช้าลงเสียเอง
- บางครั้งไม่มีประสิทธิภาพยิ่งกว่าการเขียนโค้ดโดยไม่มีตัวช่วย
- b. สร้างแรงเสียดทานต่อ workflow การทำงานของทีม
- เกิดความขัดแย้งหรือปัญหาการทำงานร่วมกันภายในหนึ่ง iteration
- c. ทำให้ความสามารถในการบำรุงรักษาโค้ดระยะยาวแย่ลง
- ตอนแรกอาจดูไม่มีปัญหา แต่จะเกิดปัญหาเมื่อมีการเปลี่ยนแปลงหรือขยายระบบในอนาคต
- ยิ่งขอบเขตผลกระทบกว้างขึ้น วงจร feedback ที่ทีมจะรับรู้และแก้ไขปัญหานั้นก็จะ ยาวขึ้น
ขอบเขตผลกระทบ: เวลาที่ล่าช้าจนกว่าจะ commit
- หมวดนี้ประกอบด้วยกรณีที่ AI ขัดขวางมากกว่าช่วยเหลือ
- เนื่องจากเป็นรูปแบบความล้มเหลวที่ชัดเจนที่สุด จึง ไม่ใช่ปัญหาใหญ่เป็นพิเศษ
- ส่วนใหญ่นักพัฒนาจะสังเกตและป้องกันได้ก่อนถึงขั้น commit
-
โค้ดที่ใช้งานไม่ได้
- โค้ดที่ AI สร้างขึ้น ใช้งานไม่ได้ตั้งแต่ต้น
- นักพัฒนาต้องแก้เอง หรือยุติ session ของ AI แล้ว แก้ปัญหาด้วยมือ
- นักพัฒนาที่มีประสบการณ์สามารถ ประเมินได้อย่างรวดเร็วว่าผิดตรงไหนและจัดการได้
-
วินิจฉัยปัญหาผิด
- AI ตัดสินสาเหตุของปัญหาผิด และ พยายามแก้ไปในทิศทางที่ไม่เกี่ยวข้อง
- จากประสบการณ์ที่ผ่านมา นักพัฒนาสามารถ ดึง AI กลับมาจากเส้นทางที่ผิด ได้
> ตัวอย่าง: เข้าใจ Docker build error ผิดว่าเป็นปัญหาการตั้งค่าสถาปัตยกรรม จึงไปแก้การตั้งค่า
> สาเหตุจริงคือการคัดลอก node_modules ที่ build มาจากสถาปัตยกรรมที่ไม่ถูกต้อง
> เนื่องจากเป็นปัญหาที่เคยเจอบ่อยมาก่อน จึงสังเกตและแก้ให้ถูกได้อย่างรวดเร็ว
ขอบเขตผลกระทบ: workflow การทำงานของทีมภายใน iteration
- หมวดนี้คือกรณีที่เกิด แรงเสียดทานในทีมระหว่างช่วง iteration เพราะการรีวิวหรือการแทรกแซงจากนักพัฒนาไม่เพียงพอ
- ผู้เขียนสามารถ รับรู้และปรับแก้ปัญหาเหล่านี้ได้ก่อน commit จากประสบการณ์ที่เคยทำงานกับทีมหลากหลายรูปแบบ
- นักพัฒนามือใหม่เองก็อาจได้เรียนรู้บทเรียนเหล่านี้ผ่านการลองผิดลองถูกกับ AI
- แต่ถ้า ความเร็วในการเขียนโค้ดเพิ่มขึ้นเพราะ AI ทีมอาจ รับมือกับปัญหาเหล่านี้ไม่ทัน
-
งานช่วงต้นที่มากเกินไป
- AI มีแนวโน้มจะทำฟีเจอร์ทั้งก้อนในคราวเดียวอย่างกว้าง ๆ มากกว่าการค่อย ๆ ทำแบบ incremental
- ด้วยเหตุนี้ ถ้าการเลือกเทคโนโลยีไม่เหมาะสมหรือเข้าใจ requirement ผิด ก็อาจ สูญเสียงานจำนวนมากโดยเปล่าประโยชน์
> ตัวอย่าง: ระหว่าง migration frontend stack พยายามแปลง UI component ทั้งหมดในคราวเดียว
> ที่จริงควรเริ่มแบบค่อยเป็นค่อยไปจาก คอมโพเนนต์เดียวที่เชื่อมกับ backend
-
แก้ปัญหาแบบมุทะลุโดยไม่วิเคราะห์สาเหตุ
- AI ใช้วิธีแก้เฉพาะข้อผิดพลาดที่เห็นภายนอก โดยไม่วิเคราะห์รากสาเหตุของปัญหา
- ส่งผลให้สมาชิกทีมคนอื่นที่มารับช่วงต่อ ต้องมานั่งวิเคราะห์ปัญหาใหม่โดยไม่มีบริบท
> ตัวอย่าง: เมื่อเกิด memory error ระหว่าง Docker build ก็เพิ่มการตั้งค่าหน่วยความจำอย่างเดียวแทนที่จะหาสาเหตุ
-
ทำให้ workflow ของนักพัฒนาซับซ้อนขึ้น
- วิธี build/run ที่ AI สร้างขึ้นทำให้ประสบการณ์ของนักพัฒนาแย่ลง
- หาก commit ทันที ก็จะ ส่งผลเสียต่อ workflow ของเพื่อนร่วมทีมคนอื่นด้วย
> ตัวอย่าง: แยกคำสั่งสำหรับรัน frontend และ backend ออกจากกัน
> ตัวอย่าง: ไม่มีฟีเจอร์ hot reload
> ตัวอย่าง: การตั้งค่า build ที่ซับซ้อนทำให้ทั้งนักพัฒนาและ AI สับสน
> ตัวอย่าง: ไม่สามารถตรวจจับ Docker error ได้ล่วงหน้า และพยายามจัดการข้อผิดพลาดตอนท้ายของการ build
-
Requirement ที่เข้าใจผิดหรือไม่สมบูรณ์
- หากไม่ได้อธิบาย requirement ของฟีเจอร์ให้ชัดเจน AI อาจ เข้าใจผิดและไปพัฒนาฟีเจอร์ในทิศทางที่ไม่ถูกต้อง
- การเข้าไปแก้ตั้งแต่ต้นเป็นทางที่ดีที่สุด แต่ทั้ง AI ที่ทำงานอัตโนมัติและนักพัฒนาที่ไม่รอบคอบต่างก็ทำให้ ต้นทุนการแก้ตามมาภายหลังสูงขึ้น
- การพัฒนาที่ผิดทางเหล่านี้มักถูกค้นพบทีหลังระหว่างดำเนิน story และทำให้เกิด งานแก้ไขจำนวนมากและต้นทุนการสื่อสารเพิ่มขึ้น
ขอบเขตผลกระทบ: ความสามารถในการบำรุงรักษาระยะยาวที่ลดลง
- นี่คือขอบเขตผลกระทบที่ แฝงตัวและอันตรายที่สุด
- ในช่วงแรกโค้ดอาจทำงานได้โดยไม่มีปัญหา แต่ภายหลังจะ แก้ไขและขยายต่อได้ยากขึ้น
- ปัญหาเหล่านี้มัก ถูกค้นพบหลังจากผ่านไปหลายสัปดาห์ถึงหลายเดือน
- โดยเฉพาะในด้านนี้ ประสบการณ์พัฒนากว่า 20 ปีของผู้เขียนมีบทบาทมากที่สุด
-
โค้ดทดสอบที่ยืดยาวและซ้ำซ้อน
- AI สร้างเทสต์ได้เก่ง แต่ก็มักเกิดปัญหาต่อไปนี้บ่อยครั้ง:
- ไม่รวมเข้ากับเทสต์เดิม แต่กลับ สร้าง test function ใหม่
- เพิ่ม assertion มากเกินไป แม้ในส่วนที่ครอบคลุมอยู่แล้ว
- จุดที่นักพัฒนามือใหม่อาจเข้าใจผิดคือ: เทสต์มากขึ้น ≠ เทสต์ที่ดีกว่า
- ยิ่งมีความซ้ำซ้อนมากเท่าไร การบำรุงรักษาก็ยิ่งยาก และเมื่อโค้ดเปลี่ยนก็มีโอกาส ที่เทสต์จะล้มจำนวนมาก
- แม้จะพยายามบรรเทาด้วยคำสั่งกำหนดเอง แต่ปัญหานี้ก็ยังเกิดขึ้นบ่อย
-
การนำกลับมาใช้ซ้ำได้ต่ำ
- โค้ดที่ AI เขียนมัก ขาดการทำเป็นโมดูล จึงนำกลับมาใช้ซ้ำได้ยาก
> ตัวอย่าง: ไม่รู้ว่ามี UI component ที่มีอยู่แล้ว จึงเขียนซ้ำขึ้นมาอีก
> ตัวอย่าง: ใช้ inline style อย่างหนักแทนการใช้ CSS class
-
โค้ดที่ซับซ้อนหรือยืดยาวเกินจำเป็น
- AI มักสร้าง โค้ดมากเกินความจำเป็น จนต้องลบส่วนที่ไม่จำเป็นออกด้วยมืออยู่บ่อย ๆ
- สิ่งนี้เพิ่มต้นทุนการดูแลรักษา และ เพิ่มโอกาสเกิดข้อผิดพลาดเมื่อมีการเปลี่ยนแปลง
> ตัวอย่าง: เวลาแก้ CSS ต้องคอยลบ style ที่ซ้ำกันจำนวนมากทีละจุด
> ตัวอย่าง: สร้าง web component ที่ซับซ้อนเกินจำเป็นเพื่อแสดงข้อมูล JSON
> ตัวอย่าง: ระหว่างการ refactor AI ไม่รับรู้ dependency injection chain ที่มีอยู่เดิม
> จึงส่งค่าที่ถูก inject อยู่แล้วซ้ำอีกครั้งผ่านพารามิเตอร์อื่น ทำให้ดีไซน์ซับซ้อนขึ้น
> - ในรูปแบบ value = service_a.get_value(); ServiceB(service_a, value=value)
บทสรุป: AI จะเขียนโค้ดแทนทั้งหมดได้หรือไม่?
- จากประสบการณ์จนถึงตอนนี้ เป็นไปไม่ได้ในทางปฏิบัติที่ AI จะเขียนโค้ด 90% ของทั้งระบบได้อย่างอัตโนมัติภายใน 1 ปี
- อย่างไรก็ตาม ในบทบาทของ ผู้ช่วยเขียนโค้ด ก็มีความเป็นไปได้ว่าจะ ช่วยได้ถึง 90% สำหรับบางทีมและบาง codebase
- ในความเป็นจริง ผู้เขียนกำลังได้รับความช่วยเหลือจาก AI ราว 80% ในโปรเจกต์ความซับซ้อนระดับกลางขนาด 15K LOC
วิธีป้องกันความผิดพลาดของ AI
-
สิ่งที่นักพัฒนารายบุคคลทำได้
- รีวิวโค้ดที่ AI สร้างอย่างระมัดระวังเสมอ
- แทบไม่มีกรณีไหนที่ไม่ต้องแก้เลย
- หาก session ของ AI เริ่มสับสน ให้หยุดทันที
- ปรับพรอมป์ใหม่ หรือเปลี่ยนไปทำด้วยมือเลยก็ได้ (บางคนเรียกว่า "handmade coding")
- ระวังโซลูชันที่ "ดูเหมือนดี" และเสร็จอย่างน่าอัศจรรย์ในเวลาอันสั้น
- อาจมีต้นทุนการบำรุงรักษาระยะยาวซ่อนอยู่
- ทำ pair programming
- 4 ตา 2 สมอง ช่วยให้ตัดสินใจได้ดีกว่า
-
กลยุทธ์รับมือในระดับทีมและองค์กร
- ใช้เครื่องมือติดตามคุณภาพโค้ดที่มีอยู่ให้เต็มที่
- เช่น Sonarqube, Codescene
- เมื่อใช้เครื่องมือ AI ควรเฝ้าดู code duplication, code smell ฯลฯ อย่างใกล้ชิดยิ่งขึ้น
- ตั้งค่า pre-commit hook และ code review ที่ผสานกับ IDE
- เสริมกลยุทธ์ shift-left เพื่อจับปัญหาตั้งแต่ช่วงต้นของการพัฒนา
- ฟื้นฟูนิสัยด้านคุณภาพโค้ดที่ดี
- แชร์กรณีปัญหาที่เกิดจากโค้ด AI ("Go-wrong log") ใน retrospective รายสัปดาห์ของทีม
- ใช้ custom rule อย่างจริงจัง
- เครื่องมือ AI ส่วนใหญ่สามารถตั้งค่า ชุดกฎที่ส่งไปพร้อมกับพรอมป์ ได้
- ทีมสามารถช่วยกันปรับปรุง ruleset เพื่อลดความผิดพลาดของ AI
- อย่างไรก็ตาม ยิ่ง session ยาวขึ้น โอกาสที่ AI จะละเลยกฎก็ยิ่งเพิ่มขึ้น
- สร้างวัฒนธรรมทีมที่ตั้งอยู่บนความไว้วางใจและการสื่อสาร
- การนำ AI มาใช้เป็นการเปลี่ยนแปลงรูปแบบใหม่ และควรตระหนักว่า ทุกคนยังเป็นมือใหม่
- การกดดันแบบ "มี AI แล้วก็ต้องทำให้เร็วขึ้นสิ" จะ เพิ่มความเสี่ยงด้านคุณภาพ
- ทีมที่มีความปลอดภัยทางจิตใจจะ แบ่งปันปัญหาและเรียนรู้ร่วมกันได้อย่างกระตือรือร้นกว่า
4 ความคิดเห็น
คนที่ใช้เครื่องมือนั้น ไม่ว่าจะมีความสามารถแค่ไหนก็น่าจะล้วนเป็นนักพัฒนากันอยู่แล้ว.... การโฆษณาในทำนองว่าอนาคตจะไม่ต้องการนักพัฒนาอีกต่อไป ดูเหมือนจะมีส่วนที่แปลก ๆ อยู่เหมือนกันนะ
ต่อจากนี้จะเป็นอย่างไรยังไม่รู้ แต่ตอนนี้ดูเหมือนว่ายังไม่ค่อยเหมาะจะใช้เป็นกระแสหลัก... ช่วงหลังผมลองใช้ Cursor ดู แต่มันยังจับแม้แต่ import path พื้นฐานของไฟล์ได้ไม่ค่อยถูกเลยครับ ถึงอย่างนั้น การที่มันพอจะคาดเดาสิ่งที่ผมอยากสร้างได้ล่วงหน้าระดับหนึ่งก็ถือว่าน่าทึ่งเหมือนกัน
พอเกิดข้อผิดพลาดเรื่องหน่วยความจำระหว่างการ build Docker ก็เพิ่มการตั้งค่าหน่วยความจำแทนที่จะถามตั้งแต่แรกว่าทำไมถึงใช้หน่วยความจำมากขนาดนั้น
-> ก็นี่แหละ.. เพราะที่ผ่านมาเราเคยทำแบบนี้มาแล้วนับครั้งไม่ถ้วน
-> AI ในตอนนี้ก็คือตัวเราในอดีต
ความคิดเห็นบน Hacker News
ช่วงนี้ใช้ Cursor กับงานพัฒนาส่วนใหญ่ บทความนี้คล้ายกับประสบการณ์ของฉันมาก
ฉันใช้ AI แบบนี้: ใช้มันเป็นตัวช่วยเขียนใน IDE และมันตอบฉันเหมือนเป็ดยางสุดเท่ที่ซับซ้อนมากตัวหนึ่ง
ฉันไม่เข้าใจเลยจริง ๆ
ตัวอย่าง: ตอนเกิด memory error ระหว่าง Docker build มันกลับเพิ่มค่า memory setting แทนที่จะถามก่อนว่าทำไมตั้งแต่แรกถึงใช้หน่วยความจำมากขนาดนั้น
ทักษะของนักพัฒนายังคงจำเป็น — ถ้าคุณขับไม่เป็น คุณก็บังคับมันไม่ได้ แต่พลังงานของนักพัฒนาล่ะ? ก่อนมี AI ฉันเขียนโค้ดได้วันละประมาณ 2 ชั่วโมงเท่านั้น (หมายถึงเวลาที่เขียนโค้ดจริง ๆ) แต่พอใช้ Claude Code ฉันเขียนต่อเนื่อง 5 ชั่วโมงได้สบาย ๆ มันเหมือนเปลี่ยนจากจักรยานธรรมดาเป็นจักรยานไฟฟ้า AI ให้ความรู้สึกเหมือนอุปมา "จักรยานสำหรับจิตใจ" ของ Steve Jobs — มันไม่ได้มาแทนที่ฉัน แต่มันทำให้ฉันไปได้ไกลขึ้นและเร็วขึ้นมาก
ไดอะแกรมนี้โดนใจมาก — ทีมของเราเช็กครบทุกข้อในนี้ ทั้งที่ยังไม่ได้ใช้ AI ด้วยซ้ำ! ลองนึกดูสิว่าถ้าสุดท้ายเราเริ่มใช้ AI จะเป็นยังไง...
สำหรับฉัน สิ่งที่ดูชัดเจนไม่ได้ชัดเลย: คนรอบตัวฉันใช้ AI กัน
ฉันต้องคอยบังคับ AI เยอะมาก แต่ก็ยังมองโลกในแง่ดีว่า prompt ที่ดีขึ้นจะนำไปสู่ agent ที่ดีขึ้น
อยากเกริ่นก่อนว่าเครื่องมือ AI ไม่ได้แย่กับทุกอย่างที่ฉันลิสต์ไว้
ตอนนี้ Martin Fowler ปล่อยเช่าพื้นที่บนเว็บไซต์ของเขาแล้วหรือ?