Bản đồ trước, xem xét sau

Hai công việc khác nhau nằm ở hai bên của một pull request. Trước khi agent viết, nó cần một bản đồ của cây mà nó sắp thay đổi. Sau khi agent mở một PR, một thứ gì đó nên đọc thay đổi đó so với phần còn lại của hệ thống và để lại các bình luận mà con người có thể hành động theo.

Những công việc này trông giống nhau từ xa vì cả hai đều liên quan đến ‘hiểu codebase’. Chúng không phải là cùng một sản phẩm. Một cái trả lời ‘thay đổi này nên hạ cánh ở đâu?’. Cái kia trả lời ‘diff này đã phá vỡ điều gì mà một linter kiểm tra từng dòng sẽ bỏ lỡ?’. Trộn lẫn chúng tạo ra một bản nháp đầu tiên tệ hơn và một sự xem xét ồn ào hơn.

Bài viết này là một hướng dẫn quy trình làm việc chung. Maguyva là bản đồ mà agent truy vấn trước tiên. Greptile là agent xem xét bình luận trên PR sau đó. Cặp này bổ sung cho nhau theo cấu trúc: Maguyva không xem xét pull request, và Greptile không thay thế lớp ngữ cảnh mà agent đã sử dụng để viết chúng.

Tại sao sự phân chia này hữu ích

Một coding agent xuất phát từ các tiền đề huấn luyện cộng với vài file được dán vào sẽ bịa ra một đường dẫn hợp lý và chỉnh sửa nó. Đó là thất bại ‘sai file’, và đó là một vấn đề truy xuất. Maguyva là một lớp ngữ cảnh codebase MCP từ xa: truy xuất ngữ nghĩa, cấu trúc (AST), đồ thị/phụ thuộc và văn bản được hợp nhất thành kết quả được xếp hạng, cộng với tìm kiếm symbol và truy xuất file. Các câu trả lời có căn cứ trở về dưới dạng path/file.ext:line, để bạn có thể từ chối một sai sót trước khi bản vá tồn tại. Tuyên bố vẫn khiêm tốn: ít thay đổi bị ảo giác hơn. Model vẫn có thể đoán. Chỉ là bước đầu tiên không còn là một sự đoán mò nữa.

Greptile là một agent xem xét code chạy bằng AI. Theo lời họ, nó tự động xem xét mọi pull request với sự hiểu biết đầy đủ về codebase, và đặt điều đó đối lập với các linter truyền thống kiểm tra file một cách riêng lẻ thay vì toàn bộ hệ thống. Việc thiết lập bao gồm cài đặt ứng dụng GitHub hoặc GitLab và chọn repository. Không có chỉ mục cục bộ nào bạn phải vận hành. Việc lưu trữ là Greptile Cloud (họ tuyên bố tuân thủ SOC 2 Type II, với báo cáo có sẵn theo yêu cầu), với tùy chọn tự lưu trữ được cung cấp cho các doanh nghiệp.

Quy trình được đánh số của riêng họ là: kết nối và xây dựng một đồ thị phụ thuộc của mọi function, class và phụ thuộc; ở mỗi pull request, phân tích thay đổi bằng cách sử dụng đồ thị repo đầy đủ đó và công bố các phát hiện dưới dạng bình luận PR với các sửa chữa được đề xuất, trong khoảng ba phút; mỗi bình luận có thể chuyển giao vấn đề cho một coding agent mà nhóm đã sử dụng. Họ cũng tuyên bố đọc các bình luận PR của con người trước đây theo thời gian để học các tiêu chuẩn code của một nhóm và giảm các đề xuất gây ồn ào. Hệ thống học tập của họ, theo tuyên bố của họ, cần 2-3 tuần để thích ứng.

Đó là xem xét, không phải soạn thảo. Điểm nổi bật của Greptile là ngữ cảnh đồ thị repo đầy đủ trên thay đổi đã hạ cánh trong một PR, tiếp theo là một vòng lặp khép kín gửi phát hiện đến Claude Code, Codex, Conductor, Cursor, hoặc Devin. Điểm nổi bật của Maguyva là bản đồ được xếp hạng mà agent đã truy vấn trước khi thay đổi đó được viết. Sử dụng cả hai. Đừng yêu cầu một trong hai làm công việc của cái kia.

Một tích hợp sản phẩm bên thứ nhất giữa Maguyva và Greptile không được nêu ra. Bạn cũng không cần nó. Maguyva nói chuyện với agent qua MCP. Greptile nói chuyện với GitHub hoặc GitLab thông qua ứng dụng riêng của họ. Chúng gặp nhau tại pull request. Không có script keo dán, không có cron kết nối một công cụ với công cụ kia. Cặp này không cần bash vì mỗi sản phẩm đã đứng trên bề mặt thuộc về nó.

Đây không phải là gì

Đây không phải là một bài đánh sập Greptile. Đây không phải là một trang ‘đổi người xem xét của bạn’. Greptile ra mắt trên Hacker News vào ngày 5 tháng 3 năm 2024 với tư cách là một công ty Y Combinator W24, và luồng đó là cách nhiều người lần đầu biết đến sản phẩm này. Nếu đó là cách bạn tìm thấy họ, hãy tiếp tục sử dụng họ. Trang này là nửa trước còn thiếu của vòng lặp đó: đặt nền tảng cho agent trước, để PR mà Greptile thấy đã nhắm vào đúng file.

Tài liệu tiếp thị của Greptile dẫn đầu bằng các tuyên bố về tốc độ xem xét và bắt lỗi. Hãy coi chúng như những tuyên bố của riêng Greptile, không phải những con số được xác minh độc lập. Bài viết này không lặp lại chúng như sự thật.

Phạm vi bao phủ ngôn ngữ cũng là loại trung thực tương tự. Greptile định khung việc hỗ trợ là bao phủ tất cả các ngôn ngữ lập trình thay vì một danh sách được liệt kê; một con số chính xác không được nêu ra. Maguyva công bố hỗ trợ hơn 279 ngôn ngữ và công nghệ dựa trên văn bản, với một sự phân chia kỹ thuật (AST được hỗ trợ bởi parser so với chỉ văn bản) trên trang web khi câu hỏi mang tính kỹ thuật. Đây là những sản phẩm khác nhau đưa ra những tuyên bố khác nhau. Đừng trộn lẫn chúng.

Giá cả của Greptile không được nêu trong tài liệu mà bài viết này được phép sử dụng. Các gói trả phí tồn tại; xem trang giá của họ. Maguyva tính phí theo không gian làm việc, không theo chỗ ngồi. Các gói bắt đầu miễn phí. Trang giá liệt kê các cấp đã công bố nếu bạn cần các con số về không gian làm việc.

Quy trình làm việc

Ba giai đoạn được đặt tên. Thực hiện chúng theo thứ tự này. Đừng bỏ qua bất kỳ giai đoạn nào trong lần đầu tiên bạn thử cặp này.

1. Ngữ cảnh Maguyva

Lập chỉ mục một repository mà bạn đã biết. Kết nối client MCP mà bạn đã đang viết code trong đó — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, hoặc một client tương thích MCP khác. Maguyva có các hướng dẫn thiết lập cho 24 client MCP đã được ghi chép và có thể kết nối với các client khác hỗ trợ cấu hình MCP chuẩn.

Đặt một câu hỏi bạn có thể đánh giá trước khi bất kỳ ai viết một dòng nào. ‘Việc hết hạn phiên được xử lý ở đâu, và cái gì gọi nó?’ là một nước đi đầu tiên tốt hơn ‘sửa auth’. Yêu cầu trích dẫn. Mở các kết quả file.ext:line. Theo dõi symbol. Xác nhận phụ thuộc mà bạn sắp chạm vào.

Maguyva cung cấp 11 công cụ MCP hướng tới khách hàng trên khắp tìm kiếm, symbol, phân tích phụ thuộc, truy xuất file, ngữ cảnh repository, và các quy trình công cụ tiện ích tất định. Bốn chế độ truy xuất được hợp nhất thành kết quả được xếp hạng; find_symbol là một công cụ riêng biệt khi bạn đã biết tên. Tài liệu mô tả con đường ngắn nhất: bắt đầu miễn phí, lập chỉ mục một repo mà bạn đã biết, kết nối client, sau đó đặt một câu hỏi bạn có thể xác minh.

Các snapshot có dấu thời gian, để agent có thể biết phiên bản nào của cây nó đang đọc. Giới hạn trung thực là công việc cục bộ chưa đồng bộ hóa. Nếu thay đổi chỉ tồn tại trong một working tree và chưa được push, bản đồ được lưu trữ vẫn chưa chứa nó. Các file hướng dẫn (CLAUDE.md, AGENTS.md) vẫn có chỗ đứng ở đây, dành cho các quy ước và những gì không nên chạm vào. Chúng không phải là một bản đồ sống. Sử dụng chúng cho hành vi. Sử dụng Maguyva cho các sự kiện.

Đừng để agent mở một PR trước khi các trích dẫn vượt qua sự tiếp xúc với repo. Cánh cổng đó là toàn bộ mục đích của giai đoạn này.

2. PR của agent

Cùng một agent giờ viết thay đổi trong client mà bạn đã trả tiền. Maguyva không phải là editor cũng không phải là người xem xét. Agent vẫn tạo ra diff. Bạn vẫn mở pull request trên GitHub hoặc GitLab như bạn đã làm.

Điều nên khác biệt là file đầu tiên. PR nên nêu tên handler thực sự triển khai hành vi, người gọi sẽ bị hỏng, và test sẽ thất bại nếu thay đổi sai. Nếu giai đoạn 1 bị bỏ qua, giai đoạn 3 sẽ dành bình luận của nó cho một thay đổi hạ cánh sai package. Greptile vẫn có thể tìm thấy các vấn đề hệ thống. Nó không nên đồng thời phải phục hồi từ một đường dẫn bị ảo giác.

Giữ PR trong phạm vi hẹp. Một file đầu tiên có căn cứ không phải là giấy phép để viết lại toàn bộ module. Cặp bổ sung này hoạt động khi agent làm một công việc với một bản đồ, sau đó yêu cầu người xem xét làm một công việc khác trên một diff có ranh giới.

3. Xem xét của Greptile

Greptile đã kết nối với repository thông qua ứng dụng GitHub hoặc GitLab. Trên pull request mới, nó phân tích thay đổi bằng cách sử dụng đồ thị repo đầy đủ mà nó đã xây dựng, và công bố các phát hiện dưới dạng bình luận với các sửa chữa được đề xuất. Tài liệu riêng của họ đặt lượt này vào khoảng ba phút.

Đọc các bình luận như bạn sẽ đọc một đồng nghiệp cẩn thận: mở vị trí được trích dẫn, quyết định xem phát hiện có thật hay không, sau đó hành động. Ở nơi Greptile cung cấp ‘Fix with your Agent’, nó gửi vấn đề — đường dẫn file, số dòng, code được đề xuất — đến Claude Code, Codex, Conductor, Cursor, hoặc Devin. ‘Fix All’ gửi tất cả các vấn đề trong lần xem xét cùng một lúc. Họ cũng cung cấp một Greptile MCP và một plugin Claude Code cho việc chuyển giao đó. Maguyva không có trong danh sách mục tiêu được đặt tên đó; sự vắng mặt đó không phải là vấn đề. Maguyva đã hoàn thành công việc của nó ở giai đoạn 1. Coding agent đã viết PR là người nên nhận payload sửa chữa.

Hãy mong đợi tiếng ồn trong 2-3 tuần đầu tiên trong khi hệ thống học tập của Greptile thích ứng với các bình luận mà nhóm của bạn thực sự để lại. Đó là lịch trình họ đã tuyên bố, không phải một khiếm khuyết của cặp đôi. Sự xem xét của con người vẫn ở trong vòng lặp. Greptile là lượt đầu tiên được tự động hóa, không phải nút merge.

Nếu một bình luận Greptile trỏ đến một file mà agent chưa bao giờ truy vấn ở giai đoạn 1, đó là một tín hiệu hữu ích. Hoặc bản đồ đã bỏ lỡ một người gọi, hoặc agent đã bỏ qua một trích dẫn. Sửa bản nháp theo bình luận đó. Đừng vô hiệu hóa người xem xét.

Cách giữ sự bổ sung này trung thực

• Maguyva luôn đi trước. Việc xem xét một PR sai file vẫn là việc xem xét file sai.
• Greptile luôn theo sau. Một bản nháp được trích dẫn tốt vẫn cần một lần đọc diff ở cấp độ toàn hệ thống.
• Đừng yêu cầu Maguyva công bố bình luận PR. Nó không làm điều đó.
• Đừng yêu cầu Greptile trở thành lớp truy xuất đầu tiên của agent trong khi nó vẫn đang chọn một đường dẫn. Đó không phải là công việc mà ứng dụng GitHub hoặc GitLab của họ được kết nối để làm.
• Đừng bịa ra một pipeline bash ‘đồng bộ hóa’ chúng. PR là giao diện.
• Xác minh cả hai phía một cách độc lập. Lập chỉ mục một repo mà bạn đã biết. Đặt một câu hỏi bạn có thể xác minh. Sau đó mở một PR nhỏ và đọc những gì Greptile thực sự bình luận.

Vòng lặp trở nên bình thường ngay khi nó được đặt tên. Bản đồ trước. PR của agent. Xem xét sau. Mỗi sản phẩm ở lại phía pull request mà nó giỏi.

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