How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)

Trong kỷ nguyên AI và AGI, tốc độ triển khai sản phẩm là yếu tố sống còn, đòi hỏi PM phải tập trung vào việc lặp lại và ra mắt tính năng nhanh chóng, đôi khi chỉ trong vài ngày thay vì hàng tháng.
Anthropic đã đạt được tốc độ triển khai sản phẩm cực nhanh bằng cách loại bỏ rào cản, đặt mục tiêu rõ ràng, sử dụng "phiên bản xem trước nghiên cứu" và thiết lập quy trình liên chức năng chặt chẽ.
Vai trò của PM đang thay đổi, ít nhấn mạnh vào lộ trình dài hạn mà chuyển sang tạo điều kiện cho các nhóm di chuyển nhanh, định nghĩa rõ ràng về thành công và trao quyền tự chủ cho các kỹ sư.

AGI (Artificial General Intelligence) — Trí tuệ tổng hợp nhân tạo
PM (Product Manager) — Quản lý Sản phẩm
AI-native products — sản phẩm thuần AI
Cross-functional — liên chức năng
LLM (Large Language Model) — mô hình ngôn ngữ lớn
Use case — trường hợp sử dụng
Research preview — phiên bản xem trước nghiên cứu
PRD (Product Requirements Document) — Tài liệu Yêu cầu Sản phẩm
Metric — chỉ số
Frontier models — mô hình tiên tiến

Tầm nhìn về `AGI` và Tốc độ Triển khai Sản phẩm

Theo tôi, rất khó để có thể cam kết vừa đủ với AGI. Việc xây dựng sản phẩm cho một mô hình AGI siêu mạnh rất dễ dàng. Điều khó là làm thế nào để khai thác tối đa khả năng từ mô hình hiện tại.

>> Tôi chưa từng thấy tốc độ nào như cách các bạn ở Anthropic đang triển khai sản phẩm.

Chúng tôi muốn loại bỏ mọi rào cản trong việc triển khai sản phẩm. Thời gian cho nhiều tính năng sản phẩm của chúng tôi đã giảm từ sáu tháng xuống còn một tháng, và đôi khi thậm chí chỉ còn một ngày. Bạn đang phỏng vấn hàng trăm PM và bạn cứ cảm thấy họ đang tiếp cận vấn đề này một cách rất sai lầm.

>> Vai trò PM đang thay đổi rất nhiều. Nó thay đổi thực sự nhanh chóng. Điều cực kỳ quan trọng để xây dựng các sản phẩm thuần AI (AI-native products) là lặp lại (phát triển) nhanh chóng, tìm ra cách để bạn thực sự ra mắt tính năng mỗi tuần.

>> Bạn nghĩ những kỹ năng mới nổi nào mà các PM cần phát triển?

Điều đó quay trở lại gu sản phẩm. Khi việc viết code trở nên rẻ hơn rất nhiều, điều trở nên có giá trị hơn là quyết định nên viết gì.

Hôm nay, khách mời của tôi là Cat Woo, Trưởng phòng Sản phẩm của Claude Code và Co-Work tại Anthropic. Cat đang ở trung tâm của mọi thay đổi trong lĩnh vực trí tuệ nhân tạo (AI), sản phẩm và phát triển. Cô ấy cùng đội ngũ của mình đang xây dựng sản phẩm thay đổi mạnh mẽ nhất cách chúng ta phát triển sản phẩm của mình. Cô ấy tràn đầy những hiểu biết sâu sắc, trí tuệ và bài học. Đây là một tập bạn không thể bỏ lỡ. Trước khi bắt đầu, đừng quên truy cập lennisprobass.com để xem những ưu đãi tuyệt vời dành riêng cho những người đăng ký nhận bản tin của Lenny. Với tất cả những điều đó, tôi xin giới thiệu Cat Woo. Cat, chào mừng bạn đến với podcast.

>> Cảm ơn vì đã mời tôi.

>> Tôi có rất nhiều câu hỏi. Tôi rất vui khi có bạn tham gia podcast này. Tôi muốn bắt đầu bằng cách giúp mọi người hiểu rõ về vai trò của bạn cùng với Boris. Mọi người đều biết Boris. Tập có Boris là tập phổ biến nhất trên podcast này. Không áp lực đâu nhé. Anh ấy đã tạo ra Claude Code. Anh ấy lãnh đạo nhóm, triển khai hàng tỉ PR (Pull Request) mỗi ngày từ điện thoại của mình. Tôi thậm chí không biết con số đó là bao nhiêu nữa. Tôi nghĩ mọi người không ghi nhận đủ công lao của bạn cho thành công mà Claude Code đã đạt được, cũng như Co-Work và tất cả những gì các bạn đang xây dựng. Hãy giúp chúng tôi hiểu rõ về vai trò của bạn trong nhóm, cách bạn làm việc với Boris, cách bạn phân chia trách nhiệm, vai trò PM trông như thế nào trong nhóm Claude Code?

Vai trò `PM` tại Anthropic và cách hợp tác với Boris

>> Tôi cảm thấy rất may mắn khi được làm việc với Boris. Anh ấy là một đối tác tư duy tuyệt vời. Anh ấy là trưởng nhóm kỹ thuật (tech lead) của chúng tôi. Anh ấy là người có tầm nhìn về sản phẩm và rất giỏi trong việc đặt ra, "Đây là những gì sản phẩm cần đạt được trong ba tháng, sáu tháng tới." Đây giống như phiên bản sản phẩm theo định hướng AGI (AGI-pilled) vậy. Và phần lớn vai trò của tôi là tìm ra, "Được rồi, lộ trình từ hiện tại đến tầm nhìn ba đến sáu tháng tới là gì?" Và tôi dành nhiều thời gian hơn cho các khía cạnh liên chức năng (cross-functional). Vì vậy, tôi đảm bảo rằng nhóm tiếp thị (marketing), nhóm bán hàng (sales), tài chính, năng lực, v.v., đều đồng tình với kế hoạch, và tất cả chúng tôi đều cùng chèo một thuyền, và một khi tính năng đã sẵn sàng thì không có bất kỳ trở ngại nào trong việc triển khai nó. Tôi nghĩ theo nhiều cách, nó hoạt động tốt vì chúng tôi có một kiểu cộng hưởng tư duy (mindmeld), nhưng thực ra đó là một đường ranh giới mờ nhạt đáng kể. Tôi nghĩ chúng tôi khoảng 80% cộng hưởng tư duy, và sau đó có khoảng 20% những điều mà có thể tôi quan tâm nhiều hơn Boris. Vì vậy, tôi sẽ chủ động thực hiện những việc đó. Và sau đó là 20% những điều mà anh ấy quan tâm nhiều hơn tôi, và anh ấy chỉ việc thực hiện chúng.

Tài trợ bởi WorkOS

>> Tập này được tài trợ bởi nhà tài trợ chính của mùa, WorkOS. OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay và hàng trăm công ty thành công khác có điểm chung là gì? Tất cả đều được cung cấp bởi WorkOS. Nếu bạn đang xây dựng một sản phẩm cho doanh nghiệp lớn (enterprise), bạn chắc hẳn đã cảm nhận được sự khó khăn khi tích hợp đăng nhập một lần (single sign-on), SCIM, RBAC, audit logs và các tính năng khác mà các công ty lớn yêu cầu. WorkOS biến những trở ngại giao dịch đó thành các API (giao diện lập trình ứng dụng) có thể tích hợp dễ dàng (drop-in API) với một nền tảng developer hiện đại được xây dựng dành riêng cho SaaS B2B (B2B SaaS). Hầu như mọi startup mà tôi là nhà đầu tư và bắt đầu mở rộng thị trường lên phân khúc cao hơn (upmarket) đều hợp tác với WorkOS. Và đó là bởi vì họ là những người giỏi nhất. Cho dù bạn là một startup giai đoạn hạt giống (seed-stage startup) đang cố gắng giành được khách hàng doanh nghiệp lớn đầu tiên hay một kỳ lân (unicorn) đang mở rộng toàn cầu, WorkOS là con đường nhanh nhất để trở nên sẵn sàng cho doanh nghiệp lớn (enterprise-ready) và khai thông tăng trưởng (unblocking growth). Về cơ bản, đó là Stripe cho các tính năng doanh nghiệp lớn. Hãy truy cập works.com để bắt đầu hoặc chỉ cần vào Slack của họ, nơi có các kỹ sư (engineer) thực thụ đang chờ trả lời câu hỏi của bạn. WorkOS cho phép bạn xây dựng nhanh hơn với các API dễ sử dụng, tài liệu toàn diện (comprehensive docs) và trải nghiệm developer mượt mà (smooth developer experience). Truy cập works.com ngay hôm nay để ứng dụng của bạn sẵn sàng cho doanh nghiệp lớn.

Vai trò `PM` trong `AI` đang thay đổi

Thực tế là bạn đang phỏng vấn hàng trăm PM mọi lúc là điều bạn đã chia sẻ trước khi chúng tôi bắt đầu ghi âm. Ví dụ, nếu tôi có một đồng niken mỗi khi có người yêu cầu tôi giới thiệu đến ai đó ở Anthropic để làm PM tại Anthropic, tôi sẽ có 30 tỷ ARR (Doanh thu định kỳ hàng năm). Đó chỉ đơn giản là nơi mà mọi người muốn làm việc nhất. Vì vậy, tôi chỉ có thể tưởng tượng bạn đang phỏng vấn bao nhiêu PM. Bạn nói với tôi rằng bạn thấy mọi người đang làm sai cách, cách họ tiếp cận những gì họ nghĩ cần có để trở thành một PM AI thành công. Hãy nói về những gì bạn đang thấy và những gì mọi người cần hiểu về việc cần những gì để thành công trong thời đại này.

Tốc độ phát triển sản phẩm `AI`

>> Tôi nghĩ rằng trước kỷ nguyên trí tuệ nhân tạo (AI), các thay đổi công nghệ diễn ra chậm hơn nhiều. Vì vậy, bạn có thể lập kế hoạch trên chân trời thời gian sáu đến mười hai tháng. Và vì bạn đang triển khai các tính năng với tốc độ chậm hơn một chút, nên có nhiều sự nhấn mạnh hơn vào việc phối hợp với tất cả các nhóm đối tác khác để đảm bảo rằng họ đang triển khai các tính năng giúp mở khóa các tính năng của bạn, bởi vì việc viết code vào thời điểm đó rất tốn kém. Tôi nghĩ rằng bây giờ, với trí tuệ nhân tạo (AI) và mức độ nó đã thúc đẩy quá trình kỹ thuật (engineering) nhanh hơn, cùng với việc khả năng của mô hình đang được cải thiện nhanh chóng, thời gian triển khai nhiều tính năng sản phẩm của chúng tôi đã giảm từ sáu tháng xuống còn một tháng, và đôi khi xuống còn một tuần hoặc thậm chí một ngày. Với điều đó, chúng tôi thực sự cần đảm bảo rằng sản phẩm được triển khai khá nhanh chóng. Và điều đó có nghĩa là, với tư cách là một PM, nên ít nhấn mạnh hơn vào việc đảm bảo rằng bạn đang điều chỉnh các roadmap (lộ trình) nhiều quý của mình với các nhóm đối tác, và nhấn mạnh nhiều hơn vào, "Được rồi, làm thế nào chúng ta có thể tìm ra cách nhanh nhất để đưa sản phẩm ra thị trường?" Làm thế nào chúng ta có thể tìm ra cách tạo ra một góc thử nghiệm (concept corner) trong bộ sản phẩm của chúng tôi, nơi một kỹ sư hoặc một PM có một ý tưởng, và đến cuối tuần, chúng tôi có thể đưa nó đến tay người dùng? Tôi nghĩ rằng các PM làm tốt nhất trên các sản phẩm thuần AI là những người có thể tìm ra, "Làm thế nào tôi có thể rút ngắn thời gian từ khi có ý tưởng đến khi sản phẩm thực sự đến tay người dùng?" và giúp xác định đâu là các tác vụ (task) quan trọng nhất cần hoạt động ngay lập tức (out of the box) cho sản phẩm của tôi. Vì vậy, điều tôi yêu thích về điều này là điều bạn đang nói chính là mọi người chưa nắm bắt được tốc độ cần di chuyển nhanh đến mức nào và bao nhiêu phần công việc bây giờ chỉ là giúp nhóm di chuyển nhanh. Điều gì giúp làm được điều đó? Bạn làm gì? Nhóm PM của bạn làm gì để giúp họ di chuyển nhanh đến vậy, ngoài việc có quyền truy cập vào các mô hình tiên tiến nhất?

Chiến lược triển khai sản phẩm nhanh chóng

Tôi nghĩ điều đầu tiên là đặt ra các mục tiêu rõ ràng, bởi vì các mô hình ngôn ngữ lớn (LLM) quá tổng quát đến mức nó thực sự tạo ra nhiều sự mơ hồ về việc chúng ta đang xây dựng cho ai, chúng ta đang cố gắng giải quyết vấn đề gì, các trường hợp sử dụng (use case) hàng đầu là gì. Và vì vậy, tôi nghĩ một PM giỏi có thể nói, "Được rồi, người dùng chính của chúng tôi là các developer chuyên nghiệp. Vấn đề chính mà chúng tôi muốn giải quyết cho tính năng này có lẽ là có quá nhiều prompt (câu lệnh/lời nhắc) yêu cầu quyền và người dùng đang cảm thấy mệt mỏi. Và trường hợp sử dụng là chúng tôi muốn các developer chuyên nghiệp tại các doanh nghiệp lớn có thể an toàn đạt đến không prompt yêu cầu quyền." Và điều đó thực sự đặt ra một mục tiêu khá rõ ràng, bởi vì nó loại bỏ nhiều phương pháp tiềm năng để giảm prompt yêu cầu quyền để mọi người có thể hoàn thành nhiều việc hơn chỉ với một prompt.

Và sau đó, tôi nghĩ điều thứ hai rất quan trọng là tìm ra một quy trình lặp lại được (repeatable process) để triển khai các tính năng này. Vì vậy, đối với Claude Code, điều chúng tôi làm là chúng tôi thực sự triển khai hầu hết các tính năng của mình dưới dạng phiên bản xem trước nghiên cứu (research preview). Chúng tôi gắn nhãn rõ ràng cho điều này khi chúng tôi triển khai một cái gì đó để người dùng biết rằng đây là một sản phẩm ban đầu. Đây chỉ là một ý tưởng. Đây chỉ là một cái gì đó mà chúng tôi đang cố gắng thu thập phản hồi và lặp lại, và rằng điều này có thể không được hỗ trợ vĩnh viễn. Và điều này giúp giảm cam kết của chúng tôi khi triển khai một thứ gì đó. Chúng tôi chỉ có thể đưa ra một cái gì đó trong một hoặc hai tuần.

Và sau đó, điều thứ ba mà một PM nên làm là giúp tạo ra khung sườn (framework) cho nhóm để họ biết khi nào nên thu hút các đối tác liên chức năng (cross-functional partners) và kỳ vọng của những đối tác liên chức năng đó là gì. Ví dụ, chúng tôi có một quy trình thực sự chặt chẽ giữa kỹ thuật, tiếp thị và tài liệu (docs). Vì vậy, khi các kỹ sư có một tính năng mà họ cảm thấy đã sẵn sàng và chúng tôi đã thử nghiệm nội bộ (dogfooded internally), họ sẽ đăng nó vào phòng ra mắt liên tục (evergreen launch room) của chúng tôi. Và sau đó Sarah, người đứng đầu bộ phận tài liệu của chúng tôi, và Alex, người đứng đầu PMM (Quản lý Tiếp thị Sản phẩm), cùng Tar và Lydia từ DevRel (Quan hệ Developer), chỉ cần tham gia và có thể hoàn thành thông báo tiếp thị vào ngay ngày hôm sau. Và vì chúng tôi có quy trình chặt chẽ này, nó giúp giảm ma sát/khó khăn (friction) cho bất kỳ kỹ sư nào khi triển khai một thứ gì đó, và PM là vai trò nên thiết lập điều này.

`PRD` và sự đồng bộ trong nhóm

>> PRD (Tài liệu Yêu cầu Sản phẩm) phù hợp với điều này như thế nào? Thực tế là bạn đã nói rằng mục tiêu là một phần thực sự quan trọng, giống như việc được căn chỉnh về cách định nghĩa thành công? Sản phẩm này dành cho ai? Không dành cho ai? Bạn có viết PRD không? Hay nó chỉ là một vài gạch đầu dòng? Điều đó đã phát triển như thế nào trong thế giới PM AI?

>> Vậy thì, có hai điều chúng tôi làm. Một là, chúng tôi có các metric (chỉ số) rất nghiêm ngặt, và chúng tôi thực hiện các báo cáo metric (metric readouts) với toàn bộ nhóm mỗi tuần. Mục tiêu của việc này là để đảm bảo rằng mọi người đều hiểu sâu sắc tất cả các khía cạnh của hoạt động kinh doanh của chúng tôi: các mục tiêu chính của chúng tôi là gì, xu hướng của chúng ra sao và điều gì thúc đẩy chúng. Điều thứ hai chúng tôi làm là chúng tôi có danh sách các nguyên tắc nhóm. Và điều này bao gồm người dùng chính của chúng tôi là ai, và tại sao họ là người dùng chính của chúng tôi. Và lý do chúng tôi diễn giải tất cả những điều này là để mọi người trong nhóm đều cảm thấy họ hiểu cách hoạt động kinh doanh của chúng tôi. Họ hiểu điều gì quan trọng đối với chúng tôi và những gì chúng tôi sẵn sàng đánh đổi. Và điều đó cho phép mọi người tự mình đưa ra quyết định mà không cảm thấy bị PM hoặc bất kỳ stakeholder (bên liên quan) nào khác chặn lại.

Sự cần thiết của `PM` trong kỷ nguyên `AI`

>> Tôi thích cách mà phần lớn điều này giống như, "Được rồi, chúng ta vẫn cần PM trong tương lai." Có rất nhiều cuộc nói chuyện kiểu như, "Tại sao chúng ta cần PM? Chúng ta chỉ cần triển khai và xây dựng. Chúng ta cần kỹ sư."

>> Ồ, chúng tôi thực sự có viết PRD đôi khi. Vì vậy, tôi nghĩ đối với các tính năng đặc biệt mơ hồ, việc viết ra một tài liệu một trang (one-pager) về các mục tiêu là gì, các trường hợp sử dụng thú vị (delightful use case) là gì, các chế độ lỗi (failure mode) hiện tại cần khắc phục là gì thực sự hữu ích. Và đôi khi có một số dự án, đặc biệt là những dự án yêu cầu hạ tầng (infrastructure) nặng nề mà mất nhiều tháng. Và đối với những tình huống đó, chúng tôi vẫn viết PRD.

Mô hình `Mythos` và tốc độ phát triển của Anthropic

>> Tôi muốn đi sâu hơn một chút vào việc làm thế nào bạn có thể di chuyển nhanh đến vậy. Tôi chưa từng thấy tốc độ nào như cách mọi người ở Anthropic đang triển khai sản phẩm. Ai đó đã tạo một lịch trình ra mắt sản phẩm của Anthropic, và theo đúng nghĩa đen, mỗi ngày đều có một tính năng hoặc sản phẩm lớn được ra mắt. Vì vậy, một câu hỏi mọi người đặt ra trực tuyến là, "Các bạn vừa ra mắt — không phải ra mắt, mà đã xây dựng mô hình Mythos đáng kinh ngạc này vẫn đang trong giai đoạn preview (xem trước) vì nó quá mạnh mẽ. Mọi người hơi e ngại về những gì nó có thể làm." Các bạn đã sử dụng mô hình này chưa? Đây có phải là một phần lý do giúp các bạn có thể di chuyển nhanh đến vậy không?

>> Chúng tôi đã di chuyển khá nhanh trong vài quý qua. Vì vậy, tôi nghĩ nó không hoàn toàn là nhờ Mythos. Mythos là một mô hình cực kỳ mạnh mẽ. Nhưng chúng tôi có sử dụng các mô hình nội bộ, và tôi nghĩ điều này đã tăng tốc độ triển khai của chúng tôi một chút, nhưng tôi không nghĩ nó giải thích phần lớn sự gia tăng.

Quy trình và Quyền tự chủ của Đội ngũ

Tôi nghĩ phần lớn là về quy trình và kỳ vọng đặt ra cho đội ngũ. Chúng tôi có rất ít quy trình. Chúng tôi muốn loại bỏ mọi rào cản đối với việc triển khai sản phẩm. Chúng tôi muốn đảm bảo mọi thành viên trong đội ngũ đều cảm thấy được trao quyền để biến ý tưởng của mình thành sản phẩm thực tế trong chưa đầy một tuần, đôi khi chỉ trong một ngày.

Tuyệt vời. Thật là một lợi thế khi vừa có mô hình tốt nhất, vừa đang xây dựng sản phẩm. Thật tuyệt vời.

Chúng tôi rất may mắn khi có thể làm việc với các Frontier models.

Ôi trời ơi, thật là một lợi thế tuyệt vời. Chỉ cần xây dựng một thứ, sau đó sử dụng nó và tăng tốc nhanh hơn. Thật thú vị.

Sự cố rò rỉ mã nguồn Claude Code

Có một vài điều bên lề khác mà tôi muốn hỏi trong cuộc trò chuyện này. Có rất nhiều điều đang xảy ra với Anthropic và tôi rất tò mò muốn biết suy nghĩ của bạn. Một là, khoảng một tuần trước, toàn bộ mã nguồn của Claude Code đã bị rò rỉ. Ai đó đã đưa nó ra ngoài. Tôi nghĩ đó là một sai lầm mà ai đó đã mắc phải. Bạn có bình luận gì về việc đó không, như chuyện gì đã xảy ra? Điều gì đã sai? Mọi người nên biết gì?

Ngay lập tức khi phát hiện, chúng tôi đã điều tra. Chúng tôi nhận ra đây là hậu quả của lỗi con người. Có một người đang làm việc với Claude để viết một PR (Pull Request). Đây chỉ là một bản cập nhật về cách chúng tôi phát hành các gói phần mềm và nó thực sự đã trải qua hai lớp xem xét của con người. Vì vậy, đây là kết quả của lỗi con người và chúng tôi đã tăng cường các quy trình của mình để đảm bảo điều đó không xảy ra trong tương lai.

Người này vẫn còn ở Anthropic chứ? Họ đang làm đúng chứ?

Vâng, đúng vậy. Đó là một lỗi quy trình và điều quan trọng nhất là học hỏi từ nó và bổ sung thêm các biện pháp bảo vệ để điều đó không xảy ra lần nữa. Và đó là những gì chúng tôi đang tập trung, hầu hết các biện pháp đó đã được triển khai.

Claude và Thay đổi chính sách đăng ký Open Claude

Được rồi. Một câu hỏi khác tôi có là về Open Claude. Gần đây có động thái ngăn người dùng sử dụng gói đăng ký Claude với các phiên bản Open Claude của họ. Mọi người đã thực sự khó chịu và bối rối không hiểu tại sao điều này lại xảy ra. Cảm giác như có sự tổn hại đến cộng đồng mã nguồn mở. Mọi người cần hiểu điều gì về quyết định này?

Chúng tôi đã nhận thấy nhu cầu rất lớn đối với Claude và đã làm việc rất chăm chỉ để vừa mở rộng cơ sở hạ tầng của mình, vừa làm cho harness của chúng tôi hiệu quả hơn về token để bạn có thể sử dụng nhiều hơn. Nó không được thiết kế cho các sản phẩm bên thứ ba có các mô hình sử dụng khác với các sản phẩm của bên thứ nhất của chúng tôi. Chúng tôi đã dành nhiều thời gian để tìm ra quá trình chuyển đổi liền mạch nhất mà chúng tôi có thể cung cấp. Và tôi rất vui khi có thể thông báo rằng mọi người đều nhận được một số tín dụng cùng với gói đăng ký của họ. Nhưng vâng, chúng tôi đã phải đưa ra quyết định khó khăn là cần ưu tiên các sản phẩm của bên thứ nhất và API của chúng tôi. Và đây là một quyết định phát sinh từ đó.

Vâng, đối với tôi điều này rất hợp lý. Các bạn đang trợ cấp việc sử dụng này với mức khoảng 200 đô la một tháng, và nó gần như là sử dụng không giới hạn. Tôi nghĩ mọi người không hiểu rằng các doanh nghiệp đang cố gắng kiếm tiền. Chúng tôi đang cố gắng có lợi nhuận ở đây. Chúng tôi không thể cứ cho không tài nguyên tính toán khi nó đang có nhu cầu cao như vậy. Nên tôi hiểu.

Cấu trúc đội ngũ PM tại Anthropic

Trở lại với đội ngũ quản lý sản phẩm (PM), đội ngũ PM tại Anthropic trông như thế nào? Có bao nhiêu PM? Họ được tổ chức ra sao?

Vâng, chúng tôi có một vài đội PM. Tôi nghĩ hiện tại chúng tôi có khoảng 30 hoặc 40 PM. Chúng tôi có đội PM nghiên cứu do Diane dẫn dắt, đội này chịu trách nhiệm thu thập tất cả phản hồi từ khách hàng về các mô hình của chúng tôi, sau đó chuyển cho đội nghiên cứu tốt nhất để họ hành động, và họ cũng quản lý quá trình ra mắt mô hình. Có đội nền tảng nhà phát triển Claude duy trì các API mà Claude Code được xây dựng trên đó, và họ cũng phát hành những thứ như Managed Agents – một cách để bạn xây dựng tác nhân AI của mình và chúng tôi có thể lưu trữ chúng thay mặt bạn. Và sau đó có Claude Code làm việc trên cả Claude Code và các sản phẩm cốt lõi Co-work. Có đội doanh nghiệp (Enterprise) giúp Claude Code và Co-work dễ dàng được các khách hàng doanh nghiệp của chúng tôi áp dụng hơn. Và điều này bao gồm mọi thứ từ kiểm soát chi phí, RBAC (Role-Based Access Control), kiểm soát bảo mật và đảm bảo các doanh nghiệp này cảm thấy rất tự tin và thoải mái khi sử dụng công cụ của chúng tôi. Và sau đó chúng tôi cũng có đội phát triển (growth team) chịu trách nhiệm phát triển trên toàn bộ bộ sản phẩm của chúng tôi. Vì vậy, chúng tôi làm việc rất chặt chẽ với họ về sự phát triển của Claude Code và Co-work, và tôi biết họ cũng làm việc với các đội khác của chúng tôi về sự phát triển của CDP (Claude Developer Platform), tức là sự phát triển của những người sử dụng API của Claude.

Nói về sự phát triển, Amole vừa tham gia podcast. Anh ấy có một cái nhìn sâu sắc rất thú vị mà hầu hết mọi người chưa chia sẻ. Luôn có cảm giác rằng chúng ta cần ít PM hơn trong tương lai. Tại sao chúng ta cần PM? Kỹ sư có thể tự triển khai. Quan điểm của anh ấy là vì kỹ sư di chuyển quá nhanh, PM và nhà thiết kế bị ép. Có ít thời gian hơn để nắm bắt mọi thứ đang diễn ra. Mỗi ngày có một tính năng được triển khai. Vì vậy, quan điểm của anh ấy là cần nhiều PM hơn vì rất khó để theo kịp. Quan điểm của bạn là gì? Bạn có nghĩ rằng sẽ có sự gia tăng trong việc tuyển dụng PM không? Bạn nghĩ điều gì đang diễn ra với nghề PM về lâu dài?

Sự hòa nhập vai trò của PM và Kỹ sư

Tôi nghĩ tất cả các vai trò đang hòa nhập vào nhau. PM đang làm một số công việc kỹ thuật, kỹ sư đang làm công việc PM, nhà thiết kế đang làm PM và cả triển khai mã nguồn. Bạn có thể thuê thêm nhiều kỹ sư có gu sản phẩm tốt hoặc bạn có thể giữ nguyên số lượng kỹ sư và thuê thêm nhiều PM để giúp định hướng công việc của họ. Trong đội ngũ của chúng tôi, chúng tôi khá tập trung vào việc thuê các kỹ sư có gu sản phẩm tốt. Bằng cách này, chúng tôi có thể giảm chi phí bổ sung cho việc triển khai bất kỳ sản phẩm nào. Có nhiều kỹ sư trong đội ngũ của chúng tôi hoàn toàn có khả năng thực hiện từ đầu đến cuối từ việc tiếp nhận phản hồi người dùng trên Twitter cho đến khi triển khai một sản phẩm vào cuối tuần mà gần như không cần sự tham gia của quản lý sản phẩm. Và tôi nghĩ đây thực sự là cách hiệu quả nhất để triển khai một thứ gì đó. Vì vậy, tôi nghĩ kỹ sư và PM đang có sự trùng lặp, và bạn sẽ nhận được nhiều lợi ích từ việc có nhiều người giỏi ở một trong hai vai trò. Tôi nghĩ gu sản phẩm vẫn là một kỹ năng rất hiếm có, và chúng tôi sẽ tuyển dụng bất kỳ ai mà chúng tôi cảm thấy đã thể hiện rõ ràng kỹ năng này.

Và nền tảng của bạn là kỹ thuật phải không?

Vâng, tôi là một kỹ sư trong nhiều năm. Sau đó tôi làm VC (quỹ đầu tư mạo hiểm) một thời gian rất ngắn trước khi gia nhập Anthropic. Và thực ra, hầu hết các PM trong đội ngũ của chúng tôi đều đã từng là kỹ sư hoặc đã triển khai mã nguồn tại Claude Code. Và đó là một trong những điều tôi nghĩ giúp xây dựng lòng tin với đội ngũ và cũng giúp chúng tôi di chuyển nhanh hơn rất nhiều. Và thực ra, các nhà thiết kế của chúng tôi cũng từng là kỹ sư front-end trước đây.

Chà, vì đó là câu hỏi lớn. Chắc chắn có sự hòa nhập đang diễn ra, các biểu đồ Venn đang kết hợp. Tôi nghĩ câu hỏi lớn đối với nhiều người là nếu bạn đến từ kỹ thuật, sản phẩm hay thiết kế, kỹ năng cốt lõi nào trong số đó sẽ có giá trị nhất? Tôi có thể thấy ở Anthropic và trên Claude Code, kỹ thuật rất có giá trị. Tôi tò mò liệu ở các công ty khác, nếu bạn có nền tảng thiết kế, việc trở thành một PM có giá trị hơn hay chỉ là một PMP.

Giá trị của Gu sản phẩm và Nền tảng Kỹ thuật

Tôi vẫn nghĩ điều quan trọng nhất là gu sản phẩm. Khi mã nguồn trở nên rẻ hơn rất nhiều để viết, điều trở nên có giá trị hơn là quyết định nên viết gì. Trải nghiệm người dùng (UX) nào phù hợp cho tính năng này? Cách nào thú vị nhất để người dùng có thể trải nghiệm nó? Chúng tôi nhận được hàng chục nghìn GitHub issues yêu cầu mọi thứ trên đời, và cần rất nhiều sự cẩn trọng và gu thẩm mỹ để tìm ra cái nào đáng để xây dựng và cách xây dựng đúng đắn. Tôi nghĩ bộ kỹ năng đó có thể đến từ bất kỳ nền tảng nào, nhưng đó là điều quan trọng nhất. Tôi nghĩ lý do tại sao nền tảng kỹ thuật đặc biệt hữu ích, ít nhất là trong vài tháng tới, là nếu bạn có nền tảng kỹ thuật, bạn sẽ có cảm nhận tốt hơn về mức độ khó của một thứ. Và điều đó thường là một yếu tố trong việc bạn chọn xây dựng cái gì. Chẳng hạn, nếu một thứ rất dễ xây dựng, thì có lẽ thay vì tranh luận, bạn chỉ cần dành một giờ để làm nó. Nhưng nếu một thứ khó xây dựng và bạn biết điều đó ngay từ đầu, bạn sẽ biết rằng điều này sẽ tốn nhiều chi phí hơn cho đội ngũ của chúng tôi để triển khai. Vì vậy, nó giúp ích một chút với việc ưu tiên.

Bạn nói "trong vài tháng tới"; có phải vì các mô hình có thể sẽ trở nên rất tốt trong vài tháng tới? Bạn có thể không cần biết nhiều điều đó nữa.

Tôi nghĩ các bộ kỹ năng được đánh giá cao thay đổi khá thường xuyên, và vì vậy rất khó để dự đoán xa hơn vài tháng. Vì vậy, đây ít hơn là một bình luận về sự thay đổi mà tôi nghĩ sẽ xảy ra, và nhiều hơn là một bình luận rằng tôi nghĩ những thay đổi lớn sẽ xảy ra.

Vậy bạn không nói rằng đó là khi Mythos ra mắt và sẽ thay đổi mọi thứ, và chúng ta không cần biết bất cứ điều gì về kỹ thuật?

Không, tôi chỉ nói rằng cứ vài tháng dường như lại có một sự gia tăng lớn trong khả năng lập trình, điều này sau đó thay đổi những vai trò khác có giá trị. Tôi nghĩ điều quan trọng nhất là có được tư duy nguyên tắc đầu tiên này, nơi bạn có thể tìm ra cách cảnh quan công nghệ đang thay đổi, đội ngũ thực sự cần gì từ bạn, và nhảy vào để khắc phục lỗ hổng đó. Bởi vì tôi nghĩ công việc đang trở nên vô định hình hơn, có nghĩa là một PM giỏi có thể hiểu tất cả các khoảng trống là gì, để tìm ra những cái nào có ưu tiên cao nhất, và sau đó chỉ cần tìm ra, "Được rồi, làm thế nào để tôi học bộ kỹ năng đó hoặc bộ kỹ năng tôi có thể áp dụng cho thử thách này là gì?" Vì vậy, tôi nghĩ môi trường hiện tại coi trọng những người có khả năng đảm nhiệm nhiều vai trò, có khả năng chuyển đổi vai trò, và có cái tôi thấp về công việc họ làm để giúp đội ngũ di chuyển nhanh hơn.

Giá trị của Trí tuệ con người trong kỷ nguyên AI

Tôi thích câu trả lời này. Có một câu hỏi tôi đã hỏi những người ở vị trí của bạn, những người đang ở tiên phong của những gì trí tuệ nhân tạo (AI) có khả năng làm và xây dựng bằng các công cụ mới nhất, đó là: "Bộ não con người sẽ tiếp tục hữu ích và cần thiết trong bao lâu cho đến khi chúng ta đạt đến siêu trí tuệ?" Điều tôi đang nghe ở đây về cơ bản là chọn những việc cần làm, biết thị trường đang đi về đâu, và tìm ra điều gì cần ưu tiên. Và sau đó là biết liệu thứ bạn đã xây dựng có tốt và đúng đắn hay không, và đưa nó ra thị trường ở một phiên bản ban đầu ít nhất. Điều đó có đúng không? Còn điều gì khác mà bộ não con người sẽ tiếp tục hữu ích trong ít nhất vài tháng tới không?

Tôi nghĩ con người vẫn cung cấp một mức độ nhận thức chung mà các mô hình không có. Và có hàng nghìn yếu tố chuyển động trong bất kỳ lần ra mắt sản phẩm nào. Một số rất nhỏ, nhưng luôn có rất nhiều điều có thể đi sai. Tôi nghĩ mô hình không phải lúc nào cũng hiểu rõ tất cả các bên liên quan là ai, họ liên hệ với nhau như thế nào, sở thích của họ là gì, đâu là các kênh phù hợp để giao tiếp với họ nhằm giữ họ tham gia. Tôi nghĩ rất nhiều kiến thức nhận thức chung mang tính ngầm, như loại EQ (Chỉ số cảm xúc), vẫn rất có giá trị. Tất nhiên, chúng tôi muốn các mô hình trở nên tốt hơn ở điều này và tôi nghĩ chúng sẽ như vậy, nhưng hiện tại tôi nghĩ vẫn còn những khoảng trống.

Đối phó với sự thay đổi không ngừng

Với tư cách là một con người, bạn đối phó thế nào khi trải qua quá nhiều thay đổi không ngừng, giống như đang ở trong tâm bão vậy? Có lẽ ở đó yên bình, nhưng làm thế nào để bạn nắm bắt được mọi thứ đang diễn ra? Làm thế nào để bạn giữ được sự tỉnh táo qua tất cả sự điên rồ mà chúng ta đang trải qua?

Tôi nghĩ đội ngũ của chúng tôi toàn những người chấp nhận thử thách. Vì vậy, chúng tôi cố gắng đối mặt với mọi thử thách bằng nụ cười vì luôn có rất nhiều điều đang xảy ra.

Năng lực cốt lõi: Bình tĩnh và Lạc quan

Luôn có rất nhiều rủi ro và tình huống khó khăn, bạn biết đấy, nếu bạn quá căng thẳng về bất cứ điều gì, bạn sẽ kiệt sức. Vì vậy, chúng tôi thực sự tìm kiếm những người có thể nhìn nhận một thử thách và nói rằng, "Điều này sẽ khó khăn, nhưng tôi rất hào hứng để giải quyết nó. Tôi sẽ cố gắng hết sức có thể, và tôi biết mình sẽ không hoàn hảo, nhưng tôi sẽ có thể ngủ ngon vào ban đêm khi biết rằng mình đã làm hết sức." Đó là một câu trả lời thú vị cho câu hỏi về những kỹ năng nào sẽ quan trọng trong tương lai, bởi vì—tôi quên ai đã nói điều này, có lẽ là Ben Mann—rằng đây là thời điểm bình thường nhất mà thế giới từng có.

Vâng, mọi thứ chắc chắn sẽ khó khăn hơn. Ví dụ, tôi cảm thấy có nhiều tuần mà có thể tối Chủ Nhật có một vấn đề P0 (ưu tiên cao nhất), rồi đến sáng Thứ Hai lại có một P0, và đến chiều Thứ Hai lại có một P0000 (ưu tiên cực kỳ cao), và bạn sẽ nghĩ, "Wow, không thể tin được là mình đã lo lắng về P0 đó từ Chủ Nhật." Nhưng tôi nghĩ bạn chỉ cần thừa nhận rằng bạn chỉ có thể làm được chừng đó, rằng bạn cần ngủ đủ giấc để có thể đưa ra những quyết định tốt vào ngày hôm sau và chỉ cần ưu tiên một cách triệt để nơi bạn dành thời gian của mình. Điều gì là quan trọng nhất để làm đúng? Và hãy chấp nhận bỏ qua một số thứ. Ví dụ, có những sản phẩm chúng tôi đã phát hành mà không được hoàn thiện như tôi mong muốn. Nhưng, mục tiêu hàng đầu của chúng tôi là giúp trao quyền cho các developer chuyên nghiệp. Và nếu một sản phẩm không thành công, miễn là nó không chặn trường hợp sử dụng cốt lõi, thì không sao cả, bởi vì chúng tôi sẽ lắng nghe phản hồi và sẽ khắc phục trong bản phát hành tiếp theo. Việc ra mắt một tính năng có lỗi là điều từng khiến tôi mất ngủ. Nhưng đó là điều mà giờ đây tôi có thể chấp nhận, biết rằng, "Được thôi, chúng ta sẽ nhận được phản hồi nhanh chóng và chúng ta sẽ khắc phục nó trong bản phát hành tiếp theo."

Điều tôi đang hình dung là có một ảnh GIF—tôi nghĩ có lẽ là từ phim Cướp biển vùng Caribbean—trong đó có một người đàn ông đi xuống cầu thang trên một con tàu và toàn bộ con tàu đang bị phá hủy xung quanh anh ta, nhưng anh ta vẫn rất bình tĩnh, chỉ đi dạo xuống cầu thang trong khi mọi thứ đang sụp đổ. Và điều đó thú vị bởi vì tất cả những người tôi từng gặp ở Anthropic đều rất bình tĩnh và rất lạc quan.

Vâng, tôi nghĩ đó là một cái nhìn sâu sắc thực sự thú vị—đó là việc có sự điềm tĩnh và lạc quan này thay vì chỉ nói, "Ôi trời ơi, mọi thứ thật điên rồ và đang loạn hết lên." Vâng, tôi nghĩ nếu bạn không có điều đó, bạn sẽ khá kiệt sức. Tôi nghĩ chúng tôi cũng có xu hướng tuyển dụng những người đã ở trong ngành một thời gian và đã trải qua nhiều thăng trầm, và có cảm nhận tốt về những gì mang lại năng lượng cho họ và cách duy trì năng lượng theo thời gian, và tôi nghĩ điều đó đã giúp ích cho chúng tôi rất nhiều.

Đánh đổi về tính nhất quán sản phẩm và trải nghiệm người dùng

Thật thú vị. Một điều mà tôi muốn hỏi là: đang có sự mờ nhạt ranh giới giữa các vai trò. Kỹ sư đang trở thành quản lý sản phẩm (PM), mọi người đang hòa nhập. Chúng ta mất gì trong thế giới đó? Chúng ta có mất thang đo sự nghiệp (career ladder) và lộ trình sự nghiệp rõ ràng không? Chúng ta có mất tính nhất quán trong thiết kế, chất lượng mã (code quality) không? Chắc chắn có một số mặt trái. Bạn thấy những điều gì chúng ta đang hy sinh vì lợi ích lớn hơn?

Chúng tôi đang hy sinh tính nhất quán của sản phẩm. Trong lịch sử, khi việc viết mã (code) tốn kém, bạn sẽ cẩn thận lập kế hoạch mọi thứ trong bộ sản phẩm (product suite) của mình: cách mỗi sản phẩm liên quan đến nhau, trường hợp sử dụng của từng sản phẩm, cách chúng tích hợp. Và bạn gần như sẽ có một sản phẩm cho mỗi trường hợp sử dụng. Còn bây giờ, với trí tuệ nhân tạo (AI) phát triển rất nhanh và với rất nhiều ý tưởng cần thử nghiệm, đôi khi chúng tôi có các tính năng chồng chéo lẫn nhau. Phần lớn thời gian là vì có hai kiểu dáng thiết bị (form factors) mà chúng tôi yêu thích nội bộ, và chúng tôi muốn khán giả bên ngoài cho chúng tôi biết cái nào tốt hơn. Tuy nhiên, điều đó có nghĩa là đối với một người dùng mới, họ có thể không biết, "Được rồi, đâu là con đường tốt nhất để hoàn thành X?" Chúng tôi cần cung cấp thêm thông tin giáo dục để giúp mọi người hiểu các tính năng cốt lõi là gì và các phương pháp hay nhất để sử dụng chúng.

Tôi nghĩ đây là cái giá của việc ra mắt nhiều tính năng. Tôi nghĩ người dùng cũng cảm thấy khó theo kịp những thông tin mới nhất. Thông thường, trong vai trò quản lý sản phẩm truyền thống, bạn sẽ phát hành một tính năng mỗi tháng hoặc mỗi quý. Vì vậy, rất dễ dàng để một người dùng hiểu, "Được rồi, tôi chỉ cần kiểm tra cái này mỗi tháng một lần và tôi sẽ học được một số điều mới, và nếu tôi bỏ qua nó trong sáu tháng thì cũng không sao. Tôi không cảm thấy mình đang bỏ lỡ điều gì." Tôi nghĩ với những công cụ tác nhân (agentic tools) này – không chỉ Code và Co-work, mà trên toàn bộ hệ sinh thái – mọi người cảm thấy cần phải kiểm tra Twitter mỗi ngày để xem điều mới nhất tuyệt đối là gì. Và tôi nghĩ chúng ta có thể làm nhiều hơn để giúp mọi người cảm thấy ít bị cuốn vào cái vòng quay ngày càng nhanh này, và rằng họ cảm thấy – tôi muốn mọi người cảm thấy rằng họ có thể chỉ cần mở các công cụ này. Các công cụ sẽ giáo dục họ, hoặc dạy họ những gì họ muốn biết, và họ có thể cảm thấy được tham gia nhiều hơn.

Vâng, tôi thấy bạn đã ra mắt một tính năng thực sự thú vị gần đây. Tôi nghĩ đó là /powerup, nơi nó hướng dẫn bạn tất cả các cách hay ho và về cơ bản là tất cả các phương pháp hay nhất để sử dụng Claude Code. Có phải điều đó cũng nằm trong những định hướng này không?

Vâng, chính xác. Trong quá khứ, chúng tôi thực sự không muốn làm một thứ gì đó như PowerUp vì chúng tôi cảm thấy sản phẩm nên đủ trực quan để bạn không cần phải trải qua bất kỳ hướng dẫn nào. Và theo thời gian, chúng tôi nhận ra rằng có quá nhiều tính năng và có quá nhiều nhu cầu về một trải nghiệm giới thiệu tích hợp (built-in onboarding experience) nên chúng tôi đã hơi đi chệch khỏi nguyên tắc ban đầu là không có quy trình giới thiệu (onboarding flow) và đã thêm tính năng này vì có quá nhiều người dùng muốn biết, "Có 100 tính năng. Đâu là 10 tính năng tôi nhất định phải sử dụng?" Và vì vậy chúng tôi đã cùng nhau xây dựng nó.

Công thức thành công của Anthropic: Sứ mệnh và Sự tập trung

Vậy, Anthropic đã thực sự thành công với các doanh nghiệp lớn B2B (B2B enterprises), nơi mà theo truyền thống bạn không ra mắt quá nhiều thứ; bạn chỉ có thể có một bản phát hành hàng quý (quarterly release) mà thôi, và điều đó hoàn toàn ngược lại với "mỗi ngày chúng ta có một cái gì đó mới." Vì vậy, có lẽ theo hướng đó, hành trình mà Anthropic đã đi thật phi thường. Anthropic đã bị tụt hậu rất xa khi mới bắt đầu. Nó được chia sẻ như một trong những công ty ít được tài trợ nhất. Không có phân phối (distribution). Không phải là người đầu tiên ra mắt. OpenAI đã đi trước rất xa. Mọi người đều nghĩ, "Không đời nào Anthropic có bất kỳ cơ hội nào để cạnh tranh đáng kể về lâu dài." Bây giờ thì nó đang làm rất tốt, đánh bại các công ty và đội ngũ lớn nhất với sự phát triển đáng kinh ngạc – như đạt 11 tỷ đô la ARR (Annual Recurring Revenue) với tốc độ tăng trưởng hàng tháng. Đến khi đoạn này được phát hành, con số đó có lẽ sẽ còn cao hơn. Là người trong cuộc, đâu là những yếu tố đã giúp Anthropic thành công đến vậy và vươn lên từ phía sau để làm tốt điều này?

Hai điều quan trọng nhất là: thứ nhất, sứ mệnh thống nhất này. Khó có thể nói hết được tầm quan trọng của nó. Chúng tôi tuyển dụng những người quan tâm nhất đến việc mang AGI (Trí tuệ nhân tạo tổng quát) an toàn đến cho toàn nhân loại. Và đây thực sự là điều chúng tôi thường xuyên tham khảo trong các quyết định về việc toàn bộ sản phẩm hoặc tổ chức của chúng tôi nên tập trung vào việc phát hành cái gì. Và bởi vì chúng tôi đặt sứ mệnh này lên trên bất kỳ dòng sản phẩm (product line) riêng lẻ nào, chúng tôi có thể đưa ra các quyết định rất nhanh chóng, bao trùm toàn bộ tổ chức (org) và thực hiện chúng một cách thống nhất. Vì vậy, tôi nghĩ đây là điều mà tôi chưa từng thấy ở một công ty có quy mô như của chúng tôi.

Và vậy, để làm rõ điều đó. Về cơ bản, sứ mệnh số một là căn chỉnh an toàn (safety alignment), đảm bảo trí tuệ nhân tạo (AI) tốt cho thế giới. Và bạn đang nói rằng việc có một sứ mệnh rõ ràng như vậy sẽ giúp việc đưa ra quyết định dễ dàng hơn rất nhiều.

Nếu có hai ưu tiên cạnh tranh, chúng tôi sẽ thảo luận xem ưu tiên nào quan trọng hơn đối với sứ mệnh của Anthropic. Và điều đó giúp việc quyết định ưu tiên cái nào trong hai điều đó dễ dàng hơn rất nhiều. Sau đó, mọi người sẽ ủng hộ quyết định mà chúng tôi đưa ra. Và đôi khi điều đó có nghĩa là, "Này, chúng tôi muốn phát hành một cái gì đó trên Claude Code, nhưng điều khác quan trọng hơn." Và vì vậy chúng tôi hạ thấp ưu tiên phát hành cái này và chúng tôi chỉ đợi đến sau này. Điều thực sự thú vị về điều đó là nó giải thích, tôi nghĩ, so với một công ty khác (có lẽ là OpenAI), đã làm rất nhiều điều khác nhau. Và điều tôi đang nghe ở đây về cơ bản là, "Được thôi, chúng tôi sẽ không ra mắt mạng xã hội (social network); chúng tôi sẽ không ra mắt một nguồn cấp dữ liệu thông tin thú vị vì nó không phù hợp với sứ mệnh này." Và điều đó đã giúp Anthropic tập trung, dường như là một thành phần cốt lõi cho sự thành công.

Chà, khi tôi nghĩ về sứ mệnh, tôi nghĩ về việc đặt mục tiêu của Anthropic lên trước bất kỳ cá nhân hay bất kỳ sản phẩm riêng lẻ nào. Và vì vậy, đối với tôi, tôi nghĩ điều thứ hai mà chúng tôi rất giỏi là sự tập trung (focus). Tôi nghĩ sứ mệnh đối với tôi hơi khác một chút. Sứ mệnh có nghĩa là các đội sẵn sàng hy sinh những điều làm tổn hại đến mục tiêu và KR (Key Results) của chính họ để phục vụ mục tiêu và KR của Anthropic. Và mọi người rất vui khi thực hiện những đánh đổi (trade-off) đó. Ví dụ cực đoan là nếu Claude Code thất bại nhưng Anthropic thành công, tôi sẽ cực kỳ hạnh phúc, và toàn bộ đội ngũ rất sẵn lòng đưa ra những quyết định tuân theo chuỗi suy nghĩ đó.

Tôi không biết liệu bạn có thể nói sâu về điều này không, nhưng bạn có cảm thấy quyết định về Open Claude là một phần của điều này không, kiểu như, "Được rồi, điều này không thúc đẩy sứ mệnh của Anthropic; chúng ta cần dừng lại vì nó không hoạt động theo cách chúng ta muốn." Tôi nghĩ một trong những điều quan trọng nhất đối với Anthropic là tăng số lượng người dùng mà chúng tôi có thể tiếp cận. Một trong những cách chúng tôi có thể làm điều này là với các đăng ký Claude (Claude subscriptions) với sản phẩm bên thứ nhất (first-party products) của chúng tôi, và vì vậy chúng tôi thực sự muốn tập trung hơn (double down) vào điều đó, nhưng đôi khi điều đó lại phải đánh đổi bằng sản phẩm bên thứ ba (third-party products).

Hướng dẫn sử dụng các công cụ Claude, Desktop và Co-work

Chúng ta đã nói về Claude, Co-work, và tất cả những thứ này. Điều tôi muốn đảm bảo mọi người hiểu và tôi tò mò về cách bạn sử dụng những công cụ này. Vậy có Claude Code, có Claude Desktop, có Co-work. Cách tốt nhất để hiểu khi nào nên dùng cái nào là gì? Khi nào bạn sử dụng từng công cụ trong ba công cụ này?

Vậy, tôi thường dùng Claude Code trong terminal khi tôi chỉ thực hiện một tác vụ lập trình (coding task) một lần và muốn có tất cả các tính năng mới nhất. CLI (Giao diện dòng lệnh) là bề mặt sản phẩm (product surface) ban đầu của chúng tôi và cũng là nơi các tính năng của chúng tôi thường xuất hiện trước tiên, vì vậy nó là công cụ mạnh nhất trong tất cả các công cụ. Đó là những gì tôi thường dùng khi tôi chỉ cố gắng khởi tạo một hoặc có thể một vài tác vụ cùng một lúc. Tôi nghĩ Desktop thực sự tỏa sáng khi bạn làm việc đòi hỏi front-end (phát triển giao diện người dùng). Và một điều tôi thích làm là sử dụng tính năng xem trước (preview feature) của chúng tôi. Vì vậy, nếu tôi đang xây dựng một ứng dụng web (web app), tôi thường sẽ sử dụng Claude Code và Desktop. Tôi sẽ mở khung xem trước (preview pane) ở bên phải để tôi có thể thực sự xem ứng dụng web mà tôi đang tạo trong thời gian thực khi tôi trò chuyện với Claude. Nó cũng rất tuyệt vời cho những người muốn thứ gì đó trực quan hơn một chút. Một terminal có thể cảm thấy rất xa lạ với một người không chuyên về kỹ thuật (non-technical). Bạn nhận được một loạt các cửa sổ bật lên (popup) đáng sợ trên máy của mình và bạn không thể nhấp chuột theo cách bạn đã quen thuộc trong hầu hết các sản phẩm khác mà bạn sử dụng. Vì vậy, có rất nhiều người chỉ đơn giản là không cảm thấy thoải mái trong terminal. Và nếu bạn là người như vậy, tôi thực sự khuyên bạn nên thử Claude Code trên Desktop. Desktop cũng rất tuyệt để có được cái nhìn tổng quan (at-a-glance view) về mọi thứ đang diễn ra. Vì vậy, bạn có thể xem các phiên terminal CLI của mình trong Desktop. Bạn có thể xem các phiên Desktop khác của mình. Bạn có thể xem các phiên bạn đã khởi tạo trên web và thiết bị di động (mobile). Vì vậy, nó là một trung tâm điều khiển duy nhất (one-stop control plane) nơi bạn có thể xem tất cả các tác vụ của mình. Tôi nghĩ lợi ích của web và thiết bị di động là nó thực sự tuyệt vời để khởi tạo mọi thứ khi đang di chuyển. Vì vậy, CLI và Desktop đều yêu cầu bạn phải sử dụng máy tính xách tay cục bộ (local laptop) của mình.

Năng Suất Di Động và Tác Nhân AI

Và điều này thường mâu thuẫn bởi vì đôi khi bạn ra ngoài, bạn "chạm vào cỏ", bạn đi dạo và không mở laptop. Tôi không thể đếm hết số người tôi đã thấy cầm laptop mở, kết nối với điện thoại của họ khi đang ở bên ngoài. Điều này đơn giản có nghĩa là chúng ta đang thiếu một sản phẩm giải quyết nhu cầu đó. Với tôi, di động cho phép bạn khởi chạy những tác vụ này khi đang di chuyển để bạn không cần phải mang laptop đi khắp nơi và đảm bảo rằng laptop của bạn luôn mở dù bạn ở đâu.

Tôi rất thích điều đó. Tôi đã thấy nhiều người trên máy bay, như thể nó đã trở thành một meme. "Tôi cần hoàn thành, hãy để tác nhân này hoàn thành. Tôi không thể tắt nó. Tôi cần Wi-Fi."

Đối với Co-work, vai trò mà nó đảm nhiệm là có rất nhiều công việc mà mọi người làm mà đầu ra không phải là mã nguồn. Cho dù đó là đạt được Slack zero hay inbox zero, hay đó là tạo một bản trình bày (slide deck) cho một cuộc họp khách hàng sắp tới, hay đó là viết một tài liệu nhanh về mục tiêu của một tính năng hoặc kế hoạch ra mắt (launch plan) của một tính năng. Tất cả những tác vụ này đều tạo ra đầu ra không phải mã nguồn (non-code output), và Co-work được định vị tốt nhất cho điều đó. Vì vậy, cách tôi phân chia các sản phẩm trong tâm trí mình là nếu tôi đang xây dựng thứ gì đó có đầu ra là mã nguồn, tôi sẽ sử dụng Claude Code trên desktop hoặc Claude Code trên di động. Còn nếu đầu ra không phải là mã nguồn, tôi sẽ sử dụng Co-work cho nó.

`Co-work` trong Thực Tiễn: Sinh Ra `Slide Deck`

Mọi người đang bỏ lỡ thành công mà Co-work mang lại. Nó đang phát triển cực kỳ nhanh chóng và tôi nghĩ mọi người vẫn chưa thực sự hiểu rõ mục đích của nó. Vậy, bạn có thể cho chúng tôi một vài trường hợp sử dụng (use case) trong công việc của bạn với vai trò quản lý sản phẩm (product manager) không? Có cách nào thực sự thú vị, có thể là không ngờ tới, mà bạn đã sử dụng Co-work để tiết kiệm thời gian, hoàn thành nhiều việc hơn không?

Nếu bạn mới bắt đầu sử dụng Co-work, điều đầu tiên bạn thực sự cần làm là kết nối tất cả các nguồn dữ liệu liên quan đến vai trò của bạn, bởi vì Co-work chỉ có thể làm tốt công việc nếu nó có quyền truy cập vào tất cả ngữ cảnh cần thiết để tạo ra đầu ra phù hợp cho bạn. Đối với tôi, điều đó có nghĩa là tôi kết nối nó với Google Calendar, Slack, Gmail, Google Drive của mình để nó có thể linh hoạt tìm kiếm ngữ cảnh liên quan, đặt câu hỏi, kéo các luồng thông tin (threads). Điều này cải thiện đáng kể chất lượng kết quả. Những thứ tôi dùng nó để làm, ví dụ như tối qua tôi đang làm việc cho hội nghị Code with Claude sắp tới, và tôi sẽ có một vài bài nói chuyện ở đó. Một trong những bài nói chuyện mà chúng tôi đang chuẩn bị là về sự chuyển đổi của Claude Code từ một trợ lý sang một tác nhân (agent) hoàn chỉnh. Một trong những điều tôi muốn làm trong bài nói này là giới thiệu tất cả các sản phẩm mà chúng tôi đã phát hành (shipping) để hỗ trợ quá trình chuyển đổi này, và cũng để tìm ra những câu chuyện thành công nội bộ mà chúng tôi có thể dùng làm demo.

Vì vậy, tôi đã kết nối Google Drive, Slack. Alex, product marketer của chúng tôi, đã soạn thảo một bản nháp về những điểm mà anh ấy nghĩ chúng tôi nên đề cập. Và tôi chỉ đơn giản đưa tất cả những thứ này vào Co-work. Tôi nói cho Co-work biết câu chuyện tôi muốn kể. Và nó thực sự đã làm việc trong một giờ. Nó đã duyệt qua Twitter để xem chúng tôi đã ra mắt (launched) những gì. Nó xem xét phòng ra mắt thường xanh (evergreen launch room) của chúng tôi. Nó xem trong kênh Claude Code thông báo (announce channel), nơi nhóm của chúng tôi đăng các demo về cách họ nhận được nhiều giá trị nhất từ Claude Code. Và nó tổng hợp tất cả những điều này thành một bản trình bày 20 trang mà tôi nhận được sáng nay. Tôi đã đọc qua nó và nó khá tốt. Có một vài chỉnh sửa, nên tôi đã phải đưa ra một vòng phản hồi. Tôi thích slide của mình có ít từ nhất có thể và nó hơi quá nhiều chữ, nhưng bạn biết đấy, nó nhanh hơn rất nhiều so với những gì tôi có thể tự làm. Và bởi vì Co-work có quyền truy cập vào toàn bộ hệ thống thiết kế (design system) của chúng tôi, nó thực sự trông giống như một nhà thiết kế của Anthropic đã tạo ra nó. Khi bạn nhìn thấy nó, bạn sẽ nghĩ, "Ồ, cái này được trau chuốt một cách đáng kinh ngạc." Vì vậy, đây là những loại công việc nhanh hơn rất nhiều. Ví dụ, việc tạo bản trình bày này sẽ mất hàng giờ của tôi, nhưng thay vào đó, nó tạo ra một bản nháp khá tốt để tôi có thể tập trung vào việc đảm bảo các demo thật tuyệt vời mà chúng tôi đưa vào đó.

Điều này nghe có vẻ như một giấc mơ thành hiện thực đối với các quản lý sản phẩm (PM) vì việc tạo ra các bản trình bày (deck) thật phiền phức.

Nó quá chậm.

Tôi yêu thích việc mọi người sẽ thấy bản trình bày này bất cứ khi nào bạn trình bày nó. Nó sẽ được công bố rộng rãi, rõ ràng là nó không phải là phiên bản hoàn chỉnh ngay từ đầu (one-shot version), nhưng bạn đã lặp đi lặp lại nó. Để giúp mọi người tự mình thử điều này. Vậy bước một là kết nối những gì bạn đã nói? Slack. Bạn còn đề xuất họ kết nối những gì nữa?

Slack, Google Calendar, Gmail, Google Drive. Bạn nên kết nối các công cụ giao tiếp (communication tool) của mình và nơi bạn lưu trữ dữ liệu nguồn (source of truth data) về những gì nhóm của bạn quan tâm, những gì bạn quan tâm và những gì bạn đang làm.

Tạo `Slide Deck` Bằng `Prompt`

Được rồi. Và sau đó câu lệnh/lời nhắc (prompt) bạn đã nhập để tạo bản trình bày này là gì?

Vì vậy, tôi chỉ viết: "Hãy tạo cho tôi một bản trình bày (slide deck) cho hội nghị Code with Claude. Đây là những gì PMM của chúng tôi gợi ý nó nên bao gồm. Đây là bản nháp hiện tại tôi đã làm nhưng tôi không thích. Đây là một bản tôi đã làm thủ công nhưng tôi cũng không thích, nhưng tôi đã liên kết nó. Bạn có thể bắt đầu bằng cách tạo một dàn ý đề xuất (proposed outline) với các chi tiết không? Ngoài ra, hãy đảm bảo nó không trùng lặp quá nhiều với một bài phát biểu chính (keynote talk), điều này quan trọng hơn." Và sau đó Claude đã đọc một loạt các liên kết (link) tôi gửi cho nó và tạo ra một dàn ý đề xuất. Sau đó tôi đã đọc qua đề xuất của nó và tất cả các ý tưởng khác nhau mà nó đã tạo ra về những gì chúng tôi có thể trình bày và tôi chỉ đưa ra quyết định về những gì tôi muốn thực sự có trong bản trình bày cuối cùng. Và tôi nghĩ đây là một ví dụ về vai trò của quản lý sản phẩm (PM) hiện nay. Giống như Claude là một đối tác động não (brainstorming partner) tuyệt vời. Nó có khả năng tổng hợp một lượng lớn thông tin rất nhanh chóng và trình bày tất cả các khả năng cho bạn. Nhưng vai trò của quản lý sản phẩm vẫn là đưa ra quyết định cuối cùng về việc cái gì nên thuộc về sản phẩm cuối cùng. Vì vậy, đối với điều này, điều tôi quyết định cuối cùng là tôi muốn bài nói chuyện này đề cập đến sự tiến bộ từ việc làm cho các tác vụ cục bộ (local task) thành công đến việc làm cho mọi Pull Request (PR) xanh (green) đến việc giúp các kỹ sư (engineer) merge được nhiều PR hơn và với mỗi điều này, demo nào sẽ là hấp dẫn nhất. Và sau quyết định về dàn ý này, Co-work đã tự động làm việc trong vài giờ và xây dựng toàn bộ bản trình bày.

Điều này thật tuyệt vời. Thật là một phần công việc tuyệt vời mà không cần phải làm nữa. Và nó cảm giác như bạn đang nói chuyện với một nhà thiết kế slide (deck designer) mà cũng có kiến thức thực tế về những gì bạn đã làm và có thể biến nội dung thành những gì bạn muốn, chứ không chỉ làm cho nó trông thật đẹp. Bạn đã làm hệ thống thiết kế (design system) như thế nào? Nó hoạt động ra sao? Làm thế nào nó biết hệ thống thiết kế của Anthropic?

Tận Dụng `Hệ Thống Thiết Kế`

Những gì tôi đã làm cho việc này là chúng tôi thực sự đã có một bản trình bày (deck) tiêu chuẩn mà chúng tôi sử dụng cho tất cả các hoạt động đối ngoại (external engagement) của mình. Và vì vậy tôi chỉ cấp quyền truy cập Claude vào đó. Và vì vậy nó có thể thấy những màu sắc chúng tôi sử dụng, những phông chữ (font) chúng tôi sử dụng, các loại định dạng slide (slide format) khác nhau có thể có. Và vì vậy nó có khoảng 20 slide mẫu này.

Cho một ví dụ. Hiểu rồi. Vậy bạn tải lên "đây là template của chúng tôi, hãy làm việc từ đây."

Đúng vậy. Bạn cũng có thể kết nối với Figma MCP của bạn nếu bạn đã lưu định dạng slide của mình ở đó và nó có thể kéo dữ liệu đó vào.

Bộ Công Cụ Cá Nhân và Ứng Dụng `AI` Nội Bộ

Nói về những điều đó, điều tôi luôn tò mò là bộ công cụ (tool stack) của bạn với vai trò quản lý sản phẩm (PM) tại Anthropic gồm những gì, rõ ràng là Claude Code và Co-work và tất cả các công cụ của Anthropic. Bạn còn sử dụng gì nữa không? Slack bạn đã đề cập, còn gì nữa không?

Bộ công cụ của tôi chủ yếu là Claude Code, Co-work. Anthropic phần lớn chạy trên Slack. Tôi cảm thấy Slack giống như hệ điều hành cốt lõi (core OS) của công ty chúng tôi và hàng ngày, tôi sẽ nói khoảng 30% thời gian của tôi là để đẩy ranh giới (boundaries) của những gì Co-work có thể làm để tôi có cảm nhận rất rõ về những gì chúng tôi chưa giỏi. Và tôi dành nhiều thời gian nói chuyện với mô hình để hiểu tại sao nó mắc lỗi. Chúng tôi thực sự có rất nhiều công cụ nội bộ (internal tool) mà chúng tôi tự xây dựng. Tôi nghĩ một trong những điều Claude Code thực sự đã mở khóa cho toàn bộ công ty chúng tôi là nó thực sự làm giảm rào cản trong việc tạo ra bất kỳ ứng dụng tùy chỉnh (custom app) nào bạn muốn. Và vì vậy chúng tôi đã thấy sự gia tăng mạnh mẽ trong phần mềm làm việc cá nhân hóa (personalized work software) mà mọi người đang xây dựng cho các trường hợp sử dụng tùy chỉnh (custom use case) thay vì sử dụng công cụ không hoàn toàn phù hợp với trường hợp sử dụng.

Tôi muốn nghe thêm. Một vài ví dụ là gì? Những thứ bạn đã xây dựng hoặc người khác đã xây dựng mà thực sự phổ biến và hữu ích?

Một trong những người phụ trách bán hàng (sales) của Claude Code, anh ấy nhận ra mình phải tạo đi tạo lại những bản trình bày (deck) lặp đi lặp lại. Vì vậy, anh ấy thực sự đã xây dựng một ứng dụng web (web app) với các ví dụ về những bản trình bày cốt lõi của Claude Code mà chúng tôi biết là hiệu quả. Ví dụ như 101, 201 và Mastering Claude Code. Và sau đó anh ấy có một cách để nhập ngữ cảnh khách hàng cụ thể được kéo từ Salesforce, từ Gong, từ các ghi chú khác để chúng tôi có thể tùy chỉnh các bản trình bày cho từng khách hàng cụ thể. Và vì vậy nó sẽ kéo ra những điều như: "khách hàng này đang sử dụng Bedrock hoặc Claude Code for enterprise hoặc Console, điều này ảnh hưởng đến các tính năng có sẵn cho họ". Nó cũng sẽ kéo ra những điều như: "khách hàng này lo ngại về giai đoạn đánh giá mã (code review stage) của chu trình phát triển phần mềm (SDLC)". Và vì vậy chúng tôi sẽ thêm một slide về các tính năng đánh giá mã của chúng tôi vào đó. Nó sẽ kéo ra những điều như: "khách hàng này cần phải tuân thủ HIPAA hoặc cần các kiểm soát bảo mật XYZ". Và vì vậy chúng tôi sẽ đảm bảo thêm một hoặc hai slide vào bản trình bày của họ về điều đó. Và sau đó, ví dụ, nếu đây là một khách hàng đang sử dụng Vertex hoặc Bedrock và không muốn sử dụng Claude Code for enterprise, thì chúng tôi sẽ chỉ loại bỏ một số slide chỉ dành cho tính năng Claude Code for enterprise. Và thông thường, đây là công việc thủ công có thể mất 20-30 phút, vì vậy mọi người hoặc dành thời gian làm nó hoặc họ sẽ quyết định không làm và sử dụng bản trình bày chung. Với điều này, chỉ mất vài giây và bạn sẽ có một bản trình bày được thiết kế riêng.

Vai Trò Bền Vững của `Slack`

Điều thú vị là Slack giống như công cụ mà không ai, không ai cố gắng tạo ra phiên bản của riêng mình. Slack vẫn tiếp tục chiến thắng và cách bạn mô tả nó giống như hệ điều hành (OS) của rất nhiều công ty. Thật thú vị khi mọi người nói về Salesforce như Phần mềm dưới dạng dịch vụ (SaaS). Chúng ta không cần phần mềm SaaS nữa. Chúng ta sẽ tự xây dựng. Nhưng Slack là một công cụ bền vững (durable tool) mà không ai muốn cạnh tranh và xây dựng một phiên bản tốt hơn. Tôi nghĩ đó là một cơ sở hạ tầng giao tiếp (communications infrastructure) khá quan trọng và tôi nghĩ họ làm rất tốt nhiệm vụ cốt lõi là giúp mọi người nhận được cập nhật thời gian thực (real-time update).

Đúng vậy. Mọi người ghét Slack, nhưng nó thực sự tuyệt vời trong những gì nó cố gắng làm và những nhóm tiên tiến (cutting edge team) nhất đều nghiện nó. Thật thú vị.

Đúng vậy. Và tôi cũng thích cách họ đã làm cho nó dễ dàng tùy chỉnh. Và vì vậy chúng tôi rất thích tạo Slack bot, và kiểu khả năng hack (hackability) này có nghĩa là chúng tôi có thể tích hợp với Slack theo cách chúng tôi muốn. Vì vậy, thực sự đánh giá cao công việc của Slack về điều đó.

Tin nhắn Nhà tài trợ: Vanta

Đã đến lúc mua một số cổ phiếu Quản lý quan hệ khách hàng (CRM). Tôi rất vui mừng được kể cho bạn về nhà tài trợ hỗ trợ mùa này, Vanta. Vanta giúp hơn 15.000 công ty như Cursor, Ramp, Duolingo, Snowflake và Atlassian đạt được và chứng minh sự tin cậy với khách hàng của họ. Các nhóm đang xây dựng và phát hành sản phẩm nhanh hơn bao giờ hết nhờ trí tuệ nhân tạo (AI). Nhưng kết quả là, lượng rủi ro (risk) được đưa vào sản phẩm và doanh nghiệp của bạn cao hơn bao giờ hết.

Quảng cáo: Giải pháp tuân thủ và quản lý rủi ro Vanta

Mỗi lãnh đạo bảo mật mà tôi trò chuyện đều cảm thấy gánh nặng ngày càng tăng trong việc bảo vệ tổ chức, doanh nghiệp của họ, chưa kể dữ liệu khách hàng. Vì mọi thứ diễn ra quá nhanh, họ liên tục phải phản ứng, đoán định các ưu tiên và xoay sở với những giải pháp lỗi thời. Vanta tự động hóa việc tuân thủ và quản lý rủi ro với hơn 35 khuôn khổ bảo mật và quyền riêng tư, bao gồm SOC 2, ISO 27001 và HIPAA. Điều này giúp các công ty đạt được sự tuân thủ nhanh chóng và duy trì tuân thủ hơn bao giờ hết. Lòng tin có sức mạnh tạo nên hoặc phá vỡ doanh nghiệp của bạn. Tìm hiểu thêm tại vanta.com/lenny. Và với tư cách là người nghe podcast này, bạn sẽ nhận được ưu đãi $1.000 từ Vanta. Đó là vanta.com/lenny.

Các đội ngũ sử dụng `token` nhiều nhất (ngoài Kỹ sư)

Được rồi. Vậy anh đã nói về tất cả các đội ngũ khác nhau này và cách họ sử dụng Claude Code và Co-work để vận hành. Ngoài bộ phận kỹ sư, anh thấy những đội ngũ nào khác? Tôi hình dung bộ phận kỹ sư là nơi tiêu tốn token nhiều nhất, nhưng nếu không phải vậy thì thật thú vị. Chức năng nào hiện đứng thứ hai về việc tiêu tốn token?

Ồ, AI ứng dụng rất tuyệt vời trong việc mở rộng ranh giới về những gì Claude Code và Co-work có thể làm. Rất nhiều thành viên trong đội ngũ AI ứng dụng của chúng tôi dành thời gian với khách hàng để giúp họ áp dụng giao diện lập trình ứng dụng (API) của chúng tôi. Và đôi khi, đội ngũ ứng dụng của chúng tôi sẽ, ví dụ, tạo các nguyên mẫu thay mặt cho những khách hàng này, điều mà Claude Code giúp thực hiện nhanh hơn rất nhiều so với trước đây. Họ cũng có mục tiêu kép là cần quản lý nhiều hoạt động giao tiếp với khách hàng, nhiều yêu cầu từ khách hàng và ghi chú cuộc gọi có ngữ cảnh lịch sử. Vì vậy, họ đều sử dụng Co-work và Claude Code rất nhiều.

Vai trò của đội ngũ AI ứng dụng

Và để hiểu rõ về AI ứng dụng, liệu đó có phải là một vai trò kỹ sư triển khai? Mọi người sẽ mô tả đội AI ứng dụng đang làm gì? Vâng, đó là giúp khách hàng của chúng tôi áp dụng giao diện lập trình ứng dụng (API) và các tính năng mô hình mới nhất trong toàn bộ công ty của họ, cả để cung cấp năng lượng cho các sản phẩm của công ty và để tăng tốc nội bộ.

Hiểu rồi. Vậy nó giống như kiểu hỗ trợ khách hàng theo hướng tiếp cận thị trường (Go-to-Market), giống một kiểu kỹ sư triển khai?

Chính xác. Đó giống như một người làm tiếp cận thị trường (Go-to-Market) rất có chuyên môn kỹ thuật.

Các trường hợp sử dụng `Co-work` trong AI ứng dụng

Hiểu rồi. Tuyệt vời. Vậy anh đang nói rằng đó có thể là bộ phận thứ hai sử dụng nhiều token nhất.

Vâng. Và chúng tôi cũng thấy họ mở rộng ranh giới về những gì Co-work có thể làm. Ví dụ, rất nhiều người trong số họ phụ trách nhiều khách hàng và trong bất kỳ ngày nào bận rộn, họ có thể có từ năm đến mười cuộc gặp gỡ với khách hàng. Vì vậy, điều họ thường dùng Co-work để làm là, đêm hôm trước, họ sẽ yêu cầu AI tóm tắt: "Được rồi, tất cả các cuộc họp với khách hàng sắp tới vào ngày mai là gì? Khách hàng này đã yêu cầu tôi những gì? Điều gì là ưu tiên hàng đầu của họ? Các mục hành động từ các cuộc họp trước là gì?" Và Co-work sẽ tổng hợp một hồ sơ, một bản tóm tắt về những điều họ cần biết trước cuộc họp tiếp theo. Co-work cũng có thể nghiên cứu câu trả lời. Vì vậy, nếu một khách hàng hỏi "Khi nào tính năng X sẽ ra mắt?", Co-work có thể giúp người phụ trách nghiên cứu thông qua Slack để có được thời gian dự kiến (ETA) mới nhất, thêm thông tin đó vào ghi chú để trong cuộc gọi với khách hàng, người phụ trách có thông tin hoàn toàn cập nhật. Và đây chỉ là những workflow mà mọi người tự xây dựng cho bản thân và chia sẻ với những người khác trong nhóm của họ.

Chi phí `token` so với `lương` và xu hướng tăng

Thật thú vị, có một câu hỏi/xu hướng/chủ đề thường xuyên xuất hiện gần đây là token spend (chi phí token) vượt quá lương của mọi người, khi người dùng AI và chi phí cao hơn số tiền họ kiếm được. Có số liệu nào ở Anthropic về lượng token mà các kỹ sư chi tiêu, ví dụ, mỗi tháng, mỗi ngày, hoặc quản lý sản phẩm (PM) không?

Rõ ràng với chúng tôi rằng khi các mô hình trở nên tốt hơn, mọi người ủy thác nhiều nhiệm vụ hơn cho chúng và họ dành nhiều giờ hơn trong các công cụ AI như Claude Code và Co-work. Vì vậy, chúng tôi thấy chi phí token cho mỗi kỹ sư hoặc mỗi người lao động tri thức tăng lên mỗi khi có một bước nhảy vọt của mô hình hoặc một cải tiến sản phẩm đáng kể. Tôi nghĩ nó vẫn thấp hơn nhiều so với lương trung bình của một kỹ sư, nhưng chúng tôi thấy tỷ lệ phần trăm này tăng lên theo thời gian.

Giới hạn `token` nội bộ và việc sử dụng có trách nhiệm tại Anthropic

Thật thú vị, chúng ta đã nói về việc anh có quyền truy cập vào các mô hình tiên tiến nhất và những lợi thế khác khi làm việc tại Anthropic. Tôi tin rằng các anh về cơ bản có token không giới hạn. Anh có thể sử dụng bao nhiêu tùy thích. Có phải vậy không?

Chúng tôi có thể sử dụng rất nhiều token. Một số người vẫn gặp phải giới hạn.

Được rồi, có giới hạn. Được rồi, Baris, dừng lại. H, được rồi. Thật thú vị khi có rất nhiều lợi thế đến từ việc sở hữu mô hình tiên tiến nhất. Đó là một vòng lặp flywheel rất thú vị bắt đầu kích hoạt. Tôi nghĩ chúng tôi cũng rất tin tưởng vào việc trao quyền cho các đội ngũ nội bộ của mình để xây dựng nhanh nhất có thể. Và chúng tôi cũng tin tưởng rằng mọi người đều hiểu chi phí thực sự để vận hành các mô hình này là bao nhiêu. Và chúng tôi tin tưởng đội ngũ của mình sẽ sử dụng token một cách có trách nhiệm. Vì vậy, việc lãng phí token là điều rất không được khuyến khích, nhưng chúng tôi tin tưởng các cá nhân sẽ đưa ra quyết định đó.

Các `kỹ năng` mới nổi cho `quản lý sản phẩm` trong các công ty `AI`

Tuyệt vời. Quay trở lại vai trò quản lý sản phẩm (PM), chúng ta đã nói một chút về điều này, nhưng tôi nghĩ điều này sẽ rất thú vị để mọi người lắng nghe. Điều tôi muốn hiểu là, theo anh, đâu là những kỹ năng mới nổi mà các quản lý sản phẩm cần phát triển/mà các công ty trí tuệ nhân tạo (AI) tìm kiếm nhiều nhất khi tuyển dụng quản lý sản phẩm hiện nay?

Tôi nghĩ kỹ năng khó nhất là khả năng xác định sản phẩm sẽ trông như thế nào sau một tháng. Tôi nghĩ có rất nhiều sự mơ hồ về khả năng của các mô hình trong khoảng thời gian đó và cách hành vi người dùng sẽ thay đổi. Nhưng tôi nghĩ có những pattern (mô hình/khuôn mẫu) mà các quản lý sản phẩm giỏi nhất có thể nhận thấy dựa trên cách người dùng đang lạm dụng giới hạn của sản phẩm hiện có, và các quản lý sản phẩm giỏi nhất có thể cảm nhận được điều đó, đặt ra một hướng đi và kiên định thực hiện theo, thay đổi lộ trình nếu khả năng của mô hình tốt hơn hoặc tệ hơn nhiều so với dự kiến ban đầu của họ. Tôi nghĩ rất khó để có cái nhìn đúng đắn về AGI (Trí tuệ nhân tạo tổng quát), bởi vì tôi nghĩ mọi người đều có thể hình dung ra một tương lai nơi các mô hình cực kỳ thông minh và có thể làm được gần như mọi thứ, trong trường hợp đó, bạn thực sự không cần một sản phẩm quá phức tạp. Bạn thực sự có thể chỉ cần một hộp văn bản nữa nơi bạn nói cho mô hình biết bạn muốn gì. Và nó thông minh đến mức có thể thêm bất kỳ công cụ AI nào hoặc tích hợp bất kỳ giao diện lập trình ứng dụng (API) nào mà nó cần để hoàn thành công việc. Nó biết khi nào nó không chắc chắn. Và nó có thể đặt các câu hỏi làm rõ. Việc xây dựng sản phẩm cho mô hình AGI mạnh mẽ là khá dễ dàng. Tôi nghĩ điều khó khăn là tìm ra cách để mô hình hiện tại phát huy tối đa khả năng của nó? Làm thế nào để giúp người dùng đi đúng lộ trình vàng (golden path)? Làm thế nào để hướng dẫn người dùng tương tác với điểm mạnh của mô hình và khắc phục điểm yếu của nó? Kỹ năng này khá hiếm.

Cách xây dựng `kỹ năng` hiểu mô hình

Và làm thế nào để xây dựng kỹ năng đó? Có phải chỉ đơn giản là sử dụng từng mô hình, về cơ bản là hiểu giới hạn của từng mô hình, có như anh đã nói, có "gu", hiểu được những gì mô hình có thể làm, những gì nó giỏi và không giỏi, và những thay đổi của nó?

Tôi nghĩ đó là dành rất nhiều thời gian để trò chuyện và sử dụng mô hình. Một trong những điều tôi thực sự thích làm là yêu cầu AI tự phân tích hành vi của chính nó (introspect on its own behaviors). Vì vậy, đôi khi khi tôi nhận thấy mô hình làm điều gì đó không mong đợi, ví dụ, có những trường hợp mô hình sẽ thực hiện thay đổi front-end (giao diện người dùng) và chạy thử nghiệm nhưng không thực sự sử dụng UI (giao diện người dùng). Thực ra khá hữu ích khi hỏi mô hình lý do tại sao nó làm điều này. Và đôi khi chúng sẽ nói rằng có điều gì đó gây nhầm lẫn trong câu lệnh/lời nhắc hệ thống (system prompt) hoặc tôi không nhận ra rằng việc xác minh front-end là một phần của nhiệm vụ này, hoặc tôi đã ủy thác việc xác minh cho tác nhân con (sub-agent) này và tác nhân con đó đã không thực hiện kiểm thử và tôi đã không kiểm tra công việc của nó. Rất nhiều lần, chỉ cần tò mò về lý do mô hình đưa ra quyết định đó sẽ cho bạn thấy điều gì đã khiến nó hiểu sai để bạn có thể sửa lại harness (công cụ điều khiển/khung kiểm thử) nhằm khắc phục khoảng cách này.

Điều khác giúp ích là tìm ra những người dùng nào bạn tin tưởng nhất để cung cấp feedback (phản hồi) chính xác về mô hình. Thường có một vài người giỏi hơn những người khác rất nhiều trong việc diễn đạt điều gì làm cho một mô hình cụ thể hoặc sự kết hợp model harness trở nên tốt. Và có rất nhiều người sẽ đưa ra feedback, nhưng không phải feedback của ai cũng có chất lượng tương đương. Vì vậy, việc tìm một nhóm khoảng năm người mà bạn tin tưởng là rất quan trọng để nhận được feedback rất nhanh.

Tôi nghĩ điều thứ ba hữu ích nhưng không phải ai cũng thích làm là xây dựng các evals. Bạn không cần phải xây dựng hàng trăm evals để chúng hữu ích. Chỉ cần xây dựng 10 evals tốt là quan trọng để giúp đội ngũ định lượng mục tiêu là gì, tiến độ của họ đối với mục tiêu đó là gì và họ đang thiếu gì. Và vì vậy, tôi nghĩ eval là một điều bị đánh giá thấp mà nhiều quản lý sản phẩm và nhiều kỹ sư nên thực hiện.

Tầm quan trọng của `evals` trong `quản lý sản phẩm`

Chúng ta đã nói nhiều về evals. Có một xu hướng rằng đây chính là tương lai của quản lý sản phẩm: viết các evals, bởi vì về cơ bản, nó giúp trả lời câu hỏi "Thành công trông như thế nào?". Được rồi, tuyệt vời. Hãy để tôi thực sự định nghĩa nó một cách cụ thể, và sau đó chúng ta sẽ biết. Anh dành bao nhiêu thời gian để viết evals?

Tôi nghĩ tầm quan trọng của evals thay đổi một chút tùy thuộc vào tính năng bạn đang phát triển và/hoặc vấn đề bạn đang cố gắng giải quyết. Vì vậy, có rất nhiều người trong đội ngũ của chúng tôi dành nhiều thời gian để thực hiện evals. Chúng tôi có một nhóm nhỏ những người cộng tác rất chặt chẽ với bộ phận nghiên cứu để hiểu chính xác hơn về hành vi của Claude Code và những lĩnh vực cải tiến lớn nhất là gì, cũng như cố gắng đo lường chúng một cách cụ thể. Cá nhân tôi tham gia vào evals khi có một tính năng mà tôi nghĩ cần định nghĩa sản phẩm rõ ràng hơn một chút, và thường thì đầu ra của việc này là: "Đây là năm evals mà tôi đã tạo; đây là cách bạn chạy chúng; đây là những evals thành công và đây là những evals không thành công; và đây là câu lệnh/lời nhắc mà tôi đã sử dụng để tăng tỷ lệ thành công." Tuy nhiên, nó thay đổi rất nhiều tùy thuộc vào tính năng cụ thể; không phải tính năng nào cũng cần, nhưng tôi nghĩ các tính năng như memory (bộ nhớ) được hưởng lợi rất nhiều từ điều này. Điểm anh nói về việc mọi người rất giỏi đánh giá mô hình thật thú vị. Nó gần giống như một eval do con người thực hiện, kiểu như họ hiểu được mô hình đang phát triển mạnh ở đâu hoặc có thể thiếu sót ở đâu.

Những người giỏi nhất trong việc đánh giá mô hình

Có ai cụ thể mà anh muốn nhắc đến là rất giỏi trong việc này không?

Hai người mà tôi nghĩ là cực kỳ xuất sắc trong việc này là Amanda, người định hình tính cách của Claude. Đó là một vai trò rất khó vì nhiệm vụ quá mơ hồ. Ngay cả lập trình cũng dễ hơn vì bạn có thể xác minh thành công, trong khi việc tạo ra một character (tính cách) đòi hỏi một niềm tin rất mạnh mẽ vào việc Claude nên là ai. Và tôi nghĩ cô ấy có khả năng phi thường không chỉ định hình character, mà còn diễn đạt rõ ràng các mục tiêu, character đó, điều gì thành công và điều gì không.

Nhóm người khác mà tôi thực sự tin tưởng chính là đội ngũ Claude Code. Chúng tôi thường có các bữa trưa đội và bất cứ khi nào có một mô hình mới đang được thử nghiệm, một trong những cách nhanh nhất để chúng tôi nhận được feedback là tại các bữa trưa này, chỉ cần hỏi từng người: "Này, cảm nhận của bạn về mô hình này thế nào?" Và thường thì chúng tôi sẽ nhận được feedback như: "Được rồi, mô hình này không giải thích đầy đủ suy nghĩ của nó. Nó quá đột ngột." hoặc "Này, mô hình này thích viết rất nhiều memory (ký ức) nhưng chúng tôi không chắc liệu các memory đó có chất lượng cao hay không." hoặc một số người sẽ nhận thấy rằng "Mô hình này thích tự kiểm tra bản thân, điều này rất tuyệt," hoặc "Mô hình này không tự kiểm tra đủ." Điều đó cung cấp thông tin cho chúng tôi về việc nên xem xét dữ liệu nào để xác minh xem đây có phải là một pattern lớn hơn không.

Dữ liệu và tầm quan trọng của tính cách `AI`

Chúng tôi có rất nhiều dữ liệu, nhưng rất khó để trích xuất insights. Phản hồi từ nhóm này giúp chúng tôi đưa ra các hypotheses (giả thuyết) cần kiểm tra, và sau đó chúng tôi có thể trích xuất dữ liệu để kiểm tra chúng. Về điểm bạn đã đề cập về đặc tính của Claude... Tôi đã có Ben Mann, một co-founder (đồng sáng lập), trên podcast, và anh ấy nói về điều này, rằng đặc tính, bản chất của Claude là một phần rất quan trọng của Claude. Và tôi đã không nhận ra cho đến sau này, giống như, mọi người, như với Open Claude, thực sự một trong những lý do mọi người buồn là vì personality (tính cách) của Claude. Bởi vì personality của Claude rất tốt, vui vẻ và thú vị, không giống như các models khác. Và cách anh ấy nói là, personality chính là điều khiến Claude làm tốt rất nhiều việc. Nghe có vẻ như một điều nhỏ nhặt bên lề. "Ồ, nó sẽ hài hước, thú vị và nói chuyện một cách vui vẻ," nhưng nó lại là cốt lõi cho sự thành công của Claude. Có điều gì bạn có thể chia sẻ về việc mọi người có thể không hiểu về lý do tại sao đặc tính như bạn mô tả và personality lại quan trọng đến vậy không?

Giá trị của tính cách `AI` trong công việc

Khi bạn nhìn lại tất cả những người bạn đã từng làm việc cùng, luôn có những người mà bạn cảm thấy: "Tôi thực sự thích năng lượng của họ. Tôi thực sự thích vibe (cảm giác) của họ." Và khi mọi người nghĩ về Claude và Claude Code, đây là một trong những điều được nhắc đến nhiều nhất, đó là họ thực sự yêu thích việc Claude nhẹ nhàng và vui vẻ. Tuy nhiên, nó cũng cực kỳ competent (có năng lực) trong task (nhiệm vụ) của bạn. Mọi người rất thích ego (cái tôi) của Claude thấp. Vì vậy, nếu bạn nói với nó: "Này, bạn đã làm sai cái này," nó thực sự xin lỗi. Nó sẽ kiểu: "Ồ, xin lỗi, cảm ơn bạn đã nói cho tôi biết. Hãy để tôi sửa nó. Chúng ta hãy làm việc cùng nhau." Nó cũng rất positive (tích cực). Vì vậy, nếu bạn cảm thấy: "Ồ, đây là một task bất khả thi. Tôi không biết bắt đầu từ đâu," Claude sẽ nói: "Không sao đâu. Đây là những bước tôi nghĩ chúng ta nên thực hiện. Bạn có muốn tôi bắt đầu làm cho bạn không?" Tôi nghĩ một phần tạo nên một co-worker (đồng nghiệp) tuyệt vời chính là sự positivity này, xu hướng bias towards action (thiên về hành động) này, khả năng đưa ra feedback (phản hồi) chân thật cho bạn, chứ không chỉ đồng ý với mọi điều bạn nói. Và vì vậy, chúng tôi cố gắng truyền điều này vào Claude vì chúng tôi nghĩ nó làm cho việc làm việc với nó trở nên thú vị hơn rất nhiều.

Thích nghi với `LLM` mới

Có một điều tôi muốn quay lại. Bạn đã nói về việc khi các model mới ra đời, bạn thường phải xem xét lại những gì mình đã xây dựng. Điều đó thật thú vị và cũng có thể gây khó chịu, kiểu như: "Ôi trời ơi, chúng ta đã ra mắt sản phẩm này rồi, bây giờ lại phải suy nghĩ lại." Hãy nói về tần suất bạn phải quay lại với một model mới và cảm thấy: "Được rồi, chúng ta phải làm lại product (sản phẩm) này mà chúng ta đã ra mắt vài tháng trước."

Đơn giản hóa sản phẩm khi `LLM` thông minh hơn

Rất nhiều thay đổi mà chúng tôi thực hiện với một model mới là loại bỏ các features (tính năng) không còn cần thiết. Vì vậy, nhiều khi chúng tôi thêm features vào product như một crutch (điểm tựa) cho model vì nó không tự làm được. Ví dụ điển hình cho điều này là một to-do list (danh sách việc cần làm). Khi chúng tôi lần đầu ra mắt Claude Code, mọi người sẽ yêu cầu nó thực hiện các refactors (tái cấu trúc) lớn và Claude Code sẽ nói: "Được rồi, tôi cần thay đổi 20 call sites (điểm gọi hàm) này," và nó sẽ đi và thay đổi năm cái rồi dừng lại. Sau đó chúng tôi nghĩ: "Làm thế nào để chúng ta buộc nó phải nhớ để hoàn thành tất cả 20 cái này?" Và Sid trong team của chúng tôi nói: "Được rồi, nếu chúng ta chỉ nghĩ về những gì một con người sẽ làm thì sao? Một con người sẽ lập một list (danh sách) tất cả những gì họ cần thay đổi. Tương tự như cách bạn tra cứu tất cả các call sites trong VS Code, và nó sẽ là một list ở bên trái, và bạn sẽ duyệt qua từng cái một và thay thế tất cả. Làm thế nào để chúng ta cung cấp loại tool (công cụ) này cho Claude?" Và thế là anh ấy đã thêm một to-do list, và chúng tôi nhận thấy rằng với nó, Claude thực sự đã có thể sửa tất cả 20 call sites này. Nhưng sau đó, với Opus 4 và các models sau này, chúng tôi nhận ra rằng chúng tôi không cần phải buộc nó sử dụng to-do list này nữa. Nó sẽ tự động sử dụng nó. Đối với các models trước đó, chúng tôi phải liên tục nhắc nhở nó: "Này, bạn đã hoàn thành mọi thứ trong to-do list chưa? Bạn không thể hoàn thành cho đến khi bạn xong mọi thứ trong to-do list." Và đối với các models sau này, mà không cần prompting (ra lệnh), nó tự nhiên nghĩ đến việc làm mọi thứ trong to-do list. Ngày nay, to-do list vẫn rất hữu ích như một user (người dùng) vì bạn có thể thấy rõ hơn những gì Claude đang làm. Nhưng thành thật mà nói, nó là một phần rất deemphasized (ít được nhấn mạnh) của product hiện tại, đến mức model có thể sử dụng hoặc không sử dụng nó; nó thực sự không cần thiết để thực hiện các thay đổi kỹ lưỡng nữa.

Khi `LLM` phát triển, `harness` trở nên dư thừa

Tôi quên ai đã nói điều này trên podcast rằng model sẽ "ăn sạch harness của bạn cho bữa sáng." Và điều tôi nghe được ở đây về cơ bản là bạn loại bỏ dần những thứ bạn đã phải thêm vào model khi nó không hoạt động theo cách bạn muốn. Và về cơ bản, khi các models trở nên thông minh hơn, mọi việc trở nên đơn giản hơn rất nhiều để nó làm được điều bạn muốn.

Mở khóa tính năng mới với `LLM` tiên tiến

Đúng vậy. Chúng ta có thể loại bỏ rất nhiều prompting interventions (can thiệp lệnh/lời nhắc) mỗi khi model trở nên thông minh hơn. Và chúng tôi thực sự làm điều này mỗi khi ra mắt một model. Chúng tôi đọc qua toàn bộ system prompt và suy nghĩ: "Được rồi, đối với từng phần này, model có thực sự cần lời nhắc này nữa không?" Và nếu không, chúng tôi sẽ loại bỏ nó. Tuy nhiên, điều thú vị nhất mà các models mới mở khóa chính là những features hoàn toàn mới. Có rất nhiều features mà chúng tôi đã thử nghiệm với các models trước đó và accuracy (độ chính xác) không đủ cao để chúng tôi muốn ra mắt chúng. Và một ví dụ về điều này là code review (đánh giá mã). Chúng tôi đã cố gắng xây dựng một product code review vài lần và chúng tôi đã ra mắt các phiên bản code review đơn giản hơn, đó là lệnh /code review trong quá khứ. Và chỉ với các models gần đây nhất, chúng tôi mới cảm thấy: "Được rồi, code review này tốt đến mức engineering team (đội ngũ kỹ sư) của chúng tôi dựa vào code review này để được duyệt trước khi chúng tôi merge PRs (hợp nhất các yêu cầu kéo)." Và chúng tôi nhận thấy rằng đây là điều chúng tôi luôn mơ ước Claude có thể trở thành một code reviewer đáng tin cậy, thực sự có thể tự tin phát hiện phần lớn các bugs (lỗi). Và chỉ với Opus 45 và 46 cùng Sonnet 4.6, chúng tôi mới cảm thấy: "Được rồi, bây giờ chúng ta có thể chạy nhiều code review agents (tác nhân đánh giá mã) cùng lúc để duyệt qua toàn bộ codebase (cơ sở mã) và tổng hợp một bộ các vấn đề thực sự mà một engineer (kỹ sư) cần giải quyết trước khi merge (hợp nhất)." Và đây là một capability (khả năng) mới mà các models mới nhất đã mở khóa.

Chiến lược phát triển sản phẩm đón đầu công nghệ

Đây là một trend (xu hướng) phổ biến khác trên podcast này: "Xây dựng thứ gì đó có thể khả thi trong sáu tháng tới. Hãy đứng ở edge (ranh giới) của những gì đang hoạt động, và sau đó nó sẽ bắt kịp, và rồi nó sẽ trở thành một product tuyệt vời, và bạn sẽ dẫn trước mọi người."

Xây dựng `prototype` và kiểm thử với `LLM` mới

Vâng, chính xác. Điều khá quan trọng là xây dựng các products mà chưa chắc đã hoạt động, để bạn biết: "Được rồi, điều gì đang thiếu để product này hoạt động?" Và sau đó, với model mới nhất, bạn có thể chỉ cần swap (hoán đổi) nó vào prototype (nguyên mẫu) bạn đã tạo và xem: "Được rồi, model mới này có thu hẹp khoảng cách đó không?"

Tầm nhìn tương lai của Claude và `Co-Work`: Từ nhiệm vụ đơn lẻ đến hệ thống tác vụ phức tạp

Bạn có thể chia sẻ bao nhiêu về định hướng của Claude và Co-Work như là vision (tầm nhìn) của nó? Tôi nghĩ bạn không muốn tiết lộ quá nhiều về goal (mục tiêu), nhưng dường như có rất nhiều features (tính năng) tuyệt vời đang được thêm vào: dispatch control (điều khiển gửi) từ phone (điện thoại) và tất cả các ứng dụng mobile app (ứng dụng di động) này. Cách nào để hiểu được vision dài hạn cho tất cả những điều này? Chúng tôi suy nghĩ về điều này dưới dạng các building blocks (khối xây dựng). Vì vậy, đối với cả Claude Code và Co-Work, building block cốt lõi là làm cho các tasks (nhiệm vụ) cá nhân thành công. Bạn muốn tạo ra một output (đầu ra), bạn cung cấp một prompt description (mô tả lời nhắc) rõ ràng. Liệu nó có thể liên tục tạo ra output chấp nhận được mà bạn có thể merge (hợp nhất) hoặc share (chia sẻ) với colleagues (đồng nghiệp) hoặc external audience (khán giả bên ngoài) của mình không? Vì vậy, task là building block cốt lõi. Khi các models trở nên thông minh hơn, task success rate (tỷ lệ thành công của nhiệm vụ) sẽ cao hơn rất nhiều. Và sau đó chúng tôi thấy mọi người chuyển sang thực hiện nhiều tasks cùng lúc. Vì vậy, multi-coding (lập trình đa nhiệm) là một điều lớn vào cuối năm 2025 và nó chỉ tăng lên kể từ đó. Và vì vậy chúng tôi thấy điều này là: "Được rồi, một task hoạt động tuyệt vời, và bây giờ bạn có thể làm sáu tasks cùng một lúc." Khi các models thậm chí còn thông minh hơn, cách chúng tôi ngoại suy điều này là: "Được rồi, tiếp theo, có thể bạn sẽ chạy 50 Claudes cùng một lúc, hoặc hàng trăm Claudes cùng một lúc." Vậy infrastructure (cơ sở hạ tầng) nào chúng ta cần xây dựng để cho phép điều đó? Tại thời điểm đó, bạn có thể sẽ không chạy mọi thứ cục bộ trên máy tính của mình nữa. Đơn giản là không đủ RAM (bộ nhớ truy cập ngẫu nhiên) để làm điều đó. Và vì vậy chúng tôi đang suy nghĩ về cách chúng tôi làm cho việc quản lý tất cả những thứ này dễ dàng hơn cho bạn? Những thứ này có thể sẽ chạy từ xa. Làm thế nào chúng ta xây dựng interface (giao diện) để bạn, với tư cách là con người, biết mình cần xem tasks nào? Làm thế nào chúng ta đảm bảo rằng AI Agent đang verifying (xác minh) công việc một cách đầy đủ để khi bạn nhìn vào một task và nó nói là đã xong, bạn có thể nhanh chóng verify và hoàn toàn tin tưởng rằng nó đã hoàn thành đúng theo spec (đặc tả) của bạn? Và làm thế nào chúng ta đảm bảo rằng process (quy trình) này là self-improving (tự cải thiện) để khi bạn thấy một task không được thực hiện theo ý muốn của bạn, bạn có thể đưa feedback và model sẽ biết cách kết hợp feedback đó cho mọi lần chạy trong tương lai để không bao giờ mắc lại lỗi đó nữa? Vì vậy, đây là progression (sự tiến bộ) mà chúng tôi đang cùng users (người dùng) của mình thực hiện.

Lời khuyên `lộ trình sự nghiệp` trong kỷ nguyên `AI`

Có rất nhiều người đang lắng nghe, rất nhiều product managers (quản lý sản phẩm), có thể là nhiều founders (nhà sáng lập), nhiều người làm cross-functional (đa chức năng) khác đang lắng nghe. Có rất nhiều lo lắng về vai trò và tương lai của lộ trình sự nghiệp của họ. Bạn có lời khuyên nào cho mọi người để không chỉ tồn tại trong transition (quá trình chuyển đổi) sang thế giới AI-driven world (thế giới do AI điều khiển) này, mà còn để thực sự thành công, để về cơ bản là phát triển mạnh trong future (tương lai) này không? Có những điều gì mọi người cần nghe, cần làm không?

Tận dụng `AI` để tối ưu `năng suất` và đổi mới

Tôi nghĩ trí tuệ nhân tạo (AI) mang lại cho mọi người nhiều leverage (đòn bẩy) hơn trước đây rất nhiều. Vì vậy, tôi sẽ khuyến khích bạn bất cứ khi nào bạn nhận ra mình đang thực hiện một manual task (nhiệm vụ thủ công) nhiều lần, hãy nghĩ xem bạn có thể sử dụng Claude Code, Co-Work hoặc các AI tools (công cụ AI) khác để automate (tự động hóa) điều đó cho bạn như thế nào. Hầu hết mọi người đều có những creative parts (phần sáng tạo) trong job (công việc) mà họ thực sự yêu thích và những tedious parts (phần tẻ nhạt) trong job mà họ thực sự ghét làm. Tôi nghĩ vẻ đẹp của AI là nó có thể làm những tedious parts đó cho bạn. Nó có thể learn (học hỏi) từ mỗi lần bạn thực hiện manual task đó và generalize (khái quát hóa) rồi run (chạy) nó automatically để bạn có thể tập trung vào những creative parts, và điều đó có nghĩa là bạn có thể làm được nhiều hơn rất nhiều so với trước đây. Vì vậy, tôi nghĩ khuyến khích tức thì của tôi dành cho mọi người là: figure out the repetitive parts (tìm ra những phần lặp đi lặp lại) mà bạn có thể pass (chuyển giao) cho Claude. Iterate (lặp lại) các automations đó cho đến khi success rate (tỷ lệ thành công) rất cao, và sau đó tập trung vào: "Được rồi, bạn có thể làm thêm điều gì cho team (đội nhóm), cho product (sản phẩm), cho company (công ty) của bạn mà mọi người chưa có bandwidth (khả năng, thời gian) để thực hiện cho đến nay?" Hoặc: "Đó là pet project (dự án cá nhân) mà bạn luôn nghĩ company nên làm nhưng bạn chưa bao giờ có bandwidth để làm là gì?" Nếu AI có thể lo liệu grunt work (công việc nhàm chán, nặng nhọc), thì bây giờ bạn có thêm 20% thời gian mà trước đây bạn có thể không có. Vì vậy, khuyến khích của tôi là lean into these tools (tận dụng tối đa những công cụ này), hand off the work (chuyển giao công việc) mà bạn không hào hứng làm, figure out how it can accelerate you (tìm cách nó có thể thúc đẩy bạn), và sau đó, kết quả là bạn sẽ có thể làm được nhiều hơn rất nhiều.

Tìm kiếm vấn đề để giải quyết bằng `AI`

Một điều cốt lõi trong những gì bạn vừa chia sẻ, mà tôi hoàn toàn đồng ý, là: find problems to solve with AI (tìm ra vấn đề để giải quyết bằng AI). Có tất cả tiềm năng mà những tools này có thể làm được.

Tự Động Hóa 100%: Giá Trị Thực Sự

Một trong những phần khó khăn nhất đối với nhiều người là việc xác định: "Tôi thực sự nên làm gì?" Và điều bạn đang nói ở đây là hãy chú ý đến những việc bạn đang làm liên tục mà có thể tự động hóa. Hãy chú ý đến những ý tưởng đã lởn vởn trong đầu mà bạn chưa có thời gian thực hiện. Về cơ bản, lời khuyên cốt lõi ở đây là: hãy tự giải quyết một vấn đề cho chính mình.

Tôi cũng muốn khuyến khích người nghe tập trung vào việc đưa các giải pháp tự động hóa của bạn từ trạng thái "đây là một khái niệm thú vị" sang "này, cái này thực sự hoạt động 100% mọi lúc". Đôi khi tôi thấy người dùng cố gắng tự động hóa một thứ gì đó, đạt được độ chính xác khoảng 90-95%, rồi sau đó từ bỏ. Và nếu một giải pháp tự động hóa không hoạt động 100% thời gian, thì nó không thực sự là một giải pháp tự động hóa. Và 5 đến 10% cuối cùng đó đòi hỏi nhiều thời gian hơn. Ngoài ra, việc xây dựng giải pháp tự động hóa thường chậm hơn rất nhiều so với việc bạn tự làm. Tôi khuyến khích người nghe dành thời gian đó để định hình một giải pháp tự động hóa mà bạn thực sự muốn đạt 100%. Hãy bỏ công sức ra để huấn luyện AI theo sở thích của bạn, cung cấp phản hồi để nó có thể cải thiện skill của mình và đạt đến 100%. Khi đó, bạn thực sự sẽ có thể tin cậy vào nó. Không có nhiều giá trị trong một giải pháp tự động hóa chỉ đạt 95%.

Thử Nghiệm Tự Động Hóa Cá Nhân: Bài Học Về Sự Hoàn Hảo

Tôi hoàn toàn mắc lỗi đó. Đây là lời khuyên rất hay dành cho tôi.

Tôi cũng mắc lỗi này. Tôi đã dạy co-work để cố gắng giúp tôi đạt inbox zero cho Gmail, và nó đã rất tốn thời gian nhưng chắc chắn chưa đạt được mục tiêu, như bạn có lẽ đã nhận ra.

Phải, thật thú vị là tâm trí tôi cũng nghĩ đến điều đó. Tôi có một workflow đã thiết lập, trong đó mọi email tôi nhận được, nó sẽ tìm kiếm những thứ có vẻ spammy – tức là tất cả những email kiểu như, "Này, tôi có thể tham gia podcast của bạn không?" hoặc "Còn cái này thì sao?" – những thứ mà tôi không có thời gian để xử lý. Và tôi đã phân loại chúng vào một thư mục gọi là spammy. Nó hoạt động tốt 95%, nhưng sau đó lại có những trường hợp, ồ, tôi đã bỏ lỡ một email quan trọng vì nó nằm trong đó. Vì vậy, đây là một động lực tốt để tôi nói rằng, tôi sẽ tập trung vào việc này. Tôi sẽ làm cho nó hoàn hảo.

Đơn Giản Hóa Tùy Chỉnh Tự Động Hóa

Vâng. Chúng tôi cũng đang nỗ lực để làm cho quy trình tùy chỉnh các lệnh này dễ dàng hơn nhiều, bởi vì hiện tại tôi nghĩ bạn phải biết quá nhiều khái niệm. Bạn phải biết cách định nghĩa một skill. Bạn phải biết cách sử dụng skill này và cung cấp phản hồi. Và sau đó bạn phải biết cách yêu cầu co-work cập nhật skill dựa trên tất cả phản hồi bạn đã đưa. Và sau đó bạn cũng phải biết nơi để đọc skill đó để đảm bảo rằng phản hồi đã được tích hợp theo cách bạn muốn. Đó cũng là công việc của chúng tôi để làm cho flow này thực sự liền mạch để việc thực hiện không còn khó khăn.

Xây Dựng Ứng Dụng AI Hữu Ích, Không Chỉ Prototype

Tuyệt vời. Cat, bạn có muốn chia sẻ điều gì khác không? Có điều gì bạn muốn gửi gắm đến người nghe không? Có điều gì bạn muốn nhấn mạnh thêm mà chúng ta chưa đề cập trước khi đến phần lightning round rất thú vị của chúng ta không?

Tôi thấy rất nhiều người đang thử nghiệm với AI và xây dựng các ứng dụng prototype cũng như mày mò với việc xây dựng các workflow. Tôi thực sự muốn khuyến khích mọi người hướng tới việc xây dựng các ứng dụng mà bạn thực sự sử dụng mỗi ngày, bởi vì tôi nghĩ chỉ thông qua việc sử dụng đó bạn mới thực sự nhận được giá trị. Chẳng hạn, nếu bạn xây dựng một ứng dụng prototype mà không giúp bạn hoàn thành nhiều việc hơn, thì AI thực sự không bổ sung giá trị cho ngày của bạn.

...cho ngày của bạn.

Và bạn chỉ học được rất ít từ điều đó khi bạn kiểu như, "À, tôi vừa làm xong một cái gì đó nhanh chóng." "Ồ, cái đó hay đấy." Và rồi bạn không bao giờ quay lại với nó. Bạn không học được nhiều.

Và bạn không nhận được nhiều leverage từ nó.

Và leverage thực sự. Đúng vậy, đó là một điểm rất hay.

Cân Bằng Giữa Tùy Chỉnh và Mục Tiêu Cốt Lõi

Tôi cũng nghĩ có rất nhiều người dành nhiều thời gian để tùy chỉnh workflow của họ. Vì vậy, tôi nghĩ có hai thái cực. Một là những người không bao giờ tùy chỉnh hoặc không bao giờ xây dựng tự động hóa, nhưng cũng có thái cực đối lập là những người bị ám ảnh bởi việc tùy chỉnh tool của họ, như thêm vô số skill và MCP cũng như những cải tiến workflow này. Và tôi nghĩ đôi khi điều đó có thể làm phân tâm khỏi mục tiêu cốt lõi của bạn, như ra mắt một product hoặc xây dựng một feature. Tôi nghĩ việc tùy chỉnh có rất nhiều niềm vui và chúng tôi chắc chắn muốn làm cho các product của mình rất dễ hack để bạn có thể làm cho nó hoạt động thực sự tốt cho mình, nhưng có một giới hạn về mức độ hữu ích của nó. Và tôi nghĩ có một nhóm người có lẽ dành quá nhiều thời gian để tùy chỉnh đến nỗi họ không ngủ và không làm nhiệm vụ cốt lõi mà họ ban đầu đặt ra.

Tôi thấy rất nhiều điều đó trên Twitter, kiểu như, "Nhìn thiết lập của tôi kìa! Nó ngoài tầm kiểm soát! Nó quá tối ưu!" Rồi, bạn đang thực sự xây dựng cái gì vậy? "Không, nhưng thiết lập của tôi thật tuyệt vời. Nó hoàn thành rất nhiều việc."

Tôi nghĩ những thiết lập đơn giản thực sự hoạt động tốt hơn.

[transcript bị gián đoạn] level up một chút.

Vâng. Vâng.

Từ AI Dựa Trên Chat Đến AI Dựa Trên Hành Động

Có một tweet của Karpathy vừa được đăng tải hôm qua, trong đó ông ấy nói về sự phân chia thú vị giữa những người đã thử ChatGPT hoặc Claude trước đây và cảm thấy "ổn thôi," rồi sau đó họ nghĩ "không, cái này tệ quá" và từ bỏ ý định về những gì AI có thể làm cho họ. Họ trở nên hoài nghi, kiểu như "không đời nào, nó không thực sự quan trọng đến thế." Và sau đó có những người đang sử dụng nó để lập trình, những người thực sự thấy được sức mạnh và sự tuyệt vời của nó. Những người ở cả hai phía không hiểu phía bên kia và cách họ nhìn nhận thế giới. Vì vậy, lời khuyên của bạn ở đây thực sự rất tốt: hãy thực sự sử dụng nó cho những công việc thực tế và xem nó đã trở nên tốt đến mức nào.

Vâng, tôi nghĩ sự thay đổi lớn là thế hệ sản phẩm chat-based của năm 2024 và thế hệ sản phẩm action-based (Claude Code generation) hiện tại. Khoảnh khắc "aha" lớn mà mọi người trải qua là khi AI có thể làm mọi thứ thay mặt bạn. Thật là một cảm giác tuyệt vời khi biết rằng agent có khả năng làm nhiều hơn là chỉ nói cho bạn biết phải làm gì. Agent thực sự có thể tự mình làm điều đó. Và khi mọi người cảm nhận được điều đó, tôi nghĩ đó là khoảnh khắc mở mắt.

Khen ngợi Chrome extension, cái được gọi là Chrome extension, cái mà bạn chỉ cần xem nó làm việc và bạn sẽ nói, "Điền cái form này giúp tôi đi," và nó sẽ kiểu, "Được rồi, tôi đây."

Chính xác.

Lightning Round: Sách Khuyên Đọc

Được rồi. Còn gì nữa không trước khi chúng ta đến với phần lightning round rất thú vị của chúng ta?

Không, làm thôi!

Làm thôi! Cat, tôi có năm câu hỏi dành cho bạn. Chào mừng đến với lightning round. Có cái hình động này xuất hiện. Tôi phải đảm bảo là nói điều đó. Bạn đã sẵn sàng chưa?

Tôi sẵn sàng! Câu hỏi đầu tiên, hai hoặc ba cuốn sách nào mà bạn thường xuyên giới thiệu cho người khác nhất?

Tôi thực sự thích cuốn How Asia Works. Nó là câu chuyện về phát triển kinh tế và những chính sách cũng như chính phủ nào tạo nên các nền kinh tế thành công lâu dài. Những cuốn sách khác mà tôi rất tâm đắc là The Technology Trap. Cuốn này nói về vài cuộc cách mạng công nghệ trong quá khứ, như cuộc cách mạng công nghiệp và cách mạng máy tính, và cách chúng đã ảnh hưởng đến worker. Lý do tôi thực sự thích cuốn này là vì tôi nghĩ chúng ta có thể học hỏi rất nhiều từ lịch sử để đảm bảo rằng quá trình chuyển đổi này diễn ra tốt đẹp. Và, có lẽ ở một khía cạnh vui vẻ hơn, tôi thực sự thích Paper Menagerie. Đó chỉ là một tập truyện ngắn về tuổi trưởng thành, AI và sự tự khám phá.

Phim/Chương Trình TV Yêu Thích: Sự Tập Trung Tuyệt Đối

Bộ phim hoặc chương trình TV gần đây yêu thích mà bạn thực sự đã thưởng thức là gì?

Tôi thực sự thích Drive to Survive. Không có ý nghĩa sâu xa gì đặc biệt. Tôi chỉ thấy có điều gì đó rất thỏa mãn khi chứng kiến mọi người bị ám ảnh bởi một mục tiêu engineering duy nhất và sự thuần khiết trong việc theo đuổi mục tiêu đó. Và tôi cũng rất yêu thích Free Solo, một bộ phim về Alex Honnold leo núi El Capitan mà không dùng dây bảo hiểm. Tôi nghĩ tương tự, đó là một thành tựu thuần túy khi có thể leo một con đường cực kỳ thử thách, nguy hiểm và có thể duy trì sự tập trung tinh thần để làm điều đó, biết rằng nếu mắc một lỗi nhỏ, bạn sẽ chết.

Thật điên rồ. Phải, bộ phim đó thật ngoài tầm kiểm soát. Và thật thú vị khi những điều này bằng cách nào đó lại liên quan đến công việc bạn làm.

Tôi thực ra là một người leo núi đá. Tôi xem Free Solo lần đầu trước khi leo núi đá, vì vậy tôi nghĩ nó ấn tượng. Nhưng tôi không hiểu mức độ ấn tượng thực sự của nó. Đây là một trong số ít bộ phim mà càng biết nhiều về nó, bạn càng bị choáng ngợp bởi mức độ điên rồ của nó. Kiểu những động tác anh ấy thực hiện trên vách đá là những thứ mà tôi không nghĩ mình sẽ bao giờ làm được trong đời, ngay cả khi nó được thiết lập trong phòng tập, cách mặt đất một foot.

...với dây thừng.

Với dây thừng.

Bạn có xem bộ phim tài liệu về người kia, người trẻ hơn leo núi băng không?

Tôi có. Bộ đó rất buồn.

Nhưng bộ đó thật hoang dại. Được rồi.

Sản Phẩm Yêu Thích: Waymo và Năng Suất Cá Nhân

Sản phẩm yêu thích bạn mới khám phá mà bạn thực sự yêu thích là gì?

Sản phẩm thay đổi cuộc sống của tôi nhiều nhất ngoài các sản phẩm Claude có lẽ là Waymo. Tôi là một người dùng Waymo cuồng nhiệt. Tôi sử dụng nó hai lần một ngày, đi làm và về nhà. Hai điều tôi thực sự thích ở nó là: một, tôi không cảm thấy áy náy nếu một chiếc Waymo đang đợi tôi. Vì vậy, tôi cảm thấy ít áp lực hơn khi phải có mặt ngay bên lề đường vào đúng lúc nó đến. Và điều thứ hai là tôi cảm thấy nó cho phép tôi năng suất hơn một chút. Khi tôi ở trong xe với một người khác, tôi thường cố gắng không thực hiện bất kỳ cuộc gọi công việc nào. Tôi cảm thấy hơi thô lỗ nếu tôi ngồi làm việc trên laptop suốt thời gian đó. Nhưng một điều tôi thực sự đánh giá cao ở Waymo là tôi có thể tham gia một cuộc gọi công việc. Tôi không lo lắng về việc ai đó nghe lén. Tôi không lo lắng, "Này, điều này có thô lỗ không? Tôi có đang nói quá to không? Tôi có cần yêu cầu ai đó đổi nhạc không?" Và vì vậy, điều này giống như đã giúp tôi lấy lại khoảng 30 phút mỗi ngày.

Tất cả những hiệu ứng cấp hai này của công nghệ. Thật thú vị.

Vâng. Tôi luôn nghĩ Waymo cần có giá thấp hơn Uber và Lyft để thành công, nhưng thực ra tôi rất vui khi trả mức giá cao gấp đôi cho nó.

Tôi yêu Waymo. Nó giống như, một khi bạn thấy nó, bạn sẽ thốt lên, "Chà, thật điên rồ!" Và sau đó bạn quen với nó. Bạn bước vào xe, bạn nói, "Cái này thật kỳ diệu." Và sau đó bạn quên béng mất.

Hoàn toàn đúng. Và tôi nghĩ nó cũng đã thay đổi cách nói chuyện. Rất nhiều người ở Anthropic yêu Waymo. Và tôi nghĩ trước đây bạn sẽ nói, "Này, hãy gọi một ứng dụng chia sẻ chuyến đi nào đó." Và bây giờ, mọi người chỉ nói, "Được rồi, Waymo đã đến chưa?"

Phương Châm Sống: "Cứ Làm Đi"

Được rồi, hai câu hỏi nữa. Bạn có một phương châm sống yêu thích mà bạn thường quay lại trong công việc hay cuộc sống không?

Cứ làm đi (Just do things).

Đúng vậy.

Tôi nghĩ có rất nhiều giá trị trong tư duy first principles. Và nếu bạn biết mình đang tối ưu hóa cho điều gì và bạn có những first principles vững chắc, thì bạn thường có thể suy ra hành động đúng đắn là gì và có thể trình bày rõ ràng điều đó với tất cả các stakeholder. Và sau đó bạn chỉ cần làm thôi. Tôi nghĩ các job là giả. Nếu bạn hiểu các ràng buộc, bạn có thể tìm ra những gì bạn có thể làm, sau đó chỉ cần cố gắng làm nó nhanh chóng, học hỏi từ những sai lầm và xin lỗi hoặc sửa chữa chúng nếu bạn làm sai điều gì đó.

Bạn, bạn có thể chỉ cần làm mọi thứ, bất cứ ai đã nói điều đó.

Tôi nghĩ việc nói điều này với mọi người thực sự mang lại sự giải phóng. Tôi nghĩ ở nhiều công ty, vai trò được định nghĩa rất chặt chẽ, kiểu như, "đây là việc PM làm," "đây là việc designer làm," "đây là việc engineer làm," và sau đó ngay cả phạm vi nhóm cũng được định nghĩa rất cứng nhắc. Kiểu như, "này, chúng ta chỉ động vào góc này của codebase và góc kia thì chúng ta không được phép chạm vào."

Khả năng tự quyết và Ranh giới làm việc tại Startup

Tôi nghĩ rằng việc 'chỉ cần làm mọi thứ' cho phép mọi người cảm thấy được trao quyền để đưa ra các quyết định này, được trao quyền để hoạt động xuyên biên giới đội nhóm chỉ để hoàn thành một việc gì đó. Đó là một kỹ năng quan trọng cần phải thành thạo. Mọi người gọi đó là agency (khả năng tự quyết). Giống như việc thiên về hành động – tất cả những cách này đều mô tả việc không chờ đợi sự cho phép.

Vâng. Tôi nghĩ đây là lý do yêu thích của tôi để làm việc tại một startup vào một thời điểm nào đó trong đời, bởi vì một điều thực sự thay đổi cuộc đời tôi là làm việc ở quy mô lớn khi chúng tôi chỉ có 20 người. Khi đó không có quy trình nào cả và chúng tôi có những vấn đề thực sự lớn cần phải giải quyết. Và tôi thực sự biết ơn Alex và phần còn lại của đội ngũ đã trao quyền cho tôi và toàn đội để tự mình tìm ra cách giải quyết mọi thứ mà không có bất kỳ Ranh giới nào về việc Bán hàng nên làm gì, vận hành nên làm gì, hay kỹ sư nên làm gì. Giống như bạn có tất cả các công cụ tùy ý sử dụng, bạn có một vấn đề đầy tham vọng và phức tạp, và bạn có thể làm bất cứ điều gì cần thiết để đạt được một giải pháp tốt.

Bạn gần như cần kinh nghiệm đó để xây dựng kỹ năng này và cảm thấy thoải mái khi làm điều đó, bởi vì rất nhiều người, bạn biết đấy, họ học ở trường phổ thông hoặc đại học và được dạy: 'hãy làm điều chúng tôi bảo bạn làm và bạn sẽ đạt điểm cao.' Và bạn phải từ bỏ tư duy đó, để suy nghĩ: 'Được rồi, tôi sẽ làm điều cần phải làm, ngay cả khi mọi người nghĩ nó ngớ ngẩn, tôi vẫn nghĩ đó là điều đúng đắn.' Vâng, chính xác.

"Từ khóa tư duy" của Claude

Được rồi, tôi có thêm hai câu hỏi nhanh nữa, hai câu hỏi cuối cùng. Một là: khi Claude suy nghĩ, có tất cả những thứ này – tôi không biết bạn có gọi chúng là động từ không – thuật ngữ cho những thứ này là gì? 'Từ khóa tư duy.' Và điều thú vị là tất cả những điều này đã bị rò rỉ trong mã nguồn. Bạn có 'từ khóa tư duy' yêu thích nào không? Tôi thực sự thích 'manifesting' (hiện thực hóa). Nó cũng giống như hình dán mà tôi có trên món đồ yêu thích của mình. Rõ ràng là từ khóa thắng cuộc.

Cuộc sống sau AGI (Trí tuệ tổng quát nhân tạo)

Được rồi, câu hỏi cuối cùng. Tôi cũng đã hỏi Boris câu này: với AGI (trí tuệ tổng quát nhân tạo) có khả năng xuất hiện trong đời chúng ta, khi bạn có thể không cần phải làm việc nữa, bạn sẽ làm gì? Bạn sẽ làm gì với tất cả thời gian của mình?

Tôi nghĩ sẽ mất một thời gian dài để AGI lan tỏa khắp xã hội. Vì vậy, tôi nghĩ điều trước mắt là giúp cả thế giới cùng tiến lên. Câu trả lời không nghiêm túc của tôi cho sau khi điều này xảy ra là tôi có thể sẽ leo núi đá rất nhiều. Tôi có thể sẽ chuyển đến Fountain Blue và sống giữa 10.000 tảng đá và leo núi một thời gian. Cũng có rất nhiều sách tôi muốn đọc, mục tiêu của tôi là có thể đọc một hoặc hai cuốn sách mỗi tuần, và hiện tại tôi đang ở mức khoảng 0,5 cuốn. Danh sách tồn đọng khá lớn. Tôi nghĩ có rất nhiều điều chúng ta có thể học hỏi từ lịch sử và rất nhiều điều mà tôi chưa hiểu rõ như tôi mong muốn. Chẳng hạn tôi không biết gì về vật lý, hay robotics, hay bất kỳ phần cứng nào, hay hàng không vũ trụ. Có quá nhiều chủ đề thú vị. Vì vậy, tôi rất hào hứng học hỏi, ngay cả khi biết rằng trí tuệ nhân tạo (AI) sẽ đã biết tất cả những điều đó rồi.

Liên hệ và Phản hồi từ người dùng

Cat, thật tuyệt vời. Bạn thật tuyệt vời. Hai câu hỏi tiếp theo: Mọi người có thể tìm bạn ở đâu trực tuyến nếu họ muốn liên hệ và theo dõi những gì bạn đang làm? Và thính giả có thể hữu ích với bạn bằng cách nào?

Cách tốt nhất để liên hệ là qua Catwoo trên Twitter. Cứ thoải mái gắn thẻ (tag) tôi vào các bài đăng. Cứ thoải mái gửi tin nhắn trực tiếp (DM) cho tôi. Tôi đọc tất cả các DM của mình. Tôi không phải lúc nào cũng trả lời từng tin nhắn, nhưng tôi sẽ đọc tất cả. Và điều hữu ích nhất là hãy cho chúng tôi biết Claude Code và Co-Work không hoạt động tốt ở đâu đối với bạn. Chúng tôi rất biết ơn những phản hồi tích cực. Nhưng những điều chúng tôi phát triển mạnh mẽ là các trường hợp biên (edge case), lỗi (error), ví dụ như các tác vụ cụ thể mà chúng tôi có thể tái tạo khi Claude Code hoặc Co-Work thất bại. Bởi vì nếu bạn có thể chia sẻ điều đó với chúng tôi và chúng tôi có thể tái tạo lại nó, thì đây là điều chúng tôi có thể chủ động cải thiện cho các thế hệ mô hình tiếp theo và cho các hệ thống (harnesses) tiếp theo của chúng tôi.

Thật tuyệt vời. Mọi người trên Twitter không ngại chia sẻ phản hồi này. Vì vậy, hãy tiếp tục gửi đến nhé. Làm ơn, xin hãy chia sẻ những vấn đề bạn đang gặp phải với chúng tôi.

Vâng. Và thật tuyệt vời khi thấy đội ngũ của bạn rất tích cực trên Twitter và phản hồi mọi người. Vì vậy, điều tôi nghe được là những điều này thực sự được các bạn thấy và phản ứng. Vâng, chúng tôi rất trân trọng việc mọi người tương tác tích cực với chúng tôi. Điều đó mang lại rất nhiều năng lượng cho đội ngũ. Chúng tôi có một kênh gọi là 'tình yêu của người dùng' và bất cứ khi nào các bạn chia sẻ một câu chuyện thành công, chúng tôi sẽ đăng nó lên đó. Còn khi các bạn chia sẻ các vấn đề với sản phẩm của chúng tôi, chúng tôi sẽ đưa nó vào kênh phản hồi của mình. Bằng cách đó, đội ngũ lớn hơn của chúng tôi có thể hành động dựa trên nó.

Thật tuyệt vời khi biết điều đó. Cảm ơn bạn đã chia sẻ. Vâng, Cat, cảm ơn bạn rất nhiều vì đã có mặt ở đây. Cảm ơn vì đã mời tôi. Tạm biệt mọi người. Cảm ơn rất nhiều vì đã lắng nghe. Nếu bạn thấy chương trình này có giá trị, bạn có thể đăng ký theo dõi trên Apple Podcasts, Spotify hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, hãy cân nhắc đánh giá hoặc để lại nhận xét vì điều đó thực sự giúp những thính giả khác tìm thấy podcast. Bạn có thể tìm tất cả các tập trước hoặc tìm hiểu thêm về chương trình tại lennispodcast.com. Hẹn gặp lại trong tập tiếp theo.

TL;DR

Trong kỷ nguyên AI và AGI, tốc độ triển khai sản phẩm là yếu tố sống còn, đòi hỏi PM phải tập trung vào việc lặp lại và ra mắt tính năng nhanh chóng, đôi khi chỉ trong vài ngày thay vì hàng tháng.
Anthropic đã đạt được tốc độ triển khai sản phẩm cực nhanh bằng cách loại bỏ rào cản, đặt mục tiêu rõ ràng, sử dụng "phiên bản xem trước nghiên cứu" và thiết lập quy trình liên chức năng chặt chẽ.
Vai trò của PM đang thay đổi, ít nhấn mạnh vào lộ trình dài hạn mà chuyển sang tạo điều kiện cho các nhóm di chuyển nhanh, định nghĩa rõ ràng về thành công và trao quyền tự chủ cho các kỹ sư.

Điểm chính

Ưu tiên tốc độ lặp lại: Các PM cần tìm cách rút ngắn thời gian từ ý tưởng đến tay người dùng, phấn đấu ra mắt tính năng mỗi tuần, hoặc thậm chí nhanh hơn đối với các sản phẩm thuần AI.
Đặt mục tiêu rõ ràng cho LLM: Với sự tổng quát của các mô hình ngôn ngữ lớn (LLM), PM cần xác định cụ thể người dùng chính, vấn đề cần giải quyết và các trường hợp sử dụng hàng đầu để giảm sự mơ hồ.
Áp dụng quy trình triển khai lặp lại: Sử dụng "phiên bản xem trước nghiên cứu" (research preview) để đưa sản phẩm ra thị trường nhanh chóng, thu thập phản hồi sớm và giảm cam kết ban đầu, cho phép lặp lại liên tục.
Thiết lập khung sườn liên chức năng chặt chẽ: Tạo quy trình rõ ràng giữa kỹ thuật, tiếp thị, tài liệu và quan hệ nhà phát triển để giảm ma sát trong quá trình ra mắt, giúp đội ngũ kỹ thuật triển khai tính năng một cách suôn sẻ.
Duy trì sự đồng bộ qua chỉ số và nguyên tắc: Thực hiện các báo cáo chỉ số (metric readouts) hàng tuần và thiết lập các nguyên tắc nhóm rõ ràng giúp mọi thành viên hiểu sâu về hoạt động kinh doanh và đưa ra quyết định tự chủ.
PM vẫn cần thiết: Dù code trở nên rẻ hơn, việc quyết định "nên viết gì" vẫn cực kỳ có giá trị. PM cần tập trung vào việc định hình tầm nhìn sản phẩm, xác định lộ trình ngắn hạn và dài hạn (đặc biệt cho hạ tầng nặng).
Tận dụng lợi thế mô hình tiên tiến: Việc Anthropic có quyền truy cập và sử dụng các mô hình nội bộ mạnh mẽ góp phần tăng tốc độ triển khai, nhưng quy trình và quyền tự chủ của đội ngũ là yếu tố chính.

Từ vựng

AGI (Artificial General Intelligence) — Trí tuệ tổng hợp nhân tạo
PM (Product Manager) — Quản lý Sản phẩm
AI-native products — sản phẩm thuần AI
Cross-functional — liên chức năng
LLM (Large Language Model) — mô hình ngôn ngữ lớn
Use case — trường hợp sử dụng
Research preview — phiên bản xem trước nghiên cứu
PRD (Product Requirements Document) — Tài liệu Yêu cầu Sản phẩm
Metric — chỉ số
Frontier models — mô hình tiên tiến

Nội dung chi tiết

Tầm nhìn về `AGI` và Tốc độ Triển khai Sản phẩm

>> Tôi chưa từng thấy tốc độ nào như cách các bạn ở Anthropic đang triển khai sản phẩm.

>> Bạn nghĩ những kỹ năng mới nổi nào mà các PM cần phát triển?

Điều đó quay trở lại gu sản phẩm. Khi việc viết code trở nên rẻ hơn rất nhiều, điều trở nên có giá trị hơn là quyết định nên viết gì.

>> Cảm ơn vì đã mời tôi.

Vai trò `PM` tại Anthropic và cách hợp tác với Boris

Tài trợ bởi WorkOS

Vai trò `PM` trong `AI` đang thay đổi

Tốc độ phát triển sản phẩm `AI`

Chiến lược triển khai sản phẩm nhanh chóng

`PRD` và sự đồng bộ trong nhóm

Sự cần thiết của `PM` trong kỷ nguyên `AI`

Mô hình `Mythos` và tốc độ phát triển của Anthropic

Quy trình và Quyền tự chủ của Đội ngũ

Tuyệt vời. Thật là một lợi thế khi vừa có mô hình tốt nhất, vừa đang xây dựng sản phẩm. Thật tuyệt vời.

Chúng tôi rất may mắn khi có thể làm việc với các Frontier models.

Ôi trời ơi, thật là một lợi thế tuyệt vời. Chỉ cần xây dựng một thứ, sau đó sử dụng nó và tăng tốc nhanh hơn. Thật thú vị.

Sự cố rò rỉ mã nguồn Claude Code

Ngay lập tức khi phát hiện, chúng tôi đã điều tra. Chúng tôi nhận ra đây là hậu quả của lỗi con người. Có một người đang làm việc với Claude để viết một PR (Pull Request). Đây chỉ là một bản cập nhật về cách chúng tôi phát hành các gói phần mềm và nó thực sự đã trải qua hai lớp xem xét của con người. Vì vậy, đây là kết quả của lỗi con người và chúng tôi đã tăng cường các quy trình của mình để đảm bảo điều đó không xảy ra trong tương lai.

Người này vẫn còn ở Anthropic chứ? Họ đang làm đúng chứ?

Vâng, đúng vậy. Đó là một lỗi quy trình và điều quan trọng nhất là học hỏi từ nó và bổ sung thêm các biện pháp bảo vệ để điều đó không xảy ra lần nữa. Và đó là những gì chúng tôi đang tập trung, hầu hết các biện pháp đó đã được triển khai.

Claude và Thay đổi chính sách đăng ký Open Claude

Chúng tôi đã nhận thấy nhu cầu rất lớn đối với Claude và đã làm việc rất chăm chỉ để vừa mở rộng cơ sở hạ tầng của mình, vừa làm cho harness của chúng tôi hiệu quả hơn về token để bạn có thể sử dụng nhiều hơn. Nó không được thiết kế cho các sản phẩm bên thứ ba có các mô hình sử dụng khác với các sản phẩm của bên thứ nhất của chúng tôi. Chúng tôi đã dành nhiều thời gian để tìm ra quá trình chuyển đổi liền mạch nhất mà chúng tôi có thể cung cấp. Và tôi rất vui khi có thể thông báo rằng mọi người đều nhận được một số tín dụng cùng với gói đăng ký của họ. Nhưng vâng, chúng tôi đã phải đưa ra quyết định khó khăn là cần ưu tiên các sản phẩm của bên thứ nhất và API của chúng tôi. Và đây là một quyết định phát sinh từ đó.

Cấu trúc đội ngũ PM tại Anthropic

Trở lại với đội ngũ quản lý sản phẩm (PM), đội ngũ PM tại Anthropic trông như thế nào? Có bao nhiêu PM? Họ được tổ chức ra sao?

Vâng, chúng tôi có một vài đội PM. Tôi nghĩ hiện tại chúng tôi có khoảng 30 hoặc 40 PM. Chúng tôi có đội PM nghiên cứu do Diane dẫn dắt, đội này chịu trách nhiệm thu thập tất cả phản hồi từ khách hàng về các mô hình của chúng tôi, sau đó chuyển cho đội nghiên cứu tốt nhất để họ hành động, và họ cũng quản lý quá trình ra mắt mô hình. Có đội nền tảng nhà phát triển Claude duy trì các API mà Claude Code được xây dựng trên đó, và họ cũng phát hành những thứ như Managed Agents – một cách để bạn xây dựng tác nhân AI của mình và chúng tôi có thể lưu trữ chúng thay mặt bạn. Và sau đó có Claude Code làm việc trên cả Claude Code và các sản phẩm cốt lõi Co-work. Có đội doanh nghiệp (Enterprise) giúp Claude Code và Co-work dễ dàng được các khách hàng doanh nghiệp của chúng tôi áp dụng hơn. Và điều này bao gồm mọi thứ từ kiểm soát chi phí, RBAC (Role-Based Access Control), kiểm soát bảo mật và đảm bảo các doanh nghiệp này cảm thấy rất tự tin và thoải mái khi sử dụng công cụ của chúng tôi. Và sau đó chúng tôi cũng có đội phát triển (growth team) chịu trách nhiệm phát triển trên toàn bộ bộ sản phẩm của chúng tôi. Vì vậy, chúng tôi làm việc rất chặt chẽ với họ về sự phát triển của Claude Code và Co-work, và tôi biết họ cũng làm việc với các đội khác của chúng tôi về sự phát triển của CDP (Claude Developer Platform), tức là sự phát triển của những người sử dụng API của Claude.

Sự hòa nhập vai trò của PM và Kỹ sư

Và nền tảng của bạn là kỹ thuật phải không?

Vâng, tôi là một kỹ sư trong nhiều năm. Sau đó tôi làm VC (quỹ đầu tư mạo hiểm) một thời gian rất ngắn trước khi gia nhập Anthropic. Và thực ra, hầu hết các PM trong đội ngũ của chúng tôi đều đã từng là kỹ sư hoặc đã triển khai mã nguồn tại Claude Code. Và đó là một trong những điều tôi nghĩ giúp xây dựng lòng tin với đội ngũ và cũng giúp chúng tôi di chuyển nhanh hơn rất nhiều. Và thực ra, các nhà thiết kế của chúng tôi cũng từng là kỹ sư front-end trước đây.

Chà, vì đó là câu hỏi lớn. Chắc chắn có sự hòa nhập đang diễn ra, các biểu đồ Venn đang kết hợp. Tôi nghĩ câu hỏi lớn đối với nhiều người là nếu bạn đến từ kỹ thuật, sản phẩm hay thiết kế, kỹ năng cốt lõi nào trong số đó sẽ có giá trị nhất? Tôi có thể thấy ở Anthropic và trên Claude Code, kỹ thuật rất có giá trị. Tôi tò mò liệu ở các công ty khác, nếu bạn có nền tảng thiết kế, việc trở thành một PM có giá trị hơn hay chỉ là một PMP.

Giá trị của Gu sản phẩm và Nền tảng Kỹ thuật

Bạn nói "trong vài tháng tới"; có phải vì các mô hình có thể sẽ trở nên rất tốt trong vài tháng tới? Bạn có thể không cần biết nhiều điều đó nữa.

Tôi nghĩ các bộ kỹ năng được đánh giá cao thay đổi khá thường xuyên, và vì vậy rất khó để dự đoán xa hơn vài tháng. Vì vậy, đây ít hơn là một bình luận về sự thay đổi mà tôi nghĩ sẽ xảy ra, và nhiều hơn là một bình luận rằng tôi nghĩ những thay đổi lớn sẽ xảy ra.

Vậy bạn không nói rằng đó là khi Mythos ra mắt và sẽ thay đổi mọi thứ, và chúng ta không cần biết bất cứ điều gì về kỹ thuật?

Không, tôi chỉ nói rằng cứ vài tháng dường như lại có một sự gia tăng lớn trong khả năng lập trình, điều này sau đó thay đổi những vai trò khác có giá trị. Tôi nghĩ điều quan trọng nhất là có được tư duy nguyên tắc đầu tiên này, nơi bạn có thể tìm ra cách cảnh quan công nghệ đang thay đổi, đội ngũ thực sự cần gì từ bạn, và nhảy vào để khắc phục lỗ hổng đó. Bởi vì tôi nghĩ công việc đang trở nên vô định hình hơn, có nghĩa là một PM giỏi có thể hiểu tất cả các khoảng trống là gì, để tìm ra những cái nào có ưu tiên cao nhất, và sau đó chỉ cần tìm ra, "Được rồi, làm thế nào để tôi học bộ kỹ năng đó hoặc bộ kỹ năng tôi có thể áp dụng cho thử thách này là gì?" Vì vậy, tôi nghĩ môi trường hiện tại coi trọng những người có khả năng đảm nhiệm nhiều vai trò, có khả năng chuyển đổi vai trò, và có cái tôi thấp về công việc họ làm để giúp đội ngũ di chuyển nhanh hơn.

Giá trị của Trí tuệ con người trong kỷ nguyên AI

Tôi nghĩ con người vẫn cung cấp một mức độ nhận thức chung mà các mô hình không có. Và có hàng nghìn yếu tố chuyển động trong bất kỳ lần ra mắt sản phẩm nào. Một số rất nhỏ, nhưng luôn có rất nhiều điều có thể đi sai. Tôi nghĩ mô hình không phải lúc nào cũng hiểu rõ tất cả các bên liên quan là ai, họ liên hệ với nhau như thế nào, sở thích của họ là gì, đâu là các kênh phù hợp để giao tiếp với họ nhằm giữ họ tham gia. Tôi nghĩ rất nhiều kiến thức nhận thức chung mang tính ngầm, như loại EQ (Chỉ số cảm xúc), vẫn rất có giá trị. Tất nhiên, chúng tôi muốn các mô hình trở nên tốt hơn ở điều này và tôi nghĩ chúng sẽ như vậy, nhưng hiện tại tôi nghĩ vẫn còn những khoảng trống.

Đối phó với sự thay đổi không ngừng

Tôi nghĩ đội ngũ của chúng tôi toàn những người chấp nhận thử thách. Vì vậy, chúng tôi cố gắng đối mặt với mọi thử thách bằng nụ cười vì luôn có rất nhiều điều đang xảy ra.

Năng lực cốt lõi: Bình tĩnh và Lạc quan

Vâng, mọi thứ chắc chắn sẽ khó khăn hơn. Ví dụ, tôi cảm thấy có nhiều tuần mà có thể tối Chủ Nhật có một vấn đề P0 (ưu tiên cao nhất), rồi đến sáng Thứ Hai lại có một P0, và đến chiều Thứ Hai lại có một P0000 (ưu tiên cực kỳ cao), và bạn sẽ nghĩ, "Wow, không thể tin được là mình đã lo lắng về P0 đó từ Chủ Nhật." Nhưng tôi nghĩ bạn chỉ cần thừa nhận rằng bạn chỉ có thể làm được chừng đó, rằng bạn cần ngủ đủ giấc để có thể đưa ra những quyết định tốt vào ngày hôm sau và chỉ cần ưu tiên một cách triệt để nơi bạn dành thời gian của mình. Điều gì là quan trọng nhất để làm đúng? Và hãy chấp nhận bỏ qua một số thứ. Ví dụ, có những sản phẩm chúng tôi đã phát hành mà không được hoàn thiện như tôi mong muốn. Nhưng, mục tiêu hàng đầu của chúng tôi là giúp trao quyền cho các developer chuyên nghiệp. Và nếu một sản phẩm không thành công, miễn là nó không chặn trường hợp sử dụng cốt lõi, thì không sao cả, bởi vì chúng tôi sẽ lắng nghe phản hồi và sẽ khắc phục trong bản phát hành tiếp theo. Việc ra mắt một tính năng có lỗi là điều từng khiến tôi mất ngủ. Nhưng đó là điều mà giờ đây tôi có thể chấp nhận, biết rằng, "Được thôi, chúng ta sẽ nhận được phản hồi nhanh chóng và chúng ta sẽ khắc phục nó trong bản phát hành tiếp theo."

Vâng, tôi nghĩ đó là một cái nhìn sâu sắc thực sự thú vị—đó là việc có sự điềm tĩnh và lạc quan này thay vì chỉ nói, "Ôi trời ơi, mọi thứ thật điên rồ và đang loạn hết lên." Vâng, tôi nghĩ nếu bạn không có điều đó, bạn sẽ khá kiệt sức. Tôi nghĩ chúng tôi cũng có xu hướng tuyển dụng những người đã ở trong ngành một thời gian và đã trải qua nhiều thăng trầm, và có cảm nhận tốt về những gì mang lại năng lượng cho họ và cách duy trì năng lượng theo thời gian, và tôi nghĩ điều đó đã giúp ích cho chúng tôi rất nhiều.

Đánh đổi về tính nhất quán sản phẩm và trải nghiệm người dùng

Chúng tôi đang hy sinh tính nhất quán của sản phẩm. Trong lịch sử, khi việc viết mã (code) tốn kém, bạn sẽ cẩn thận lập kế hoạch mọi thứ trong bộ sản phẩm (product suite) của mình: cách mỗi sản phẩm liên quan đến nhau, trường hợp sử dụng của từng sản phẩm, cách chúng tích hợp. Và bạn gần như sẽ có một sản phẩm cho mỗi trường hợp sử dụng. Còn bây giờ, với trí tuệ nhân tạo (AI) phát triển rất nhanh và với rất nhiều ý tưởng cần thử nghiệm, đôi khi chúng tôi có các tính năng chồng chéo lẫn nhau. Phần lớn thời gian là vì có hai kiểu dáng thiết bị (form factors) mà chúng tôi yêu thích nội bộ, và chúng tôi muốn khán giả bên ngoài cho chúng tôi biết cái nào tốt hơn. Tuy nhiên, điều đó có nghĩa là đối với một người dùng mới, họ có thể không biết, "Được rồi, đâu là con đường tốt nhất để hoàn thành X?" Chúng tôi cần cung cấp thêm thông tin giáo dục để giúp mọi người hiểu các tính năng cốt lõi là gì và các phương pháp hay nhất để sử dụng chúng.

Vâng, tôi thấy bạn đã ra mắt một tính năng thực sự thú vị gần đây. Tôi nghĩ đó là /powerup, nơi nó hướng dẫn bạn tất cả các cách hay ho và về cơ bản là tất cả các phương pháp hay nhất để sử dụng Claude Code. Có phải điều đó cũng nằm trong những định hướng này không?

Vâng, chính xác. Trong quá khứ, chúng tôi thực sự không muốn làm một thứ gì đó như PowerUp vì chúng tôi cảm thấy sản phẩm nên đủ trực quan để bạn không cần phải trải qua bất kỳ hướng dẫn nào. Và theo thời gian, chúng tôi nhận ra rằng có quá nhiều tính năng và có quá nhiều nhu cầu về một trải nghiệm giới thiệu tích hợp (built-in onboarding experience) nên chúng tôi đã hơi đi chệch khỏi nguyên tắc ban đầu là không có quy trình giới thiệu (onboarding flow) và đã thêm tính năng này vì có quá nhiều người dùng muốn biết, "Có 100 tính năng. Đâu là 10 tính năng tôi nhất định phải sử dụng?" Và vì vậy chúng tôi đã cùng nhau xây dựng nó.

Công thức thành công của Anthropic: Sứ mệnh và Sự tập trung

Hai điều quan trọng nhất là: thứ nhất, sứ mệnh thống nhất này. Khó có thể nói hết được tầm quan trọng của nó. Chúng tôi tuyển dụng những người quan tâm nhất đến việc mang AGI (Trí tuệ nhân tạo tổng quát) an toàn đến cho toàn nhân loại. Và đây thực sự là điều chúng tôi thường xuyên tham khảo trong các quyết định về việc toàn bộ sản phẩm hoặc tổ chức của chúng tôi nên tập trung vào việc phát hành cái gì. Và bởi vì chúng tôi đặt sứ mệnh này lên trên bất kỳ dòng sản phẩm (product line) riêng lẻ nào, chúng tôi có thể đưa ra các quyết định rất nhanh chóng, bao trùm toàn bộ tổ chức (org) và thực hiện chúng một cách thống nhất. Vì vậy, tôi nghĩ đây là điều mà tôi chưa từng thấy ở một công ty có quy mô như của chúng tôi.

Và vậy, để làm rõ điều đó. Về cơ bản, sứ mệnh số một là căn chỉnh an toàn (safety alignment), đảm bảo trí tuệ nhân tạo (AI) tốt cho thế giới. Và bạn đang nói rằng việc có một sứ mệnh rõ ràng như vậy sẽ giúp việc đưa ra quyết định dễ dàng hơn rất nhiều.

Nếu có hai ưu tiên cạnh tranh, chúng tôi sẽ thảo luận xem ưu tiên nào quan trọng hơn đối với sứ mệnh của Anthropic. Và điều đó giúp việc quyết định ưu tiên cái nào trong hai điều đó dễ dàng hơn rất nhiều. Sau đó, mọi người sẽ ủng hộ quyết định mà chúng tôi đưa ra. Và đôi khi điều đó có nghĩa là, "Này, chúng tôi muốn phát hành một cái gì đó trên Claude Code, nhưng điều khác quan trọng hơn." Và vì vậy chúng tôi hạ thấp ưu tiên phát hành cái này và chúng tôi chỉ đợi đến sau này. Điều thực sự thú vị về điều đó là nó giải thích, tôi nghĩ, so với một công ty khác (có lẽ là OpenAI), đã làm rất nhiều điều khác nhau. Và điều tôi đang nghe ở đây về cơ bản là, "Được thôi, chúng tôi sẽ không ra mắt mạng xã hội (social network); chúng tôi sẽ không ra mắt một nguồn cấp dữ liệu thông tin thú vị vì nó không phù hợp với sứ mệnh này." Và điều đó đã giúp Anthropic tập trung, dường như là một thành phần cốt lõi cho sự thành công.

Chà, khi tôi nghĩ về sứ mệnh, tôi nghĩ về việc đặt mục tiêu của Anthropic lên trước bất kỳ cá nhân hay bất kỳ sản phẩm riêng lẻ nào. Và vì vậy, đối với tôi, tôi nghĩ điều thứ hai mà chúng tôi rất giỏi là sự tập trung (focus). Tôi nghĩ sứ mệnh đối với tôi hơi khác một chút. Sứ mệnh có nghĩa là các đội sẵn sàng hy sinh những điều làm tổn hại đến mục tiêu và KR (Key Results) của chính họ để phục vụ mục tiêu và KR của Anthropic. Và mọi người rất vui khi thực hiện những đánh đổi (trade-off) đó. Ví dụ cực đoan là nếu Claude Code thất bại nhưng Anthropic thành công, tôi sẽ cực kỳ hạnh phúc, và toàn bộ đội ngũ rất sẵn lòng đưa ra những quyết định tuân theo chuỗi suy nghĩ đó.

Tôi không biết liệu bạn có thể nói sâu về điều này không, nhưng bạn có cảm thấy quyết định về Open Claude là một phần của điều này không, kiểu như, "Được rồi, điều này không thúc đẩy sứ mệnh của Anthropic; chúng ta cần dừng lại vì nó không hoạt động theo cách chúng ta muốn." Tôi nghĩ một trong những điều quan trọng nhất đối với Anthropic là tăng số lượng người dùng mà chúng tôi có thể tiếp cận. Một trong những cách chúng tôi có thể làm điều này là với các đăng ký Claude (Claude subscriptions) với sản phẩm bên thứ nhất (first-party products) của chúng tôi, và vì vậy chúng tôi thực sự muốn tập trung hơn (double down) vào điều đó, nhưng đôi khi điều đó lại phải đánh đổi bằng sản phẩm bên thứ ba (third-party products).

Hướng dẫn sử dụng các công cụ Claude, Desktop và Co-work

Vậy, tôi thường dùng Claude Code trong terminal khi tôi chỉ thực hiện một tác vụ lập trình (coding task) một lần và muốn có tất cả các tính năng mới nhất. CLI (Giao diện dòng lệnh) là bề mặt sản phẩm (product surface) ban đầu của chúng tôi và cũng là nơi các tính năng của chúng tôi thường xuất hiện trước tiên, vì vậy nó là công cụ mạnh nhất trong tất cả các công cụ. Đó là những gì tôi thường dùng khi tôi chỉ cố gắng khởi tạo một hoặc có thể một vài tác vụ cùng một lúc. Tôi nghĩ Desktop thực sự tỏa sáng khi bạn làm việc đòi hỏi front-end (phát triển giao diện người dùng). Và một điều tôi thích làm là sử dụng tính năng xem trước (preview feature) của chúng tôi. Vì vậy, nếu tôi đang xây dựng một ứng dụng web (web app), tôi thường sẽ sử dụng Claude Code và Desktop. Tôi sẽ mở khung xem trước (preview pane) ở bên phải để tôi có thể thực sự xem ứng dụng web mà tôi đang tạo trong thời gian thực khi tôi trò chuyện với Claude. Nó cũng rất tuyệt vời cho những người muốn thứ gì đó trực quan hơn một chút. Một terminal có thể cảm thấy rất xa lạ với một người không chuyên về kỹ thuật (non-technical). Bạn nhận được một loạt các cửa sổ bật lên (popup) đáng sợ trên máy của mình và bạn không thể nhấp chuột theo cách bạn đã quen thuộc trong hầu hết các sản phẩm khác mà bạn sử dụng. Vì vậy, có rất nhiều người chỉ đơn giản là không cảm thấy thoải mái trong terminal. Và nếu bạn là người như vậy, tôi thực sự khuyên bạn nên thử Claude Code trên Desktop. Desktop cũng rất tuyệt để có được cái nhìn tổng quan (at-a-glance view) về mọi thứ đang diễn ra. Vì vậy, bạn có thể xem các phiên terminal CLI của mình trong Desktop. Bạn có thể xem các phiên Desktop khác của mình. Bạn có thể xem các phiên bạn đã khởi tạo trên web và thiết bị di động (mobile). Vì vậy, nó là một trung tâm điều khiển duy nhất (one-stop control plane) nơi bạn có thể xem tất cả các tác vụ của mình. Tôi nghĩ lợi ích của web và thiết bị di động là nó thực sự tuyệt vời để khởi tạo mọi thứ khi đang di chuyển. Vì vậy, CLI và Desktop đều yêu cầu bạn phải sử dụng máy tính xách tay cục bộ (local laptop) của mình.

Năng Suất Di Động và Tác Nhân AI

`Co-work` trong Thực Tiễn: Sinh Ra `Slide Deck`

Điều này nghe có vẻ như một giấc mơ thành hiện thực đối với các quản lý sản phẩm (PM) vì việc tạo ra các bản trình bày (deck) thật phiền phức.

Nó quá chậm.

Tạo `Slide Deck` Bằng `Prompt`

Được rồi. Và sau đó câu lệnh/lời nhắc (prompt) bạn đã nhập để tạo bản trình bày này là gì?

Tận Dụng `Hệ Thống Thiết Kế`

Cho một ví dụ. Hiểu rồi. Vậy bạn tải lên "đây là template của chúng tôi, hãy làm việc từ đây."

Đúng vậy. Bạn cũng có thể kết nối với Figma MCP của bạn nếu bạn đã lưu định dạng slide của mình ở đó và nó có thể kéo dữ liệu đó vào.

Bộ Công Cụ Cá Nhân và Ứng Dụng `AI` Nội Bộ

Tôi muốn nghe thêm. Một vài ví dụ là gì? Những thứ bạn đã xây dựng hoặc người khác đã xây dựng mà thực sự phổ biến và hữu ích?

Vai Trò Bền Vững của `Slack`

Tin nhắn Nhà tài trợ: Vanta

Quảng cáo: Giải pháp tuân thủ và quản lý rủi ro Vanta

Các đội ngũ sử dụng `token` nhiều nhất (ngoài Kỹ sư)

Vai trò của đội ngũ AI ứng dụng

Hiểu rồi. Vậy nó giống như kiểu hỗ trợ khách hàng theo hướng tiếp cận thị trường (Go-to-Market), giống một kiểu kỹ sư triển khai?

Chính xác. Đó giống như một người làm tiếp cận thị trường (Go-to-Market) rất có chuyên môn kỹ thuật.

Các trường hợp sử dụng `Co-work` trong AI ứng dụng

Hiểu rồi. Tuyệt vời. Vậy anh đang nói rằng đó có thể là bộ phận thứ hai sử dụng nhiều token nhất.

Chi phí `token` so với `lương` và xu hướng tăng

Giới hạn `token` nội bộ và việc sử dụng có trách nhiệm tại Anthropic

Chúng tôi có thể sử dụng rất nhiều token. Một số người vẫn gặp phải giới hạn.

Các `kỹ năng` mới nổi cho `quản lý sản phẩm` trong các công ty `AI`

Cách xây dựng `kỹ năng` hiểu mô hình

Tầm quan trọng của `evals` trong `quản lý sản phẩm`

Những người giỏi nhất trong việc đánh giá mô hình

Có ai cụ thể mà anh muốn nhắc đến là rất giỏi trong việc này không?

Dữ liệu và tầm quan trọng của tính cách `AI`

Giá trị của tính cách `AI` trong công việc

Thích nghi với `LLM` mới

Đơn giản hóa sản phẩm khi `LLM` thông minh hơn

Khi `LLM` phát triển, `harness` trở nên dư thừa

Mở khóa tính năng mới với `LLM` tiên tiến

Chiến lược phát triển sản phẩm đón đầu công nghệ

Xây dựng `prototype` và kiểm thử với `LLM` mới

Tầm nhìn tương lai của Claude và `Co-Work`: Từ nhiệm vụ đơn lẻ đến hệ thống tác vụ phức tạp

Lời khuyên `lộ trình sự nghiệp` trong kỷ nguyên `AI`

Tận dụng `AI` để tối ưu `năng suất` và đổi mới

Tìm kiếm vấn đề để giải quyết bằng `AI`

Tự Động Hóa 100%: Giá Trị Thực Sự

Thử Nghiệm Tự Động Hóa Cá Nhân: Bài Học Về Sự Hoàn Hảo

Tôi hoàn toàn mắc lỗi đó. Đây là lời khuyên rất hay dành cho tôi.

Đơn Giản Hóa Tùy Chỉnh Tự Động Hóa

Xây Dựng Ứng Dụng AI Hữu Ích, Không Chỉ Prototype

...cho ngày của bạn.

Và bạn không nhận được nhiều leverage từ nó.

Và leverage thực sự. Đúng vậy, đó là một điểm rất hay.

Cân Bằng Giữa Tùy Chỉnh và Mục Tiêu Cốt Lõi

Tôi nghĩ những thiết lập đơn giản thực sự hoạt động tốt hơn.

[transcript bị gián đoạn] level up một chút.

Vâng. Vâng.

Từ AI Dựa Trên Chat Đến AI Dựa Trên Hành Động

Chính xác.

Lightning Round: Sách Khuyên Đọc

Được rồi. Còn gì nữa không trước khi chúng ta đến với phần lightning round rất thú vị của chúng ta?

Không, làm thôi!

Tôi sẵn sàng! Câu hỏi đầu tiên, hai hoặc ba cuốn sách nào mà bạn thường xuyên giới thiệu cho người khác nhất?

Phim/Chương Trình TV Yêu Thích: Sự Tập Trung Tuyệt Đối

Bộ phim hoặc chương trình TV gần đây yêu thích mà bạn thực sự đã thưởng thức là gì?

Thật điên rồ. Phải, bộ phim đó thật ngoài tầm kiểm soát. Và thật thú vị khi những điều này bằng cách nào đó lại liên quan đến công việc bạn làm.

...với dây thừng.

Với dây thừng.

Bạn có xem bộ phim tài liệu về người kia, người trẻ hơn leo núi băng không?

Tôi có. Bộ đó rất buồn.

Nhưng bộ đó thật hoang dại. Được rồi.

Sản Phẩm Yêu Thích: Waymo và Năng Suất Cá Nhân

Sản phẩm yêu thích bạn mới khám phá mà bạn thực sự yêu thích là gì?

Tất cả những hiệu ứng cấp hai này của công nghệ. Thật thú vị.

Vâng. Tôi luôn nghĩ Waymo cần có giá thấp hơn Uber và Lyft để thành công, nhưng thực ra tôi rất vui khi trả mức giá cao gấp đôi cho nó.

Phương Châm Sống: "Cứ Làm Đi"

Được rồi, hai câu hỏi nữa. Bạn có một phương châm sống yêu thích mà bạn thường quay lại trong công việc hay cuộc sống không?

Cứ làm đi (Just do things).

Đúng vậy.

Bạn, bạn có thể chỉ cần làm mọi thứ, bất cứ ai đã nói điều đó.

Tầm nhìn về AGI và Tốc độ Triển khai Sản phẩm

Vai trò PM tại Anthropic và cách hợp tác với Boris

Tài trợ bởi WorkOS

Vai trò PM trong AI đang thay đổi

Tốc độ phát triển sản phẩm AI

Chiến lược triển khai sản phẩm nhanh chóng

PRD và sự đồng bộ trong nhóm

Sự cần thiết của PM trong kỷ nguyên AI

Mô hình Mythos và tốc độ phát triển của Anthropic

Quy trình và Quyền tự chủ của Đội ngũ

Sự cố rò rỉ mã nguồn Claude Code

Claude và Thay đổi chính sách đăng ký Open Claude

Cấu trúc đội ngũ PM tại Anthropic

Sự hòa nhập vai trò của PM và Kỹ sư

Giá trị của Gu sản phẩm và Nền tảng Kỹ thuật

Giá trị của Trí tuệ con người trong kỷ nguyên AI

Đối phó với sự thay đổi không ngừng

Năng lực cốt lõi: Bình tĩnh và Lạc quan

Đánh đổi về tính nhất quán sản phẩm và trải nghiệm người dùng

Công thức thành công của Anthropic: Sứ mệnh và Sự tập trung

Hướng dẫn sử dụng các công cụ Claude, Desktop và Co-work

Năng Suất Di Động và Tác Nhân AI

Co-work trong Thực Tiễn: Sinh Ra Slide Deck

Tạo Slide Deck Bằng Prompt

Tận Dụng Hệ Thống Thiết Kế

Bộ Công Cụ Cá Nhân và Ứng Dụng AI Nội Bộ

Vai Trò Bền Vững của Slack

Tin nhắn Nhà tài trợ: Vanta

Quảng cáo: Giải pháp tuân thủ và quản lý rủi ro Vanta

Các đội ngũ sử dụng token nhiều nhất (ngoài Kỹ sư)

Vai trò của đội ngũ AI ứng dụng

Các trường hợp sử dụng Co-work trong AI ứng dụng

Chi phí token so với lương và xu hướng tăng

Giới hạn token nội bộ và việc sử dụng có trách nhiệm tại Anthropic

Các kỹ năng mới nổi cho quản lý sản phẩm trong các công ty AI

Cách xây dựng kỹ năng hiểu mô hình

Tầm quan trọng của evals trong quản lý sản phẩm

Những người giỏi nhất trong việc đánh giá mô hình

Dữ liệu và tầm quan trọng của tính cách AI

Giá trị của tính cách AI trong công việc

Thích nghi với LLM mới

Đơn giản hóa sản phẩm khi LLM thông minh hơn

Khi LLM phát triển, harness trở nên dư thừa

Mở khóa tính năng mới với LLM tiên tiến

Chiến lược phát triển sản phẩm đón đầu công nghệ

Xây dựng prototype và kiểm thử với LLM mới

Tầm nhìn tương lai của Claude và Co-Work: Từ nhiệm vụ đơn lẻ đến hệ thống tác vụ phức tạp

Lời khuyên lộ trình sự nghiệp trong kỷ nguyên AI

Tận dụng AI để tối ưu năng suất và đổi mới

Tìm kiếm vấn đề để giải quyết bằng AI

Tự Động Hóa 100%: Giá Trị Thực Sự

Thử Nghiệm Tự Động Hóa Cá Nhân: Bài Học Về Sự Hoàn Hảo

Đơn Giản Hóa Tùy Chỉnh Tự Động Hóa

Xây Dựng Ứng Dụng AI Hữu Ích, Không Chỉ Prototype

Cân Bằng Giữa Tùy Chỉnh và Mục Tiêu Cốt Lõi

Từ AI Dựa Trên Chat Đến AI Dựa Trên Hành Động

Lightning Round: Sách Khuyên Đọc

Phim/Chương Trình TV Yêu Thích: Sự Tập Trung Tuyệt Đối

Sản Phẩm Yêu Thích: Waymo và Năng Suất Cá Nhân

Phương Châm Sống: "Cứ Làm Đi"

Khả năng tự quyết và Ranh giới làm việc tại Startup

"Từ khóa tư duy" của Claude

Cuộc sống sau AGI (Trí tuệ tổng quát nhân tạo)

Liên hệ và Phản hồi từ người dùng

TL;DR

Điểm chính

Từ vựng

Nội dung chi tiết

Tầm nhìn về AGI và Tốc độ Triển khai Sản phẩm

Vai trò PM tại Anthropic và cách hợp tác với Boris

Tài trợ bởi WorkOS

Vai trò PM trong AI đang thay đổi

Tốc độ phát triển sản phẩm AI

Chiến lược triển khai sản phẩm nhanh chóng

PRD và sự đồng bộ trong nhóm

Sự cần thiết của PM trong kỷ nguyên AI

Mô hình Mythos và tốc độ phát triển của Anthropic

Quy trình và Quyền tự chủ của Đội ngũ

Sự cố rò rỉ mã nguồn Claude Code

Claude và Thay đổi chính sách đăng ký Open Claude

Tầm nhìn về `AGI` và Tốc độ Triển khai Sản phẩm

Vai trò `PM` tại Anthropic và cách hợp tác với Boris

Vai trò `PM` trong `AI` đang thay đổi

Tốc độ phát triển sản phẩm `AI`

`PRD` và sự đồng bộ trong nhóm

Sự cần thiết của `PM` trong kỷ nguyên `AI`

Mô hình `Mythos` và tốc độ phát triển của Anthropic

`Co-work` trong Thực Tiễn: Sinh Ra `Slide Deck`

Tạo `Slide Deck` Bằng `Prompt`

Tận Dụng `Hệ Thống Thiết Kế`

Bộ Công Cụ Cá Nhân và Ứng Dụng `AI` Nội Bộ

Vai Trò Bền Vững của `Slack`

Các đội ngũ sử dụng `token` nhiều nhất (ngoài Kỹ sư)

Các trường hợp sử dụng `Co-work` trong AI ứng dụng

Chi phí `token` so với `lương` và xu hướng tăng

Giới hạn `token` nội bộ và việc sử dụng có trách nhiệm tại Anthropic

Các `kỹ năng` mới nổi cho `quản lý sản phẩm` trong các công ty `AI`

Cách xây dựng `kỹ năng` hiểu mô hình

Tầm quan trọng của `evals` trong `quản lý sản phẩm`

Dữ liệu và tầm quan trọng của tính cách `AI`

Giá trị của tính cách `AI` trong công việc

Thích nghi với `LLM` mới

Đơn giản hóa sản phẩm khi `LLM` thông minh hơn

Khi `LLM` phát triển, `harness` trở nên dư thừa

Mở khóa tính năng mới với `LLM` tiên tiến

Xây dựng `prototype` và kiểm thử với `LLM` mới

Tầm nhìn tương lai của Claude và `Co-Work`: Từ nhiệm vụ đơn lẻ đến hệ thống tác vụ phức tạp

Lời khuyên `lộ trình sự nghiệp` trong kỷ nguyên `AI`

Tận dụng `AI` để tối ưu `năng suất` và đổi mới

Tìm kiếm vấn đề để giải quyết bằng `AI`

Tầm nhìn về `AGI` và Tốc độ Triển khai Sản phẩm

Vai trò `PM` tại Anthropic và cách hợp tác với Boris

Vai trò `PM` trong `AI` đang thay đổi

Tốc độ phát triển sản phẩm `AI`

`PRD` và sự đồng bộ trong nhóm

Sự cần thiết của `PM` trong kỷ nguyên `AI`

Mô hình `Mythos` và tốc độ phát triển của Anthropic

`Co-work` trong Thực Tiễn: Sinh Ra `Slide Deck`

Tạo `Slide Deck` Bằng `Prompt`

Tận Dụng `Hệ Thống Thiết Kế`

Bộ Công Cụ Cá Nhân và Ứng Dụng `AI` Nội Bộ

Vai Trò Bền Vững của `Slack`

Các đội ngũ sử dụng `token` nhiều nhất (ngoài Kỹ sư)

Các trường hợp sử dụng `Co-work` trong AI ứng dụng

Chi phí `token` so với `lương` và xu hướng tăng

Giới hạn `token` nội bộ và việc sử dụng có trách nhiệm tại Anthropic

Các `kỹ năng` mới nổi cho `quản lý sản phẩm` trong các công ty `AI`

Cách xây dựng `kỹ năng` hiểu mô hình

Tầm quan trọng của `evals` trong `quản lý sản phẩm`

Dữ liệu và tầm quan trọng của tính cách `AI`

Giá trị của tính cách `AI` trong công việc

Thích nghi với `LLM` mới

Đơn giản hóa sản phẩm khi `LLM` thông minh hơn

Khi `LLM` phát triển, `harness` trở nên dư thừa

Mở khóa tính năng mới với `LLM` tiên tiến

Xây dựng `prototype` và kiểm thử với `LLM` mới

Tầm nhìn tương lai của Claude và `Co-Work`: Từ nhiệm vụ đơn lẻ đến hệ thống tác vụ phức tạp

Lời khuyên `lộ trình sự nghiệp` trong kỷ nguyên `AI`

Tận dụng `AI` để tối ưu `năng suất` và đổi mới

Tìm kiếm vấn đề để giải quyết bằng `AI`