AI coding agent ที่ใช้เขียนโค้ดต้องลดต้นทุนการบำรุงรักษาได้จริง
(jamesshore.com)- ต่อให้ AI coding agent ช่วยเพิ่มความเร็วในการเขียนโค้ดได้ แต่ถ้าไม่สามารถลด ต้นทุนการบำรุงรักษา ลงในสัดส่วนเดียวกันได้ ก็จะกลายเป็นว่าหลังจากผลิตภาพดีขึ้นชั่วคราว สุดท้ายกลับนำไปสู่การลดลงของผลิตภาพแบบถาวร
- โค้ดทุกชิ้นหลังจากเขียนเสร็จแล้วต้องการ การบำรุงรักษาอย่างต่อเนื่อง เช่น การแก้บั๊ก การเก็บกวาดโค้ด และการอัปเกรด dependency และเมื่อเวลาผ่านไป งานบำรุงรักษาจะกินสัดส่วนเวลางานส่วนใหญ่
- หากเพิ่มปริมาณโค้ดที่ผลิตได้เป็น 2 เท่า และต้นทุนการบำรุงรักษาก็เพิ่มเป็น 2 เท่าด้วย ต้นทุนการบำรุงรักษาจริงจะ เพิ่มเป็น 4 เท่า ทำให้ข้อได้เปรียบด้านผลิตภาพหายไปภายในไม่กี่เดือน
- แม้จะเลิกใช้ AI ภาระการบำรุงรักษาของโค้ดที่สร้างไปแล้วก็ยังคงอยู่ ทำให้ผลิตภาพ ต่ำกว่ากรณีที่ไม่เคยใช้ AI และติดอยู่เช่นนั้น
- หากต้องการเพิ่มผลิตภาพเป็น 2 เท่า ก็จำเป็นต้องมี AI ที่ลดต้นทุนการบำรุงรักษาได้ เหลือครึ่งหนึ่งพอดี และต้องทุ่มความพยายามกับการลดต้นทุนการบำรุงรักษาให้มากพอๆ กับการเพิ่มความเร็วในการเขียนโค้ด
ต้นทุนการบำรุงรักษาเป็นตัวกำหนดผลิตภาพ
- ทุกเวลาที่ใช้ไปกับการเขียนโค้ด จะก่อให้เกิดเวลาบำรุงรักษาต่อเนื่องในภายหลัง เช่น การแก้บั๊ก การเก็บกวาดโค้ด และการอัปเกรด dependency
- ประเด็นที่พูดถึงคือการบำรุงรักษาที่เกิดซ้ำทุกปีตราบใดที่โค้ดยังมีอยู่ ไม่ใช่งานเพิ่มฟีเจอร์ใหม่หรือการปรับปรุงอื่นๆ
- ตัวเลขประมาณการในตัวอย่างนี้ตั้งอยู่บนสมมติฐานว่า ทุกการเขียนโค้ด 1 เดือน จะต้องใช้เวลาบำรุงรักษา 10 วัน ในปีแรก และ 5 วัน ต่อปีหลังจากนั้น
- ผู้เขียนมองว่าหากใช้แนวทาง Wisdom of the Crowd ไปถามนักพัฒนาราว 50 คนเรื่องต้นทุนการบำรุงรักษา ก็อาจได้คำตอบที่ค่อนข้างแม่นยำ
- ตาม แบบจำลองในสเปรดชีต ที่สร้างจากสมมติฐานนี้ ช่วงต้นของโปรเจ็กต์ใหม่ เวลาส่วนใหญ่จะใช้ไปกับการพัฒนาฟีเจอร์ แต่เมื่อเวลาผ่านไป สัดส่วนการบำรุงรักษาโค้ดเก่าจะเพิ่มขึ้นเรื่อยๆ
- ในค่าประมาณนี้ หลังผ่านไป 2 ปีครึ่ง เวลาที่ใช้กับงานบำรุงรักษาจะเกินครึ่งของเวลาทั้งหมด และหลัง 10 ปี ก็แทบยากที่จะทำอย่างอื่นได้
- หากลดค่าประมาณต้นทุนการบำรุงรักษาลงครึ่งหนึ่ง จะยืดเวลาไปถึงจุด 50% ได้อีก 3 ปี แต่หากเพิ่มเป็น 2 เท่า ผลิตภาพจะตกต่ำกว่า 50% ภายในเวลาไม่ถึง 1 ปี
- ถ้าอยากได้ทีมที่มีผลิตภาพสูง ควรโฟกัสที่ ต้นทุนการบำรุงรักษา มากกว่าความเร็วในการเขียนโค้ดใหม่
โมเดลอาจผิดได้ แต่ทิศทางนั้นถูกต้อง
- ในสตาร์ตอัปช่วงระยะหลัง มักพบปัญหาว่าหลังผ่านไปประมาณ 5~9 ปี ทีมเริ่มทำงานให้เสร็จลุล่วงไม่ได้เหมือนเดิม ซึ่งมีลักษณะคล้ายกับแพตเทิร์นที่กราฟแสดง
- เหตุผลที่ทีมจริงอาจไม่ได้ดูแย่เท่ากราฟ อาจเป็นเพราะต้นทุนการบำรุงรักษาต่ำกว่า หรืออาจเพราะปัญหาถูกกลบด้วยวิธีอื่น
- วิธีรับมือที่เป็นไปได้คือไม่แก้ทุกบั๊ก ไม่อัปเกรดทุก dependency เพิ่มคนเมื่อทีมเริ่มช้าลงแล้วก็เพิ่มต่อไปเรื่อยๆ หรือทิ้งทั้งหมดแล้วเขียนใหม่
- แม้ตัวเลขที่แน่นอนจะยังถกเถียงกันได้ แต่แนวโน้มใหญ่ที่ผลิตภาพลดลงเมื่อเวลาผ่านไปนั้น ดูสอดคล้องกับประสบการณ์จริง
ผลคูณที่ AI coding agent สร้างขึ้น
- ยกตัวอย่างสมมติว่าเฟรมเวิร์กการเขียนโค้ดแบบ agent รุ่นใหม่อย่าง Rock Lobster สามารถเพิ่มปริมาณโค้ดที่ผลิตได้เป็น 2 เท่า
- พร้อมกันนั้นก็สมมติว่าโค้ดเข้าใจยากขึ้นเล็กน้อย ทีมถูกถาโถมด้วย pull request และไม่ได้อ่านโค้ดอย่างรอบคอบก่อนอนุมัติ
- หากในหนึ่งเดือนสร้างโค้ดได้เทียบเท่า 2 เดือน และต้นทุนการบำรุงรักษาของผลลัพธ์นั้นก็เพิ่มเป็น 2 เท่าด้วย ต้นทุนการบำรุงรักษาในเดือนถัดไปจะ เพิ่มเป็น 4 เท่า
- ในตัวอย่างสุดโต่งนี้ หลังใช้ Rock Lobster ไปประมาณ 5 เดือน ผลิตภาพจะกลับลงมาเท่าระดับเดิม และอีกไม่กี่เดือนต่อมาก็จะแย่กว่ากรณีที่ไม่เคยใช้เลย
- ไม่ได้หมายความว่า AI จะเพิ่มผลิตภาพหรือต้นทุนการบำรุงรักษาเป็น 2 เท่าจริงๆ แต่ต้องการเน้นว่าต่อให้ความสามารถในการบำรุงรักษาเท่ากับโค้ดที่มนุษย์เขียน ข้อได้เปรียบด้านผลิตภาพก็อยู่ได้ไม่นาน
แม้หยุดใช้ agent แล้ว ต้นทุนการบำรุงรักษาก็ยังอยู่
- coding agent มีต้นทุน และเมื่อประโยชน์ที่ได้ต่ำกว่าต้นทุน ก็อาจอยากกลับไปใช้วิธีเดิม
- เมื่อหยุดใช้ agent ข้อได้เปรียบด้านผลิตภาพจะหายไป แต่ ต้นทุนการบำรุงรักษาที่เพิ่มขึ้น จากโค้ดที่ agent สร้างไว้จะยังคงอยู่ตราบเท่าที่โค้ดยังอยู่
- ในกรณีนี้ คุณอาจถูกผูกไว้กับระดับผลิตภาพที่ต่ำกว่าการไม่ใช้ agent ตั้งแต่แรก
คณิตศาสตร์ที่ลงตัวได้มีเพียงการลดต้นทุนการบำรุงรักษา
- LLM ต้อง ลดต้นทุนการบำรุงรักษา ลงในสัดส่วนที่เป็นค่ากลับกันอย่างพอดีกับอัตราที่มันเพิ่มปริมาณโค้ด จึงจะทำให้การคำนวณผลิตภาพโดยรวมสมเหตุสมผล
- หากปริมาณผลลัพธ์เพิ่มเป็น 2 เท่า และต้นทุนการบำรุงรักษาของผลลัพธ์นั้นก็เพิ่มเป็น 2 เท่า ต้นทุนการบำรุงรักษารวมจะ เพิ่มเป็น 4 เท่า
- หากปริมาณผลลัพธ์เพิ่มเป็น 2 เท่า แต่ต้นทุนการบำรุงรักษาต่อผลลัพธ์ยังเท่าเดิม ต้นทุนการบำรุงรักษารวมก็ยัง เพิ่มเป็น 2 เท่า
- ถ้าปริมาณผลลัพธ์เพิ่มเป็น 2 เท่า ต้นทุนการบำรุงรักษาต้องลดเหลือครึ่งหนึ่ง และถ้าเพิ่มเป็น 3 เท่า ต้นทุนการบำรุงรักษาต้องลดเหลือ 1 ใน 3
- ต้องทำตามเงื่อนไขนี้จึงจะได้ประโยชน์จากความเร็ว โดยไม่ต้องแลกกับการติดกับดักในระยะยาว
ความกังวลต่อ coding agent ในปัจจุบัน และคันโยกอื่นที่เป็นไปได้
- จากแหล่งอย่าง Hacker News ดูเหมือนจะมีสัญญาณมากมายว่า coding agent ทำให้ต้นทุนการบำรุงรักษาสูงขึ้น
- แม้บางคนจะบอกว่ามันช่วยให้เข้าใจระบบขนาดใหญ่ได้ดีขึ้น แต่ยังไม่เห็นการลดต้นทุนการบำรุงรักษาอย่างมากในระดับที่ต้องการ และดูจะใกล้เคียงกับตรงกันข้ามมากกว่า
- แม้โมเดลจะไม่ได้สะท้อนความเป็นจริงอย่างสมบูรณ์แบบ แต่สารสำคัญที่ว่า AI ต้องลดต้นทุนการบำรุงรักษาให้สอดคล้องกับความเร็วที่เพิ่มขึ้นในการเขียนโค้ดใหม่นั้นยังใช้ได้
- ต่อให้ไล่ตามการเพิ่มความเร็วในการเขียนโค้ด ก็ต้องใช้เวลาเท่ากันกับการปรับปรุงต้นทุนการบำรุงรักษา
- นี่ไม่ใช่ข้อโต้แย้งแบบต่อต้าน AI เพราะยังมีคันโยกแบบอื่น เช่น AI ที่ช่วยให้งานบำรุงรักษาเองมีผลิตภาพมากขึ้น แม้จะไม่ได้ทำให้ตัวโค้ดบำรุงรักษาง่ายขึ้นโดยตรง
- หากต้องการเปลี่ยนสมมติฐานให้ตรงกับสถานการณ์จริง สามารถคัดลอกสเปรดชีต แล้วปรับตัวแปรต่างๆ ในโมเดลได้
2 ความคิดเห็น
เหตุผลพื้นฐานที่สุดที่ทำให้เกิดความไม่ไว้วางใจ AI คือ
ตอนนี้ผู้เชี่ยวชาญ (ที่อ้างตัวเอง) ส่วนใหญ่กำลังตะโกนว่าตัวเองไม่ได้เจอข้อเสียของ AI ตามที่คนอื่นพูดถึง และก็ไม่มี trade-off อะไรทั้งนั้น พร้อมทั้งทำตัวเหมือนหน้าม้า
ตอนนี้พวกมิจฉาชีพมีมากขึ้นแล้ว เลยเกิดความไม่ไว้วางใจต่อภาพรวมสะสมขึ้นมา
ความคิดเห็นจาก 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