AI coding agent context คืออะไร และทำไมต้องเริ่มที่บริบทก่อนโค้ด
AI coding agent context คือชุดข้อมูลพื้นฐานเกี่ยวกับภูมิหลังโครงการ สถาปัตยกรรม ข้อจำกัด และแนวปฏิบัติที่ต้องการ ให้ AI อ่านก่อนเริ่มเขียนหรือแก้ไขโค้ด เพื่อให้เอเจนต์ไม่เขียนจากค่าเฉลี่ยสถิติของโค้ดทั่วโลก แต่เขียนให้สอดคล้องกับขอบเขตโมดูล กติกาทีม รูปแบบความปลอดภัย และเจตนาการออกแบบของระบบ ช่วยลดความเสี่ยงที่โค้ดใหม่จะแค่คอมไพล์ผ่านแต่ไม่เข้ากับโครงสร้างจริงของโปรดักต์
ปัญหาที่หลายทีมมักมองข้ามคือ AI coding agent ที่ทำงานในรีโปของเราจริงๆ ไม่เคยเห็นสถาปัตยกรรมของโปรเจกต์ ไม่รู้ขอบเขตโมดูล ข้อตกลงทีม เหตุการณ์อินซิเดนต์ที่เคยห้ามใช้แพตเทิร์นบางแบบ หรือเหตุผลว่าทำไมเซอร์วิสบางตัวเรียกกันได้ บางตัวห้ามเรียก เอเจนต์จึงเขียนโค้ดจากค่ากลางของสิ่งที่ถูกเทรน ซึ่งแทบไม่มีโค้ดของเราอยู่เลย ผลคือโค้ดที่คอมไพล์ผ่าน อ่านผ่านตา แต่ค่อยๆ ลื่นไถลออกจากสถาปัตยกรรมเดิมอย่างเงียบๆ นี่คือ AI architectural drift ที่สะสมเป็นหนี้เทคนิคแบบช้าๆ แทนที่จะช่วยลดงาน กลับเพิ่มภาระรีวิวและรีแฟกเตอร์ในระยะยาว
เมื่อเอเจนต์ไร้บริบท: สถาปัตยกรรมเพี้ยน ความปลอดภัยรั่ว และค่าใช้จ่ายบาน
เมื่อ AI coding agent ทำงานโดยไม่มี AI coding agent context ปัญหาที่ตามมามากกว่าที่หลายคนคิด งานวิจัยหนึ่งพบว่าโมเดลชั้นนำทุกตัวมี “การรับรู้ด้านความปลอดภัยต่ำ และโน้มเอียงไปสู่โค้ดรก” โดยโค้ดสเมลที่ไม่ทำให้บิลด์แตกแต่ทำให้ดูแลยากคิดเป็นประมาณ 90% ของปัญหาทั้งหมด ด้านช่องโหว่ความปลอดภัย บางเวอร์ชันของโมเดลมีบั๊กที่ถูกจัดระดับ BLOCKER มากกว่าเวอร์ชันก่อนถึง 93% แสดงว่าเวอร์ชันใหม่ไม่ได้ปลอดภัยขึ้นอัตโนมัติ
ในระดับโค้ดเบส มีหลักฐานว่าการใช้เอเจนต์โดยไม่คุมบริบททำให้โค้ดซ้ำเพิ่มขึ้น เอเจนต์เก่งสร้างโค้ดใหม่แต่แย่ในการนำโค้ดเดิมกลับมาใช้ จึงชอบก็อปปี้แทนการรีแฟกเตอร์ ทำให้ duplication กลายเป็น AI architectural drift แบบค่อยเป็นค่อยไป และการโคลนโค้ดที่เปลี่ยนพร้อมกันเกี่ยวข้องกับบั๊กเฉลี่ย 57% ของกรณีในงานศึกษาหนึ่ง เมื่อดริฟต์ถูกจับได้ช้าระดับรีวิวหรือในโปรดักชัน ทีมต้องจ่ายชั่วโมงรีวิว รีเวิร์ก และการพ่นพรอมป์ต์ใหม่ซ้ำไปมา แถมยังสิ้นเปลืองโทเคนอินพุตและเอาต์พุตซึ่งกลายเป็นประเด็นด้านต้นทุนเชิงกลยุทธ์ขององค์กร
CLAUDE.md และ AGENTS.md: กรอบงานเล็กๆ ที่ทำให้เอเจนต์มองเห็นระบบ
ทางออกที่หลายทีมเริ่มใช้คือไฟล์ CLAUDE.md framework และ AGENTS.md ซึ่งทำหน้าที่เป็นคู่มือออนบอร์ดสั้นที่สุดให้เอเจนต์ เข้าใจภูมิหลังโปรเจกต์ สถาปัตยกรรม และข้อจำกัดก่อนเขียนโค้ด โมเดลเปรียบเสมือนเด็กแรกเกิด ทุกครั้งที่เริ่มเซสชันใหม่มันไม่รู้ว่าเราเป็นใคร โปรเจกต์คืออะไร หรือกติกาเดิมคืออะไร จึงต้องมีคนใช้ภาษาง่ายและสั้น เล่าให้เข้าใจภาพรวมโปรเจกต์ สถาปัตยกรรม และบริบทสำคัญ การทำเช่นนี้มีสองประโยชน์ คือช่วยให้เอเจนต์ไม่ต้องไล่โค้ดทั้งรีโป ลดการใช้โทเคน และช่วยกันไม่ให้เอเจนต์ทำสิ่งที่สวนทางกับเจตนาของโค้ดเบสหรือสร้างล้อใหม่ทั้งที่มีโค้ดเดิมอยู่แล้ว
การใช้ไฟล์บริบทเหล่านี้ต่างจากการพ่นพรอมป์ต์สดที่ต้องเขียนซ้ำทุกครั้ง เพราะมันกลายเป็น prompt engineering guide แบบถาวรที่อยู่ในรีโป อย่างไรก็ตามต้องเข้าใจข้อจำกัดว่าไฟล์พรอมป์ต์หรือเอกสารกติกาเหล่านี้เป็นของคงที่และต้องดูแลปรับตามโค้ดเบส เมื่อสถาปัตยกรรมเปลี่ยนเล็กน้อย ไฟล์ที่เขียนมือมักเริ่มหลุดจากของจริงทันที และไม่สามารถแทนข้อมูลสดอย่างกราฟสถาปัตยกรรม ข้อจำกัดการเรียกใช้โมดูล หรือประวัติแพตเทิร์นที่ทีมมักทำผิดได้ครบ ดังนั้นไฟล์เหล่านี้จึงต้องเขียนให้กระชับ ปรับง่าย และใช้ควบคู่กับเครื่องมือที่มองเห็นโค้ดจริงในรีโป
จะเขียน CLAUDE.md ให้ได้ผล ต้องคิดแบบคู่มือออนบอร์ดไม่ใช่กฎเหล็ก 200 หน้า
คำถามคือจะเขียน CLAUDE.md framework อย่างไรให้ช่วยเอเจนต์ได้จริง แนวทางที่แนะนำคือให้มันอ่านเหมือนคู่มือออนบอร์ดสั้นที่สุดสำหรับน้องใหม่ในทีม บอกเท่าที่จำเป็นเพื่อให้เริ่มงานได้โดยไม่ทำโค้ดเบสพัง และควรเขียนให้กระชับระดับเรซูเม โดยลดคำซ้ำและประโยคที่ไม่จำเป็นให้มากที่สุด เนื้อหาควรเน้นความรู้เชิงนามธรรม เช่น หลักออกแบบสถาปัตยกรรม รูปแบบการเข้าถึงฐานข้อมูล ขอบเขตชั้นต่างๆ ในระบบ มากกว่ารายละเอียดเชิงบรรทัดของไฟล์ เพราะไฟล์และบรรทัดเปลี่ยนตลอดเวลา แนวทางหนึ่งคือให้ไฟล์นี้ยาวไม่เกินประมาณ 200 บรรทัด เพื่อรักษาความอ่านง่ายและไม่เปลืองบริบท
กรอบโครงสร้างที่ใช้ได้ดีมักเริ่มจากคำอธิบายหนึ่งบรรทัดว่าระบบคืออะไร ตามด้วยส่วน Architecture ที่อธิบายว่า controller ต้องบาง โลจิกธุรกิจอยู่ที่ใด การเข้าถึงฐานข้อมูลต้องผ่านเลเยอร์ไหน จากนั้นคือ Tech stack คำสั่งที่ใช้บ่อย Conventions เช่น แนวปฏิบัติที่ลินเตอร์จับไม่ได้ Boundaries ว่าโมดูลไหนห้ามเรียกกัน และ Domain doc map ที่ชี้เอกสารโดเมนเชิงลึก ที่สำคัญ ควรหลีกเลี่ยงการใส่หัวข้อ “Never” ยาวๆ ที่บันทึกความผิดพลาดในอดีต เพราะทำให้ไฟล์กลายเป็นรายการห้ามไม่มีที่สิ้นสุด ทางออกที่ดีกว่าคือกลับด้านความล้มเหล่านั้นเป็นกติกาเชิงบวก เช่น แทนที่จะเขียนว่า “ห้ามใช้ pattern X” ให้เขียนว่า “ใช้ pattern Y สำหรับกรณีนี้” เพื่อให้อ่านแล้วนำไปทำได้ทันที
จากบริบทสู่คุณภาพ: ลดความเสี่ยง เพิ่มความแม่นยำ และประหยัดโทเคน
เมื่อทีมลงทุนในบริบทผ่าน CLAUDE.md และ AGENTS.md ผลลัพธ์ที่ได้ไม่ใช่แค่ความสบายใจ แต่มีตัวเลขรองรับ งานทดสอบหนึ่งพบว่าเมื่อนำเฟส Guide ที่ฉีดบริบทโปรเจกต์เฉพาะเข้าไปก่อนให้เอเจนต์เขียนโค้ด แล้วมีขั้น Verify ตรวจผลระดับ CI อยู่ในลูปก่อนเปิดพูลรีเควสต์ จากนั้นจึงให้เฟส Solve ปิดปัญหาที่เหลือ ทำให้จำนวนปัญหาที่เอเจนต์สร้างลดลงถึง 92% ในการทดสอบภายใน ขณะเดียวกัน การศึกษาควบคุมอีกกรณีที่ใช้เอเจนต์เดียวกันกับรีโปคู่เปรียบเทียบ พบว่ารีโปที่สะอาดกว่าใช้โทเคนอินพุตน้อยลง 7.2% และเอาต์พุตน้อยลง 8.5% โดยอัตราความสำเร็จของงานไม่ลดลงอย่างมีนัยสำคัญ
มุมมองหนึ่งคือ codebase security risks จากเอเจนต์ที่ไม่เข้าใจระบบจะกลายเป็นอินซิเดนต์ของวันพรุ่งนี้ และ AI architectural drift จากโค้ดซ้ำกับ churn ที่สูงขึ้นจะกลายเป็นภาระบำรุงรักษาในอนาคต การเพิ่มบริบทที่เป็นระบบจึงไม่ใช่เรื่องสวยหรู แต่เป็นมาตรการจัดการความเสี่ยงและต้นทุนในระยะยาว วิธีคิดที่ควรเปลี่ยนคือหยุดหวังว่าพรอมป์ต์ที่ดีขึ้นหรือรีวิวแน่นขึ้นจะเยียวยาผลลัพธ์ของเอเจนต์ที่กำลังเดาแทนเราตลอดเวลา เพราะปัญหาไม่ได้อยู่ที่คำสั่ง แต่คือเอเจนต์ไม่เคยรู้ความจริงเกี่ยวกับระบบของเรา การเขียน CLAUDE.md และ AGENTS.md ที่ดีจึงคือการบอกความจริงนั้นให้ชัดตั้งแต่บรรทัดแรก ก่อนที่เอเจนต์จะเริ่มเขียนโค้ดแถวเดียว
