การเปลี่ยนแปลงของเวิร์กโฟลว์การเขียนโค้ด
- ในเดือนพฤศจิกายน 2024 เป็น เขียนเอง+autocomplete 80% และ agent coding 20% แต่ในเดือนธันวาคมสัดส่วนนี้กลับด้าน กลายเป็น agent coding 80% และการแก้ไข/เก็บงาน 20%
- ในทางปฏิบัติกลายเป็นการ โปรแกรมด้วยภาษาอังกฤษ โดยบอก LLM เป็นคำพูดว่าต้องการให้เขียนโค้ดแบบไหน
- แม้จะกระทบศักดิ์ศรีอยู่บ้าง แต่พลังในการจัดการซอฟต์แวร์ในหน่วยของ "code action" ขนาดใหญ่ นั้นมีประโยชน์มาก
- ถ้าปรับตัว ตั้งค่า เรียนรู้วิธีใช้ และทำความเข้าใจว่าอะไรทำได้/ทำไม่ได้ ก็จะใช้งานได้อย่างมีประสิทธิภาพยิ่งขึ้น
- นี่คือ การเปลี่ยนแปลงพื้นฐานของเวิร์กโฟลว์การเขียนโค้ดครั้งใหญ่ที่สุดในรอบราว 20 ปีของการเขียนโปรแกรม และมันเกิดขึ้นภายในเวลาเพียงไม่กี่สัปดาห์
- คาดว่าน่าจะมีวิศวกรจำนวนไม่น้อย (ระดับเลขสองหลักเป็นเปอร์เซ็นต์) ที่กำลังเจอสิ่งคล้ายกัน แต่การรับรู้ของสาธารณชนทั่วไปน่าจะยังอยู่เพียงเปอร์เซ็นต์ต้น ๆ หลักเดียว
IDE / agent swarm / ความเป็นไปได้ของข้อผิดพลาด
- มองว่ากระแสโฆษณาเกินจริงแนว "ไม่ต้องใช้ IDE แล้ว" หรือ "agent swarm" ยังถือว่าเกินจริงในตอนนี้
- โมเดลยังคงทำผิดพลาดอยู่ และถ้าเป็นโค้ดที่สำคัญจริง ๆ ก็ต้อง คอยเฝ้าดูอย่างเข้มงวด และยังจำเป็นต้องเปิด IDE ขนาดใหญ่ไว้ข้าง ๆ
- ลักษณะของความผิดพลาดเปลี่ยนไป: ไม่ใช่แค่ syntax error แบบง่าย ๆ อีกต่อไป แต่เป็น ข้อผิดพลาดเชิงแนวคิดที่ละเอียดอ่อน แบบที่นักพัฒนาจูเนียร์ที่ค่อนข้างสะเพร่าและใจร้อนอาจทำ
- ประเภทความผิดพลาดที่พบบ่อยที่สุด: ตั้ง สมมติฐานผิด แทนผู้ใช้ แล้วเดินหน้าต่อโดยไม่ตรวจสอบ
- ปัญหาเพิ่มเติม:
- จัดการความสับสนไม่ได้
- ไม่ขอคำชี้แจงเพิ่มเติม
- ไม่เปิดเผยความไม่สอดคล้อง
- ไม่เสนอ trade-off
- ไม่โต้แย้งเมื่อควรโต้แย้ง
- ยังมีแนวโน้ม เอาใจผู้ใช้มากเกินไป (sycophantic) อยู่บ้าง
- ใน plan mode จะดีขึ้น แต่ยังต้องการ plan mode แบบ inline ที่เบากว่านี้
- ยังมีแนวโน้มทำให้โค้ดและ API ซับซ้อนเกินจำเป็น ขยาย abstraction จนใหญ่เกินไป และไม่เก็บกวาด dead code หลังทำงานเสร็จ
- บางครั้งสร้างโครงสร้างที่ไม่มีประสิทธิภาพ เทอะทะ และเปราะบางยาวถึง 1000 บรรทัด แต่พอถามว่า "ทำแบบนี้ไม่ได้เหรอ?" ก็จะตอบว่า "ได้แน่นอน!" แล้วลดเหลือ 100 บรรทัดทันที
- ยังมีกรณีที่ไป เปลี่ยน/ลบคอมเมนต์และโค้ด ที่ตัวเองไม่ชอบหรือยังเข้าใจไม่พอ แม้จะไม่เกี่ยวกับงานที่กำลังทำ
- แม้จะใส่คำแนะนำไว้ใน CLAUDE.md และพยายามแก้แบบง่าย ๆ ปัญหาเหล่านี้ก็ยังเกิดขึ้น
- แม้มีปัญหาเหล่านี้อยู่ แต่มันก็ยังเป็น การพัฒนาแบบก้าวกระโดดครั้งใหญ่จริง ๆ และยากมากที่จะกลับไปเขียนโค้ดแบบแมนนวลล้วน
- เวิร์กโฟลว์ปัจจุบัน: ด้านซ้ายเป็น หน้าต่าง/แท็บ ghostty ที่รัน Claude Code อยู่ไม่กี่เซสชัน ด้านขวาเป็น IDE สำหรับตรวจโค้ดและแก้ไขด้วยมือ
ความอึด (Tenacity)
- การเห็น agent พยายามเกาะติดกับบางอย่างโดยไม่หยุดนั้นน่าสนใจมาก
- มัน ไม่เหนื่อย ไม่ท้อ และยังคงพยายามต่อ แม้ในสถานการณ์ที่ถ้าเป็นมนุษย์คงยอมแพ้ไปนานแล้วแล้วค่อยกลับมาวันหลัง
- การเฝ้าดูมันต่อสู้อยู่กับบางอย่างเป็นเวลานานแล้ว สุดท้ายสำเร็จในอีก 30 นาทีต่อมา ให้ความรู้สึกเหมือนเป็นช่วงเวลาที่ "สัมผัสได้ถึง AGI"
- ทำให้ตระหนักว่า พละกำลังในการลุยงานต่อเนื่องคือคอขวดหลักของงาน และเมื่อถือ LLM ไว้ในมือ สิ่งนี้จะเพิ่มขึ้นอย่างมาก
การเพิ่มความเร็ว
- ยังไม่ชัดเจนว่าจะวัด "การเพิ่มความเร็ว" ของการมี LLM ช่วยอย่างไร
- สิ่งที่ตั้งใจจะทำ รู้สึกว่าเร็วขึ้นมากจริง แต่ผลหลักคือ ได้ทำมากกว่าสิ่งที่ตั้งใจไว้มาก:
- สามารถเขียนสิ่งต่าง ๆ มากมายที่ก่อนหน้านี้ไม่คุ้มจะลงมือเขียน
- เข้าถึงโค้ดที่ก่อนหน้านี้ทำงานด้วยไม่ได้เพราะข้อจำกัดด้านความรู้/ทักษะ
- มันคือการเพิ่มความเร็วก็จริง แต่ส่วนที่ใหญ่กว่าอาจเป็น การขยายขอบเขต (expansion)
Leverage
- LLM เก่งมากในการ วนลูปจนกว่าจะบรรลุเป้าหมายที่กำหนด และนี่คือเวทมนตร์ส่วนใหญ่ของความรู้สึกแบบ "สัมผัสได้ถึง AGI"
- อย่าบอกละเอียดว่าจะต้องทำอะไร แต่ให้ เกณฑ์ความสำเร็จ แล้วคอยดู
- ให้มัน เขียนเทสต์ก่อน แล้วทำให้เทสต์นั้นผ่าน
- ใส่ Browser MCP เข้าไปในลูป
- ให้เขียน naive algorithm ที่น่าจะมีความถูกต้องสูงมากก่อน แล้วค่อยขอให้ optimize โดยยังรักษาความถูกต้องไว้
- เมื่อเปลี่ยนแนวทางจาก imperative ไปเป็น declarative agent จะวนลูปได้นานขึ้นและสร้าง leverage ได้มากขึ้น
ความสนุก
- สิ่งที่ไม่คาดคิดคือ การทำงานร่วมกับ agent ทำให้การเขียนโปรแกรม สนุกขึ้น
- งานน่าเบื่อแบบเติมช่องว่างถูกตัดออกไป เหลือแต่ ส่วนที่สร้างสรรค์
- อาการ ตัน/ติดขัด (สภาวะที่ไม่น่าสนุก) ลดลง และได้สัมผัสกับ ความกล้ามากขึ้น — เพราะมีวิธีเดินหน้าสู่ความคืบหน้าเชิงบวกด้วยกันได้เสมอ
- แต่ก็มีคนที่รู้สึกตรงกันข้าม: LLM coding จะทำให้เกิดการแบ่งระหว่าง วิศวกรที่ชอบการเขียนโค้ดเอง กับ วิศวกรที่ชอบการสร้างสิ่งต่าง ๆ
การฝ่อ (Atrophy)
- เริ่มสังเกตได้ว่าความสามารถในการ เขียนโค้ดด้วยมือ กำลัง ถดถอย ลงทีละน้อย
- การสร้าง (เขียนโค้ด) และ การจำแนก (อ่านโค้ด) เป็นความสามารถคนละแบบกันในสมอง
- เพราะรายละเอียดด้านไวยากรณ์เล็ก ๆ ของการเขียนโปรแกรม แม้จะเริ่มเขียนเองได้ยากขึ้น แต่การรีวิวโค้ดยังทำได้ไม่มีปัญหา
Slopacolypse
- คาดว่าในปี 2026 จะเป็น ปีแห่ง Slopacolypse (น้ำท่วมของคอนเทนต์คุณภาพต่ำที่สร้างโดย AI) ครอบคลุมทั้ง GitHub, Substack, arXiv, X/Instagram และสื่อดิจิทัลโดยทั่วไปทั้งหมด
- นอกจากการพัฒนาที่แท้จริงแล้ว ยังจะมี ละครผลิตภาพจากกระแสโฆษณา AI เพิ่มขึ้นอีกมาก (มันยังจะมากกว่านี้ได้อีกเหรอ?)
คำถามต่าง ๆ
- เกิดอะไรขึ้นกับ "วิศวกร 10X"? — อัตราส่วนผลิตภาพระหว่างวิศวกรทั่วไปกับวิศวกรระดับท็อปจะเป็นอย่างไร? มีโอกาสที่อัตราส่วนนี้จะ เพิ่มขึ้นมาก
- เมื่อเสริมพลังด้วย LLM แล้ว generalist จะค่อย ๆ แซง specialist หรือไม่? เพราะ LLM เก่งเรื่องการเติมช่องว่างระดับไมโครมากกว่าการวางกลยุทธ์ใหญ่ระดับแมโคร
- การเขียนโค้ดด้วย LLM ในอนาคตจะให้ความรู้สึกแบบไหน? จะเหมือนเล่น StarCraft ไหม? หรือเหมือนเล่น Factorio หรือเล่นดนตรี?
- มีส่วนไหนของสังคมบ้างที่กำลังติดคอขวดอยู่เพราะ งานความรู้ดิจิทัล?
TLDR
- ความสามารถของ LLM agent อย่าง Claude และ Codex ดูเหมือนจะข้าม จุดวิกฤตด้านความสม่ำเสมอ บางอย่างในช่วงราวเดือนธันวาคม 2025 และทำให้เกิด การเปลี่ยนสถานะ (phase shift) ในงานวิศวกรรมซอฟต์แวร์และสาขาที่เกี่ยวข้อง
- รู้สึกราวกับว่าส่วนของความฉลาดได้พุ่งล้ำหน้าองค์ประกอบอื่นทั้งหมดไปมากแล้ว — การบูรณาการ (เครื่องมือ, ความรู้), ความจำเป็นของเวิร์กโฟลว์องค์กรแบบใหม่, กระบวนการ, และการแพร่กระจายที่กว้างขึ้นโดยรวม
- ปี 2026 จะเป็นปีที่พลังงานสูงสำหรับอุตสาหกรรมในการย่อยและดูดซับความสามารถใหม่นี้
15 ความคิดเห็น
ดูเหมือนว่าจะมีการเผยแพร่เวอร์ชัน skills ที่ช่วยปรับปรุงการทำงานของ Claude Code โดยอ้างอิงจากเนื้อหาในบทความนี้ด้วยนะครับ
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
ผมยังสงสัยเรื่องนี้อยู่เรื่อย ๆ ว่าคนที่ชินกับการเขียนโค้ดด้วยมือมาแล้วจะทำหน้าที่กำกับดูแล LLM ได้ก็ดีอยู่หรอก แต่สำหรับคนที่เพิ่งเริ่มเรียนรู้ ถ้าเอาแต่จ้องโค้ดที่ LLM สร้างให้ ก็ดูเหมือนจะยากที่จะตัดสินได้ว่าสิ่งนี้ถูกหรือไม่ถูก
คนที่เมื่อก่อนเขียนกันด้วย assembler พอ compiler ออกมาใหม่ ๆ เขาเคยคิดกันไหมประมาณว่า จะไปเชื่อ compiler ที่ปล่อย assembly output ห่วย ๆ แบบนั้นได้ยังไง
ตอนนั้นถึงจะเขียนด้วย C ก็คงยังเขียนไปพร้อมกับคอยชี้นำให้ assembly output ออกมาตามที่ต้องการด้วย
ก็เลยอดสงสัยไม่ได้ว่า ถ้ายุค AI พัฒนาไปไกลกว่านี้ สุดท้ายจะสามารถสร้างงานสำเร็จรูปออกมาด้วยภาษาธรรมชาติโดยแทบไม่ต้องมีการกำกับจากมนุษย์ได้ไหม
แม้ในสมัยที่คนยังเป็นคนเขียนโค้ดเอง ถ้าไม่ตั้งใจเรียนก็คงไม่รู้เหมือนกันว่ามันผิดตรงไหน 555
เหล่าผู้เชี่ยวชาญด้านแอสเซมบลียังบ่นเรื่องคอมไพเลอร์กันอยู่เลย สุดท้ายสิ่งสำคัญคือในสถานการณ์ที่ต้องการการปรับแต่งประสิทธิภาพขั้นสุด ก็ยังจำเป็นต้องมีสเปเชียลลิสต์แบบนั้นอยู่ ถ้าเอาไปเทียบกับ AI ต่อให้ AI พัฒนาไปอีกมาก ก็อาจยังเอาชนะคนที่เขียนได้เฉียบคมถึงขีดสุดได้ยากก็ได้ แต่ในภาพรวมตอนนี้ มนุษย์คนไหนก็ชนะ AI ไม่ได้แล้ว ถ้ามีการแข่งขัน AlphaCode แบบเป็นอีกสักโมเมนต์ของ AlphaGo ก็น่าสนุกดี
ถ้ามีความพยายามที่จะวิเคราะห์และทำความเข้าใจโค้ดที่มันสร้างขึ้นมา ก็ดูน่าจะโอเคครับ
คอมไพเลอร์เป็นแนวคิดที่ต่างออกไปเล็กน้อย เพราะมันสร้างแอสเซมบลีตามกฎ จึงอยู่ในขอบเขตที่กำหนดผลได้แน่นอน ทำให้ถ้าตรวจทานสักครั้งแล้ว ปัญหาเดิมก็มักจะไม่เกิดซ้ำ แต่ LLM อยู่ในขอบเขตเชิงความน่าจะเป็น จึงยังมีโอกาสที่ปัญหาเดิมจะเกิดขึ้นอีกได้
ถ้าความแม่นยำเชิงความน่าจะเป็นนี้พัฒนาไปอีก ก็อาจจะเข้าใกล้ 100% ได้หรือไม่ก็ไม่แน่ แต่ถ้าความต้องการที่สั่งด้วยภาษาธรรมชาติเองยังไม่แม่นยำ สุดท้ายผลลัพธ์ก็ย่อมไม่แม่นยำตามไปด้วย ดังนั้นผมจึงคิดว่า "ผลงานสำเร็จ" ที่
ดีในท้ายที่สุดก็คงยังขึ้นอยู่กับมนุษย์อยู่ดีผมก็เป็นห่วงคนรุ่นจูเนียร์ที่ได้สัมผัส LLM ตั้งแต่สมัยยังเป็นนักเรียนเหมือนกันครับ รู้สึกด้วยว่าสถานการณ์ของตลาดรับสมัครจูเนียร์อาจจะแย่ลงนิดหน่อย แต่ก็พิสูจน์ได้ยากอีกเหมือนกัน...
ส่วนตัวผมรู้สึกว่าถ้ามีแค่ความรู้ด้าน CS ก็คงไม่ได้ต่างกันมากใช่ไหม
หรืออาจเป็นเพราะตอนนี้ผมใช้มันในลักษณะเหมือนทำ pair programming กับเพื่อนที่มือไวมากและพิมพ์โค้ดให้ทั้งหมดก็ได้...
สุดท้ายแล้วพอพัฒนาลงลึกไปจริง ๆ ก็มักจะมีช่วงที่จำเป็นต้องต้องรู้ว่าข้างใน abstraction layer ทำงานอย่างไร
ช่องว่างระหว่างพรอมป์ต์ภาษาธรรมชาติกับโค้ดที่ถูกสร้างขึ้นมันกว้างเกินไป เลยดูเหมือนว่าจะยากที่จะเจาะจากพรอมป์ต์เข้าไปถึงด้านในของ abstraction layer ของ LLM
ตอนนี้พวกเรายังอยู่ในวิธีการเอาแนวคิดของสเปกที่อยู่ในหัวส่งให้ LLM ผ่านพรอมป์ต์ แล้วกลับมาอ่านโค้ดที่มันเขียนเพื่อตรวจสอบอีกที
มันเลยใกล้เคียงกับการรีวิวโค้ดที่คนอื่นเขียนมากกว่า จึงยังไม่ค่อยให้ความรู้สึกว่าได้เข้าไปอยู่ข้างใน abstraction นั้น
ผมคงละเลย 20% นั้นมากเกินไปจริง ๆ
ช่วงนี้เจอบั๊กที่ AI แก้ไม่ได้... เลยได้ตระหนักว่ามันไม่ใช่ของสารพัดนึก แต่ผมกลับเผลอมองว่ามันเป็นแบบนั้นไปแล้ว
อ๊ะ... 555
เห็นด้วยอย่างมากครับ/ค่ะ ช่วงโปรเจ็กต์ล่าสุดผม/ฉันคอมมิตไปประมาณ 100,000 บรรทัด (ปริมาณโค้ดจริงมากกว่านี้) และโดยเฉลี่ยใช้เอเจนต์ 2-3 ตัว ผม/ฉันคิดว่าประมาณ 95% น่าจะเป็นสิ่งที่เอเจนต์เขียนครับ/ค่ะ
แต่ก็ยังคงต้องมีการจัดการเรื่องเทสต์และโค้ดที่ตายแล้ว รวมถึงต้องมีรายละเอียดเกี่ยวกับเทสต์เคสและเงื่อนไขความสำเร็จของการทดสอบ การกำกับว่าต้องทำอะไรและทำถึงระดับไหนเป็นสิ่งสำคัญ เพื่อให้เป็นเช่นนั้น ไม่ใช่แค่แผนเท่านั้น แต่ยังต้องอัปเดตการตั้งค่าต่าง ๆ อย่างต่อเนื่อง เช่น สถาปัตยกรรมที่ช่วยสร้าง harness และ Rules
ความคิดเห็นจาก Hacker News
น่าสนใจที่ได้เห็นเอเจนต์ พยายามต่อไปโดยไม่เหนื่อยล้า
ทั้ง GPU และ NPU ทำงานกันจนร้อนจัด และเราก็กำลังส่งต่อแม้กระทั่งข้อมูลที่ปกติคงไม่ยอมแชร์
ตอนนี้มันดูเหมือนเป็นการแลกเปลี่ยนที่สะดวก แต่ในระยะยาวมีความเสี่ยงที่ การพึ่งพาและปัญหาสังคม จะขยายใหญ่ขึ้น
ท้ายที่สุดอาจกลายเป็นโครงสร้างที่ต้องพึ่งพาเกตคีปเปอร์รายยักษ์นี้
ระหว่างทำงานร่วมกับ AI ปัญหาที่ใหญ่กว่า สมองฝ่อ ดูจะเป็นการกลายเป็น พอใจตัวเองและหมดเรี่ยวแรง
ตอนแรกผลลัพธ์ที่เร็วทำให้โดพามีนพุ่ง แต่ยิ่งทำซ้ำก็ยิ่งรู้สึกว่า AI กำลังลากทิศทางโปรเจ็กต์ไปตามใจมันเอง
สุดท้ายการทดลองเชิงสร้างสรรค์ที่ฉันต้องการก็หายไป และถูกดูดเข้าไปใน แรงโน้มถ่วงของ latent space ของ AI
มันเหมือน doomscrolling คือเป็นลูปเสพติดที่อยากเห็นเอาต์พุตถัดไปเรื่อย ๆ
กำลังทำเกมมัลติเพลเยอร์ด้วย Rust และ Bevy อยู่ แม้โค้ดจะรันได้ดี แต่กลับกลายเป็น โค้ดที่ฉันเองก็ไม่เข้าใจ
แต่ก่อนคงต้องเข้าใจเครื่องมืออย่างถ่องแท้ถึงจะมาถึงจุดนี้ได้ แต่ตอนนี้ฉันทำเกมที่พอเล่นได้ไปครึ่งหนึ่งแล้วทั้งที่ยัง ไม่รู้ด้วยซ้ำว่า ECS คืออะไร
ถ้าคิดถึงเรื่องการบำรุงรักษาหรือการรับมือเหตุฉุกเฉิน นี่คือสถานะที่อันตรายจริง ๆ
ตอนนี้เรามุ่งไปที่การเรียนรู้วิธีใช้โมเดล และกำลังลืมวิธีคิดด้วยตัวเอง
วิธีใช้ LLM เปลี่ยนตลอดเวลา สุดท้ายก็เหมือนยืนอยู่บน ลู่วิ่งเรียนรู้ไม่มีที่สิ้นสุด
ต่อให้เว้นไปนาน ความรู้สึกก็ยังอยู่ และพอกลับมาทำก็ฟื้นเร็ว
พอ LLM ไม่รู้ นักพัฒนาหลายคนก็ยอมแพ้ไปเลยและไม่อยากอ่านเอกสาร
ต่อให้เราอ่านเอกสารเองแล้วแคปหน้าจอมาให้ดู ก็ยังถามแบบสงสัยว่า “มันใช่เหรอ?”
เพราะความสุขสั้น ๆ คนเลยคอยโยนพรอมป์ต์เข้าไปเรื่อย ๆ และนั่งรอว่า “รอบนี้จะได้อะไรออกมา”
การเขียนโค้ดด้วย LLM กำลังกลายเป็นตัวแบ่งระหว่าง ‘คนที่ชอบการเขียนโค้ด’ กับ ‘คนที่ชอบการสร้างของ’
ฉันเป็นสาย builder ที่ชอบทำให้เกิดผลลัพธ์ ดังนั้นการเปลี่ยนแปลงนี้จึงสนุก
ในทางกลับกัน คนที่สนุกกับการเขียนโค้ดเองจะรู้สึกอึดอัดกับกระแสนี้
เสน่ห์ของการเขียนโปรแกรมอยู่ที่ กระบวนการจัดโครงสร้างปัญหาและลงมือทำเอง
ตอนนี้มันเหมือน “ไม่ใช่ฉันที่เขียนโค้ด แต่เป็นการสั่งให้คนอื่นทำ” เลยทำให้ความสนใจลดลง
ในอดีตก็เคยมีความขัดแย้งอย่าง compile vs interpret, typed vs untyped, deploy ให้เร็ว vs ดูแลรักษาง่าย
สุดท้ายซอฟต์แวร์ที่ประสบความสำเร็จมักผ่านกระบวนการจาก ช่วงเริ่มต้นที่วุ่นวายไปสู่ช่วงขยายตัวอย่างมั่นคง
ตอนนี้ยังไม่แน่ใจว่า AI ช่วยกระบวนการนี้ หรือกลับทำให้มันซับซ้อนกว่าเดิม
ไม่ได้สนใจแค่ผลลัพธ์ แต่สนุกกับกระบวนการวางโครงสร้างระบบ
เพื่อนร่วมทีมที่เป็นมนุษย์มี ความรับผิดชอบและความน่าเชื่อถือ แต่ LLM ไม่มีสิ่งนั้น
แนวคิดที่ว่า AI อาจนำมาซึ่ง การเพิ่มผลิตภาพ 10 เท่า นั้นน่าสนใจ
DevOps เปลี่ยนรูปแบบการทำงานร่วมกันระหว่างพัฒนาและปฏิบัติการจนสร้าง ทีมประสิทธิภาพสูง ได้ และสิ่งนี้ให้ผลใกล้เคียงกับ 10X ในระดับทีม
ถ้าจะใช้ AI coding ให้เก่ง ก็ต้องมีเหมือน DevOps คือกระบวนการ ปรับปรุงอย่างต่อเนื่อง การเปลี่ยน workflow และการสร้างความเชื่อมั่นผ่าน automation/verification
เช่นเดียวกับที่ DevOps ต้องอาศัยการเรียนรู้แนวคิดใหม่และการเปลี่ยนวัฒนธรรมทีมจนทำให้ไม่ได้แพร่หลายง่าย ๆ AI coding ก็อาจมีศักยภาพ 10X แต่ถ้าไม่มี การเรียนรู้/การเปลี่ยนวัฒนธรรม การปรับตัวก็อาจช้า
การจะลงหลักปักฐานได้ต้องมี การศึกษา และการเปลี่ยนแปลงวัฒนธรรมวิศวกรรม
รู้สึกว่า LLM ไร้ประโยชน์กับโค้ดเบสขนาดใหญ่
โดยเฉพาะในโค้ดที่ซับซ้อนและมีปฏิสัมพันธ์กันมาก แทบไม่ช่วยอะไรเลย
การเอาไปใส่ในโค้ดเบสใหญ่/ซับซ้อนที่มีอยู่แล้วนั้นเสี่ยง ถ้าไม่ใช่การเปลี่ยนแปลงที่จำกัดวงและมีการรีวิวอย่างละเอียด
วิธีให้รายการไฟล์ในโครงสร้างง่าย ๆ แล้วปล่อยให้เอเจนต์ไปลงมือทำเองนั้นน่าประทับใจ แต่พอความซับซ้อนสูงขึ้น พรอมป์ต์ก็ต้องค่อย ๆ ลงไปสู่ คำสั่งที่ละเอียดมากขึ้น ถึงจะยังได้ผล
ต่างจากโมเดลก่อนหน้า ตอนนี้มันช่วยงานได้จริงแม้ในโมโนรีโปที่ซับซ้อน
ลองเทียบดูว่ามันทำได้ดีกว่าสมาชิกใหม่ในทีมที่มีข้อมูลเท่ากันหรือไม่
โค้ดเบสภายในเชิงพาณิชย์มักเละเทะจากการพัฒนาซ้ำเพื่อตอบโจทย์ลูกค้า จนสมมติฐานแรกเริ่มกับความต้องการจริงค่อย ๆ คลาดกันและเกิด หนี้ทางเทคนิค
ถ้าใช้ LLM รีแฟกเตอร์แยก helper / ทำโมดูลาร์ / เปลี่ยนชื่อ ฯลฯ ให้สอดคล้องกับความต้องการปัจจุบัน การทำงานของเอเจนต์หลังจากนั้นจะคาดเดาได้มากขึ้น
ต้องมีโฟลว์แบบเป็นขั้นตอน คือจัด requirement / acceptance criteria / user story เป็น markdown ให้ชัดเจน ให้มันเขียนแผนอย่างละเอียดก่อน แล้วค่อยไปสู่การลงมือทำจริง
น่าประทับใจที่ ความอึดและพลังงานในการทำงาน ของ AI ก้าวข้ามขีดจำกัดของมนุษย์
แม้ในงานวิจัยก็มีคำกล่าวว่า grit มากกว่าความฉลาด สัมพันธ์กับความสำเร็จมากกว่า
ตราบใดที่งบประมาณยังไหว LLM ก็มีความอึดได้ไม่สิ้นสุด
ช่วงไม่กี่เดือนมานี้รู้สึกว่า ประสิทธิภาพของ AI ถดถอยลงด้วยซ้ำ
มันลืมกฎ และสร้างทั้ง แผนที่มากเกินไป กับ โค้ดที่ออกแบบเกินจำเป็น
แต่สำหรับงานฟรอนต์เอนด์ (HTML + Tailwind) ก็ยังมีประโยชน์อยู่
รู้สึกว่าความคาดหวังที่สูงเกินไปต่อ IDE หรือ agent swarm ยังเร็วเกินไป
ระหว่างทำแอป iPhone ก็ทึ่งกับ ความสามารถในการสร้างโค้ดจากพรอมป์ต์ภาษาอังกฤษ ของ Claude
> การเขียนโค้ดด้วย LLM ทำให้วิศวกรถูกแบ่งออกเป็นคนที่ชอบการเขียนโค้ดเอง กับคนที่ชอบการสร้างสิ่งต่าง ๆ
ถ้ารวบรวมสิ่งที่ผมได้ยินจากคนรอบตัวดู ก็รู้สึกว่าสุดท้ายแล้วน่าจะถูกแบ่งออกมาแบบนี้จริง ๆ