ทำไม AI แบบเอเจนต์จึงไม่ใช่คู่โปรแกรมมิ่งที่ดี
(justin.searls.co)- เพราะเอเจนต์ LLM เขียนโค้ดได้เร็วมากกว่ามนุษย์อย่างมาก ประสบการณ์การทำ pair programming จึงอาจแย่ลงแทน
- ระบบอัตโนมัติที่เร็วเกินไป ทำให้ผู้ใช้ตามไม่ทัน และมักเกิดปัญหาสูญเสียบริบทของงาน
- ปรากฏการณ์นี้คล้ายกับ ความรู้สึกถูกทิ้งไว้ข้างหลังเมื่อจับคู่ทำงานกับนักพัฒนาที่มีประสบการณ์สูง และสุดท้ายนำไปสู่ผลลัพธ์ที่การควบคุมคุณภาพและการสื่อสารอ่อนแอลง
- แนวทางแก้คือเสนอให้ใช้ การทำงานร่วมกันที่เน้น asynchronous code review และ เปลี่ยนไปสู่เวิร์กโฟลว์ที่ลดความเร็วของการจับคู่กับ AI เพื่อให้โฟกัสที่การควบคุมคุณภาพและการสื่อสาร
- แม้แต่ AI agent เองก็จำเป็นต้องถูกออกแบบให้ “หยุดและสนทนา โดยให้ความสำคัญกับความสงสัยและการตรวจสอบมากกว่าความมั่นใจ” คล้ายมนุษย์
ปัญหาของ LLM agent กับ pair programming
- AI agent (เช่น Copilot Agent) เขียนโค้ดได้เร็วกว่าความเร็วในการคิดของมนุษย์มาก
- ด้วยเหตุนี้ โค้ดจึงไหลออกมาก่อนที่ผู้ใช้จะตามทัน ทำให้เกิดอาการ สูญเสียบริบทและลดระดับการมีสมาธิกับงาน
- เมื่อเอเจนต์ขอความช่วยเหลือในสถานการณ์ที่มีปัญหา ผู้ใช้ก็มักยังไม่เข้าใจภาพรวมและต้องรับบท “ตามเก็บงาน” ไปโดยปริยาย ส่งผลให้ ภาระในการจัดการโค้ดที่เดินผิดทิศทางเพิ่มขึ้น
- สุดท้ายแล้ว การควบคุมคุณภาพ การสื่อสาร และการรักษาทิศทางที่ถูกต้องก็ทำได้ยากขึ้น
- ประสบการณ์การจับคู่กับ AI agent ที่ดีที่สุด กลับชวนให้นึกถึง ความทรงจำด้านลบ จากการ จับคู่กับโปรแกรมเมอร์มนุษย์ที่เก่งมาก ในอดีต
- คู่ทำงาน พิมพ์คีย์บอร์ดอย่างเงียบ ๆ ด้วยความเร็วสูงเกินไป จนตามโค้ดไม่ทัน
- ใช้พลังงานทางจิตใจจนหมด และค่อย ๆ หลุดออกจากงาน
- พอคู่ทำงานติดขัดแล้วมาขอความช่วยเหลือ ก็เกิดประสบการณ์ชวนสับสนเพราะยากจะเข้าใจสถานการณ์
- ระหว่างทำงานกลับได้ สิ่งที่ถูกสร้างขึ้นมาในทิศทางที่ต่างจากเป้าหมาย และภาระในการแก้ให้ทันเดดไลน์ก็ถูกผลักมาให้รับผิดชอบ
The path forward: แนวทางแก้ที่ใช้ได้จริง
-
1. การทำงานร่วมกันแบบอะซิงโครนัส
- คล้ายกับการทำ pair programming กับมนุษย์ในกรณีที่มีคนหนึ่งเป็นฝ่ายขับเคลื่อนหลัก รูปแบบที่ AI เขียนโค้ดอย่างอิสระแล้วส่งมาให้รีวิวผ่าน Pull Request จะมีประสิทธิภาพมากกว่า
- ใช้ เวิร์กโฟลว์แบบอะซิงโครนัส อย่าง GitHub Coding Agent เพื่อให้ผู้ใช้โฟกัสกับการรีวิวและการควบคุมคุณภาพได้
-
2. การจับคู่แบบ “ผลัดกันเดิน” ที่ลดความเร็วลง
- แทนที่จะใช้ “Agent Mode” ของ AI ให้ใช้ วิธีที่เดินทีละขั้นอย่าง Edit/Ask Mode
- คล้าย Ping-pong pairing (ฝ่ายหนึ่งเสนอ อีกฝ่ายหนึ่งอนุมัติ) โดย ผู้ใช้รับหรือรีวิวการเปลี่ยนแปลงที่ AI เสนอด้วยตนเองเพื่อควบคุมความเร็ว
- ไม่ควรใช้ AI เฉพาะตอนแก้ปัญหา/debugging เท่านั้น แต่ควร นำมาใช้ในเวิร์กโฟลว์อย่างสม่ำเสมอ
ไอเดียที่จะทำให้ agent pairing มีความเป็นมนุษย์มากขึ้น
- ให้ผู้ใช้ตั้งค่า ความเร็วในการแสดงผลโค้ด (บรรทัด/นาที, คำ/นาที) ได้โดยตรง
- มีฟังก์ชัน หยุดเอเจนต์ชั่วคราว เพื่อให้ผู้ใช้ถามคำถามหรือโต้แย้งทิศทางได้
- ก้าวข้าม UI แบบแชตบอต เดิม ๆ ด้วยการมี UI primitives ที่เชื่อมกับความคืบหน้าของงาน (เช่น ปัก session ปัจจุบันไว้กับ GitHub issue ใด issue หนึ่ง, มี To-do list ในตัว เป็นต้น)
- ออกแบบให้เอเจนต์หยุดและสนทนาบ่อยขึ้น: ยืนยันว่า “ทำสิ่งนี้ไปทำไม” ขอคำแนะนำ ตรวจสอบทิศทาง ฯลฯ เพื่อสร้างบรรยากาศการทำงานร่วมกันแบบมนุษย์
- เพิ่ม การรองรับ voice chat ขั้นสูง เพื่อให้ผู้ใช้ยังจ้องที่โค้ดไปพร้อมกับสื่อสารกับ AI ด้วยเสียงได้
- หากมีฟีเจอร์เหล่านี้ ประสบการณ์ในปัจจุบันที่เป็นการจับคู่กับเอเจนต์แบบรวดเร็วและทางเดียว ก็อาจเปลี่ยนเป็น ประสบการณ์ความร่วมมือร่วมกันระหว่างมนุษย์กับเอเจนต์อย่างแท้จริง ได้
บทสรุป
- ณ เวลานี้ เรากำลังเห็นทั้งข้อจำกัดและศักยภาพของ pair programming ที่ขับเคลื่อนด้วย AI agent ไปพร้อมกัน
- AI agent pair programming จะให้ผลลัพธ์ที่ดีกว่า หากไม่ได้ออกแบบให้เน้นแค่ความเร็ว แต่เน้นการสื่อสาร คุณภาพ และการตรวจสอบเหมือนการทำงานร่วมกับมนุษย์
- วิธีแบบ “ค่อย ๆ ไป สนทนา ตรวจสอบ และแชร์สถานการณ์ร่วมกัน” จะยกระดับคุณภาพของการจับคู่กับ AI
2 ความคิดเห็น
> 1. การทำงานร่วมกันแบบอะซิงโครนัส
> แทนที่จะเป็นการจับคู่เขียนโปรแกรมกับมนุษย์ที่อีกฝ่ายหนึ่งเป็นคนนำเหมือนในการ pair programming ระหว่างคนด้วยกัน การให้ AI เขียนโค้ดอย่างอิสระแล้วรีวิวผ่าน Pull Request จะมีประสิทธิภาพมากกว่า
ผมกำลังใช้ Codex มาได้หลายวันแล้ว และเห็นด้วยกับแนวคิดนี้มากกว่าการใช้งานในรูปแบบเอเจนต์ ตอนนี้สามารถรันงานหลายโปรเจกต์พร้อมกันได้แล้ว จึงรู้สึกเหมือนกำลังทำงานร่วมกับนักพัฒนาระดับจูเนียร์หลายคนจริง ๆ
เมื่อสามารถใช้ AI แบบอะซิงโครนัสได้ ก็สั่งงานหลายโปรเจกต์ได้พร้อมกัน และแม้แต่ภายในโปรเจกต์เดียวกันก็สั่งหลายงานไปพร้อมกันได้ ทำให้สัมผัสได้จริงว่าประสิทธิภาพการทำงานเพิ่มขึ้นแบบเชิงเลขถึงมากกว่า 3-10 เท่า
ความเห็นจาก Hacker News
รู้สึกว่านี่อธิบายได้ตรงมากว่าทำไมฉันถึงเลิกใช้ AI แบบนี้อย่างรวดเร็ว เวลาอยากสร้างอะไรสักอย่าง ปกติฉันจะมี วิธีการ คร่าว ๆ อยู่แล้ว แต่สิ่งที่ AI ลงมือทำจริงมักต่างจากที่ฉันต้องการบ่อยมาก แล้วพอ AI สร้างโค้ดมา 2,000 บรรทัดรวดเดียว งานกลับยิ่งเพิ่มขึ้นอีก ต้องมานั่งสั่งว่า "ก่อนอื่นลบคอมเมนต์พวกนี้ทั้งหมดออกที คำอธิบายมันเยอะเกินจำเป็นสำหรับโค้ดง่าย ๆ อย่า abstract X แบบนี้ ฉันต้องการแบบนี้..." แล้วพอให้ฟีดแบ็กไป จู่ ๆ โค้ด 2,000 บรรทัดก็หดเหลือ 700 บรรทัดแบบเปลี่ยนไปคนละเรื่อง จนตามไม่ทันจริง ๆ อีกอย่างฉันก็ไม่ชอบที่ codebase กลายเป็นกองสคริปต์ที่ฉันไม่ค่อยรู้จักและแต่ละอันก็คนละแนวกัน ฉันต้องการ AI ที่มีสไตล์และวิธีคิดใกล้กับตัวเอง แต่ตรงนั้นแหละที่ยากมาก การทำงานกับ AI ให้ความรู้สึกเหมือนทำงานวันแรกกับใครสักคนที่ยังไม่มีประสบการณ์ สำหรับฉันมันไม่ใช่เรื่อง AI มั่นใจเกินไปเท่าไร แต่เป็นเพราะมันทำให้เห็นกระบวนการออกแบบชัดขึ้น ตามอุดมคติแล้วควรมีขั้นตอนให้ดูเอกสารออกแบบก่อนว่า "ฉันกำลังคิดแนวทางแบบนี้ จะจัดการฟังก์ชันหรือคลาสและสถานะแบบนี้" ถ้าโอเคค่อยไปขั้น implement
อยากเน้นว่าเหมือนกับวิศวกรมนุษย์เลย การมี planning session ก่อนสำคัญมาก ต้องคุยและต่อรองรายละเอียดกันก่อนเขียนโค้ด ฉันตั้งใจถามคำถามแรกให้กว้างที่สุดก่อน เพื่อดูว่าจะมีคำแนะนำที่ไม่คาดคิดโผล่มาไหม แล้วค่อย ๆ เจาะจงขึ้น พอพอใจแล้วก็ให้ LLM สร้างเอกสารสองไฟล์คือ initialprompt.txt และ TODO.md ใน initialprompt.txt จะมีสรุปโปรเจกต์ คำสั่งให้อ่าน TODO.md และสั่งให้เช็กแต่ละขั้นเมื่อทำเสร็จ วิธีนี้ช่วยให้ LLM เข้าใจทั้งเป้าหมายใหญ่และงานย่อยทั้งหมด และถ้าทีหลังบทสนทนาหลุดเพราะติดข้อจำกัดด้าน context แล้วต้องเริ่มใหม่ ก็ใช้เตือนงานได้เร็ว
รู้สึกเหมือนสรุปประสบการณ์ของฉันออกมาเป๊ะ ๆ ประสบการณ์ที่จบได้สวยมีแค่ตอนที่สนใจผลลัพธ์อย่างเดียวและแทบไม่มีความรู้พื้นฐานในโดเมนนั้นเลย ถ้าฉันมีความเห็นแรง ๆ ว่าผลลัพธ์แบบไหนถึงจะ “ดี” สุดท้ายก็มักหงุดหงิดและล้มเลิกโปรเจกต์อยู่ดี ตอนใช้ฟีเจอร์ architect ของ roo code เพื่อจัดระเบียบแนวทางก่อน แล้วค่อยใช้ code mode ลงมือเขียนจริง ก็มีทั้งความสุขและความหงุดหงิดอย่างละครึ่ง บทเรียนสำคัญคือให้เริ่มงานใหม่เสมอ อย่าลากบทสนทนายาว ๆ ต่อไป ฉันปกติเป็นคนชอบแตกปัญหาเป็นชิ้นเล็ก ๆ และตรวจผลทีละขั้น แต่กับ LLM กลับโยนทั้ง problem space ใส่ทีเดียวจนพัง ฉันลองผิดลองถูกหลายรอบเพื่อหาวิธีของตัวเอง และวันนี้ก็เพิ่งเพิ่มฟีเจอร์ในแอปได้ใน 30 นาที ถ้าทำเองคงใช้เวลาหลายวัน ที่บันทึกไว้แค่ 30 นาทีจริง ๆ ก็เพราะฉันรู้อยู่แล้วว่าต้องการอะไร และไม่สนใจกระบวนการ ประสบการณ์แบบนี้ทำให้สรุปได้ว่า การให้ AI เขียนโค้ดที่วันหนึ่งคนอื่นต้องมาดูแลต่อ เป็นไปไม่ได้ด้วยเหตุผลทุกข้อที่ว่ามา
สุดท้ายมันเหนื่อยเกินไป และเจอแต่ผลลัพธ์ที่ไม่น่าพอใจ พูดไว้สำหรับคนที่กำลังกังวลเรื่องนี้ ฉันเองก็เคยพอใจกับ agent coding แค่ตอนเป็นสคริปต์ระยะสั้นที่ไม่สนคุณภาพโค้ด หรือเป็น leaf function เล็ก ๆ ที่ไม่มีผลกับอะไรจริง ๆ
workflow ที่ Anthropic แนะนำใน คู่มือใช้งาน Claude Code ก็น่าแนะนำ ใจความคือ “ให้มันอ่านโค้ดก่อน จากนั้นวางแผนการเปลี่ยนแปลง แล้วค่อยลงมือทำ” คุณจะได้เห็นแผนและแก้ไขมันได้ก่อนที่ AI จะเขียนโค้ดแม้แต่บรรทัดเดียว เวลาใช้ agent แล้วมันทำไม่ตรงแบบที่ต้องการ เช่น กระโจนไปเขียนโค้ดเลยโดยไม่มีแบบ ก็แค่บอกว่า "ทำอีกแบบ"
เรื่องที่บอกว่ามันสร้างโค้ด 2,000 บรรทัดในทีเดียว นี่เหมือนกำลังใส่พรอมป์ให้ยัด Skyrim ทั้งเกมลง SNES หรือเปล่า ไปกินข้าวกลางวันกลับมารันดูแล้วโวยวายว่ามันดันสร้าง Fallout ที่มีแต่การโจมตีระยะประชิดในสไตล์ PS1 ให้
ทุกครั้งที่โพสต์ขึ้นหน้าแรกของ HN ฉันมักกลัวว่าจะเปิดคอมเมนต์มาเจอว่าตัวเองโง่แค่ไหน และจะโดนคนพูดจาเชิงรุกทำลายหน้าตา แต่บางครั้งถ้าฉันตั้งชื่อบทความได้ดีมาก ๆ ก็ไม่มีใครอ่านเนื้อหา ทุกคนมัวแต่พูดเรื่องของตัวเอง แล้วฉันก็รอดจากคำด่าเหล่านั้นไป
คิดว่าเป็นเรื่องเล่าที่ทั้งขำและสมจริง เจอแพตเทิร์นแบบนี้บ่อยในโพสต์อื่นเหมือนกัน ยังไงก็ชอบการถกเถียงแบบนี้อยู่แล้วเลยสนุกดี
บทความดีมาก ให้ความรู้สึกเหมือน “วิธีสนุกกับการ pair programming กับ AI” อะไรทำนองนั้น ขอบคุณเพราะได้ประโยชน์จริง
ตอนใช้ LLM agent ครั้งแรก ฉันคาดหวังการสื่อสารสองทางและการ pair programming แบบร่วมมือกันจริง ๆ แต่ของจริงกลับเหมือนได้คู่หูที่พยายามแก้ทุกอย่างด้วยวิธีของตัวเองล้วน ๆ พอฉันพยายามแก้นิดหน่อย context ของโค้ดที่ AI เขียนก็พัง กลายเป็นยิ่งใช้งานยาก สิ่งที่ฉันต้องการคือการทำงานร่วมกันจริง ๆ แบบฉันทำหน่อย AI ทำหน่อย สลับกันไปมา
ถามว่าได้ลองใหม่เมื่อเร็ว ๆ นี้ไหม เพราะประสบการณ์ฉันต่างออกไป ฉันจะแก้โค้ดที่ AI สร้างแล้วสั่งให้มันอ่านไฟล์ใหม่ จากนั้นมันก็มักตอบประมาณว่า “มีการเปลี่ยนแปลงในไฟล์นะ” ถ้า AI แก้โค้ด ฉันก็จะรันทดสอบแล้วให้ฟีดแบ็ก มันก็ปรับดีขึ้นเป็นรอบ ๆ วิธีนี้ใช้ได้ดีมากกับ Zed และ Claude Sonnet
วิธีที่ฉันใช้บ่อยคือรับข้อเสนอจาก AI มาก่อน แล้วค่อย refactor หรือถ้าจำเป็นก็ค่อยพรอมป์สั่งใหม่ วิธีนี้มีผลข้างเคียงคือทำให้อัตราการยอมรับ (accept rate) สูงขึ้นแบบเทียม ๆ ซึ่งบริษัท AI ก็อาจเอาสถิตินี้ไปใช้เป็นหลักฐานว่า "AI เขียนโค้ดได้ดีมาก" ทั้งที่ความจริงหลายครั้งมันคืออารมณ์แบบ “เฮ้อ ช่างมัน เดี๋ยวฉันแก้เองก็ได้”
สำหรับฉัน ถ้าพิมพ์กำกับไว้ว่า “คุยกันก่อนอย่างเดียว อย่าแก้โค้ด” ก็มักจะได้บทสนทนาแบบที่ต้องการ พอคุยไปคุยมาจนพอแล้ว ค่อยสั่งท้ายสุดว่า “apply”
ถ้าอยากได้รูปแบบการร่วมงานแบบที่ต้องการ ก็ควรบอก LLM ให้ชัดเจนไปเลย แนะนำให้เตรียมเอกสารพรอมป์ไว้สักหลาย ๆ แบบเพื่อหยิบมาใช้ได้ทุกบทสนทนา
ช่วงนี้การรักษาบริบทไม่ได้ยากมากจนทำให้แก้โค้ดไม่ได้แล้ว ฉันใช้แต่ Ask mode (โหมดถามตอบ ไม่ใช่สั่งการ) ใน Claude Code ใช้ Opus ส่วนใน Cursor ใช้ o3 max จงใจเลี่ยง agent mode เพราะอย่างที่บทความต้นทางว่าไว้ ยิ่งเวลาผ่านไปผลประโยชน์ที่ฉันได้ยิ่งน้อย ฉันแทบไม่ใช้ tab completion และโค้ดที่แนะนำมา 80–90% ฉันจะปรับและพิมพ์เองทั้งหมด เลยยังพิมพ์ได้ต่อเนื่องที่ 170wpm ความเร็วเอาต์พุตของ Opus กับ o3 max ก็จำกัดพอสมควร เลยไม่ได้อ่านไม่ทัน ตอนแรกเร็วเกินไปจนลำบาก แต่เดี๋ยวก็ชิน ความเห็นส่วนตัวคือ ถ้าประสบการณ์ LLM ของคุณมีแค่ GitHub Copilot นั่นยังเป็นแค่ประสบการณ์ระดับโมเทลเท่านั้น
pair programming เองก็ไม่ได้เหมาะกับทุกสถานการณ์ แถมหลายกรณีก็อาจไม่เหมาะเลยด้วยซ้ำ เคยพูดไว้ที่อื่นเหมือนกันว่า คำแนะนำแบบ autocomplete ของ LLM ทำให้ flow ของการโค้ดที่ต้องใช้สมาธิสะดุด ต้องหยุดเป็นช่วง ๆ เพื่ออ่าน ตรวจ และกดยอมรับหรือปฏิเสธ จน programming flow พังหมด ฉันพยายามเอา AI autocomplete มาใส่ใน workflow ของตัวเองแล้วลำบากมาก
ฉันก็คิดเหมือนกัน ทางแก้คือใช้ทั้ง IDE ที่ไม่มี AI กับ Cursor/VS Code แล้วสลับไปมา ภาวะจดจ่อลึก ๆ หรือ deep work เกิดขึ้นพร้อมกับการคุยกับแชตบอตไม่ได้จริง
ไม่นานมานี้ฉันซื้อโน้ตบุ๊กใหม่และติดตั้ง IDE ใหม่ ระหว่างโค้ดอยู่หลายชั่วโมงก็รู้สึกว่ามีอะไร “แปลก ๆ” สุดท้ายถึงรู้ว่าลืมล็อกอิน GitHub Copilot เลยทำงานแบบไม่มี AI อยู่ กลายเป็นว่าฉันเขียนโค้ดเชิงรุกมากขึ้นเยอะโดยไม่ต้องรอ autocomplete ของโค้ด โดยเฉพาะ Cursor ที่รบกวน flow ตลอด ฟีเจอร์อย่าง “ทำนายตำแหน่งเคอร์เซอร์ถัดไป” นี่ไม่จำเป็นเลย ต่อไปฉันว่าจะปิด Copilot แล้วใช้เครื่องมือสไตล์ agent อย่าง aider แค่กับ boilerplate หรืองานซ้ำ ๆ พอ
ฟีเจอร์ autocomplete หรือคำแนะนำโค้ดจาก AI แย่มากเป็นพิเศษเวลาใช้ภาษาที่ type เข้ม เพราะส่วนใหญ่ถูกแค่ 80% ขณะที่ autocomplete ของ IDE ถูกแทบ 100% ส่วนวิธีแบบ AI agent ดีกว่าตรงที่ 1) ไม่มาขัดจังหวะกระแสความคิดตลอดเวลา และ 2) มันคอมไพล์และรันทดสอบเอง แก้ของที่ผิด แล้วค่อยส่งโค้ดที่ถูกต้องกลับมา
ฉันกลับชอบ autocomplete มาก ต้องใช้ภาษา Go ซึ่งมี boilerplate เยอะมาก ปัญหาหลายอย่างก็แก้ด้วยการเพิ่มไลบรารีไม่ได้ เลยบ่อยครั้งที่พิมพ์เองยังเร็วกว่าก็จริง แต่กับโค้ดน่าเบื่อ ๆ autocomplete ช่วยได้มาก เรื่องเขียนอะไรจุกจิกมือฉันไวกว่า AI อยู่แล้ว เลยยิ่งทำให้ autocomplete มีประโยชน์ ข้อเสนอทีละบรรทัดอ่านผ่านได้ทันที ส่วนข้อเสนอยาวหน่อย ถ้าใกล้กับที่ฉันกำลังจะเขียนก็ปล่อยผ่านได้ พอใช้ไปเรื่อย ๆ ก็เริ่มเดาได้ว่า AI จะเดาอะไร มันไม่ถึงกับเพิ่ม productivity แบบมหาศาล แต่พวก log message หรือ for loop น่ารำคาญ ๆ เร็วขึ้นแน่ ๆ ฉันคิดว่ามันช่วยได้เฉพาะตอนที่ความเร็วในการอ่านของฉันเร็วกว่าความเร็วในการพิมพ์เองมากเท่านั้น
pair programming อาจไม่ได้เหมาะเสมอไป แต่ก็มีประโยชน์ในสถานการณ์ส่วนใหญ่อยู่ดี เวลาที่มันไม่เวิร์กมักเป็นตอนที่คนหนึ่งหรือทั้งคู่ไม่ได้ทุ่มกับกระบวนการนี้จริง ๆ หรือมีฝ่ายหนึ่งตั้งแง่ว่า “แบบนี้ใช้ไม่ได้” หรือพยายามยึดหลัก pair programming แบบเคร่งเกินไป
จุดยืนฉันค่อนข้างซับซ้อน ตอนนี้กำลังลองใช้เครื่องมือ LLM หลายตัวในบริษัทแบบจริงจังอย่างน้อยหนึ่งเดือน เพื่อเรียนรู้ว่าจะใช้ให้คุ้มที่สุดได้อย่างไร ถ้าวัดจากจำนวนบรรทัดโค้ด productivity เพิ่มขึ้นชัดเจน แต่ถ้ามองภาพรวม ฉันยังบอกไม่ได้ว่าตัวเอง productive ขึ้น ทุกงานที่เสร็จมักมีพฤติกรรมประหลาดอธิบายไม่ได้ หรือบางครั้งไปแตะส่วนที่ไม่เกี่ยวจนต้องย้อนกลับเองบ่อยมาก เทสต์ที่ AI สร้างให้อัตโนมัติดูเผิน ๆ เหมือนใช้ได้ แต่พอมองตัวชี้วัดอื่นอย่าง coverage ก็เห็นข้อบกพร่องชัด การไปให้ถึงผลลัพธ์ที่ต้องการกลับให้ความรู้สึกเหมือนต้องถอยหลังหลายขั้น ไม่ใช่แค่ไม่ได้กำไรหรือไม่ได้เรียนรู้ แต่เหมือนถอยหลังจริง ๆ ครั้งหนึ่งมันเคยแอบเพิ่มโค้ด import ที่ไม่จำเป็นถึง 50,000 บรรทัดเข้าไปในโมดูลที่ไม่ได้อยู่ในขอบเขตการแก้ไข อีกครั้งหนึ่งก็ทั้งที่ตั้งกติกาไว้ชัด มันกลับทำลายโครงสร้างเชิงวัตถุทั้งหมดแล้วเขียนทุกอย่างเป็น if/else เต็มไปหมด ปัญหาคือผลลัพธ์มันผันผวนมาก ตามสถานการณ์ บางครั้งงานเดียวกันทำได้สมบูรณ์แบบ แต่อีกครั้งกลับพังทั้งระบบ ฉันลองมาหลายวิธีว่าจะสั่งงานหรือชี้นำยังไง แต่ถึงเป็นงานคล้ายกัน พฤติกรรมก็แตกต่างมากจนต้องทนตรวจทุกการเปลี่ยนแปลงอยู่ดี ต่อให้โค้ดเกือบถูกทั้งหมดแล้ว ถ้าขอให้แก้แค่จุดเล็ก ๆ มันก็มักพาทั้งงานหลุดทิศ จากประสบการณ์ของฉัน มันมีประโยชน์กับการเขียนเครื่องมือเล็ก ๆ แต่กับ codebase ขนาดกลางถึงใหญ่ ยากจะคาดหวังผลลัพธ์ที่สม่ำเสมอ
LLM agent ดูเป็นพวกพูดเยอะและเชื่อว่าทางของตัวเองถูกเสมอ มันไม่กระชับ อะไรที่จบได้ในบรรทัดเดียวก็อธิบายยืดยาว เปลี่ยนเล็กน้อยก็ใส่คอมเมนต์ยาวเหยียด ชอบทำตัวเหมือนจะมาสอนฉัน และออกแนวเยอะเกินเหตุ
พฤติกรรมบางอย่างที่คนไม่ชอบ (อย่าง “เอาต์พุตยาวเกินไป, คอมเมนต์มากเกินไป” เป็นต้น) อาจเป็นผลข้างเคียงจากการออกแบบ LLM ให้มีประสิทธิภาพขึ้นในด้านอื่น เอาต์พุตยาวมีแนวโน้มเชื่อมโยงกับโค้ดที่ไม่ขี้เกียจเขียนและคะแนน benchmark ด้านประสิทธิภาพที่สูงกว่า ส่วนคอมเมนต์เยอะก็เกี่ยวกับการเสริม local context เพื่อยกระดับคุณภาพโค้ดถัดไปและลดข้อผิดพลาด
เมื่อวานฉันลองใช้ sonnet 4 กับงานที่แค่เปลี่ยนค่า config ตัวเดียว มันกลับใช้เวลา 15 นาทีไปกับการทดสอบและ refactor วนไปวนมา สุดท้ายแก้ไฟล์ไร้สาระไป 40 ไฟล์ ยังพยายามจะรันดีบักเกอร์ที่ไม่มีอยู่จริง และเปิดหน้าเว็บที่ต้องยืนยันตัวตนซ้ำ ๆ ด้วย รู้สึกได้ชัดเลยว่ามันห่างไกลจากคำว่าสมบูรณ์แบบมาก
จากประสบการณ์ของฉัน ปัญหาไม่ใช่ว่ามันเร็วเกินไป แต่กลับช้าเกินไปเสียมากกว่า แถมเป็นความช้าที่ก้ำกึ่งจนแย่กว่าเดิม ถ้ามันเร็วกว่านี้ ฉันคงตามโค้ดแบบเรียลไทม์ได้ ถ้ามันช้ากว่านี้ ฉันก็จะไปทำอย่างอื่นแล้วค่อยกลับมา แต่ความจริงคืองานเสร็จเป็นช่วง 50 วินาทีถึงหลายนาที ทำให้ไปโฟกัสอย่างอื่นก็ไม่ได้ ฉันเลยคิดว่าการทำซ้ำเป็นรอบสั้น ๆ ที่เล็กกว่าน่าจะดีกว่า สุดท้ายแล้วรูปแบบที่ดีกว่าคือความเป็นอิสระระดับที่เทียบกับการรีวิวโดยมนุษย์ได้ เช่น ทำงานแยกไปเลยคล้ายการตรวจ merge request (PR) ตอนนี้ลูปแบบเดิม ๆ คือ สั่งงาน รอ 1–3 นาที ดูผล ให้ฟีดแบ็ก แล้ววนใหม่ สำหรับฉันนี่คือกรณีใช้งานที่แย่ที่สุด
ฟังแล้วนึกถึงการ์ตูนของ Oatmeal เรื่อง “อินเทอร์เน็ตช้า vs ไม่มีอินเทอร์เน็ต”
ถ้าสมาธิแตกง่าย มีคนแนะนำให้ตั้งตู้ปลา 30L ไว้บนโต๊ะ เป็นทิปขำ ๆ ว่าเหมาะมากสำหรับนั่งเหม่อ
ในฐานะนักพัฒนา ฉันแทบไม่ใช้ AI เลย นาน ๆ ทีถึงจะใช้แชตบอตถามคำถามที่ไม่เกี่ยวกับโปรเจกต์ เลยอยากรู้ว่าพวกคุณใช้ AI กับโปรเจกต์ลูกค้าด้วยไหม หรือใช้แค่กับโปรเจกต์ส่วนตัว ถ้าใช้กับงานลูกค้า อยากถามว่าได้ระบุในสัญญาหรือเปล่าว่าโค้ดจะถูกส่งให้ AI เพราะลูกค้าส่วนใหญ่จะมี NDA ห้ามเปิดเผยต่อภายนอก และบางรายก็เคยมีข้อห้ามใช้ AI โดยตรง อยากรู้ว่าเคยเจอลูกค้าที่อนุญาตข้อยกเว้นให้เครื่องมือเขียนโค้ดด้วย AI ไหม
ฉันใช้เกือบทั้งหมดภายในบริษัทเท่านั้น และนั่นก็เพราะบริษัทมีแนวทางการใช้ AI ที่ชัดเจนด้วย จริง ๆ แล้วจากที่รู้สึกมันแทบไม่ได้ช่วยประหยัดเวลาเลย ฉันเลยไม่คิดจะจ่ายเงินใช้กับงานส่วนตัว สำหรับโปรเจกต์ส่วนตัว ความสนุกจากการลงมือทำเองสำคัญกว่าผลลัพธ์อยู่แล้ว เลยสนุกกับการทำเองมากกว่านั่งพรอมป์
บางครั้งฝั่งลูกค้าเองก็เป็นคนผลักดันให้ใช้ AI อย่างจริงจัง เพราะคาดหวังคุณภาพที่ดีขึ้นและการพัฒนาที่เร็วขึ้น (สุดท้ายก็เพื่อลดต้นทุน) แต่ในความเป็นจริงบ่อยครั้งผลกลับไม่เป็นแบบนั้น (แต่อีกเรื่องหนึ่งนะ)
ฉันจะแชร์กับ OpenAI/Anthropic เฉพาะโค้ดที่เปิดเผยได้มากพอ ๆ กับการเอาไปแปะในช่องค้นหาบนเว็บเท่านั้น
ฉันไม่แชร์เลย รวมถึงโปรเจกต์ภายในด้วย การเอาโค้ดออกไปภายนอกทำได้ก็ต่อเมื่อมีการจ่ายเงินเท่านั้น ฉันทำงานกับข้อมูลส่วนบุคคลด้วย ถ้าโค้ดถูกเปิดเผยต่อบริษัทอเมริกัน ความเสี่ยงทางกฎหมายสูงเกินไป
ในที่สุดก็มีคนพูดชี้จุดนี้ตรง ๆ เรื่องที่ AI มั่นใจเกินไปกับการออกแบบ แต่พอลงรายละเอียด implement กลับเดินหน้าเองโดยไม่คุย Mocking API ก็ชอบทำให้โครงสร้างเสียจนต้องมานั่งแก้ใหม่ อยากให้พฤติกรรมของ LLM ร่วมมือมากกว่านี้ และถ้ารายละเอียดไม่พอก็ควรถามทันที เราไม่สามารถใส่ข้อมูลทุกอย่างลงไปในพรอมป์แรกได้ และการเติมพรอมป์ทีหลังมักไปทำลายบริบทและกระบวนการคิดของแบบร่างตั้งต้น ไม่แน่ใจว่าฉันใช้งานผิดเองหรือเปล่า เลยอยากรู้ว่ามีวิธีที่ดีกว่านี้ไหม ฉันอยากให้ LLM พัฒนาไปในทางที่รับฟีดแบ็กทีละน้อยแล้วค่อย ๆ ปรับใช้ได้ดีขึ้น สงสัยเหมือนกันว่าการเพิ่มหรืออัปเดตบริบทเป็นปัญหาที่ยากโดยตัวมันเองหรือไม่ แต่ก็ยังอยากเรียนรู้ต่อไป
เดี๋ยวนี้ tech stack ส่วนใหญ่รองรับ session แบบ “ออกแบบ/วางแผน” กันแล้ว ลองใช้ตรงนี้ก่อนน่าจะช่วยได้ workflow ที่ฉันใช้บ่อยและได้ผลคือ ไม่ว่าจะเป็นโมเดลใหญ่หรือเล็ก ก็เริ่มด้วยบทสนทนาประมาณว่า “อิงจาก @file, @docs, @examples ฉันอยากให้ทำ _ ที่ @path โดยอ้างอิง @module_requirements.md — มาคุยทุกอย่างที่จำเป็นก่อนลงมือ implement” จากนั้นคุยกลับไปกลับมาจนเห็นตรงกัน แล้วค่อยบันทึกไว้ในไฟล์ .md หรือจะส่งต่อว่า “โอเค ตอนนี้ทำต่อได้เลย” ก็ได้ ถ้าบันทึก workflow นี้ไว้ใน .rules หรือไฟล์ .md หรือเป็น snippet ใน IDE ก็หยิบมาใช้ซ้ำกับงานใหม่ได้ทุกครั้ง ต้องจำไว้ด้วยว่า LLM รุ่นใหม่ต้องการ context มากขึ้นมาก และผลลัพธ์ก็จะแตกต่างกันไปตาม codebase แต่ละอัน (แต่ละโปรเจกต์) ดังนั้นควรลองหลายแนวทาง
ยิ่งข้อมูลเยอะ AI ก็ดูยิ่งสับสนเหมือนกัน น่าจะมีวิธีรับมือได้อยู่ แต่ถึงมันจะเก่งเรื่องดึงข้อมูลชิ้นเล็ก ๆ ออกมาได้ดีมาก ฉันก็ยังเสียดายที่ทั้งอุตสาหกรรมดูจะหมกมุ่นกับโมเดลแบบแชตบอตกันไปหมด ลองนึกภาพดูว่าถ้าเราไม่เคยสร้างคีย์บอร์ด เมาส์ GUI หรือทัชสกรีนกันต่อมาเลยจะเป็นยังไง
ฉันมองว่าสไตล์การใช้งาน AI แบบร่วมมือในฐานะผู้ช่วยนี่แหละคือวิธีใช้ AI ที่ถูกต้อง ส่วนกระแสที่ไปหมกมุ่นกับ “ให้ AI เขียนโค้ดเอง” กลับเป็นตัวอย่างว่าทิศทางของอุตสาหกรรมซอฟต์แวร์กำลังเพี้ยนไป ฉันไม่เคยให้ AI เขียนโค้ดให้เลย ฉันใช้มันวิจารณ์โค้ดที่ฉันเขียน หรือช่วยวางกลยุทธ์ออกแบบโครงสร้างโค้ดขนาดใหญ่เท่านั้น เหมือนใช้เป็นที่ปรึกษาด้านกลยุทธ์ ซึ่งถ้าจัด context ให้ LLM ดี ๆ มันให้คำแนะนำที่ยอดเยี่ยมมากได้ ผู้ที่ต้องเป็นเจ้าของงานเสมอคือตัวฉันเอง ต้องเป็นคนเข้าใจและลงมือทำ และไม่มอบความรับผิดชอบให้ AI เกินกว่าบทบาทผู้ให้คำปรึกษา สำหรับฉัน AI คือ “idiot savant” ที่ต้องใช้อย่างระมัดระวัง