Điểm nổi bật
- Bài gốc mô tả dự án 6 repo: tác giả nói workflow này được dùng trên hệ thống gồm 6 repository với Go, Node.js và React.
- Context window cực lớn nhưng vẫn chưa đủ: tác giả dùng Opus 4.7, 1M context và vẫn kết luận bài toán thật sự là quản trị context, không phải chỉ tăng token.
- Mô hình 3 vai trò: tách agent thành lead planner, implementer và reviewer thay vì coi “AI” là một khối duy nhất.
- HN phản ứng nhanh: thread mới chỉ khoảng 2 điểm sau 11 phút, nhưng chủ đề chạm đúng nỗi đau chung của đội dùng coding agent cho codebase lớn.
- Giá trị vận hành: đây là một discussion đáng chú ý vì nó chuyển trọng tâm từ prompt sang quy trình phối hợp, artifact bền vững và end-to-end verification.
Biểu đồ
Tóm tắt
Điểm làm thread này đáng đọc không nằm ở chuyện “Claude Code mạnh đến đâu”, mà ở việc tác giả mô tả rất rõ khi dùng coding agent cho dự án lớn thì thứ dễ vỡ nhất là ngữ cảnh. Dù có context window lớn, agent vẫn có thể sinh code nhìn sạch, chạy được, nhưng sai ở những ràng buộc mà nó không nắm hết. Điều đó kéo cuộc thảo luận sang vùng thực tế hơn nhiều so với các màn demo ngắn.
Cách tiếp cận 3 vai trò — planner, implementer, reviewer — vì vậy trở thành điểm chốt. Nó biến AI từ một người viết code duy nhất thành một quy trình kiểm soát chất lượng có handoff, có plan.md làm nguồn sự thật, và có verify end-to-end trước khi đánh dấu xong. Với đội đang scale coding agent sang nhiều repo, đây là tư duy vận hành đáng chú ý hơn mọi benchmark model.
Chi tiết
Bài viết gốc của LocalCan mô tả một workflow dùng Claude Code cho dự án lớn, trong đó tác giả nhấn mạnh rất thẳng rằng bottleneck không còn là tốc độ sinh code, mà là cách giữ cho model luôn nhìn đúng phần việc cần nhìn. Đây là một quan sát đáng giá vì nó phản ánh giai đoạn trưởng thành hơn của thị trường coding agent. Khi model đã đủ giỏi để viết nhanh, vấn đề chuyển sang kiểm soát sự đúng đắn xuyên nhiều repo, nhiều service và nhiều quyết định kiến trúc đã tồn tại trước đó.
Mấu chốt của workflow là tách AI thành ba vai trò. Lead planner chịu trách nhiệm viết kế hoạch tổng thể thành file plan.md, định nghĩa phạm vi từng phase và contract giữa các phần. Implementer chỉ đào sâu một phase cụ thể, không tự ý thay đổi quyết định kiến trúc. Reviewer vào với bối cảnh “lạnh”, chuyên đọc lại code theo master plan để soi lệch hướng và gợi ý tối giản hóa. Chu trình reviewer → implementer → lead giúp mọi thay đổi lớn đều đi ngược lại master plan trước khi lan sang phase tiếp theo. Đây là một cơ chế governance khá hợp lý cho code sinh bởi agent.
Điều HN có thể tranh luận sâu từ thread này là việc “thêm vai” cho AI thực ra là thêm cấu trúc cho con người. Plan.md không chỉ là tài liệu cho model; nó là cách neo quyết định để các session khác nhau không drift khỏi nhau. Trong môi trường nhiều repository, drift này rất đắt: sai ở phase đầu thì các phase sau nhân lỗi lên theo cấp số nhân. Chính vì vậy, thread gợi ra một nguyên tắc quan trọng: càng nhiều agent, càng phải có artifact bền vững để neo context.
Bài viết cũng đáng chú ý ở phần verify. Tác giả không dừng ở unit test mà đẩy sang end-to-end, thậm chí mở tunnel để chạy vòng lặp thật với upstream service. Đây là điểm khác giữa demo và vận hành. Coding agent chỉ trở nên đáng tin khi nó có thể tự thấy hậu quả của code qua test, log, screenshot hoặc traffic thật. Nếu không có vòng phản hồi đó, agent chỉ giỏi viết ra thứ “có vẻ đúng”.
Về chiến lược, discussion này nói một điều quan trọng cho doanh nghiệp: lợi thế cạnh tranh không còn nằm riêng ở chọn model nào, mà ở việc bạn có thiết kế được workflow giảm sai lệch context, giảm quyết định mồ côi và tăng khả năng tự kiểm chứng của agent hay không. Trong ngắn hạn, đây có lẽ là đòn bẩy thực dụng hơn việc cứ chạy theo model mới hơn.