มนุษย์ในลูปนั้นเหนื่อยล้าแล้ว
(pydantic.dev)- การเขียนโปรแกรมด้วย LLM เพิ่มผลิตภาพก็จริง แต่ในขณะเดียวกันก็เพิ่ม ความเหนื่อยล้าจากการกำกับดูแล เพราะนักพัฒนายังต้องควบคุมเจตนาและคุณภาพอย่างต่อเนื่อง ทำให้ความพึงพอใจและความยั่งยืนสั่นคลอน
- โมเดลสร้างโค้ดที่ดูน่าเชื่อถือได้อย่างรวดเร็ว แต่สามารถพลาดเจตนาที่สอดคล้องกันของการเปลี่ยนแปลงที่ซับซ้อนได้ ทำให้มนุษย์กลายเป็น ด่านคุณภาพ ที่ต้องตรวจและแก้ผลลัพธ์ที่เพิ่มขึ้น
- แม้งานที่เริ่มทำได้จะพุ่งขึ้นมาก แต่ปริมาณงานที่ทำให้เสร็จอย่างรอบคอบยังถูกจำกัดด้วยสมองและความใส่ใจของมนุษย์ ขณะที่รางวัลเล็กๆ จากการเขียนโค้ดลดลง และภาระทางความคิดจากการรีวิวเพิ่มขึ้น
- ในโดเมนที่เข้าใจอย่างลึกซึ้ง มนุษย์สามารถชี้นำ LLM ได้อย่างมีประสิทธิภาพ แต่ในโดเมนที่ความเชี่ยวชาญตื้น ผลลัพธ์มักเอนเอียงไปทางความดูน่าเชื่อถือมากกว่าความถูกต้อง ทำให้ รสนิยมและการตัดสินใจด้านสถาปัตยกรรม สำคัญยิ่งขึ้น
- ซอฟต์แวร์วิศวกรรมไม่ได้หายไป แต่กำลังหดตัวและถูกจัดระเบียบใหม่ โดยทรัพยากรที่หายากไม่ใช่การเขียนโค้ดเอง หากแต่เป็น ความใส่ใจของมนุษย์ การตัดสินใจเชิงวิศวกรรม และความสามารถในการรักษาวิสัยทัศน์ที่สอดคล้องกันของระบบ
การเขียนโปรแกรมด้วย LLM ที่มีประโยชน์แต่ไม่เสถียร
- การเขียนโปรแกรมด้วย LLM มีประโยชน์จริงแต่ไม่เสถียร และหากมองข้ามความไม่เสถียรนี้ นักพัฒนาอาจหมดไฟได้
- ทีม Pydantic เองก็เผชิญความสับสนแบบเดียวกันระหว่างสร้างเครื่องมือตรวจสอบข้อมูล สร้าง AI agent และเครื่องมือสังเกตการณ์ระดับโปรดักชัน
- แก่นสำคัญไม่ใช่ว่า AI จะมาแทนโปรแกรมเมอร์หรือไม่ แต่คือประสบการณ์การพัฒนาในปัจจุบันเปลี่ยนไปอย่างไร และจะปรับปรุงมันด้วยอะไรได้บ้าง
ความรู้สึกของการลงมือสร้างด้วยมือ
- การเขียนโปรแกรมเคยมอบ ความรู้สึกของการสร้างสรรค์ จากการสร้างบางสิ่งด้วยตรรกะล้วนๆ และการจัดการชั้นนามธรรมที่ลึกด้วยตนเอง
- สำหรับผู้ที่เรียนซอฟต์แวร์วิศวกรรมผ่านการลองผิดลองถูกแทนการศึกษาวิทยาการคอมพิวเตอร์แบบเป็นทางการ หลักการด้านสถาปัตยกรรมและคุณภาพโค้ดจึงคล้ายบาดแผลที่สั่งสมมากกว่ากฎในตำรา
- เครื่องมือ low-code/no-code ในยุค 2010s และผลิตภัณฑ์อย่าง Dreamweaver ก็เคยชูคำมั่นว่าจะสร้างบางอย่างได้โดยไม่ต้องเขียนโค้ด แต่สุดท้ายกลับสร้างสปาเกตตีโค้ดภายในและไม่อาจตอบความคาดหวังได้เต็มที่
- เครื่องมือ AI ปัจจุบันต่างจากอดีตตรงที่มัน ลดช่องว่างระหว่างคำสัญญากับความจริงลงได้อย่างมีนัยสำคัญ และนั่นเองที่ทำให้มันชวนกังวลยิ่งกว่าเดิม
ประสบการณ์จริงของคำว่า “โค้ดเขียนตัวเอง”
- โค้ดเขียนตัวเองได้ในระดับหนึ่ง แต่ประสบการณ์ของมนุษย์ที่ต้องตรวจสอบ สั่งการ และปรับทิศทางกลับแย่ลงได้
- Douwe ผู้ดูแล Pydantic AI ต้องตื่นเช้ามารีวิว PR ราว 30 รายการที่ AI ของคนอื่นสร้างไว้ข้ามคืน และต้องตัดสินแต่ละรายการทันที
- แม้จะล่อตาล่อใจให้โยนงานรีวิวให้ AI ด้วย แต่ก็ยังเหลือคำถามว่ามนุษย์กำลังทำอะไรอยู่กันแน่
- ต่อให้เขียนแผนให้ LLM ทำงานอยู่นานเกือบสองวันและคอยปรับให้ชัดซ้ำแล้วซ้ำอีก โมเดลก็ยังอาจย้าย React hook ไปไว้ในไฟล์ Storybook story หรืออ่านแผนผิดแล้วสร้างคอมโพเนนต์ที่ไม่มีอยู่จริงได้
- ความล้มเหลวแบบนี้ใกล้เคียงกับ การขาดความสม่ำเสมอ มากกว่าการขาดความสามารถ
- โมเดลฉลาดพอจะสร้างโค้ดที่ดูน่าเชื่อถือได้ แต่ไม่อาจรักษาเจตนาเดียวกันไว้ตลอดการเปลี่ยนแปลงที่ซับซ้อนทั้งหมด
- มนุษย์จึงต้องเก็บเจตนาไว้ในหัว พร้อมตัดสินผลลัพธ์จำนวนมากที่ ‘เกือบถูกต้อง’ อย่างต่อเนื่อง และกระบวนการนี้ก็ก่อให้เกิดความเหนื่อยล้าจากการกำกับดูแลรูปแบบใหม่
- แม้แต่รางวัลจากการสร้างฟีเจอร์ร่วมกับคนจริงในโอเพนซอร์สและการช่วยให้อีกฝ่ายพัฒนาความสามารถก็ลดลง
- เมื่องานถูกส่งเข้าไปในกล่องดำของ AI ก็ไม่มีคนอีกฝั่งที่ได้เรียนรู้ ทำให้ ความพึงพอใจจากการร่วมมือ หายไป
กับดักที่เพิ่มความเข้มข้นของงาน
- งานวิจัย Berkeley Haas ที่ Simon Willison นำมาเล่าชี้ว่า การใช้ AI ไม่ได้ลดภาระงาน แต่เพิ่ม ความเข้มข้นของงาน
- เมื่อใกล้จบวัน ก็ยังมีแรงกดดันให้พิมพ์พรอมป์ต์เพิ่มอีกครั้งหรือปิดงานฟีเจอร์อีกหนึ่งอย่าง
- ความรู้สึกว่าแผนเกือบเสร็จแล้วอาจทำให้เผลอพิมพ์พรอมป์ต์ไปจนเกือบตีสอง
- Marcelo จาก Pydantic ถึงกับล้อว่า ถ้า Claude Code session ค้างก็ให้เปิดอีก 5 session
- ความหมายคือ ถ้ายุ่งอยู่กับการให้ฟีดแบ็กกับ session อื่น คุณอาจไม่ทันสังเกตด้วยซ้ำว่าอีก session หนึ่งหยุดไปแล้ว
- งานที่เริ่มทำได้ด้วยการทำแบบขนานเพิ่มขึ้นมาก แต่จำนวนงานที่ปิดจบอย่างรอบคอบได้ไม่ได้เพิ่มตาม
- เพราะการทำให้เสร็จต้องใช้ สมองของมนุษย์ ซึ่งเป็นทรัพยากรที่ขนานไม่ได้
ความผิดพลาดของฟังก์ชันรางวัลของมนุษย์
- เช่นเดียวกับที่ฟังก์ชันรางวัลในแมชชีนเลิร์นนิงนิยามผลลัพธ์ที่ดีให้ agent การเขียนโค้ดด้วยมือก็เคยมีรางวัลเล็กๆ อย่างการแก้ปัญหา การเข้าใจตรรกะซับซ้อน การคอมไพล์ผ่าน และความรู้สึกควบคุมได้
- การเขียนโปรแกรมแบบมี LLM ช่วยได้ทำให้งานที่เคยสร้างรางวัลแบบโดพามีนเหล่านี้ถูกทำให้อัตโนมัติ และแทนที่ด้วย ภาระทางความคิด ของการรีวิวและกำกับดูแล
- ส่วนที่น่าพึงพอใจลดลง
- ส่วนที่สิ้นเปลืองเพิ่มขึ้น
- และยังไม่มีรางวัลรูปแบบใหม่มาทดแทนช่องว่างนี้
- ปรากฏการณ์ที่ผลิตภาพสูงขึ้นแต่ความพึงพอใจลดลงไม่ใช่ความบกพร่องส่วนบุคคล แต่คือ ฟีดแบ็กลูปที่เสียหาย ซึ่งควรถูกมองเป็นปัญหาทางวิศวกรรมอีกข้อหนึ่ง
ความโดดเดี่ยวและรางวัลแบบแปรผัน
- การเขียนโปรแกรมด้วย LLM อาจกลายเป็นกิจกรรมที่โดดเดี่ยวมาก ระหว่างมนุษย์กับเครื่องที่วนซ้ำอยู่กับการพรอมป์ต์ แก้ไข และรีวิว
- ช่วงเวลาที่เคยถามเพื่อนร่วมงาน พูดปัญหาออกมาด้วยกัน และแบ่งปันความยินดีเล็กๆ จากการแก้โจทย์ ถูกแทนที่ด้วยพรอมป์ต์อีกหนึ่งอัน
- ในทีมที่วัฒนธรรมการทำงานร่วมกันเดิมก็ไม่แข็งแรงอยู่แล้ว การสื่อสารระหว่างคนยิ่งหดตัวลง และยิ่งยากที่จะรู้ว่าคนอื่นก็ลำบากเหมือนกัน
- การที่ผลลัพธ์บางครั้งยอดเยี่ยม บางครั้งแย่มาก แต่ไม่อาจรู้ล่วงหน้าได้ สร้าง โครงสร้างรางวัลแบบแปรผัน คล้าย Skinner Box
- แม้จะเลือกเขียนโค้ดเองเมื่อจำเป็นได้ แต่การทำงานแบบมี LLM ช่วยกับการเขียนด้วยมือนั้นใช้กรอบความคิดต่างกันมาก ทำให้สลับไปมาลำบาก
- การอนุญาตให้ตัวเองสลับระหว่างสองวิธีนี้ได้ต้องอาศัยความเป็นผู้ใหญ่และความมั่นใจ
ความคล้ายกับการเปลี่ยนผ่านสู่ responsive design
- ราวปี 2009 ตอนที่เว็บเปลี่ยนจากเลย์เอาต์พิกเซลคงที่ไปสู่ responsive design ที่ยืดหยุ่น นักออกแบบก็เคยเผชิญความรู้สึกสูญเสียการควบคุม
- สำหรับคนที่สร้างอัตลักษณ์และความเชี่ยวชาญบนเลย์เอาต์ที่แม่นยำและกริดที่สมบูรณ์แบบ แนวคิดที่ดีไซน์ต้องไหลไปตามความกว้างหน้าจอและอุปกรณ์ที่คาดเดาไม่ได้ถือเป็นการเปลี่ยนแปลงระดับรากฐาน
- นักออกแบบที่ปรับตัวกับการเปลี่ยนผ่านนี้ได้ไม่ได้ทิ้งทักษะเดิม แต่จัดระเบียบมันใหม่
- ความรู้สึกเรื่องสัดส่วนและความเข้าใจลำดับชั้นยังสำคัญอยู่
- ความยึดติดกับการควบคุมระดับพิกเซลสำคัญน้อยลง
- การออกแบบเพื่อระบบ การปรับตัว และความไม่แน่นอนสำคัญยิ่งขึ้น
- การเปลี่ยนผ่านด้าน AI ในตอนนี้เกิดขึ้นเร็วกว่ามากและมีเดิมพันต่างออกไปเมื่อเทียบกับ responsive design
- การเปลี่ยนของ responsive design ใช้เวลาหลายปี แต่การเปลี่ยนในตอนนี้เกิดในระดับ ไม่กี่เดือน
- แม้ตอนนั้นเอเจนซีจะสูญเสียลูกค้าและนักออกแบบจะสูญเสียงาน แต่ก็ไม่ได้มาพร้อมความกังวลเชิงอัตถิภาวนิยมแบบในปัจจุบัน
- ถึงกระนั้น รูปแบบที่เทคโนโลยีไม่ได้หายไปแต่พัฒนา และทำให้ทักษะแกนกลางสำคัญขึ้น ก็ยังใช้ได้กับการเขียนโค้ดบนฐาน LLM
- ต่อให้ไม่ได้เขียนโค้ดทุกบรรทัดด้วยตัวเอง คุณค่าของวิศวกรก็ไม่ได้ลดลง แต่เมื่อกลายเป็น ด่านคุณภาพ ของผลลัพธ์จำนวนมหาศาล ความสามารถในการแยกแยะสิ่งที่ดีจึงสำคัญกว่าเดิม
ความเชี่ยวชาญที่อยู่รอดและวิธีทำงานแบบใหม่
- ในสภาพแวดล้อมที่ใครๆ ก็สร้าง UI ที่ดูน่าเชื่อถือและโค้ดที่คอมไพล์ผ่านได้ รสนิยมและความละเอียดอ่อน การตัดสินใจด้านสถาปัตยกรรมที่เป็นผู้ใหญ่ และการตัดสินใจนอกกระแสที่ตั้งอยู่บนความเชี่ยวชาญจริง จะกลายเป็นจุดต่าง
- ยิ่งเป็นโดเมนที่เข้าใจโค้ด การตัดสินใจ และ trade-off อย่างลึกซึ้ง ก็ยิ่งชี้นำ LLM ให้สำเร็จได้ดี
- ยิ่งเข้าไปในโดเมนที่ความเชี่ยวชาญตื้น ผลลัพธ์ก็ยิ่งห่างจากความพร้อมระดับโปรดักชัน และใกล้กับความน่าประทับใจแบบดูน่าเชื่อถือมากกว่าความถูกต้องจริง
- โมเดลไม่รู้ว่าตัวเองไม่รู้อะไร และเติมช่องว่างด้วยความมั่นใจ ซึ่งเป็นรูปแบบความล้มเหลวที่มนุษย์ก็มีเช่นกัน
- สำหรับแผนที่ซับซ้อน สามารถใช้ pre-mortem ได้
- ให้ LLM session ใหม่สมมติว่าแผนนั้นล้มเหลวอย่างย่อยยับไปแล้ว จากนั้นขอให้วิเคราะห์สาเหตุ
- วิธีนี้ช่วยหาช่องโหว่ในสเปกที่คนซึ่งจมอยู่กับรายละเอียดมาสองวันอาจมองไม่เห็น
- วิศวกรคนหนึ่งของ Pydantic พัฒนาเครื่องมือที่ดึงกฎจากคอมเมนต์รีวิวโค้ดนับพันในอดีต แล้วแปลงเป็นคำสั่งตั้งต้นในไฟล์
AGENTS.md- นี่คือ การกลั่นความเชี่ยวชาญ ที่สั่งสมอย่างเงียบๆ มาหลายปีให้กลายเป็นแนวทางที่ LLM ทำตามได้
- คนที่ปรับตัวกับการเปลี่ยนแปลงได้มักมีเกณฑ์การตัดสินที่แข็งแรงจากประสบการณ์จริง และแยกได้ว่าอะไรคือหลักการที่ยังใช้ได้ กับอะไรคือเพียงนิสัยที่เกิดจากข้อจำกัดด้านแบนด์วิดท์ในอดีต
- คนกลุ่มนี้ไม่ทิ้งมาตรฐานของตัวเอง แต่ก็พร้อมเปลี่ยน workflow
ทรัพยากรที่หายากซึ่งเผยให้เห็นในลูป
- กระแส AI ปัจจุบันอาจไม่ทำให้อาชีพซอฟต์แวร์วิศวกรรมสิ้นสุดลง แต่สามารถนำไปสู่ การหดตัวอย่างรุนแรงและการปรับโครงสร้างครั้งใหญ่ ของอุตสาหกรรมได้
- ความกลัวว่าจะถูกคัดออก ทักษะเสื่อมถอย หรือถูกทิ้งไว้ข้างหลังหากเคลื่อนไหวไม่เร็วพอ เป็นความกลัวที่มีเหตุผล
- ข้อกังวลสุดท้ายอาจถูกพูดเกินจริงบ้าง แต่ก็ไม่ได้ไร้มูลเสียทีเดียว
- คอขวดที่แท้จริงไม่ใช่โค้ด แต่คือความใส่ใจของมนุษย์ การตัดสินใจเชิงวิศวกรรม และความสามารถในการรักษาวิสัยทัศน์ที่สอดคล้องกันของระบบ
- เดิมทีคอขวดนี้ไม่เด่นชัดเพราะการเขียนโค้ดเองให้ความรู้สึกว่าเป็นส่วนที่ยาก แต่เมื่อกระบวนการเขียนถูกทำให้อัตโนมัติ ก็ยิ่งเห็นชัดว่าความสามารถของมนุษย์ต่างหากคือ ทรัพยากรที่หายาก จริงๆ
- นักพัฒนาอาจมีผลิตภาพสูงขึ้นแต่มีความสุขน้อยลงและเปราะบางขึ้น ขณะที่ทีมผู้สร้างเครื่องมือเองก็เผชิญปัญหาเดียวกันและกำลังปรับฟังก์ชันรางวัลกันแบบเรียลไทม์
- แม้โค้ดและวิธีพัฒนาจะเปลี่ยนไป แต่มนุษย์ก็ยังอยู่ในลูป และสภาวะสำคัญในตอนนี้คือ ความเหนื่อยล้าของผู้มีส่วนร่วมที่เป็นมนุษย์
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ยิ่งการเขียนโค้ดด้วยมือยากขึ้น รางวัลเล็ก ๆ อย่างการแก้ปัญหา การเข้าใจตรรกะ การคอมไพล์สำเร็จ และความรู้สึกว่าควบคุมได้ก็ยิ่งมีความหมายมากขึ้น ในทางกลับกัน การเขียนโค้ดด้วยเอเจนต์ ต้องการการกำกับดูแลคล้าย ๆ กันอยู่ตลอดไม่ว่าฟีเจอร์จะมีขนาดเท่าใด ตอนแรกจึงรู้สึกตื่นเต้นเหมือนได้โต้คลื่นแห่งผลิตภาพ แต่ส่วนที่ให้ความพึงพอใจกลับลดลง ภาระทางความคิดในการตรวจทานเพิ่มขึ้น และเหนื่อยล้าอย่างรวดเร็ว
ใช้ Claude อย่างสนุกทั้งในงานและโปรเจกต์ส่วนตัว โดยหัวใจคือ หลีกเลี่ยงสิ่งยั่วยวนของเอเจนต์ และปฏิบัติกับมันเหมือนตัวสร้างโค้ด เปิดเซสชันเดียว ขัดเกลาแผนให้มากพอก่อน จากนั้นคอยดูการลงมือทำทีละขั้น และเมื่อแต่ละขั้นจบก็ตรวจทานและปรับทิศทาง ทำให้ตอนท้ายยังเข้าใจสถานะของโค้ดได้ดี
หากจะใช้ให้ใกล้เคียง one-shot ต้องทำให้ชัดเจนตั้งแต่ขั้นวางแผน ไม่ใช่แค่สถาปัตยกรรม แต่รวมถึงโค้ดจริงที่จะมีผลต่อการตัดสินใจสำคัญด้วย ตอนนี้ต้นทุนการรีแฟกเตอร์ต่ำกว่าที่เคย ส่วนไหนเข้าใจยากก็ควรแก้กับ LLM ทันที แต่ต้องให้ LLM หนึ่งตัวทำงานหนึ่งอย่างต่อครั้ง และต้องมีส่วนร่วมกับกระบวนการอยู่ตลอด
หากให้อำนาจเต็มกับ Claude ความสับสนและอุปสรรคที่เกิดขึ้นอย่างหลีกเลี่ยงไม่ได้จะทำให้คนหมดแรง แต่ถ้าอยากโค้ดเองก็ทำเอง และเมื่อเหนื่อยค่อยส่งต่อให้ Claude ก็ยังรักษา ความรู้สึกควบคุม codebase ได้
เวลาตรวจโค้ดของเพื่อนร่วมงานหรือลูกน้อง ต้องใช้พลังใจส่วนใหญ่ไปกับการคำนึงถึงไม่เพียงความถูกต้องทางเทคนิคของฟีดแบ็ก แต่ยังรวมถึงอีโก้ ความต่างของมุมมองด้านสถาปัตยกรรม น้ำเสียงที่สุภาพ ปริมาณงานที่เพิ่มขึ้น และพลวัตของทีม ในทางกลับกัน LLM ไม่ต้องกังวลเรื่องผลกระทบทางอารมณ์ ทำให้การตรวจทานและปรับทิศทางง่ายกว่ามาก
ที่ทำงานเริ่มเรียกแทน human in the loop ว่า Human on the hook สื่อนัยได้แม่นยำกว่าว่าเป็นโครงสร้างที่ถ้าทำได้ดีก็ไม่ได้เครดิต แต่ถ้าผิดพลาดก็กลายเป็นผู้รับผิดชอบ กล่าวคือมนุษย์สำคัญขึ้นมาเฉพาะตอนเกิดปัญหาเท่านั้น
การเขียนโค้ดเองไม่เคยเป็นส่วนที่ยากสำหรับผมเลย ผมพิมพ์เร็ว ใช้การแก้ไขแบบ modal ของ Vim, คำสั่ง Unix, สคริปต์กับคีย์ลัด, Git, การรีแฟกเตอร์ใน IDE และ Java จนเมื่อรู้ว่าจะสร้างอะไร ก็ทำงานได้เร็วเท่าความคิด
จังหวะที่หยุดไม่ใช่เพราะการพิมพ์หรือไวยากรณ์ แต่เป็นตอนคิดถึงรูปแบบของโค้ดและการเปลี่ยนแปลงที่ถูกต้อง และเมื่อยากขึ้นก็สร้าง abstraction ที่ดีกว่า เครื่องมือ IDE หรือ Unix pipeline รวมถึง
sedดังนั้น คอขวดไม่ใช่การเขียนโค้ด แต่เป็นการคิดและการตัดสินเหตุผลที่ AI coding รู้สึกเหมือนก้าวกระโดดใหญ่ อาจเป็นเพราะมีนักพัฒนามากกว่าที่คิดที่ไม่เคยเจอหรือไม่เชี่ยวชาญเครื่องมือดี ๆ ถ้าตอนนี้ผมอายุ 20 กว่า ๆ ก็คงใช้เวลาน้อยลงกับการฝึกทักษะเหล่านี้ แต่ช่วงเวลาที่วิศวกรรมซอฟต์แวร์ดึงดูดใจผมที่สุด คือเมื่อเข้าใจว่าไม่มีสิ่งใดในนั้นเป็นเวทมนตร์เลย
เหมือนที่ผมไม่ถนัดวาดรูปแล้วภาพจาก AI ดูสุดยอด การประเมิน AI programming ก็อาจเป็นหลักการเดียวกัน
ความเหนื่อยล้าที่หลายคนรู้สึกเกิดจาก การสูญเสียการควบคุม ซึ่งเป็นผลรวมของแรงขับเคลื่อนที่เร็วขึ้นกับความสับสนที่ใหญ่ขึ้น LLM อยู่กึ่งกลางระหว่างอัจฉริยะกับเด็กเล็ก การนั่งดูจากเบาะหลังจึงทั้งเร้าใจและน่ากลัว
หลังจากวิ่งเร็วอยู่พักหนึ่ง คงจะได้ตระหนักว่าการเดินก็ไม่ได้แย่ และกลับมีโอกาสไปถึงจุดหมายที่ต้องการมากกว่าเสียอีก
การเขียนโค้ดด้วย LLM ให้ความรู้สึกเหมือนทำพิธีซ้ำ ๆ ราวกับดึง คันโยกสล็อตแมชชีน แล้วหวังว่าครั้งนี้จะสำเร็จ ข้อผิดพลาดในการเขียนโปรแกรมทั่วไปมีสาเหตุที่สอดคล้องกัน และถูกออกแบบมาให้เราเข้าใจสาเหตุนั้นแล้วกำจัดออกไปอย่างถาวรหากเป็นไปได้ นักพัฒนาที่มีประสบการณ์จะไม่ลองสุ่ม ๆ แล้วเมื่อสำเร็จก็ปัดทิ้งว่าเป็นเรื่องที่ไม่รู้เหตุผล
หากคุณเหนื่อยล้าอยู่แล้วจากการต้องรับมือกับผู้มีส่วนได้ส่วนเสียหลายฝ่ายที่แม้แต่คำว่าระบบคืออะไรก็ยังตกลงกันไม่ได้ คุณก็อาจรู้อยู่ก่อนแล้วว่า ความใส่ใจของมนุษย์และวิจารณญาณทางวิศวกรรมต่างหากที่เป็นคอขวดมาตั้งแต่แรก
การเขียนโค้ดด้วย Claude ให้ความรู้สึกเหมือนย้อนกลับไปสู่ขั้นตอนการเดานั้น จึงไม่ใช่สิ่งที่ผมต้องการ อย่างไรก็ตาม ในงานแนว DevOps เช่นการเชื่อมต่อ API ที่ซับซ้อนกับองค์ประกอบหลายส่วน ซึ่งเดิมทีก็มีการเดาแบบมืดบอดมากอยู่แล้ว บทสนทนากับ LLM กลับมีประโยชน์ที่สุด
แผนสามารถเปลี่ยนได้ทุกเมื่อ และโอกาสที่จะถูกเขียนใหม่ทั้งหมดแบบหุนหันพลันแล่นก็ยิ่งสูงขึ้น
ผมเห็นด้วยกับแก่นของบทความ แต่หลายจุดมีกลิ่นอาย สำนวนเฉพาะของ Claude ติดอยู่ ทำให้การอ่านงานที่ใครสักคนใช้ AI เขียนยิ่งเหนื่อยกว่าเดิม
นึกถึงบทความปี 2021 เรื่อง The Animal is Tired: https://www.robinhobb.com/blog/archives/2021-05
ต่อให้ถนอมร่างกายมากกว่านี้ สุดท้ายก็อาจมาถึงจุดเดียวกันอยู่ดี ขณะเดียวกันก็อาจพลาดความทรงจำล้ำค่าไป จงดูแลร่างกาย แต่อย่าปฏิบัติต่อมันเหมือน โพชันในเกม ที่ไม่กล้าใช้จนหมดเพราะกลัวว่าจะต้องใช้ในการต่อสู้ครั้งถัดไป ส่วนต่าง ๆ ของร่างกายเรามีเพียงแค่อาจถูกสละหนึ่งครั้งเพื่อเป้าหมายที่ใหญ่กว่า หรือไม่ถูกสละเลยเท่านั้น
แค่คิดเรื่องแบบนี้ก็ยังร้องไห้ได้ แสดงว่ายังอยู่ท่ามกลางวิกฤตทางอารมณ์
ข่าวประชาสัมพันธ์งานวิจัย ของ Berkeley Haas ที่บอกว่าการใช้ AI ทำให้ความเข้มข้นของงานสูงขึ้นนั้นน่าสนใจ แต่ผ่านมาเกิน 5 เดือนแล้วนับจากบทความใน HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... และข่าวประชาสัมพันธ์ https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... ก็ยังหาบทความวิจัยจริงหรือฉบับเผยแพร่ล่วงหน้าไม่เจอ
สิ่งที่รู้ในตอนนี้มีเพียงว่าเป็น การสัมภาษณ์เชิงคุณภาพ ประมาณ 40 ครั้งในบริษัทหนึ่งของอุตสาหกรรมเดียวเท่านั้น จึงยากที่จะประเมินความน่าเชื่อถือของผลลัพธ์โดยไม่เห็นวิธีวิจัย