การเขียนโค้ดไม่เคยเป็นคอขวดเลย
(ordep.dev)- ในการพัฒนาซอฟต์แวร์ คอขวด ไม่ได้อยู่ที่การเขียนโค้ด แต่เกิดจากกระบวนการที่มีมนุษย์เป็นศูนย์กลางหลายอย่าง เช่น การรีวิวโค้ด, การถ่ายทอดความรู้, การทดสอบ, การดีบัก, การทำงานร่วมกัน/การสื่อสาร
- ด้วย LLM การสร้างโค้ดเองกลายเป็นเรื่องง่ายมาก แต่ในทางกลับกัน ต้นทุนและภาระด้าน ความเข้าใจ, การตรวจสอบ, ความน่าเชื่อถือ กลับยิ่งสูงขึ้น
- การสร้างโค้ดได้อย่างรวดเร็วทำให้ ภาระเพิ่มขึ้น กับผู้รีวิว ผู้รวมระบบ และผู้ดูแลรักษา และไม่ได้ทำให้ความเร็วของทั้งทีมเพิ่มขึ้นจริง
- การทำความเข้าใจโค้ด คือส่วนที่ยากที่สุด และต่อให้ LLM สร้างโค้ดได้ หากไม่มี ความเชื่อใจและการแบ่งปันบริบท ภายในทีม ก็ไม่อาจรับประกันคุณภาพได้
- LLM ทรงพลังมากสำหรับการทำต้นแบบ การทำ automation และ scaffold แต่ไม่อาจแทนที่พื้นฐานของการพัฒนาซอฟต์แวร์อย่าง การออกแบบอย่างรอบคอบ, การรีวิว, การแบ่งปันบริบท ได้
คอขวดที่แท้จริงของการเขียนโค้ด
- ตลอดหลายปีที่ผ่านมา การเขียนโค้ด เองไม่ใช่ คอขวด ของวิศวกรรมซอฟต์แวร์
- คอขวดที่แท้จริงเกิดจาก การรีวิวโค้ด, การเมนทอร์ และ การถ่ายทอดความรู้ผ่าน pair programming, การทดสอบ, การดีบัก, และ ต้นทุนของการทำงานร่วมกันและการสื่อสาร
- การจัดการทิกเก็ต การประชุมวางแผน การประชุมแบบ agile และขั้นตอนที่ซับซ้อนต่าง ๆ ทำให้ความเร็วช้าลงอีก
- กระบวนการเหล่านี้ที่ใช้เพื่อรับประกันคุณภาพ แท้จริงแล้วต้องใช้เวลาและการคิดมากกว่าการเขียนโค้ดเองอย่างมาก
- แต่ด้วย LLM ต้นทุนของการสร้างโค้ดที่ทำงานได้กำลัง เข้าใกล้ศูนย์
- อย่างไรก็ตาม ต้นทุนในการ ทำความเข้าใจ, ทดสอบ, และสร้างความเชื่อมั่นในโค้ด กลับสูงขึ้น
- แม้ความเร็วของการลงมือทำในช่วงแรกจะเพิ่มขึ้น แต่ก็ทำให้มี โค้ดจำนวนมากขึ้นที่ต้องถูกรีวิว/รวมเข้าระบบ/บำรุงรักษา และเพิ่มภาระตามมา
LLM เปลี่ยนธรรมชาติของงาน แต่ไม่ได้กำจัดมัน
- เครื่องมือ LLM อย่าง Claude ช่วยเร่งความเร็วในการทำ implementation ช่วงแรก แต่สุดท้ายเมื่อมีโค้ดไหลเข้าสู่ระบบมากขึ้นในเวลาที่สั้นลง ก็ยิ่งเพิ่มภาระให้ผู้รับผิดชอบด้าน การรีวิว และ การบำรุงรักษา
- ภาระนี้รุนแรงขึ้นเป็นพิเศษในสถานการณ์ต่อไปนี้
- ไม่แน่ชัดว่าผู้เขียนเข้าใจโค้ดที่ตัวเองส่งเข้ามาอย่างเพียงพอหรือไม่
- โค้ดที่ถูกสร้างขึ้นใช้แพตเทิร์นที่ไม่คุ้นเคย หรือขัดกับคอนเวนชันเดิม
- เงื่อนไขขอบเขตและผลข้างเคียงที่ไม่ตั้งใจไม่ได้แสดงออกมาอย่างชัดเจน
- ด้วยเหตุนี้ แม้การผลิตโค้ดจะง่ายขึ้น แต่ความยากของการตรวจสอบกลับสูงขึ้น และสุดท้ายก็ไม่ได้ทำให้ความเร็วของทั้งทีมเพิ่มขึ้น
- เดิมทีในหมู่นักพัฒนามีมุกเรื่อง “copy-paste engineering” กันอยู่แล้ว แต่เมื่อมี LLM ปรากฏการณ์นี้ก็ยิ่งทวีความรุนแรงขึ้นมาก
สิ่งที่ยากจริง ๆ คือการเข้าใจโค้ด
> “ต้นทุนที่มากที่สุดของโค้ดไม่ใช่การเขียน แต่คือการทำความเข้าใจ”
- แม้ LLM จะช่วยให้การผลิตโค้ดเร็วขึ้น แต่การ อนุมานพฤติกรรมการทำงาน, ค้นหาบั๊กที่ละเอียดซับซ้อน, หรือ รับประกันการบำรุงรักษาในระยะยาว ก็ไม่ได้ง่ายขึ้นเลย
- ยิ่งยากขึ้นโดยเฉพาะเมื่อผู้รีวิวแยกไม่ออกว่าโค้ดส่วนไหนถูกสร้างขึ้นและส่วนไหนเขียนเอง หรือยากที่จะเข้าใจเหตุผลของแนวทางแก้ปัญหาที่ถูกเลือก
ทีมยังคงพึ่งพาความเชื่อใจและบริบทที่แบ่งปันร่วมกัน
- การพัฒนาซอฟต์แวร์มีพื้นฐานอยู่บน การทำงานร่วมกัน และพึ่งพา ความเข้าใจร่วมกัน, alignment, และ การเมนทอร์ อย่างเต็มที่
- เมื่อโค้ดถูกสร้างเร็วเกินกว่าความเร็วในการพูดคุยและรีวิว ทีมอาจ เข้าใจผิดว่าคุณภาพได้รับการตรวจสอบแล้ว ทั้งที่ในความเป็นจริงยังไม่ได้ยืนยันคุณภาพอย่างแท้จริง
- ส่งผลให้ภาระทางจิตใจของ ผู้รีวิว และ เมนทอร์ เพิ่มขึ้น และทำให้ความเร็วของทั้งทีมช้าลงในรูปแบบใหม่
LLM ทรงพลัง แต่ยังแก้แก่นของปัญหาไม่ได้
- LLM มีคุณค่าสูงสำหรับ prototyping, scaffold, และ automation อย่างรวดเร็ว แต่ไม่ได้ลบความจำเป็นของ การคิดอย่างชัดเจน, การรีวิวอย่างรอบคอบ, และ การออกแบบอย่างลึกซึ้ง ออกไป
- แม้ต้นทุนของการเขียนโค้ดจะลดลง แต่ต้นทุนที่ทีมต้อง เข้าใจโค้ดร่วมกัน และ มอบความหมายให้กับมัน ไม่ได้เปลี่ยนแปลง
- คอขวดที่แท้จริงยังคงอยู่ที่ "ความเข้าใจและการทำงานร่วมกัน"
7 ความคิดเห็น
ผมเป็นนักพัฒนาที่ขาดทักษะตามที่บทความนี้พูดถึงพอดี และพึ่งพา LLM อย่างมาก
เพราะความรู้ทางเทคนิคยังไม่มาก เลยอยู่ในสถานการณ์ที่ถ้าไม่มี AI ก็ทำงานตาม WBS ได้ยาก..
อย่างน้อยเพื่อช่วยลดเวลารีวิวของรุ่นพี่นักพัฒนา ผมควรทำอะไรดีบ้างครับ..?
แถมถ้าจะช่วยให้ผมได้สะสมความรู้ไปด้วยก็คงดีครับ..
ถ้าต้องการลดเวลาในการรีวิว คุณต้องเป็นคนตัดสินใจเองและอธิบายได้ว่าโค้ดที่คุณเขียนมีที่มาจากบริบทแบบไหน และในบรรดาวิธีการพัฒนาที่หลากหลายทำไมถึงเลือกวิธีนั้น ดังนั้นคุณควรทำข้อ 3 อย่างสม่ำเสมอไม่ว่าจะเป็นช่วงสุดสัปดาห์หรือเวลาว่าง และลองสุ่มดูไลบรารีดัง ๆ หรือโค้ดที่คนอื่นอัปไว้บน GitHub พร้อมวิเคราะห์สิ่งอย่างโครงสร้างโค้ดและสไตล์การพัฒนาก็น่าจะดีครับ
ขอบคุณมากสำหรับคำพูดดี ๆ ครับ!!
แต่พอเห็นว่าลดคนอยู่ก็ยิ่งหมดหวัง.. จะให้คน 4 คนทำโปรเจ็กต์ 12 อันได้ยังไง.. แถมในนั้นยังมีคนหนึ่งต้องคอยบริหารจัดการอีก..
โอ๊ย คงลำบากมากเลยนะครับ/คะ
ความคิดเห็นจาก Hacker News
ในฐานะเมนเทอร์ที่มีประสบการณ์ ผู้แสดงความคิดเห็นเล่าว่าเคยดูแลเด็กฝึกงานที่มีความทะเยอทะยานแต่ยังไม่ชำนาญ ซึ่งสามารถปั่นโค้ดได้ในหนึ่งวันเท่ากับงานหนึ่งสัปดาห์หรือสองสัปดาห์ แต่กลับทำให้งานของเขายากกว่าเดิมเสียอีก ตอนรีวิวโค้ด เด็กฝึกงานเหล่านี้มักไม่ได้คิดลึกพอเกี่ยวกับโค้ดที่ตัวเองเขียน ทำให้รับฟีดแบ็กได้ไม่ดี ปัญหาเล็ก ๆ หรือบั๊กง่าย ๆ แทบหายไปหมดแล้ว แต่ปัญหาที่เหลือกลับละเอียดอ่อน ซับซ้อน และอธิบายยากกว่ามาก แถมยังมีบั๊กรูปแบบใหม่ ๆ ที่ไม่เคยเห็นมาก่อนด้วย บางครั้งโค้ดดูเหมือนปกติดี แต่จริง ๆ แล้วใช้งานไม่ได้เลย หรือดูเหมือนเสร็จสมบูรณ์แต่พื้นฐานกลับพังตั้งแต่ต้น เด็กรุ่นใหม่ที่ทำงานร่วมกับ LLM มีแนวโน้มจะส่งโค้ดซับซ้อนที่ดูเหมือนเสร็จแล้วในทีเดียว ซึ่งสร้างปัญหาต่อการทำงานร่วมกันและการบำรุงรักษา มากกว่าจะส่งโค้ดง่าย ๆ ที่ยังพอถกเถียงและปรับปรุงกันได้ ผลคือแนวทาง “ค่อย ๆ ปรับปรุง” แบบดั้งเดิมในการขัดเกลา PR หนึ่งอันไปจนถึงคุณภาพสุดท้ายเริ่มใช้ไม่ค่อยได้ผล เมื่อให้ฟีดแบ็ก พวกเขามักเสนอแนวทางใหม่ทั้งชุดแทนการแก้ PR เดิม—ซึ่งก็มักก่อปัญหาใหม่อีก ทำให้สุดท้ายฝั่งซีเนียร์ต้องใช้เวลากับ PR นี้มากกว่าฝั่งจูเนียร์เสียอีก ฝั่งจูเนียร์อาจรู้สึกว่าตัวเอง productive มาก แต่บรรยากาศฟีดแบ็กจากรีวิวเวอร์ซีเนียร์ก็เริ่มไม่อบอุ่นหรือให้กำลังใจเหมือนเดิม ในที่สุดสิ่งที่พอช่วยได้บ้างคือการบังคับให้มี test case จำนวนมาก แต่แม้แต่เทสต์เหล่านี้ก็เริ่มชนข้อจำกัดจากปัญหาคล้ายกัน
พอเห็นโค้ดแบบ “ดูเหมือนเสร็จดีแต่ใช้งานไม่ได้เลย” ก็ทำให้นึกถึงโปรเจกต์พัฒนาซอฟต์แวร์ต่างประเทศมูลค่า 250,000 ดอลลาร์ที่เคยเจอมาก่อน ตอนอ่านสเปกเหมือนทุกอย่างถูกต้องหมด แต่ของจริงกลับเป็นระบบที่ไม่สอดคล้องกันเลย เพราะมัวแต่ยึดติดกับการตีความสเปกจนพลาดเรื่องสามัญสำนึก สุดท้ายต้องทิ้งทั้งโปรเจกต์ทันที น่าประทับใจตรงที่ตอนนี้เรื่องแบบนี้กำลังถูกทำให้เป็นอัตโนมัติและฟรีด้วย LLM
เห็นด้วยกับปัญหานี้เต็มที่ จากประสบการณ์ส่วนตัว เวลานำ LLM มาใช้ แม้จะสร้างโค้ดได้หลายพันบรรทัดอย่างรวดเร็ว แต่ของที่ยากจริง ๆ คือการรีวิวโค้ด แก้บั๊ก ตรวจช่องโหว่ความปลอดภัย รีแฟกเตอร์ และลบโค้ดที่ไม่จำเป็น สุดท้ายหลายครั้งการเขียนเองกลับ productive กว่า การใช้ LLM อย่างสมจริงที่สุดคือใช้กับ autocomplete หรือสร้างชิ้นส่วนเล็ก ๆ เท่านั้น ถ้าจูเนียร์ต้องคั่นกลางด้วย LLM แล้วฉันยังต้องส่งต่ออีกทอด ประสิทธิภาพก็น่าจะยิ่งแย่ลง คนที่ตอนนี้รู้สึกว่า LLM ทำให้ตัวเอง productive ขึ้น อาจเป็นเพราะข้ามงานสำคัญเหล่านี้ไปเลยหรือไม่ก็ไม่ได้ใส่ใจมันตั้งแต่แรก ผลคือคนส่วนน้อยที่สนใจคุณภาพของผลิตภัณฑ์จริง ๆ ต้องเป็นฝ่ายแบกรับปริมาณโค้ดมหาศาล คนพวกนี้อาจถูกเข้าใจผิดว่าเรื่องมากเกินเหตุ แต่จริง ๆ แล้วพวกเขาคือตัวจริงที่พยายามส่งมอบผลิตภัณฑ์ที่ดีที่สุดให้ผู้ใช้ ไม่ค่อยเห็นทางแก้ชัดเจน และดูเหมือนสถานการณ์จะยิ่งแย่ลง เพราะนักพัฒนาที่ถูกฝึกด้วย LLM อย่างเดียวจะไหลเข้าสู่อุตสาหกรรมต่อไป ขณะที่บริษัทผู้สร้างเครื่องมือก็ยังทำการตลาดเกินจริงอย่างต่อเนื่อง สุดท้ายภาระในการรักษาคุณภาพก็มีแต่จะเพิ่มขึ้น
ฉันเองก็เจอปรากฏการณ์ 'effort inversion' แบบที่ซีเนียร์ต้องลงแรงกับ PR หนึ่งอันมากกว่าจูเนียร์ ในกรณีของฉัน คนเขียน PR ใช้ AI ช่วยเขียนบทความบล็อกหรือข่าวประชาสัมพันธ์ แต่เมื่อผู้เชี่ยวชาญเฉพาะทางอย่างฉันได้รับงานนั้น กลับต้องเสียเวลามากขึ้น 3–4 เท่าเพื่อไล่แก้ภาพหลอนและข้อผิดพลาดของ AI เดิมทีงานของพวกเขาควรช่วยซัพพอร์ตฉัน แต่ตอนนี้กลายเป็นว่าฉันต้องไปช่วยพวกเขา แถมภาพหลอนของ AI ก็ไม่ซ้ำเดิม ต้องมานั่งแก้ใหม่ทุกครั้ง ฉันแจ้งผู้บริหารเรื่องนี้ไปแล้ว และถ้ายังเป็นแบบนี้ต่อไป ฝ่าย PR น่าจะหายไปครึ่งหนึ่งในปีหน้า ถ้างานมีแค่ก็อปปี้อีเมลไปวางใน ChatGPT แล้วส่งกลับมาหาฉัน ฉันทำเองก็ได้
อยากฟังรายละเอียดเพิ่มเติมเกี่ยวกับประโยคที่ว่า “ฟีดแบ็กที่ฉันให้ระหว่างรีวิวส่งไปไม่ถึง” เพราะฉันกำลังเจอปัญหาคล้ายกันอยู่ ถ้ามีวิธีแก้หรือข้อสังเกตอะไร อยากให้ช่วยแชร์
ถ้าจะเสริมจากมุมฉัน รุ่นก่อน ๆ ได้สร้างความเข้าใจเชิงลึกเกี่ยวกับโครงสร้างและการออกแบบซอฟต์แวร์อย่างเป็นธรรมชาติผ่านการรีแฟกเตอร์และการเขียนยูนิตเทสต์ แต่ถ้าต่อไป LLM สร้างแม้กระทั่งยูนิตเทสต์ให้อีก นักพัฒนาอาจสูญเสียโอกาสในการทบทวนตัวเองและเรียนรู้แบบ “ฉันต้องการอะไร” หรือ “จะทำให้สิ่งนี้ง่ายกว่านี้ได้อย่างไร” ความต่างระหว่างสิ่งที่ฉันมองว่าเป็น 'developer', 'engineer' และ 'architect' อยู่ตรงนี้เอง LLM หรือ 'vibe coding' ไม่มีทางปลูกฝังชุดความคิดแบบนั้นได้ ในภาษาอย่าง Go ที่ภาระด้านไวยากรณ์ต่ำ ความผิดพลาดด้านการออกแบบแบบนี้มักโผล่ให้เห็นในรีวิวได้ง่ายกว่า และโครงสร้างยูนิตเทสต์ของ Go ก็มีประโยชน์ในการวินิจฉัยความซับซ้อนของโค้ด สุดท้ายแล้วเราต้องการวิธีทดสอบ/รีวิวที่ดีกว่านี้ แค่ fuzz testing, unit test และ integration test ยังไม่พอ ฉันคิดว่าเราต้องมี automated test framework ที่ช่วยยืนยันเชิงตรรกะได้ว่ากิ่งของโค้ดถูกเรียกใช้อย่างถูกต้องและเงื่อนไขความพึงพอใจถูกทำให้เป็นจริง
แม้ LLM จะทำให้ต้นทุนการเริ่มต้นนำซอฟต์แวร์ใหม่มาใช้ลดลงจนเกือบเป็นศูนย์ แต่ต้นทุนในการทำความเข้าใจ ทดสอบ และเชื่อถือโค้ดนั้นอย่างลึกซึ้งกลับรู้สึกว่าสูงกว่าที่เคยเป็นมา อย่างไรก็ตาม จากประสบการณ์ของฉัน โค้ดที่ LLM สร้างก็ไม่ได้แย่กว่ากองโค้ดเก่ามากมายที่คนเขียนลาออกไปแล้วจนถามอะไรไม่ได้ หรือโค้ดที่ลอยอยู่ตามอินเทอร์เน็ตเท่าไรนัก ตรงกันข้าม LLM ไม่ได้ขี้เกียจเขียนเทสต์เหมือนมนุษย์ และไม่ปล่อยผ่านเพราะเหนื่อยด้วย ปรัชญาของฉันเริ่มจากสมมติฐานว่า ‘โค้ดทุกชิ้นคือหนี้ที่อาจเกิดขึ้นได้’ ดังนั้นจึงไม่ได้กังวลเรื่องความน่าเชื่อถือของโค้ดมากนัก ฉันเคยสร้าง codebase ขนาดใหญ่ด้วย AI และทำให้มันทำงานได้จริง—แต่ทำได้เฉพาะเมื่อโดเมนตรวจสอบได้ และมีการทดสอบกับการวนซ้ำจำนวนมาก สรุปคือ LLM ทำให้การผลิตโค้ดเร็วขึ้น แต่ตัวงานเขียนโค้ดเองกลับให้ความกระตุ้นทางปัญญาน้อยลง จนรู้สึกเหมือนสมองตัวเองเฉื่อยตามไปด้วย ยุคนี้จึงยิ่งทำให้งานคิดส่วนต้นน้ำอย่างการนิยาม requirement และการออกแบบสำคัญขึ้นมาก
แม้ไม่มี LLM เดิมทีอุตสาหกรรมก็ไม่ได้ติดคอขวดที่ “โค้ดไม่พอ” อยู่แล้ว แต่ติดข้อจำกัดด้านความต้องการของตลาดและข้อจำกัดด้านทุนที่ทำให้ความเร็วในการพัฒนามีเพดาน เครื่องมือดีขึ้นมากจนการเขียนโค้ดเองไม่ใช่แกนหลักอีกต่อไป สภาพแวดล้อมวันนี้ต่างจากยุคแรกเริ่มโดยสิ้นเชิง ทำให้นึกถึงเกร็ดสมัย Bill Gates ยังเป็นวัยรุ่น ที่แค่ “เขียนโค้ดได้” ก็เป็นทรัพยากรหายาก บริษัทหนึ่งรีบจ้าง Gates วัย 16 ปีและ Paul Allen แล้วทึ่งเพียงเพราะทั้งคู่เขียนโค้ดได้เร็ว ทุกวันนี้คำถามสำคัญกว่าคือ “จะสร้างอะไร และมันมี business model รองรับไหม?”
วิดีโอที่เกี่ยวข้อง
เห็นด้วยกับข้อเสนอที่ว่าการเขียนโค้ดไม่ใช่คอขวดเพราะข้อจำกัดจริงอยู่ที่ demand ของตลาด ก่อนยุค AI boom นั้น Marc Andreessen ก็เคยพูดว่า “มีทุนล้นเหลือ แต่ไอเดียดี ๆ สำหรับลงทุนมีไม่พอ” ฉันเองไม่ได้คิดว่าคำพูดนั้นสะท้อนความจริงทั้งหมด แต่ในเชิงข้อมูลอย่างน้อยก็ดูมีน้ำหนัก
เหมือนเกร็ดเก่าของ Bill Gates ความสามารถในการเขียนโค้ดคุณภาพสูงและเข้าใจมันอย่างลึกซึ้งก็ยังเป็นทรัพยากรหายากอยู่ เพียงแต่สิ่งที่ต่างจากอดีตคือบรรยากาศในอุตสาหกรรมดูจะไม่ให้คุณค่ากับความสามารถนั้นมากนัก
ถ้ามองจากมุมวิเคราะห์ผลกระทบของ AI เรามักมั่นใจในประสิทธิภาพมากเกินไป แต่เศรษฐกิจจริงมีโครงสร้างคอขวดที่ซับซ้อนกว่านั้นมาก ต่อให้ปริมาณโค้ดเพิ่มขึ้น 100 เท่า ก็ยังไม่ชัดว่าจะกลายเป็นสิ่งที่มีประโยชน์จริงหรือไม่
ทุกวันนี้เวลาอ่านประสบการณ์ของใครสักคน มันชวนหดหู่เกินไป ถ้าจูเนียร์ส่งก้อนโค้ดมหึมาที่ใช้งานไม่ได้ ไม่ได้ทดสอบ/ตรวจสอบเอง ไม่ได้กลั่นให้กระชับ และไม่มีเอกสาร คอมเมนต์ หรือคำอธิบายใด ๆ แถมมอบต่อมาให้ นั่นก็คือ “LLM เวอร์ชันติดตั้งในมนุษย์” อยู่แล้ว สุดท้ายสิ่งสำคัญคือการคิดเชิงวิพากษ์และความรับผิดชอบต่อผลลัพธ์ ที่จริงฉันยังคิดว่า LLM อาจตอบสนองต่อฟีดแบ็กได้ดีกว่าจูเนียร์ซอฟต์แวร์เอนจิเนียร์แบบเดิมเสียอีก
ฉันเองก็เคยคิดว่าการเขียนโค้ดคือคอขวด แต่หลังจากทำงานมา 10 ปี ก็พบว่าสิ่งที่ยากจริง ๆ คือการทำให้เทคโนโลยีสอดคล้องกับธุรกิจ แม้อยู่ในสภาพแวดล้อมแบบ B2B หรือ SaaS ที่ต้องรับมือกับกองโค้ดซับซ้อนซึ่งแตกต่างกันไปตามลูกค้า ถ้าเทคโนโลยีสอดคล้องกับธุรกิจอย่างถูกต้อง ทุกอย่างก็จะไหลลื่น ทุกวันนี้เทคโนโลยีพัฒนาไปไกลพอแล้ว ดังนั้นประเด็นสำคัญจริง ๆ คือ 'ego' ของนักพัฒนาและท่าทีที่มุ่งไปที่คุณค่าของลูกค้า ต้องคิดว่าลูกค้าต้องการอะไรจริง ๆ พวกเขาจะยอมจ่ายเงินให้หรือไม่ หรือจริง ๆ แล้วจำเป็นต้องมีเว็บอินเทอร์เฟซด้วยหรือเปล่า ฟีเจอร์แบบ “ของเล่นแมว” ที่นักพัฒนาสร้างเพื่อความพอใจของตัวเองต่างหากที่เป็นสาเหตุแท้จริงของค่าใช้จ่ายคลาวด์ที่เพิ่มขึ้น ที่น่าเศร้ายิ่งกว่าคือ ต่อให้โยน incentive รุนแรง ๆ, stock option หรือเงินเดือนสูง ๆ เข้าไป ก็แก้ปัญหาแก่นนี้ไม่ได้ ต้องมีใครสักคนที่มี 'mission' อยากสร้างซอฟต์แวร์ให้ดีจริง ๆ และอย่างน้อยต้องมีสักคนที่ยินดีคุยกับลูกค้าโดยตรงและตั้งใจทำให้ถูกต้อง
ช่วงเวลาที่ LLM ช่วยได้จริงในองค์กร สำหรับฉันกลับเป็นโปรเจกต์ส่วนตัวหรือโปรเจกต์ข้าง เวลาพัฒนาแอปเพื่อแก้ปัญหาเล็ก ๆ มักมีเวลาน้อยจนการเขียนโค้ดกลายเป็นคอขวดจริง ๆ สำหรับโปรเจกต์แบบนี้ การใช้ LLM มีประโยชน์ 100%
เห็นด้วยเต็มร้อยเหมือนกัน ถ้าลงเวลาให้ Claude code วันละ 1–2 ชั่วโมง พอถึงช่วงสุดสัปดาห์ก็จะมีผลลัพธ์ที่ใช้งานได้จริงออกมาชิ้นหนึ่ง ทำให้การพิสูจน์ไอเดียหรือทดลองอะไรใหม่ ๆ ง่ายขึ้นมากด้วยเวลาลงทุนเพียงน้อยนิด ฉันคิดว่าเครื่องมือ LLM แบบนี้ก็สร้างคุณค่าอย่างมหาศาลในองค์กรมืออาชีพได้เหมือนกัน ทั้งเครื่องมือดูแลงานและระบบอัตโนมัติต่าง ๆ ที่ปกติไม่มีเวลาสร้าง ก็สามารถทำต้นแบบได้เร็วมาก ถ้าเพื่อนร่วมงานต้องการ query ฐานข้อมูลหรือ automation ง่าย ๆ ก็แค่ถาม Claude แล้วรีวิวก่อนคัดลอกไปใช้ได้ทันที การช่วยให้คนที่ไม่ใช่วิศวกรสามารถจัดการงานซ้ำ ๆ ในขอบเขตของตัวเองได้ก็คือเป้าหมายของโปรเจกต์ mcp-front[0] ของฉันเช่นกัน
GitHub ของ mcp-front
พูดตามตรง ด้วยจังหวะอาชีพของฉันตอนนี้ การทุ่มเวลาเป็นสัปดาห์ทำได้ยาก และจากประสบการณ์ยาวนานก็ทำให้ต้องคำนึงถึง non-functional requirements และมุมมองระยะยาวอยู่ตลอด แม้จะข้ามเรื่องอย่างการทดสอบไป สุดท้ายก็ยังมีเรื่องให้คิดต่ออีกมาก
ทำให้นึกถึงคำกล่าวของ Robert C. Martin ที่ว่า “เวลาอ่านโค้ดมีมากกว่าเวลาเขียนโค้ดเกิน 10 เท่า”
คำคมที่เกี่ยวข้อง
น่าเสียดายที่สไตล์ clean code ของเขาเอง ในทางปฏิบัติบางครั้งกลับทำให้บริบทแตกเป็นชิ้น ๆ จนยิ่งจับเจตนาได้ยากขึ้น
ที่แย่กว่านั้นคือ มันอาจลดเวลาเขียน แต่เพิ่มเวลาอ่าน จนภาระงานโดยรวมไม่ได้ลดลงเลย
ขอนำเสนอบทความของ Joel Spolsky เมื่อวันที่ 2 ตุลาคม 2000 ที่ยังไม่มีใครพูดถึง
Joel on Software: Painless Functional Specifications (2000)
คอขวดที่แท้จริงไม่ใช่โค้ด แต่คือสเปกของฟีเจอร์ ซอฟต์แวร์ควรทำงานอย่างไรนั้นจำเป็นต้องนิยามให้ชัดเจนด้วยภาษาอังกฤษ ไดอะแกรม user story ฯลฯ หากสเปกแน่นพอ LLM ก็สามารถสร้างโซลูชัน เทสต์ และ integration test ที่ยอดเยี่ยมได้ในคราวเดียว ถ้าขนาดใหญ่เกินไป ก็ควรเลิกเก็บสเปกไว้ในไฟล์ Markdown เดียว แล้วแยกแบบวิกิตามฟีเจอร์พร้อมลิงก์และการอ้างอิง ความสามารถในการแข่งขันที่แท้จริงไม่ได้อยู่ที่ความยากของการ implement แต่อยู่ที่การลงแรงกับสเปกมากแค่ไหน
ผู้แสดงความคิดเห็นไม่เห็นด้วยกับผู้เขียน จากมุมของบริษัทใหญ่ โค้ดอาจไม่ใช่คอขวด แต่สำหรับสตาร์ตอัปที่ทรัพยากรจำกัด การวางแผนอย่างมีประสิทธิภาพสำคัญกว่า นั่นคือ ในหลายกรณีงานสร้างโค้ดที่ทำงานได้จริงอย่างถูกต้องต่างหากคือคอขวดที่ใหญ่ที่สุด สุดท้ายแล้วการจะสรุปกว้าง ๆ ว่า “AI/LLM มีประโยชน์แค่ไหน” นั้นทำไม่ได้ สำหรับบางทีม โค้ดคือคอขวด แต่สำหรับบางทีมก็ไม่ใช่
อย่างที่ทุกคนรู้กัน โค้ดที่ LLM สร้างมักเละเทะและรีวิวแทบไม่ได้ พอถามจูเนียร์ที่ส่งโค้ด LLM มาแบบประหลาดว่าเพราะอะไร เจ้าตัวก็ตอบไม่ได้ ได้แต่บอกว่า LLM เป็นคนทำ สุดท้ายแนวโน้มนี้มีแต่จะเพิ่ม ‘noise’ และ ‘overhead’ ให้การบำรุงรักษาโค้ด ถ้าหลีกเลี่ยงการใช้ LLM ไม่ได้ ก็อาจต้องโยนงานรีวิวและบำรุงรักษาให้ LLM ด้วยเช่นกัน แน่นอนว่าผลลัพธ์คงเป็นสปาเกตตีที่ซับซ้อนยิ่งกว่าเดิม แต่ในโลกความจริง สำหรับธุรกิจส่วนใหญ่คุณภาพมักไม่ได้สำคัญขนาดนั้น ถ้าโค้ดจาก LLM พอใช้งานได้คร่าว ๆ พวกเขาก็พอใจแล้ว หรือไม่ก็แค่ค่อย ๆ เอา LLM มาแปะเพิ่มจนสุดท้ายมันแก้ปัญหาได้ตามต้องการก็พอ