ทีมพัฒนาโปรเจกต์เดียวกันหลายคน ใช้ GitHub Claude Code ต่อกับ Supabase อย่างไรไม่ให้ชนกัน

ทีมพัฒนาที่เริ่มใช้ Claude Code เปิด Pull Request แทนตัวเองมักตื่นเต้นกับความเร็วที่เพิ่มขึ้นในช่วงแรก แค่เขียน GitHub Issue อธิบายงานที่ต้องการ Agent ก็เริ่มทำงาน อ่านโค้ดในโปรเจกต์ เขียนฟีเจอร์ใหม่ และเปิด PR กลับมาให้รีวิวภายในเวลาไม่นาน แต่พอโปรเจกต์เริ่มมีหลายคนใช้ Agent พร้อมกัน และงานเริ่มแตะฐานข้อมูลจริงผ่าน Supabase คำถามที่ตามมาคือใครเป็นคนควบคุมว่า Agent แตะ Schema ตรงไหนได้บ้าง และใครรู้ว่า Migration ที่ Agent เขียนขึ้นปลอดภัยพอจะรันจริงหรือยัง

ปัญหานี้ไม่ได้อยู่ที่ตัว Claude Code เขียนโค้ดแย่ แต่อยู่ที่ทีมส่วนใหญ่ยังไม่มี Workflow ที่ชัดเจนสำหรับงานที่ AI Agent เข้ามาเกี่ยวข้องกับฐานข้อมูลจริง ต่างจากการเขียนโค้ด Frontend ทั่วไปที่ผิดพลาดแล้วแก้ทีหลังได้ไม่ยาก การเปลี่ยนแปลง Schema หรือรัน Migration ผิดพลาดอาจทำให้ข้อมูลเสียหายหรือระบบล่มได้จริง

บทความนี้จะไล่ดูตั้งแต่การเขียน Issue ให้ Agent เข้าใจงานได้ตรง ไปจนถึงการวางจุดตรวจสอบระหว่างทางก่อนโค้ดของ Agent จะไปแตะฐานข้อมูลจริง โดยอ้างอิงหลักการจัดการ Database บน Supabase ที่เคยพูดถึงใน line-bot-supabase และแนวคิดเรื่องการจำกัดขอบเขตให้ AI Agent เรียกใช้เฉพาะสิ่งที่จำเป็นตามที่อธิบายไว้ใน line-oa-mcp

เขียน GitHub Issue อย่างไรให้ Claude Code เข้าใจงานได้โดยไม่ต้องอธิบายซ้ำ

จุดเริ่มต้นของ Workflow ทั้งหมดคือคุณภาพของ Issue ที่ป้อนให้ Agent ถ้า Issue เขียนกว้าง ๆ เช่น 'เพิ่มฟีเจอร์แจ้งเตือนลูกค้า' โดยไม่มีรายละเอียดว่าแจ้งเตือนเมื่อไหร่ ผ่านช่องทางไหน และเกี่ยวข้องกับตารางใดใน Database Agent จะต้องเดาบริบทเอง ซึ่งเสี่ยงทำให้ผลลัพธ์ที่ได้ไม่ตรงกับที่ทีมต้องการจริง

Issue ที่ทำงานได้ดีกับ Agent ควรระบุ Acceptance Criteria ชัดเจน บอกไฟล์หรือ Module ที่เกี่ยวข้องถ้าทีมรู้อยู่แล้ว และถ้างานนั้นแตะ Database ควรระบุด้วยว่าเกี่ยวข้องกับตารางไหน ต้องการ Schema แบบใด และมีข้อจำกัดอะไรที่ Agent ต้องรู้ เช่น คอลัมน์ไหนห้ามแก้เพราะมีระบบอื่นพึ่งพาอยู่

ทีมที่ทำ Workflow นี้ได้ดีมักมี Template สำหรับ Issue ที่เกี่ยวกับ Database โดยเฉพาะ แยกจาก Issue ทั่วไป เพื่อบังคับให้คนเปิด Issue ต้องกรอกข้อมูลที่จำเป็น เช่น ตารางที่เกี่ยวข้อง ผลกระทบต่อข้อมูลเดิม และว่าจำเป็นต้องมี Migration ใหม่หรือไม่ ก่อนที่ Agent จะเริ่มทำงานเลย

Claude Code ทำงานตั้งแต่รับ Issue จนเปิด Pull Request ได้อย่างไร

เมื่อ Claude Code ได้รับมอบหมาย Issue มันจะอ่านโครงสร้างโปรเจกต์ ค้นหาไฟล์ที่เกี่ยวข้องกับงานที่ระบุ แล้ววางแผนการเปลี่ยนแปลงก่อนเริ่มเขียนโค้ดจริง ระหว่างทางถ้างานนั้นต้องแก้ Schema ของ Database Agent จะเขียนไฟล์ Migration แยกต่างหาก ไม่ใช่ไปรันคำสั่งเปลี่ยนแปลงตรงเข้า Database ที่ใช้งานจริง

หลังจากเขียนโค้ดและ Migration เสร็จ Agent จะรัน Test ที่มีอยู่ในโปรเจกต์เพื่อตรวจสอบเบื้องต้นว่าไม่ทำให้ของเดิมพัง แล้วเปิด Pull Request พร้อมคำอธิบายว่าทำอะไรไปบ้าง เปลี่ยนไฟล์ไหน และถ้ามี Migration จะระบุไว้ในคำอธิบายของ PR ให้ผู้รีวิวเห็นชัดว่ามีการเปลี่ยนแปลงระดับ Database เกิดขึ้น ไม่ใช่แค่เปลี่ยนโค้ด Application ทั่วไป

จุดสำคัญคือ PR ที่ Agent เปิดยังต้องผ่านการรีวิวจากคนในทีมเหมือน PR ทั่วไป ไม่ใช่ Merge อัตโนมัติทันทีที่ Agent สร้างเสร็จ โดยเฉพาะ PR ที่แตะ Migration ควรมีกฎบังคับให้ต้องมีคนอย่างน้อยหนึ่งคนที่เข้าใจ Schema ของ Database รีวิวก่อนเสมอ ไม่ว่าโค้ดส่วนอื่นจะผ่าน Test อัตโนมัติแล้วก็ตาม

ทำไมต้องมี Supabase MCP เป็นตัวกลาง ไม่ให้ Agent ต่อ Database ตรง ๆ

หลายทีมที่เริ่มต่อ AI Agent เข้ากับ Supabase โดยตรงผ่าน Connection String มักเจอปัญหาว่า Agent มีสิทธิ์เข้าถึง Database เท่ากับสิทธิ์ของ Credential ที่ใช้ ถ้า Credential นั้นมีสิทธิ์เต็มเท่ากับ Admin การให้ Agent เข้าถึงตรง ๆ เท่ากับเปิดความเสี่ยงให้ Agent สามารถแก้ไขหรือลบข้อมูลส่วนไหนก็ได้ ถ้าตีความคำสั่งผิดหรือถูกป้อนคำสั่งแปลกปลอมผ่านข้อความในบริบทของงาน

Supabase MCP เข้ามาแก้ปัญหานี้ด้วยการเป็นตัวกลางที่กำหนดชัดเจนว่า Agent เรียกใช้เครื่องมืออะไรได้บ้าง เช่น เครื่องมือดู Schema เครื่องมือสร้าง Migration หรือเครื่องมือ Query ข้อมูลแบบอ่านอย่างเดียว แทนที่จะให้ Agent รันคำสั่ง SQL อิสระเข้า Database โดยตรง ทำให้ทีมควบคุมขอบเขตการทำงานของ Agent ได้ชัดเจนกว่า

อีกประโยชน์ของการผ่าน MCP คือทุกคำสั่งที่ Agent เรียกจะถูกบันทึกไว้เป็น Log ทำให้ทีมย้อนดูได้ว่า Agent เรียกเครื่องมือไหนบ้างระหว่างทำงาน Query อะไร และได้ผลลัพธ์แบบไหน ต่างจากการต่อ Connection ตรงที่มักไม่มี Log ระดับนี้ ทำให้ตรวจสอบย้อนหลังยากเมื่อเกิดปัญหาว่า Agent ทำอะไรไปบ้างกันแน่

ออกแบบสิทธิ์ Schema ให้ Agent แตะได้เฉพาะส่วนที่ควร

หลักการพื้นฐานคือ Agent ควรมีสิทธิ์เท่าที่จำเป็นสำหรับงานที่มอบหมายเท่านั้น ไม่ใช่สิทธิ์เต็มเท่า Admin ทีมควรแยก Environment สำหรับให้ Agent ทดลองทำงาน เช่น Database แยกต่างหากสำหรับ Development หรือ Staging ที่ไม่กระทบข้อมูลจริงของผู้ใช้ แล้วให้การเปลี่ยนแปลงที่ผ่านการรีวิวแล้วเท่านั้นที่ถูกนำไปใช้กับ Production

สำหรับตารางที่มีข้อมูลอ่อนไหว เช่น ข้อมูลผู้ใช้หรือข้อมูลการชำระเงิน ควรพิจารณาว่า Agent จำเป็นต้องเห็น Schema ของตารางเหล่านี้ในระดับใด บางทีมเลือกให้ Agent เห็นแค่โครงสร้างคอลัมน์แต่ไม่เห็นข้อมูลจริง เพื่อให้ยังเขียนโค้ดที่เกี่ยวข้องได้โดยไม่ต้องเข้าถึงข้อมูลส่วนบุคคลจริงระหว่างพัฒนา

การกำหนดสิทธิ์ควรทำผ่าน Role เฉพาะที่สร้างขึ้นสำหรับ Agent โดยเฉพาะ ไม่ใช้ Role เดียวกับที่นักพัฒนาคนใช้ Login ปกติ เพราะทำให้แยกยากว่าการเปลี่ยนแปลงใดมาจาก Agent และใดมาจากคนจริง เมื่อแยก Role ชัดเจนแล้ว การจำกัดหรือเพิกถอนสิทธิ์ของ Agent ในภายหลังก็ทำได้ง่ายโดยไม่กระทบสิทธิ์ของนักพัฒนาคนอื่น

วาง Migration ให้ผ่าน Review ก่อนเข้า Production เสมอ

แม้ Agent จะเขียน Migration ได้ถูกต้องตามหลักไวยากรณ์ SQL แต่ความถูกต้องทางไวยากรณ์ไม่ได้แปลว่าปลอดภัยต่อข้อมูลจริงเสมอไป เช่น การลบคอลัมน์ที่ดูเหมือนไม่ได้ใช้แล้วในโค้ด แต่จริง ๆ ยังมีระบบอื่นหรือ Report ที่อ้างอิงคอลัมน์นั้นอยู่ ซึ่ง Agent อาจไม่รู้บริบทนี้ถ้าไม่มีข้อมูลเพียงพอในโปรเจกต์

ทีมควรกำหนดเป็นกฎตายตัวว่า Migration ทุกไฟล์ที่มาจาก PR ของ Agent ต้องผ่านการรีวิวจากคนที่เข้าใจ Schema จริง ก่อนจะถูก Merge และรันบน Production ไม่ว่า Agent จะมั่นใจแค่ไหนว่าโค้ดถูกต้อง เพราะความเสียหายจาก Migration ที่ผิดพลาดมักแก้คืนยากกว่าโค้ด Application ทั่วไปมาก

แนวทางที่ช่วยลดความเสี่ยงเพิ่มเติมคือให้ Migration ที่มีผลกระทบสูง เช่น การลบคอลัมน์หรือเปลี่ยนชนิดข้อมูล ต้องรันผ่านขั้นตอนที่ย้อนกลับได้ เช่น เก็บข้อมูลเดิมไว้ในตารางสำรองชั่วคราวก่อนลบจริง แทนที่จะลบทิ้งทันทีในขั้นตอนเดียว เผื่อพบภายหลังว่ามีผลกระทบที่ไม่ได้คาดไว้ตอนรีวิว

ตั้ง CI และ Test ให้จับความผิดพลาดก่อน Merge เข้า Main

นอกจากการรีวิวโดยคน ทีมควรมี CI Pipeline ที่รัน Test อัตโนมัติทุกครั้งที่ Agent เปิด PR ใหม่ รวมถึง Test ที่ตรวจสอบว่า Migration รันได้จริงบน Database ทดสอบโดยไม่ Error และไม่ทำให้ Test เดิมที่เคยผ่านกลับมาล้มเหลว เพื่อจับปัญหาที่อาจมองข้ามได้ตั้งแต่ก่อนถึงขั้นตอนรีวิวโดยคน

ควรมี Test เฉพาะสำหรับตรวจสอบ Schema ด้วย เช่น ตรวจว่าคอลัมน์ที่ระบบอื่นพึ่งพาอยู่ยังคงอยู่ หรือ Constraint สำคัญยังทำงานถูกต้องหลัง Migration ใหม่ถูกนำไปใช้ Test แบบนี้ช่วยจับความผิดพลาดที่ Agent อาจมองข้าม เพราะ Agent เห็นแค่โค้ดในโปรเจกต์ แต่ไม่เห็นบริบททางธุรกิจทั้งหมดที่อยู่เบื้องหลังการออกแบบ Schema เดิม

เมื่อ CI ผ่านครบและมีคนรีวิวอนุมัติแล้ว จึงค่อย Merge เข้า Main และปล่อยให้ขั้นตอน Deploy ที่ทีมตั้งไว้ทำงานต่อ ทีมไม่ควรลัดขั้นตอนใดขั้นตอนหนึ่งเพียงเพราะ PR นั้นมาจาก Agent ที่ดูน่าเชื่อถือ เพราะมาตรฐานความปลอดภัยของ Workflow ควรเท่ากันไม่ว่าใครหรืออะไรเป็นผู้เขียนโค้ด

ข้อผิดพลาดที่ทีมมักเจอเมื่อปล่อยให้ AI Agent ทำงานอิสระเกินไป

ข้อผิดพลาดที่พบบ่อยที่สุดคือให้ Credential ที่มีสิทธิ์สูงเกินจำเป็นแก่ Agent ตั้งแต่ต้น เพราะดูสะดวกในช่วงทดลองใช้งาน แล้วลืมกลับมาจำกัดสิทธิ์ทีหลังเมื่อเริ่มใช้งานจริง ทำให้ความเสี่ยงสะสมโดยไม่มีใครสังเกตจนเกิดปัญหาขึ้นจริง

อีกข้อผิดพลาดคือปล่อยให้หลายคนในทีมรันคำสั่งให้ Agent ทำงานกับ Database เดียวกันพร้อมกันโดยไม่มีการประสานงาน ทำให้เกิด Migration ที่ขัดแย้งกัน หรือ Agent สองตัวพยายามแก้ไขตารางเดียวกันในเวลาใกล้เคียงกันจนเกิดความสับสนว่าเวอร์ชันไหนคือของจริงที่ควรใช้

ทีมที่เจอปัญหาแบบนี้ควรกลับมาตกลงกันเรื่องลำดับการทำงาน เช่น กำหนดว่า Migration ที่กระทบ Schema เดียวกันต้องรอให้ PR ก่อนหน้า Merge เสร็จก่อนถึงจะเริ่ม Agent ตัวถัดไป และควรมีคนหนึ่งคนที่รับผิดชอบดูภาพรวมของ Schema ทั้งหมด ไม่ปล่อยให้ต่างคนต่างสั่ง Agent ทำงานแยกกันโดยไม่มีใครเห็นภาพรวม

เทียบ Workflow แบบทีมทำเองทั้งหมด กับแบบมี Claude Code ร่วมทำ

ตารางนี้เทียบขั้นตอนสำคัญของสองแนวทาง เพื่อให้เห็นว่าจุดไหนที่ Agent ช่วยประหยัดเวลา และจุดไหนที่ยังต้องมีคนควบคุมเหมือนเดิม:

สรุป

การให้ Claude Code ทำงานตั้งแต่ GitHub Issue จนถึงการแตะ Database ผ่าน Supabase ไม่ใช่เรื่องของความเร็วเพียงอย่างเดียว แต่ต้องมี Workflow ที่กำหนดขอบเขตชัดเจนว่า Agent ทำอะไรได้เอง และตรงไหนที่ยังต้องมีคนตรวจสอบก่อนเสมอ โดยเฉพาะงานที่กระทบ Schema หรือข้อมูลจริงของผู้ใช้

ทีมที่วาง Workflow นี้ได้ดีมักไม่ได้พยายามให้ Agent ทำงานอิสระที่สุดเท่าที่จะทำได้ แต่ออกแบบให้ทุกขั้นตอนที่มีความเสี่ยงยังผ่านมนุษย์เสมอ ในขณะที่ปล่อยให้ Agent ช่วยแบ่งเบางานที่ใช้เวลานานอย่างการร่างโค้ดและ Migration เบื้องต้น

• ให้ Agent เขียน Migration ผ่าน Pull Request เสมอ ห้ามรันเข้า Production โดยตรง
• ใช้ Supabase MCP เป็นตัวกลางเพื่อจำกัดเครื่องมือและบันทึก Log การเรียกใช้ทุกครั้ง
• แยก Role สิทธิ์เข้าถึง Database ของ Agent ออกจาก Role ของนักพัฒนาคนจริงเสมอ

คำถามที่พบบ่อย