5 ประเด็นร้อน AI จาก GitHub: อนาคตของ RAG, MCP และการอ่านโค้ด

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

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

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

เราได้ร่วมสำรวจเรื่องราวเหล่านี้และประเด็นอื่นๆ อีกมากมายในตอนล่าสุดของ GitHub Podcast!

หากคุณยังไม่พร้อมที่จะฟังแบบเต็มๆ นี่คือส่วนหนึ่งของประเด็นร้อนเกี่ยวกับ AI ที่เราได้หยิบยกมาพูดคุยพร้อมสรุปสิ่งที่เราได้เรียนรู้ร่วมกัน

Hot take #1: “คุณไม่จำเป็นต้องอ่านโค้ดที่สร้างโดย AI”

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

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

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

บางครั้งงานตรวจสอบจะเริ่มขึ้นตั้งแต่ก่อนที่ AI Agent จะลงมือเขียนด้วยซ้ำ โดยเริ่มจากการอ่านระบบปัจจุบัน วางแผนความเชื่อมโยงของโค้ด (Dependencies) ระบุเคสที่อาจเกิดปัญหา (Edge cases) เพื่อให้เข้าใจล่วงหน้าว่าโค้ดควรทำงานอย่างไรและจุดใดที่อาจเกิดข้อผิดพลาด

ขณะที่ในกรณีอื่นๆ ตัวโค้ดที่สร้างขึ้นนั่นแหละที่ต้องการความสนใจมากที่สุด ซึ่งคุณจำเป็นต้องตรวจสอบทั้งระบบการจัดการข้อผิดพลาด (Error handling), สิทธิ์การเข้าถึง (Permissions), ประสิทธิภาพการทำงาน และการทดสอบระบบ (Tests)

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

Hot take #2: “บริษัทต่างๆ จะไม่จ้างคุณถ้าคุณไม่ใช้ AI”

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

อย่างไรก็ดี ไม่มีใครคาดหวังให้นักพัฒนาทุกคนต้องมีกระบวนการทำงาน (Workflow) แบบเดียวกัน ใช้เครื่องมือเดียวกัน หรือมีความกระตือรือร้นในระดับที่เท่ากันทั้งหมด สิ่งสำคัญที่บริษัทมองหามากกว่าคือ "การใช้วิจารณญาณ"

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

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

คำตอบที่เหมาะสมกว่าคือการอธิบายอย่างชัดเจนว่าคุณมีกระบวนการทำงานอย่างไร สิ่งใดที่คุณไว้วางใจให้เครื่องมือช่วยทำ และจุดใดที่คุณยังคงต้องควบคุมดูแลด้วยตัวเอง ความคล่องแคล่วในลักษณะนี้ต่างหากที่กำลังกลายเป็นทักษะวิชาชีพที่สำคัญ

Hot take #3: “Skills ฆ่า MCP แล้ว”

เรื่องนี้ไม่เป็นความจริง เพราะทั้งสองสิ่งถูกออกแบบมาเพื่อแก้ปัญหาคนละอย่างกัน โดย Model Context Protocol (MCP) ช่วยให้ AI Agent มีมาตรฐานในการเชื่อมต่อกับเครื่องมือและข้อมูลภายนอก ซึ่งมีความสำคัญมากเมื่อต้องการให้ระบบต่างๆ ทำงานร่วมกันได้อย่างน่าเชื่อถือ ผ่านวิธีเรียกใช้เครื่องมือและดึงบริบทที่มีโครงสร้างชัดเจน

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

ดังนั้น MCP จึงทำหน้าที่ให้สิทธิ์การเข้าถึงข้อมูล (Access) ส่วน Skills จะช่วยอธิบายว่าจะใช้สิทธิ์การเข้าถึงนั้นอย่างไรให้เกิดประสิทธิภาพสูงสุด คุณจึงไม่จำเป็นต้องเลือกฝ่ายใดฝ่ายหนึ่ง แต่ควรใช้มาตรฐานร่วมกันเพื่อผสมผสานจุดเด่นของทั้งสองสิ่งเข้าด้วยกัน

Hot take #4: “RAG ตายแล้ว”

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

ระบบ Retrieval-augmented generation (RAG) ทำหน้าที่ป้อนข้อมูลที่เกี่ยวข้องจากภายนอกให้แก่ AI เช่น เอกสารประกอบ (Documentation) หรือประวัติการดูแลลูกค้า ซึ่งช่วยให้โมเดลทำงานได้แม่นยำยิ่งขึ้นโดยไม่ต้องพึ่งพาเฉพาะข้อมูลที่ใช้ฝึกมาเท่านั้น

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

ในความเป็นจริง ทั้ง Agents, Skills, MCP และ RAG สามารถทำงานร่วมกันในกระบวนการเดียวได้อย่างราบรื่น การมองว่าเทคโนโลยีเหล่านี้เป็นคู่แข่งกันจะทำให้เราพลาดโอกาสในการเรียนรู้วิธีการสร้างงานด้วย AI อย่างมีประสิทธิภาพ

Hot take #5: “ถ้าคุณต้อง fine-tune โมเดลสำหรับ codebase ของคุณ แสดงว่าโค้ดคุณแย่”

แม้การ Fine-tune โมเดลจะมีเหตุผลที่สมควรอยู่บ้าง แต่โมเดลสมัยใหม่ในปัจจุบันได้เรียนรู้สถาปัตยกรรมและรูปแบบโค้ดทั่วไปมามากมายมหาศาลแล้ว ดังนั้น หากโมเดลยังไม่สามารถเข้าใจซอร์สโค้ดของคุณได้ ก็มีโอกาสสูงที่เพื่อนร่วมทีมใหม่จะทำงานได้ลำบากเช่นกัน

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

การพัฒนาซอฟต์แวร์ด้วย AI (AI-assisted development) จะให้ผลตอบแทนที่ดีแก่ซอร์สโค้ดที่มีการแสดงเจตจำนงอย่างชัดเจน ซึ่งถือเป็นแนวโน้มที่ดีสำหรับวงการนี้

งานจริงน่าสนใจกว่าการดีเบต

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

ตัวอย่างเช่น โปรเจกต์ Pollinations AI ที่กำลังทดลองแพลตฟอร์ม Generative AI ให้ผู้ร่วมพัฒนาได้รับเครดิตจากการปรับปรุงระบบ ซึ่งเป็นแนวทางที่ช่วยตอบคำถามว่า AI จะเข้ามาลดอุปสรรคในการมีส่วนร่วมกับ Open Source ได้อย่างไร

หรือโปรเจกต์ Avian Visitors ที่สร้างจอแสดงผล e-ink สำหรับตรวจจับเสียงนก โดยผสมผสาน Raspberry Pi, ภาพนกจาก AI และเอกสารประกอบอย่างใส่ใจ ซึ่งแสดงให้เห็นถึงการนำ AI มาใช้งานจริงในรูปแบบที่สร้างสรรค์

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

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

สิ่งที่สำคัญที่สุดคือการลงมือทำสิ่งต่างๆ จากสิ่งที่คุณได้เรียนรู้ และอย่าลืมกดติดตาม GitHub Podcast เพื่อที่คุณจะได้ไม่พลาดในตอนต่อๆ ไป!