โค้ดที่ AI เขียนให้ เชื่อได้แค่ไหน? เช็คลิสต์ 6 ข้อต้องตรวจก่อนกด commit

เวลามีน้องๆ ถามทีมเราว่า "ใช้ AI เขียนโค้ดให้ แล้วมันรันได้เลย แบบนี้ก็เอาไปใช้ต่อได้ใช่ไหม" คำตอบที่เราตอบบ่อยที่สุดคือ "รันได้ ยังไม่พอครับ" เพราะโค้ดที่ทำงานได้ในเครื่องเรา กับโค้ดที่เอาขึ้นงานจริงแล้วไม่พังทีหลัง มันคนละเรื่องกัน

ทุกวันนี้ AI ช่วยเขียนโค้ดให้ได้เร็วมาก เร็วจนหลายคนเผลอกด commit (บันทึกโค้ดเข้าโปรเจกต์จริง) ทั้งที่ยังอ่านไม่ครบด้วยซ้ำ พอโค้ดขึ้นหน้าจอมาสวยๆ ไม่มีขีดแดง เราก็มักเชื่อไปก่อนแล้วว่ามันถูก ทั้งที่ยังไม่ได้พิสูจน์อะไรเลย

วันนี้ Superdev Academy จะพาไปดูว่า ก่อนจะเอาโค้ดที่ AI เขียนให้ไปใช้จริง เราควรเช็คอะไรบ้าง เป็นเช็คลิสต์ 6 ข้อที่จำง่าย และเอาไปใช้ได้ตั้งแต่บรรทัดถัดไปที่คุณให้ AI ช่วยเขียน

โค้ด "รันได้" ไม่ได้แปลว่าโค้ด "ถูก"

นี่คือกับดักแรกที่ทุกคนเจอ พอ AI เขียนโค้ดมาให้ เรารันแล้วมันไม่ error หน้าจอขึ้นผลลัพธ์สวยงาม สมองเราก็สรุปทันทีว่า "เสร็จแล้ว" ความรู้สึกว่าเสร็จมันมาไวมาก และนั่นแหละคือปัญหา

ความจริงคือ AI เก่งเรื่องทำให้โค้ด ดู ใช้งานได้ มากกว่าทำให้มัน ถูก ในทุกสถานการณ์ มันถูกฝึกมาให้เขียนโค้ดที่หน้าตาเหมือนโค้ดที่ทำงานได้ ซึ่งส่วนใหญ่ก็ทำงานได้จริง แต่ "ส่วนใหญ่" กับ "ทุกครั้ง" คือระยะห่างที่ทำให้ระบบล่มตอนมีคนใช้เยอะๆ

โค้ดที่รันผ่าน ไม่ได้แปลว่าถูก มันแปลว่ายังไม่พังตอนนี้ เท่านั้น

เพราะฉะนั้นหน้าที่ของเราเปลี่ยนไปแล้ว จากคนที่นั่งเขียนโค้ดเองทุกบรรทัด กลายเป็นคนที่ต้อง review (ตรวจทาน) โค้ดที่คนอื่นเขียน และคนอื่นคนนั้นก็คือ AI ที่เขียนไว แต่ไม่รู้จักงานของเราเท่าเรา

ข่าวดีคือทักษะการตรวจแบบนี้ฝึกได้ และมีจุดที่ต้องดูซ้ำๆ ไม่กี่จุด ต่อไปนี้คือ 6 ข้อหลักที่ควรไล่เช็คก่อนกด commit ทุกครั้ง

โค้ดจาก AI ต่างจากโค้ดเพื่อนร่วมทีมตรงไหน

ก่อนเข้าเช็คลิสต์ ขอปูพื้นสั้นๆ ว่าทำไมโค้ดจาก AI ต้องตรวจด้วยสายตาแบบพิเศษ ไม่เหมือนตอนรีวิวงานเพื่อน

เวลาเพื่อนในทีมส่งโค้ดมาให้เรารีวิว เพื่อนคนนั้นเข้าใจงาน รู้ว่าลูกค้าต้องการอะไร และถ้าเขาไม่แน่ใจตรงไหน เขาจะเขียนคอมเมนต์บอกหรือเดินมาถาม เรารู้ได้ว่าจุดไหนที่เขาก็ยังไม่มั่นใจ

แต่ AI ไม่ทำแบบนั้น เวลามันไม่รู้ มันจะเดาแล้วเขียนออกมาด้วยน้ำเสียงมั่นใจเท่าๆ กับตอนที่มันรู้จริง พูดง่ายๆ คือ AI ไม่มีวันบอกเราว่า "ตรงนี้ผมไม่ชัวร์นะ" ทั้งที่จริงมันไม่ชัวร์

ความมั่นใจสม่ำเสมอแบบนี้แหละที่อันตราย เพราะมันทำให้เราการ์ดตก เราเลยต้องตั้งใจตรวจเองในจุดที่ปกติเราจะเชื่อเพื่อนไปแล้ว นี่คือเหตุผลที่การตรวจโค้ด AI ต้องเป็นนิสัยติดตัว ไม่ใช่ทำเฉพาะตอนที่รู้สึกว่าโค้ดดูแปลก เพราะโค้ดที่อันตรายที่สุดคือโค้ดที่หน้าตาปกติดีนี่แหละ

เช็ค 1: เราอธิบายทุกบรรทัดได้ไหม

ข้อนี้สำคัญที่สุด และเป็นข้อที่คนข้ามบ่อยที่สุด

กติกามีข้อเดียว ถ้ามีโค้ดบรรทัดไหนที่ AI เขียนมาแล้วเราอธิบายไม่ได้ว่ามันทำอะไร อย่าเพิ่ง commit

เหตุผลไม่ใช่ว่าโค้ดมันผิด แต่เพราะวันที่มันพังขึ้นมา คนที่ต้องแก้คือเรา ไม่ใช่ AI ลองนึกภาพว่าระบบล่มตอนตีสอง ลูกค้าโทรมา แล้วเราเปิดโค้ดตัวเองขึ้นมาดูแล้วพบว่าอ่านไม่ออกสักบรรทัด เพราะตอนรับมาเราก็แค่ก๊อปวาง ณ จุดนั้นเราจะเริ่มไล่หาสาเหตุจากศูนย์ ทั้งที่มันเป็นโค้ดในโปรเจกต์ของเราเอง

วิธีแก้ง่ายมาก ก่อนรับโค้ดเข้าโปรเจกต์ ให้ถาม AI กลับว่า "อธิบายโค้ดนี้ทีละส่วนให้ฟังหน่อย ว่าแต่ละบรรทัดทำอะไร" แล้วอ่านให้เข้าใจจริงๆ ตรงไหนงงให้ถามต่อจนกระจ่าง ถ้าคำอธิบายมันฟังไม่ขึ้น หรือเราไล่ตามเหตุผลไม่ได้ นั่นคือสัญญาณว่ายังไม่ควรเอาโค้ดก้อนนี้เข้าไป

ขั้นตอนนี้ใช้เวลาไม่กี่นาที แต่เปลี่ยนโค้ดก้อนแปลกหน้าให้กลายเป็นโค้ดที่เราเป็นเจ้าของได้จริง โบนัสคือยิ่งเราให้ AI อธิบายบ่อยๆ เราจะยิ่งอ่านโค้ดเก่งขึ้นเอง ซึ่งเป็นทักษะที่ติดตัวไปตลอด ถ้าใครยังใหม่กับการอ่านโค้ดคนอื่น ลองฝึกจากโปรเจกต์เล็กๆ ก่อนได้ เรารวมไอเดียไว้ในบทความ 5 โปรเจกต์ง่ายๆ สำหรับมือใหม่

เช็ค 2: Business Logic ตรงกับที่เราต้องการจริงไหม

Business Logic (กติกาที่งานของเราต้องเป็น) คือจุดที่ AI พลาดได้แนบเนียนที่สุด เพราะมันไม่รู้ว่าธุรกิจเราต้องการอะไรกันแน่ มันได้แค่เดาจากที่เราพิมพ์บอก และการเดาที่ฟังดูสมเหตุสมผล ก็ยังเป็นการเดาอยู่ดี

ยกตัวอย่างที่เห็นภาพ เราสั่งให้ AI เขียนโค้ดคำนวณส่วนลด มันเขียนออกมารันได้ ตัวเลขขึ้นครบ หน้าตาน่าเชื่อถือ แต่มันดันคิดส่วนลดก่อนบวก VAT ทั้งที่กติกาจริงของร้านเราต้องบวก VAT ก่อนแล้วค่อยลด

ผลที่ได้คือโค้ดที่ทำงานได้ แต่คิดเงินผิดทุกบิล

บั๊กแบบนี้จับยากมาก เพราะไม่มี error ให้เห็น ไม่มีขีดแดง มีแต่ตัวเลขที่ผิดเงียบๆ กว่าจะรู้ตัวก็อาจผ่านไปหลายร้อยออเดอร์แล้ว และพอไปเจอทีหลังก็ต้องตามแก้ข้อมูลย้อนหลังอีกยาว

จุดนี้ AI ช่วยเราไม่ได้เลย เพราะคนที่รู้ว่าอะไรถูกคือเราคนเดียว วิธีตรวจที่ได้ผลคือหยิบเคสจริงมาสักสองสามเคส แล้วลองคิดเลขด้วยมือ เทียบกับผลที่โค้ดคำนวณให้ ถ้าตรงกันทุกเคสค่อยวางใจ โดยเฉพาะโค้ดที่แตะเรื่องเงิน วันหมดอายุ หรือสิทธิ์การเข้าถึง สามอย่างนี้ควรตรวจด้วยมือทุกครั้ง

เช็ค 3: Edge Case — เคสที่ไม่ปกติ

Edge Case (เคสที่อยู่นอกเส้นทางปกติ) คือสถานการณ์ที่ AI มักลืมเขียนเผื่อ มันเก่งเรื่องเขียนโค้ดสำหรับเคสที่ทุกอย่างเป็นไปตามคาด แต่ผู้ใช้จริงไม่ได้ทำตัวตามคาดเสมอไป

ลองไล่ถามตัวเองก่อน commit ว่า ถ้าค่าที่ส่งเข้ามาเป็นค่าว่างล่ะ ถ้าเป็นเลขติดลบล่ะ ถ้าผู้ใช้กรอกภาษาไทยในช่องที่เราคิดว่าจะมีแต่ภาษาอังกฤษล่ะ ถ้าเน็ตหลุดกลางคันตอนกำลังบันทึกล่ะ ถ้ามีคนกดปุ่มส่งรัวๆ พร้อมกันสิบครั้งล่ะ

เคสพวกนี้แหละที่ทำให้ระบบพังตอนขึ้นงานจริง ทั้งที่ตอนเทสต์ในเครื่องด้วยข้อมูลสวยๆ มันผ่านฉลุย

สาเหตุที่ AI มองข้ามเคสพวกนี้ ก็เพราะในหัวมันไม่มีภาพผู้ใช้จริงของเรา มันไม่รู้ว่าลูกค้าเราชอบพิมพ์เบอร์โทรติดขีด ชอบวางเลขบัตรมาทั้งช่องว่าง หรือชอบกดย้อนกลับกลางคัน สิ่งเหล่านี้เรารู้ดีกว่า

เทคนิคที่ใช้ได้จริงคือ ก่อนให้ AI เขียน ให้เราลิสต์ข้อมูลแปลกๆ ที่ผู้ใช้อาจใส่เข้ามาไว้ก่อนสักชุด แล้วค่อยเอาไปไล่ทดสอบทีหลัง การมีลิสต์นี้ติดตัว ทำให้เราไม่ต้องมานั่งนึกสดๆ ทุกครั้ง

เช็ค 4: Security — ช่องโหว่ที่ AI มักมองข้าม

เรื่องความปลอดภัยเป็นอีกจุดที่ห้ามไว้ใจ AI ร้อยเปอร์เซ็นต์ โค้ดที่มันเขียนมาอาจดูเรียบร้อยดี แต่แอบเปิดช่องโหว่ไว้โดยที่เราไม่รู้ตัว

จุดที่เจอบ่อยมีอยู่ไม่กี่แบบ อย่างแรกคือการเอาข้อมูลลับอย่าง API key (กุญแจลับสำหรับเรียกใช้บริการภายนอก) หรือรหัสผ่าน ฝังไว้ในโค้ดตรงๆ ซึ่งพอโค้ดหลุดขึ้นที่สาธารณะเมื่อไหร่ กุญแจก็หลุดตามทันที

อย่างที่สองคือการไม่ตรวจสอบข้อมูลที่ผู้ใช้กรอกเข้ามาก่อนเอาไปใช้ และอย่างที่สามคือการต่อคำสั่งฐานข้อมูลด้วยการเอาข้อความจากผู้ใช้มาต่อกันตรงๆ ซึ่งเปิดช่องให้คนไม่หวังดีส่งคำสั่งอันตรายเข้ามาได้

สาเหตุที่ AI มักพลาดเรื่องนี้ เพราะมันถูกฝึกให้เขียนโค้ดที่ทำงานได้ก่อน ส่วนความปลอดภัยเป็นเรื่องที่ต้องตั้งใจสั่ง ถ้าเราไม่บอก มันก็มักเลือกทางที่ง่ายและสั้นที่สุด ซึ่งบ่อยครั้งไม่ใช่ทางที่ปลอดภัยที่สุด

ทางที่ดีคือถาม AI ตรงๆ ว่าโค้ดนี้มีช่องโหว่ตรงไหนบ้าง แล้วเราค่อยไล่ดูตาม ถ้าอยากลงลึกเรื่องนี้ เราเขียนแยกไว้แล้วในบทความ เขียนโปรแกรมอย่างไรให้ปลอดภัย เทคนิค Secure Coding ที่มือใหม่ต้องรู้ อ่านคู่กับข้อนี้ได้เลย

เช็ค 5: Library ที่ AI แต่งขึ้นมาเอง (Hallucination)

Hallucination (อาการที่ AI มั่วหรือแต่งข้อมูลขึ้นมาเองด้วยความมั่นใจ) เป็นเรื่องที่คนเพิ่งเริ่มใช้ AI มักไม่ทันระวัง

บางครั้ง AI แนะนำให้เราติดตั้ง library (ชุดเครื่องมือสำเร็จรูปที่โค้ดเราเรียกใช้) ที่ฟังดูสมเหตุสมผลมาก ชื่อเท่ วิธีใช้ดูง่าย แต่พอไปหาจริงๆ กลับไม่มี library ตัวนั้นอยู่บนโลกเลย มันแต่งชื่อขึ้นมาเองเพราะมันคิดว่าควรจะมีของแบบนี้

ที่อันตรายกว่านั้นคือ บางทีมีคนไม่หวังดีไปสร้าง library ปลอมตามชื่อที่ AI ชอบแต่งขึ้น เผื่อมีคนหลงติดตั้ง กลายเป็นช่องโหว่ด้านความปลอดภัยไปอีกชั้น เรื่องนี้จึงไม่ใช่แค่เสียเวลา แต่อาจเสียความปลอดภัยด้วย

กฎง่ายๆ คือ ถ้า AI แนะนำเครื่องมือหรือคำสั่งที่เราไม่เคยได้ยิน อย่าเพิ่งเชื่อ ให้เปิดเว็บทางการของมันดูก่อนว่ามีอยู่จริงไหม มีคนใช้เยอะไหม และยังมีคนดูแลอัปเดตอยู่หรือเปล่า

อีกจุดที่ต้องดูคือ ต่อให้ library นั้นมีอยู่จริง มันอาจเก่ามากจนไม่มีคนดูแลแล้ว หรือเลิกทำไปแล้วก็ได้ การเสียเวลาสองสามนาทีเช็คตรงนี้ ช่วยเราไม่ให้เอาของที่ไม่มีอยู่จริง หรือของที่ตายไปแล้ว เข้ามาในโปรเจกต์

เช็ค 6: เทสต์จริง อย่าถาม AI ว่า "ถูกไหม"

ข้อสุดท้าย พอเช็คห้าข้อบนครบแล้ว วิธียืนยันว่าโค้ดใช้ได้จริงคือเอาไปเทสต์ ไม่ใช่ถาม AI กลับว่าโค้ดนี้ถูกไหม

เพราะถ้ามันตอบว่าถูกแล้วครับ เราก็ยังไม่มีหลักฐานอะไรเพิ่มขึ้นเลย มันก็แค่มั่นใจเหมือนเดิม และความมั่นใจของ AI ไม่ใช่หลักฐาน

วิธีที่ดีกว่าคือลองรันด้วยข้อมูลจริงหลายๆ แบบ รวมถึง Edge Case ที่เราลิสต์ไว้ในข้อ 3 แล้วดูด้วยตาว่าผลลัพธ์ตรงกับที่ควรจะเป็นไหมในทุกเคส

ถ้าเริ่มเขียน Unit Test (โค้ดเทสต์อัตโนมัติที่รันตรวจโค้ดของเราซ้ำๆ ได้เอง) เป็นแล้ว จะยิ่งดี เราให้ AI ช่วยร่างเทสต์ให้ก็ได้ แต่หน้าที่เราคือตรวจว่าเทสต์ที่มันร่างครอบคลุมเคสสำคัญจริงไหม ไม่ใช่เทสต์แบบผ่านง่ายๆ เพื่อให้ดูเหมือนมีเทสต์ เพราะเทสต์ที่ตั้งใจให้ผ่าน ไม่ได้พิสูจน์อะไรเลย

สรุปหลักคิดของข้อนี้สั้นๆ การเห็นโค้ดทำงานถูกกับข้อมูลจริงด้วยตาเราเอง เชื่อถือได้กว่าคำรับรองของ AI เสมอ

เริ่มนิสัยนี้ยังไงไม่ให้กินเวลา

พอเห็นเช็คลิสต์ 6 ข้อ หลายคนอาจคิดว่าตรวจขนาดนี้คงช้าน่าดู แต่จริงๆ พอทำจนชิน มันเร็วกว่าที่คิดมาก

เคล็ดลับคือ อย่ารอตรวจทีเดียวตอนจบ ให้ตรวจทีละก้อนเล็กๆ ระหว่างทาง ทุกครั้งที่รับโค้ดจาก AI มาสักส่วน ให้ไล่ในหัวเร็วๆ ว่า อธิบายได้ไหม, ตรงกับที่ต้องการไหม, มีเคสแปลกๆ ที่ยังไม่ได้คิดไหม สามคำถามนี้ใช้เวลาไม่กี่วินาที

ส่วนข้อที่หนักหน่อยอย่าง Security กับการเทสต์ ค่อยทำจริงจังตอนก่อนจะ commit ก้อนใหญ่ พอแบ่งแบบนี้ ภาระมันจะกระจาย ไม่ใช่มากองทีเดียวจนรู้สึกว่าตรวจไม่ไหว

สรุป

ตอบแบบตรงๆ ไม่อ้อม AI เขียนโค้ดเก่งขึ้นทุกวัน แต่มันเขียนให้ดูใช้ได้ เก่งกว่าเขียนให้ถูกจริง หน้าที่ที่เพิ่มเข้ามาของเราจึงเป็นการเป็นคนตรวจ ไม่ใช่แค่คนกด commit ตาม

ทวนเช็คลิสต์ 6 ข้ออีกที ก่อนกด commit ครั้งหน้า อธิบายทุกบรรทัดได้ไหม, Business Logic ถูกไหม, คิดเผื่อ Edge Case หรือยัง, มีช่องโหว่ Security ไหม, library มีอยู่จริงไหม, และเทสต์ด้วยข้อมูลจริงแล้วหรือยัง

เช็คลิสต์นี้ไม่ได้มีไว้ให้กลัวการใช้ AI มันมีไว้ให้เราใช้ AI ได้อย่างมั่นใจ ว่าของที่ส่งออกไปเป็นของที่เรารับผิดชอบได้เต็มปาก มองอีกมุม ทักษะการตรวจโค้ดเป็น กำลังกลายเป็นของมีค่าขึ้นเรื่อยๆ ยิ่ง AI เขียนโค้ดเก่ง คนที่ตรวจเป็นและกล้ารับผิดชอบยิ่งขาดแคลน เรื่องบทบาทที่เปลี่ยนไปนี้ เราเล่าไว้ในบทความ ChatGPT กับการเขียนโค้ด ช่วยได้จริงหรือทำลายโปรแกรมเมอร์ ด้วย

ที่อยากฝากไว้คือ เครื่องมือจะเก่งแค่ไหน คนที่เข้าใจว่าโค้ดทำงานยังไงและกล้ารับผิดชอบมัน จะเป็นคนที่ AI แทนไม่ได้เสมอ และทักษะการอ่านโค้ดให้ออก ตรวจให้เป็น ก็ฝึกได้จากการลงมือทำทุกวันนี่แหละ ถ้าอยากปูพื้นฐานให้แน่นตั้งแต่ต้น ลองอ่าน เครื่องมือที่ช่วยเพิ่มความเร็วในการเขียนโค้ดสำหรับมือใหม่ ต่อได้เลย