- "การทดลองชวนสับสนที่เปลี่ยนวิธีคิดเรื่องการวิเคราะห์โค้ดด้วย AI"
- พบว่าสถานการณ์ที่ AI แบบเดิมมักล้มเหลวขณะวิเคราะห์โค้ดเบส React เกิดขึ้นบ่อยครั้ง
- จึงตระหนักว่าสาเหตุมาจากวิธีวิเคราะห์แบบอ่านทีละบรรทัด เหมือนนักพัฒนาระดับจูเนียร์ที่เพิ่งเริ่มอ่านโค้ดเป็นครั้งแรก
ความต่างระหว่างช่วงบูตแคมป์กับกรอบความคิดแบบซีเนียร์
- ตอนเป็นจูเนียร์ มักอ่านไฟล์ตามลำดับและไล่ทีละบรรทัด จนหลงทางได้อย่างรวดเร็ว
- นักพัฒนาอาวุโส เมื่อดู PR ขนาดใหญ่จะใช้แนวทางดังนี้
- ตรวจดูไฟล์สำคัญก่อน
- จัดกลุ่มการเปลี่ยนแปลงตามฟังก์ชันการทำงาน
- ทำความเข้าใจสถาปัตยกรรมโดยรวมก่อน แล้วค่อยดูรายละเอียดการ implement ภายหลัง
- จึงตัดสินใจนำแนวทางนี้มาใช้กับ AI
การทดลอง
- ลองใช้วิธีจัดกลุ่มไฟล์ตามฟังก์ชัน และให้ข้อมูลบริบทของแต่ละกลุ่มแก่ AI ก่อน
- ในโค้ดตัวอย่างมีการนิยามอินเทอร์เฟซ
FileGroup และประมวลผลไฟล์โดยจัดกลุ่มตามฟังก์ชันที่เกี่ยวข้องและขนาดไฟล์
- สร้างพรอมป์ต์ในระดับกลุ่มเพื่อบอก AI ว่า "นี่คือพื้นที่ฟังก์ชันอะไร และควรโฟกัสดูอะไรเป็นหลัก"
ช่วงเวลาของการเปลี่ยนแปลงที่น่าทึ่ง
- เดิมที AI มักตอบแบบง่าย ๆ ว่า "มีตรรกะการยืนยันตัวตนด้วยโทเค็น JWT อยู่"
- แต่กลับเริ่มเสนอข้อสังเกตระดับนักพัฒนาอาวุโส เช่น "ผลกระทบที่อาจมีต่อการเชื่อมต่อ WebSocket หรือความเป็นไปได้ของ race condition ใน PR ที่เพิ่งถูกรวม"
- AI เริ่มชี้ให้เห็นประเด็นโดยคำนึงถึงบริบทของทั้งระบบ
สิ่งที่เปลี่ยนไปจริง ๆ
- แก่นสำคัญไม่ใช่การใช้โมเดลแมชชีนเลิร์นนิงที่ซับซ้อนขึ้น แต่คือการมอบลำดับการคิดแบบนักพัฒนาอาวุโสให้ AI
- ให้บริบทมาก่อน: เริ่มจากทำความเข้าใจทั้งระบบก่อน
- การจับคู่แพตเทิร์น: จัดกลุ่มไฟล์ที่คล้ายกันเพื่อหา logic ที่ทำซ้ำ
- การวิเคราะห์ผลกระทบ: รับรู้ว่าการเปลี่ยนแปลงส่งผลต่อทั้งระบบอย่างไร
- ความเข้าใจประวัติ: ย้อนตามเหตุผลหรือบริบทของการเปลี่ยนแปลงโค้ดในอดีตด้วย
ผลข้างเคียงเชิงบวกที่ไม่คาดคิด
- ไม่ได้แค่แก้เฉพาะจุดที่ต้องการ แต่ยังจับอินไซต์ต่อไปนี้ได้ด้วย
- ระบุบล็อกโค้ดซ้ำที่เกิดจากการคัดลอกแล้ววาง
- เตือนเรื่องแพตเทิร์นการจัดการข้อผิดพลาดที่ไม่สอดคล้องกัน
- มองเห็นความเป็นไปได้ของคอขวดด้านประสิทธิภาพ
- เสนอแนวทางปรับปรุงสถาปัตยกรรมตามแพตเทิร์นการใช้งาน
ทำไมเรื่องนี้จึงสำคัญ
- IDE ที่ขับเคลื่อนด้วย AI ในช่วงหลังมุ่งเน้นไปที่การสร้างโค้ดอัตโนมัติ
- แต่การให้เพียงข้อเสนอแนะโดยไม่มีบริบทของทั้งระบบ อาจเสี่ยงเหมือน "นักพัฒนาจูเนียร์ที่เพิ่งเข้าทีมมา"
- สิ่งที่สำคัญจริง ๆ คือ "ความเข้าใจโค้ดอย่างลึกซึ้ง"
คำถามที่ยังเหลืออยู่
- ปัญหาเรื่องการตัดสินใจว่าจะอัปเดต context (ข้อมูลประวัติ) เมื่อไร และควรรักษาไว้เมื่อไร
- จะรับมืออย่างไรเมื่อพบแพตเทิร์นที่ขัดแย้งกัน
- จะสื่อสารผลการวิเคราะห์ที่มีความไม่แน่นอนสูงให้ผู้ใช้อย่างไร
ทิศทางต่อจากนี้
- กำลังพิจารณาว่าจะสอนให้ AI มีสัญชาตญาณแบบนักพัฒนาอาวุโสในเรื่องต่อไปนี้ได้หรือไม่
- ความสามารถในการตรวจจับ technical debt ล่วงหน้า
- ศักยภาพในการเสนอแนวทางปรับปรุงสถาปัตยกรรมเชิงรุก
- ความสามารถในการตรวจจับปัญหาความปลอดภัยจากแพตเทิร์นการใช้งาน
- สัมผัสในการมองเห็นกฎที่ไม่เป็นทางการภายในทีม
- เป้าหมายสูงสุดไม่ใช่แค่การสร้าง "โค้ดให้มากขึ้น" แต่คือการสอน "วิธีทำความเข้าใจโค้ดทั้งระบบอย่างลึกซึ้งเหมือนนักพัฒนาอาวุโส"
3 ความคิดเห็น
คำถามที่ควรถามเพื่อวิเคราะห์และปรับปรุงโค้ดเบส มันก็ไม่ได้เป็นอะไรที่เป็นแบบแผนตายตัวอยู่แล้วไม่ใช่เหรอ? ผู้เขียนดูตื่นเต้นเกินไปหน่อยนะ
ดูเหมือนว่าจะเป็นบริบทเดียวกันกับการที่ cursor อธิบายภาพรวมทั้งโปรเจกต์ให้ฟังผ่าน notepad นะ
ความคิดเห็นบน Hacker News
ผู้คนในคอมเมนต์ค่อนข้างวิพากษ์วิจารณ์ บทความนี้พูดถึงผลลัพธ์สั้น ๆ ในเชิงบวกเกี่ยวกับความเป็นไปได้ของเครื่องมือใหม่ และมีความเห็นที่ตรงไปตรงมาและสมเหตุสมผลอยู่ด้วย
นี่เป็นอีกตัวอย่างหนึ่งที่ LLM ทำสิ่งน่าทึ่งได้ อย่างไรก็ตาม การสร้างระบบที่ทำงานได้อย่างสม่ำเสมอและแม่นยำกับทุกอินพุตนั้นยากมาก
น่าจะมีบทเรียนสำหรับระบบเอเจนต์ที่ดีกว่านี้ในการเขียนโค้ด
อ่านบรรทัดแรกของบทความแล้วรู้สึกเหมือนเป็นมนุษย์ต่างดาว คงต้องอ่านทั้งบทความ แต่การบอกว่าอ่านโค้ดที่มีอยู่แบบไล่ลำดับนั้นฟังดูแปลก
เน้นความสำคัญของปัจจัยมนุษย์ หากไม่มีความเข้าใจบริบทของ codebase ก็ไม่อาจรู้ได้ว่าคำเตือนจาก AI มีความหมายอย่างไร
เป็นเรื่องยากที่จะป้องกันไม่ให้ AI แต่ง API ที่ไม่มีอยู่จริงขึ้นมา เวลาที่มันทำงานได้ดีก็ดีอยู่หรอก แต่ส่วนใหญ่มักไม่ได้ผลดีนัก
บริบทของโค้ดและความเข้าใจมีความสำคัญต่อการยกระดับคุณภาพของโค้ดที่ LLM สร้าง
เหมือนกับคำบ่นของ John McCarthy นี่เป็นเรื่องเล่า ไม่ใช่การทดลองหรือข้อพิสูจน์
ผลลัพธ์น่าประทับใจ แม้จะมีคำวิจารณ์เรื่องสไตล์และความเป็นหนึ่งเดียวกัน แต่ผลลัพธ์ก็ดูมีประโยชน์
ดูเหมือนว่าส่วนสำคัญของเทคนิคนี้จะหายไปจากบทความ ไม่มี implementation ของ getFileContext() และ shouldStartNewGroup()