- เอเจนต์เขียนโค้ดด้วย AI ช่วยเพิ่มความเร็วในการเขียนโค้ดได้อย่างมาก แต่ส่วนที่สำคัญที่สุดในกระบวนการพัฒนาจริงยังคงเป็น ความเข้าใจและการแก้ปัญหา
- แม้จะใช้ LLM เพื่อสร้างโค้ดได้อย่างรวดเร็ว แต่เพราะขาดความเข้าใจบริบทโดยรวม จึงต้องใช้เวลากับ งานหลังการสร้างโค้ด และการทำความเข้าใจมากขึ้น
- ส่งผลให้เกิดช่องว่างระหว่าง ความคาดหวังด้านประสิทธิภาพการผลิตกับประสิทธิผลที่เกิดขึ้นจริง และทำให้นักพัฒนาต้องใช้เวลากับ งานซ้ำ ๆ และน่าหนักใจอย่างการทดสอบ การรีแฟกเตอร์ และการทำเอกสาร แทนงานสร้างสรรค์ที่ต้องการทำ
- เช่นเดียวกับ 'ภาวะกลืนไม่เข้าคายไม่ออกของเทครีด' ในอดีต หากเทงานซับซ้อนให้ AI หรือซีเนียร์เพื่อหวังผลระยะสั้น ก็อาจนำไปสู่ การลดลงของศักยภาพทีมในระยะยาว และก่อวิกฤตได้
- ควรมอง LLM เป็น วิศวกรจูเนียร์ที่ทรงพลัง และนำกระบวนการพัฒนาที่ผ่านการพิสูจน์แล้วมาปรับใช้กับการทำงานร่วมกับ AI เพื่อสร้างโครงสร้างสำหรับ การส่งมอบซอฟต์แวร์อย่างยั่งยืน
การตระหนักถึงปัญหา: สิ่งที่สำคัญยิ่งกว่าการเขียนโค้ดเอง
- การพัฒนาซอฟต์แวร์เป็นงานที่มีศูนย์กลางอยู่ที่ การแก้ปัญหา
- การเขียนโค้ดจริงเป็นเพียง ส่วนท้าย ของกระบวนการคิดและการพิจารณาทั้งหมดของนักพัฒนา
- นอกจากโค้ดแล้ว นักพัฒนายังต้องทำงานอีกมาก เช่น การทำความเข้าใจโดเมน การแยกย่อยความต้องการ การทำ abstraction การพิจารณาผลข้างเคียง การทดสอบแบบค่อยเป็นค่อยไป และการแก้บั๊ก
- เวิร์กโฟลว์การพัฒนาแบบเดิม: คิดให้เพียงพอก่อนแล้วค่อยเขียนโค้ด
- ยุคของ AI coding: เปลี่ยนไปสู่รูปแบบ โค้ดมาก่อน ความเข้าใจตามมาทีหลัง
การเปลี่ยนผ่านของ AI coding: กระบวนทัศน์ที่โค้ดถูกสร้างขึ้นก่อน
- เอเจนต์เขียนโค้ดด้วย AI อย่าง Claude Code สามารถสร้างโค้ดได้อย่างรวดเร็ว แต่ไม่อาจเข้าใจบริบทของทั้งระบบได้อย่างสมบูรณ์
- กระบวนการ ตรวจทาน ทดสอบ และผสานรวม โดยมนุษย์ยังคงจำเป็น และต้องใช้เวลามากในการทำความเข้าใจโค้ดที่ AI เขียนขึ้นภายหลัง
- การตลาดมักเน้น ความเร็วในการเขียนโค้ดที่เพิ่มขึ้น แต่ในทางปฏิบัติ การเพิ่มขึ้นของ ผลิตภาพในการส่งมอบซอฟต์แวร์ที่ใช้งานได้จริง กลับมีน้อยมาก
- นักพัฒนาต้องใช้เวลากับงานซ้ำ ๆ และยากมากขึ้น เช่น การทดสอบ การกำจัดความซ้ำซ้อน การทำเอกสาร และการจัดการโครงสร้างพื้นฐาน ของผลลัพธ์ที่ AI สร้างขึ้น
- เกิดประสบการณ์ที่ ความสนุกของการเขียนโค้ดจริงลดลง ขณะที่งานซ้ำเพิ่มขึ้น
ภาวะกลืนไม่เข้าคายไม่ออกที่เก่าแก่ของผู้นำด้านเทคนิค
- เมื่อวิศวกรรับบทบาท เทครีด ก็ต้องแบกรับ ความรับผิดชอบในการส่งมอบทางเทคนิค ของทีม
- เมื่อประสบการณ์ในทีมกระจุกอยู่ที่คนคนเดียว จะเกิด ความไม่สมดุลด้านประสิทธิภาพการผลิต
- จึงเกิดความขัดแย้งระหว่างสองกลยุทธ์ คือ การกระจายงานอย่างเป็นธรรม (ให้ความสำคัญกับการเติบโตของทีม) และ การเทงานให้บางคน (มุ่งเน้นการพัฒนาให้เร็ว)
- การเทงานให้บางคนให้ผลดีระยะสั้นสูง แต่ก็ก่อให้เกิด ความเสี่ยงระยะยาว ของทีมจากการกระจุกตัวของประสบการณ์ เช่น การขาดคนค้ำทีม ภาวะหมดไฟ และการหาคนมาช่วยได้ยาก
- หากต้องการวัฒนธรรมทีมที่ดี จำเป็นต้องหาวิธีสร้าง สมดุลระหว่างการเติบโตกับประสิทธิภาพ
แก่นสำคัญของภาวะผู้นำที่ดี: สมดุลระหว่างกระบวนการกับการเติบโต
- จำเป็นต้องนำ หลักการพัฒนา และ เฟรมเวิร์ก ต่าง ๆ มาใช้ เพื่อให้ทั้งทีมเรียนรู้โนว์ฮาวของวิศวกรที่มีประสบการณ์
- ตัวอย่าง: Extreme Programming, code review, การปล่อยใช้งานแบบค่อยเป็นค่อยไป, การออกแบบแบบโมดูลาร์, การพัฒนาแบบ test-driven, pair programming, การทำเอกสาร, continuous integration เป็นต้น
- เป้าหมายสูงสุดคือ ลดงานทำซ้ำให้ต่ำสุด เพิ่มการทำงานร่วมกันให้สูงสุด และส่งเสริมการเติบโตของแต่ละบุคคล
การทำงานร่วมกับเอเจนต์ AI: บทบาทใหม่ของผู้นำทีม
- เอเจนต์เขียนโค้ดบนพื้นฐาน LLM รุ่นใหม่มีลักษณะคล้าย นักพัฒนาจูเนียร์ที่เร็วมหาศาล
- ต่างจากจูเนียร์ทั่วไปตรงที่ LLM มีความต่างชัดเจนคือ ไม่มีความสามารถในการเรียนรู้ และ ไม่มีข้อจำกัดด้านความเร็ว
- AI มุ่งเน้นไปที่ การเพิ่มความเร็ว อย่างต่อเนื่องมากกว่าการยกระดับคุณภาพ และยังขาดความเข้าใจบริบทและโดเมนของมนุษย์
- รูปแบบการทำงานร่วมกันมี 2 แบบ:
- วิศวกรรมที่ขับเคลื่อนด้วย AI: มุ่งสู่การทำงานเป็นทีมที่มีประสิทธิภาพและยั่งยืน แม้จะช้ากว่า
- vibe coding: มุ่งเน้นการได้ผลลัพธ์อย่างรวดเร็ว แต่ค่อย ๆ สะสม ความยุ่งเหยิงที่กู้คืนไม่ได้
- คล้ายกับจุดบอดแบบดั้งเดิมของการเติบโตของโค้ดในซิลิคอนแวลลีย์: ได้ประโยชน์ระยะสั้นก่อน แล้วจึงชนกับ กำแพงข้อจำกัดด้านการเติบโต
วิธีปฏิบัติจริงเพื่อเอาตัวรอดจากกับดัก AI coding
- LLM ไม่รู้สถานการณ์ของตนเองและสามารถผลิต โค้ดจำนวนมากอย่างไร้การกลั่นกรอง
- วิศวกรต้องจัดเตรียม โครงสร้าง มาตรฐาน และกระบวนการที่ชัดเจน ให้ AI เพื่อเปลี่ยน ผลลัพธ์ดิบ ให้เป็นบริการจริง
- ต้องมี playbook ใหม่ที่นำ best practices ของวงจรการพัฒนาแบบดั้งเดิมมาปรับใช้อย่างแนบแน่นกับสภาพแวดล้อมการทำงานร่วมกับ AI
- แนวทางใช้ AI ในแต่ละขั้นตอนหลัก:
- การกำหนดสเปก: วิเคราะห์ edge case และโฟกัสขอบเขตของเป้าหมาย
- การทำเอกสาร: เก็บคู่มือและหลักฐานที่นำกลับมาใช้ซ้ำได้
- การออกแบบโมดูล: จำกัดบริบทเพื่อเพิ่มความเข้าใจ
- การพัฒนาแบบ test-driven: สร้าง test case ก่อนลงมือพัฒนา เพื่อป้องกัน regression
- มาตรฐานการเขียนโค้ด: รักษาสไตล์และคุณภาพ
- การมอนิเตอร์: วิเคราะห์ล็อกอัตโนมัติและดึง insight
บทสรุป
- การส่งมอบซอฟต์แวร์ ไม่ได้เกิดจากการเขียนโค้ดเพียงอย่างเดียว และจำเป็นต้องวางโครงสร้างการทำงานร่วมกันระหว่าง AI กับมนุษย์อย่างมีประสิทธิภาพ
- ต้องมอง LLM เป็น นักพัฒนาจูเนียร์ความเร็วสูงพิเศษ และใช้กระบวนการพัฒนาที่ผ่านการพิสูจน์แล้ว จึงจะสามารถส่งมอบ ซอฟต์แวร์คุณภาพสูงที่ขยายต่อได้
2 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อยากเห็นข้อโต้แย้งแบบ anti-AI ที่ไม่ได้ตั้งอยู่บนคำกล่าวง่าย ๆ ว่า “เทคโนโลยีทำให้คนขี้เกียจ” คนที่เคยใช้ LLM สร้างโค้ดอย่างจริงจังคงรู้สึกได้ว่าวงจร วางแผน-ประกอบ-ทดสอบ-ทบทวน ยังสำคัญมากอยู่ดี ถ้าปล่อยรันแบบไม่ระวังก็พังได้ง่ายมาก ถ้าใช้วงจรนี้ให้ดี ก็จะได้ใช้เวลาไปกับการทดสอบการออกแบบสถาปัตยกรรมและประสบการณ์ผลลัพธ์ที่ตัวเองชอบมากขึ้น เพราะ LLM จัดการส่วนที่ง่ายได้เร็ว สุดท้ายสิ่งที่เหลือให้เราทำคือพวกงานที่น่าสนใจน้อยกว่าและไม่ค่อยมีใครเห็นคุณค่า ในสายงานที่ AI ทำให้ความเชี่ยวชาญยิ่งโดดเด่น ความเห็นต่างระหว่างคนที่สนุกกับตัวงานเองกับคนที่สนุกกับการคิดจึงยิ่งชัด คนที่ชอบคิดจะได้โฟกัสแทบทั้งหมดกับส่วนนั้นเพราะ AI แต่สำหรับคนที่ชอบพิมพ์และลงมือควบคุมเอง AI กลับเหมือนมาแย่งส่วนที่ตัวเองชอบไป
สำหรับการสร้างโค้ดด้วย AI ผมมองว่าคำวิจารณ์ที่สำคัญกว่าความคิดที่ว่าเทคโนโลยีทำให้คนขี้เกียจ คือมันดึงความเข้าใจเชิงลึกต่อโค้ดที่ AI สร้างออกไป แก่นของวิศวกรซอฟต์แวร์ไม่ใช่การสร้างโค้ด แต่คือการออกแบบระบบทั้งหมด สิ่งสำคัญตรงนี้คือ mental model ว่าโค้ดทำงานอย่างไรและความเชี่ยวชาญในโดเมน โดยโค้ดเป็นเพียงผลลัพธ์ที่แตกออกมาจากแบบจำลองทางความคิดนี้ ในโปรเจกต์ที่มีขนาดเกินระดับหนึ่ง หากไม่ใช่คนที่เขียนโค้ดเองก็มักยากที่จะรู้โค้ดนั้นได้อย่างถ่องแท้ ถ้าไม่สร้าง mental model เหล่านี้ ปัญหาอื่น ๆ ก็จะตามมาอีก เอเจนต์เขียนโค้ดที่อิง LLM ยังมีข้อจำกัดด้านการให้เหตุผลระดับไวยากรณ์ จึงมีจุดอ่อนเรื่องการขยายสเกล
ถ้าพูดถึงมุมมองของผม ผมใช้เครื่องมือ AI อย่าง Cline เป็นบางครั้ง แต่ยิ่งนานก็ยิ่งพิมพ์โค้ดเองมากขึ้น เหตุผลคือในหลายกรณีมันแค่แทนการเขียนโค้ดด้วยการเขียนพรอมป์ต ถ้าเวลาที่ใช้เขียนพรอมป์ตและรอให้มันคิดสั้นกว่าการเขียนโค้ดเอง ผมก็จะใช้ AI แต่ปกติสิ่งนี้จะเกิดเฉพาะตอนชนเพดานความเร็วระดับรีแฟกเตอร์เท่านั้น งานส่วนใหญ่ถ้าทำเองใช้ 10 นาที แต่ถ้าใช้ AI ก็หมดเวลาเขียนพรอมป์ต รัน แล้วใช้ 8 นาที ถ้ามันออกมาถูกโดยไม่พลาดก็ประหยัดได้ 2 นาที แต่ถ้าต้องแก้หรือพรอมป์ตใหม่ก็กลับกลายเป็นใช้ 10~12 นาที แถมยังเสีย AI เครดิตอีก แย่สุด ๆ พอคิดแบบนี้แล้ว เมื่อมองทั้งคุณภาพโค้ดและเวลาที่ใช้ ก็มาสรุปว่างานทำมือปลอดภัยกว่า
ต่อข้ออ้างที่ว่าเทคโนโลยีทำให้คนสะเพร่า ในภาพรวมแล้วหลายครั้งเทคโนโลยีกลับทำให้คนระมัดระวังมากขึ้นด้วย ปัญหาคือเทคโนโลยี AI นี้มีแนวโน้มสูงที่จะชักนำให้ผู้ใช้สะเพร่า สำหรับผม สิ่งที่สนใจไม่ใช่ส่วนสนุกของการเขียนโค้ด แต่ชอบงานออกแบบ (สถาปัตยกรรม) มากกว่า ถ้ามีวิธีสะท้อนเจตนาให้กลายเป็นโค้ดได้ตรง ๆ ผมก็จะใช้ แต่ interface แบบแชตบอตส่งต่อเจตนาได้อย่างอ้อม ๆ และไม่สมบูรณ์ พอเอาไปใช้กับการสร้างโค้ดระดับสูง โมเดลในหัวของผมกับความเข้าใจโค้ดจริงก็ห่างออกจากกันเร็ว จนเหลือฐานที่ไม่มั่นคง จะไล่รีวิวทีละบรรทัดอย่างละเอียดก็ทำได้ แต่ก็สวนทางกับจุดประสงค์ของเครื่องมือ AI coding ชอบสร้างความรู้สึกว่า “เร็วขึ้น 10 เท่า” จึงยิ่งกระตุ้นช่องว่างระหว่างรายละเอียดการลงมือทำกับความเข้าใจภาพใหญ่ ที่จริงแล้วการคิดเรื่องโครงสร้างให้น้อยลงคือหนึ่งในข้อดีหลักที่ใช้โปรโมต AI coding แต่ช่องว่างความเข้าใจนี้จะกลายเป็นปัญหาทีหลัง ระบบอัตโนมัติที่ดีควรเชื่อถือได้และคาดเดาได้ จนเราเข้าใจเพียง invariant ระดับบนก็พอ แต่โค้ดจากแชตบอตไม่ให้หลักประกันแบบนั้น สุดท้ายจึงกลายเป็นโครงสร้างที่ต้องตรวจทุกอย่างด้วยมืออยู่ดี ในบริบทนี้ความปลอดภัยและความน่าเชื่อถือกลับยิ่งยากขึ้น
ผมเห็นตรรกะแบบ “โฟกัสกับส่วนที่ต้องคิด” บ่อยเกินไปจนเริ่มเอียนแล้ว ปัญหาคือผมสงสัยว่าคนที่ยังไม่เคยผ่านงานจริงมาหลายปี จะทำงานที่ลึกซึ้งได้ด้วยการคิดอย่างเดียวจริงหรือ สุดท้ายถ้าไม่มีประสบการณ์ลงมือทำเอง ความคิดเองก็เสี่ยงจะค่อย ๆ ตื้นขึ้น
มุมมองของผมคือ ดีบักยากกว่าการเขียน ดังนั้นแทนที่จะไปดีบักโค้ดที่ผมไม่ได้เขียน ผมว่าเขียนเองยังดีกว่า
ทุกครั้งที่อ่านการถกเถียงแบบนี้ ผมก็มักคิดว่า ผู้เขียนใช้เครื่องมือเดียวกับผมหรือเปล่า เพราะผมใช้ Claude Code ทำได้แทบทุกอย่าง ตั้งแต่ boilerplate ง่าย ๆ ไปจนถึงอัลกอริทึมซับซ้อน แม้ในโค้ดเบสขนาดใหญ่ที่สับสนมากก็ยังทำได้ แน่นอนว่าไม่ถูก 100% แต่ใกล้มาก แถมยังเสนออัลกอริทึมที่ผมเองนึกไม่ถึงบ่อย ๆ เครื่องมือพวกนี้ช่วยประหยัดเวลาให้ผมได้อย่างน้อย 10 เท่า
บทความนี้โอเค แต่ผมเห็นจุดพลาดอยู่สองอย่าง อย่างแรก ต่อให้เป็นนักพัฒนาที่ชำนาญแล้ว เวลาจะใช้ LLM ก็ยังจำเป็นต้องสำรวจ คิดล่วงหน้า และออกแบบให้มากอยู่ดี ที่จริงถ้าจะใช้ LLM ให้ดี ยิ่งต้องคิดมากกว่าปกติ เปรียบเทียบทางเลือกการออกแบบหลายแบบ และวาดโครงสร้างรวมทั้งระบบ สมัยก่อนผมไม่ได้บันทึกกระบวนการนี้ แต่ตอนนี้เริ่มเก็บไว้เป็นเอกสารการออกแบบแล้ว อย่างที่สองคือข้ออ้างที่ว่า LLM เหมือนนักพัฒนาจูเนียร์ที่ไม่เติบโต ซึ่งสองอย่างนี้ต่างกันโดยสิ้นเชิง มนุษย์จูเนียร์คือคน ส่วน LLM คือเครื่องมือ ประเด็นสำคัญที่มักพูดกันคือ ถ้าทำงานกับพนักงานใหม่จะเกิดคุณค่าสะสม แต่กับ LLM ไม่ใช่แบบนั้น ซึ่งผมก็คิดว่าไม่จริงเหมือนกัน ต่อให้ LLM ไม่ได้เรียนรู้ ผมเองกลับฝึกมันและใช้งานมันได้มีประสิทธิภาพมากขึ้นอย่างชัดเจน นี่เป็นช่วงแรกของการเอา LLM ไปใช้กับผลิตภัณฑ์อย่างจริงจัง จึงเป็นธรรมดาที่จะเห็นคุณค่าการเติบโตในหลายมิติแบบซับซ้อน
เห็นด้วยกับ “ถึง LLM จะไม่เรียนรู้ แต่ผมเรียนรู้” แต่ผมก็ยังอยากให้ LLM เรียนรู้จากการโต้ตอบกับผู้ใช้ได้จริง สิ่งที่ผมต้องการคือให้สามารถบันทึก/โหลดเนื้อหาของเซสชันเป็นไฟล์ แล้ว LLM เข้าใจคอนเท็กซ์ทั้งหมดที่เคยเรียนรู้มาก่อนโดยไม่มีตกหล่น แม้ UI ฝั่งฟรอนต์เอนด์บางตัวจะบันทึก/กู้คืนเซสชันได้ แต่จุดสำคัญคือ a) อยากให้ “การเรียนซ้ำ” แบบนี้ไม่ไปกิน current context window ของ LLM (หรือจริง ๆ อยากให้แนวคิดนี้หายไปเลย) และ b) ต้องเป็นวิธีที่ไม่มีการสูญหายเด็ดขาด ตอนนี้มีทั้งการสรุปแล้วคุยต่อ หรือแนวทางแบบ RAG ออกมาแล้ว แต่ทั้งหมดนี้ก็ยังมีข้อจำกัดพื้นฐาน เช่น ข้อมูลสูญหาย หรือกู้คืนได้ก็ต่อเมื่อถูกกระตุ้นจากการโต้ตอบปัจจุบันเท่านั้น ตัวอย่างเช่น เมื่อวานผมอธิบายฟังก์ชันหนึ่งให้ LLM ฟังแล้วเซฟเซสชันไว้ วันนี้พอกู้คืนเซสชันแล้วถามคำถามที่ไม่เกี่ยวกันเลย ก็ยังอยากให้ LLM ตอบโดยคำนึงถึงบริบทเก่าทั้งหมดด้วย และถ้าอยากเริ่มใหม่แบบ clean slate ก็ควรทำได้อย่างชัดเจนเช่นกัน
ถูกต้อง เพราะในผลิตภาพรวมของงานซอฟต์แวร์ เวลาที่ใช้คิดกินสัดส่วนมากกว่าเวลาที่ใช้เขียนโค้ดจริงมาก ดังนั้นต่อให้ LLM ทำส่วนการเขียนโค้ดได้เร็วขึ้น ก็ไม่ได้ทำให้ผลิตภาพรวมหรือความต้องการกำลังคนเปลี่ยนแบบมหาศาล
สำหรับผม การเริ่มด้วยพรอมป์ต
DO NOT WRITE ANY CODE YETเป็นค่าปกติอยู่แล้ว มันเป็นวิธีทำความเข้าใจก่อนว่า LLM กำลังจะทำอะไร และทำให้ผมยังคุมเกมได้ ผมสนุกกับตัวงานออกแบบเองมากกว่าการเขียนโค้ด ไม่ว่าจะเป็นตรรกะ การแก้ปัญหา หรือการบูรณาการระบบมีฟีเจอร์อย่างโหมด Ask ของ Copilot หรือโหมด Plan/Chat ของ GPT-5 Codex ที่ให้วางแผนได้โดยไม่แก้ไฟล์โค้ด ผมลองใช้ Codex อยู่สองสามวัน ถ้าให้คำสั่งละเอียดพอก็เก่งมาก
ผมเองก็ชอบถาม LLM ประมาณว่า “ช่วยบอกแผนก่อน” ก่อนจะลงมือทำอะไรแบบเจาะจง
บทความนี้อ้างแค่เอกสารการตลาดของ Microsoft แล้วบอกว่าผลิตภาพดีขึ้น 10% แต่ในงานวิจัยของ Harvard กลับพบว่าผลิตภาพลดลง 10% ด้วยซ้ำ ผมอยากเห็นบทความที่อ้างผลงานวิจัยอิสระก่อน มากกว่าการอ้างสื่อประชาสัมพันธ์ของบริษัทใดบริษัทหนึ่ง
อีกประเด็นสำคัญที่บทความนี้สื่อออกมาได้ไม่ครบ คือคำพูดของ Casey Muratori ที่ว่า “ถ้าคุณเขียนโปรแกรมด้วย mindset ที่เน้นการเรียนรู้ AI แทบไม่มีความหมายเลย” ผมเห็นด้วย โดยส่วนตัวผมมองว่า AI code generator มีประโยชน์กับโค้ดใช้ครั้งเดียวหรือโค้ดที่ตั้งใจจะทิ้งเท่านั้น ในด้านที่อยากเรียนรู้อย่างจริงจัง ผมรู้สึกว่าการไม่ให้ AI สร้างโค้ดแทนจะช่วยเพิ่มผลลัพธ์ด้านการเรียนรู้ได้มากที่สุด แน่นอนว่า “AI-driven engineering” คงมีความหมายสำหรับบางคน แต่สำหรับผม อย่างน้อยการได้เขียนบล็อกโค้ดด้วยมือตัวเองยังสนุกกว่า และสุดท้ายก็รู้สึกว่างานที่ออกมาสมบูรณ์กว่าด้วย วิดีโอที่เกี่ยวข้อง ความยาว 5 นาที
พอใช้ Claude Code แล้ว ผมใช้เวลาไปกับการคิดมากขึ้นเยอะมาก ผมไม่เคยต้องบรรยายฟีเจอร์ที่อยากได้เป็นคำ 400~600 คำมาก่อน แต่ตอนนี้กลับต้องนั่งจัดระเบียบข้อมูลให้แน่นขึ้น การคิดแบบนี้ทำให้ผลลัพธ์ออกมาเร็วและดีขึ้นจริง แต่ในขณะเดียวกัน ความเข้าใจโค้ดของผมเองก็ลดลงจากเมื่อก่อนเล็กน้อย อย่างไรก็ตาม ผมไม่เห็นด้วยกับข้ออ้างที่ว่าเมื่อใช้ Claude Code แล้วนักพัฒนาที่มีประสบการณ์จะคิดน้อยลง ผมเดาว่าหลายคนคงใช้เอเจนต์อย่างไม่มีประสิทธิภาพ เช่น แทบเขียนแต่พรอมป์ตอย่างเดียว แต่ผมไม่คิดว่านั่นเป็นความผิดของเอเจนต์
เวลาเห็นการถกเถียงพวกนี้ ผมมักคิดว่าตอนนี้ยังเป็นช่วงเปลี่ยนผ่านที่คลุมเครือ อีกสักปี การถกเถียงแบบวันนี้อาจถูกมองว่า “คิดมากเกินไป” ก็ได้ มันดูคล้ายกับช่วงก่อนและหลังอินเทอร์เน็ตแพร่หลาย ที่มีคำถามมากมายว่าเป็น “กระแสชั่วคราว” หรือ “การลงทุนที่ผิดพลาด”
สิ่งที่บทความแบบนี้มักพลาดมีดังนี้
อยากเห็นบทความที่สรุปข้อดี ข้อเสีย และ trade-off ของตัวช่วยเขียนโค้ดด้วย AI อย่างเป็นระบบ โดยไม่ใส่การตัดสินเชิงศีลธรรมว่า “ดี/ไม่ดี” เข้าไป ผมยอมรับว่าถ้า “ทักษะการเขียนโค้ด” เป็นส่วนหนึ่งของอัตลักษณ์ตัวเอง ก็ยิ่งยากที่จะมองเรื่องนี้อย่างเยือกเย็น
ทุกวันผมคอยให้กำลังใจตัวเองว่า “ทนอีกแค่ 30 ปีก็เกษียณได้แล้ว” ทำงานด้านแมชชีนเลิร์นนิงมา 10 ปี เหนื่อยทั้งกับการนั่งหน้าคอมและเหนื่อยกับงานแล้ว แค่อยากไปนอนกลิ้งบนสนามหญ้า
กราฟ “คิด&เขียนโค้ด vs คิด&แก้ไข” น่าสนใจดี ช่วงหลังผมใช้ Codex แล้วคาดว่า AI จะทำให้ต้องแก้โค้ดของตัวเองเยอะขึ้นแน่ ๆ แต่ในความเป็นจริง เวลามักหายไปมหาศาลตอนต้นเหตุของปัญหาไม่ได้เกี่ยวกับโค้ดเลย ช่วงหลังผมเสียเวลาไล่ดูโค้ดอยู่นานเพราะปัญหาการยืนยันตัวตน สุดท้ายพบว่าต้นเหตุคือการตั้งค่า ipv6 ของ VM มีปัญหา
เห็นด้วยมากครับ/ค่ะ เวลาใช้ AI เขียนโค้ด งานตามมาเพื่อเก็บรายละเอียดมีเยอะมาก จนลำบากมากในการนำไปหลอมรวมเข้ากับธุรกิจจริงและดูแลรักษาต่อ
ถึงจะทำงานในมุมที่เหมือนพัฒนาด้วยกัน คอยโต้ตอบไปมาระหว่างทางให้มากที่สุดแล้วก็ตาม แต่เพราะมีบางส่วนของโค้ดที่ไม่ได้เขียนเองโดยตรง จึงมักมีกรณีที่หลุดหายไปจากความทรงจำ
ผม/ฉันคิดว่าการมีขอบเขตเป็นสิ่งจำเป็นอย่างแน่นอน