เจาะประเด็น
AI / Engineering
LinkedIn สร้างทีม AI Review โค้ดของตัวเอง เพราะของสำเร็จรูปมันใช้ไม่ได้กับสเกลนี้
ที่บริษัทระดับหมื่นล้านบรรทัดโค้ด การจ้างคนนั่งไล่ review ทุก pull request มันไม่ใช่ทางรอดอีกต่อไป แล้วทางรอดของเขาคืออะไร?
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
การเอา AI สำเร็จรูปไปวางไว้หน้ากองโค้ดทั้งบริษัทแล้วหวังว่ามันจะเก่งเอง มันคือจินตนาการของคนที่ไม่เคยเจอโค้ดเบสระดับองค์กรจริงๆ
เอาล่ะ ฟังทางนี้ก่อน ถ้าคุณคิดว่าการเอา AI มาช่วย review โค้ดคือการโยนโค้ดทั้งหมดให้ ChatGPT แล้วรอมันฟันธงว่า "อันนี้ดี อันนี้ห่วย" ขอบอกเลยว่าคุณคิดผิดถนัด วิศวกรของ LinkedIn เพิ่งออกมาเปิดเผยว่าพวกเขาสร้างแพลตฟอร์ม AI review โค้ดแบบ multi-agent ขึ้นมาเองทั้งหมด เพราะของสำเร็จรูปในตลาดมันไม่ตอบโจทย์กับขนาดโค้ดเบสระดับพวกเขา และถ้าใครบอกว่า "ใช้ของสำเร็จรูปก็ได้" แปลว่าคนนั้นไม่เคยบริหารโค้ดระดับองค์กรที่มี dev หลายพันคนจริงจัง
ประเด็นมันไม่ได้อยู่ที่ว่า AI ฉลาดพอจะอ่านโค้ดเข้าใจหรือเปล่า แต่เป็นเรื่องของ "บริบท" ล้วนๆ บริษัทอย่าง LinkedIn มีโค้ดเบสที่ถูกเขียนและแก้มาหลายปี มี design pattern เฉพาะตัว มีสถาปัตยกรรมภายในที่คนนอกหรือโมเดลทั่วไปไม่มีทางรู้ถ้าไม่ได้รับการสอนมาโดยเฉพาะ การเอาตัว AI review ทั่วไปไปวางไว้หน้ากองโค้ดแบบนี้ มันจะได้ผลลัพธ์เป็น "เสียงรบกวน" มากกว่าความเห็นที่มีประโยชน์ — เหมือนเอานักศึกษาใหม่ไปนั่งตรวจงานของสถาปนิกมากประสบการณ์ แล้วมันก็จะทักทุกอย่างที่ดูไม่ตรงตำรา ทั้งที่ของจริงมันต้องปรับตามบริบท
ปัญหาของการ review โค้ดในสเกล LinkedIn ไม่ใช่แค่เรื่องปริมาณ แต่เป็นเรื่อง "คุณภาพของ feedback" ด้วย ถ้าคุณมี dev พันคน ส่ง pull request เข้ามาวันละเป็นร้อยๆ อัน คุณจะไม่มีวันมีมนุษย์ไปนั่ง review ครบทุกอันได้ทัน และถ้าคุณใช้ AI ทั่วไป มันจะทักทุกอย่างที่เบี่ยงเบนจาก "ตำรา" ซึ่งส่วนใหญ่เป็น noise ที่ dev จริงต้องมานั่งอ่านแล้วปัดทิ้ง — เสียเวลากว่าไม่มี AI มาช่วยอีก
ทีมวิศวกรของ LinkedIn เลยตัดสินใจว่า ถ้าจะทำ ก็ต้องทำแบบจริงจัง พวกเขาสร้างแพลตฟอร์มที่เข้าใจ "บริบทขององค์กร" อย่างลึกซึ้ง ตั้งแต่วิธีการเขียนโค้ดของแต่ละทีม ไปจนถึงกฎและมาตรฐานภายในที่ไม่ได้เขียนไว้ในคู่มือ แต่เป็นที่รู้กันในหมู่ dev รุ่นพี่
หัวใจสำคัญของระบบนี้คือการมองว่า "AI code review" ไม่ใช่แค่ของเล่นเสริม แต่เป็น "production infrastructure" — โครงสร้างพื้นฐานที่ต้องมี SLA มีการ monitor มีการวัดผล ต้องเสถียร ไม่ใช่โมเดลที่ใครอยากได้ก็เสียบเข้าไปใช้แบบไม่มีใครรับผิดชอบ พวกเขารักษาระดับความแม่นยำด้วยการตัด "hallucination" ทิ้งไปให้เหลือน้อยที่สุด และกรอง "low-signal feedback" ออกไปก่อนที่จะไปถึงมือ dev
การออกแบบแบบ multi-agent ไม่ใช่เรื่องบังเอิญ มันคือการแก้ปัญหาที่ว่า "โมเดลเดียวไม่สามารถเก่งได้ทุกเรื่อง" บาง agent ถนัดเรื่อง security บางตัวถนัดเรื่อง performance บางตัวถนัดเรื่องความถูกต้องตาม business logic แล้วระบบก็เอา feedback จากหลายๆ ตัวมาประมวลผลรวมกันอีกที ก่อนจะสรุปเป็นความเห็นที่ dev คนหนึ่งอ่านแล้วเข้าใจได้ในเวลาอันสั้น
สิ่งที่ LinkedIn ทำคือการยอมรับความจริงที่หลายองค์กรไม่อยากยอมรับ: การ review โค้ดด้วยมนุษย์มันไปไม่ไหวแล้วในสเกลนี้ และ AI สำเร็จรูปมันไม่ได้ถูกออกแบบมาให้เข้าใจ "โค้ดเบสเฉพาะของคุณ" มันถูกฝึกมาด้วยข้อมูลสาธารณะ ซึ่งหมายความว่ามันรู้จัก "โค้ดทั่วไป" แต่ไม่รู้จัก "โค้ดของคุณ" — สองอย่างนี้ต่างกันราวฟ้ากับเหว
การลงทุนสร้างระบบของตัวเองแบบนี้ไม่ใช่เรื่องเล่นๆ มันต้องใช้ทั้งทรัพยากร เวลา และทีมวิศวกรที่เข้าใจทั้ง AI และระบบภายในของบริษัทอย่างลึกซึ้ง แต่สำหรับบริษัทที่โค้ดคือหัวใจของธุรกิจ มันคือการลงทุนที่คุ้มค่า และผมคิดว่านี่คือเทรนด์ที่เราจะได้เห็นมากขึ้นเรื่อยๆ — องค์กรใหญ่ๆ เริ่มรู้แล้วว่าของสำเร็จรูปไม่ตอบโจทย์ และต้องสร้างของเฉพาะทางขึ้นมาเอง
อีกประเด็นที่น่าสนใจคือการที่พวกเขาจริงจังกับเรื่อง "ลดเสียงรบกวน" มากขนาดไหน ในโลกของ AI review โค้ด ตัวชี้วัดความสำเร็จไม่ได้อยู่ที่ว่า "เจอ bug ได้กี่ตัว" แต่อยู่ที่ว่า "dev เสียเวลาไปกับ feedback ที่ไร้สาระกี่ชั่วโมง" ระบบที่ดีต้องรู้จัก "ไม่พูด" เมื่อไม่มีอะไรจะพูด และรู้จัก "พูดเฉพาะเรื่องที่สำคัญจริงๆ" — หลักคิดง่ายๆ แต่มีน้อยระบบที่จะทำได้จริง
เข้าใจบริบทองค์กร
AI ต้องถูกสอนให้รู้จัก design pattern และสถาปัตยกรรมภายในของ LinkedIn ไม่ใช่แค่ความรู้ทั่วไปจากอินเทอร์เน็ต
มองเป็นโครงสร้างพื้นฐาน
ต้องมี SLA, การ monitor และการวัดผลเหมือนระบบ production ทั่วไป ไม่ใช่ของทดลองเล่น
ตัด noise ทิ้ง
ลด hallucination และ low-signal feedback เพื่อให้ dev โฟกัสกับสิ่งที่สำคัญจริงๆ ไม่ใช่เสียเวลากับขยะ
สุดท้ายแล้ว สิ่งที่ LinkedIn ทำคือการตั้งคำถามกับ "ทางเลือกสำเร็จรูป" ทั้งหมด แล้วกลับมาคิดตั้งแต่ต้นว่าอะไรคือสิ่งที่องค์กรตัวเองต้องการจริงๆ มันเป็นวิธีคิดที่ควรค่าแก่การปรบมือ และเป็นบทเรียนที่ทุกองค์กรที่มีทีม dev ขนาดใหญ่ควรศึกษาไว้ เพราะอนาคตของการ review โค้ดไม่ได้อยู่ที่ "ใช้ AI หรือไม่ใช้" แต่อยู่ที่ "AI แบบไหนที่ถูกออกแบบมาให้เข้ากับบริบทของเรา" ต่างหาก
บทเรียนจาก LinkedIn คือ AI review โค้ดที่ดีไม่ได้วัดที่ความฉลาดของโมเดล แต่วัดที่ความเข้าใจบริบทของโค้ดเบสคุณ และความสามารถในการ "เงียบ" เมื่อไม่มีอะไรจะพูด องค์กรไหนที่ยังคิดว่าใช้ของสำเร็จรูปแล้วจบ จะได้เรียนรู้บทเรียนนี้แบบจ่ายแพง
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 5
กำลังโหลดความคิดเห็น...