เอเจนต์ AI สำหรับเขียนโค้ดต้องลดต้นทุนการบำรุงรักษาได้
(jamesshore.com)- ความเร็วในการเขียนโค้ดใหม่ไม่สำคัญต่อผลิตภาพระยะยาวเท่ากับ ต้นทุนการบำรุงรักษา
- ในโมเดลตัวอย่าง หลังผ่านไป 2 ปีครึ่ง เวลาที่ใช้บำรุงรักษาจะเกินครึ่งของเวลาทั้งหมด
- หากเอเจนต์ AI เพิ่มทั้งปริมาณงานที่สร้างได้และต้นทุนการบำรุงรักษา ผลลัพธ์ที่ได้จะหายไปอย่างรวดเร็ว
- ต่อให้หยุดใช้เอเจนต์แล้ว ต้นทุนการบำรุงรักษาเพิ่มเติม ของโค้ดที่สร้างไปแล้วก็ยังคงอยู่
- ถ้าปริมาณงานเพิ่มเป็นสองเท่า ต้นทุนการบำรุงรักษาต่อโค้ดก็ต้องลดลง ครึ่งหนึ่ง
ต้นทุนการบำรุงรักษาเป็นตัวกำหนดผลิตภาพ
- ทุกเวลาที่ใช้เขียนโค้ด จะก่อให้เกิดเวลาบำรุงรักษาต่อเนื่องในภายหลัง เช่น การแก้บั๊ก, การจัดระเบียบโค้ด และการอัปเกรด dependency
- ที่นี่พิจารณาเฉพาะงานบำรุงรักษาที่ต้องทำซ้ำทุกปีตราบใดที่โค้ดยังมีอยู่ ไม่รวมการเพิ่มฟีเจอร์ใหม่หรือการปรับปรุงอื่น ๆ
- การประมาณตัวอย่างนี้ตั้งสมมติฐานว่า ทุกการเขียนโค้ด 1 เดือน จะมีเวลาบำรุงรักษา 10 วัน ในปีแรก และ 5 วัน ในทุกปีถัดไป
- มองว่า หากใช้วิธี Wisdom of the Crowd ไปถามนักพัฒนาราว 50 คนเรื่องต้นทุนการบำรุงรักษา ก็อาจได้คำตอบที่ค่อนข้างแม่นยำ
- ตาม โมเดลสเปรดชีต ที่สร้างจากสมมติฐานนี้ ช่วงต้นของโปรเจกต์ใหม่ เวลาส่วนใหญ่จะถูกใช้ไปกับการพัฒนาฟีเจอร์ แต่เมื่อเวลาผ่านไป สัดส่วนเวลาที่ใช้บำรุงรักษาโค้ดเก่าจะเพิ่มขึ้นเรื่อย ๆ
- ในค่าประมาณนี้ หลังผ่านไป 2 ปีครึ่ง เวลาที่ใช้กับการบำรุงรักษาจะเกินครึ่งของเวลาทั้งหมด และหลัง 10 ปี ก็แทบจะยากมากที่จะทำงานอย่างอื่นได้
- หากลดค่าประมาณการบำรุงรักษาลงครึ่งหนึ่ง จะยืดเวลาจนถึงจุด 50% ออกไปได้อีก 3 ปี แต่ถ้าเพิ่มเป็นสองเท่า ผลิตภาพจะตกต่ำกว่า 50% ภายในไม่ถึง 1 ปี
- ถ้าต้องการทีมที่มีผลิตภาพ ควรโฟกัสที่ ต้นทุนการบำรุงรักษา มากกว่าความเร็วในการเขียนโค้ดใหม่
โมเดลอาจไม่แม่นทั้งหมด แต่ทิศทางนั้นถูกต้อง
- ในสตาร์ตอัปช่วงปลาย มักพบปัญหาว่าหลังผ่านไปประมาณ 5~9 ปี ทีมเริ่มทำงานให้เสร็จอย่างมีประสิทธิภาพไม่ได้อีก ซึ่งมีรูปแบบคล้ายกับกราฟนี้
- เหตุผลที่ทีมจริงอาจไม่ได้ดูแย่เท่ากราฟ อาจเป็นเพราะต้นทุนการบำรุงรักษาต่ำกว่า หรือเพราะใช้วิธีอื่นกลบปัญหาไว้
- วิธีรับมือที่เป็นไปได้ ได้แก่ ไม่แก้ทุกบั๊ก ไม่อัปเกรดทุก dependency, เพิ่มคนเมื่อทีมเริ่มช้าลงแล้วก็เพิ่มต่อไปเรื่อย ๆ, หรือทิ้งทั้งหมดแล้วเขียนใหม่
- แม้ตัวเลขที่แน่นอนจะถกเถียงกันได้ แต่แนวโน้มใหญ่ที่ผลิตภาพลดลงเมื่อเวลาผ่านไปนั้น ดูจะตรงกับประสบการณ์จริง
ผลคูณที่เอเจนต์เขียนโค้ด AI สร้างขึ้น
- ยกตัวอย่างว่าเฟรมเวิร์กเขียนโค้ดแบบเอเจนต์รุ่นใหม่ Rock Lobster เพิ่มปริมาณโค้ดที่สร้างได้เป็นสองเท่า
- พร้อมกันนั้นก็สมมติว่าโค้ดเข้าใจยากขึ้นเล็กน้อย ทีมรับมือกับ pull request ไม่ไหว และไม่ได้อ่านโค้ดอย่างจริงจังก่อนอนุมัติ
- ถ้าในหนึ่งเดือนสร้างโค้ดได้เทียบเท่าสองเดือน และต้นทุนการบำรุงรักษาของผลลัพธ์นั้นก็เพิ่มเป็นสองเท่า ต้นทุนการบำรุงรักษาในเดือนถัดไปจะเพิ่มเป็น 4 เท่า
- ในตัวอย่างสุดโต่งนี้ หลังใช้ Rock Lobster เพียงประมาณ 5 เดือน ผลิตภาพจะกลับไปอยู่ระดับเดิม และอีกไม่กี่เดือนต่อมาก็จะแย่กว่ากรณีไม่ใช้เลย
- ไม่ได้หมายความว่า AI เพิ่มผลิตภาพหรือต้นทุนการบำรุงรักษาเป็นสองเท่าในโลกจริง แต่ต้องการเน้นว่า ต่อให้ความสามารถในการบำรุงรักษาเท่ากับโค้ดที่มนุษย์เขียน ผลประโยชน์ด้านผลิตภาพก็อยู่ได้ไม่นาน
แม้หยุดใช้เอเจนต์ ต้นทุนการบำรุงรักษาก็ยังคงอยู่
- เอเจนต์เขียนโค้ดมีต้นทุน และเมื่อประโยชน์ที่ได้ต่ำกว่าต้นทุน ก็อาจต้องการกลับไปใช้วิธีเดิม
- เมื่อหยุดใช้เอเจนต์ ผลประโยชน์ด้านผลิตภาพจะหายไป แต่ ต้นทุนการบำรุงรักษาเพิ่มเติม ของโค้ดที่สร้างด้วยเอเจนต์จะยังคงอยู่ตราบใดที่โค้ดยังอยู่
- ในกรณีนี้ คุณอาจติดอยู่กับผลิตภาพที่ต่ำกว่าการไม่ใช้เอเจนต์เลยตั้งแต่แรก
คณิตศาสตร์ที่เป็นไปได้คือการลดต้นทุนการบำรุงรักษาเท่านั้น
- LLM ต้อง ลดต้นทุนการบำรุงรักษา ลงตามอัตราส่วนผกผันที่แม่นยำของอัตราที่มันเพิ่มปริมาณโค้ด จึงจะทำให้สมการผลิตภาพโดยรวมสมเหตุสมผล
- หากปริมาณงานเพิ่มเป็นสองเท่า และต้นทุนการบำรุงรักษาของผลลัพธ์นั้นก็เพิ่มเป็นสองเท่า ต้นทุนการบำรุงรักษารวมจะเพิ่มเป็น 4 เท่า
- หากปริมาณงานเพิ่มเป็นสองเท่า แต่ต้นทุนการบำรุงรักษาต่อผลลัพธ์ยังเท่าเดิม ต้นทุนการบำรุงรักษารวมก็ยังเพิ่มเป็น 2 เท่า
- ถ้าปริมาณงานเพิ่มเป็นสองเท่า ต้นทุนการบำรุงรักษาต้องลดลงครึ่งหนึ่ง และถ้าเพิ่มเป็นสามเท่า ต้นทุนการบำรุงรักษาต้องเหลือหนึ่งในสาม
- ต้องเป็นไปตามเงื่อนไขนี้ จึงจะได้ประโยชน์ด้านความเร็วโดยไม่สร้างภาระผูกพันระยะยาว
ความกังวลต่อเอเจนต์เขียนโค้ดในปัจจุบัน และคานงัดแบบอื่นที่อาจเป็นไปได้
- จากแหล่งอย่าง Hacker News ดูเหมือนจะมีสัญญาณมากมายว่าเอเจนต์เขียนโค้ดกำลังเพิ่มต้นทุนการบำรุงรักษา
- บางคนบอกว่ามันช่วยให้เข้าใจระบบขนาดใหญ่ได้ดีขึ้น แต่ยังไม่เห็นการลดต้นทุนการบำรุงรักษาขนาดใหญ่ตามที่จำเป็น และดูเหมือนจะเป็นตรงกันข้ามมากกว่า
- แม้โมเดลจะไม่ได้สะท้อนโลกจริงอย่างสมบูรณ์ แต่สารสำคัญที่ว่า AI ต้องลดต้นทุนการบำรุงรักษาให้ได้ตามสัดส่วนกับความเร็วในการเขียนโค้ดใหม่นั้นยังใช้ได้
- ต่อให้มุ่งปรับปรุงความเร็วในการเขียนโค้ด ก็ควรใช้เวลาเท่า ๆ กันกับการปรับปรุงต้นทุนการบำรุงรักษาด้วย
- นี่ไม่ใช่ข้อโต้แย้งต่อต้าน AI เพราะยังมีคานงัดแบบอื่น เช่น AI ที่ช่วยให้งานบำรุงรักษาเองมีผลิตภาพสูงขึ้น แม้จะไม่ได้ทำให้ตัวโค้ดบำรุงรักษาง่ายขึ้นโดยตรง
- หากต้องการปรับสมมติฐานให้ตรงกับสถานการณ์จริง สามารถคัดลอก สเปรดชีต แล้วปรับตัวแปรต่าง ๆ ในโมเดลได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในงานนำเสนอ Dconf'24 Software as investment มีการเสนอกรอบพื้นฐานที่อิงกับฟังก์ชันมูลค่าซึ่งนำมาประกอบกันได้สำหรับแต่ละชิ้นส่วนของซอฟต์แวร์
ตัวกรอบนี้เองไม่ได้จำเป็นต้องเปลี่ยนเพราะ AI โดยตรง แค่ปรับโมเดลต้นทุนตามว่า AI ทำงานด้านการบำรุงรักษาได้ดีแค่ไหนก็พอ
แม้จะมีคนบอกว่า AI สร้างบั๊กมากขึ้น 1.7 เท่า แต่มันก็อาจจะแก้ได้เร็วขึ้นด้วย เลยยังตอบยาก
ถ้ามองซอฟต์แวร์เป็นการลงทุน เราจะพูดถึง “มูลค่า” แทน “หนี้ทางเทคนิค” และหนี้ก็เป็นแค่สินทรัพย์ที่มีมูลค่าติดลบ
เมื่อซอฟต์แวร์ออกจากโลกเดิมที่มีกำไรขั้นต้นสูง เราจำเป็นต้องนิยามให้แม่นยำว่า ซอฟต์แวร์ที่คุ้มค่าต่อการมีอยู่ คืออะไร
ในซอฟต์แวร์ย่อมมีส่วนที่เขียนให้ดีกว่านี้ได้เสมอ และนั่นแหละคือหนี้
เป็นมุมมองที่มีอินไซต์และเห็นด้วย
น่าเสียดายที่ความสามารถในการบำรุงรักษามักถูกจับใส่ตะกร้า “ข้อกำหนดที่ไม่ใช่เชิงหน้าที่”
แต่ข้อกำหนดที่ไม่ใช่เชิงหน้าที่อย่างความสามารถในการบำรุงรักษา ควรถูกมองว่าเป็นสิ่งที่รักษาและทำให้การส่งมอบข้อกำหนดเชิงหน้าที่ในอนาคตเป็นไปได้
ไม่ควรถูกวางกรอบว่าเป็นแค่เรื่อง “ควรทำอย่างไร” ตรงข้ามกับ “ซอฟต์แวร์ควรทำอะไร”
ถ้าเป็นโปรเจ็กต์ที่ต้องเพิ่มและปรับปรุงฟีเจอร์อย่างต่อเนื่อง ความสามารถในการบำรุงรักษาก็แทบจะเป็น ข้อกำหนดเชิงหน้าที่ เลย ยกเว้นในช่วงเวลาที่สั้นมาก
ทันทีที่มีชื่อแยก คนที่ไม่เข้าใจมากพอจะมีข้ออ้างในการกั้นมันออกไปต่างหากและลดลำดับความสำคัญ
คุณภาพเป็นเรื่องสำคัญ และถ้าไม่รักษาไว้ มันจะกระทบงบกำไรขาดทุนอย่างแรงและเร็วมาก
เพราะฉะนั้นมันสำคัญพอ ๆ กับองค์ประกอบอื่นทุกอย่าง
ใช้คำของ Kevlin Henney คือ operational properties และ development properties แทนก็พอ
ความสามารถในการบำรุงรักษาเป็น development property ที่เป็นรากฐาน
อาจมี product roadmap 1-2 ปี แต่พูดตามตรง roadmap แบบนั้นหลายครั้งก็มีเป้าหมายทางการขายมากกว่าเป็นแผนวิศวกรรม
พอรายได้สะดุด ฝั่งผลิตภัณฑ์กับวิศวกรรมก็เปลี่ยนทิศ และยิ่งเป็นบริษัทช่วงต้นก็ยิ่งเกิดบ่อย
พอพ้นโหมดสตาร์ตอัปแล้วมันควรนิ่งขึ้น แต่หลายบริษัทก็ไม่เป็นแบบนั้นและยังวนกับรูปแบบการวางแผนระยะสั้นต่อไป
ผลลัพธ์คือ เสถียรภาพของผลิตภัณฑ์ ยังคงมีความสำคัญต่ำ
สุดท้ายเลยดูเหมือนว่าหลายบริษัทไม่มีทรัพยากรจะทำซอฟต์แวร์ดี ๆ หรือไม่ก็ไม่ได้แคร์จริง ๆ
จากที่เจอในโปรเจ็กต์ของเรา AI เร็วก็จริง แต่บั๊กที่ AI ใส่มามักแปลกตรงที่หาเจอยาก
ไม่ใช่บั๊กชัด ๆ แต่เป็นตรรกะประเภทที่อีก 3 สัปดาห์ค่อยพังใน production แล้วพอไล่ดูถึงพบว่า AI เข้าใจรายละเอียดบางอย่างผิดแบบละเอียดอ่อน
พูดตรง ๆ คือ AI ไม่ได้ลดต้นทุนการบำรุงรักษาเท่าไร มันแค่ ย้ายตำแหน่งของต้นทุน
เวลาเขียนลดลง แต่เวลารีวิวเพิ่มขึ้น
โค้ดจาก AI เวลาผิดก็ดูลื่นไหลและมั่นใจมาก ทำให้รีวิวยากกว่าโค้ดคน
จะคุ้มสุทธิหรือไม่ขึ้นอยู่กับว่าทีมเก่งในการ อ่าน โค้ดมากแค่ไหน มากกว่าการเขียนโค้ดเสียอีก
จากประสบการณ์ของผม AI ช่วยลด ต้นทุนการบำรุงรักษา ได้
แต่บริบทอาจสำคัญ ผมดูแลหลายโปรเจ็กต์ที่มีอายุหลายสิบปี มีทั้งการพัฒนาฟีเจอร์ใหม่จำนวนมาก แต่โค้ดเก่าและโปรเจ็กต์เก่ากลับจัดการง่ายขึ้นมาก ทันสมัยขึ้นง่ายขึ้น และในหลายกรณีก็ลบทิ้งได้ด้วย
dependency ของไลบรารีเก่าและเครื่องมือ build บางกรณีอัปเดตได้ บางกรณีก็เอาออกไปเลย ทำให้ build เร็วขึ้นและง่ายขึ้นสำหรับนักพัฒนา
การตั้งค่าและทำ automation ของการทดสอบแบบ end-to-end ก็ง่ายขึ้นมาก DevOps ก็ดีขึ้นมาก และการวิเคราะห์ปัญหาในระบบจริงก็ดีขึ้นอย่างมาก
มี log และข้อมูลจำนวนมากอยู่แล้ว รวมทั้งแดชบอร์ดและการมอนิเตอร์แบบรวมศูนย์เพื่อจับสิ่งสำคัญ แต่ตอนนี้เราวิเคราะห์ระบบที่ปล่อยใช้งานอยู่ราว 50 โปรเจ็กต์ได้ลึกกว่าเดิมมาก
ข้ออ้างหลักของบทความคือ ต่อการพัฒนาฟีเจอร์ที่ “เพิ่มมูลค่า” 1 ชั่วโมง ต้องใช้เวลาบำรุงรักษากี่ชั่วโมง
เพราะงั้นอย่างแรกคืออย่าวัดแค่ต้นทุนการบำรุงรักษา ต้องดูเป็นสัดส่วน และอย่างที่สองคือ โค้ดเก่า นั้นเดิมทีก็ไม่ได้เขียนด้วย AI ตั้งแต่แรก
แต่ประเด็นของผู้เขียนน่าจะเป็นว่า ถ้าสูญเสียการเข้าถึงเครื่องมือ AI ทุกอย่างจะดูยากขึ้นมากทันที
เหมือนเคยใช้เครื่องจักรหนักย้ายภูเขาอย่างสบาย แล้วต้องกลับไปใช้เครื่องมือช่างมืออีกครั้ง
จำนวน incident เพิ่มขึ้นพร้อมกับจำนวนบรรทัดโค้ดที่ deploy และ incident ก็รุนแรงขึ้นเรื่อย ๆ
แน่นอนว่าเราได้ปรับปรุงโค้ดเก่าไปมาก ลบได้มากขึ้น ทำ code modernization อัตโนมัติได้ และวิเคราะห์ปัญหาได้ดีขึ้น รวมถึงมีทางเลือกในการบรรเทาปัญหามากขึ้น
แต่ทั้งหมดนั้นก็ยังหักล้าง ขนาดที่ท่วมท้น ของโค้ดที่ถูก deploy โดยที่ไม่มีใครเข้าใจอย่างแท้จริงไม่ได้
ทีมของเราใช้ AI ไม่ใช่แค่เพิ่มโค้ด แต่ยังใช้ลบโค้ดเก่าที่เลิกใช้แล้วอย่างจริงจังด้วย
คำถามอย่าง “ยังมีใครใช้อันนี้อยู่ไหม?” หรือ “สิ่งนี้ถูกเรียกอย่างไร?” ตอบง่ายขึ้นมากเมื่อโยนทั้งฟรอนต์เอนด์ แบ็กเอนด์ และทั้ง codebase ให้เอเจนต์ช่วยทำแผนที่ของโปรเจ็กต์ซอฟต์แวร์
IDE ก็ช่วยได้ระดับหนึ่งถ้าอยู่ในภาษาเดียวและมักจะเป็นโปรเจ็กต์เดียว แต่ขอบเขตอย่าง RPC หรือ REST มักทำให้เครื่องมือใน IDE พัง
ชอบคำถามนี้มาก: ถ้าเลือกได้ คุณอยากได้ codebase แบบไหน?
คิดแป๊บเดียวก็น่าจะไม่ใช่ codebase ที่มีฟีเจอร์เยอะมหาศาล
น่าจะอยากได้ codebase ที่ค่อนข้างคล้ายกับของตอนนี้ แต่เข้าใจง่าย และดูแลง่าย/ขยายง่ายตามโจทย์ธุรกิจในอนาคตมากกว่า
codebase ที่ “ใช้งานได้จริง” หรือก็คือ codebase ที่มีการบำรุงรักษาอยู่ กำลังแก้ปัญหาในโลกจริง และการแก้ปัญหาเหล่านั้นก็ควรมาก่อนความเนี้ยบเสมอ
codebase ที่สะอาดเนี้ยบมาก ๆ มักเป็นเพียง ตัวอย่างโชว์ ที่วางไว้บนหิ้งให้ชื่นชมเสียมากกว่า
อยากเสริมอยู่สองเรื่อง
อย่างแรก ซอฟต์แวร์ไม่ได้มีแค่การบำรุงรักษาทางเทคนิค แต่ยังมี การซัพพอร์ตผู้ใช้ ด้วย และสิ่งนี้ก็เพิ่มขึ้นเมื่อซอฟต์แวร์ใหญ่ขึ้น
อย่างที่สอง ผมไม่มั่นใจว่าต้นทุนการบำรุงรักษาจะเพิ่มแบบเส้นตรง
ต่อให้เพิ่มแบบเส้นตรง สุดท้ายก็จะไปถึงจุดที่เวลาทั้งหมดถูกใช้ไปกับการบำรุงรักษาอยู่ดี
ถ้าต้องบำรุงรักษาไม่ใช่แค่แต่ละส่วน แต่รวมถึงวิธีที่แต่ละส่วนโต้ตอบกันด้วย ก็อาจเป็นแบบนั้น
สัญญาณที่ชัดที่สุดเท่าที่ผมเห็นเกี่ยวกับคำถามว่า AI ลดต้นทุนการบำรุงรักษาจริงไหม คือ นักพัฒนามองผลลัพธ์จาก AI เป็น ร่างแรก หรือมองเป็นงานสุดท้าย
เวลาใช้เครื่องมือ AI กับ codebase เดิม เช่น เพื่อเข้าใจโมดูลที่ไม่คุ้นเคย สร้าง targeted refactoring หรือเขียน migration script ภาระการบำรุงรักษาจะลดลงจริง
เพราะ AI กำลังทำงานบนโค้ดที่ผมเข้าใจในเชิงสถาปัตยกรรมอยู่แล้ว ทำให้ประเมินผลลัพธ์ได้เร็ว
ปัญหาเกิดตอน AI สร้างโค้ดใหม่ที่ไม่มีใครเข้าใจลึกพอ
แล้วโค้ดนั้นก็ต้องถูกบำรุงรักษาโดยคนที่ไม่ได้เป็นคนเขียนหรือออกแบบมัน
ถ้าเป็นโค้ดที่คนอื่นเขียน อย่างน้อยเรายังพออนุมานเจตนาได้จากชื่อ โครงสร้าง และประวัติ commit
แต่โค้ดที่ AI สร้างมักขาด เจตนาที่อ่านออกได้ แบบนั้น เพราะ “ผู้เขียน” ไม่ได้มีเจตนาที่ต่อเนื่องครอบคลุมทั้งไฟล์
จุดที่บทความนี้พูดถูกคือ เราควรวัดไม่ใช่แค่ความเร็ว แต่รวมถึงต้นทุนการบำรุงรักษาด้วย
ในทางปฏิบัติเราควรติดตามเวลาในการทำความเข้าใจและอัตราการเปลี่ยนแปลงที่ล้มเหลวของโค้ดที่มี AI ช่วยกับโค้ดที่คนเขียน เป็นช่วงหลายเดือน ไม่ใช่แค่ไม่กี่วัน
code review ก็เหมือนกัน
ผมสงสัยว่า AI จะช่วยให้ code review ดูอ่านง่ายขึ้นได้ไหม
ใน code review ของคน นักพัฒนามักเรียนรู้ได้เร็วว่าควรหลีกเลี่ยงการเปลี่ยนแปลงทางภาพที่ไม่จำเป็น เช่น reflow โค้ดหรือคอมเมนต์ เปลี่ยน indentation ที่เครื่องมือซ่อนไม่ได้ ย้ายฟังก์ชัน หรือแค่ลบบรรทัด
และก็ควรหลีกเลี่ยง refactoring ที่ไม่จำเป็นด้วย
บางทีอาจแยกรีวิวเป็นสองส่วนคือ การเปลี่ยนแปลงฟังก์ชันการทำงาน กับ การเปลี่ยนแปลงรูปลักษณ์
แบบนั้นรีวิวจะง่ายขึ้นมาก
การรีวิวเริ่มจากสมมติฐานว่า “ต้องไม่มีอะไรเปลี่ยน” และ reviewer ก็ใช้การจับแพตเทิร์นได้
ไม่อย่างนั้น reviewer ต้องประเมินทุกบรรทัดใหม่หมดเพื่อยืนยันว่าไม่มีอะไรเปลี่ยน ซึ่งทำให้ทำได้ดีจริง ๆ ยากมาก
ระบบควบคุมเวอร์ชันที่ผมเคยใช้ต่างก็รองรับคิวการเปลี่ยนแปลงที่รีวิวแยกกันอย่างอิสระ
ถ้าระหว่างพัฒนาต้อง refactor ก็ส่ง commit หนึ่งอันเพื่อ refactor แล้วส่งรีวิว จากนั้นค่อย rebase งานที่ทำอยู่และทำต่อ
ถ้าปล่อยการเปลี่ยนแบบ “CLEANUP:”, “REFACTOR_ONLY:” ออกมาเรื่อย ๆ การเปลี่ยนแปลงสุดท้ายก็จะเล็กลงมาก แทนที่จะกลายเป็นก้อนยักษ์น่ากลัว
reviewer จะขอบคุณความพยายามนั้น
และถ้าเป็นองค์กรแบบนั้น การเล่นกับตัวชี้วัดก็อาจทำได้โดยไม่กลายเป็นเรื่องชั่วร้าย
ผู้เขียนดูเหมือนตั้งต้นจากสมมติฐานว่ามนุษย์จะต้องตรวจโค้ด AI ทุกส่วนอย่างละเอียด และต้องสามารถเข้าใจและบำรุงรักษามันได้โดยไม่พึ่ง AI
แต่จากประสบการณ์ของผม คนไม่ได้ใช้ AI แบบนั้น
ตอนแรกอาจใช่ เพราะยังไม่เชื่อใจ และยังเรียนรู้การ prompt เพื่อให้ได้ผลลัพธ์ที่ต้องการอยู่ จึงใช้มันช่วยงานน่าเบื่อ โดยให้คนทำ implementation หรือลวดลายหลักก่อน แล้ว AI ค่อยเติมช่องว่าง
มันใกล้เคียงกับ autocomplete ที่เก่งขึ้น มากกว่าจะเป็นการปฏิวัติวิธีเขียนโค้ดเต็มรูปแบบ
ยิ่งทำงานกับ AI มากขึ้น คนก็ยิ่งกังวลกับโค้ดที่ AI สร้างจริง ๆ น้อยลง
ไม่ได้หมายความว่ามันเป็นเรื่องดี มันอาจสร้างบั๊ก ปัญหาด้านประสิทธิภาพ หรือช่องโหว่ความปลอดภัยได้
แต่ความเป็นจริงก็เป็นแบบนั้น ถ้าโค้ดจาก AI สร้างบั๊ก? ก็ให้ AI แก้
ถ้าโค้ดจาก AI อ้วนเทอะทะและอ่านยาก? ถ้าแคร์ก็ให้ AI แก้ หลายคนไม่แคร์ด้วยซ้ำ
ถ้ามนุษย์หลุดออกจากการบำรุงรักษาโค้ดทั้งหมด ความจำเป็นของ โค้ดที่บำรุงรักษาได้ ก็จะหายไปด้วย
เรายังไปไม่ถึงจุดนั้น 100% แต่กำลังมุ่งหน้าไปทางนั้น
สำหรับหลายบริษัท แค่ดีพอแล้ว จึงคุ้มที่จะรับความเสี่ยงและเดินหน้าแบบ YOLO
ส่วนตัวผมยังไม่ไว้ใจ AI มากพอจะไม่อ่านโค้ดที่มันสร้างเลย แต่ก็ไม่ได้อ่านทุกบรรทัด
ผมจะดูเทสต์ละเอียดกว่าโค้ดที่ถูกทดสอบ ให้ความสำคัญกับส่วนที่ performance สำคัญมากกว่า และคอยกำกับโครงสร้างโดยรวม
ถึงอย่างนั้น ถ้ายังไม่ถึงมาตรฐาน ผมก็ไม่ได้ไปบำรุงรักษาเอง แต่ให้ AI แก้
ถ้าการบำรุงรักษาถูกขนาดนี้ ต้นทุนการบำรุงรักษาก็ไม่ใช่เรื่องที่ผมสนใจนัก
บทความนี้ชี้ให้เห็นได้ดีว่าตัวแทน AI หรือเครื่องมือช่วย ไม่ควรช่วยแค่ช่วงแรกแบบ “ช่วยสร้างวิดเจ็ตใหม่ให้หน่อย” แต่ควรช่วยในหลายส่วนของการพัฒนาซอฟต์แวร์ด้วย
ผู้เขียนมองว่าถ้ามีคนใช้เอเจนต์ AI หรือเครื่องมือช่วยแค่ในขั้นสร้างวิดเจ็ตใหม่ AI ก็จะปั๊มโค้ดออกมามากขึ้น และนั่นหมายถึงโค้ดที่ต้องบำรุงรักษาก็มากขึ้นมากเช่นกัน
ต่อให้คุณภาพโค้ดสูง เมื่อเวลาผ่านไป ต้นทุนการบำรุงรักษา ก็ยังเกิดขึ้นอยู่ดี
แต่ปัญหาที่ผู้เขียนพูดถึงนั้น ดูจะไม่ใช่ปัญหาที่ทุกคนต้องเจอเสียทีเดียว หลายส่วนคล้ายเป็นปัญหาที่สร้างขึ้นเอง
สถานการณ์แบบสตาร์ตอัปที่ผู้เขียนยกมา คือ “มาทำให้มันใช้ได้ก่อนเพื่อพิสูจน์ product-market fit และดึงลูกค้ามา” เดิมทีก็มาพร้อมต้นทุนการบำรุงรักษาที่สูงขึ้นในภายหลังอยู่แล้ว
เพราะถ้าต้องพิสูจน์ว่าธุรกิจมีจริงและถ้ามีก็ต้องโตให้เร็ว การลดคุณภาพลงบ้างเพื่อแลกกับความเร็วก็ถือว่าพอมีเหตุผล
และผมยังรู้สึกว่าผู้เขียนค่อนข้างหลีกเลี่ยงที่จะพูดถึงว่า AI จะช่วยในส่วนการบำรุงรักษาจริง ๆ ได้อย่างไร
AI อาจมีประโยชน์มากในการแก้ dependency เก่า ๆ หรือจัดการบั๊กจุกจิก เมื่อมีคนคอยชี้นำ
งานประเภทนี้อาจให้ความรู้สึกเหมือนงานจิปาถะสำหรับวิศวกรซอฟต์แวร์ และเป็นงานประเภทที่เราอยากได้ตัวช่วยจาก AI