วิกฤตอัตลักษณ์ของโปรแกรมเมอร์
(hojberg.xyz)- อัตลักษณ์ของโปรแกรมเมอร์ กำลังถูก คุกคาม จากการมาถึงของ AI และเครื่องมือ LLM ในช่วงหลัง
- วัฒนธรรมการเขียนโปรแกรม เริ่มต้นจากจริยธรรมแฮกเกอร์ของ MIT ในทศวรรษ 1950 และยกให้ การเขียนโค้ดนั้นเอง เป็นงานเชิงช่างฝีมือ (craft) ที่ลุ่มลึก โดยมีตรรกะที่แม่นยำและการดื่มด่ำกับการแก้ปัญหาเป็นคุณค่าหลัก
- แต่ในปัจจุบัน อุตสาหกรรม AI และเครื่องมือ LLM กำลังพยายามเปลี่ยนนักพัฒนาให้เป็นเพียง ผู้เขียนสเปกหรือโอเปอเรเตอร์ และบีบให้ใช้แนวทาง "vibe-coding" ที่สั่งงานด้วยภาษาธรรมชาติแทนการเขียนโค้ดด้วยตนเอง
- โค้ดที่ LLM สร้างขึ้นนั้น ไม่เป็นเชิงกำหนดและไม่แม่นยำ และยังตัดทอน ความเข้าใจเชิงลึกและภาวะจดจ่อ ที่นักพัฒนาได้จากกระบวนการอ่านและเขียนโค้ดด้วยตนเอง ทำให้ความเชื่อมโยงกับ codebase ขาดหายไป
- บริษัทต่าง ๆ ใช้ข้ออ้างเรื่องการเพิ่มผลิตภาพเพื่อ บังคับใช้เครื่องมือ และแทนที่วัฒนธรรมการทำงานร่วมกันกับการมีพี่เลี้ยงในทีมด้วยการโต้ตอบกับ AI จนทำให้ ความเชื่อมโยงระหว่างมนุษย์ ในหมู่นักพัฒนาอ่อนแอลง
- คุณค่าพื้นฐานที่มองการเขียนโปรแกรมไม่ใช่แค่ผลลัพธ์ แต่เป็น กระบวนการคิดและความเข้าใจ กำลังสูญหายไป และนักพัฒนาจำเป็นต้องต่อต้านการเปลี่ยนแปลงนี้เพื่อปกป้องทักษะ ความสุข และอัตลักษณ์ทางอาชีพของตน
แก่นแท้และธรรมเนียมของโปรแกรมเมอร์
-
การเขียนโค้ด ไม่ใช่แค่งานธรรมดา แต่เป็นตัวตนของนักพัฒนาเอง โดย editor คือทั้งสถานที่ทำงานและพื้นที่ศักดิ์สิทธิ์สำหรับฝึกฝนทักษะและเข้าสู่ภาวะลื่นไหล (flow)
- ผ่านเครื่องมืออย่าง Vim นักพัฒนาสามารถทำงานโดยแทบไม่มีสิ่งกีดขวางระหว่างความคิดกับโค้ด และสร้างโลกที่ไร้รูปธรรมซึ่งส่งผลต่อโลกจริง
- กระบวนการแก้ปริศนาสำคัญกว่าภาพที่เสร็จสมบูรณ์ และเวลาเหมือนหายไปท่ามกลางกระแสทักษะที่ไหลจากปลายนิ้วสู่บัฟเฟอร์
-
ในช่วงปลายทศวรรษ 1950 ที่ MIT ได้เกิด วัฒนธรรมการเขียนโปรแกรมรูปแบบใหม่ ขึ้น เมื่อเหล่าแฮกเกอร์ผู้มีแนวคิดทดลองและต่อต้านขนบใช้ Flexowriter และคอมพิวเตอร์ TX-0 เพื่อแสวงหาโปรแกรมที่สมบูรณ์แบบ
- พวกเขายึดแนวคิด "The Right Thing" เป็นศูนย์กลาง และตั้งเป้าจะเขียนโค้ดที่สง่างามและกระชับ
- สมาชิกของ Tech Model Railroad Club หมกมุ่นกับภาษาเครื่อง ฝึกฝนเวทมนตร์ดิจิทัล และสร้างวัฒนธรรมการแบ่งปันความรู้ที่ค้นพบให้แก่นักศึกษาคนอื่น
-
ใน เบ้าหลอมแห่งการคอมพิวต์ ของ Building 26 ทักษะการเขียนโค้ดได้รับการขัดเกลา และวัฒนธรรมที่ก่อตัวขึ้นเมื่อราว 70 ปีก่อนนี้ก็ยังสืบทอดมาจนถึงปัจจุบัน ยังคงอยู่ทั้งในหัวใจของนักพัฒนาและในเครื่องจักร
- มรดกของแฮกเกอร์ยุคบุกเบิกยังคงอยู่ในฐานะทักษะอันลึกซึ้งและมีมิติทางกายภาพ และได้กลายเป็นรากฐานของอุตสาหกรรมที่ขับเคลื่อนด้วยความหลงใหล
- นักพัฒนายังคงได้รับแรงผลักดันจากความอัศจรรย์ ความภูมิใจในความสำเร็จ และความงามของการแก้ปริศนาเช่นเดิม
-
แต่ คุณค่าหลัก เหล่านี้ที่ประกอบขึ้นเป็นอัตลักษณ์ของโปรแกรมเมอร์กำลังถูกคุกคาม และอนาคตของการเขียนโปรแกรมที่เคยดูสดใสและชัดเจน บัดนี้กลับถูกปกคลุมด้วยความมืดมน การลวงตา และความไม่แน่นอน
การยัดเยียดอัตลักษณ์ใหม่จากอุตสาหกรรม AI
-
อุตสาหกรรม AI มูลค่าหลายพันล้านดอลลาร์ ชุมชน Hacker News และผู้สนับสนุน LLM บน LinkedIn ต่างอ้างว่า อนาคตของการพัฒนาซอฟต์แวร์แทบไม่เหมือนการเขียนโปรแกรมอีกต่อไป และสิ่งที่เมื่อปีก่อนยังดูเหมือนมีมอย่าง "vibe-coding" ก็กำลังกลายเป็นกระแสหลัก
- นักพัฒนาจะต้อง เขียนสเปกด้วย Markdown แทนโค้ด ขณะที่ความดื่มด่ำเชิงลึกและความลุ่มลึกของทักษะจากการสำรวจทุกซอกมุมของ codebase การแก้ปริศนา และการค้นพบความลับต่าง ๆ กำลังหายไป
- แทนที่จะคิดด้วยตนเอง นักพัฒนากลับต้องยอมรับการรับรู้ที่แตกกระจายและการสลับบริบทอยู่ตลอด ขณะที่ เอเจนต์เป็นฝ่ายคิดแทน การแก้ปัญหาอย่างสร้างสรรค์จึงถูกยกให้เครื่องจักร ส่วนนักพัฒนากลายเป็นเพียงโอเปอเรเตอร์
-
นักพัฒนาบางส่วนกลับต้อนรับการเปลี่ยนแปลงนี้และ อัตลักษณ์ใหม่ที่เรียกว่า "Specification Engineering" พร้อมตื่นเต้นกับการได้เป็นโอเปอเรเตอร์ที่เหมือน Steve Jobs ในบทบาท "วาทยกรของวงออร์เคสตรา"
- จึงน่าตั้งคำถามว่าหากดูเหมือนไม่ได้สนใจการเขียนโค้ดเลย แล้วเหตุใดถึงมาเป็นโปรแกรมเมอร์ หรืออาจกำลังสับสนระหว่าง Woz กับ Jobs กันแน่
- Prompt, Context, Specification "Engineering" ดูไม่ใช่เส้นทางที่จะมอบอาชีพที่รุ่งเรืองและสดใสให้โปรแกรมเมอร์ได้
-
สิ่งนี้หมายถึง การลดคุณค่าของทักษะ ความชำนาญ และแรงงาน โดยย้ายความสามารถเฉพาะของนักพัฒนาในการคิดเชิงนามธรรมออกไปสู่พื้นที่ที่ไม่ต้องการมันอีกแล้ว และเข้าสู่พื้นที่ที่ผู้จัดการผลิตภัณฑ์กับนักออกแบบยืนอยู่ก่อนแล้ว
การเปลี่ยนแปลงของพลวัตอำนาจในองค์กร
-
เมื่ออัตลักษณ์ใหม่นี้ถูกยัดเยียดในองค์กร พลวัตของอำนาจก็เปลี่ยนตามไปด้วย และด้วยความพยายามคลั่งไคล้ที่จะเพิ่มผลิตภาพในจุดที่ผิด นักพัฒนาจึงถูกบังคับให้ใช้ LLM ในรูปแบบที่เฉพาะเจาะจงมากขึ้นเรื่อย ๆ
- ถ้าไม่ยอมทำตาม ก็อาจถูกเขี่ยออกไป และต้องเลือกระหว่างใช้ผลิตภัณฑ์ที่ประกาศกลาย ๆ ว่าตนเองไร้ประโยชน์ หรือไม่ก็ลาออก
- ในอดีตแทบไม่เคยมีกรณีที่ฝ่ายบริหารจะสั่งการเรื่องเครื่องมือของนักพัฒนาอย่างละเอียดถึงเพียงนี้
-
นักพัฒนามักภาคภูมิใจอย่างมากในการ คัดสรรและขัดเกลาเครื่องมือ ของตนเอง ไม่ต่างจากเชฟหรือช่างไม้ และได้ปรับแต่งเครื่องมือให้สอดคล้องกับวิธีคิดของตนผ่านการตั้งค่า editor อย่างพิถีพิถัน การปรับ dotfile และการจัดสภาพแวดล้อมการพัฒนา
- พวกเขาทุ่มเทให้กับการปรับแต่งชุดเครื่องมือในฐานะส่วนหนึ่งของทักษะ แต่เมื่อผู้บริหารที่แทบไม่เกี่ยวข้องกับงานประจำวันกลับมาสั่งเรื่องนี้โดยตรง มันจึงให้ความรู้สึกเหมือนการล่วงล้ำ
- สำหรับโปรแกรมเมอร์ที่เคยได้รับอภิสิทธิ์ในองค์กรมาเป็นเวลาหลายทศวรรษ เรื่องเล่านี้จึงเปิดทางให้ผู้บริหารมีวิธีใหม่ในการดึงดุลอำนาจกลับเข้าหาตนเอง
ความต่างเชิงแก่นแท้ระหว่าง LLM กับภาษาโปรแกรม
-
บางคนเปรียบผลกระทบของ LLM กับ การเปลี่ยนผ่านจากภาษาระดับต่ำไปสู่ภาษาระดับสูง (จาก Assembly ไป Fortran) แต่การเปรียบเทียบนี้ผิดพลาดในหลายด้าน
- Fortran มีรากฐานอยู่บนการเขียนโปรแกรม ไม่ได้พยายามลบทักษะนั้นทิ้ง แต่ต่อยอดจากมัน และขยายความแม่นยำกับพลังในการแสดงออกของการเขียนโปรแกรม แทนที่จะลดทอนมัน
- Fortran สามารถสร้างผลลัพธ์ที่ถูกต้องจากอินพุตได้อย่างสม่ำเสมอ แต่ในโลกของ LLM ไม่มีข้อใดในนี้ที่เป็นจริง
-
คอมพิวเตอร์และการเขียนโปรแกรมอาจชวนให้หงุดหงิดอย่างมาก แต่เราอย่างน้อยก็ เชื่อถือความแม่นยำได้เสมอ และผ่านการเขียนโปรแกรม มันจะทำงานตามที่สั่งไว้อย่างถูกต้อง
- เพราะเราพึ่งพาและเชื่อมั่นในความแม่นยำของคอมพิวเตอร์ จึงง่ายที่จะหลงเชื่อเมื่อแชตบอต gaslight ว่ามันได้ทำงานที่ร้องขอเรียบร้อยแล้ว
-
LLM และวิธีการทำงานของมันนั้น ไม่แม่นยำโดยเนื้อแท้ ทั้งจากคุณสมบัติของโมเดลภาษาขนาดใหญ่เองและจากลักษณะการสั่งงานด้วยภาษาธรรมชาติที่เปิดช่องให้ตีความผิดได้
- น่าสนใจที่โปรแกรมเมอร์ซึ่งมักไม่ชอบความไม่เป็นเชิงกำหนดกลับเลือกแนวทางนี้ ทั้งที่โดยปกติชื่นชอบความคาดเดาได้ composability idempotence และการทดสอบ integration ที่ไม่เปราะบาง
- แต่โค้ดจาก LLM กลับเป็นตรงกันข้าม คือ ความโกลาหลที่ไม่สม่ำเสมอ
-
Dijkstra เคยชี้ไว้ใน "On the foolishness of natural language programming" ว่าควรตั้งคำถามกับสมมติฐานที่ว่าภาษาธรรมชาติจะทำให้งานง่ายขึ้น และเน้นว่าข้อดีของข้อความเชิงรูปแบบคือการจะถูกต้องตามกฎนั้น เพียงแค่ต้องผ่านกติกาง่าย ๆ ไม่กี่ข้อ
การสูญเสียความเข้าใจเชิงลึกและภาวะจดจ่อ
-
แม้จะมีความพยายามแยกการพัฒนาที่มี AI ช่วยออกจาก vibe-coding ด้วยความเข้มงวดและระบบราชการ แต่นั่นกลับ มองข้ามแก่นของปัญหา
- เมื่อเป็นโค้ดที่ LLM สร้างขึ้น เรามักไม่ได้อ่านอย่างละเอียดเท่ากับตอนที่เขียนเองหรือรีวิวใน PR และมีบางอย่างใน LLM coding ที่ทำให้สายตาพร่าและจิตใจล่องลอย
- เรามักแค่กวาดตาผ่าน รู้สึกท่วมท้นและเบื่อหน่าย และเมื่อ CI ผ่านกับโปรแกรมคอมไพล์ได้ ก็ยอมรับกับดักอันตรายเหล่านั้นอย่างมืดบอด
- ไม่ได้ตรวจด้วยซ้ำว่ามีการตั้งให้รันทดสอบหรือไม่ มีการ import ไลบรารีที่ไม่มีอยู่จริงหรือเปล่า หรือมันได้ลงมือเขียนไลบรารีทั้งก้อนขึ้นมาเองหรือไม่
-
รีวิวหรือสรุปหนังสือไม่อาจแทนประสบการณ์ของการอ่านด้วยตนเองได้ เพราะการค่อย ๆ อ่านแต่ละประโยคอย่างใส่ใจตลอดหลายร้อยหน้าและครุ่นคิดกับแนวคิดต่าง ๆ เป็นสิ่งจำเป็น
- เช่นเดียวกัน การกวาดตาอ่านสรุปงานที่ AI ทำเสร็จแล้ว ย่อมพราก ความเข้าใจเชิงลึกเกี่ยวกับโดเมน ปัญหา และทางออกที่เป็นไปได้ และตัดขาดความเชื่อมโยงกับ codebase
- การกระโจนลงสู่ห้วงลึกของความไม่รู้เพื่อเปิดเผยหัวข้อ ผลกระทบของมัน เรียนรู้ และทำความเข้าใจ เป็นทั้งสิ่งน่าพึงพอใจและจำเป็นต่อซอฟต์แวร์ที่ดี
- ความเป็นเจ้าของ ความเป็นผู้กระทำการ และงานลึกที่ให้ความพึงพอใจ ถูกแทนที่ด้วยความสนใจที่แตกกระจัดกระจายระหว่างแท็บของเอเจนต์
-
Joan Didion เคยกล่าวว่า "ฉันเขียนเพื่อค้นหาว่าฉันกำลังคิดอะไรอยู่ ฉันกำลังมองอะไรอยู่ และสิ่งที่ฉันมองเห็นนั้นหมายความว่าอะไร" ขณะที่ Peter Naur ได้สำรวจแนวคิดเดียวกันใน "Programming as Theory Building"
- "Theory" ของ Naur คือการทำให้ความเข้าใจใน codebase ปรากฏเป็นรูปธรรม ครอบคลุมทั้งวิธีการทำงาน รูปแบบเชิงทฤษฎี และการแทนโลกจริง
- บริบทและความเข้าใจลึกซึ้งเช่นนี้เกิดขึ้นได้ผ่านการดื่มด่ำเท่านั้น และ Naur อธิบายว่า "Theory" คือผลผลิตหลักและตัวผลิตภัณฑ์ที่แท้จริงของการเขียนโปรแกรม ยิ่งกว่าตัวซอฟต์แวร์เอง
- ต้องมี "Theory" ที่พัฒนาอย่างดีเสียก่อน จึงจะสามารถขยายและแก้บั๊กใน codebase ได้อย่างมีประสิทธิภาพ
-
การออกแบบที่ดีนั้น เกิดจากการดื่มด่ำ และเผยตัวผ่านการทำงานไปมาบน text buffer รวมถึงในช่วงเวลาที่มักอยู่ห่างจากคีย์บอร์ด
- เพราะเราไม่อาจเก็บ codebase ทั้งหมดไว้ในหัวได้ จึงต้องกระโดดเข้าออกระหว่างโมดูล คลาส และฟังก์ชัน เพื่อทำให้แบบจำลองทางความคิดที่พร่าเลือนชัดเจนขึ้น
- เราต้องอ่านและเขียนโค้ดเพื่อขยายการรับรู้ และฟื้นคืนความคุ้นเคยกับความเข้าใจในโดเมนของปัญหา
-
เมื่อบริบทบางส่วนก่อตัวขึ้น เราอาจค้นพบวิธีแก้ได้ในท้ายที่สุดผ่านความพยายามที่ไม่สมบูรณ์มากมาย และเราจำเป็นต้อง รู้สึกถึงความไม่ประสานของการออกแบบที่แย่
- ก็เพราะได้เขียนโค้ดที่น่าเกลียดและซ้ำซากนั่นเอง เราจึงตระหนักว่ามีวิธีที่ดีกว่า กระชับกว่า สง่างามกว่า ประกอบต่อได้ และนำกลับใช้ซ้ำได้
- มันทำให้เราหยุดเพื่อคิดอย่างลึกซึ้งเกี่ยวกับปัญหา ถอยออกมาหนึ่งก้าว และเริ่มต้นใหม่ตั้งแต่ต้น
- ตรงกันข้าม งานของ AI agent นั้น ไร้แรงเสียดทาน จนทำให้หลีกเลี่ยงการสำรวจทางออกอื่น ๆ และเราไม่อาจรู้ได้ว่าสิ่งที่กำลังยอมรับนั้นสมบูรณ์แบบ ธรรมดา เลวร้าย หรือถึงขั้นเป็นอันตราย
การพังทลายของการทำงานร่วมกันในทีมและความเชื่อมโยงระหว่างมนุษย์
-
หนี้ทางการรับรู้ ของการเขียนโค้ดแบบยึด LLM เป็นศูนย์กลางขยายไปไกลกว่าการเสื่อมถอยของทักษะ เมื่อเหล่า "slop-jockey" ที่มีช่วงความสนใจสั้นโยนผลงานของตนเข้าไปใน pull request และเอกสารออกแบบ จนขัดขวางการทำงานร่วมกันและรบกวนทั้งทีม
- เพื่อนร่วมงานที่ทำ code review กำลังมึนงงกับการตระหนักอย่างน่าตกใจว่า ตอนนี้ตนไม่ได้เป็นชั้นสุดท้ายของการควบคุมคุณภาพอีกต่อไป แต่กลายเป็นชั้นแรกแทน
- พวกเขาต้องคอยชี้ว่ามีฟังก์ชันที่เพิ่มเข้ามาใหม่แต่ไม่ถูกเรียกใช้ มีการเพิ่มไลบรารีที่หลอนขึ้นมาเอง และมี runtime หรือ compile error ที่เห็นได้ชัด
- ขณะที่ผู้เขียนซึ่งเห็นได้ชัดว่าเพียงกวาดตาดูโค้ดของตัวเองกลับไม่รับผิดชอบ และพูดว่า "Claude เขียนมาแบบนั้นเอง AI บ๊อง ๆ ฮ่า ๆ"
-
ผู้จัดการที่ชอบแทรกแซงและผู้บริหารที่ต้องการประหยัดเงินกำลังกดดันให้ทีม ลดปฏิสัมพันธ์ระหว่างมนุษย์ ลง (หวังว่าโดยไม่รู้ตัว)
- ในสภาพที่โดดเดี่ยวและถูกตัดขาดจากความเชื่อมโยง ตอนนี้ผู้คนกลับถูกให้อำนาจและได้รับการสนับสนุนให้สร้างกำแพงล้อมรอบประสบการณ์การทำงานของตนเอง
- เมื่อต้องการ pair programmer ต้องการถกเถียงและแลกเปลี่ยนแนวทางแก้ปัญหา ต้องการทำ prototype ต้องการสเก็ตช์สถาปัตยกรรม หรืออยากให้ผู้เชี่ยวชาญตอบคำถามเกี่ยวกับส่วนลึกลับของ codebase ก็กลับพึ่ง LLM แทนที่จะพึ่งมนุษย์
- ไม่จำเป็นต้องมี onboarding buddy, mentor หรือเพื่อนร่วมงานอีกต่อไป เพราะสามารถคุยกับเครื่องจักรแทนได้
- การใช้ LLM เพื่อหลีกเลี่ยงการปฏิสัมพันธ์กับมนุษย์นั้นง่ายเกินไป จนมีโอกาสกลายเป็นมาตรฐานใหม่
การปกป้องอัตลักษณ์ของโปรแกรมเมอร์
-
เป็นเรื่องน่าตกใจว่าเรายอมจำนนต่อเรื่องเล่าโฆษณาเกินจริงของ AI มากเพียงใด และถึงขั้น มีส่วนร่วมอย่างแข็งขันในการลบทักษะออกไปตามแผน พร้อมยอมสละเครื่องมือในการคิดของตนอย่างเต็มใจ
- พวกเราเคยเป็นคนโชคดีที่หาเลี้ยงชีพจากงานอดิเรกได้ แต่แม้จะสร้างกระบวนการที่เข้มงวดและละเอียดถี่ถ้วนขึ้นมาเพื่อตอบสนองต่อ slop ก็ยังเท่ากับเอาส่วนที่สนุกของงานไปจ้างภายนอก และแทนที่มันด้วยความน่าเบื่อแบบสั่งการ
-
LLM ดูเหมือน ทางแก้แบบทิ้งระเบิดนิวเคลียร์จากวงโคจรใส่ความซับซ้อนของซอฟต์แวร์ โดยแทนที่จะจัดการปัญหาจริง กลับเอื้อมไปหาสิ่งที่ซับซ้อนและคลุมเครือกว่ามากเพื่อรักษาแค่อาการ
- การแทน
sedด้วย Claude หรือการถามคำตอบเกี่ยวกับไลบรารีหรือเฟรมเวิร์กที่แม้ค้นเอกสารอยู่หลายชั่วโมงก็ยังไม่เจอความชัดเจน นั้นถือว่าใช้ได้ - แต่ไม่ต้องการจะกลายเป็นเพียง โอเปอเรเตอร์หรือผู้รีวิวโค้ด ที่ถอยไปนั่งเบาะหลังของงานที่สนุกและน่าสนใจ
- การแทน
-
ฉันชอบเครื่องมือที่ช่วยงานซ้ำ ๆ ช่วยทำความเข้าใจ codebase และช่วยเขียนโปรแกรมที่ถูกต้อง มากกว่า ผลิตภัณฑ์ที่ออกแบบมาให้คิดแทนฉัน
- ฉันปฏิเสธผลิตภัณฑ์ที่พรากความเป็นเจ้าของต่อความเข้าใจในซอฟต์แวร์ที่ฉันผลิต และตัดขาดฉันจากเพื่อนร่วมงาน
- ต่อให้ LLM ทำได้สมคำโฆษณา เราก็ยังต้องสูญเสียสิ่งเหล่านี้และตัวทักษะเองอยู่ดี
- มนุษย์สำคัญกว่าทั้งเครื่องจักรและบริษัทที่หนุนหลังมัน ขณะที่พวกเขากำลังทำกำไรจากการที่คนที่เหลือไล่ตาม American Dream แบบใหม่ที่พวกเขาขายอยู่
- และสิ่งที่เราเอาไปแลกก็คือความสามารถในการคิดเชิงวิพากษ์ ความสนุก ทักษะ ความเป็นส่วนตัว และอาจรวมถึงโลกทั้งใบด้วย
3 ความคิดเห็น
โดยรวมแล้วเห็นด้วย
โดยเฉพาะเรื่อง context switching? ต้องคอยขอพรอมป์ต์แล้วรอ ระหว่างนั้นสมาธิหลุด และกลายเป็นสาเหตุให้ประสิทธิภาพการทำงานลดลง ถ้า LLM เร็วขึ้นจนตอบสนองได้ทันที บางทีปัญหานี้อาจแก้ได้
ตัวบทความเองให้ความรู้สึกแรงมากว่าเขียนแบบตั้งข้อสรุปไว้ล่วงหน้าแล้ว ปัญหาที่ความเป็นเจ้าของงานของนักพัฒนาถูกลดทอนลงนั้น ต่อให้ไม่เกี่ยวกับ LLM ก็อ่านได้ว่าเป็นเรื่องของ "ยุคช่างฝีมือ vs ยุคอุตสาหกรรม"
ความเห็นจาก Hacker News
สิ่งที่ทำให้ฉันประทับใจที่สุดคือการได้เห็นคนรีวิวโค้ดเริ่มเสียสุขภาพจิตกันทีละน้อย เมื่อพวกเขาตระหนักว่าตอนนี้ตัวเองไม่ใช่ด่านสุดท้ายของการควบคุมคุณภาพอีกต่อไป แต่กลายเป็นแนวป้องกันด่านแรกไปแล้ว ได้รับคำขอรีวิวมา แต่ตอนนี้ต้องคอยไล่จับทีละอย่างทั้งฟังก์ชันที่เพิ่มมาใหม่แต่ไม่ถูกเรียกใช้ ไลบรารีที่โผล่มาแบบไม่มีปี่มีขลุ่ย หรือแม้แต่ runtime / compile error แบบชัดเจน คนเขียนโค้ดก็ปัดความรับผิดชอบด้วยทำนองว่า “Claude เขียนมาแบบนี้ครับ AI มันพลาดน่ะ ฮ่าๆ” หลังการนำ LLM มาใช้ กฎของบรันโดลินีที่ว่า “พลังงานที่ใช้ในการหักล้างเรื่องไร้สาระมากกว่าพลังงานที่ใช้สร้างมันหลายเท่า” ยิ่งรู้สึกจริงขึ้นเรื่อยๆ เมื่อนักพัฒนาที่ประสบการณ์น้อยหรือฝีมือยังไม่ถึงสามารถพ่นโค้ดออกมาหลายพันบรรทัดในไม่กี่นาที ความรับผิดชอบในการรับประกันความสมบูรณ์ของระบบก็ถูกผลักมาให้คนรีวิวโค้ดแทนจริงๆ พอดู added/removed LoC delta ของ PR จะเห็นว่า PR ที่ LLM เขียนมักมีแต่เพิ่มอย่างเดียว ส่วนวิศวกรอาวุโสที่ชำนาญมักลบโค้ดเก่าออกพอๆ กับที่เพิ่มโค้ดใหม่
ผมคิดว่านี่ไม่ใช่ปัญหาเทคโนโลยี แต่เป็นปัญหาคน ถ้าเกิดแบบนี้ขึ้นครั้งหนึ่งก็ควรเตือนอย่างจริงจัง และถ้าเกิดซ้ำรอบสองก็ควรส่งให้ผู้จัดการแล้วปฏิเสธไป ไม่ว่าใครจะเป็นคนเขียน PR สุดท้ายก็ต้องเอาชื่อตัวเองไปรับรองผลงานอยู่ดี ถ้าโค้ดเละเทะ ความรับผิดชอบนั้นก็ต้องเป็นของเจ้าตัว
ตอนนี้ผมไม่ได้ทำ code review ในทีมใหญ่แล้ว แต่ถ้าผมอยู่ในสถานการณ์แบบนั้น การโยนความรับผิดชอบแบบนี้อาจยอมให้ได้ครั้งหนึ่ง แต่ถ้าเป็นซ้ำ ผมคงพยายามไล่คนนั้นออก ถ้าทำไม่ได้ ผมก็คงลาออกเอง มันเป็นสภาพแวดล้อมที่เลวร้ายขนาดนั้น
ผมคิดว่าความรู้สึกว่าตัวเองผลิตงานได้น้อยลงในช่วงนี้ก็น่าจะเกี่ยวกับเรื่องนี้เหมือนกัน ทั้งแรงกดดันให้ผลิตโค้ดให้มากขึ้นและเร็วขึ้น และความจริงที่ว่าเมื่อใช้พวก agent ผมกลับมองภาพรวมทั้งหมดของโค้ดที่ตัวเองเขียนได้ไม่ดีพอ ผมรับประกันคุณภาพได้แค่ในขอบเขตที่ยังรีวิวละเอียดทีละบรรทัดได้ ซึ่งนั่นคือขีดจำกัด ช่วงนี้เลยใช้ AI ช้าลงและระมัดระวังมากขึ้น แล้วกลับมาเขียนเองด้วยมือมากขึ้น ถ้าเป็นงานอย่างกำหนด type ชัดๆ หรือเอาสเปกเดียวกันไปใช้ซ้ำกับหลายพร็อพเพอร์ตี AI ก็พอช่วยได้บ้าง แต่ถึงอย่างนั้นผลลัพธ์ก็ไม่ได้แน่นอนเสมอไป
ยิ่งเป็นวิศวกรอาวุโสที่มีประสบการณ์มาก ก็มักยิ่งลบโค้ดเก่าออกพอๆ กับที่เพิ่มโค้ดใหม่ ลองดูบทความ Negative 2,000 Lines Of Code ประกอบได้
ทันทีที่ LLM เข้ามาเกี่ยวข้อง ผมคิดว่ามันสะท้อนปัญหาสังคมที่กว้างขึ้นเรื่องการโยนความรับผิดชอบให้ใครกันแน่ คนเรามักรับความดีความชอบไว้เองถ้าผลออกมาดี แต่ถ้าไม่ดี ก็โยนให้ AI ได้ง่ายๆ ผมคิดว่าแค่มีคดีฟ้องร้องที่เหมาะสมสักไม่กี่คดี วัฒนธรรมนี้ก็จะเปลี่ยนไปมาก
ผมรู้สึกว่าคนที่เข้ามาในอุตสาหกรรมนี้มานานแล้วจำนวนมากไม่ได้มองโค้ดแบบงานช่างฝีมือ แต่มองเป็นวิธีหาเงินง่ายๆ ตั้งแต่ตอนเห็นบทความเกี่ยวกับนักพัฒนา open source infrastructure ที่เลี้ยงชีพลำบาก เห็นนักพัฒนานั่งโค้ดในคาเฟ่ เห็น bootcamp หรือกระแส “เรียนแค่โค้ดก็พอ” เห็นพวก Leetcode grinder ไปจนถึงนักพัฒนาในซานฟรานซิสโกที่ค่าเช่าแพงจนต้องนอนในรถ ทุกวันนี้ประเด็นกลายเป็นใช้ AI ทำให้ตัวเองถูกอัตโนมัติจนงานหาย ปัญหาคือภาพจำว่านักพัฒนาไม่ใช่มืออาชีพจริงๆ มาตรฐานก็หลวม ไม่มีจรรยาบรรณ ไม่มีชุดทักษะที่สม่ำเสมอ ไม่มีตัวแทนที่เป็นทางการ แถมสมาชิกในอุตสาหกรรมเองยังขาดความเป็นเจ้าของจนถึงขั้นเป็นปฏิปักษ์กับผลประโยชน์ของตัวเอง ทนายมีสภาทนาย แพทย์มีแพทยสภา แต่นักพัฒนามีแค่ความไม่มั่นคงเชิงอัตถิภาวนิยม ตอนนี้ถึงขั้นโดนหัวหน้าขู่ว่า “จะใช้ AI ทำให้งานคุณหายไป” อาชีพวิชาชีพอื่นไม่ได้เป็นปฏิปักษ์กับผลประโยชน์ตัวเองแบบนี้ ผมเลยสงสัยเหมือนกันว่าทำไมวงการนี้ถึงเป็นแบบนี้
ผมคิดว่า “coder” กับ software engineer เป็นคนละอย่างกัน แค่เรียนจบ bootcamp แล้วเขียนโปรแกรมง่ายๆ ด้วย Python ได้ ไม่ได้แปลว่าเป็น software engineer พอผมพูดว่าตัวเองมีปริญญา ก็มีคนหาว่าเป็นพวก elitist บ้าง บอกว่าสิ่งที่เรียนใน computer science ใช้กับงานจริงไม่ได้บ้าง แต่แน่นอนว่าก็มีคนที่ไม่มีปริญญาแต่พัฒนาตัวเองจนเป็นวิศวกรชั้นยอดได้จริง ถึงอย่างนั้นผมก็เห็นด้วยว่าจำเป็นต้องมีมาตรฐานบางรูปแบบ พวกที่จบ bootcamp แล้วไปเข้ายูนิคอร์นสตาร์ตอัปตามกระแส buzzword ล่าสุด ก็แค่ยินดีด้วยได้ แต่ระบบอ่อนไหวแบบกรณี Therac-25 นั้นผมคิดว่าควรให้คนที่ผ่านการฝึกฝนอย่างเป็นทางการรับผิดชอบจะดีกว่า
หัวหน้าที่พูดว่า “ถ้าไม่ทำให้อัตโนมัติ งานคุณจะหายไป” เหรอ? นั่นแหละคืองานของเรา การทำให้งานเป็นอัตโนมัติคือแก่นของอาชีพนี้อยู่แล้ว และพวกเราก็เป็นกลุ่มอาชีพที่มีทั้งโอกาสและความเข้าใจมากที่สุดในการทำให้ที่ทำงานของตัวเองเป็นอัตโนมัติ
ผมคิดว่าวิชาชีพครูก็มีความคล้ายกับนักพัฒนาอยู่บ้าง มีทั้งครูที่ยอดเยี่ยม ครูที่แย่ และอีกมากมายที่อยู่ตรงกลาง แค่รู้วิชาไม่ได้แปลว่าจะสอนได้เก่ง บางทีนักพัฒนาก็อาจมองได้ว่าเป็นครูที่สอนเครื่องจักร มีตั้งแต่สอนทีละตัวอักษร ทีละความคิด ไปจนถึงสอนด้วยบรรยากาศภาพรวม
ถ้าพักเรื่อง LLM ไว้ก่อน บางครั้งผมก็เขียนโค้ดที่เสร็จสมบูรณ์จนตัวเองภูมิใจได้จริงๆ ตั้งแต่โครงสร้างไปจนถึงทุกบรรทัด ไม่มีการตัดสินใจไหนที่ไร้เหตุผล โค้ดแบบนี้คือโค้ดที่ผมเป็นผู้เชี่ยวชาญและเข้าใจทั้งหมดอย่างถ่องแท้ แต่โค้ดส่วนใหญ่ผมก็ไม่ได้เขียนให้สมบูรณ์แบบขนาดนั้น ส่วนมากจะเป็นแนว “ทำงานให้เสร็จก็พอ” โดยยอมปล่อยให้มาตรฐานต่ำลงเล็กน้อยกับตัวเอง ถึงอย่างนั้นโค้ดที่ได้ทุ่มเต็มที่จริงๆ เป็นครั้งคราวก็ยังให้ความรู้สึกคุ้มค่ามาก และเป็นหนึ่งในประสบการณ์การเขียนโค้ดที่ดีที่สุดในชีวิต พอมาคิดเรื่อง LLM ด้วย มันทำให้การเขียนโค้ดคุณภาพสูงง่ายขึ้นในด้านหนึ่ง แต่ก็ยากขึ้นในอีกด้านหนึ่ง ถ้าอยู่ในสภาวะจิตใจที่จดจ่อจริงๆ เราสามารถใช้ LLM ให้ช่วยสร้างผลลัพธ์ที่เร็วขึ้นและได้มาตรฐานสูงขึ้นได้ ผมเขียนได้ดีกว่าโค้ดที่ LLM สร้างอย่างชัดเจน แต่ก็อาจเขียนได้ดียิ่งขึ้นด้วยความช่วยเหลือของ LLM เช่นกัน ปัญหาคือการรักษาสภาวะจดจ่อนั้นยากขึ้นเรื่อยๆ เรามักแค่กวาดตาดูโค้ดที่ LLM สร้าง เห็นหน้าตาก็ดูดี แถมยังทำงานได้ ก็เลยปล่อยผ่านไป แต่โค้ดที่ปล่อยผ่านแบบนั้นจะค่อยๆ แย่ลงทีละนิด และถ้าปล่อยให้ผ่านแบบมึนๆ ไปเรื่อยๆ สุดท้ายก็สายเกินแก้ ผลคือเราจะไม่ได้กลายเป็นผู้เชี่ยวชาญของโค้ดนั้นเอง และมีแต่โค้ดหละหลวมสะสมขึ้นเรื่อยๆ
บทความนี้ตรงกับความคิดผมมาก อ่านแล้วรู้สึกดี ผมเคยพยายามใช้ AI ในบริษัท แต่ในกรณีส่วนใหญ่ผลลัพธ์ออกมาไม่ค่อยดี สุดท้ายเกือบทั้งหมดผมก็ต้องเขียนใหม่เองอยู่ดี ผมมั่นใจเลยว่าการยกเวลาในการคิดหรือการแก้ปัญหาที่ไม่จำเป็นให้ AI เป็นทางเลือกที่แย่ที่สุดสำหรับอาชีพของผม AI ก็เป็นแค่เครื่องสร้างข้อความคุณภาพระดับกลางเท่านั้น
สำหรับคำถามที่ว่า “คนพวกนั้นตกลงเข้ามาเป็นโปรแกรมเมอร์ทำไม ในเมื่อดูเหมือนไม่ได้สนใจโค้ดเลย” ผมอยากเน้นว่า “เป้าหมายคือการแก้ปัญหา” การเขียนโค้ดเป็นเพียงวิธีการ ไม่ใช่จุดหมายในตัวเอง เรื่อง “ตั้งค่า editor ปรับ dotfiles จัดสภาพแวดล้อมพัฒนา” อาจจะสนุกก็จริง แต่ผมมองว่าเป็นความซับซ้อนที่ไม่จำเป็นและยินดีจะมอบหมายให้คนอื่นทำ
การตั้งค่า editor, dotfiles และสภาพแวดล้อมพัฒนาด้วยตัวเอง สุดท้ายแล้วคือการสร้างความคุ้นเคยกับสภาพแวดล้อมการทำงานของตัวเอง พัฒนาทักษะการใช้เครื่องมือ และสร้างสภาพแวดล้อมที่ทำงานได้มีประสิทธิภาพมากขึ้น เวลาต้องไปแตะ build script แล้วกลายเป็น “คนที่ถูกเรียกหา” ก็เพราะเคยดูแลเรื่องพวกนี้มาก่อน มีคนจำนวนมากเกินไปที่ใช้ Git มาเป็นสิบยี่สิบปีแล้วยังไม่เข้าใจ merge conflict หรือการใช้งานพื้นฐานอยู่ดี สุดท้ายงานน่ารำคาญทั้งหมดก็ไปตกที่คนที่เรียนรู้เครื่องมืออย่างจริงจัง
คำกล่าวแนว “สิ่งนี้ไม่มีคุณค่า” ถ้าผลักตรรกะไปจนสุดทาง มันก็อาจลงเอยที่ “การมีอยู่เองมีคุณค่าอะไรหรือเปล่า” ได้เหมือนกัน
งานเกือบทุกอาชีพในโลกมีเป้าหมายเพื่อแก้ปัญหาทั้งนั้น แต่ผมก็ยังสงสัยอยู่ดีว่าทำไมในบรรดาอาชีพมากมายเหล่านั้นถึงเลือกซอฟต์แวร์
ผมเห็นด้วย 100% กับคำกล่าวที่ว่า “เป้าหมายคือการแก้ปัญหา และการเขียนโค้ดเป็นเพียงเครื่องมือ” คนที่เศร้าเมื่อ AI มาเขียนโค้ดแทนมักเป็นพวก “ศิลปินโค้ด” ที่ยึดติดกับ “รูปแบบ” ของสิ่งที่กำลังสร้างมากกว่า ส่วนผมเป็นคนที่สนใจตัวปัญหาเอง ดังนั้นการที่ AI มาเขียนโค้ดแทนจึงไม่ได้ทำให้รู้สึกเสียดายเลย
คำกล่าวว่า “การเขียนโค้ดไม่ใช่เป้าหมาย แต่เป็นเครื่องมือ” หรือ “การเล่นกับ editor แม้จะสนุกแต่ไม่มีคุณค่า” ล้วนเป็นเรื่องอัตวิสัยอย่างยิ่ง มีคนจำนวนมากที่ชอบการเขียนโค้ดล้วนๆ แม้จะไม่มีปัญหาให้แก้ และถ้าบนโลกนี้ไม่มีปัญหาอะไรเหลืออยู่เลย ก็ยังน่าจะมีคนจำนวนมากที่สนุกกับการเขียนโค้ดอยู่ดี
ผมอ่านบทความนี้ด้วยความสนใจมาก มันแทบตรงกับความรู้สึกของผมต่อการเขียนโปรแกรมด้วย LLM ทุกอย่าง ผมเป็นคนที่ชอบการเขียนโค้ดจริงๆ และก็สนุกกับการทำมันเป็นอาชีพ แต่ทุกวันนี้น่าเสียดายที่ผมเอางานอดิเรกที่ตัวเองรักมาใช้ในงานไม่ได้เหมือนเดิมแล้ว มันกลายเป็นงานคนละแบบไปโดยสิ้นเชิง
ผมอายุมากพอสมควร ราวปี 1995 ผมเขียนโปรแกรมในสภาพแวดล้อมที่ต่างจากตอนนี้อย่างสิ้นเชิง ตอนนั้นวิศวกรรู้ทั้งลูกค้าเป้าหมาย tech stack และแนวโน้มของอุตสาหกรรม และถืออำนาจนำอยู่จริงๆ โค้ดของตัวเองคือสนามเด็กเล่นของตัวเอง จะรื้อใหม่แบบไหนก็ได้ จะตั้งกฎเยื้องบรรทัดหรือสไตล์วงเล็บอย่างไรก็ได้เอง (พังก็แก้เอง) ตอนนั้นยังไม่มี unit test ด้วยซ้ำ (อย่างมากก็เช็กพารามิเตอร์) และแทบไม่มี code review อย่างเป็นทางการ เป็นยุคที่แค่คุยเล่นในออฟฟิศกับเพื่อนร่วมงาน ขีดๆ เขียนๆ บนไวต์บอร์ดกันไป ถ้ามีบั๊กก็แก้ทันที ท้ายที่สุดฝ่ายบริหารก็ชนะ และดูเหมือนยุค ‘cowboy coding’ แบบนั้นคงกลับมาได้ยากแล้ว จะคิดถึง Apple ยุค 90s ก็ได้ แต่เราคงย้อนกลับไปไม่ได้ ตอนนั้นมันสนุกมากจริงๆ
ผมก็เริ่มต้นช่วงเวลาใกล้ๆ กัน แต่ทีมผมมี code review เป็นประจำเพราะ ISO 9001 เราพิมพ์ผลงานออกกระดาษ แล้วให้คน 3 คนมานั่งในห้องเดียวกัน ตรวจทุกบรรทัดและเซ็นชื่อรับรอง เราทำสิ่งนี้กับ industrial control RTOS ส่วนการบริหารโครงการก็พิมพ์ gantt chart ยาว 40 ฟุตไปแปะบนผนังแล้วตามงานกัน เป็นยุค waterfall เต็มตัว
ผมเริ่มงานช่วงปลายยุค 2000s ซึ่งตอนนั้นเส้นทางอาชีพและขอบเขตความเชี่ยวชาญยังชัดเจนกว่าตอนนี้มาก ผู้ดูแลระบบกับนักพัฒนาแยกกันชัดเจน แต่ตอนนี้กลับคาดหวังให้ผมทำบทบาทฝั่ง system operations ด้วย ทำให้ขอบเขตงานกว้างขึ้นไปอีก ผมพัฒนาทักษะสายระบบไว้เป็นงานอดิเรกเท่านั้น และพอได้งานจริงก็อยากเมินมันไปเลย เพราะเอกสารและการอบรมจาก vendor ในโลกจริงมักแย่มาก
วงการทั้งหมดคงไม่ย้อนกลับไปเป็น cowboy coding อีกครั้ง แต่ผมคิดว่าในบางสภาพแวดล้อมสไตล์แบบนี้ยังคงเหลืออยู่ ที่ WhatsApp ช่วงปี 2011–2019 ก็มีสภาพแวดล้อมที่ค่อนข้างอิสระอยู่พอสมควร แม้แต่ละที่จะแตกต่างกัน แต่ความเหมาะสมก็ขึ้นอยู่กับต้นทุนของการจับข้อผิดพลาดก่อนเกิด และต้นทุนของการแก้หลังเข้าโปรดักชัน สำหรับผมแล้ว ผมชอบแนวทางที่ลดต้นทุนการแก้ข้อผิดพลาดมากกว่า แน่นอนว่าก็ยังพยายามไม่ทำพลาดแบบน่าอาย และทดสอบในส่วนที่จำเป็นจริงๆ
ตอนนี้คนสาย business mindset, พวก vibe coder และพวก script kiddie เข้ามาเยอะเกินไป จนทุกอย่างแย่ลงหมด
ปัญหาของ cowboy coding คือสมาชิกทีมที่เชื่อถือไม่ได้แค่คนเดียวก็ทำทั้งทีมพังได้ ยิ่งองค์กรใหญ่ขึ้น จำนวนคนที่มีปัญหาก็เลี่ยงไม่ได้ที่จะเพิ่มขึ้น และถ้าจะป้องกันไม่ให้ปัญหาระเบิด ก็ต้องมีระบบป้องกันที่ใหญ่ขึ้นเรื่อยๆ สำหรับทีมขนาดเล็กที่คัดแต่คนเก่งและทำงานบนพื้นฐานความไว้วางใจ cowboy coding มีประสิทธิภาพสูงสุด แต่เพราะการประเมินฝีมือผู้สมัครตอนจ้างงานทำได้ยาก มันจึงไม่เหมาะกับองค์กรขนาดใหญ่เลย ในอนาคตวิธีนี้อาจอยู่รอดได้เฉพาะบริษัทเล็กๆ หรือทีมเล็กภายในบริษัทใหญ่เท่านั้น
ผมเห็นด้วยได้ยากกับคำพูดของผู้เขียนที่ว่า "<i>LLM เป็นเหมือนอาวุธนิวเคลียร์ลูกสุดท้ายที่ใช้จัดการกับความซับซ้อนของซอฟต์แวร์ มันไม่ได้แก้ปัญหาจริง แต่พยายามบรรเทาอาการด้วยการนำความซับซ้อนที่ใหญ่กว่าเดิมเข้ามา</i>" แก่นแท้ของการนำ AI มาใช้คือการรวมศูนย์ “แรงงานทักษะสูงที่มีความคิดสร้างสรรค์และมีราคาแพง” ไปอยู่ในบริษัทไม่กี่แห่งที่ออกแบบ AI แล้วให้บริษัทที่เหลือทั้งหมดเลิกจ้าง creative worker และเหลือไว้แค่แรงงานง่ายๆ กล่าวคือ เป้าหมายคือทำให้ความซับซ้อนของทุกธุรกิจถูกทำให้ง่ายลงด้วย AI ถ้ายกตัวอย่างจาก “The Wizard of Oz” ก็คือทุกคนไม่อยากเปิดดูหลังม่าน แค่อยากให้งานตัวเองง่ายขึ้นเท่านั้น ความเสี่ยงระยะยาวที่ต้องใช้เวลามองเห็นถูกเมินหมด เพราะทุกคนสนใจแต่ผลประโยชน์ระยะสั้น
ผมชอบบทความนี้มาก และก็เห็นด้วยกับบางความเห็นที่ว่าการแก้ปัญหาสำคัญกว่าโค้ด แต่ในมุมของผม ถ้าเราเริ่มมอบปัญหาที่ต้องใช้การคิดลึกๆ ให้ AI ด้วย ความสามารถในการแก้ปัญหาเชิงลึกแบบนี้เองอาจเสื่อมลงไปตามเวลา การสั่งแค่ว่า “ช่วยทำอะไรบางอย่างให้หน่อย” สำหรับผมแล้วไม่ใช่การแก้ปัญหาจริงๆ