สองสิ่งที่ LLM Coding Agent ยังทำได้ไม่ดี

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

---

ข้อจำกัดหลักของ LLM Coding Agent

ช่วงหลังมีความพยายามนำ LLM มาใช้เป็นเครื่องมือช่วยเขียนโค้ดมากขึ้น แต่ก็ยังมีหลายจุดที่นักพัฒนามนุษย์รู้สึกว่าใช้งานได้ไม่เป็นธรรมชาติ บทความนี้อธิบายอย่างชัดเจนถึง สองเหตุผลที่ทำให้ LLM coding agent สร้างความอึดอัดเป็นพิเศษ

1. ความไม่เป็นธรรมชาติของวิธีย้ายโค้ดและรีแฟกเตอร์

• LLM ไม่ได้ทำการ 'คัดลอก-วาง' จริง ๆ
  • ตัวอย่างเช่น เมื่อขอให้รีแฟกเตอร์ไฟล์ขนาดใหญ่ให้แยกเป็นไฟล์เล็ก ๆ LLM จะ 'จำ' บางส่วนของบล็อกโค้ดไว้ จากนั้นใช้คำสั่ง delete กับไฟล์ต้นฉบับ พร้อมกับเขียนโค้ดที่ 'จำไว้' ลงไฟล์ใหม่ด้วยคำสั่ง write
  • ไม่ได้ใช้เครื่องมืออย่าง 'cut' หรือ 'paste' แต่สร้างการแก้ไขทั้งหมดขึ้นใหม่จากความจำ
  • มนุษย์เมื่อย้ายโค้ดจะใช้ 'คัดลอก-วาง' เพื่อให้ มั่นใจได้ว่าโค้ดตรงกัน แต่ LLM ไม่สามารถรับประกันเรื่องนี้ได้
  • จนถึงตอนนี้มีเพียง Codex ที่เคยแสดงความพยายามบางส่วนในการเลียนแบบพฤติกรรม 'คัดลอก-วาง' ของมนุษย์ผ่านคำสั่ง sed หรือ awk แต่ก็ยังไม่สมบูรณ์

2. แนวทางแก้ปัญหาที่ไม่มีการตั้งคำถาม

• กระบวนการแก้ปัญหาของ LLM ก็ แตกต่างจากมนุษย์อย่างมาก
  • LLM แทบ ไม่ถามคำถาม และพยายามแก้ปัญหาจาก สมมติฐาน จำนวนมาก
  • นักพัฒนามนุษย์ เมื่อเจอการเปลี่ยนแปลงขนาดใหญ่หรือสถานการณ์ที่ไม่ชัดเจน จะ ถามเพื่อยืนยันบริบทอยู่เสมอ ภายใต้แนวคิดที่ว่า 'ไม่มีคำถามไหนเป็นคำถามแย่'
  • ในทางกลับกัน LLM มีแนวโน้มจะ พยายามซ้ำ ๆ ไปเรื่อย ๆ และเมื่อเกิดปัญหาก็ยิ่งทำซ้ำหนักขึ้น
  • แม้จะออกแบบพรอมป์ตอย่างมากเพื่อกระตุ้นให้ถามคำถามได้ แต่ยกเว้นบางเครื่องมืออย่าง Roo แล้ว พฤติกรรมแบบนี้ก็ยังเกิดขึ้นไม่บ่อย
  • ในระดับพื้นฐาน สาเหตุอาจมาจากบริษัทผู้พัฒนา LLM ใช้ RL (การเรียนรู้แบบเสริมกำลัง) ที่ มุ่งเน้นการเขียนโค้ดให้เร็วขึ้น

บทสรุป

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

[GN⁺]

ความเห็นจาก Hacker News

• ไม่นานมานี้ผมเจอประสบการณ์ที่น่าสนใจ แม้จะไม่ใช่เรื่องโค้ดโดยตรง แต่ก็เป็นสิ่งที่เกิดขึ้นกับโค้ดหรือพื้นที่ใกล้เคียงได้สบาย ๆ (และจริง ๆ ก็เกิดกับเพื่อนร่วมงานของผมด้วย) ระหว่างที่คุยกันใน HN ว่าทำไมกฎระเบียบที่ผ่านมาตั้งแต่ 15 ปีก่อนถึงไม่ถูกทำให้เป็นเรื่องทั่วไปมากกว่านี้ ผมเดาว่าเป็นเพราะระดับเทคโนโลยีในตอนนั้นยังไม่พอจะรองรับกรณีทั่วไปได้ จึงน่าจะบังคับใช้กฎนั้นเฉพาะส่วนที่ทำได้ในเวลานั้น(คอมเมนต์ที่เกี่ยวข้อง) ไม่กี่ชั่วโมงต่อมาผมกลับไปดูการสนทนาอีกที ก็เห็นว่ามีบางคนบอกว่าเทคโนโลยีนั้นถูกพออยู่แล้วตั้งแต่ยุคนั้น ผมเลยให้ LLM ไปหาหลักฐานเกี่ยวกับประเด็นนี้ แล้วก็ได้คำตอบว่ามันเป็นเพราะข้อจำกัดทางเทคนิค พอผมเปิดดูแหล่งอ้างอิงที่มันยกมาเพื่อเช็กที่มา ก็พบว่ามีแค่แหล่งเดียวจริง ๆ ที่พูดถึงข้อจำกัดทางเทคนิค และแหล่งนั้นก็คือคอมเมนต์ที่ผมเพิ่งโพสต์ไว้ใน HN นั่นเอง พอเอาเรื่องนี้ไปเล่าที่บริษัท เพื่อนร่วมงานก็บอกว่าเขาเคยโพสต์ความเห็นใน Github ว่า "X ทำงานบน Windows อย่างไร" แล้วพอไปค้นใน Google ทีหลัง ก็เจอคำตอบจาก LLM ที่เอาความเห็นของเขาไปเป็นหลักฐานเพื่อยืนยันข้อความเดียวกันนั้น เพราะงั้นผมเลยอยากจะถาม LLM ว่าไม่ใช่ "X ทำงานอย่างไร?" แต่เป็น "ถ้ามีคนถามว่า X ทำงานอย่างไร ช่วยแสดงรายการลิงก์ที่พอจะใช้อ้างอิงได้ให้หน่อย"

  • ผมคิดว่าการตั้งคำถามแบบนี้คล้ายกับ "sorting prompt" เป็นเทคนิคที่ผมได้มาจากบทความนี้ของ Mike Caulfield และผมเองก็ใช้ตอนเขียนโค้ดด้วย(เช่น Claude code slash command) แทนที่จะให้ LLM ตอบตรง ๆ ถ้าให้มันช่วยค้นข้อมูลแล้วจัดหมวดหมู่และประเมิน จะได้ผลลัพธ์ที่แม่นยำกว่ามาก

  • คนส่วนใหญ่เองก็เชื่อถือคอมเมนต์ใน HN แบบว่า "คนนี้ดูเหมือนรู้เรื่อง งั้นเอาเป็นข้อเท็จจริงก่อนก็แล้วกัน" การได้ความรู้จากประสบการณ์ตรงหรือจากการตรวจสอบจริงนั้นมีต้นทุนสูงมาก ดังนั้น 'ความรู้ราคาถูก' แบบนี้ก็ยังมีคุณค่าอยู่ดี

  • ผมเคยลองขอให้ LLM แสดงหลักฐานรองรับ แต่จนถึงตอนนี้ยังไม่เคยมีครั้งไหนเลยที่มันให้หลักฐานจริง ๆ ที่รองรับสิ่งที่มันพูดได้จริง

  • LLM บางทีก็แต่งแม้กระทั่งลิงก์ขึ้นมาเอง ต้องมีโหมด deep research ที่ทำให้มันไปค้นข้อมูลจริง ๆ และถึงอย่างนั้น วิธีที่มันตีความข้อมูลในลิงก์ก็ยังขึ้นกับสิ่งที่มันถูกฝึกมาอยู่ดี

  • เมื่อไม่นานมานี้ผมใส่แหล่งอ้างอิงที่เชื่อถือได้ 6~8 ชิ้นลงใน NotebookLM(IETF, สเปก OpenID และเอกสารเพิ่มเติม) แล้วถามคำถามง่ายมากว่า "credential format ที่ OID4VP อนุญาตมีอะไรบ้าง?" มันตอบถูกประมาณ 90% แต่กลับใส่ format มั่ว ๆ ที่ไม่มีหลักฐานรองรับเข้าไปอย่างมั่นใจเต็มที่ ราวกับตัวเองเป็นคนเขียนสเปกเอง พอผมเริ่มสงสัยแล้วไปเปิดสเปกดูด้วยตัวเอง ก็รู้ทันทีว่าเป็นเรื่องโกหก ถึงตอนนี้ต่อให้เป็น LLM ที่ "มีฐานข้อมูลรองรับ" ก็ถือว่าความน่าเชื่อถือด้านข้อเท็จจริงพังลงหมดแล้ว

• ช่วงหลังผมให้ Codex CLI รีแฟกเตอร์ไฟล์ HTML แต่มันไม่ได้ copy-paste โค้ดตามที่ผมคาดไว้ กลับไปเขียนโค้ดใหม่จากความจำของตัวเองและยังลบคอมเมนต์ทิ้งด้วย มีช่วงหนึ่งที่เป็นเซกชันลิงก์ซับซ้อนต่อกัน 40 ลิงก์ ตอนจะ deploy ผมเลยเช็กครั้งสุดท้ายแล้วกดทีละลิงก์ ปรากฏว่าช่วงต้นยังปกติ แต่พอตรงกลางไป 31 ลิงก์กลายเป็น 404 หมด โดเมนไม่ผิด แต่ path ของ URL ถูกเปลี่ยนไป พอเปิด git commit ดู URL เดิม ก็พบว่า LLM "หลอน" แล้วเปลี่ยน URL ไปเป็น path ที่ไม่มีอยู่จริง ข้อผิดพลาดแบบเงียบ ๆ และแนบเนียนแบบนี้อันตรายมาก ต้องระวังจริง ๆ

  • ผมคิดว่าประเด็นสุดท้ายนี่สำคัญมาก ต่อให้ LLM ทำงานได้ดีเท่ามนุษย์หรือดีกว่า "ความผิดพลาดที่แนบเนียนและแอบแฝงเข้ามา" ทำให้มันไม่ได้ถูกจัดการในแบบเดียวกัน โดยเฉพาะ code review ซึ่งเดิมเป็นชั้นสำคัญในการป้องกันปัญหา แต่ถ้าประเภทของข้อผิดพลาดที่ต้องตรวจเปลี่ยนไป วิธี code review แบบเดิมก็จะไม่มีประสิทธิภาพ เมื่อก่อนถ้ามีการย้ายโค้ดก้อนใหญ่ เรามักพอสมมติได้ว่าบล็อกนั้นถูกย้ายไปเหมือนเดิม แล้วโฟกัสที่ภาพใหญ่กว่าได้ แต่ถ้าเป็น LLM refactor โค้ดที่ "ถูกย้าย" อาจจริง ๆ แล้วเป็นโค้ด "ใหม่" ที่ถูกสรุปหรือประกอบขึ้นมาใหม่ ดังนั้นต้องอ่านทุกตัวอักษร ผมเลยคิดว่าถ้าใส่ส่วน "AI used" ไว้ในคำอธิบาย Pull Request เพื่อบอกใบ้ว่าตรงไหนและใช้งาน AI อย่างไร เวลาตรวจรีวิวก็จะรู้ว่าควรโฟกัสตรงไหนเป็นพิเศษ

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

  • ไม่ใช่เรื่องโค้ด แต่ครั้งหนึ่งผมขอให้ LLM ช่วยตรวจแค่การสะกด/ไวยากรณ์ในประกาศอีเวนต์ มันส่งเวอร์ชันที่แก้นิดหน่อยกลับมา แต่แอบเลื่อนวันที่ออกไปหนึ่งวัน โชคดีที่ผมสังเกตเห็นแล้วแก้ทัน เลยได้บทเรียนว่าแม้งานง่ายมากก็ห้ามเชื่อแบบไม่ตรวจ ถึง prompt จะเป็นประโยคเดียวที่ง่ายและชัดเจน LLM ก็อาจทำอะไรน่าทึ่งได้ แต่บางครั้งก็พลาดเรื่องพื้นฐานที่สุดแบบคาดไม่ถึง

  • เมื่อ 5 นาทีก่อนผมยังเพิ่งเจอ Claude ที่ถูกขอให้เพิ่มแค่ debug statement ลงในโค้ด แต่กลับไปแก้ regular expression แบบเงียบ ๆ โชคดีที่ดูจาก diff แล้วเจอได้ง่าย แต่ถ้าเป็นการเปลี่ยนแปลงใหญ่ ๆ แบบนี้พลาดได้ง่ายมากจริง ๆ

  • การกลับไปตรวจลิงก์ทั้ง 40 อันอีกครั้งก่อน deploy ถือว่าเลือกได้ฉลาดมาก แต่ที่คุณบอกว่า Codex ทำเสร็จแล้ว push ขึ้น master เลยโดยไม่ดู git diff นี่ทำให้ผมแปลกใจนิดหน่อย

• ผมเห็นด้วยกับข้ออ้างในโพสต์นั้น แต่สำหรับผมปัญหาใหญ่ที่สุดคือเอเจนต์เห็นเพียงส่วนเล็กมากของ code repository มันไม่รู้ว่ามี helper function อยู่แล้ว เลยชอบสร้างของเดิมซ้ำขึ้นมาใหม่ ในงาน UI พอมันเทียบโครงสร้าง UI ทั้งหมดไม่ได้ โค้ดที่ไม่สอดคล้องกันก็เลยถูกทำซ้ำไปเรื่อย ๆ สุดท้ายมนุษย์ยังต้องเป็นคนป้อนบริบทที่ถูกต้อง เช่น "อ้างอิง helper function ในไฟล์นี้" "ทำตาม implementation นี้" หรือ "ต้องอ่านเอกสารนี้ก่อน" ถ้าให้ context ที่เหมาะสมด้วยตัวเองได้ ก็เพิ่มประโยชน์จากเอเจนต์ได้มาก อีกปัญหาหนึ่งคือเวลาเจอ monorepo ขนาดใหญ่ มันสำรวจโครงสร้างโฟลเดอร์ไม่เก่ง เช่น บ่อยมากที่มันรัน npm test จาก subdirectory ไม่เป็น

  • นี่ตรงกับปัญหาที่ผมเจอจริง ๆ ช่วงหลังผมรีวิวโค้ดฟีเจอร์ใหม่ราว 200 กว่าบรรทัดที่ Cursor เขียนให้ แต่โค้ดที่จำเป็นจริง ๆ มีนิดเดียว การไปหาว่าใน utility library มีฟังก์ชันที่มีอยู่แล้วหรือไม่นี่น่ารำคาญมากจนบางทีก็ปล่อยผ่าน เมื่อ 5 ปีก่อน การรีวิวแบบนี้ยังมีความหมายในเชิง onboarding สำหรับ junior อยู่มาก จึงสำคัญที่จะต้องช่วยชี้ให้เขาเห็น แต่ทุกวันนี้พอมี Cursor และเครื่องมือคล้ายกัน ปริมาณโค้ดกลับเยอะขึ้น ขณะที่ตัว developer เองก็รู้โครงสร้างอยู่แล้วแต่บางครั้งทำแบบนั้นเพราะนโยบายบริษัท ทำให้รู้สึกว่าผลิตภาพกลับลดลง

  • เรื่องรันคำสั่งอย่าง npm test จากโฟลเดอร์ย่อยมักเป็นปัญหาเสมอ ใน repo ที่แยกเป็น frontend แบบ Vite/React และ backend แบบ .NET ถ้า npm command ล้มเหลว มันจะตื่นตระหนกแล้ววนทำซ้ำหลายครั้งโดยแก้ไม่สำเร็จ กลายเป็น troubleshooting ที่ไม่จำเป็น ครั้งหนึ่งผมถึงกับเขียนคำสั่งไว้ใน CLAUDE.md ให้เช็ก current directory ก่อนเสมอ แต่ปัญหาที่มันลืม path แบบสุ่มก็ยังอยู่ สุดท้ายเลยเพิ่ม alias ที่ใช้ได้จากทุก directory อย่าง run-dev server restart, run-dev client npm install แล้วใส่คำสั่ง dotnet/npm ตรง ๆ ไว้ในรายการห้ามใช้ เพื่อบังคับให้ AI ไปอ่านคู่มือโปรเจ็กต์แล้วใช้ alias แทน วิธีนี้ค่อนข้างเสถียรที่สุดเท่าที่มี แต่กว่าจะมาถึงจุดนี้ได้ก็ใช้เวลา แรง และความเครียดไม่น้อย

  • ผมคิดว่าโมเดล context ใหญ่ ๆ ถ้าเอามาใช้กับ tool call น่าจะดี Gemini chat มีความสามารถ ingest ทั้ง github repository ได้ ถ้ามีเครื่องมือแบบ 'not-invented-here' ที่คอยเช็กก่อนเขียนฟังก์ชันใหม่ว่ามีของแบบเดียวกันอยู่ใน codebase แล้วหรือยัง ก็คงดี แน่นอนว่าอันดับแรกคงต้องไปดูก่อนว่ามีใครทำเครื่องมือแบบนี้ไว้แล้วหรือยัง

  • นี่แหละคือเหตุผลว่าทำไมถึงต้องมีเอกสารอย่าง claude.md ถ้าอยากให้มันทำตามกฎเฉพาะของทีมเรา การเขียนเอกสารไว้เป็นสิ่งจำเป็นจริง ๆ

  • จริง ๆ สถานการณ์แบบนี้เป็นเรื่องที่ senior engineer เจอบ่อยอยู่แล้วเวลาทำงานร่วมกับเพื่อนร่วมทีมในงานจริง

• ผมเห็นด้วยเต็มที่กับส่วนที่ถูกยกมาในบทความ ผมเห็นด้วยว่า LLM ยังแทนที่นักพัฒนาระดับท็อปไม่ได้ คนที่มีสติหน่อยก็คงไม่พูดแบบนั้นในตอนนี้ แต่ผมคิดว่านักพัฒนาที่ฝีมืออ่อนหรือระดับกลางบางส่วนถูกแทนที่ไปแล้ว ตัวอย่างเช่นในองค์กรของผมเคยมีอยู่ 3 คนที่จบ bootcamp 6 เดือน ตอนนั้นหานักพัฒนาที่เก่งจริง ๆ ยากมากเลยรับเข้ามา แต่ในทางปฏิบัติพวกเขาลำบากแม้แต่งานที่ง่ายมาก และผมต้องไปเก็บกวาดโค้ดใน review ทุกครั้ง หลังจากนั้นเครื่องมือ AI ดีขึ้นแบบก้าวกระโดดจนแซง performance ของคนกลุ่มนี้ไปแล้ว สุดท้ายถูกเลิกจ้าง 2 คน อีก 1 คนลาออกเอง ช่วงหลังเราก็แทบไม่รับ junior developer ใหม่เลย และจะไม่รับคนจาก bootcamp อีกแล้ว คนรอบตัวก็คล้ายกัน น่าจะเป็นเหตุผลว่าทำไมอุตสาหกรรม bootcamp เองก็เริ่มหายไป ผมไม่รู้ว่า AI จะไปถึงขั้นแทนที่นักพัฒนาที่เก่งจริงได้ไหม แต่ถ้าดูข้อมูลตอนนี้ มันพัฒนาเร็วมากอย่างชัดเจน ความเห็นเชิงลบแบบปฏิเสธทั้งหมดก็เหมือนหลบเลี่ยงความจริง ในอเมริคายุคแรก ๆ คน 90% ทำเกษตร แต่ตอนนี้เหลือแค่ 2% ทั้งที่ปริมาณและความหลากหลายของอาหารกลับมากขึ้นมาก ทั้งหมดนั้นเกิดจากความก้าวหน้าทางเทคโนโลยี ผมคิดว่าวงการซอฟต์แวร์อาจเจอสิ่งเดียวกันในอัตราเร่งแบบนี้ได้

  • แน่นอนว่าเทคโนโลยีทำให้อาหารผลิตได้มากขึ้น แต่ความจริงก็คือมันมีคุณค่าทางโภชนาการต่ำลงและมีพิษมากขึ้นด้วย

  • ผมสงสัยว่าคุณคิดว่าสาเหตุที่คนจาก bootcamp เติบโตต่อไม่ได้คืออะไร

• บทเรียนที่สำคัญกว่าคือ LLM ยังเปราะบางมากแม้กับงานที่ค่อนข้างง่าย ถ้าไม่มีคำสั่งจำนวนมากและการกำกับดูแลอย่างใกล้ชิด ผมลองให้มันรีแฟกเตอร์ parser ในโปรเจ็กต์เล็ก ๆ ของตัวเอง(2.5K บรรทัด) แผนที่มันเสนอออกมาดูดีทีเดียว ผมกำหนด checkpoint เป็นขั้น ๆ แล้วสั่งตามลำดับ แต่พอถามจริงว่า "ลบโครงสร้างเก่าออกหรือยัง?" "แทนที่ด้วยโครงสร้างใหม่หรือยัง?" มันกลับตอบว่า "ยังครับ ยังอยู่เหมือนเดิม" เทสต์ล้ม 80% และต่อให้ผมบอกทิศทางการแก้เฉพาะเจาะจง มันก็ยังล้มเหลวด้วยปัญหาเดิมซ้ำ ๆ ในงานนามธรรมอย่าง "รีแฟกเตอร์" สุดท้ายถ้าไม่ลงรายละเอียดมากถึงขั้น "คลาสไหนต้องเปลี่ยนอะไร" ก็ไปไม่รอด ถ้าต้องละเอียดขนาดนี้ก็เท่ากับสั่งงานมันแบบอิสระไม่ได้ และความหมายของการใช้ LLM ก็ลดลงไปมาก

  • ประสบการณ์ของผมต่างออกไปนิดหน่อย expression tree parser ที่เขียนด้วย typescript(tinqerjs.org) ของผม โค้ดที่เขียนเองมี 0 บรรทัด สร้างเสร็จใน 2 สัปดาห์(พาร์ตไทม์) ด้วย Codex+Claude ล้วน ๆ และยังเพิ่มเทสต์อีกหลายร้อยรายการ(รวมเคสซ้ำด้วย) ผมเคยทำ ORM ด้วย และพบว่าใช้ LLM แล้วประหยัดเวลาได้อย่างน้อย 4~10 เท่า แทบไม่ต้องกำกับดูแล สุดท้ายผมคิดว่าจุดประสงค์การใช้งานและการตั้งกระบวนการทำงานต่างหากที่เป็นตัวตัดสินผลลัพธ์ นักพัฒนาที่คุ้นกับการใช้ LLM ก็กำลังสร้าง workflow เฉพาะของตัวเองกันอยู่ และสิ่งที่เหมือนกันคือทุกคนโฟกัสที่การทดสอบ การทำเอกสาร และ code review

  • ปัญหาประเภท "ถ้าคำสั่งรีแฟกเตอร์ต้องละเอียดมากก็ไม่คุ้มจะใช้" อาจต้องเปลี่ยนมุมเป็น "ถ้าแบ่งเป็นขั้นระดับสูงให้ดีแล้วออกคำสั่งเป็นลำดับ จะเร็วกว่าเราทำเองมาก"

  • เรื่องนี้ก็เชื่อมกับจุดที่บทความชี้ไว้เหมือนกันว่า 'AI ไม่ได้ cut-paste แต่ลบแล้วสร้างใหม่' ดังนั้นโค้ดจะค่อย ๆ drift ไปบ้างเป็นเรื่องหลีกเลี่ยงยาก

  • อยากรู้ว่าคุณใช้โมเดลหรือเครื่องมือตัวไหน ตอนใช้ Cursor หรือ Copilot ผมก็เจอปัญหาว่าต้องคอยกำกับแม้แต่รีแฟกเตอร์เล็ก ๆ บ่อยมากเหมือนกัน

• LLM มีส่วนที่ช่วยได้ชัดเจนอยู่ อย่างเช้าวันนี้ผมเพิ่งแก้บั๊กใน PDF Metadata parser ได้โดยอาศัยความช่วยเหลือจาก LLM โดยไม่ต้องไปขุดสเปก PDF ลึก ๆ เอง แต่ในกรณีส่วนใหญ่ ผลลัพธ์กลับไม่มีประสิทธิภาพเท่าทำเอง ก่อนหน้านี้ตอนพยายามให้ Codex Code เขียน unit test ผมเตรียม setup ไว้หลายแบบแต่ขี้เกียจ mock data เลยโยนให้มันทำ สุดท้ายต้องลองถึง 8 รอบและยังต้องแก้ด้วยมือ มันยังไม่เข้าใจด้วยว่า entity นั้น obsolete ไปแล้วและไม่ได้ใช้ใน service อีก ผลลัพธ์เลยน่าผิดหวัง มันยังไม่ถึงขั้นแทนที่นักพัฒนาได้ทั้งหมด แต่ในฐานะที่คล้ายกับ Stack Overflow ในอดีต มันเก่งมากในการเปิดเผยความรู้ในหัวข้อที่ไม่คุ้นและชี้นำไปสู่แนวทางแก้ปัญหา

  • แม้ตอนนี้ผมก็ยังคิดว่า LLM เองมีศักยภาพมากพออยู่ดี แต่เวทมนตร์ที่แท้จริงเกิดตอนเอามันไปประกบกับ coding agent ถ้ามีเครื่องมือที่เหมาะสม มีการเชื่อมต่อและวนรอบกับโมเดลได้ดี copy-paste ก็ทำให้เกิดขึ้นได้ และข้อบกพร่องส่วนใหญ่ในวันนี้ก็แก้ได้ด้วย context และคำสั่งที่ดี การตรวจซ้ำแบบวนรอบ และ agent architecture ที่แข็งแรง อีกทั้งถ้าโมเดลตอบเร็ว มี context ขนาดใหญ่ และโฟกัสตามคำสั่งได้ดี ประสบการณ์ใช้งานก็จะดีขึ้นมาก ผมยังคิดว่าทักษะการเขียน prompt ของมนุษย์สำคัญมาก สุดท้ายแล้วต้องอาศัยทักษะวิศวกรรมซอฟต์แวร์ที่ดี โดยเฉพาะความสามารถในการมอบหมายงานให้ developer คนอื่น รวมถึงการทำเอกสารแนวทางและ best practice ใน codebase อย่าง AGENTS.md(หรือ CLAUDE.md) สรุปแล้วการถกเถียงว่า "AI/LLM แทนนักพัฒนาได้หรือไม่ได้" เริ่มน่าเบื่อ ประเด็นสำคัญกว่าคือ "เราจะทำอะไรให้ LLM ของเราเก่งขึ้นได้บ้าง"

• ผมไม่คิดว่าการทำ prompt ให้ "บังคับถามให้ชัดก่อน" เป็นการ over-engineer ตรงกันข้าม การออกแบบ prompt ให้ "ถ้าไม่ชัดให้ถามก่อน" ได้ผลดีมาก โปรแกรมเมอร์ที่ดีจะรู้เองว่าตัวเองส่งมอบสเปกครบหรือยัง และยังต้อง clarification เพิ่มอีกไหม จึงสามารถชี้นำให้ AI ถามคำถามเพิ่มเติมที่จำเป็นล่วงหน้าได้

  • เรากำหนดจำนวนคำถามที่อยากให้มันถามได้ด้วย เวลาหัวข้อซับซ้อน ผมมักสั่งให้ถามล่วงหน้า 20~30 ข้อ แล้วผลลัพธ์ออกมาค่อนข้างน่าพอใจ การเก็บ QnA พวกนี้ไว้ในไฟล์แยกต่างหากเพื่อใช้ซ้ำใน session ถัดไปหรือกับ agent ตัวอื่นก็มีประโยชน์มาก

  • ด้วยวิธีนี้ ผมเลยไม่เขียน prompt แบบสมัยก่อนแล้ว แค่โยนไอเดียให้แล้วบอกว่า "ถ้าจำเป็นก็ถาม" มันมักชี้ประเด็นที่ผมนึกไม่ถึงได้ดีมาก

• อ่านเรื่อง copy-paste ในบทความแล้วได้แรงบันดาลใจ จึงไปเพิ่มเครื่องมือ agent buffer ใน clippy(ยูทิลิตี้บน macOS) clippy มี MCP server สำหรับคุยกับ system clipboard อยู่แล้ว แต่รอบนี้การใช้ private buffer แยกต่างหากเหมาะกว่า ฟีเจอร์ที่เพิ่มเข้ามาคือ buffer_copy(คัดลอกช่วงบรรทัดที่กำหนดจากไฟล์ไปเก็บใน private buffer), buffer_paste(แทรก/แทนที่ไฟล์เป้าหมายด้วย byte ชุดเดิมจาก buffer แบบตรงตัว), และ buffer_list(ดูว่ามีอะไรอยู่ใน buffer บ้าง) เช่น ถ้าเอเจนต์สั่งว่า "คัดลอกบรรทัด 50~75 จาก auth.py" server ก็จะจัดการ file I/O ให้ตรง ๆ โดยไม่มีการสร้าง token หรือ hallucination เลย และไม่แตะ system clipboard ด้วย เดิมที AI สามารถคัดลอกโค้ดที่ตัวเองสร้างไปไว้ใน clipboard เพื่อใช้งานต่อได้อยู่แล้ว จุดประสงค์หลักของ clippy คือปรับปรุง macOS pbcopy—คือคัดลอกเนื้อหาจริงของไฟล์ แล้วไปวางใน Slack หรืออีเมลจาก terminal เป็นไฟล์จริงได้เลย ใครใช้เอเจนต์ที่รองรับ MCP เช่น Claude บน macOS ดูได้ที่นี่ ติดตั้งได้ด้วย brew install neilberkman/clippy/clippy

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

  • อย่างไรก็ตาม เป็นธรรมดาที่ผู้คนจะคาดหวังว่ารถยนต์ไร้คนขับหรือ AI ต้องน่าเชื่อถือกว่ามนุษย์ ข้อแก้ตัวแบบ "มนุษย์เองก็ทำไม่ได้" ไม่ค่อยมีน้ำหนักสำหรับคนที่มีความคาดหวังแบบนั้น ส่วนตัวผมเข้าใจท่าทีนี้ได้มาก

• เหมือนที่บทความต้นฉบับบอกว่า "LLMs ไม่ได้ copy-paste(หรือ cut-paste)" แต่มันจะจำโค้ดไว้แล้วลบทิ้งกับเขียนใหม่ จึงให้ความรู้สึกเหมือนมันคอยออกแต่คำสั่ง write ใหม่ทุกครั้ง ในงานรีแฟกเตอร์จริง ๆ แล้วไม่ได้มี copy/paste เยอะนัก จึงมักอาศัยการ recall ตาม context มากกว่า ในการทำงานจริง ผมก็ยังไม่แน่ใจว่าคำสั่ง copy/paste โดยตรงมีประโยชน์มากแค่ไหน(อย่างน้อยในการทดสอบของผมก็ไม่เห็นต่างมาก) กลับกัน ส่วนที่ซ้ำ ๆ และกิน context มากนั้น ใช้เครื่องมืออย่าง fastmod ร่วมกับ codex หรือ claude เพื่อให้ช่วย "แก้ส่วนนี้แบบครอบคลุม" ดูจะได้ผลกว่า วิธีแก้ปัญหาของมันต่างจากมนุษย์เลยรู้สึกแปลก แต่ถ้าคุยกันพร้อมวางแผนดี ๆ แนวทางทำงานก็เปลี่ยนไปได้มาก

  • IDE เปลี่ยนชื่อฟังก์ชันหรือ signature ข้ามหลายไฟล์ได้ทันที แต่ถ้าให้ LLM agent ทำ มักใช้เวลาหลายนาทีแล้วยังทำได้ไม่แม่น ผมคิดว่าประโยชน์ของการรองรับ copy/paste จริง ๆ นั้นชัดเจนอยู่

  • copy/paste ยังช่วยลดการระเบิดของ context ได้มาก เพราะโมเดลไม่จำเป็นต้องจำเนื้อหาของบล็อกโค้ดไว้ตลอด และสามารถเข้าถึงมันได้ทุกเมื่อที่ต้องการ