Trò chuyện cùng đội ngũ phát triển Claude Code: Tương lai của lập trình AI

Ngày 21 tháng 7 năm 2026

Đầu tháng này, tôi đã tổ chức một buổi trò chuyện thân mật tại AI Engineer World’s Fair với Cat Wu và Thariq Shihipar từ đội ngũ Claude Code của Anthropic. Chúng tôi đã thảo luận về Claude Code, Claude Tag, Fable, bảo mật cho các tác nhân lập trình (coding agent), các phương pháp đánh giá (evals), thiết kế công cụ và cách chính Anthropic sử dụng những công cụ này.

Video đầy đủ của buổi trò chuyện hiện đã có trên YouTube. Dưới đây là bản ghi chép đã được biên tập lại, kèm theo các liên kết bổ sung và những điểm nhấn được tôi in đậm.

Một vài lưu ý chính nếu bạn không muốn xem video hoặc đọc toàn bộ bản ghi chép:

Công việc hàng ngày của bạn đã thay đổi như thế nào trong năm qua?

1:05

Simon: Claude Code ra mắt vào tháng 2 năm ngoái — nó mới chỉ được chưa đầy một năm rưỡi, và ban đầu chỉ là một gạch đầu dòng trong buổi ra mắt Claude Sonnet 3.7. Công việc hàng ngày của các bạn đã thay đổi thế nào trong năm qua, khi chúng ta đã có những tác nhân lập trình thực sự làm việc cho mình?

Cat: Tôi nhớ khi chúng tôi mới ra mắt Claude Code và Sonnet 3.7, bạn giao cho nó một nhiệm vụ và phải giám sát chặt chẽ từng việc nhỏ mà nó thực hiện. Tôi thường đọc từng lời nhắc cấp quyền (permission prompt) một cách cực kỳ cẩn thận. Tôi thường xuyên phải nói không — không, không, không, bạn đã kiểm tra tệp này chưa? Bạn đã kiểm tra tệp kia chưa? Và giờ đây, mọi thế hệ mô hình mới đều mang lại kết quả đáng kinh ngạc. Tôi cảm thấy tất cả chúng tôi đều có cơ hội lùi lại một bước và ủy quyền nhiều hơn các công việc triển khai vụn vặt cho Claude. Điều đó giải phóng rất nhiều thời gian để chúng tôi suy nghĩ về những công việc sáng tạo hơn, chẳng hạn như: trải nghiệm đúng đắn mà chúng tôi nên cung cấp cho người dùng là gì, khi chúng ta biết Claude Code có thể triển khai phần lớn trong số đó? Và giờ đây với Fable, đó là một bước tiến thay đổi hoàn toàn. Chúng tôi thấy rằng với rất nhiều trường hợp sử dụng, bạn thực sự có thể hoàn thành hàng loạt tính năng chỉ trong một lần chạy với Fable.

Thariq: Tôi nhớ tin nhắn đầu tiên tôi nhận được về Claude Code. Một trong những người bạn thân nhất của tôi đã nói: "Bạn cần phải thử Claude Code ngay." Đó là khoảng thời gian Opus 4 ra mắt, tôi đã thử và thốt lên: "Ôi trời. Mình cần phải làm việc tại Anthropic ngay bây giờ." Đó là Opus 4 — một mô hình tuyệt vời, nhưng bạn vẫn phải đọc các lời nhắc cấp quyền. Thật điên rồ khi chúng ta lại nhanh quên đến vậy, kiểu như tôi tự hỏi, ồ, chế độ tự động (auto mode) vẫn luôn ở đây mà, phải không? Tôi thậm chí không nhớ mình đã từng phải nhấn "có" và "cho phép". Đối với tôi, điều quan trọng mà tôi đang tự thúc đẩy bản thân là chúng ta phải thực hiện công việc với chất lượng cao hơn bao giờ hết. Các kết quả đầu ra có chất lượng cực kỳ cao. Tôi đã sử dụng nó để chỉnh sửa video rất nhiều, và tôi nghĩ, được rồi, nó phải đáp ứng được những yêu cầu khắt khe từ đội ngũ thương hiệu của chúng tôi trong vài giờ, nếu không chúng tôi sẽ không thể làm được. Đó là cách tôi đang cố gắng thay đổi với Fable: thực hiện công việc tốt nhất mà chúng tôi từng làm, với tốc độ nhanh hơn bao giờ hết.

Phần nào của kỹ thuật phần mềm truyền thống không còn đúng nữa?

3:39

Simon: Có phần nào của kỹ thuật phần mềm truyền thống từng đúng một năm trước mà bạn nghĩ không còn đúng trong thế giới mới này nữa không?

Cat: Một trong những thay đổi lớn nhất mà chúng tôi thấy trong bộ kỹ năng kỹ thuật: hai năm trước, một quản lý sản phẩm (product manager) thường sẽ đi nói chuyện với một nhóm khách hàng, dành sáu tháng để thống nhất với các nhóm liên chức năng về một tài liệu yêu cầu sản phẩm (PRD), và viết một bản đặc tả kỹ lưỡng về cách chúng tôi sẽ triển khai nó trước khi dòng mã đầu tiên được viết. Bây giờ mọi thứ hoàn toàn ngược lại. Đối với nhiều kỹ sư, lời khuyên của tôi là hãy phát triển tư duy kinh doanh và tư duy sản phẩm nhiều hơn về những gì chúng ta nên xây dựng, bởi vì khoảng thời gian từ khi có ý tưởng đến khi xây dựng xong đã ngắn hơn rất nhiều — giảm từ sáu đến mười hai tháng xuống chỉ còn khoảng một tuần. Điều đó có nghĩa là tất cả chúng ta cần có gu thẩm mỹ tốt hơn về những gì đáng xây dựng, những gì thực sự sẽ tạo ra tác động cho doanh nghiệp mà chúng ta đang làm việc. Vì vậy, giá trị của tư duy sản phẩm và tư duy kinh doanh đang tăng lên, trong khi tầm quan trọng của việc thực thi thuần túy lại giảm đi ở hầu hết các lĩnh vực sản phẩm. Tất nhiên, đối với hạ tầng (infra), vẫn cần chú trọng rất nhiều vào việc đảm bảo mọi chi tiết đều chính xác.

Thariq: Với tôi, đó là việc viết lại mã (rewrite) giờ đây là một điều tốt.

Simon: Điều tồi tệ nhất bạn có thể làm giờ đây thực ra lại ổn!

Thariq: Chính xác. Tất cả những lý thuyết trong cuốn "The Mythical Man-Month" — đừng bao giờ viết lại mã — tôi lại ủng hộ việc viết lại ngay bây giờ. Nếu bạn có một bộ kiểm thử (test suite) tốt — và tôi nghĩ việc viết lại thực sự buộc bạn phải đảm bảo mình có một bộ kiểm thử tốt — nhưng tôi nghĩ điều mọi người đánh giá thấp là một cơ sở mã (codebase) chính là một bản đặc tả, và có lẽ đó là bản sao duy nhất mà bạn có, vì không ai biết hết mọi nhánh của cơ sở mã đó. Bạn có thể coi đây là một hiện vật và chắt lọc nó hoặc tạo ra các phiên bản khác từ nó. Chúng tôi đã viết lại Bun bằng Rust và nó hoạt động rất tuyệt — nó đang chạy trực tiếp cho tôi ngay lúc này.

Simon: Bạn chưa phát hành Claude Code trên Bun-in-Rust đúng không?

Thariq: Nội bộ chúng tôi đã làm rồi.

(Thực tế có vẻ như Anthropic đã bắt đầu phát hành Claude Code trên Bun-in-Rust cho tất cả mọi người vào ngày 17 tháng 6.)

Những người không phải kỹ sư đang làm gì với Claude Tag?

6:36

Simon: Một đợt ra mắt lớn khác gần đây là Claude Tag — tính đến nay đã được một tuần, ít nhất là đối với phần còn lại của chúng ta. Tôi hiểu rằng nó đang được sử dụng rất nhiều tại Anthropic bởi những người không phải kỹ sư. Những người không phải kỹ sư đang làm gì với Claude Tag?

Cat: Claude Tag là một Claude sống trong các công cụ cộng tác của nhóm bạn. Chúng tôi đã ra mắt nó tuần trước trong Slack. Điểm khác biệt của Claude Tag là nó hỗ trợ nhiều người dùng (multiplayer) theo mặc định. Khi bạn thêm Claude Tag vào một kênh Slack, bạn có thể tham gia, đồng nghiệp của bạn có thể tham gia và các bạn có thể cùng nhau cộng tác trên một PR (Pull Request). Điểm khác biệt lớn thứ hai là nó chủ động thay vì bị động. Bạn có thể nói với Claude Tag: "Này, hãy giám sát mọi báo cáo lỗi trong kênh này, tạo một PR để sửa lỗi đó và gắn thẻ kỹ sư đã chạm vào phần mã này gần đây nhất", và nó sẽ thực hiện việc đó trong suốt thời gian tồn tại của kênh mà bạn không cần phải gắn thẻ thủ công. Và thay đổi lớn thứ ba là chúng tôi đã thêm bộ nhớ nhóm (team memory) vào đây. Nếu bạn nói với Claude Tag về các tùy chọn của mình trong kênh, nó sẽ ghi nhớ chúng cho mọi bài đăng trong tương lai. Nếu bạn luôn muốn nó gỡ lỗi các sự cố nhưng không muốn nó gỡ lỗi các cảnh báo, chỉ cần nói điều đó bằng ngôn ngữ tự nhiên trong kênh và nó sẽ ghi nhớ cho bạn cũng như mọi người trong nhóm.

Nội bộ, chúng tôi coi Claude Tag là sự tiến hóa của Claude Code. Chúng tôi coi đây là một thay đổi lớn trong cách làm việc nội bộ. Hiện tại, Claude Tag thực hiện thành công 65% các PR kỹ thuật sản phẩm của chúng tôi.

Simon: Cho toàn bộ Anthropic, hay chỉ cho Claude Code?

Cat: Đây chỉ dành cho đội ngũ kỹ thuật sản phẩm của chúng tôi — phiên bản nội bộ của Claude Tag hiện đang thực hiện thành công 65% các PR sản phẩm. Đây là một thay đổi lớn; con số này chiếm hơn 50% tổng số PR của chúng tôi. Cách chúng tôi thấy mọi người phân chia công việc giữa Claude Code và Claude Tag là: Claude Code vẫn là nơi tốt nhất cho các tác vụ phức tạp nhất, khi bạn tương tác lặp đi lặp lại với tác nhân. Nhưng Claude Tag lại tuyệt vời cho việc để nó chủ động làm việc thay bạn, vì vậy bạn không còn cần phải khởi chạy thủ công Claude Code cho tất cả các báo cáo lỗi phát sinh đối với các tính năng mà bạn đang thực hiện.

Thariq: Và đối với các trường hợp không liên quan đến lập trình: ví dụ, trước buổi trò chuyện này, chúng tôi đã hỏi Claude Tag: "Này, khi nào Fable ra mắt?" Chúng tôi muốn đảm bảo rằng mình đã căn chỉnh nó với thông báo. Claude Tag sẽ tìm kiếm trong Slack của chúng tôi và xem ai đã nói gì. Như một công cụ tìm kiếm cho công ty, nó thực sự rất giá trị. Nó có tất cả ngữ cảnh về sản phẩm của bạn, vì vậy bạn có thể hỏi nó các câu hỏi liên quan đến số liệu — thường khi đưa ra quyết định, bạn muốn chúng được thông tin bởi những gì số liệu cho thấy, vì vậy bạn kết nối nó với kho lưu trữ sự kiện (event store) của mình. Tôi đã thấy đội ngũ tiếp thị của chúng tôi làm những việc như: "Này, hãy cho tôi biết về tính năng này." Họ không phải là lập trình viên, nhưng Claude là một lập trình viên — nó có thể sao chép cơ sở mã và nói: "Đây là tính năng, đây là hình dáng của nó, đây là bản ghi tôi đang sử dụng tính năng này." Nó cho phép thực hiện rất nhiều việc đa dạng, và tôi nghĩ chúng ta vẫn còn ở giai đoạn đầu trong việc khám phá điều đó.

Claude Tag như một lớp cộng tác nhóm

10:06

Simon: Một trong những vấn đề tôi gặp phải với các tác nhân lập trình là tôi hiểu cách sử dụng chúng với tư cách cá nhân, nhưng tôi không thực sự rõ cách sử dụng chúng trong môi trường nhóm. Có vẻ như Claude Tag là câu trả lời hiện tại của các bạn cho lớp cộng tác nhóm đó.

Cat: Chính xác. Và một tỷ lệ lớn các phiên làm việc của chúng tôi hiện thực sự là đa người dùng. Có lẽ tôi nói: "Này, tôi nghĩ chúng ta nên triển khai tính năng mới này trong Cowork", và tôi sẽ gắn thẻ Claude Tag để thực hiện bước đầu tiên. Sau đó, tôi sẽ nói với Claude Tag: "Hãy chia sẻ bản ghi về quá trình triển khai cuối cùng của bạn", và tôi sẽ gắn thẻ đội thiết kế để họ xem qua. Họ sẽ điều chỉnh, sau đó chuyển cho đội kỹ thuật để hoàn thiện và đưa ra môi trường sản xuất (prod). Đó là một trải nghiệm rất linh hoạt. Chúng tôi vẫn đang cố gắng hoàn thiện các động lực xã hội để điều hướng cùng một phiên làm việc, nhưng chúng tôi nhận thấy mọi người chỉ cần quan sát cách người khác sử dụng và tuân theo các chuẩn mực xã hội đó — việc tích hợp Claude Tag vào các nhóm của chúng tôi khá trực quan.

Thariq: Nó rất tuyệt để dạy mọi người, và cũng để giảm bớt sự cẩu thả, bởi vì việc mọi người cùng thấy bạn sử dụng Claude giúp nâng cao trình độ sử dụng Claude của chính họ.

Điều này làm tôi nhớ đến cách Midjourney giải quyết thách thức trong việc dạy mọi người cách viết câu lệnh (prompt) hình ảnh nâng cao bằng cách bắt buộc thực hiện công khai trong các kênh Discord của họ.

Làm thế nào để bạn quyết định tính năng nào đáng xây dựng khi việc xây dựng trở nên rẻ hơn nhiều?

11:41

Một điều tôi thấy thực sự khó khăn là biết khi nào một tính năng đáng để phát hành khi chi phí xây dựng tính năng đã giảm đi rất nhiều.

Simon: Các bạn giải quyết vấn đề khó nhất trong kỹ thuật như thế nào — sự ưu tiên? Làm thế nào để bạn quyết định tính năng nào đáng xây dựng và phát hành khi việc xây dựng một tính năng hiện nay rẻ hơn nhiều?

Cat: Đây là điều khó khăn. Có một vài cách chúng tôi tiếp cận nó. Một là chúng tôi sử dụng chính sản phẩm của mình (dogfooding) mỗi ngày. Bất cứ khi nào có điều gì đó chúng tôi muốn làm trong sản phẩm của mình mà chúng tôi không thể, thay vì tìm một giải pháp khác, chúng tôi sửa sản phẩm của mình để nó có thể hỗ trợ trường hợp đó. Chúng tôi có văn hóa sử dụng sản phẩm nội bộ rất mạnh mẽ. Trước khi chia sẻ sản phẩm với mọi người trên thế giới, chúng tôi chia sẻ chúng với tất cả mọi người trong Anthropic, và với một số khách hàng sớm, những người đưa ra phản hồi rất trung thực — càng thẳng thắn càng tốt — và chúng tôi lặp lại cho đến khi mọi người yêu thích nó. Chúng tôi có một tiêu chuẩn nội bộ về số lượng người dùng hoạt động và mức độ giữ chân (retention) mà một tính năng phải đạt được trước khi chúng tôi chia sẻ nó với thế giới. Vì tiêu chuẩn này rất rõ ràng, mọi kỹ sư đều biết họ đang cố gắng đạt được điều gì. Tôi nghĩ điều này cũng nâng cao độ hoàn thiện của chúng tôi, bởi vì nếu tính năng không được trau chuốt, mọi người sẽ rời bỏ — và khi đó chúng tôi không nên phát hành tính năng đó.

Việc sử dụng tỷ lệ giữ chân người dùng nội bộ để quyết định xem một tính năng có nên được phát hành hay không đối với tôi là rất hợp lý.