นักพัฒนาได้เปิดตัวแผนผังฐานโค้ดแบบสามเลเยอร์ (three-layer code-base map) ที่ช่วยให้ AI coding agents สามารถจดจำบริบทของตำแหน่งที่อยู่ได้แม้จะเปลี่ยนเซสชันการทำงาน
ทำไม AI agents จึงต้องการแผนผัง
ผู้ช่วยเขียนโค้ดแบบแชทจะสร้างโมเดลทางความคิด (mental model) ของ repository เฉพาะในขณะที่หน้าต่าง prompt ยังเปิดอยู่เท่านั้น เมื่อหน้าต่าง context ปิดลง โมเดลดังกล่าวจะหายไป ทำให้ agent ต้องค้นหาสัญลักษณ์ (symbols), การนำเข้า (imports) และความสัมพันธ์ระหว่างไฟล์ใหม่ทั้งหมดตั้งแต่ต้น การทำงานที่ต้องทำซ้ำไปมาเช่นนี้ทำให้สิ้นเปลืองทรัพยากรการประมวลผล (compute cycles) และทำให้ agent มีประสิทธิภาพลดลงเมื่อนักพัฒนาต้องสลับไปมาระหว่างไฟล์ หรือกลับมาทำโปรเจกต์เดิมหลังจากหยุดพักไป
สามเลเยอร์ที่ประกอบกันเป็นแผนผัง
- Structural layer – แคตตาล็อกของ symbols, การเรียกใช้ฟังก์ชัน (function calls) และคำสั่ง import ซึ่งจะตอบคำถามเชิงสถิต (static) ว่า “อะไรเรียกใช้อะไร”
- Temporal layer – สัญญาณที่ได้จาก git เช่น อัตราการเปลี่ยนแปลงของไฟล์ (file churn rates) และประวัติความเป็นเจ้าของ (ownership histories) ซึ่งจะแสดงให้เห็นว่าส่วนใดของโค้ดมีการเปลี่ยนแปลงบ่อยที่สุด และใครเป็นผู้แก้ไขส่วนนั้นๆ
- Behavioral layer – รูปแบบการใช้งานจริงที่สกัดมาจากประวัติการแก้ไขและการนำทาง (navigation history) ของตัว agent เอง ซึ่งจะเผยให้เห็นว่าไฟล์ใดที่มักจะถูกเปิดขึ้นมาพร้อมกันในระหว่างเซสชันการเขียนโค้ด ทำให้เห็น “เพื่อนบ้านที่แท้จริง” (true neighbors) ที่การวิเคราะห์เชิงสถิต (static analysis) มักจะมองข้ามไป
เลเยอร์เชิงพฤติกรรม (behavioral layer) มีความสำคัญมากที่สุด เพราะมันสะท้อนถึงวิธีการทำงานที่แท้จริงของนักพัฒนา (และ agent) ไม่ใช่แค่เพียงโครงสร้างการเชื่อมต่อของโค้ดเท่านั้น
สองวิธีในการส่งแผนผังให้กับ agent
- Ambient Path – สรุปข้อมูลแบบกระชับที่ถูกใส่เข้าไปในการโต้ตอบทุกครั้ง ช่วยให้ agent เห็นภาพรวมทันทีว่า “คุณกำลังอยู่ในโมดูล X และมี symbols เหล่านี้อยู่ใกล้ๆ” โดยไม่ต้องมีการเรียกใช้ข้อมูลเพิ่มเติม
- Deep Path – เครื่องมือสอบถามข้อมูลตามความต้องการ (on-demand query tools) ที่ agent สามารถเรียกใช้เมื่อต้องการรายละเอียดที่ลึกขึ้น เช่น รายชื่อไฟล์ที่มักจะเปลี่ยนแปลงพร้อมกัน หรือไทม์ไลน์ของประวัติความเป็นเจ้าของล่าสุด
การแยกข้อมูลแบบ ambient ออกจากข้อมูลแบบ deep ช่วยให้ prompt ปกติมีขนาดเบา ในขณะที่ยังสามารถให้ข้อมูลเชิงลึกได้เมื่อจำเป็น
กฎการออกแบบที่ช่วยให้ระบบทำงานได้อย่างคล่องตัว
- ข้ามการใช้ language servers ที่หนักเครื่อง แผนผังนี้อาศัยการวิเคราะห์แบบตื้น (shallow parsing) แทนที่จะเป็นการอนุมานประเภทข้อมูลแบบเต็มรูปแบบ (full type inference) เป้าหมายไม่ใช่การสร้างเครื่องมือที่เหนือกว่า static analyzers ที่มีอยู่แล้ว แต่เป็นการเสริมการทำงานด้วยข้อมูลเชิงลึกด้านพฤติกรรม
- จำกัดขอบเขตของ graph ไว้เฉพาะในแต่ละโปรเจกต์ ระบบจะไม่เชื่อมโยง dependency graph เข้าด้วยกันในระดับ global ข้าม repository การจำกัดขอบเขตนี้ช่วยลดการใช้หน่วยความจำ (memory footprint) และทำให้การอัปเดตเร็วขึ้น
- ใช้หน่วยจัดเก็บหน่วยความจำที่มีอยู่เดิม บันทึกการเปลี่ยนแปลงไฟล์ (file-change logs) มาจากหน่วยความจำของการเรียกใช้เครื่องมือของตัว agent เอง ซึ่งช่วยหลีกเลี่ยงการจัดเก็บข้อมูลซ้ำซ้อนและทำให้แหล่งข้อมูลมีความสอดคล้องกัน
การสร้างแผนผังในทางปฏิบัติ
- รวบรวมข้อมูลเชิงโครงสร้าง (structural data) โดยการไล่ดูไฟล์ต้นฉบับอย่างรวดเร็ว เพื่อดึง symbols และบรรทัดการ import ออกมา
- ดึงตัวชี้วัดเชิงเวลา (temporal metrics) จาก git history ของ repository โดยระบุว่าไฟล์ใดมีการ commit มากที่สุดและใครเป็นผู้เขียน
- เก็บรวบรวมสัญญาณเชิงพฤติกรรม (behavioral signals) โดยการบันทึกการเปิดไฟล์ การแก้ไข และการนำทางของ agent ในระหว่างเซสชันการเขียนโค้ดจริง บันทึกเหล่านี้จะกลายเป็นพื้นฐานสำหรับเมทริกซ์ "การปรากฏร่วมกัน" (co-occurrence matrix) ที่ใช้กำหนดเพื่อนบ้านเชิงพฤติกรรม
- เติมข้อมูลใน Ambient Path ด้วยรายการ symbols และไฟล์ที่เกี่ยวข้องที่สุดสำหรับงานปัจจุบัน โดยเรียงลำดับความสำคัญไว้
- เปิดใช้งาน Deep Path ในรูปแบบของชุดฟังก์ชันสอบถามข้อมูลที่มีน้ำหนักเบา (เช่น “แสดงรายชื่อไฟล์ที่ถูกแก้ไขพร้อมกันในเซสชันล่าสุด”)
Fast hooks จะดักจับการแก้ไขแต่ละครั้งทันทีที่เกิดขึ้น ในขณะที่การสแกนเบื้องหลัง (background sweeps) ที่ช้ากว่าจะทำหน้าที่คำนวณสถิติการเปลี่ยนแปลงใหม่ ทั้งสองส่วนทำงานร่วมกันเพื่อให้แผนผังมีความสดใหม่อยู่เสมอโดยไม่ทำให้ขั้นตอนการทำงานของนักพัฒนาล่าช้าลง
บทเรียนที่ได้รับระหว่างการพัฒนา
- แยกข้อมูลแบบ ambient ออกจากแบบ on-demand การรักษาบทสรุปที่ต้องมีอยู่ตลอดเวลาให้มีขนาดเล็กจะช่วยป้องกันปัญหา token บวม (token bloat) ในขณะที่การสอบถามข้อมูลที่ละเอียดกว่าจะยังคงเป็นทางเลือกเสริม
- จัดลำดับความสำคัญของบริบทตามงาน การเรียงลำดับ ambient symbols ตามจุดที่กำลังแก้ไขอยู่ในปัจจุบันจะช่วยให้ได้คำแนะนำที่มีประโยชน์มากขึ้น
- อัปเดตข้อมูลอย่างรวดเร็วแต่ต้องชาญฉลาด ใช้ quick hooks เพื่อดักจับการเปลี่ยนแปลงที่มีความถี่สูง และใช้การสแกนเป็นระยะเพื่อจัดการกับการเปลี่ยนแปลงที่มีความถี่ต่ำและการเปลี่ยนเจ้าของไฟล์
- การวิเคราะห์แบบตื้น (shallow parsing) ชนะในเรื่องความเร็ว การวิเคราะห์ประเภทข้อมูลเชิงลึก (deep type analysis) จะเพิ่มความหน่วง (latency) โดยไม่ช่วยให้ได้ข้อมูลเชิงลึกด้านพฤติกรรมซึ่งเป็นจุดแข็งหลักของแผนผังนี้
สรุป: ด้วยการวางโครงสร้างแบบเลเยอร์ที่ประกอบด้วยโครงสร้างเชิงสถิต, ประวัติจาก git และการใช้งานจริง เข้ากับโมเดลการเข้าถึงข้อมูลแบบสองระดับที่กะทัดรัด นักพัฒนาจึงสามารถมอบแผนผังฐานโค้ดที่ยั่งยืนให้กับ AI coding agents ได้ การรักษาบทสรุปที่ต้องมีอยู่ตลอดเวลาให้มีขนาดเล็กจะช่วยป้องกันปัญหา token บวม