ในขณะที่ปัญญาประดิษฐ์กำลังเปลี่ยนแปลงวิธีการเขียนซอฟต์แวร์ นักพัฒนากำลังเผชิญกับผลกระทบที่คาดไม่ถึง นั่นคือปริมาณโค้ดคุณภาพต่ำที่ไหลบ่าเข้ามาอย่างไม่หยุดยั้ง ซึ่งกำลังทำให้ผู้ตรวจสอบโค้ด overwhelmed และคุกคามต่อศาสตร์แห่งการเขียนโปรแกรมโดยตรง สิ่งที่เริ่มต้นเป็นเครื่องมือเพื่อเพิ่มผลผลิต กลับกลายเป็นแหล่งความตึงเครียดในทีมพัฒนาทั่วโลก
การเพิ่มขึ้นของโค้ดไร้คุณภาพจาก AI
ทั่วทั้งอุตสาหกรรมเทคโนโลยี นักพัฒนารายงานถึงการเพิ่มขึ้นอย่างมากของสิ่งที่หลายคนเรียกว่า โค้ดขยะจาก AI ซึ่งเป็นโค้ดที่สร้างขึ้นโดย large language models ที่ดูเผินๆ ว่าถูกต้องแต่มีข้อผิดพลาดพื้นฐานซ่อนอยู่ ปัญหาไม่ได้เป็นเพียงด้านเทคนิคเท่านั้น แต่ยังเป็นเรื่องทางวัฒนธรรมด้วย นักพัฒนาที่พึ่งพาเครื่องมือ AI อย่างหนักกำลังผลิตโค้ดจำนวนมหาศาลโดยไม่เข้าใจอย่างถ่องแท้ว่ากำลังส่งอะไรไปให้ตรวจสอบ
นักพัฒนาคนหนึ่งสะท้อนความหงุดหงิดที่หลายคนรู้สึก: ผู้ตรวจสอบโค้ดกำลังเสียสติอย่างรวดเร็ว เมื่อพวกเขาตระหนักอย่างเจ็บปวดว่าตอนนี้พวกเขากลายเป็นด่านควบคุมคุณภาพชั้นแรก แทนที่จะเป็นหนึ่งในด่านสุดท้าย ผู้ตรวจสอบพบตัวเองต้องจับตาดูทุกอย่าง ตั้งแต่ฟังก์ชันที่ไม่ได้ใช้ การอ้างอิง library ที่ถูกปั้นขึ้นมา ไปจนถึงข้อผิดพลาดขณะรันที่ชัดเจนซึ่งควรถูกตรวจพบโดยผู้เขียนโค้ดตั้งแต่แรก
ปัญหาทั่วไปในโค้ดที่สร้างโดย AI:
- ฟังก์ชันที่ไม่ได้ใช้งานและไม่มีการเรียกใช้
- การอ้างอิงไปยังไลบรารีที่ไม่มีอยู่จริง
- ข้อผิดพลาดที่เห็นได้ชัดเจนในการรันไทม์หรือการคอมไพล์
- รูปแบบโค้ดที่ยืดยาวและซ้ำซากเกินไป
- ขาดการจัดการข้อผิดพลาดที่เหมาะสม
- อัลกอริทึมและโครงสร้างข้อมูลที่ไม่มีประสิทธิภาพ
ช่องว่างของความรับผิดชอบ
แนวโน้มที่น่าวิตกที่สุดอาจเป็นการเกิดขึ้นของสิ่งที่บางคนเรียกว่า วัฒนธรรมแบบ 'อุ๊ปส์' เมื่อถูกตั้งคำถามเกี่ยวกับโค้ดที่มีปัญหา นักพัฒนาบางคนกลับโยนความรับผิดชอบด้วยคำพูดอย่าง 'อุ๊ปส์' Claude เป็นคนเขียนน่ะ AI มันงี่เง่าจริงๆ ฮ่าๆ ทัศนคตินี้แสดงถึงการเปลี่ยนแปลงพื้นฐานในวิธีที่โปรแกรมเมอร์เข้าสู่การทำงาน ในขณะที่นักพัฒนาเคยภูมิใจในความเป็นเจ้าของโค้ดของตน บางคนตอนนี้กลับมองผลลัพธ์จาก AI ว่าเป็นปัญหาของคนอื่น
การตอบสนองจากชุมชนนั้นชัดเจน: หากใครทำครั้งหนึ่ง พวกเขาจะได้รับข้อความเตือนอย่างจริงจังเกี่ยวกับเรื่องนี้ หากเกิดขึ้นครั้งที่สอง มันจะถูกปฏิเสธและส่งต่อไปยังผู้จัดการของพวกเขา นักพัฒนาที่มีประสบการณ์หลายคนแย้งว่าไม่ว่าโค้ดจะถูกเขียนขึ้นอย่างไร บุคคลที่ส่งโค้ดมายังคงต้องรับผิดชอบต่อคุณภาพของมัน ทางออกตามที่ผู้แสดงความคิดเห็นคนหนึ่งระบุนั้นง่ายดาย: วิธีแก้คือเพียงแค่ปฏิเสธ commit ด้วยข้อความ 'จัดการให้เรียบร้อย' ทันทีที่คุณพบเรื่องไร้สาระ ความไว้วางใจต้องได้รับ!
ตัวชี้วัดผลผลิตเทียบกับคุณภาพ
การผลักดันไปสู่การเขียนโค้ดด้วย AI ไม่ได้เกิดขึ้นในสุญญากาศ ทีมผู้จัดการที่กระตือรือร้นที่จะแสดงให้เห็นถึงการเพิ่มขึ้นของผลผลิต มักจะวัดในสิ่งที่ไม่ถูกต้อง ดังที่ผู้สังเกตการณ์คนหนึ่งระบุไว้: บุคคลที่โยนโค้ดขยะจาก LLM ไปที่ GitHub มีตัวชี้วัดที่ดูดีเมื่อผู้บริหารมองที่การใช้งานเคอร์เซอร์ จำนวนบรรทัดโค้ด จำนวน PR ในขณะที่บุคคลที่ชะลอตัวลงเพื่ออ่านสิ่งที่คนอื่นส่งมาจริงๆ กลับกำลังจมอยู่กับโค้ดขยะจนพวกเขามีเวลาน้อยลงที่จะผลิตผลงานของตัวเอง
สิ่งนี้สร้างโครงสร้างแรงจูงใจที่ผิดปกติ โดยที่ปริมาณมีความสำคัญเหนือคุณภาพ นักพัฒนาที่สร้างโค้ดด้วยความช่วยเหลือจาก AI เป็นพันๆ บรรทัด ดูเหมือนจะมีผลผลิตมากกว่าผู้ที่ค่อยๆ สร้างโซลูชันขนาดเล็กที่มีประสิทธิภาพมากขึ้นอย่างพิถีพิถัน นักพัฒนาคนหนึ่งชี้ให้เห็นถึงความแตกต่างที่สำคัญ: โค้ดที่เขียนโดย LLM นั้นเกือบทั้งหมดเป็นการเพิ่มเติม ในขณะที่วิศวกรอาวุโสที่ดีมักจะลบโค้ดออกไปมากเท่ากับที่พวกเขาเพิ่มเข้าไป สิ่งนี้สะท้อนให้เห็นถึงเรื่องเล่าที่มีชื่อเสียงจากยุคแรกๆ ของ Apple เกี่ยวกับ จำนวนบรรทัดโค้ดติดลบ ที่ถูกใช้เป็นตัวชี้วัดผลผลิต
ตัวชี้วัดผลกระทบต่อทีม:
- เวลาในการตรวจสอบโค้ดเพิ่มขึ้น 3-5 เท่าสำหรับงานที่สร้างด้วย AI
- จำนวนบรรทัดใน Pull request โดยทั่วไปสูงขึ้น 200-500% เมื่อใช้ความช่วยเหลือจาก AI
- อัตราข้อบกพร่องในโค้ดที่สร้างด้วย AI: สูงขึ้น 2-3 เท่าในการส่งงานครั้งแรก
- การถ่ายทอดความรู้ระหว่างสมาชิกในทีมลดลงประมาณ 40-60%
- เวลาในการปฐมนิเทศนักพัฒนาใหม่เพิ่มขึ้นเนื่องจากความซับซ้อนของโค้ด
การเชื่อมโยงระหว่างมนุษย์จางหาย
เหนือกว่าคุณภาพโค้ด หลายคนกังวลว่า AI หมายถึงอะไรสำหรับพลวัตของทีมและการแบ่งปันความรู้ วิธีดั้งเดิมที่นักพัฒนาเรียนรู้จากกันและกัน - การเขียนโปรแกรมคู่ การอภิปรายเกี่ยวกับสถาปัตยกรรม และการให้คำปรึกษา - กำลังถูกแทนที่ด้วยการโต้ตอบระหว่างมนุษย์กับเครื่องจักร การหันไปหา LLMs แทนที่จะเป็นผู้คนเมื่อเราต้องการคู่หูในการเขียนโปรแกรม คนที่จะร่วมโต้ตอบโซลูชัน สร้างต้นแบบ ร่างสถาปัตยกรรมด้วยกัน หรือช่วยตอบคำถามระดับผู้เชี่ยวชาญเกี่ยวกับส่วนลึกซึ้งของ codebase กำลังกลายเป็นเรื่องปกติ
การเปลี่ยนแปลงนี้มีนัยสำคัญต่อวิธีการแพร่กระจายความรู้ภายในองค์กร นักพัฒนารุ่นจูเนียร์ที่อาจเคยเรียนรู้จากรุ่นพี่ผ่านการตรวจสอบโค้ดและการทำงานร่วมกัน ตอนนี้กำลังได้รับคำติชมหลักจากระบบ AI ความเข้าใจอย่างลึกซึ้งที่มาจากการอธิบายแนวคิดที่ซับซ้อนให้มนุษย์อีกคนฟังกำลังสูญหายไป
การหาจุดสมดุลที่เหมาะสม
ไม่ใช่นักพัฒนาทุกคนที่ต่อต้านการปฏิวัติ AI บางคนพบวิธีที่สร้างสรรค์ในการผนวกเครื่องมือเหล่านี้เข้ากับเวิร์กโฟลว์ของพวกเขา ในขณะที่ยังคงรักษามาตรฐานคุณภาพไว้ นักพัฒนาคนหนึ่งแบ่งปันการเดินทางของพวกเขา: ฉันมีเส้นทางแบบนี้: ใช้ AI เฉพาะสำหรับงานเล็กๆ ประทับใจมันมาก → มอบหมายงานที่ใหญ่ขึ้นให้ AI → โหมดเต็มรูปแบบแบบอัตโนมัติ → ตระหนักว่าฉันยังต้องคิดผ่านโค้ดทั้งหมดอยู่ → กลับไปมอบหมายงานเล็กๆ ให้ AI
แนวทางที่ประสบความสำเร็จมากที่สุดดูเหมือนจะเป็นการใช้ AI สำหรับการวิจัย การสร้าง proof-of-concept และโค้ดชั่วคราว ในขณะที่เก็บการเขียนโค้ดภาพใหญ่ไว้ในมือมนุษย์ ดังที่นักพัฒนาอีกคนระบุไว้: ฉันพบว่า AI มีประโยชน์มากสำหรับการวิจัย proof-of-concept และโค้ดชั่วคราวแบบ 'อันนี้ทำงานได้ แต่ไม่สามารถยอมรับได้ใน production' มันเป็นงานที่ฉันมักจะทำอยู่แล้วก่อนเริ่มจัดการโซลูชันสุดท้าย
แนวทางของนักพัฒนาในการใช้ AI เขียนโค้ด:
- การวิจัยและสร้างต้นแบบ: ใช้ AI สำหรับโค้ดเชิงสำรวจและการพิสูจน์แนวคิด
- ช่วยเหลืองานเล็กน้อย: ใช้งานอย่างจำกัดสำหรับฟังก์ชันหรือยูทิลิตี้เฉพาะเจาะจง
- โหมด Agentic เต็มรูปแบบ: ปล่อยให้ AI จัดการฟีเจอร์ทั้งหมดโดยมีมนุษย์ตรวจสอบ
- แนวทางผสมผสาน: รวมการสร้างโค้ดด้วย AI เข้ากับการปรับแต่งอย่างมีนัยสำคัญโดยมนุษย์
- การต่อต้าน: หลีกเลี่ยงเครื่องมือ AI ทั้งหมดสำหรับโค้ดที่ใช้งานจริง
วิกฤตอัตลักษณ์ทวีความรุนแรง
สำหรับโปรแกรมเมอร์หลายคน นี่ไม่ใช่แค่เรื่องของเครื่องมือและผลผลิตเท่านั้น - มันเป็นเรื่องของอัตลักษณ์ ศาสตร์แห่งการเขียนโปรแกรม ด้วยความสนใจลึกซึ้งและความพึงพอใจในการแก้ปัญหา คือสิ่งที่ดึงดูดหลายคนเข้าสู่วงการ ดังที่นักพัฒนาคนหนึ่งคร่ำครวญ: ในระดับหนึ่ง ฉันรู้สึกไม่พอใจที่ฉันไม่ได้ทำงานอดิเรกของฉันเพื่อการทำงานอีกต่อไป ตอนนี้มันเป็นสิ่งที่แตกต่างไปโดยพื้นฐานแล้ว
ช่องว่างระหว่างผู้ที่มองการเขียนโปรแกรมเป็นเครื่องมือเพื่อไปสู่จุดหมาย กับผู้ที่มองมันเป็นศาสตร์แห่งงานฝีมือ ไม่เคยกว้างขนาดนี้มาก่อน บางคนแย้งว่าการเขียนโค้ดเป็นเครื่องมือเพื่อไปสู่จุดหมาย ไม่ใช่จุดหมายปลายทาง ในขณะที่คนอื่นโต้แย้งว่าการแก้ปัญหาเป็นผลลัพธ์ของการเขียนโปรแกรม ไม่ใช่จุดประสงค์ของการเขียนโปรแกรม ความขัดแย้งทางปรัชญานี้สะท้อนถึงคำถามที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับความหมายของการเป็นโปรแกรมเมอร์ในยุคของ AI
การเปลี่ยนแปลงของการพัฒนาซอฟต์แวร์ผ่าน AI กำลังสร้างความตึงเครียดพื้นฐานระหว่างผลผลิตและคุณภาพ ระหว่างการทำซ้ำอย่างรวดเร็วและความเข้าใจอย่างลึกซึ้ง ขณะที่อุตสาหกรรมกำลังก้าวผ่านช่วงเปลี่ยนผ่านนี้ นักพัฒนากำลังถูกบังคับให้ทบทวนใหม่ว่าการเขียนโค้ดที่ดีและการเป็นโปรแกรมเมอร์ที่มีความรับผิดชอบหมายถึงอะไร เครื่องมืออาจกำลังเปลี่ยนแปลง แต่ความต้องการการพัฒนาซอฟต์แวร์อย่างรอบคอบและไตร่ตรองยังคงมีความสำคัญไม่แพ้กัน
อ้างอิง: The Programmer Identity Crisis