Ngày 15/7/2026, xAI mã nguồn mở Grok Build — một coding agent chạy trên terminal, dùng model Grok 4.6, có giao diện terminal toàn màn hình, hỗ trợ subagent gốc, plan mode, và tích hợp sâu với git worktree. Nhìn trên giấy, nó giống hệt danh sách tính năng của Claude Code. Điều này không phải ngẫu nhiên: cả nhóm công cụ “agentic CLI” đã hội tụ về cùng một kiến trúc trong hơn một năm qua — lên kế hoạch trước, giao việc cho subagent, cô lập công việc bằng worktree, và expose mọi thứ qua MCP. Điều thú vị không nằm ở kiến trúc chung đó, mà ở chỗ mỗi vendor làm khác nhau như thế nào bên trong nó. Tôi chạy Grok Build song song với Claude Code trong một tuần trên một refactor thật — tách một service Express dạng monolith thành các module riêng — và muốn chia sẻ những điểm khác biệt thực sự.

Kiến trúc giống hệt nhau — và chính điều đó mới đáng nói

Cả hai công cụ đều bắt đầu task bằng giai đoạn lập kế hoạch, mọi thay đổi file đều bị chặn cho đến khi bạn duyệt plan. Cả hai đều cho phép comment vào từng bước trong plan hoặc viết lại toàn bộ trước khi có bất kỳ dòng code nào bị sửa. Cả hai đều giao các task lớn cho subagent chạy song song, mỗi subagent có context window riêng, và cả hai đều có thể chạy các subagent đó trong worktree git riêng để công việc song song không đụng nhau trên cùng một file. Sự hội tụ này nói lên điều gì đó: sau một năm thử-sai trên toàn ngành, mô hình “lên kế hoạch → cô lập → song song hoá → xác minh” đã trở thành kiến trúc chuẩn cho agentic coding, giống cách REST hội tụ về mô hình verb-resource. Nếu sáu tháng nữa bạn đánh giá một công cụ agentic CLI mới, hãy kỳ vọng nó cũng sẽ có hình dạng tương tự.

Grok Build khác biệt ở đâu

Khác biệt cụ thể nhất tôi tìm thấy là mức độ song song của subagent: Grok Build công bố rõ hỗ trợ tới tám subagent chạy song song cho một task, trong khi Claude Code mặc định fan-out thận trọng hơn. Với refactor tách module — tách tám route handler thành tám file riêng, mỗi file cần test riêng và cập nhật import — trần song song cao hơn của Grok Build giúp nó hoàn thành bước tách cơ học nhanh hơn rõ rệt về thời gian thực, vì nhiều cặp file độc lập thực sự chạy cùng lúc thay vì xếp hàng.

Nhưng nhanh hơn không đồng nghĩa với tốt hơn, và đây mới là phần thú vị của tuần thử nghiệm. Khi tám subagent chạy thực sự song song trên cùng một monorepo, hai trong số đó đưa ra giả định không tương thích về signature mới của một hàm tiện ích dùng chung — một subagent sửa hàm để nhận một object options, subagent còn lại vẫn giả định hàm nhận tham số theo vị trí, và context window của mỗi bên không hề chứa phần chỉnh sửa đang dang dở của bên kia. Mức độ song song mặc định thận trọng hơn của Claude Code khiến va chạm kiểu này ít xảy ra hơn trong cùng một phiên, đơn giản vì có nhiều tính tuần tự hơn, nên subagent chạy sau có cơ hội thấy được kết quả đã hoàn thành của subagent chạy trước trước khi bắt đầu. Không lỗi nào trong hai kiểu này là bản chất của model — đó là đánh đổi giữa lập lịch và chia sẻ context, và đây là điều tôi khuyên bất kỳ tech lead nào đang đánh giá các công cụ này nên test rõ ràng trước khi tin tưởng giao việc trên codebase dùng chung: đưa cho agent một task buộc phải chạm vào một interface chung từ nhiều góc cùng lúc, rồi xem nó có tự phát hiện ra sự không nhất quán trước khi bạn phát hiện hay không.

Khả năng mở rộng: gần như ngang nhau, có một khoảng cách thật

Grok Build đóng gói skill, agent, hook và MCP server vào một lần cài, hỗ trợ mô hình marketplace lẫn tự host từ bất kỳ git repo nào — về chức năng khá gần với câu chuyện plugin và MCP của Claude Code. Tôi kết nối cả hai công cụ với cùng một MCP server Postgres và một MCP server Sentry cho refactor này, cả hai đều nhận tool definition mà không gặp trở ngại gì. Khoảng cách tôi tìm thấy không nằm ở cơ chế mở rộng, mà ở độ trưởng thành của hệ sinh thái xung quanh: marketplace MCP của Claude Code đã có thêm khoảng một năm để tích luỹ các MCP server do cộng đồng maintain cho các công cụ nội bộ ngách, nên với team đã có sẵn MCP server nội bộ tuỳ biến, chi phí chuyển đổi gần như bằng không dù chọn công cụ nào — nhưng nếu bạn bắt đầu từ số 0 và muốn dựa vào các integration dựng sẵn, hiện tại Claude Code vẫn có catalog sâu hơn.

Ý nghĩa cho việc chọn công cụ

Việc Grok Build được mã nguồn mở thay đổi bài toán nhiều hơn bất kỳ tính năng riêng lẻ nào. Khả năng tự host từ bất kỳ git repo nào nghĩa là một platform team có thể fork nó, gỡ bỏ telemetry, thêm auth nội bộ, và ship như một công cụ nội bộ được duyệt mà không cần chờ roadmap của vendor — đây là lựa chọn thật sự có ý nghĩa với môi trường quản lý chặt, nơi “source code của agent CLI phải audit được” là yêu cầu bắt buộc trong procurement, không phải chỉ là điểm cộng. Nếu ràng buộc này không áp dụng cho bạn, câu trả lời thành thật sau một tuần dùng song song là việc chọn công cụ nào phụ thuộc vào việc bạn tin tưởng output của model nào hơn cho stack cụ thể của mình, chứ không phải lớp wrapper CLI nào khách quan tốt hơn — kiến trúc wrapper đã hội tụ đến mức không còn là yếu tố khác biệt nữa.

Kết luận thực chiến

Nếu bạn là tech lead đang cân nhắc chuẩn hoá team về một agentic CLI duy nhất, đừng đánh giá dựa trên danh sách tính năng — plan mode, subagent, cô lập bằng worktree giờ đã là tiêu chuẩn tối thiểu, không còn là điểm khác biệt. Hãy đánh giá dựa trên hai thứ: công cụ hành xử thế nào khi nhiều subagent cần thống nhất về một interface dùng chung giữa chừng task (đây là nơi sinh ra bug thật), và việc tự host hay khả năng audit source code có phải yêu cầu thực sự trong môi trường của bạn hay không. Mọi thứ khác gần như ngang nhau đến mức chất lượng model trên codebase cụ thể của bạn mới là yếu tố quyết định, không phải giao diện terminal.