งานตามเก็บกวาดหลังนักพัฒนา AI ระดับร็อกสตาร์
(codingwithjesse.com)- ในอดีต ปัญหาฐานโค้ดที่เข้าใจได้ยากซึ่ง ‘นักพัฒนาระดับร็อกสตาร์’ ทิ้งไว้ กำลังขยายกลายเป็นภาระด้านการบำรุงรักษาของทั้งทีม จากการแพร่หลายของโค้ดที่สร้างโดย LLM
- นักพัฒนาระดับร็อกสตาร์นำเทคโนโลยีใหม่ กระบวนทัศน์ใหม่ และสถาปัตยกรรมใหม่มาใช้ได้อย่างรวดเร็ว และปิดงานยาก ๆ ได้ไว แต่ให้ความสำคัญน้อยกับการเขียนโค้ดที่คนอื่นเข้าใจและทำงานร่วมกันได้
- เอเจนต์ LLM สามารถสร้างโค้ดนับหมื่นบรรทัดในเวลาอันสั้นโดยไม่จำงานก่อนหน้า และไม่ใส่ใจว่าโค้ดนั้นสอดคล้องกับทั้งระบบหรือช่วยให้เข้าใจได้ง่ายขึ้นหรือไม่
- ยิ่งมีโค้ดที่สร้างขึ้นมากเท่าไร ความซับซ้อนของระบบก็ยิ่งเพิ่มขึ้นมาก และอาจเกิดวงจรที่ต้องพึ่ง LLM อีกครั้งเพื่อทำความเข้าใจมัน
- สำหรับซอฟต์แวร์ที่ต้องใช้งานยาวนาน ควรจำกัดการใช้ LLM ไว้กับการสร้างโค้ดชิ้นเล็ก ๆ ให้มนุษย์เป็นผู้นำการออกแบบ และทำให้สถาปัตยกรรมเรียบง่ายให้สอดคล้องกับความซับซ้อนของปัญหา
โครงสร้างที่นักพัฒนาร็อกสตาร์ทิ้งไว้
- นักพัฒนาระดับร็อกสตาร์หลังเข้าร่วมทีม มักเสนอไอเดียที่หนักแน่นเกี่ยวกับเทคโนโลยีใหม่ กระบวนทัศน์ใหม่ และสถาปัตยกรรมใหม่
- เขียนสถาปัตยกรรมหลักของบริษัทขึ้นใหม่เกือบทั้งหมด และนำกระบวนการ build เครื่องมือ และภาษาใหม่เข้ามาใช้
- ปฏิเสธ pull request จำนวนมาก ยกระดับมาตรฐานที่ทีมต้องทำตาม และคนอื่นก็ไม่อาจแสดงออกว่าเข้าใจโค้ดนั้นหรือไม่
- งานที่ยากที่สุดมักถูกมอบให้กับนักพัฒนาร็อกสตาร์ และเขาก็ทำเสร็จเร็วกว่าคนอื่น
- สมาชิกทีมคนอื่น ๆ เคลื่อนไหวช้าลง เพราะต้องเรียนรู้ไลบรารีใหม่และปรับตัวเข้ากับแนวทางของนักพัฒนาร็อกสตาร์
- หลายปีต่อมา นักพัฒนาร็อกสตาร์ก็ออกจากทีมไป เพราะต้องการโปรเจ็กต์ที่ยากกว่าและบริษัทที่ใหญ่กว่า
รับมือกับผลกระทบที่ตามมา
- สมาชิกทีมที่เหลือต้องรับช่วงโปรเจ็กต์ของนักพัฒนาร็อกสตาร์ และเผชิญกับความรู้สึกถูกโค้ดถาโถมใส่
- การไล่ตาม data flow ทำได้ยาก ราวกับมีใครบางคนพยายามปกปิดคดีฆาตกรรม
- เริ่มจากแก้บั๊กง่าย ๆ แต่ใช้เวลาถึงหนึ่งสัปดาห์กว่าจะรันโค้ดบนโน้ตบุ๊กได้
- ครึ่งหนึ่งของโค้ดเขียนด้วยภาษาที่ไม่เข้าใจ อีกครึ่งเขียนด้วยไลบรารีที่ไม่เคยได้ยินชื่อมาก่อน
- เคยบอกหัวหน้าว่าจำเป็นต้องเขียนโค้ดใหม่ แต่ก็ไม่เป็นที่ยอมรับเพียงเพราะมันเป็นโค้ดที่นักพัฒนาร็อกสตาร์เขียนไว้
- ระหว่างที่ต้องหลงทางอยู่ในโค้ดอันยุ่งเหยิง ก็เริ่มจินตนาการถึงการลาออกขณะไถดูประกาศรับสมัครงาน
การเก็บกวาดหลังร็อกสตาร์
- หลายทีมและหลายเอเจนซีจำเป็นต้องจัดการฐานโค้ดที่นักพัฒนาระดับร็อกสตาร์ทิ้งไว้เช่นนี้
- กระบวนการทำความเข้าใจและกู้ฐานโค้ดที่ซับซ้อน เปรียบได้กับการแก้สายไฟประดับที่พันกันเพื่อให้กลับมาใช้งานได้อีกครั้ง
- นักพัฒนาร็อกสตาร์ชอบการเขียนโค้ด การเรียนรู้ และการใช้กระบวนทัศน์ใหม่ ๆ พร้อมผลักตัวเองไปจนสุดความสามารถ
- พวกเขาพยายามเขียนโค้ดให้ฉลาดที่สุดเท่าที่จะทำได้ และมุ่งเน้นการเดินหน้าให้เร็วที่สุด
- การเขียนโค้ดที่คนอื่นสามารถร่วมงานด้วยได้ กลายเป็นสิ่งที่มีลำดับความสำคัญต่ำที่สุดสำหรับนักพัฒนาร็อกสตาร์
การมาถึงของปัญญาประดิษฐ์
- ในช่วงไม่กี่ปีที่ผ่านมา หลายทีมกำลังเผชิญกับสถานการณ์ที่ถูกกองทัพนักพัฒนาร็อกสตาร์กดดัน
- ทุกครั้งที่มีใครเริ่มแชตใหม่ ก็มีความเสี่ยงเหมือนเพิ่มนักพัฒนาร็อกสตาร์เข้าทีมอีกคน
- เอเจนต์จำไม่ได้ว่าเมื่อวานทำอะไรไว้ และสร้างโค้ดนับหมื่นบรรทัดได้ในเวลาไม่กี่นาที
- เอเจนต์มุ่งปิดงานด้วยความเร็วในระดับที่มนุษย์ทำไม่ได้
- มันไม่สนใจว่าโค้ดที่สร้างขึ้นจะเข้ากับโค้ดส่วนอื่นของระบบหรือทำให้ระบบเข้าใจง่ายขึ้นหรือไม่
- AI มีกล่องเครื่องมือของแนวปฏิบัติที่ดีที่สุดซึ่งอาจไม่เหมาะกับบริบท
- แม้เมื่อความซับซ้อนจะมากกว่าประโยชน์ AI ก็ยังยืนยันใช้มาตรการป้องกันเกินจำเป็นแบบ “belt and suspenders”
- เมื่อขอ code review มันก็มักสร้างรายการปรับปรุงยาวเหยียดที่มีหลายข้อซึ่งยากจะเห็นด้วย
- ผู้คนจำนวนมากเริ่มรู้สึกว่าถ้าไม่ใช้ LLM ก็จะตามหลังตลอดกาล
- แต่ผู้เขียนมองว่าการปล่อยให้ LLM เขียนโค้ดทั้งหมด สุดท้ายต่างหากที่จะทำให้ตามหลัง
การเก็บกวาดหลัง AI ร็อกสตาร์นับร้อยคน
- การทำความสะอาดกองโค้ดที่สร้างขึ้นอย่างยุ่งเหยิง ไม่น่าเพลิดเพลินเท่าการเก็บกวาดโค้ดของนักพัฒนาร็อกสตาร์เพียงคนเดียว
- อย่างน้อยนักพัฒนาร็อกสตาร์ก็ยังมีเจตนาด้านการออกแบบบางอย่าง และมีความพยายามที่จะทำให้ดีที่สุด
- แต่กองโค้ดรก ๆ ที่สร้างจาก vibe coding ไม่ได้ถูกเขียนโดยนักพัฒนาเทียมคนเดียว
- มันกลายเป็นฐานโค้ดที่สร้างขึ้นทีละฟีเจอร์หรือทีละการแก้บั๊ก จากหลายแชตและหลายบริบท
- นี่คล้ายกับฐานโค้ดที่เขียนโดยนักพัฒนาร็อกสตาร์ต่างคนกันนับร้อยคน
- ในบางกรณี หนี้ทางเทคนิคอาจพอกพูนมากเกินกว่าจะชดใช้ได้ตลอดไป
การสร้างซอฟต์แวร์ที่ยืนยาว
- มีหลายวิธีในการใช้ LLM โดยไม่ปล่อยให้มันทำตัวเหมือนนักพัฒนาร็อกสตาร์
- มนุษย์ควรเป็นผู้นำงานวิศวกรรม และชี้นำให้ LLM สร้างโค้ดเพียงชิ้นเล็ก ๆ ในแต่ละครั้ง
- ต้องตรวจสอบให้แน่ใจว่าซอฟต์แวร์ถูกเขียนในแบบที่สมาชิกทีมทุกคนเข้าใจและทำงานต่อได้ง่าย
- หาก LLM หลงทางโดยไม่เข้าใจว่ากำลังทำอะไรและทำไปทำไม ก็ควรชะลอความเร็วลง
- การเดินให้ช้าลงเพื่อรับประกันคุณภาพของซอฟต์แวร์ที่กำลังสร้างนั้นเป็นเรื่องที่ยอมรับได้
- การป้องกัน over-engineering และค่อย ๆ ทำให้สถาปัตยกรรมเรียบง่ายลงจนสอดคล้องกับความซับซ้อนของปัญหาก็เป็นเรื่องที่ยอมรับได้
- บางครั้งการวาง LLM ไว้ในกล่องเครื่องมือแล้วลงมือเขียนโค้ดเองก็เป็นเรื่องที่ยอมรับได้
- ความเป็นช่างฝีมือยังคงอยู่ในมือมนุษย์เสมอ และเป็นขอบเขตที่ไม่อาจเอาต์ซอร์สให้เครื่องจักรได้
2 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ประโยคสุดท้ายที่บอกว่างานฝีมือจะต้องคงอยู่ในมือมนุษย์เสมอและไม่มีวันจ้างเครื่องทำแทนได้ ฟังดูน่ากังวลนิดหน่อย
งานฝีมือในอุตสาหกรรมอื่นก็ไม่ได้ตายไปไหน แต่ถูกทางเลือกที่ถูกกว่าและหาได้ง่ายกว่ากลบไปมาก รองเท้าหนังทำมือก็ยังซื้อได้ แต่คนที่อยากจ่ายเกิน $1000 มีไม่มาก ภาพวาดที่ใช้เวลาหลายสัปดาห์ก็ยังซื้อได้ แต่คนส่วนใหญ่ซื้อของตกแต่งผนังและของใช้จุกจิกจาก HomeGoods แทน
ความต่างสำคัญคือ สมมติฐานว่าใช้แล้วทิ้ง ซึ่งน่าเสียดายที่ซอฟต์แวร์ก็กำลังกลายเป็น “ของใช้แล้วทิ้ง” เหมือนสินค้าอื่นมากขึ้นเรื่อย ๆ ถ้าเป็นแอปนับถอยหลังง่าย ๆ จะทิ้งก็ได้ แต่ซอฟต์แวร์ที่ค้ำกระบวนการทำงานของธุรกิจในระยะยาวไม่ควรถูกปฏิบัติแบบนั้น
ถ้าไปโฟกัสที่งานฝีมือของซอฟต์แวร์ ปัญหาอาจดูเหมือนเป็น “สิ่งที่ตรงกับการใช้งานของฉัน” เทียบกับ “ของบูติกที่แพงและไม่จำเป็น” แต่จริง ๆ แล้วมันควรเป็น “สิ่งที่บำรุงรักษาได้และเชื่อถือได้” เทียบกับ “สิ่งที่ทิ้งได้”
ประเด็นที่อยากพูดตรงนี้ไม่ใช่ว่าสิ่งนี้เป็นประโยชน์ต่อผู้ให้บริการโมเดลรายใหญ่อย่าง OpenAI หรือ Anthropic หรือไม่
โต๊ะราคาถูกที่มาในกล่องแบน ๆ แล้วฉันเอาไขควงประกอบเองก็ผลิตจำนวนมากจากโรงงาน แต่ การออกแบบ ของมันอาจมีงานฝีมือจากผู้เชี่ยวชาญมากกว่าของสั่งทำเสียอีก โครงสร้างคือจ่ายต้นทุนการออกแบบสูงล่วงหน้า แล้วผลิตจำนวนมากด้วยต้นทุนส่วนเพิ่มต่ำ
ซอฟต์แวร์ก็เป็นแบบนั้นมาตั้งแต่แรกเป็นส่วนใหญ่ ตอนคุณดาวน์โหลด Firefox ไม่ได้มีช่างฝีมือมาสร้างเว็บเบราว์เซอร์ให้คุณคนเดียว แต่เป็นเซิร์ฟเวอร์ CDN ในดาต้าเซ็นเตอร์ที่ไหนสักแห่งคัดลอกไบต์จากแคชมาให้
สิ่งที่ AI กำลังคุกคามคือการแทนที่ งานฝีมือแบบลงทุนล่วงหน้า ซึ่งไม่เคยเกิดขึ้นในวงกว้างในอุตสาหกรรมอื่น ส่วนที่ AI เข้าไปแทนได้สำเร็จกว่าคือซอฟต์แวร์ “ทำมือ” ราคาถูก ซึ่งจริง ๆ แล้วเป็นหมวดที่แทบไม่เคยมีอยู่มาก่อนเพราะไม่คุ้มเศรษฐศาสตร์
เพราะงั้นจึงมีคันโยกจาก การลงทุนด้านคุณภาพ มากกว่ามาก
ผมก็เห็นด้วยได้ยากว่าซอฟต์แวร์เป็นของใช้แล้วทิ้งในความหมายเดียวกัน ถ้าเป็นปัญหาชั่วคราวก็ทิ้งโค้ดแล้วทำใหม่เมื่อมีปัญหาอื่นได้ แต่ถ้าเป็นปัญหาที่คงอยู่ โค้ดก็จะคงอยู่ต่อไป
สกรูเคยเป็นของหายากที่ต้องทำขึ้นตามสั่ง และการทำสกรูดี ๆ สักตัวต้องใช้เวลาและแรงมาก แม้แต่สิ่งที่ทุกวันนี้เราเรียกว่า machine screw ก็เคยต้องอาศัยคนที่มีทักษะสูงและลงแรงอย่างหนักกว่าจะทำได้
แต่เครื่องจักรสามารถถ่ายทอดงานฝีมือได้ ถ้าคุณทำสกรูที่ดีมากได้หนึ่งตัว เครื่องจักรก็ถ่ายโอนคุณภาพของสกรูนั้นไปยังสกรูใหม่จำนวนมากได้
ทุกวันนี้สกรูแทบทุกชนิดทุกเกรดกลายเป็นของสิ้นเปลืองที่คล้าย ๆ กันไปหมด และสกรูที่สมัยก่อนต้องเหลาด้วยมือเป็นวันหรือเป็นสัปดาห์ วันนี้ผลิตกันทีละหลายพันล้านตัว
ผมมอง AI เหมือนเครื่องกลึงที่ไม่มี leadscrew ตอนแรกคุณยังต้องทำสกรูด้วยมือเองก่อน แล้วหลังจากนั้นก็ถ่ายทอดคุณภาพที่คุณทำได้ไปยังสกรูใหม่ได้ไม่จำกัด พอคุณทำสกรูที่ดีกว่าเดิมได้ ก็เอามันใส่เครื่องกลึงแล้วทำสกรูที่ดีขึ้นได้มากขึ้น แต่โดยพื้นฐานก็ยังถูกจำกัดด้วยคุณภาพของสกรูที่คุณทำด้วยตัวเองได้ ถ้าคุณทำได้แค่ของคด ๆ เบี้ยว ๆ ขรุขระ ยุ่ย ๆ เครื่องจักรก็ให้ได้แค่นั้น
นักพัฒนาซอฟต์แวร์สร้างทรัพย์สินทางปัญญาที่มีลักษณะเฉพาะ ไม่ได้ผลิตหน่วยของซอฟต์แวร์ คล้ายผู้เขียนหนังสือหรือนักดนตรี
ในซอฟต์แวร์ไม่มีสิ่งที่เทียบกับการผลิตเป็นหน่วย เพราะมันก็แค่การคัดลอกและย้ายบิตเท่านั้น
เพราะฉะนั้น “งานฝีมือ” ในบริบทของซอฟต์แวร์หมายถึงการใส่ใจแค่ไหนในการออกแบบสิ่งดี ๆ มันจะไม่หายไป เว้นแต่เราจะไปถึงจุดที่คุณภาพของซอฟต์แวร์ที่เราใช้ไม่สำคัญอีกต่อไป ซึ่งตอนนี้ยังไม่มีสัญญาณว่าจะไปทางนั้น
การเปรียบเทียบที่เหมาะกว่าอาจเป็น วิศวกรที่สร้างและบำรุงรักษาอุปกรณ์การผลิต ของโรงงานรองเท้า พวกเขาอยู่ห่างจากผู้บริโภคไปหนึ่งชั้น แต่ก็ยังมีงานฝีมืออยู่ชัดเจน
ผมชอบงานที่ต้องไปแก้โค้ด AI หรือโค้ดที่เอาไปจ้างข้างนอกทำ สัปดาห์ก่อนเพิ่งรู้ว่าลูกค้ารายหนึ่งพยายามสร้างเครื่องมือให้แผนกด้วย vibe coding ผลที่ได้คือ ขยะ Next.js ก้อนมหึมา ที่ต้องใช้หน่วยความจำ 10GB เพื่อคอมไพล์ มี lint error เป็นพัน ๆ รายการ และยังมี development log เสียงดังรก ๆ ถูกใส่ไว้ใน Git ด้วย
ตอนนี้เราต้องเข้าไปเก็บกวาด ซึ่งเรื่องแบบนี้แทบจะเป็นงานฟรีมูลค่า 10,000 ถึง 50,000 ยูโรที่เข้ามาซ้ำ ๆ ถ้ารู้ว่ากำลังทำอะไรอยู่ มันง่ายมาก ถ้าไม่รู้ก็เป็นไปไม่ได้ เอามาอีกเรื่อย ๆ ได้เลย
ผมทำงานด้าน incident response ให้กับธุรกิจขนาดเล็กและกลาง ช่วงไม่กี่ปีที่ผ่านมา งานเพิ่มขึ้นจนแทบรับไม่ไหว และบัญชีธนาคารก็ให้ความรู้สึกเหมือนกองทองของมังกร
ผมเชื่อมาตลอดว่าความปลอดภัยต้องถูกบูรณาการและวางแผนไว้ตั้งแต่ต้น ไม่ได้หมายความว่าอยากเห็นเหตุการณ์ถูกเจาะเลย
เพียงแต่การที่คนซึ่งมีความเชี่ยวชาญแบบก้ำกึ่งสามารถปั่นแอปออกมาได้ภายในชั่วโมงเดียว กลายเป็นลาภก้อนโตสำหรับคนแบบผม
ถ้าจะมองแบบนี้ มันก็คือ สล็อตแมชชีนมนุษย์ ที่คนเอาเงินยัดเข้าไป
เวลาลูกค้าเข้ามาหา พวกเขาตั้งใจจะขอความช่วยเหลือเพื่อนำขึ้น production ตั้งแต่แรก หรือว่านี่เป็นทางเลือกสุดท้ายหลังจากแนวทาง AI ล้มเหลวทั้งหมดแล้ว
และอยากรู้ด้วยว่าโปรเจ็กต์แบบนี้มักพังในรูปแบบเดิม ๆ หรือว่าความล้มเหลวส่วนใหญ่ออกมาแบบค่อยเป็นค่อยไปและจับยาก
เคยเจอคนไม่กี่คนในชีวิตที่เรียกได้ว่าเก่งจริง ๆ แบบคิดว่า “ทำไมถึงฉลาดได้ขนาดนี้?”
มีอยู่สองลักษณะที่มักเห็นในคนที่ฉลาดมาก ๆ ซึ่งโดยมากมักจะขัดแย้งกันเอง อย่างแรกคือคนที่ไม่รู้ว่าตัวเองฉลาดแค่ไหน สำหรับเขา มันเป็นเรื่องง่าย หรือเป็นเรื่องที่ตัวเองรู้อยู่แล้ว เลยคิดว่าถ้าใครมีปริญญาวิทยาการคอมพิวเตอร์ก็น่าจะรู้ จำได้ และเข้าใจเหมือนกันหมด เคยดูเพื่อนที่พูดคณิตศาสตร์เกี่ยวกับการเข้ารหัสได้เป็นฉาก ๆ แล้วรู้สึกว่า “ฉันสอบวิชานั้นผ่านนะ แต่จะบอกว่าฉันเข้าใจหัวข้อที่เธอเพิ่งพูดจริง ๆ ก็คงไม่ได้”
อีกแบบคือคนที่รับรู้ตลอดเวลาอย่างเจ็บปวดว่าตัวเองฉลาดกว่าคนรอบตัวส่วนใหญ่ บางคนก็ทำตัวแย่ ๆ บางคนก็แค่เหนื่อยล้าที่ต้องอยู่ท่ามกลางคนที่ “โง่กว่า” ในกรณีหลังนี้ก็พอเข้าใจได้ระดับหนึ่ง ลองจินตนาการว่าคุณใช้ชีวิตแบบที่ทุกอย่างดูชัดเจน ตรงไปตรงมา และจัดการได้ง่าย แต่ต้องมองมนุษยชาติเลือกทางที่โง่ซ้ำแล้วซ้ำเล่า ทั้งที่คำตอบเป็นที่รู้กันมานานแล้ว
เวลาเห็นคนทำอะไรสะเปะสะปะ หรือทำ X ทั้งที่เห็นชัด ๆ ว่ามันจะนำไปสู่ผลลัพธ์แย่ ๆ คือ -Y ก็แทบจะบ้าตาย ส่วนใหญ่แค่เรียนรู้ที่จะไม่พูดมันออกมา
โดยเฉพาะในความสัมพันธ์ใกล้ชิดในครอบครัว มันไม่ดีต่อสุขภาพเลย เห็นมากจนรู้สึกว่าถ้าพูดจู้จี้ทั้งหมดอาจทำให้อีกฝ่ายประสาทกินได้
แต่ไม่มีใครเลยที่เป็น นักพัฒนา 10x แบบที่ก่อกองความเละเทะมหึมาไว้ให้ทีมกับผมต้องมานั่งเก็บกวาดกันเป็นเดือน ๆ
ต่อให้พยายามแค่ไหนก็ยากที่จะเชื่อมโยงกับคนส่วนใหญ่ และพวกเขาก็ยิ่งเข้าใจผมได้ยากเป็นพิเศษ ความต่างของประสบการณ์ชีวิตมันใหญ่มาก และบ่อยครั้งก็ข้ามผ่านได้ยาก
ไม่ใช่ว่านักพัฒนาทุกคนจะสร้างผลลัพธ์ได้เท่ากัน แต่ถ้าตัดสินใจที่จะคิดต่อไปให้เกินกว่าค่าเฉลี่ยทางวัฒนธรรม ใคร ๆ ก็ฉลาดขึ้นในแบบของตัวเองได้
คนส่วนใหญ่ไม่รู้ด้วยซ้ำว่าตัวเองทำแบบนั้นได้
มีสองประโยคนี้ที่โดนใจมาก
“การตามรอย data flow มันยากมากจนเหมือนมีใครกำลังพยายามปกปิดคดีฆาตกรรม”
“แค่ทำให้โค้ดรันบนโน้ตบุ๊กได้ก็ใช้เวลาไปเป็นสัปดาห์”
ผมคิดมาตลอดว่ามีแค่ผมคนเดียวที่ลำบากกับการทำความเข้าใจ data flow หรือการตั้งค่าสภาพแวดล้อมพัฒนาให้ใช้งานได้จริง Impostor syndrome และบางครั้งสภาพแวดล้อมการทำงานที่เป็นพิษซึ่งคอยเร่งเรื่อง “ความเร็ว” ก็ไม่ได้ช่วยอะไรเลย
ดีใจที่รู้ว่าไม่ได้มีแค่ผมคนเดียว
Claude Code บน CLI ช่วยให้การสตาร์ตแอปและไล่ดีบัก dependency แปลก ๆ หรือปัญหาเกี่ยวกับ Docker ง่ายขึ้นกว่าเมื่อก่อนมาก เมื่อก่อนต้องทั้งเรียนรู้สถาปัตยกรรมไปพร้อมกับแก้ปัญหาว่าทำไมมันรันบนเครื่องตัวเองไม่ได้
กับโค้ดจาก AI ยิ่งหนักเข้าไปอีก เพราะมันแค่ generate สิ่งที่ตอนนั้นดูเหมือนพอใช้ได้ออกมา
อิจฉาคนที่ได้คอยเก็บกวาดสิ่งที่คนอื่นทิ้งไว้ให้นิดหน่อย อย่างน้อยมันก็ยังเหมือนกำลังแก้ปริศนา
งานตอนนี้น่าเบื่อมาก เป็นงานง่าย ๆ ที่ระดับจูเนียร์ก็ทำได้ แต่ดันบอกว่าต้องใช้ นักพัฒนาระดับกลาง ไม่ได้หมายความว่าผมดีกว่างานนี้ หรือหมายความว่าคนระดับกลางไม่ควรทำงานแบบนี้ แค่ผมไม่สามารถบังคับตัวเองให้สนใจโค้ดที่บริษัทนี้กำลังสร้างได้เลย มันเก่า มีแต่ฝุ่น และคนสำคัญก็ไม่ได้ใช้มัน ลูกค้าใช้มันอยู่ก็เพราะเคยซื้อเครื่องมือนี้ไว้ครั้งหนึ่ง และไม่สนใจมากพอจะเปลี่ยนเพราะมันเป็นเครื่องมือที่น่าเบื่อ
ผมเคยถูกสัญญาว่างานที่เหมาะกับประสบการณ์ของผมมากกว่านี้กำลังจะมา แต่ดูจากบริษัทที่นิ่งตายแบบนี้ก็คงไม่มีลูกค้าแบบนั้นเข้ามาหรอก
ที่บริษัทนี้เสียทั้งลูกค้าและพนักงานไปมันไม่น่าแปลกใจ แต่ผมต้องผ่อนบ้าน วันนี้เพิ่งได้ยินมาด้วยว่าพวกเขาอาจไม่ต่อสัญญา ซึ่งก็แทบจะเป็นการขู่ว่าต้องรับผิดชอบมากขึ้นและทำงานมากขึ้นในเงินเดือนเท่าเดิม
น่าเสียดายที่ต้องทนไปก่อนจนกว่าจะหาที่ใหม่ที่น่าสนใจจริง ๆ ได้ ผมไม่ได้ต้องการเงินเยอะ และไม่สนใจเรื่อง “การเติบโต” เลย แค่อยากมีพอให้อยู่รอดก็พอ
คอมเมนต์นี้อาจไม่ค่อยเกี่ยวเท่าไร ขอโทษด้วย แค่ไม่มีที่ระบายเรื่องนี้ที่อื่น
ผมอยู่ระดับ L63 แต่งานที่ทำจริง ๆ เป็นระดับที่ L60~L61 ก็ทำได้บ่อยครั้ง และมักรู้สึกเหมือนตัวเองอยู่ในงานประเภท Bullshit Jobs แบบที่ David Graeber พูดถึง ค่าตอบแทนก็ดีมาก แต่พอหุ้นโบนัสตอนเข้าทำงานหมดลง ผมก็เห็นชัดว่าตัวเองอยู่ที่นั่นต่อเพราะความมั่นคงล้วน ๆ
มันให้ความรู้สึกเหมือนเป็นหนึ่งในวิศวกรที่นั่งอาบแดดรอหุ้น vesting อยู่บนระเบียงออฟฟิศ Hooli ผมทำงานมา 9 ปีแล้ว และมันดูไม่ใช่สิ่งที่ดีที่สุดสำหรับเส้นทางอาชีพของผมตอนนี้
เพียงแต่ผมไม่มีภาระทางการเงินก้อนใหญ่ การตัดสินใจเลยง่ายกว่ามาก
ผลิตภัณฑ์ขยะที่ทำโดยบริษัทขยะ อาศัยความขี้เกียจและการไร้รสนิยมของคนส่วนใหญ่ แล้วพวกนักการตลาดก็มาหาเงินจากมัน
ตอนนี้ยิ่งแย่ลงไปอีกเพราะทั้งวงการกำลังถูก ทำให้เป็น LLM จนขยายผลขึ้น 100 เท่า ทำให้โค้ดดูแลต่อไม่ได้ และที่แย่กว่านั้นคือทำให้พวกเราทุกคนโง่ลง
ผมคิดจากใจจริงเลยว่าอยากให้เราไม่เคยค้นพบสิ่งนี้มาก่อน
หมายถึงให้ทำงานล่วงเวลาและงานไร้สาระเพิ่มขึ้นเฉย ๆ หรือว่ามีโอกาสได้เขียนโค้ดมากขึ้นจริง ๆ หรือเป็นความคาดหวังแบบกะทันหันว่าต้องพิสูจน์ว่าตัวเองมีคุณค่ามากขึ้นกันแน่
ไม่ได้จะทำให้สิ่งที่คุณเจอเบาลงนะ ถ้าเป็นอย่างหลัง ผมก็สงสัยว่ามันพอจะมีอะไรที่ลงมือทำได้จริงไหม
สองสามส่วนแรกโดนใจมาก เมื่อก่อนฉันน่าจะเคยเป็น นักพัฒนาแบบร็อกสตาร์ แต่ก็ได้ตระหนักว่านั่นไม่ใช่เรื่องดี
ฉันอาจจะทำงานเสร็จได้เร็วกว่าเพื่อนร่วมงาน 10 เท่า แต่ถึงจุดหนึ่งก็พบว่านั่นไม่ใช่เพราะฉันมีประสิทธิภาพมากกว่าคนทั่วไป 10 เท่า หากแต่เป็นเพราะวิธีทำงานของฉันทำให้คนธรรมดารอบตัวมีประสิทธิภาพเหลือเพียง 1/10
หลังจากนั้นฉันก็ช้าลง และนั่นเป็นการเปลี่ยนแปลงเชิงบวกต่อชีวิตโดยรวม การเป็นทีมเพลเยอร์อาจไม่ได้ให้โอกาสก้าวหน้าในระดับเดียวกันในอุตสาหกรรมบ้าคลั่งนี้ แต่มันดีต่อสุขภาพจิตอย่างน่าทึ่ง
สำหรับฉัน มักจะเป็นการ ทำ abstraction มากเกินไป กับสิ่งที่ไม่จำเป็น หรือสร้างบางอย่างเผื่อ use case ที่ไม่มีวันเกิดขึ้นจริง ดังนั้นทุกครั้งที่ความคิดเริ่มไหลไปทาง abstraction ที่มากเกินไป ฉันจะพยายามนึกถึง YAGNI และ KISS
บทความนี้มีคุณค่าต่ำมาก
ไม่ค่อยเข้าใจด้วยซ้ำว่ากำลังจะสื่ออะไร และดูเหมือนเป็นแค่บทความตบไหล่ตัวเอง
สิ่งที่ถูกเรียกว่า โค้ดแย่จำนวนมหาศาล ที่ “นักพัฒนาแบบร็อกสตาร์” ทิ้งไว้ จำนวนมากจริง ๆ แล้วเป็นผลจากความซับซ้อนที่ค่อย ๆ สะสมขึ้นอย่างยาวนานและช้า ๆ เพื่อตอบรับการเปลี่ยนแปลงของความต้องการ
อีกอย่าง คนมักคิดว่าตัวเอง “รีแฟกเตอร์เพื่อให้อ่านง่ายขึ้น” แต่ความจริงหลายครั้งคือ “เขียนโค้ดใหม่แล้วค่อยเข้าใจมันระหว่างทาง” มากกว่า
ฉันคาดหวังว่าจะมีเนื้อหามากกว่านี้หรือมีตัวอย่างจริงอะไรบ้าง 90% ของบทความใช้ไปกับการบ่นและนิยามปัญหา แล้วค่อยโยนวิธีแก้ที่คลุมเครือเหมือนเขี่ย ๆ ไว้ในย่อหน้ารองสุดท้าย แทบไม่มีความเกี่ยวข้องหรือประโยชน์ใช้สอยจริงเลย
การไปกดดัน production engineer สองคนอย่างหนักเพื่อให้มาสร้างอินฟรารอบ ๆ โปรเจกต์ทำเงินสองตัวที่ฉันสร้างขึ้น เป็นเรื่องโง่มากจริง ๆ
ถ้าฉันทำทุกอย่างเป็นสปาเกตตีโค้ดแบบบอสสาย 10x แล้วย้ายไป Anthropic เพื่อรับแพ็กเกจค่าตอบแทน 9 หลัก ฉันคงได้เงินมากกว่านี้เยอะ โง่จริง ๆ โง่ซ้ำโง่ซ้อน
อย่างน้อยนี่ก็เป็นข้อสรุปที่ฉันได้จากที่นี่
โค้ดที่เขียนขึ้นมาส่วนใหญ่ สุดท้ายแล้วมักต้องให้คนอื่นที่ไม่ใช่ผู้เขียนเป็นคนดูแลต่อ ดังนั้นถ้าเขียนโค้ดที่ไม่มีใครเข้าใจ สุดท้ายมันก็จะนำไปสู่ ความล้มเหลวในการบำรุงรักษา
สิ่งที่ต้องการ optimize อาจต่างกันไป ไม่ว่าจะเป็นโค้ดที่ทีมเข้าใจได้ง่าย ความเร็ว หรือความเป็นเลิศทางเทคนิค
แต่ถึงจะ optimize เพื่อความเป็นเลิศทางเทคนิค ถ้าไม่มีใครคนอื่นในทีมเข้าใจโค้ดนั้นเลย มันก็ยังถือว่าล้มเหลวอยู่ดี
ฉันเคยเห็นโค้ดที่ออกแบบเกินความจำเป็นมาแล้ว
ความเห็นจาก Lobste.rs
บทความนี้แทบไม่มี คำแนะนำที่ใช้ได้จริง เลย
คำว่า “นักพัฒนาแบบร็อกสตาร์” ฟังดูน่าสงสัยเสมอ แต่ก็มีนักพัฒนาที่เก่งมากอยู่จริง เพียงแต่คนแบบนั้นไม่ได้ทำตัวอย่างที่บทความนี้บรรยาย พวกเขาจะทำงานภายใต้สภาพแวดล้อมที่มีอยู่ให้ดีที่สุด ปรับปรุง codebase ไม่เอาของใหม่ที่ยังไม่ผ่านการพิสูจน์มาใส่เล่น ๆ และเมื่อจากไปก็จะทิ้งระบบไว้ในสภาพที่มั่นคงกว่าเดิมด้วยการมีการทดสอบ การ deploy แบบสคริปต์ และ linting
ส่วน AI ในที่นี้ดูเหมือนถูกเติมเข้ามาเพื่อจะบอกว่าพฤติกรรมแบบนี้จะยิ่งแย่ลง ซึ่งอาจเป็นไปได้ แต่ก็ยังไม่ใช่ข้อเท็จจริงที่พิสูจน์ได้มากพอ ตลอดหลายสิบปีที่ทำงานเป็นที่ปรึกษาและเข้าไปจัดระเบียบ codebase ที่เละมาเยอะ สาเหตุบางครั้งก็มาจากคนที่ทำเกินเลย แต่บ่อยกว่าคือทีมที่ไม่รู้วิธีที่ดีกว่า และไม่ว่าแบบไหนก็ไม่เคยคิดเลยว่า “คงเป็นฝีมือพวกนักพัฒนาแนวร็อกสตาร์/นินจา/สายคำฮิต”
ตกลงว่าต่อจากนี้เราต้องไม่ใช่แค่เก็บกวาดขยะที่แชตบอตเทลงมาบนหัว แต่ยังต้องตามล้างตามเช็ดให้คนที่ไม่สนใจเรื่องพวกนี้ด้วยงั้นเหรอ
ทำได้แค่นั่งรอให้ ฟองสบู่แตก
ถ้าคุณเข้าบริษัทหนึ่งในปี 2026 แล้วพบว่ายังใช้ create-react-app อยู่ ผมสงสัยว่าพฤติกรรมที่แนะนำจริง ๆ คืออะไร คือต้องไม่พูดอะไรเลยหรือ?
ถ้าเป็นโปรเจ็กต์เก่า นั่นหมายความว่าคุณพบหนี้ทางเทคนิคเข้าแล้ว ซึ่งทุกที่ก็มี วิธีที่ดีที่สุดในการโน้มน้าวให้คนยอมแก้เรื่องแบบนี้คือสร้างเหตุผลทางธุรกิจที่ฟังขึ้น มันยังทำงานได้อยู่แล้วถือว่าเป็นความเสี่ยงจริงไหม? ถ้าเทียบกับหนี้ทางเทคนิคอื่น ๆ แล้วควรอยู่ลำดับไหน? ถ้าไม่อัปเกรด เรากำลังแบกรับความเสี่ยงแฝงอะไรไว้? และการอัปเกรดต้องใช้แรงมากแค่ไหน?
ถ้างานไม่มากและเพื่อนร่วมทีมก็อยากทำ บางทีก็ทำไปเลยโดยไม่ต้องขออนุญาตก็ได้ แต่จะเวิร์กที่สุดเมื่อมีคนที่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้สนับสนุน และมันไม่ไปขวางงานหลักของคุณ อาจไม่ใช่สิ่งที่ควรทำตั้งแต่สัปดาห์แรกที่เข้าทำงาน
โดยทั่วไปแล้ว การถามและทำความเข้าใจก่อนว่าทำไมตอนนี้มันถึงเป็นแบบนี้ มักดีกว่าการพูดว่า “มันควรจะเป็นอย่างนั้น” เสมอ codebase ทุกตัวที่มีประวัติ ล้วนเป็นผลลัพธ์ของการตัดสินใจนับพันที่คุณยังไม่รู้ คุณต้องมีทั้งความรู้และความเข้าอกเข้าใจ
ผมเกลียดมันมาตั้งแต่ปี 2020 ตอนที่มันยังดูเท่อยู่เลย
ประโยคที่ว่า “เอเจนต์จำไม่ได้เลยว่าเมื่อวานตัวเองทำอะไรไว้” เป็นปัญหาที่แก้ได้ ใช้วิธีพวก memory approach ก็ได้ มันอาจไม่ใช่สิ่งที่ดีแบบครอบจักรวาล แต่ก็ค่อย ๆ ดีขึ้นเรื่อย ๆ
ส่วน “มันไม่สนใจว่าโค้ดนี้จะเข้ากับส่วนอื่นของระบบได้ดีไหม” นั้นไม่ตรงกับประสบการณ์ของผม ปกติแล้ว โค้ดที่ LLM สร้าง มักมีแนวโน้มจะคล้ายกับโค้ดในส่วนที่เกี่ยวข้องพอสมควร โค้ดที่มันอ่านเพื่อจับทิศทางมักสะท้อนออกมาแทบตรง ๆ
ข้อความว่า “มันไม่สนใจว่าระบบจะเข้าใจง่ายขึ้นหรือแย่ลง” ก็แก้ได้เหมือนกัน ให้ LLM ประเมินเรื่องนี้แล้วค่อย ๆ ปรับลดลงไป อะไรที่เข้าใจง่ายนั้นมักเป็นคุณสมบัติที่ไม่เป็นเชิงกำหนดตายตัวของระบบ ดังนั้นในเชิงย้อนแย้ง LLM อาจเป็นเครื่องมือที่วัดเรื่องนี้ได้ง่ายกว่าเครื่องมืออื่น คุณสามารถเปิดเซสชันใหม่แล้วถามว่า “ถ้าจะเข้าใจโค้ดที่เพิ่งเพิ่มมานี้ ต้องเข้าใจระบบมากแค่ไหน” แล้วค่อย optimise เพื่อลดขอบเขตนั้นลง
ส่วนที่ว่า “AI มีชุดเครื่องมือแนว best practice ที่อาจไม่เหมาะกับที่นี่” นั้น ในหลายกรณีการใช้ AI ก็คล้ายกับการฝึก นักพัฒนาจูเนียร์ ที่เข้ามาในโปรเจ็กต์ใหม่พร้อมอุดมคติแบบเดียวกัน กับจูเนียร์เราจะบอกด้วยคำพูดและหวังว่าเขาจะจำความรู้นั้นไปประยุกต์ใช้ แต่กับ AI ถ้าคุณเขียนไว้ในไฟล์ AGENTS.md / CLAUDE.md ความรู้นั้นก็จะถูกเก็บไว้ต่อเนื่อง
ข้อความว่า “พอให้มันรีวิวโค้ด มันก็เสนอสิ่งที่ไม่เห็นด้วยมาเป็นพรวน” สำหรับ Codex แล้วมันถูกปรับมาให้รายการสั้น กระชับ และมีคุณค่าสูง โมเดลอื่นอาจต่างออกไป แต่ท้ายที่สุดนี่ก็เป็นเรื่องของระดับคำสั่งอยู่ดี หลายอย่างที่คุณใส่ใจมักมีค่าพอจะเขียนเป็นเอกสาร และเมื่อใช้ AI สิ่งนั้นก็ยิ่งจำเป็น
เวลาต้องรับมือกับพวกร็อกสตาร์ ปัญหาครึ่งหนึ่งคือเรื่อง อีโก้ แต่ถึงอย่างนั้น ร็อกสตาร์ที่ทิ้งโค้ดที่เขียนโดยมนุษย์ไว้ ก็ยังมีการไตร่ตรองและเจตนาอยู่เบื้องหลังโค้ดนั้น
ในทางกลับกัน “ร็อกสตาร์” ที่เป็นแค่เปลือกมนุษย์ครอบ AI ไว้ มักมีความยโสพอ ๆ กันหรือมากกว่า แต่กลับไม่เข้าใจแม้แต่ครึ่งหนึ่งของปัญหาที่ตัวเองอ้างว่ากำลังแก้อยู่
ถ้าใช้แนวทาง functional programming ให้มากที่สุด เพื่อสร้างองค์ประกอบที่ไม่ผูกกับบริบทและสามารถนำไปประกอบกันได้หลายแบบ คุณจะได้แรงทดที่สูงมาก
ถ้าแยก building block แต่ละชิ้นที่นามธรรมรายละเอียดการ implement ออก จากงานที่ขึ้นกับบริบทเฉพาะไว้ให้ชัด เวลาความต้องการเปลี่ยนหรือจะลองแนวทางอื่น ก็สามารถจัดเรียงบล็อกใหม่ได้ง่าย อีกทั้งยังใช้เหตุผลกับแต่ละชิ้นแบบแยกจากกันได้โดยไม่ต้องรู้บริบทของการประกอบทั้งหมด และเมื่อดูว่าชิ้นเหล่านั้นประกอบเข้าหากันอย่างไร ก็จะเข้าใจตรรกะระดับบนได้
ภาษาเชิงฟังก์ชันเป็นฐานที่ดีสำหรับ การทำงานร่วมกับ LLM เพราะมันทำให้คุณเขียนโค้ดในลักษณะที่จำกัดบริบทได้อย่างเป็นธรรมชาติ ซึ่งช่วยลดขอบเขตที่ต้องเข้าใจเพื่อทำความเข้าใจความสามารถเฉพาะอย่างของโปรแกรม เป็นประโยชน์ทั้งต่อโมเดลและผู้ใช้ที่เป็นมนุษย์