เจาะลึกเบื้องหลังโค้ด: ทำไมการลงมือเขียนด้วยมือยังสร้างความต่างในยุค AI
บทความสะท้อนมุมมองจากคอมมูนิตี้ Dev.to ว่าด้วยความสำคัญของความเข้าใจ ความฝืดในการทำงาน (Friction) และจริยธรรมของ AI
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- บทความนี้ต่อยอดจากกระแสตอบรับของบทความก่อนหน้าเกี่ยวกับที่มาของโค้ด
- ถอดบทเรียนจากความเห็นของเหล่านักพัฒนาบน Dev.to เช่น @darkwiiplayer และ @madsendev
- ไขข้อสงสัยเรื่องความต่างระหว่างการเขียนโค้ดด้วยมือกับการสั่งงาน AI
- ตอกย้ำว่า 'ความฝืด' ระหว่างเขียนโค้ดคือหัวใจสำคัญของการสร้างความเข้าใจที่แท้จริง
หลังจากที่ผมได้เผยแพร่บทความชื่อ 'Understanding Over Origin' ออกไป สิ่งที่ตามมาคือการพูดคุยและแลกเปลี่ยนมุมมองที่ยอดเยี่ยมจากนักพัฒนาทั่วโลกในช่องคอมเมนต์ แม้จะมีความเห็นที่เห็นต่างกันบ้าง แต่นั่นคือเป้าหมายสำคัญของการสร้างคอมมูนิตี้ที่มีสุขภาพดี ทว่ายิ่งผมได้พูดคุยมากเท่าไร ผมก็ยิ่งตระหนักถึงความจริงข้อหนึ่งเกี่ยวกับวิธีการทำงานของตัวเอง นั่นคือผมยังคงเลือกที่จะเขียนโค้ดส่วนใหญ่ด้วยมือ และนั่นคือส่วนที่ทำให้ผมรู้สึกภาคภูมิใจมากที่สุด
นี่ไม่ใช่การทำตัวเป็นผู้กั้นขวางความรู้ (Gatekeeping) หรือความพยายามปกป้องตัวตนแบบโบราณ แต่ออกจะเป็นการยอมรับตรงๆ ว่าบทความชิ้นแรกของผมนั้นยังขาดองค์ประกอบบางอย่างไป การพูดคุยกับ @darkwiiplayer กลายเป็นการถกเถียงที่ผมชอบที่สุด เพราะมันทำให้ผมต้องขบคิดกับไอเดียที่ยังไม่สมบูรณ์ และนำมาสู่บทความชิ้นนี้
ก่อนอื่นผมต้องขอขอบคุณคอมเมนต์จาก @unitbuilds ที่มองว่ามาตรฐานการทดสอบ (Benchmarking) ระดับสากลคือสิ่งพิสูจน์ความถูกต้องของซอฟต์แวร์ยุคใหม่ เช่นเดียวกับวงการวิทยาศาสตร์ นอกจากนี้เขายังชี้ให้เห็นประเด็นสำคัญว่าภาระความรับผิดชอบ (Burden of correctness) ยังคงอยู่ที่ตัวนักพัฒนาที่เซ็นชื่ออนุมัติ Pull Request นั้นๆ อยู่เสมอ เช่นเดียวกับ @madsendev ผู้จุดประกายบทความนี้ ที่เสนอแนวคิดน่าสนใจว่าโปรเจกต์ที่ใช้ AI ช่วยควรมีระบบทดสอบความเข้าใจของตัวผู้สร้างเอง เพื่อพิสูจน์ว่าเรารู้จริงในสิ่งที่สร้างขึ้นมาหรือไม่
"Maintenance receipts are much harder to fake."
komo
ประโยคสั้นๆ จาก @komo ชิ้นนี้ได้เปลี่ยนกรอบความคิดของผมไปอย่างสิ้นเชิง การทดสอบ การแก้บั๊ก การจัดการกับอุบัติเหตุในระบบ (Production incidents) และการ refactor โค้ด ล้วนทิ้งร่องรอยหลักฐานที่แสดงว่าไม่ใช่แค่ใครสร้างมันขึ้นมา แต่ใครคือคนที่เข้าใจ ดูแล และรับผิดชอบมันในระยะยาว ซึ่งเป็นสิ่งที่ยากจะเสแสร้งทำขึ้นมาได้
ในมุมมองเชิงวิเคราะห์ การถกเถียงเรื่อง AI ในวงการซอฟต์แวร์ปัจจุบันมักถูกแบ่งออกเป็นสองชั้น (Layers) ชั้นแรกคือเรื่องของคุณภาพโค้ด ความเข้าใจ และความสามารถในการดูแลรักษา ซึ่งเป็นสิ่งที่นักพัฒนาส่วนใหญ่ถกเถียงกัน ส่วนชั้นที่สองซึ่งลึกซึ้งกว่าคือเรื่องของจริยธรรม ข้อมูลฝึกฝน (Training data) และความยินยอม (Consent) ของเจ้าของโค้ดต้นทาง การที่เราเข้าใจทั้งสองเลเยอร์นี้พร้อมกันจะช่วยให้เรามองเห็นภาพรวมของอุตสาหกรรมไอทีได้รอบด้านยิ่งขึ้น
อีกหนึ่งความเห็นที่เข้ามาช่วยเปิดมุมมองใหม่คือ @fromzerotoship ผู้สร้างเครื่องมือภายในองค์กรกว่า 20 ชิ้นด้วย AI สำหรับโรงพยาบาล แม้พวกเขาจะไม่สามารถอธิบายโค้ดทีละบรรทัดได้ตามมาตรฐานดั้งเดิม แต่พวกเขากลับแสดงความสามารถในการรับมือกับความผิดพลาดของระบบได้อย่างยอดเยี่ยม สิ่งนี้ทำให้ผมตระหนักว่าแก่นแท้ที่แท้จริงไม่ใช่การมานั่งเถียงว่าใครเป็นคนพิมพ์โค้ด แต่คือความสามารถในการรักษาให้ระบบมีชีวิตรอดต่อไปต่างหาก
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อผมเขียนโค้ดด้วยมือ ผมต้องเผชิญหน้ากับปัญหาแบบเรียลไทม์ ผมชนกำแพง วิธีการของผมใช้ไม่ได้ผล ผมต้อง refactor และค้นพบพื้นที่ปัญหาผ่านข้อจำกัดและความล้มเหลว กระบวนการนี้ทำให้ผมต้องตัดสินใจเลือกเส้นทางที่ได้สำรวจด้วยตัวเองจริงๆ ในขณะที่การใช้ AI เป็นการอธิบายสิ่งที่เราต้องการ เลือกตัวเลือกที่ AI สينค้ามาให้ และทำหน้าที่เป็นผู้คัดสรร (Curator) มากกว่าผู้สำรวจ
ทั้งสองวิธีสามารถสร้างโค้ดที่ดีได้เหมือนกัน แต่เส้นทางสู่ความเข้าใจนั้นแตกต่างกันอย่างสิ้นเชิง การเขียนด้วยมือมอบความฝืด (Friction) ที่นำมาซึ่งอินไซต์และการตัดสินใจที่ดีในก้าวถัดไป ส่วนการใช้ AI เน้นไปที่การเลือก การใช้งาน และการตรวจสอบความถูกต้อง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น