แผนที่ก่อน ตรวจสอบทีหลัง

งานที่แตกต่างกันสองอย่างอยู่ในสองด้านของ pull request ก่อนที่เอเจนต์จะเขียน มันต้องการแผนที่ของต้นไม้ที่มันกำลังจะเปลี่ยนแปลง หลังจากที่เอเจนต์เปิด PR แล้ว บางสิ่งต้องอ่านการเปลี่ยนแปลงนั้นเทียบกับระบบที่เหลือ และทิ้งความคิดเห็นที่มนุษย์สามารถนำไปปฏิบัติได้

งานเหล่านี้ดูคล้ายกันจากระยะไกลเพราะทั้งคู่เกี่ยวข้องกับ ‘การเข้าใจโค้ดเบส’ มันไม่ใช่ผลิตภัณฑ์เดียวกัน อย่างหนึ่งตอบว่า ‘การเปลี่ยนแปลงนี้ควรลงจอดที่ไหน?’ อีกอย่างตอบว่า ‘อะไรที่ diff นี้ทำพังที่ลินเตอร์แบบบรรทัดต่อบรรทัดจะพลาดไป?’ การผสมทั้งสองเข้าด้วยกันให้ผลเป็นร่างแรกที่แย่กว่าและการตรวจสอบที่มีเสียงรบกวนมากกว่า

บทความนี้คือคู่มือเวิร์กโฟลว์แบบคู่ Maguyva คือแผนที่ที่เอเจนต์สอบถามก่อน Greptile คือเอเจนต์ตรวจสอบที่แสดงความคิดเห็นบน PR หลังจากนั้น คู่นี้เสริมกันตามการออกแบบ: Maguyva ไม่ตรวจสอบ pull request และ Greptile ไม่แทนที่ชั้นบริบทที่เอเจนต์ใช้เขียนมัน

ทำไมการแบ่งแยกนี้จึงมีประโยชน์

เอเจนต์เขียนโค้ดที่เริ่มต้นด้วยอคติจากการฝึกฝนบวกกับไฟล์บางไฟล์ที่ถูกวางไว้ จะประดิษฐ์เส้นทางที่น่าเชื่อถือขึ้นมาและแก้ไขมัน นี่คือความล้มเหลวแบบ ‘ไฟล์ผิด’ และมันคือปัญหาการดึงข้อมูล Maguyva คือชั้นบริบทโค้ดเบส MCP ระยะไกล: การดึงข้อมูลเชิงความหมาย เชิงโครงสร้าง (AST) เชิงกราฟ/การพึ่งพา และข้อความรวมกันเป็นผลลัพธ์ที่มีการจัดอันดับ พร้อมการค้นหาสัญลักษณ์และการดึงไฟล์ คำตอบที่มีหลักฐานกลับมาเป็น path/file.ext:line เพื่อให้คุณปฏิเสธข้อผิดพลาดได้ก่อนที่ patch จะมีอยู่ สิ่งที่อ้างนั้นเรียบง่ายโดยตั้งใจ: การเปลี่ยนแปลงที่หลอนน้อยลง โมเดลยังคงเดาได้ แค่ก้าวแรกไม่ใช่การเดาอีกต่อไป

Greptile คือเอเจนต์ตรวจสอบโค้ดที่ขับเคลื่อนด้วย AI ในคำพูดของพวกเขาเอง มันตรวจสอบทุก pull request โดยอัตโนมัติด้วยความเข้าใจโค้ดเบสอย่างเต็มที่ และวางตำแหน่งตัวเองเทียบกับลินเตอร์แบบดั้งเดิมที่ตรวจสอบไฟล์แยกกันแทนที่จะเป็นระบบทั้งหมด การตั้งค่าประกอบด้วยการติดตั้งแอป GitHub หรือ GitLab และเลือกรีโพซิทอรี ไม่มีดัชนีในเครื่องที่คุณต้องรัน การโฮสต์คือ Greptile Cloud (พวกเขาระบุว่าปฏิบัติตาม SOC 2 Type II โดยมีรายงานพร้อมให้เมื่อมีการร้องขอ) โดยมีตัวเลือกโฮสต์เองสำหรับองค์กร

ขั้นตอนที่มีหมายเลขของพวกเขาเองคือ: เชื่อมต่อและสร้างกราฟการพึ่งพาของทุกฟังก์ชัน คลาส และการพึ่งพา; ในทุก pull request วิเคราะห์การเปลี่ยนแปลงโดยใช้กราฟรีโพเต็มรูปแบบนั้น และเผยแพร่ผลการค้นพบเป็นความคิดเห็น PR พร้อมการแก้ไขที่แนะนำ ภายในเวลาประมาณสามนาที; ทุกความคิดเห็นสามารถส่งต่อปัญหาไปยังเอเจนต์เขียนโค้ดที่ทีมใช้อยู่แล้ว พวกเขายังระบุว่าอ่านความคิดเห็น PR ของมนุษย์ในอดีตเมื่อเวลาผ่านไปเพื่อเรียนรู้มาตรฐานโค้ดของทีมและลดคำแนะนำที่มีเสียงรบกวน ระบบการเรียนรู้ของพวกเขา ตามที่พวกเขาระบุเอง ใช้เวลา 2-3 สัปดาห์ในการปรับตัว

นั่นคือการตรวจสอบ ไม่ใช่การร่าง จุดแข็งของ Greptile คือบริบทกราฟรีโพเต็มรูปแบบเทียบกับการเปลี่ยนแปลงที่ลงจอดแล้วใน PR ตามด้วยวงจรปิดที่ส่งผลการค้นพบไปยัง Claude Code, Codex, Conductor, Cursor หรือ Devin จุดแข็งของ Maguyva คือแผนที่ที่มีการจัดอันดับซึ่งเอเจนต์สอบถามก่อนที่การเปลี่ยนแปลงจะถูกเขียน ใช้ทั้งสองอย่าง อย่าขอให้อย่างหนึ่งทำงานของอีกอย่างหนึ่ง

ไม่มีการระบุว่ามีการผสานรวมผลิตภัณฑ์อย่างเป็นทางการระหว่าง Maguyva และ Greptile คุณก็ไม่ต้องการมันเช่นกัน Maguyva พูดคุยกับเอเจนต์ผ่าน MCP Greptile พูดคุยกับ GitHub หรือ GitLab ผ่านแอปของพวกเขาเอง พวกเขาพบกันที่ pull request ไม่มีสคริปต์เชื่อมต่อ ไม่มี cron ที่ป้อนเครื่องมือหนึ่งไปยังอีกเครื่องมือหนึ่ง คู่นี้ไม่ต้องการ bash เพราะแต่ละผลิตภัณฑ์นั่งอยู่บนพื้นผิวที่เป็นของตัวเองอยู่แล้ว

สิ่งนี้ไม่ใช่อะไร

นี่ไม่ใช่การดูถูก Greptile นี่ไม่ใช่หน้า ‘เปลี่ยนตัวตรวจสอบของคุณ’ Greptile เปิดตัวบน Hacker News เมื่อวันที่ 5 มีนาคม 2024 ในฐานะบริษัท Y Combinator W24 และกระทู้นั้นคือวิธีที่หลาย ๆ คนรู้จักผลิตภัณฑ์นี้เป็นครั้งแรก หากนั่นคือวิธีที่คุณค้นพบพวกเขา ก็ใช้พวกเขาต่อไป หน้านี้คือครึ่งหน้าที่ขาดหายไปของวงจรนั้น: ทำให้เอเจนต์อ้างอิงข้อเท็จจริงก่อน เพื่อให้ PR ที่ Greptile เห็นนั้นกำหนดเป้าหมายไปที่ไฟล์ที่ถูกต้องอยู่แล้ว

เนื้อหาการตลาดของ Greptile นำเสนอด้วยการอ้างเรื่องความเร็วในการตรวจสอบและการจับบัค ให้ถือว่านั่นเป็นการอ้างของ Greptile เอง ไม่ใช่ตัวเลขที่ได้รับการตรวจสอบอย่างเป็นอิสระ บทความนี้ไม่ได้ทำซ้ำมันเป็นข้อเท็จจริง

ความครอบคลุมด้านภาษาก็เป็นความซื่อสัตย์แบบเดียวกัน Greptile กำหนดกรอบการรองรับว่าครอบคลุมภาษาโปรแกรมทั้งหมดแทนที่จะเป็นรายการที่ระบุไว้ ตัวเลขที่แน่นอนไม่ได้ระบุไว้ Maguyva เผยแพร่การรองรับมากกว่า 279 ภาษาและเทคโนโลยีที่อิงข้อความ พร้อมการแบ่งแยกทางเทคนิค (AST ที่รองรับโดยตัวแยกวิเคราะห์ไวยากรณ์ เทียบกับข้อความเท่านั้น) บนเว็บไซต์เมื่อคำถามเป็นเรื่องทางเทคนิค นี่คือผลิตภัณฑ์ที่แตกต่างกันที่อ้างสิ่งที่แตกต่างกัน อย่าผสมมันเข้าด้วยกัน

ราคาของ Greptile ไม่ได้ระบุไว้ในเนื้อหาที่ใช้งานได้ของบทความนี้ แผนที่เสียเงินมีอยู่ ดูหน้าราคาของพวกเขา Maguyva คิดค่าบริการต่อพื้นที่ทำงาน ไม่ใช่ต่อที่นั่ง แผนเริ่มต้นฟรี หน้าราคา แสดงรายการระดับที่เผยแพร่หากคุณต้องการตัวเลขพื้นที่ทำงาน

เวิร์กโฟลว์

สามขั้นตอนที่มีชื่อ ดำเนินการตามลำดับนี้ อย่าข้ามข้อใดในครั้งแรกที่คุณลองคู่นี้

1. บริบท Maguyva

จัดทำดัชนีรีโพซิทอรีหนึ่งที่คุณรู้จักอยู่แล้ว เชื่อมต่อไคลเอนต์ MCP ที่คุณเขียนโค้ดอยู่แล้ว — Claude Code, Cursor, Codex CLI, VS Code, Windsurf หรือไคลเอนต์ที่เข้ากันได้กับ MCP อื่น ๆ Maguyva มีคู่มือการตั้งค่าสำหรับไคลเอนต์ MCP ที่มีเอกสารประกอบ 24 ตัว และสามารถเชื่อมต่อกับไคลเอนต์อื่น ๆ ที่รองรับการตั้งค่า MCP มาตรฐานได้

ถามคำถามหนึ่งข้อที่คุณสามารถประเมินได้ก่อนที่ใครจะเขียนอะไรเลย ‘การหมดอายุของเซสชันถูกจัดการที่ไหน และใครเรียกใช้มัน?’ เป็นก้าวแรกที่ดีกว่า ‘แก้ไข auth’ เรียกร้องการอ้างอิง เปิดผลลัพธ์ file.ext:line ติดตามสัญลักษณ์ ยืนยันการพึ่งพาที่คุณกำลังจะแตะต้อง

Maguyva เปิดเผยเครื่องมือ MCP ที่เน้นลูกค้า 11 ตัวครอบคลุมการค้นหา สัญลักษณ์ การวิเคราะห์การพึ่งพา การดึงไฟล์ บริบทรีโพซิทอรีและเวิร์กโฟลว์เครื่องมืออรรถประโยชน์ที่กำหนดผลลัพธ์ได้แน่นอน โหมดการดึงข้อมูลสี่แบบรวมกันเป็นผลลัพธ์ที่มีการจัดอันดับ; find_symbol เป็นเครื่องมือแยกต่างหากเมื่อคุณรู้ชื่ออยู่แล้ว เอกสารประกอบ อธิบายเส้นทางที่สั้นที่สุด: เริ่มต้นฟรี จัดทำดัชนีรีโพที่คุณรู้จักอยู่แล้ว เชื่อมต่อไคลเอนต์ จากนั้นถามคำถามหนึ่งข้อที่คุณสามารถตรวจสอบได้

สแนปช็อตมีการประทับเวลา เพื่อให้เอเจนต์บอกได้ว่ากำลังอ่านต้นไม้เวอร์ชันใด ข้อจำกัดตามจริงคืองานในเครื่องที่ยังไม่ซิงค์ หากการเปลี่ยนแปลงมีอยู่เฉพาะในไดเรกทอรีทำงานและยังไม่ได้พุช แผนที่บนคลาวด์ยังไม่มีมัน ไฟล์คำสั่ง (CLAUDE.md, AGENTS.md) ยังคงมีที่ทางที่นี่ สำหรับข้อตกลงและสิ่งที่ไม่ควรแตะต้อง มันไม่ใช่แผนที่ที่มีชีวิต ใช้สำหรับพฤติกรรม ใช้ Maguyva สำหรับข้อเท็จจริง

อย่าให้เอเจนต์เปิด PR ก่อนที่การอ้างอิงจะพิสูจน์ตัวเองผ่านการสัมผัสกับรีโพ ประตูนั้นคือจุดประสงค์ทั้งหมดของขั้นตอนนี้

2. PR ของเอเจนต์

เอเจนต์ตัวเดียวกันตอนนี้เขียนการเปลี่ยนแปลงในไคลเอนต์ที่คุณจ่ายเงินไปแล้ว Maguyva ไม่ใช่ตัวแก้ไขโค้ดหรือตัวตรวจสอบ เอเจนต์ยังคงสร้าง diff คุณยังคงเปิด pull request บน GitHub หรือ GitLab เหมือนที่คุณเคยทำ

สิ่งที่ควรแตกต่างคือไฟล์แรก PR ควรระบุชื่อตัวจัดการที่อิมพลีเมนต์พฤติกรรมนั้นจริง ผู้เรียกที่จะพัง และการทดสอบที่จะล้มเหลวหากการเปลี่ยนแปลงนั้นผิด หากข้ามขั้นตอนที่ 1 ไป ขั้นตอนที่ 3 จะเสียความคิดเห็นไปกับการเปลี่ยนแปลงที่ลงจอดในแพ็กเกจผิด Greptile ยังคงสามารถค้นหาปัญหาเชิงระบบได้ มันไม่ควรต้องกู้คืนจากเส้นทางที่หลอนด้วย

รักษา PR ให้เล็ก ไฟล์แรกที่มีหลักฐานไม่ใช่ใบอนุญาตให้เขียนโมดูลใหม่ คู่ที่เสริมกันนี้ทำงานเมื่อเอเจนต์ทำงานหนึ่งอย่างด้วยแผนที่ แล้วขอให้ตัวตรวจสอบทำงานอีกอย่างบน diff ที่จำกัด

3. การตรวจสอบของ Greptile

Greptile เชื่อมต่อกับรีโพซิทอรีผ่านแอป GitHub หรือ GitLab อยู่แล้ว ในทุก pull request ใหม่ มันวิเคราะห์การเปลี่ยนแปลงโดยใช้กราฟรีโพเต็มรูปแบบที่มันสร้างขึ้น และเผยแพร่ผลการค้นพบเป็นความคิดเห็นพร้อมการแก้ไขที่แนะนำ เนื้อหาของพวกเขาเองระบุขั้นตอนนี้ไว้ที่ประมาณสามนาที

อ่านความคิดเห็นเหมือนที่คุณจะอ่านเพื่อนร่วมทีมที่ใส่ใจ: เปิดตำแหน่งที่อ้างอิง ตัดสินใจว่าผลการค้นพบนั้นถูกต้องหรือไม่ จากนั้นดำเนินการ ที่ที่ Greptile เสนอ ‘Fix with your Agent’ มันส่งปัญหา — เส้นทางไฟล์ หมายเลขบรรทัด โค้ดที่แนะนำ — ไปยัง Claude Code, Codex, Conductor, Cursor หรือ Devin ‘Fix All’ ส่งปัญหาทั้งหมดในการตรวจสอบนั้นในครั้งเดียว พวกเขายังมี Greptile MCP และปลั๊กอิน Claude Code สำหรับการส่งต่อนั้นด้วย Maguyva ไม่อยู่ในรายการเป้าหมายที่มีชื่อนั้น การขาดหายไปนั้นไม่ใช่ปัญหา Maguyva ทำงานของมันเสร็จแล้วในขั้นตอนที่ 1 เอเจนต์เขียนโค้ดที่เขียน PR นั้นคือฝ่ายที่ควรได้รับ payload การแก้ไข

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

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

วิธีรักษาความซื่อสัตย์ของการเสริมกันนี้

• Maguyva มาก่อนเสมอ การตรวจสอบ PR ที่มีไฟล์ผิดก็ยังคงเป็นการตรวจสอบไฟล์ผิดอยู่ดี
• Greptile มาทีหลังเสมอ ร่างที่อ้างอิงได้ดียังคงต้องการการอ่าน diff ระดับทั้งระบบ
• อย่าขอให้ Maguyva เผยแพร่ความคิดเห็น PR มันไม่ทำอย่างนั้น
• อย่าขอให้ Greptile เป็นชั้นการดึงข้อมูลแรกของเอเจนต์ในขณะที่มันยังคงเลือกเส้นทางอยู่ นั่นไม่ใช่งานที่ออกแบบไว้สำหรับแอป GitHub หรือ GitLab ของพวกเขา
• อย่าประดิษฐ์ไปป์ไลน์ bash ที่ ‘ซิงค์’ ทั้งสองอย่าง PR คืออินเทอร์เฟซนั้น
• ตรวจสอบทั้งสองฝั่งแยกกัน จัดทำดัชนีรีโพที่คุณรู้จักอยู่แล้ว ถามคำถามหนึ่งข้อที่คุณสามารถตรวจสอบได้ จากนั้นเปิด PR เล็ก ๆ และอ่านสิ่งที่ Greptile แสดงความคิดเห็นจริง ๆ

วงจรนี้กลายเป็นเรื่องธรรมดาเมื่อได้รับการตั้งชื่อแล้ว แผนที่ก่อน PR ของเอเจนต์ ตรวจสอบทีหลัง แต่ละผลิตภัณฑ์ยังคงอยู่ในฝั่งของ pull request ที่ตนเชี่ยวชาญ

// map first. review second. in that order.