เจาะประเด็น
AI / Dev Practices
Claude Code เก่งทุกอย่างยกเว้นเขียนโค้ด? วิศวกรสายฮาร์ดคอร์ชี้ชัด ปัญหาไม่ได้อยู่ที่ AI แต่อยู่ที่คน
สองวิศวกรที่ใช้ AI จริงในงานจริงไม่ใช่แค่ทดลอง เล่าประสบการณ์ที่ทำให้พวกเขาคิดว่า AI ยังใช้แทนคนเขียนโค้ดไม่ได้ในโปรเจกต์ระดับ production
ทีมข่าว เอไอไทย.com
⏱ อ่าน 5 นาที
ถ้า AI เขียนโค้ดเก่งขนาดนั้น ทำไมคนที่ใช้มันจริงในงานจริงถึงบอกว่ามันใช้ไม่ได้กับโค้ดเก่า? บางทีคำตอบอาจไม่ใช่เรื่องเทคโนโลยี แต่เป็นเรื่องวิธีคิดของคนต่างหาก
เรื่องนี้มันน่าสนใจตรงที่มันไม่ใช่คอนเทนต์โปรโมต AI แบบที่เราเจอเกลื่อนตามอินเทอร์เน็ต แต่เป็นบทสนทนาจาก InfoQ Podcast ที่ Asgaut Mjølne Söderbom และ Ola Hast สองวิศวกรผู้มากประสบการณ์ นั่งเล่าประสบการณ์จริงในการใช้ Claude Code ทำงานกับ codebase ขนาดใหญ่ที่ไม่ได้เกิดในยุค AI
ฟังดูเหมือนเรื่องปกติที่ใครๆ ก็พูดถึง แต่ประเด็นมันอยู่ที่พวกเขาพูดตรงกันข้ามกับกระแสหลักเป๊ะๆ นั่นคือ "Claude Code ดีสำหรับทุกอย่าง ยกเว้นการเขียนโค้ด" ฟังแล้วแบบ... อ้าวเหรอ? แล้วที่บริษัทเทคยักษ์ใหญ่โปรโมตกันหนำเล่าว่า AI แทนที่โปรแกรมเมอร์ได้แล้ว มันคืออะไรกันแน่?
ก่อนอื่นต้องทำความเข้าใจก่อนว่า คนสองคนนี้ไม่ใช่พวกอนุรักษ์นิยมที่กลัวเทคโนโลยี พวกเขาคือคนที่ใช้ continuous deployment และ pair engineering กันมานานแล้ว นั่นหมายความว่าพวกเขาเปิดรับเครื่องมือใหม่ๆ และการเปลี่ยนแปลงอยู่ตลอด แต่พอมาเจอ Claude Code ในโค้ดเบสขนาดใหญ่ที่เต็มไปด้วยของเก่าสะสมมานานหลายปี พวกเขากลับพบว่ามันไม่เวิร์กอย่างที่โฆษณาไว้จริงๆ
สาเหตุหลักที่ทำให้ AI เจ๋งๆ อย่าง Claude Code พลาดในโค้ดเบสแบบ brownfield ก็คือโค้ดพวกนั้นมันไม่มี "บรรยากาศแบบ AI" อยู่เลย มันเต็มไปด้วยการตัดสินใจที่สั่งสมมาจากอดีต ความไม่สมบูรณ์แบบ และบริบทเฉพาะขององค์กรที่ไม่มีอยู่ในเทรนนิ่งดาต้าของโมเดล AI ไหนๆ ทั้งสิ้น
ลองนึกภาพตามนะครับ โค้ดเบสที่เขียนกันมาสิบปี มีเทคนิคเก่าๆ ที่ไม่มีใครกล้าแตะ มี naming convention แปลกๆ ที่คนรุ่นก่อนตั้งไว้ มี business logic ที่ซ่อนอยู่ในชั้นเชิงที่ไม่น่าเชื่อ AI มองเห็นแค่ syntax แต่ไม่เห็น "จิตวิญญาณ" ของโค้ด พอมันเสนอโค้ดใหม่ให้ มันก็เหมือนคนที่อ่านหนังสือคู่มือมาทั้งเล่ม แต่ไม่เคยลงมือทำจริง มันดูถูกต้อง แต่พอใส่เข้าไปในระบบจริง แตกกระจายทันที
สิ่งที่สองวิศวกรนี้ค้นพบ คือการที่ AI เก่งในการสรุปเอกสาร เขียนเทสต์ หรือสร้างโค้ดชิ้นเล็กๆ ที่เป็นอิสระต่อกัน แต่พอเป็นงานที่ต้องเข้าใจระบบทั้งหมดแล้วแก้ไขให้เข้ากับโครงสร้างเดิม มันกลับทำได้แย่มาก พวกเขาจึงสรุปว่ามันเหมาะกับงาน "รอบข้าง" มากกว่าตัวจริง
ส่วนตัวผมคิดว่าเรื่องนี้มันสะท้อนอะไรบางอย่างที่ใหญ่กว่านั้นมาก มันคือบทเรียนว่าคนในวงการ tech ชอบวิ่งตาม " vibes" มากเกินไป พอมีอะไรใหม่ๆ ออกมา ทุกคนก็แห่ไปเมนต์กันบนโซเชียลว่ามันเปลี่ยนโลกแล้ว แต่พอถามว่ามีใครเอาไปใช้กับงานจริงที่ไม่ได้สวยหรูเหมือนในเดโม่บ้าง? ส่วนใหญ่เงียบ
สิ่งที่พวกเขาพูดถึงในพอดแคสต์เรื่อง "Mob Programming" คือทางออกที่แท้จริง มันคือการที่คนหลายคนนั่งทำงานด้วยกัน จ้องจอเดียวกัน คุยกันตลอดเวลา แชร์บริบทซึ่งกันและกัน ซึ่งเป็นสิ่งที่ AI ทำไม่ได้ เพราะ AI ไม่มี "ประสบการณ์ร่วม" กับทีม มันไม่รู้ว่าทำไมโค้ดบรรทัดนี้ถึงต้องเขียนแบบนี้ มันไม่รู้ว่าลูกค้าคนนี้ชอบอะไร
ฟังดูเป็นประโยคที่แรงและแหกกระแส แต่ถ้าเรามองในมุมของคนที่ต้องดูแลระบบที่เต็มไปด้วยของเก่า ผมว่ามันคือความจริงที่หลายคนไม่อยากยอมรับ AI มันเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการเริ่มต้นโปรเจกต์ใหม่ๆ หรือการสร้างสิ่งที่ไม่เคยมีมาก่อน แต่มันแย่มากสำหรับการซ่อมแซมหรือต่อยอดสิ่งที่มันไม่เคยเห็นมาก่อน
นี่ไม่ได้หมายความว่า AI ห่วยนะครับ มันหมายความว่าเราต้องเข้าใจข้อจำกัดของมันให้ถูกต้อง การใช้ AI ในโค้ดเบสเก่าๆ โดยไม่มีความเข้าใจบริบทพอ มันเหมือนการเอาค้อนปอนด์ไปตอกตะปูที่เล็กนิดเดียว ได้ผลแต่ก็พังของอื่นไปด้วย
สุดท้ายแล้ว สิ่งที่บทสนทนานี้บอกกับเราคือ "ทักษะมนุษย์" อย่างการสื่อสาร การทำงานร่วมกัน และการเข้าใจบริบท ยังคงเป็นสิ่งที่ AI ทดแทนไม่ได้ และในโลกที่โค้ดเบสส่วนใหญ่ของโลกคือ brownfield codebase ที่เต็มไปด้วยร่องรอยของอดีต Mob Programming อาจเป็นคำตอบที่ดีกว่า AI Superpowersied เสียอีก
AI คือเพื่อนร่วมทีมที่ดี แต่ยังไม่ใช่คนเขียนโค้ดหลักในโปรเจกต์ใหญ่ๆ ที่สั่งสมประวัติศาสตร์มานาน ถ้าอยากให้ AI ทำงานได้จริง ต้องเริ่มจากทำให้โค้ดเบสของคุณ "อ่านง่าย" สำหรับมนุษย์ก่อน แล้วค่อยให้ AI มาช่วย ไม่ใช่หวังพึ่งมันเป็นพระเจ้า
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...