Head of Claude Code: What happens after coding is solved | Boris Cherny

Trí tuệ nhân tạo (AI), đặc biệt là Claude Code, đang thay đổi cơ bản cách thức lập trình, cho phép các kỹ sư không cần viết mã thủ công và tăng năng suất lên đáng kể (ví dụ 200%).
Vai trò của kỹ sư phần mềm đang chuyển dịch từ người viết mã sang "người xây dựng" hoặc "quản lý sản phẩm," tập trung vào ý tưởng và thiết kế, trong khi AI đảm nhiệm các chi tiết triển khai và sửa lỗi.
Sự phát triển của AI trong lĩnh vực này diễn ra nhanh chóng một cách "cấp số nhân", với bằng chứng là tỷ lệ commit do AI tạo ra trên GitHub tăng vọt, cho thấy một sự thay đổi toàn diện trong ngành kỹ thuật phần mềm.

code — mã nguồn
AI — Trí tuệ nhân tạo
pull request — yêu cầu kéo
agent — tác nhân
năng suất — productivity
kỹ sư phần mềm — software engineer
quản lý sản phẩm — product manager
dữ liệu đo xa — telemetry data
commit — cam kết (trong Git)
tool use — sử dụng công cụ
prototype — nguyên mẫu
terminal — thiết bị đầu cuối
người dùng hoạt động hàng ngày (DAU) — daily active users (DAU)
nhu cầu tiềm ẩn — latent demand
tiện ích mở rộng IDE — IDE extension
phản hồi — feedback
kỹ thuật phần mềm — software engineering
cấp số nhân — exponential (growth)

Hiệu suất Lập trình với `AI`

— Boris Cherny: 100% code của tôi được viết bởi Claude Code. Kể từ tháng 11, tôi chưa từng chỉnh sửa một dòng nào bằng tay. Mỗi ngày, tôi gửi 10, 20, 30 pull request. Hiện tại, tôi có khoảng năm agent đang chạy trong khi chúng ta đang ghi âm cuộc trò chuyện này.

— Người dẫn chương trình: Vâng, vâng. Anh có nhớ việc viết code không?

— Boris Cherny: Tôi chưa bao giờ thích viết code nhiều như bây giờ, vì tôi không phải xử lý tất cả những chi tiết vụn vặt. Năng suất của mỗi kỹ sư đã tăng 200%.

— Người dẫn chương trình: Luôn có câu hỏi này: liệu tôi có nên học viết code không? Trong một hoặc hai năm nữa, điều đó sẽ không còn quan trọng. Việc viết code phần lớn đã được giải quyết. Tôi hình dung một thế giới nơi mọi người đều có thể lập trình. Bất cứ ai cũng có thể xây dựng phần mềm bất cứ lúc nào. Bước chuyển lớn tiếp theo về cách phần mềm được viết sẽ là gì?

Tương lai của Lập trình và Vai trò `Kỹ sư Phần mềm`

— Boris Cherny: Claude Code đang bắt đầu đưa ra ý tưởng. Nó đang xem xét phản hồi, các báo cáo lỗi, dữ liệu đo xa (telemetry) để sửa lỗi và các vấn đề cần triển khai, giống như một co-worker vậy.

— Người dẫn chương trình: Rất nhiều người nghe chương trình này là quản lý sản phẩm và họ có lẽ đang toát mồ hôi. Tôi nghĩ đến cuối năm nay, mọi người sẽ là quản lý sản phẩm và mọi người đều biết viết code. Chức danh kỹ sư phần mềm sẽ bắt đầu biến mất. Nó sẽ được thay thế bằng builder (người xây dựng) và điều này sẽ gây khó khăn cho rất nhiều người. Hôm nay, khách mời của tôi là Boris Cherny, Trưởng bộ phận Claude Code tại Anthropic. Thật khó để mô tả tác động mà Claude Code đã mang lại cho thế giới. Khoảng thời gian tập này được phát hành cũng sẽ là kỷ niệm một năm ra mắt Claude Code. Và trong thời gian ngắn ngủi đó, nó đã thay đổi hoàn toàn công việc của một kỹ sư phần mềm và hiện đang bắt đầu thay đổi công việc của nhiều chức năng khác trong lĩnh vực công nghệ mà chúng ta sẽ nói đến. Bản thân Claude Code cũng là động lực lớn thúc đẩy sự tăng trưởng chung của Anthropic trong năm qua. Họ vừa huy động được một vòng vốn với hơn 350 tỷ đô la. Và như Boris đã đề cập, tốc độ tăng trưởng của bản thân Claude Code vẫn đang tăng tốc. Chỉ trong tháng qua, số người dùng hoạt động hàng ngày của họ đã tăng gấp đôi. Boris cũng là một con người thực sự thú vị, chu đáo và tư duy sâu sắc. Trong cuộc trò chuyện này, chúng tôi phát hiện ra rằng chúng tôi sinh ra cùng một thành phố ở Ukraine. Thật buồn cười, tôi không hề biết điều đó. Xin chân thành cảm ơn Ben Mann, Jenny Wen và Mike Krieger đã gợi ý các chủ đề cho cuộc trò chuyện này. Đừng quên ghé thăm lennisprodpass.com để tìm hiểu về bộ ưu đãi đáng kinh ngạc dành riêng cho những người đăng ký nhận bản tin của Lenny. Hãy cùng bắt đầu sau một vài lời từ các nhà tài trợ tuyệt vời của chúng ta. Tập hôm nay được tài trợ bởi DX, nền tảng thông tin developer được thiết kế bởi các nhà nghiên cứu hàng đầu. Để phát triển mạnh mẽ trong kỷ nguyên AI, các tổ chức cần thích nghi nhanh chóng. Nhưng nhiều nhà lãnh đạo tổ chức gặp khó khăn khi trả lời các câu hỏi cấp bách như: những công cụ nào đang hoạt động? Chúng đang được sử dụng như thế nào? Điều gì thực sự mang lại giá trị? DX cung cấp dữ liệu và thông tin chi tiết mà các nhà lãnh đạo cần để điều hướng sự thay đổi này. Với DX, các công ty như Dropbox, Booking.com, Adyen và Intercom có được sự hiểu biết sâu sắc về cách AI đang cung cấp giá trị cho các developer của họ và tác động của AI đối với năng suất kỹ thuật. Để tìm hiểu thêm, hãy truy cập trang web của DX tại getdx.com/lenny. Đó là getdx.com/lenny. Các ứng dụng có thể gặp lỗi theo nhiều cách khác nhau. Sự cố, chậm lại, lỗi hồi quy (regressions) và những thứ bạn chỉ thấy khi người dùng thực xuất hiện. Sentry nắm bắt tất cả. Xem điều gì đã xảy ra ở đâu và tại sao, đến cả commit đã gây ra lỗi, developer đã triển khai nó và dòng code chính xác, tất cả trong một chế độ xem được kết nối. Tôi chắc chắn đã thử phương pháp gỡ lỗi bằng "năm tab và chuỗi Slack". Cách này tốt hơn. Sentry cho bạn thấy yêu cầu đã di chuyển như thế nào, những gì đã chạy, những gì đã chậm lại và những gì người dùng đã thấy. Seer, AI debugging agent của Sentry, sẽ xử lý từ đó. Nó sử dụng tất cả ngữ cảnh của Sentry để cho bạn biết nguyên nhân gốc rễ, đề xuất cách sửa lỗi và thậm chí mở một PR cho bạn. Nó cũng xem xét PR của bạn và gắn cờ bất kỳ thay đổi gây lỗi (breaking changes) nào với các bản sửa lỗi sẵn sàng. Hãy dùng thử Sentry và Seer miễn phí tại sentry.io/lenny và sử dụng code Lenny để nhận 100 đô la tín dụng Sentry. Đó là sentry.io/lenny. Boris, cảm ơn anh rất nhiều vì đã có mặt ở đây và chào mừng anh đến với podcast.

— Boris Cherny: Vâng, cảm ơn vì đã mời tôi.

Quyết định Quay lại Anthropic: Tầm nhìn Sứ mệnh

— Người dẫn chương trình: Tôi muốn bắt đầu với một câu hỏi khá "nóng". Khoảng 6 tháng trước, tôi không biết mọi người có còn nhớ không, anh thực sự đã rời Anthropic. Anh đã gia nhập Cursor và sau đó hai tuần, anh quay lại Anthropic. Chuyện gì đã xảy ra vậy? Tôi không nghĩ mình đã từng nghe câu chuyện thực sự.

— Boris Cherny: [tiếng cười] Đó là thay đổi công việc nhanh nhất mà tôi từng có. Tôi gia nhập Cursor vì tôi là một fan hâm mộ lớn của sản phẩm đó và thành thật mà nói, tôi đã gặp đội ngũ và tôi thực sự ấn tượng. Họ là một đội ngũ tuyệt vời. Tôi vẫn nghĩ họ thật tuyệt vời và họ đang xây dựng những thứ thực sự thú vị, và họ đã nhìn thấy nơi AI coding sẽ đi đến, tôi nghĩ là trước nhiều người khác. Vì vậy, ý tưởng xây dựng một sản phẩm tốt đã rất thú vị đối với tôi. Tôi nghĩ ngay khi tôi đến đó, điều tôi bắt đầu nhận ra là điều tôi thực sự nhớ về Anthropic là sứ mệnh. Và đó thực sự là điều ban đầu đã thúc đẩy tôi đến với Anthropic, bởi vì trước khi tôi gia nhập Anthropic, tôi đang làm việc trong các công ty big tech và sau đó tôi muốn làm việc tại một lab để giúp định hình tương lai của thứ điên rồ mà chúng ta đang xây dựng theo một cách nào đó. Và điều thu hút tôi đến với Anthropic chính là sứ mệnh. Và nó, bạn biết đấy, tất cả là về an toàn. Và khi bạn nói chuyện với mọi người ở Anthropic, chỉ cần tìm một người nào đó trong hành lang, nếu bạn hỏi họ tại sao họ ở đây, câu trả lời sẽ luôn là an toàn. Và vì vậy, kiểu sứ mệnh-định hướng này thực sự, thực sự cộng hưởng với tôi. Và tôi biết cá nhân mình, đó là điều tôi cần để hạnh phúc. Và đó chỉ là một điều tôi thực sự nhớ. Và tôi thấy rằng, bạn biết đấy, bất kể công việc có thể là gì, dù thú vị đến đâu, ngay cả khi đó là xây dựng một sản phẩm thực sự tuyệt vời, thì nó cũng không thực sự là một sự thay thế cho điều đó. Vì vậy, đối với tôi, thực sự khá rõ ràng rằng tôi đã thiếu điều đó khá nhanh.

Tác động và Tăng trưởng Vượt bậc của `Claude Code`

— Người dẫn chương trình: Được rồi. Vậy thì, hãy theo dõi dòng suy nghĩ về việc quay lại Anthropic và công việc anh đã làm ở đó. Podcast này sẽ được phát hành vào khoảng kỷ niệm một năm ra mắt Claude Code. Vì vậy, tôi sẽ dành một chút thời gian để suy ngẫm về tác động mà anh đã tạo ra. Có một báo cáo gần đây mà tôi chắc chắn anh đã xem của SemiAnalysis, cho thấy 4% tổng số commit trên GitHub hiện nay được tạo bởi Claude Code. Và họ dự đoán rằng con số này sẽ là một phần năm tổng số commit code trên GitHub vào cuối năm nay. Cách họ diễn đạt là: "Trong khi chúng ta nhấp nháy, AI đã ngốn hết toàn bộ quá trình phát triển phần mềm." Vào ngày chúng ta đang ghi âm này, Spotify vừa đưa ra một tiêu đề rằng những developer giỏi nhất của họ đã không viết một dòng code nào kể từ tháng 12 nhờ AI. Ngày càng nhiều kỹ sư cấp cao tiên tiến nhất, bao gồm cả anh, đang chia sẻ sự thật rằng họ không còn viết code nữa, mà tất cả đều do AI tạo ra. Và nhiều người thậm chí không còn nhìn vào code nữa, đó là mức độ mà chúng ta đã đạt được, phần lớn nhờ vào dự án nhỏ mà anh đã khởi xướng và đội ngũ của anh đã mở rộng trong năm qua. Tôi tò mò muốn nghe những suy ngẫm của anh về năm vừa qua và tác động mà công việc của anh đã tạo ra.

— Boris Cherny: Những con số này thật điên rồ, đúng không? 4% tổng số commit trên thế giới thì nhiều hơn rất nhiều so với những gì tôi tưởng tượng, và như anh nói, nó vẫn giống như điểm khởi đầu. Đây cũng chỉ là các public commit. Vì vậy, chúng tôi thực sự nghĩ rằng nếu bạn nhìn vào các kho lưu trữ riêng tư (private repositories), con số đó còn cao hơn đáng kể. Và tôi nghĩ điều điên rồ nhất đối với tôi không phải là con số hiện tại, mà là tốc độ chúng ta đang tăng trưởng, bởi vì nếu bạn nhìn vào tốc độ tăng trưởng của Claude Code trên bất kỳ chỉ số nào, nó vẫn tiếp tục tăng tốc. Vì vậy, nó không chỉ tăng lên, mà còn tăng lên nhanh hơn và nhanh hơn.

`AI Agent`, `Tool Use` và Hành trình Phát triển `Claude Code`

— Boris Cherny: Khi tôi lần đầu tiên bắt đầu Claude Code, nó chỉ là một dự án nhỏ. Bạn biết đấy, chúng tôi nói chung đều biết tại Anthropic rằng chúng tôi muốn có một, chúng tôi muốn triển khai một loại sản phẩm coding nào đó và bạn biết đấy, đối với Anthropic trong một thời gian dài, chúng tôi đã xây dựng các mô hình theo cách phù hợp với mô hình tư duy của chúng tôi về cách chúng tôi xây dựng AI an toàn, nơi mô hình bắt đầu bằng việc rất giỏi coding, sau đó nó trở nên rất giỏi tool use, sau đó nó trở nên rất giỏi computer use, đại khái đây là quỹ đạo. Và bạn biết đấy, chúng tôi đã làm việc này trong một thời gian dài và khi bạn nhìn vào đội ngũ mà tôi bắt đầu, nó được gọi là nhóm Anthropic Labs. Và thực ra Mike Krieger và Ben Mann, họ vừa khởi động lại đội ngũ này cho vòng hai. Đội ngũ đã xây dựng một số thứ khá thú vị, vì vậy chúng tôi đã xây dựng Claude Code, chúng tôi đã xây dựng MCP, chúng tôi đã xây dựng ứng dụng desktop. Vì vậy, bạn có thể thấy hạt giống của ý tưởng này, bạn biết đấy, nó là coding sau đó là tool use sau đó là computer use. Và lý do điều này quan trọng đối với Anthropic là vì an toàn. Nó lại một lần nữa trở lại với việc AI ngày càng mạnh mẽ hơn, ngày càng có khả năng hơn. Điều đã xảy ra trong năm qua là, ít nhất đối với các kỹ sư, AI không chỉ viết code. Nó không chỉ là một đối tác trò chuyện, mà nó thực sự sử dụng công cụ. Nó hành động trong thế giới. Và tôi nghĩ bây giờ với Cowork, chúng ta đang bắt đầu thấy sự chuyển đổi đối với cả những người không chuyên về kỹ thuật. Đối với nhiều người sử dụng AI đàm thoại, đây có thể là lần đầu tiên họ sử dụng thứ thực sự hành động. Nó thực sự có thể sử dụng Gmail của bạn, nó có thể sử dụng Slack của bạn, nó có thể làm tất cả những điều này cho bạn và nó khá tốt ở đó. Và nó sẽ chỉ tốt hơn từ đây. Vì vậy, tôi nghĩ đối với Anthropic trong một thời gian dài, có cảm giác rằng chúng tôi muốn xây dựng một cái gì đó nhưng không rõ là gì. Và vì vậy, khi tôi gia nhập Anthropic, tôi đã dành một tháng để thử nghiệm và bạn biết đấy, đã xây dựng một loạt các prototype kỳ lạ, hầu hết chúng đều không được triển khai và bạn biết đấy, thậm chí không gần với việc triển khai, đó chỉ là việc cố gắng hiểu ranh giới của những gì mô hình có thể làm. Sau đó, tôi dành một tháng để thực hiện post-training để hiểu khía cạnh nghiên cứu của nó. Và tôi nghĩ thành thật mà nói, đối với tôi với tư cách là một kỹ sư, tôi thấy rằng để làm tốt công việc, bạn thực sự phải hiểu lớp dưới lớp mà bạn đang làm việc. Và với công việc kỹ thuật truyền thống, bạn biết đấy, nếu bạn đang làm việc trên sản phẩm, bạn muốn hiểu cơ sở hạ tầng, runtime, máy ảo, ngôn ngữ, bất cứ điều gì đó, hệ thống mà bạn đang xây dựng. Nhưng, vâng, nếu bạn đang làm việc trong AI, bạn thực sự phải hiểu mô hình ở một mức độ nào đó để làm tốt công việc. Vì vậy, tôi đã đi đường vòng một chút để làm điều đó và sau đó tôi quay lại và bắt đầu tạo mẫu thứ cuối cùng trở thành Claude Code. Và phiên bản đầu tiên của nó, tôi có một bản ghi video mùa hè vì tôi đã ghi lại bản demo này và tôi đã đăng nó. Nó được gọi là ClaudeCLI vào thời điểm đó. Và tôi chỉ thể hiện cách nó sử dụng một vài công cụ và điều gây sốc đối với tôi là tôi đã cung cấp cho nó một công cụ Bash và nó đã có thể sử dụng nó để viết code để cho tôi biết tôi đang nghe nhạc gì khi tôi hỏi nó "Tôi đang nghe nhạc gì?". Và đây là điều điên rồ nhất, đúng không? Bởi vì, bạn biết đấy, chúng tôi không hướng dẫn mô hình phải nói, bạn biết đấy, sử dụng công cụ này cho cái này hoặc làm bất cứ điều gì. Mô hình đã được cung cấp công cụ này và nó đã tìm ra cách sử dụng nó để trả lời câu hỏi mà tôi có mà tôi thậm chí không chắc liệu nó có thể trả lời được không: "Tôi đang nghe nhạc gì?". Và vì vậy, tôi đã bắt đầu tạo mẫu điều này một chút nữa. Tôi đã tạo một bài đăng về nó và tôi đã công bố nó nội bộ và nó nhận được hai lượt thích.

Phản ứng ban đầu và Thiết kế giao diện `terminal`

Đó là mức độ của phản ứng vào thời điểm đó, bởi vì tôi nghĩ rằng mọi người nội bộ, bạn biết đấy, khi bạn nghĩ về các công cụ lập trình, bạn nghĩ về IDE, bạn nghĩ về tất cả những môi trường khá tinh vi này, không ai nghĩ rằng thứ này có thể dựa trên terminal. Đó là một cách thiết kế hơi kỳ lạ và đó không thực sự là ý định ban đầu, nhưng ngay từ đầu tôi đã xây dựng nó trong một terminal bởi vì trong vài tháng đầu chỉ có mình tôi, nên đó là cách dễ nhất để xây dựng. Và đối với tôi, đây thực sự là một bài học sản phẩm khá quan trọng: bạn muốn phân bổ nguồn lực dưới mức tối ưu (underresource) một chút cho mọi thứ lúc ban đầu. Sau đó, chúng tôi bắt đầu nghĩ về những kiểu dáng thiết bị (form factors) khác mà chúng tôi nên xây dựng và chúng tôi thực sự quyết định gắn bó với terminal trong một thời gian, lý do lớn nhất là mô hình (model) đang cải thiện rất nhanh chóng. Chúng tôi cảm thấy không có kiểu dáng thiết bị nào khác có thể bắt kịp nó. Và thành thật mà nói, đây chỉ là tôi đang vật lộn với câu hỏi: chúng ta nên xây dựng gì? Bạn biết đấy, trong năm vừa qua, Claude Code là tất cả những gì tôi nghĩ đến. Và thế là vào đêm khuya, đây là điều tôi nghĩ: được rồi, mô hình đang tiếp tục cải thiện. Chúng ta phải làm gì? Làm thế nào chúng ta có thể bắt kịp? Và terminal thành thật mà nói, là ý tưởng duy nhất mà tôi có. Và, vâng, nó đã trở nên phổ biến khá nhanh sau khi tôi phát hành.

Khởi đầu và Thành công của `Claude Code`

Nó trở thành một hiện tượng tại Anthropic và, bạn biết đấy, người dùng hoạt động hàng ngày (daily active users) đã tăng vọt. Và ngay từ rất sớm, thực ra trước khi tôi ra mắt, Ben đã gợi ý tôi tạo biểu đồ DAU, và tôi đã nghĩ, bạn biết đấy, có lẽ còn hơi sớm, chúng ta có nên làm điều đó ngay bây giờ không? Và anh ấy nói, "Có." Thế là biểu đồ đã tăng vọt ngay lập tức. Sau đó, vào tháng 2, chúng tôi đã phát hành nó ra bên ngoài. Thực ra, điều mà mọi người không thực sự nhớ là Claude Code ban đầu không phải là một hiện tượng khi chúng tôi phát hành nó. Nó thu hút rất nhiều người dùng. Có nhiều người dùng tiên phong (early adopters) đã nắm bắt được ngay lập tức, nhưng phải mất nhiều tháng để mọi người thực sự hiểu rõ công cụ này là gì. Đơn giản là nó rất khác biệt. Và khi tôi nghĩ về nó, một phần lý do Claude Code hoạt động là ý tưởng về nhu cầu tiềm ẩn (latent demand) nơi chúng tôi mang công cụ đến cho mọi người và làm cho các quy trình làm việc hiện có dễ dàng hơn một chút, nhưng cũng bởi vì nó nằm trong terminal. Nó có vẻ hơi bất ngờ. Nó hơi lạ lẫm theo cách này. Vì vậy, bạn phải có một tư duy (mindset) cởi mở và bạn phải học cách sử dụng nó. Và tất nhiên bây giờ, Claude Code hiện có sẵn trên ứng dụng Claude dành cho iOS và Android. Nó có sẵn trên ứng dụng dành cho máy tính để bàn. Nó có sẵn trên trang web. Nó có sẵn dưới dạng tiện ích mở rộng IDE (IDE extensions) trong Slack và GitHub. Bạn biết đấy, ở tất cả những nơi mà các kỹ sư làm việc, nó đã quen thuộc hơn một chút, nhưng đó không phải là điểm khởi đầu. Vì vậy, vâng, ban đầu khá ngạc nhiên khi công cụ này thực sự hữu ích, và khi nhóm phát triển, sản phẩm phát triển, khi nó bắt đầu trở nên hữu ích hơn với mọi người, thì mọi người trên khắp thế giới, từ các startup nhỏ đến các công ty FANG lớn nhất, bắt đầu sử dụng và đưa ra phản hồi. Và tôi nghĩ khi nhìn lại, đó là một trải nghiệm đầy khiêm tốn vì chúng tôi liên tục học hỏi từ người dùng của mình, và điều thú vị nhất là không ai trong chúng tôi thực sự biết mình đang làm gì. Và chúng tôi chỉ đang cố gắng tìm hiểu cùng với mọi người, và tín hiệu tốt nhất cho điều đó chính là phản hồi từ người dùng. Vì vậy, đó là điều tuyệt vời nhất, tôi đã ngạc nhiên rất nhiều lần.

Sự thay đổi nhanh chóng của Kỹ thuật phần mềm

Thật đáng kinh ngạc khi mọi thứ có thể thay đổi nhanh chóng như vậy trong thế giới ngày nay. Bạn đã ra mắt điều này một năm trước và đó không phải là lần đầu tiên mọi người có thể sử dụng AI để lập trình, nhưng trong một năm, toàn bộ ngành kỹ thuật phần mềm (software engineering) đã thay đổi đáng kể. Có tất cả những dự đoán kiểu như AI sẽ viết 100% mã nguồn, mã nguồn của AI sẽ được AI viết, mọi người đều nói, "Không, điều đó thật điên rồ, bạn đang nói gì vậy?" Bây giờ thì, "Chắc chắn rồi, nó đang xảy ra đúng như họ đã nói." Mọi thứ giờ đây chuyển động và thay đổi quá nhanh. Đúng vậy, nó thực sự rất nhanh. Trở lại với Code with Claude vào tháng 5, đó là hội nghị dành cho developer đầu tiên mà chúng tôi tổ chức tại Anthropic. Tôi đã có một bài nói ngắn và trong phần hỏi đáp sau bài nói, mọi người hỏi về dự đoán của tôi cho cuối năm. Và dự đoán của tôi vào tháng 5 năm 2025 là đến cuối năm, bạn có thể không cần IDE để lập trình nữa, và chúng ta sẽ bắt đầu thấy các kỹ sư không làm điều này, và tôi nhớ cả căn phòng đã há hốc mồm kinh ngạc. Đó là một dự đoán điên rồ, nhưng tôi nghĩ tại Anthropic, cách chúng tôi suy nghĩ mọi thứ là theo cấp số nhân và điều này đã ăn sâu vào DNA của chúng tôi. Nếu bạn nhìn vào các nhà đồng sáng lập (co-founders) của chúng tôi, ba trong số họ là ba tác giả đầu tiên của bài báo về luật mở rộng (scaling laws paper). Vì vậy, chúng tôi thực sự chỉ suy nghĩ theo cấp số nhân, và nếu bạn nhìn vào biểu đồ cấp số nhân của tỷ lệ mã nguồn được Claude viết vào thời điểm đó, nếu bạn chỉ vạch ra đường thẳng, thì khá rõ ràng là chúng tôi sẽ vượt 100% vào cuối năm, ngay cả khi điều đó hoàn toàn không phù hợp với trực giác (intuition). Và thế là tất cả những gì tôi làm là vạch ra đường thẳng, và vâng, vào tháng 11, điều đó đã xảy ra với cá nhân tôi và đó là trường hợp kể từ đó, và chúng tôi cũng bắt đầu thấy điều đó đối với nhiều khách hàng khác nhau.

Đổi mới thông qua Thử nghiệm và `Tư duy` theo Cấp số nhân

Tôi nghĩ điều bạn vừa chia sẻ về hành trình này thực sự thú vị, đó là ý tưởng chỉ chơi đùa và xem điều gì xảy ra. Điều này thường xuyên xuất hiện với Open Claw, giống như Peter đang thử nghiệm và một điều gì đó đã xảy ra. Và cảm giác như đó là một thành phần trung tâm của rất nhiều đổi mới (innovation) lớn nhất trong AI, đó là mọi người chỉ ngồi thử nghiệm và đẩy mô hình đi xa hơn hầu hết những người khác. Ý tôi là, điều về đổi mới là bạn không thể ép buộc nó. Không có lộ trình (road map) nào cho đổi mới. Bạn chỉ phải cho mọi người không gian. Bạn phải cho họ, có lẽ từ đúng hơn là an toàn. Đó là an toàn tâm lý (psychological safety) để họ được phép thất bại. Không sao nếu 80% các ý tưởng tồi. Bạn cũng phải yêu cầu họ có trách nhiệm (accountable) một chút. Vì vậy, nếu ý tưởng tồi, bạn biết đấy, bạn phải cắt lỗ (cut your losses), chuyển sang ý tưởng tiếp theo thay vì đầu tư thêm. Trong những ngày đầu của Claude Code, tôi hoàn toàn không biết rằng công cụ này sẽ hữu ích. Vì ngay cả vào tháng 2 khi chúng tôi phát hành, nó chỉ viết khoảng 20% mã nguồn của tôi, không hơn. Và ngay cả vào tháng 5, nó chỉ viết khoảng 30%. Tôi vẫn sử dụng Curtzer cho phần lớn mã nguồn của mình. Và nó chỉ vượt mốc 100% vào tháng 11. Vì vậy, phải mất một thời gian. Nhưng ngay từ những ngày đầu, tôi đã cảm thấy mình đang đi đúng hướng. Và tôi đã dành mọi buổi tối, mọi cuối tuần cho việc này. Và may mắn là vợ tôi rất ủng hộ. Nhưng tôi chỉ cảm thấy mình đang nắm giữ một điều gì đó. Không rõ ràng là gì. Và đôi khi, bạn biết đấy, bạn tìm thấy một đầu mối, bạn chỉ cần lần theo nó.

100% `Mã nguồn` được viết bởi `Claude Code`

Người phỏng vấn: Vậy tại thời điểm này, 100% mã nguồn của bạn được viết bởi Claude Code? Đó có phải là trạng thái hiện tại của việc lập trình của bạn không?

Người được phỏng vấn: Vâng. 100% mã nguồn của tôi được viết bởi Claude Code. Tôi là một lập trình viên (coder) khá năng suất. Và điều này đã đúng ngay cả khi tôi làm việc tại Instagram. Tôi là một trong số ít những kỹ sư năng suất nhất. Và điều đó thực sự vẫn đúng ở Anthropic.

Người phỏng vấn: Wow. Ngay cả khi là trưởng nhóm (head of the team).

Người được phỏng vấn: Vâng. Vâng. Vẫn lập trình rất nhiều. Và mỗi ngày tôi phát hành (ship) khoảng 10, 20, 30 pull request gì đó.

Người phỏng vấn: Mỗi ngày?

Người được phỏng vấn: Mỗi ngày. Vâng.

Người phỏng vấn: Lạy Chúa.

Người được phỏng vấn: 100% được viết bởi Claude Code. Tôi chưa từng chỉnh sửa thủ công một dòng mã nào kể từ tháng 11. Và, vâng, đó là điều đã xảy ra. Tôi vẫn xem xét mã nguồn. Vì vậy, tôi không nghĩ chúng ta đã đến lúc có thể hoàn toàn tự động (hands-off), đặc biệt khi có nhiều người đang vận hành chương trình. Bạn phải đảm bảo nó chính xác. Bạn phải đảm bảo nó an toàn, v.v. Và sau đó chúng tôi cũng có Claude thực hiện kiểm tra mã tự động (automatic code review) cho mọi thứ. Tại Anthropic, Claude kiểm tra 100% pull request. Vẫn có một lớp kiểm tra của con người (human review) sau đó, nhưng bạn vẫn muốn có những điểm kiểm tra này, bạn vẫn muốn một người xem xét mã nguồn, trừ khi đó là mã nguồn nguyên mẫu (pure prototype code) thuần túy mà bạn biết rằng nó sẽ không chạy ở bất kỳ đâu, nó chỉ là một nguyên mẫu (prototype).

Biên giới tiếp theo: `AI` đề xuất ý tưởng và Công việc tổng quát

Người phỏng vấn: Vậy biên giới tiếp theo (next frontier) là gì? Tại thời điểm này, 100% mã nguồn của bạn đang được viết bởi AI. Rõ ràng đây là hướng đi của mọi người trong kỹ thuật phần mềm. Điều đó từng là một cột mốc điên rồ. Bây giờ thì, tất nhiên, đây chính là thế giới hiện tại. Vậy, sự thay đổi lớn tiếp theo trong cách viết phần mềm mà nhóm của bạn đang hoạt động hoặc bạn nghĩ sẽ hướng tới là gì?

Người được phỏng vấn: Tôi nghĩ điều đang xảy ra hiện nay là Claude đang bắt đầu đưa ra các ý tưởng. Claude đang xem xét phản hồi, xem xét báo cáo lỗi (bug reports), xem xét dữ liệu đo lường từ xa (telemetry) và những thứ tương tự, và nó đang bắt đầu đưa ra các ý tưởng để sửa lỗi (bug fixes) và các tính năng để phát hành. Vì vậy, nó đang dần trở nên giống một đồng nghiệp (co-worker) hơn một chút. Tôi nghĩ điều thứ hai là chúng tôi đang bắt đầu mở rộng ra ngoài lập trình (coding) một chút. Vì vậy, tôi nghĩ tại thời điểm này, có thể nói rằng lập trình phần lớn đã được giải quyết. Ít nhất đối với loại lập trình mà tôi thực hiện, đó chỉ là một vấn đề đã được giải quyết (solved problem) vì Claude có thể làm được. Và thế là bây giờ chúng tôi đang bắt đầu nghĩ về: được rồi, tiếp theo là gì? Điều gì ngoài việc này? Có rất nhiều thứ gần với lập trình. Và tôi nghĩ điều này sẽ đến. Nhưng cũng có cả công việc tổng quát (general tasks), bạn biết đấy, như tôi sử dụng Co-work mỗi ngày để làm đủ thứ việc không liên quan đến lập trình chút nào và chỉ để làm tự động. Ví dụ, hôm nọ tôi phải trả tiền phạt đỗ xe. Tôi chỉ để Co-work làm điều đó. Tất cả quản lý dự án (project management) cho nhóm, Co-work làm tất cả. Nó như việc đồng bộ hóa mọi thứ giữa bảng tính (spreadsheets) và gửi tin nhắn cho mọi người trên Slack và email và tất cả những thứ tương tự. Vì vậy, tôi nghĩ biên giới tiếp theo là một điều gì đó như thế này, và tôi không nghĩ đó là lập trình vì tôi nghĩ lập trình, bạn biết đấy, nó gần như đã được giải quyết rồi, và trong vài tháng tới, tôi nghĩ điều chúng ta sẽ thấy là trên toàn ngành, nó sẽ ngày càng được giải quyết cho mọi loại cơ sở mã (codebase), mọi ngăn xếp công nghệ (tech stack) mà mọi người làm việc.

`AI` hỗ trợ `Quản lý Sản phẩm` và Chu kỳ Phản hồi Nhanh chóng

Người phỏng vấn: Ý tưởng giúp bạn đưa ra những gì cần làm thật thú vị. Rất nhiều quản lý sản phẩm (product managers) đang lắng nghe điều này có lẽ đang lo lắng. Làm thế nào bạn sử dụng Claude cho việc này? Bạn chỉ nói chuyện với nó ư? Bạn có phát minh ra điều gì thông minh để giúp bạn sử dụng nó đưa ra những gì cần xây dựng không?

Người được phỏng vấn: Thành thật mà nói, điều đơn giản nhất là mở Claude Code hoặc Co-work và trỏ nó vào một chuỗi Slack (Slack thread). Đối với chúng tôi, chúng tôi có kênh này chứa tất cả phản hồi nội bộ (internal feedback) về Claude Code. Kể từ khi chúng tôi phát hành lần đầu, ngay cả vào năm 2024 nội bộ, nó đã là một lượng lớn phản hồi (fire hose of feedback). Và đó là điều tốt nhất. Và trong những ngày đầu, bất cứ khi nào ai đó gửi phản hồi, tôi sẽ vào và sửa mọi thứ nhanh nhất có thể. Ví dụ, trong vòng một phút, trong vòng 5 phút hoặc đại loại vậy. Và chu kỳ phản hồi (feedback cycle) nhanh chóng này, nó khuyến khích mọi người đưa ra ngày càng nhiều phản hồi. Điều này rất quan trọng vì nó khiến họ được lắng nghe (feel heard), bởi vì bạn biết đấy, thông thường khi bạn sử dụng một sản phẩm, bạn đưa ra phản hồi, nó chỉ biến mất vào một hố đen (black hole) nào đó và sau đó bạn không đưa ra phản hồi nữa. Vì vậy, nếu bạn khiến mọi người được lắng nghe, họ sẽ muốn đóng góp và giúp sản phẩm tốt hơn.

Claude và Code Review

Và bây giờ, tôi cũng làm những việc tương tự, nhưng Claude (cụ thể là Claude code) thật sự đảm nhận phần lớn công việc. Tôi chỉ cần chỉ nó vào kênh và nó sẽ nói: "Được thôi, đây là vài thứ tôi có thể làm. Tôi vừa gửi vài PR. Bạn có muốn xem xét PR đó không?" Tôi trả lời: "Có." Bạn có nhận thấy rằng nó đang ngày càng giỏi hơn trong việc này không? Bởi vì đây chính là "chén thánh", phải không? Giờ thì mọi người đều nghĩ: "Tuyệt vời, việc xây dựng đã được giải quyết." Code review trở thành nút thắt cổ chai tiếp theo. Với tất cả những pull request này, ai sẽ xem xét chúng đây? Câu hỏi lớn tiếp theo là: "Được rồi, bây giờ con người cần thiết để tìm ra nên xây dựng cái gì, ưu tiên cái gì." Và bạn đang nói rằng đó là lúc Claude Code bắt đầu giúp đỡ bạn. Nó đã tốt hơn rất nhiều với Opus 4.6 hay xu hướng phát triển là gì?

Năng suất Kỹ sư và Tác động của AI

Vâng, nó đã cải thiện rất nhiều. Tôi nghĩ một phần là do quá trình huấn luyện cụ thể mà chúng tôi thực hiện cho việc lập trình. Rõ ràng, đây là mô hình lập trình tốt nhất thế giới và nó đang ngày càng tốt hơn, như 4.6 thật sự đáng kinh ngạc. Nhưng thực tế, rất nhiều quá trình huấn luyện mà chúng tôi thực hiện bên ngoài lĩnh vực lập trình cũng chuyển giao rất tốt. Vì vậy, có một sự chuyển giao khi bạn dạy mô hình làm X, và nó cũng trở nên tốt hơn ở Y.

Và những bước tiến này thật điên rồ, như tại Anthropic trong năm qua, kể từ khi chúng tôi giới thiệu Claude Code, chúng tôi có thể không biết chính xác con số, nhưng chúng tôi có thể đã tăng gấp 4 lần đội ngũ kỹ sư hoặc tương tự, nhưng năng suất trên mỗi kỹ sư đã tăng 200%. Về mặt pull request và những con số này thật sự điên rồ đối với bất kỳ ai làm việc trong lĩnh vực này và làm về năng suất nhà phát triển. Bởi vì trong một công việc trước đây, tôi làm ở Meta và một trong những trách nhiệm của tôi là chất lượng mã cho công ty. Đó là trách nhiệm của tôi đối với tất cả các cơ sở mã của chúng tôi, như Facebook, Instagram, WhatsApp và tất cả những thứ này. Và rất nhiều công việc đó là về năng suất, bởi vì nếu bạn làm cho mã chất lượng cao hơn, thì các kỹ sư sẽ làm việc năng suất hơn. Và những điều chúng tôi thấy là trong một năm với hàng trăm kỹ sư làm việc trên đó, bạn sẽ thấy mức tăng năng suất chỉ khoảng vài phần trăm.

Và vì vậy, ngày nay, việc chứng kiến những mức tăng hàng trăm phần trăm này thật sự điên rồ. Điều cũng điên rồ không kém là mọi thứ đã trở nên bình thường hóa như thế nào. Chúng ta nghe những con số này cứ như thể "tất nhiên AI đang làm điều này cho chúng ta." Mức độ thay đổi đang diễn ra trong phát triển phần mềm, xây dựng sản phẩm, và chỉ đơn giản là thế giới công nghệ, là điều chưa từng có tiền lệ. Thật dễ dàng để quen với nó, nhưng điều quan trọng là phải nhận ra rằng điều này thật điên rồ. Đây là điều mà thỉnh thoảng tôi phải tự nhắc nhở mình.

Thích nghi với Sự thay đổi của AI

Có một nhược điểm của việc này, bởi vì mô hình thay đổi rất nhiều – thực ra có rất nhiều nhược điểm mà chúng ta có thể nói đến – nhưng tôi nghĩ một trong số đó ở cấp độ cá nhân là mô hình thay đổi thường xuyên đến mức đôi khi tôi bị mắc kẹt trong cách suy nghĩ cũ về nó. Và tôi thậm chí thấy rằng những người mới trong nhóm hoặc thậm chí những sinh viên mới tốt nghiệp tham gia lại làm mọi thứ theo cách "AGI hướng tới" hơn tôi.

Bài học từ Memory Leak: Tầm quan trọng của Tư duy mới

Ví dụ, đôi khi tôi đã gặp trường hợp này vài tháng trước, có một rò rỉ bộ nhớ. Đây là khi mức sử dụng bộ nhớ của Claude Code tăng lên và đến một lúc nào đó nó bị treo. Đây là một vấn đề kỹ thuật rất phổ biến mà mọi kỹ sư đều đã gỡ lỗi hàng nghìn lần. Theo truyền thống, cách bạn làm là lấy một ảnh chụp heap (heap snapshot), đưa nó vào một trình gỡ lỗi đặc biệt, bạn tìm ra chuyện gì đang xảy ra, sử dụng những công cụ đặc biệt này để xem điều gì đang diễn ra.

Tôi đang làm điều này và tôi đang xem xét những dấu vết này và cố gắng tìm ra chuyện gì đang xảy ra. Và kỹ sư mới hơn trong nhóm chỉ đơn giản là nhờ Claude Code làm việc đó và nói: "Này Claude, dường như có một rò rỉ bộ nhớ. Bạn có thể tìm ra nó không?" Và Claude Code đã làm chính xác những gì tôi đang làm. Nó đã lấy ảnh chụp heap. Nó đã tự viết một công cụ nhỏ để tự phân tích nó. Nó giống như một chương trình just-in-time. Và nó đã tìm ra vấn đề và đưa ra một pull request nhanh hơn tôi có thể làm. Vì vậy, đối với những người trong chúng ta đã sử dụng mô hình này trong một thời gian dài, bạn vẫn phải tự đưa mình đến thời điểm hiện tại và không bị mắc kẹt trong một mô hình cũ, bởi vì nó không còn là Sonnet 3.5 nữa. Các mô hình mới hoàn toàn khác biệt. Và sự thay đổi tư duy này rất khác biệt.

Tôi nghe nói bạn có những nguyên tắc rất cụ thể mà bạn đã mã hóa cho nhóm của mình, rằng khi mọi người tham gia, bạn sẽ hướng dẫn họ. Tôi tin rằng một trong số đó là: "Điều gì tốt hơn việc tự mình làm? Hãy để Claude làm điều đó." Và có vẻ như đó chính xác là những gì bạn mô tả với rò rỉ bộ nhớ này, cứ như thể bạn gần như quên mất nguyên tắc đó: "Được rồi, hãy xem liệu Claude có thể giải quyết vấn đề này cho mình không."

Nguyên tắc Hoạt động: Cấp vốn không đủ và Tốc độ

Có một điều thú vị khác cũng xảy ra khi bạn cấp vốn không đủ cho mọi thứ một chút, bởi vì sau đó mọi người buộc phải "làm mọi thứ với Claude", và đây là điều chúng ta thấy. Vì vậy, đối với công việc, đôi khi chúng tôi chỉ giao một kỹ sư cho một dự án và cách họ có thể triển khai rất nhanh là vì họ muốn triển khai nhanh chóng. Đây là một động lực nội tại đến từ bên trong, chỉ đơn giản là muốn làm tốt công việc. Nếu bạn có một ý tưởng hay, bạn thực sự muốn đưa nó ra ngoài. Không ai phải ép buộc bạn làm điều đó. Điều đó đến từ chính bạn. Và vì vậy, nếu bạn có Claude, bạn có thể sử dụng nó để tự động hóa rất nhiều công việc. Và đó là điều chúng tôi thấy lặp đi lặp lại.

Vì vậy, tôi nghĩ đó là một nguyên tắc: cấp vốn không đủ cho mọi thứ một chút. Tôi nghĩ một nguyên tắc khác là khuyến khích mọi người đi nhanh hơn. Nếu bạn có thể làm điều gì đó hôm nay, bạn nên làm nó ngay hôm nay. Và đây là điều chúng tôi thực sự, thực sự khuyến khích trong nhóm. Ban đầu, điều này rất quan trọng vì chỉ có tôi, và lợi thế duy nhất của chúng tôi là tốc độ. Đó là cách duy nhất chúng tôi có thể triển khai một sản phẩm có thể cạnh tranh trong thị trường lập trình rất đông đúc này. Nhưng ngày nay, đó vẫn là một nguyên tắc rất quan trọng mà chúng tôi có trong nhóm. Và nếu bạn muốn đi nhanh hơn, một cách rất tốt để làm điều đó là chỉ cần để Claude làm nhiều việc hơn. Vì vậy, nó rất khuyến khích điều đó.

Tự do Token và Đổi mới

Ý tưởng cấp vốn không đủ này thật thú vị bởi vì nói chung có một cảm giác rằng AI sẽ cho phép bạn không cần nhiều nhân viên, không cần nhiều kỹ sư. Và vì vậy, không chỉ là bạn có thể làm việc năng suất hơn. Điều bạn đang nói là bạn thực sự sẽ làm tốt hơn nếu bạn cấp vốn không đủ. Không chỉ AI có thể làm bạn nhanh hơn. Mà là bạn sẽ nhận được nhiều hơn từ công cụ AI nếu bạn có ít người làm việc về một thứ gì đó.

Vâng. Nếu bạn thuê những kỹ sư giỏi, họ sẽ tìm ra cách để làm điều đó. Và đặc biệt là nếu bạn trao quyền cho họ để làm điều đó. Đây là điều tôi thực sự nói rất nhiều với các CTO và đủ loại công ty. Lời khuyên của tôi nói chung là đừng cố gắng tối ưu hóa. Đừng cố gắng cắt giảm chi phí ngay từ đầu. Hãy bắt đầu bằng cách cấp cho kỹ sư càng nhiều token càng tốt. Và bây giờ bạn đang bắt đầu thấy các công ty như Anthropic có, bạn biết đấy, mọi người đều có thể sử dụng rất nhiều token. Chúng ta đang bắt đầu thấy điều này xuất hiện như một đặc quyền ở một số công ty. Giống như nếu bạn tham gia, bạn sẽ nhận được token không giới hạn. Đây là điều tôi rất khuyến khích bởi vì nó giúp mọi người tự do thử những ý tưởng mà trước đây có thể quá điên rồ. Và sau đó, nếu có một ý tưởng hoạt động, bạn có thể tìm ra cách mở rộng nó và đó là lúc để tối ưu hóa và cắt giảm chi phí. Hãy tìm ra, bạn biết đấy, có thể bạn có thể làm điều đó với Haiku hoặc với Sonnet thay vì Opus hoặc bất cứ thứ gì, nhưng ban đầu bạn chỉ muốn ném thật nhiều token vào đó và xem liệu ý tưởng có hiệu quả không và cho kỹ sư sự tự do để làm điều đó. Vì vậy, lời khuyên ở đây là hãy thoải mái với token của bạn, với chi phí sử dụng các mô hình này.

Mọi người nghe điều này có thể nghĩ: "Tất nhiên rồi, anh ta làm việc ở Anthropic. Anh ta muốn chúng ta sử dụng càng nhiều token càng tốt." Nhưng điều bạn đang nói ở đây là những ý tưởng sáng tạo thú vị nhất sẽ đến từ việc ai đó chỉ cần tận dụng tối đa và xem điều gì là có thể.

Vâng. Và tôi nghĩ thực tế là ở quy mô nhỏ, bạn sẽ không nhận được một hóa đơn khổng lồ hay bất cứ điều gì tương tự. Nếu đó là một kỹ sư cá nhân đang thử nghiệm, chi phí token vẫn có thể tương đối thấp so với lương của họ hoặc các chi phí khác của việc điều hành doanh nghiệp. Vì vậy, nó thực sự không phải là một chi phí lớn khi mọi thứ mở rộng. Chẳng hạn, giả sử họ xây dựng một thứ tuyệt vời và sau đó nó tốn một lượng token khổng lồ và chi phí trở nên khá lớn. Đó là thời điểm bạn muốn tối ưu hóa nó. Nhưng đừng làm điều đó quá sớm.

Bạn đã thấy các công ty nào mà chi phí token của họ cao hơn lương không? Bạn có nghĩ rằng đó là một xu hướng mà chúng ta sẽ tìm thấy và thấy không?

Bạn biết đấy, tại Anthropic, chúng tôi bắt đầu thấy một số kỹ sư chi tiêu, bạn biết đấy, hàng trăm nghìn một tháng cho token. Vì vậy, chúng tôi đang bắt đầu thấy điều này một chút. Có một số công ty mà chúng tôi đang bắt đầu thấy những điều tương tự. Vâng.

Coding như một Công cụ

Quay trở lại với lập trình, bạn có nhớ việc viết mã không? Điều này có khiến bạn buồn vì đây không còn là điều bạn sẽ làm với tư cách là một kỹ sư phần mềm nữa? Đối với tôi, thật buồn cười, khi tôi học kỹ thuật, đối với tôi nó rất thực tế. Tôi học kỹ thuật để tôi có thể xây dựng mọi thứ và đối với tôi, tôi là người tự học. Bạn biết đấy, tôi học kinh tế ở trường, nhưng tôi không học khoa học máy tính, nhưng tôi đã tự học kỹ thuật từ khá sớm. Tôi đã lập trình từ cấp hai và ngay từ đầu nó đã rất thực tế. Vì vậy, tôi thực sự đã học lập trình để có thể gian lận trong một bài kiểm tra toán. Đó là điều đầu tiên chúng tôi có những máy tính đồ họa này và bạn biết đấy, tôi chỉ lập trình câu trả lời vào đó.

TI-83.

TI-83 Plus. Vâng, vâng. Chính xác. [tiếng cười]

Plus. Vâng. Vì vậy, tôi đã lập trình các câu trả lời vào đó và sau đó bài kiểm tra toán tiếp theo, bạn biết đấy, năm tiếp theo nó quá khó. Tôi không thể lập trình tất cả các câu trả lời vào đó vì tôi không biết câu hỏi là gì. Và vì vậy tôi phải viết một bộ giải nhỏ để nó là một chương trình sẽ chỉ giải những câu hỏi đại số này hoặc bất cứ thứ gì. Và sau đó tôi phát hiện ra bạn có thể lấy một sợi cáp nhỏ, bạn có thể đưa chương trình cho phần còn lại của lớp và sau đó cả lớp đều được điểm A. Nhưng sau đó tất cả chúng tôi đều bị bắt và giáo viên bảo chúng tôi dừng lại.

Nhưng ngay từ đầu, nó luôn rất thực tế đối với tôi, nơi lập trình là một cách để xây dựng một thứ gì đó. Nó không phải là mục đích tự thân. Đến một lúc nào đó, cá nhân tôi đã sa vào cái hố thỏ của cái đẹp của lập trình. Vì vậy, tôi đã viết một cuốn sách về TypeScript. Tôi đã bắt đầu, thực ra vào thời điểm đó, đó là buổi gặp mặt TypeScript lớn nhất thế giới chỉ vì tôi đã yêu thích chính ngôn ngữ đó. Và tôi đã đi sâu vào lập trình hàm và tất cả những thứ này. Tôi nghĩ rất nhiều lập trình viên bị phân tâm bởi điều này. Đối với tôi, nó luôn là một điều gì đó... có một vẻ đẹp trong lập trình và đặc biệt là trong lập trình hàm. Có một vẻ đẹp trong hệ thống kiểu. Có một cảm giác hưng phấn nhất định mà bạn có được khi bạn giải quyết một vấn đề toán học thực sự phức tạp. Nó khá tương tự khi bạn cân bằng các kiểu hoặc bạn biết đấy, chương trình thực sự đẹp, nhưng nó thực sự không phải là mục đích cuối cùng. Tôi nghĩ đối với tôi, lập trình rất nhiều là một công cụ và là một cách để làm mọi việc. Tuy nhiên, không phải ai cũng cảm thấy như vậy.

Tương Lai Của Kỹ Năng Lập Trình Và Sự Thay Đổi Cá Nhân

Người dẫn chương trình: Chẳng hạn, có một kỹ sư trong nhóm tên là Lena, cô ấy vẫn viết C++ thủ công vào cuối tuần vì cô ấy thực sự thích viết C++ bằng tay. Mọi người đều khác nhau, và tôi nghĩ ngay cả khi lĩnh vực này thay đổi, mọi thứ thay đổi, vẫn luôn có không gian để làm điều này, luôn có không gian để thưởng thức nghệ thuật và để tự tay làm mọi thứ nếu bạn muốn.

Người phỏng vấn: Anh có lo lắng về việc các kỹ năng của mình bị mai một với tư cách là một kỹ sư không? Đó có phải là điều anh lo lắng hay anh chỉ nghĩ, "Đây là cách mọi việc sẽ diễn ra"?

Người dẫn chương trình: Tôi nghĩ đó là cách mọi thứ diễn ra. Cá nhân tôi không quá lo lắng về điều đó. Đối với tôi, lập trình nằm trên một chuỗi liên tục. Xa xưa, phần mềm thực ra là một thứ tương đối mới. Nếu nhìn vào cách các chương trình được viết ngày nay, sử dụng phần mềm chạy trên máy ảo hoặc tương tự, đây là cách chúng ta viết chương trình có lẽ từ những năm 1960. Vậy là đã khoảng 60 năm rồi. Trước đó là thẻ đục lỗ (punch cards). Trước đó là công tắc (switches). Trước đó là phần cứng (hardware). Và trước đó nữa, nó chỉ đơn thuần là bút và giấy. Đó là một căn phòng đầy người đang làm toán trên giấy.

Lập trình đã luôn thay đổi theo cách này. Theo một khía cạnh nào đó, bạn vẫn muốn hiểu lớp bên dưới vì nó giúp bạn trở thành một kỹ sư giỏi hơn. Tôi nghĩ điều này sẽ đúng trong khoảng một năm tới. Nhưng tôi nghĩ chẳng bao lâu nữa, điều đó sẽ không còn thực sự quan trọng. Nó sẽ giống như mã assembly chạy bên dưới developer hoặc đại loại vậy. Ở cấp độ cảm xúc, tôi cảm thấy mình luôn phải học những điều mới. Và với tư cách là một developer, điều này thực ra không quá mới mẻ vì luôn có các framework mới, các ngôn ngữ mới. Đó là điều mà chúng tôi khá quen thuộc trong lĩnh vực này. Nhưng đồng thời, điều này không đúng với tất cả mọi người. Và tôi nghĩ đối với một số người, họ sẽ cảm thấy mất mát, hoài niệm hoặc mai một hơn.

Tôi không biết bạn có thấy không, nhưng Elon Musk đã nói rằng, tại sao trí tuệ nhân tạo (AI) không viết trực tiếp ra binary? Bởi vì cuối cùng thì tất cả sự trừu tượng trong lập trình này có ý nghĩa gì?

Người phỏng vấn: Vâng, đó là một câu hỏi hay. Ý tôi là, nó hoàn toàn có thể làm điều đó nếu anh muốn.

Người dẫn chương trình: Ồ, vậy điều tôi nghe được ở đây là luôn có câu hỏi: "Tôi có nên học lập trình không? Những người đang đi học có nên học lập trình không?" Điều tôi nghe từ bạn là quan điểm của bạn là trong một hoặc hai năm tới, bạn sẽ không thực sự cần. Quan điểm của tôi là tôi nghĩ đối với những người đang sử dụng Claude Code, những người đang sử dụng Tác nhân AI để lập trình ngày nay, bạn vẫn phải hiểu lớp bên dưới. Nhưng đúng vậy, trong một hoặc hai năm nữa, điều đó sẽ không còn quan trọng.

Bài Học Lịch Sử Từ Máy In Chữ Nổi

Người dẫn chương trình: Tôi đã nghĩ về analog lịch sử nào phù hợp cho việc này, bởi vì chúng ta phải đặt điều này vào lịch sử và tìm hiểu xem chúng ta đã trải qua những chuyển đổi tương tự khi nào. Mô hình tư duy phù hợp cho việc này là gì? Tôi nghĩ thứ gần nhất đối với tôi là máy in chữ nổi (printing press).

Nếu bạn nhìn vào châu Âu vào giữa những năm 1400, tỷ lệ biết chữ thực sự rất thấp. Chỉ dưới 1% dân số là các thư lại (scribes). Họ là những người thực hiện tất cả việc viết lách và đọc. Họ được thuê bởi các lãnh chúa và vua, những người thường không biết chữ. Vì vậy, đó là công việc của một phần rất nhỏ dân số.

Và rồi, Gutenberg và máy in chữ nổi ra đời. Có một thống kê đáng kinh ngạc rằng trong 50 năm sau khi máy in chữ nổi được chế tạo, lượng tài liệu in được tạo ra nhiều hơn so với một nghìn năm trước đó. Khối lượng tài liệu in tăng vọt. Chi phí giảm đáng kể, khoảng 100 lần trong 50 năm tiếp theo.

Và nếu bạn nhìn vào tỷ lệ biết chữ, phải mất một thời gian vì học đọc và viết khá khó. Nó đòi hỏi một hệ thống giáo dục, đòi hỏi thời gian rảnh rỗi, đòi hỏi không phải làm việc trên nông trại cả ngày để có thời gian cho giáo dục và những thứ tương tự. Nhưng trong 200 năm tiếp theo, tỷ lệ này đã tăng lên khoảng 70% trên toàn cầu. Vì vậy, tôi nghĩ đây là loại chuyển đổi mà chúng ta có thể thấy.

Thực tế có một tài liệu lịch sử thú vị, trong đó có một cuộc phỏng vấn với một thư lại vào những năm 1400 về việc họ cảm thấy thế nào về máy in chữ nổi. Và họ thực sự rất hào hứng, vì họ nói rằng điều họ không thích làm là sao chép giữa các cuốn sách. Điều họ thích làm là vẽ tranh minh họa trong sách và đóng sách. Và họ rất vui vì giờ đây thời gian của họ được giải phóng.

Thật thú vị, với tư cách là một kỹ sư, tôi cảm thấy một sự tương đồng. Đây là cách tôi cảm nhận khi tôi không phải làm những công việc tẻ nhạt của lập trình nữa, bởi vì đó luôn là những chi tiết vụn vặt, phần tẻ nhạt của nó, và việc loay hoay với git và sử dụng tất cả các công cụ khác nhau. Đó không phải là phần thú vị. Phần thú vị là tìm ra những gì cần xây dựng và nghĩ ra nó. Đó là nói chuyện với người dùng, suy nghĩ về các hệ thống lớn, suy nghĩ về tương lai, cộng tác với những người khác trong nhóm. Và đó là những gì tôi có thể làm nhiều hơn bây giờ.

Người phỏng vấn: Và điều tuyệt vời là công cụ anh đang xây dựng cho phép bất kỳ ai cũng có thể làm điều này. Những người không có kinh nghiệm kỹ thuật cũng có thể làm chính xác những gì anh đang mô tả. Giống như tôi đã thực hiện một loạt các dự án nhỏ ngẫu nhiên, và bất cứ khi nào tôi gặp khó khăn, tôi chỉ cần nói "giúp tôi giải quyết vấn đề này" và tôi được "gỡ lỗi" (unblock). Tôi từng là một kỹ sư trong 10 năm đầu sự nghiệp, và tôi nhớ đã dành rất nhiều thời gian cho các thư viện (libraries) và phụ thuộc (dependencies) và những thứ kiểu như "Ôi trời ơi, tôi phải làm gì đây?" rồi tìm kiếm trên Stack Overflow. Và bây giờ chỉ cần nói "giúp tôi giải quyết vấn đề này" và có từng bước một, hai, ba, bốn. "Được rồi, chúng ta đã làm được."

Người dẫn chương trình: Vâng, chính xác. Chính xác. Tôi đã nói chuyện với một kỹ sư ngày hôm nay, họ đang viết một service bằng Go và họ đã mất khoảng một tháng. Họ đã xây dựng service đó và nó hoạt động khá tốt. Và rồi tôi hỏi, "Vậy anh cảm thấy thế nào khi viết nó?" Anh ấy nói, "Thực ra tôi vẫn không thực sự biết Go," [tiếng cười]. Và tôi nghĩ chúng ta sẽ bắt đầu thấy điều này ngày càng nhiều. Nếu bạn biết rằng nó hoạt động chính xác và hiệu quả, thì bạn không thực sự phải biết tất cả các chi tiết.

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa `Tác Nhân AI`

Người phỏng vấn: Rõ ràng, cuộc sống của một kỹ sư phần mềm đã thay đổi đáng kể. Nó giống như một công việc hoàn toàn mới trong một hoặc hai năm qua. Anh nghĩ vai trò nào tiếp theo sẽ bị trí tuệ nhân tạo (AI) tác động mạnh nhất, trong lĩnh vực công nghệ (như quản lý sản phẩm, nhà thiết kế) hay thậm chí ngoài công nghệ? Trí tuệ nhân tạo (AI) sẽ đi đến đâu tiếp theo?

Người dẫn chương trình: Tôi nghĩ đó sẽ là nhiều vai trò liền kề với kỹ thuật. Vâng, đó có thể là quản lý sản phẩm, có thể là thiết kế, có thể là khoa học dữ liệu (data science). Nó sẽ mở rộng ra hầu hết mọi loại công việc mà bạn có thể thực hiện trên máy tính vì mô hình sẽ ngày càng tốt hơn trong việc này. Và sản phẩm co-work (co-work product) là cách đầu tiên để tiếp cận điều này, nhưng nó chỉ là cái đầu tiên. Và đó là thứ tôi nghĩ sẽ mang AI agentic (Tác nhân AI có khả năng tự động hóa) đến với những người chưa từng thực sự sử dụng nó trước đây, và mọi người đang bắt đầu có cảm nhận về nó lần đầu tiên.

Khi tôi nghĩ về kỹ thuật một năm trước, không ai thực sự biết Tác nhân AI (agent) là gì. Không ai thực sự sử dụng nó. Nhưng ngày nay, đó là cách chúng ta làm việc. Và khi tôi nhìn vào công việc không chuyên về kỹ thuật ngày nay, hoặc có thể bán kỹ thuật như công việc sản phẩm (product work) và khoa học dữ liệu (data science) và những thứ tương tự, khi bạn nhìn vào các loại trí tuệ nhân tạo (AI) mà mọi người đang sử dụng, tất cả đều là AI đàm thoại (conversational AI), giống như chatbot hoặc tương tự. Nhưng không ai thực sự đã sử dụng một Tác nhân AI (agent) trước đây. Và từ agent này cứ được nhắc đến mọi lúc và nó bị lạm dụng đến mức mất hết ý nghĩa.

Nhưng Tác nhân AI (agent) thực sự có một ý nghĩa kỹ thuật rất cụ thể: đó là một trí tuệ nhân tạo (AI), một LLM có khả năng sử dụng công cụ (tool use). Vì vậy, nó không chỉ nói chuyện, nó thực sự có thể hành động và tương tác với hệ thống của bạn. Điều này có nghĩa là nó có thể sử dụng Google Docs của bạn và nó có thể gửi email. Nó có thể chạy các lệnh trên máy tính của bạn và làm tất cả những loại việc này.

Vì vậy, tôi nghĩ bất kỳ loại công việc nào mà bạn sử dụng công cụ máy tính theo cách này, tôi nghĩ đây sẽ là bước tiếp theo. Đây là điều chúng ta phải cùng nhau tìm hiểu với tư cách là một xã hội. Đây là điều chúng ta phải tìm hiểu với tư cách là một ngành công nghiệp. Và tôi nghĩ đối với tôi, đây cũng là một trong những lý do khiến việc thực hiện công việc này tại Anthropic cảm thấy rất quan trọng và cấp bách, bởi vì tôi nghĩ chúng tôi rất nghiêm túc về điều này. Và vì vậy, bây giờ chúng tôi có các nhà kinh tế học, chúng tôi có các chuyên gia chính sách, chúng tôi có các chuyên gia tác động xã hội. Đây là điều chúng tôi muốn nói rất nhiều để xã hội có thể cùng nhau tìm ra phải làm gì, bởi vì nó không nên chỉ phụ thuộc vào chúng tôi.

Tác Động Đến Việc Làm Và Tương Lai Lạc Quan

Người phỏng vấn: Vậy câu hỏi lớn mà anh đang đề cập đến là việc làm, mất việc làm và những thứ tương tự. Có một khái niệm về Nghịch lý Jevons (Jevons Paradox) là khi chúng ta có thể làm được nhiều hơn, chúng ta lại tuyển dụng nhiều hơn, và điều đó không đáng sợ như vẻ ngoài của nó. Anh đã trải nghiệm điều gì cho đến nay khi trí tuệ nhân tạo (AI) trở thành một phần lớn trong công việc kỹ thuật? Anh có đang tuyển dụng nhiều hơn so với khi không có trí tuệ nhân tạo (AI) không, và những suy nghĩ của anh về việc làm?

Người dẫn chương trình: Vâng, ý tôi là, đối với nhóm của chúng tôi, chúng tôi đang tuyển dụng. Vì vậy, nhóm Claude Code đang tuyển dụng. Nếu bạn quan tâm, hãy kiểm tra trang việc làm trên Anthropic. Cá nhân tôi, tất cả những điều này chỉ khiến tôi yêu thích công việc của mình hơn. Tôi chưa bao giờ thích lập trình nhiều như ngày hôm nay vì tôi không phải giải quyết tất cả những chi tiết nhỏ nhặt. Vì vậy, đối với cá nhân tôi, điều đó khá thú vị.

Đây là điều chúng tôi nghe từ rất nhiều khách hàng, họ yêu thích công cụ, họ yêu Claude Code vì nó làm cho lập trình trở nên thú vị trở lại. Và điều đó thực sự rất vui đối với họ. Nhưng rất khó để biết điều này sẽ đi đến đâu. Và một lần nữa, tôi phải tìm đến những analog lịch sử này. Và tôi nghĩ máy in chữ nổi là một ví dụ tuyệt vời, bởi vì điều đã xảy ra là công nghệ này, vốn bị giới hạn trong một nhóm nhỏ người (như biết đọc và viết), đã trở nên dễ tiếp cận với tất cả mọi người. Nó vốn dĩ là dân chủ hóa. Mọi người bắt đầu có thể làm điều này.

Và nếu không phải vậy thì một điều gì đó như thời Phục hưng đã không thể xảy ra, bởi vì phần lớn thời Phục hưng là về sự lan truyền kiến thức. Đó là về các bản ghi chép bằng văn bản mà mọi người sử dụng để giao tiếp. Vì không có điện thoại hay bất cứ thứ gì tương tự vào thời điểm đó. Không có internet. Vì vậy, vấn đề là điều này sẽ mở ra những gì tiếp theo? Và tôi nghĩ đó là phiên bản rất lạc quan của nó đối với tôi. Và đó là phần mà tôi thực sự hào hứng. Thật không thể tưởng tượng được, chúng ta sẽ không thể nói chuyện ngày hôm nay nếu máy in chữ nổi không được phát minh. Micro của chúng ta sẽ không tồn tại. Không có thứ gì xung quanh chúng ta sẽ tồn tại. Sẽ không thể điều phối một nhóm lớn người như vậy nếu điều đó không xảy ra. Và vì vậy, tôi hình dung một thế giới, vài năm nữa trong tương lai, nơi mọi người đều có thể lập trình. Và điều đó sẽ mở khóa điều gì? Bất cứ ai cũng có thể xây dựng phần mềm bất cứ lúc nào. Và tôi không biết.

Tác động của AI và lời khuyên để thành công

Điều này giống như việc vào những năm 1400, không ai có thể dự đoán được điều gì sẽ xảy ra. Tôi nghĩ đây cũng là một trường hợp tương tự. Tuy nhiên, trong thời gian tới, tôi cho rằng nó sẽ rất gây xáo trộn và mang lại nhiều khó khăn cho rất nhiều người. Và một lần nữa, với tư cách là một xã hội, đây là cuộc trò chuyện mà chúng ta cần có và là điều mà chúng ta phải cùng nhau tìm ra giải pháp.

Vậy, đối với những người đang lắng nghe và muốn thành công, muốn trụ vững trong giai đoạn hỗn loạn mà chúng ta đang bước vào, bạn có lời khuyên nào không? Liệu có phải là hãy thử nghiệm với các AI tools, trở nên thành thạo với những công nghệ mới nhất? Có điều gì khác mà bạn khuyên để giúp mọi người đi trước thời đại không?

Chắc chắn rồi, tôi nghĩ đó chính là những gì bạn cần làm. Hãy thử nghiệm với các tools, làm quen với chúng, đừng sợ hãi. Cứ dấn thân vào, thử chúng, đi tiên phong, vươn ra frontier. Có lẽ lời khuyên thứ hai là hãy cố gắng trở thành một generalist (người đa năng) hơn so với trước đây. Ví dụ, trong trường học, rất nhiều người học ngành CS (Khoa học máy tính), họ chỉ học code và không thực sự học nhiều thứ khác. Có thể họ học một chút về systems architecture hoặc những thứ tương tự. Nhưng một số kỹ sư hiệu quả nhất mà tôi làm việc cùng hàng ngày và một số quản lý sản phẩm hiệu quả nhất, họ đều là những người cross-functional (liên chức năng).

Tư duy đa ngành và sự thay đổi vai trò trong tương lai

Ví dụ, trong đội ngũ Claude Code, tất cả mọi người đều code. Quản lý sản phẩm của chúng tôi code, engineering manager của chúng tôi code, designer của chúng tôi code, nhân viên tài chính của chúng tôi code, data scientist của chúng tôi code. Giống như mọi người trong đội đều code. Và khi tôi nhìn vào các kỹ sư cụ thể, mọi người thường giao thoa giữa các lĩnh vực khác nhau. Vì vậy, một số kỹ sư giỏi nhất là những kỹ sư sản phẩm và kỹ sư hạ tầng kết hợp, hoặc kỹ sư sản phẩm với khả năng thiết kế rất tốt và họ cũng có thể thực hiện công việc thiết kế, hoặc một kỹ sư có cảm nhận tốt về business (kinh doanh) và có thể sử dụng điều đó để tìm ra việc cần làm tiếp theo. Hoặc một kỹ sư cũng thích nói chuyện với user (người dùng) và có thể thực sự nắm bắt được điều user muốn để tìm ra hướng đi tiếp theo.

Vì vậy, tôi nghĩ rất nhiều người sẽ được tưởng thưởng nhiều nhất trong vài năm tới, họ sẽ không chỉ là AI-native và không chỉ biết cách sử dụng những tools này thật tốt, mà còn tò mò, là generalist và giao thoa giữa nhiều lĩnh vực, có thể suy nghĩ về vấn đề lớn hơn mà họ đang giải quyết, chứ không chỉ riêng phần engineering.

Bạn có thấy ba lĩnh vực riêng biệt này vẫn hữu ích để suy nghĩ về đội ngũ không? Đó là engineering, design, product management. Bạn có thấy những vai trò đó, mặc dù bây giờ họ đều code và đóng góp vào việc suy nghĩ nên xây dựng gì, bạn có cảm thấy những vai trò đó sẽ tồn tại lâu dài, ít nhất là tại thời điểm này không?

Tôi nghĩ trong ngắn hạn thì chúng sẽ tồn tại, nhưng một điều mà chúng ta bắt đầu thấy là có thể có sự chồng chéo 50% trong các vai trò này, nơi mà rất nhiều người thực sự đang làm cùng một việc và một số người có chuyên môn. Ví dụ, tôi code nhiều hơn một chút so với Cat RPM, người thực hiện nhiều hơn về coordination (phối hợp) hoặc planning (lập kế hoạch) hoặc forecasting (dự báo) hoặc những thứ tương tự.

Stakeholder alignment (Sự đồng thuận của các bên liên quan).

Stakeholder alignment. Chính xác. Tôi thực sự nghĩ rằng có một tương lai mà tôi nghĩ đến cuối năm nay chúng ta sẽ bắt đầu thấy những điều này trở nên murkier (mơ hồ) hơn nữa, nơi mà tôi nghĩ ở một số nơi, chức danh software engineer sẽ bắt đầu biến mất và nó sẽ chỉ được thay thế bằng builder hoặc có thể mọi người sẽ trở thành một product manager và mọi người đều code hoặc những điều tương tự.

Quảng cáo: MetaView - Lợi thế không công bằng trong tuyển dụng

Ai nói việc tuyển dụng phải công bằng? Mọi founder và hiring manager mà tôi nói chuyện gần đây đều cảm thấy cùng một áp lực: tuyển dụng những người giỏi nhất nhanh nhất có thể. Nhưng [nhạc] tuyển dụng tốn thời gian, sự đồng bộ khó khăn, và cạnh tranh cho nhân tài giỏi ngày càng gay gắt. Đó là lý do tại sao các nhóm như 11 Labs, Brex, Replit, Deel và 5.000 [nhạc] tổ chức khác sử dụng MetaView, công ty AI mang lại cho các đội ngũ hiệu suất cao một lợi thế không công bằng thực sự trong tuyển dụng. Họ cung cấp cho bạn một bộ AI agents hoạt động như những đồng nghiệp tuyển dụng. Họ tìm ứng viên cho bạn dựa trên tiêu chí chính xác của bạn, [nhạc] tự động ghi chú phỏng vấn, thu thập thông tin chi tiết trong toàn bộ quy trình tuyển dụng của bạn, và giúp bạn xác định các ứng viên tốt nhất trong pipeline của bạn. AI xử lý công việc tuyển dụng nặng nhọc và cung cấp cho bạn một nguồn thông tin đáng tin cậy. Điều đó có nghĩa là tiết kiệm hàng giờ cho mỗi lần tuyển dụng và một đội ngũ tập trung vào điều quan trọng nhất: giành được [nhạc] các ứng viên phù hợp. Đừng để đối thủ cạnh tranh tuyển dụng giỏi hơn bạn. Khách hàng của MetaView hoàn thành các vị trí nhanh hơn 30%. Hãy dùng thử MetaView ngay hôm nay miễn phí và [nhạc] nhận thêm một tháng tìm kiếm tại metaview.ai/lenny. Đó là tôi. Lenny.

Phản hồi về việc sử dụng công cụ AI: Kỹ sư và PM yêu thích, Designer thì sao?

Bạn đã nói về việc bạn thích coding hơn. Tôi thực sự đã thực hiện một cuộc khảo sát không chính thức nhỏ trên Twitter – tôi không biết bạn có thấy không – nơi tôi chỉ hỏi, tôi đã thực hiện ba cuộc thăm dò khác nhau. Tôi hỏi các kỹ sư, "Bạn có yêu thích công việc của mình nhiều hơn hay ít hơn kể từ khi áp dụng AI tools không?" Và sau đó tôi đã làm một cuộc thăm dò riêng cho PMs và một cho designers. Cả kỹ sư và PMs, 70% số người nói rằng họ yêu thích công việc của mình nhiều hơn, và khoảng 10% nói rằng họ yêu thích công việc của mình ít hơn. Designers, điều thú vị là, chỉ 55% nói rằng họ yêu thích công việc của mình nhiều hơn, và 20% nói rằng họ yêu thích công việc của mình ít hơn. Tôi nghĩ điều đó thực sự thú vị.

Điều đó cực kỳ thú vị. Tôi rất muốn nói chuyện với những người này, cả trong nhóm "thích hơn" và nhóm "ít thích hơn" để hiểu rõ. Bạn đã liên hệ với ai trong số họ chưa?

Một vài người đã trả lời, và chúng tôi thực sự đang thực hiện một cuộc thăm dò tiếp theo mà chúng tôi sẽ liên kết trong phần show notes, đi sâu hơn vào một số điều này. Nhưng có nhiều yếu tố khiến công việc trở nên vui hơn và ít vui hơn. Các designers, họ thực sự không chia sẻ nhiều về lý do tại sao họ lại ít yêu thích công việc của mình hơn. Và tôi không nghe được nhiều. Vì vậy, tôi tò mò điều gì đang diễn ra ở đó.

Vâng.

Vâng, tôi cũng thấy điều này một chút ở Anthropic. Tôi nghĩ mọi người đều khá technical (có chuyên môn kỹ thuật). Đây là điều mà chúng tôi screen (sàng lọc) khi mọi người tham gia. Chúng tôi có rất nhiều cuộc phỏng vấn technical mà mọi người phải trải qua, ngay cả đối với các chức năng không technical. Và các designer của chúng tôi chủ yếu code. Vì vậy, tôi nghĩ đối với họ, đây là điều mà họ đã yêu thích, từ những gì tôi thấy, bởi vì bây giờ thay vì làm phiền các kỹ sư, họ có thể tự mình code. Và ngay cả một số designer trước đây không code cũng đã bắt đầu làm điều đó, và đối với họ thì rất tuyệt vì họ có thể tự mình unblock (gỡ bỏ trở ngại) cho mình. Nhưng tôi thực sự rất muốn nghe thêm kinh nghiệm của mọi người, vì tôi cá là nó không đồng nhất như vậy.

Vâng. Vì vậy, có lẽ nếu bạn đang nghe điều này, hãy để lại bình luận nếu bạn cảm thấy công việc của mình ít vui hơn và ít yêu thích công việc của mình hơn, bởi vì những gì bạn đang nói và những gì tôi nghe từ hầu hết mọi người – 70% PMs và kỹ sư đang yêu thích công việc của mình nhiều hơn. Nếu bạn không thuộc nhóm đó, có lẽ có điều gì đó đang xảy ra.

`Claude Desktop App` và Nguyên tắc `Latent Demand`

Vâng. Chúng tôi cũng thấy rằng mọi người sử dụng các tools khác nhau. Ví dụ, các designer của chúng tôi, họ sử dụng Claude desktop app nhiều hơn để thực hiện coding của họ. Bạn chỉ cần tải xuống desktop app. Có một code tab. Nó nằm ngay cạnh Co-work, và nó thực sự là cùng một Claude Code. Vì vậy, nó giống như cùng một agent và mọi thứ. Chúng tôi đã có điều này trong nhiều tháng. Và vì vậy bạn có thể sử dụng điều này để code theo cách mà bạn không phải mở nhiều terminal, nhưng bạn vẫn có được sức mạnh của Claude Code. Và điều lớn nhất là bạn có thể chạy bao nhiêu Claude sessions song song tùy thích. Chúng tôi gọi đây là multi-quading.

Vì vậy, điều này hơi native (tự nhiên) hơn, tôi nghĩ, đối với những người không phải là kỹ sư. Và thực sự, điều này quay trở lại việc đưa product đến nơi có người dùng. Bạn không muốn bắt mọi người sử dụng một workflow (quy trình làm việc) khác. Bạn không muốn bắt họ phải cố gắng học một điều mới. Dù mọi người đang làm gì, nếu bạn có thể làm cho điều đó dễ dàng hơn một chút, thì đó sẽ là một product tốt hơn nhiều mà mọi người yêu thích hơn. Và đây chính là nguyên tắc latent demand (nhu cầu tiềm ẩn), mà tôi nghĩ là nguyên tắc quan trọng nhất trong product.

Bạn có thể nói về điều đó không, thực sự, bởi vì tôi định nói về nó. Giải thích nguyên tắc này là gì, và điều gì xảy ra khi bạn unlock (khai phá) latent demand này. Latent demand là ý tưởng rằng nếu bạn xây dựng một product theo cách mà nó có thể bị hacked (tấn công) hoặc có thể bị misused (lạm dụng) bởi mọi người – theo một cách mà nó không thực sự được thiết kế để làm – để thực hiện điều gì đó mà họ muốn làm, thì điều này giúp bạn, với tư cách là product builder (người xây dựng sản phẩm), học được nơi để đưa product tiếp theo.

Khai phá `Latent Demand`: Từ `Facebook Marketplace` đến `Co-work`

Một ví dụ về điều này là Facebook Marketplace. Manager của nhóm, Fiona, thực sự là manager sáng lập của nhóm Marketplace, và cô ấy nói về điều này rất nhiều. Facebook Marketplace bắt đầu dựa trên quan sát vào khoảng năm 2016 hoặc tương tự, rằng 40% bài đăng trong Facebook groups là mua và bán đồ. Điều này thật điên rồ. Mọi người đang abusing (lạm dụng) product Facebook groups để mua và bán. Và đó không phải là abuse theo nghĩa security (bảo mật); đó là abuse ở chỗ không ai thiết kế product này cho mục đích đó, nhưng họ đang tự mình tìm ra cách sử dụng vì nó quá useful (hữu ích) cho việc này. Và vì vậy, khá rõ ràng rằng nếu bạn xây dựng một product tốt hơn để cho phép mọi người mua và bán, họ sẽ thích nó. Và rõ ràng là Marketplace sẽ là một hit (thành công lớn) từ điều này. Và vì vậy, điều đầu tiên là các buy and sell groups – các groups có mục đích đặc biệt để cho phép mọi người làm điều đó. Và product thứ hai là Marketplace. Facebook Dating tôi nghĩ cũng bắt đầu ở một nơi khá tương tự.

Và tôi nghĩ quan sát là, nếu bạn nhìn vào profile views – những người nhìn vào profile của nhau trên Facebook – 60% profile views là những người không phải là bạn bè của nhau và khác giới. Vì vậy, đây là một dating setup (cách hẹn hò) truyền thống, nhưng mọi người chỉ đang creeping (theo dõi) nhau. Vì vậy, có lẽ nếu bạn có thể xây dựng một product cho việc này, nó có thể hoạt động. Và vì vậy ý tưởng về latent demand tôi nghĩ là rất mạnh mẽ. Và ví dụ, đây cũng là nơi Co-work ra đời. Chúng tôi thấy rằng trong khoảng sáu tháng qua, rất nhiều người sử dụng Claude Code không dùng nó để code. Có người trên Twitter đã dùng nó để trồng cây cà chua. Có người khác dùng nó để phân tích genome của họ. Có người dùng nó để khôi phục ảnh từ một corrupted hard drive (ổ cứng bị lỗi) – đó là wedding photos (ảnh cưới). Có người dùng nó để phân tích một MRI. Vì vậy, có tất cả những use cases khác nhau này mà không hề technical một chút nào. Và rõ ràng là: mọi người đang phải làm đủ mọi cách để sử dụng terminal để làm điều này. Có lẽ chúng ta nên xây dựng một product cho họ.

Và chúng tôi đã thấy điều này khá sớm, có lẽ vào tháng 5 năm ngoái. Tôi nhớ khi bước vào văn phòng và data scientist của chúng tôi, Brendan, có Claude Code trên máy tính của anh ấy. Anh ấy chỉ đang mở một terminal, và tôi đã rất sốc. Tôi hỏi, "Brendan, anh đang làm gì vậy?" Anh ấy đã tìm ra cách mở terminal, một engineering product (sản phẩm kỹ thuật) đặc thù. Ngay cả rất nhiều kỹ sư cũng không muốn sử dụng terminal. Nó chỉ là cách thấp nhất để thực hiện công việc của bạn – thực sự rất đi sâu vào hoạt động bên trong của máy tính. Và vì vậy, anh ấy đã tìm ra cách sử dụng terminal. Anh ấy đã tải Node.js. Anh ấy đã tải Claude Code, và anh ấy đang thực hiện SQL analysis (phân tích SQL) trong một terminal, và điều đó thật điên rồ. Và sau đó tuần sau, tất cả các data scientist khác cũng đang làm điều tương tự.

Nhu Cầu Tiềm Ẩn (Latent Demand) và Cách Tiếp Cận Phát Triển Sản Phẩm AI

Khi bạn thấy mọi người lạm dụng sản phẩm theo cách không được thiết kế ban đầu để đạt được điều gì đó hữu ích cho họ, đó là một chỉ báo mạnh mẽ cho thấy bạn nên xây dựng một sản phẩm chuyên biệt cho use case đó. Mọi người chắc chắn sẽ yêu thích nó. Tôi nghĩ giờ đây, latent demand có một khía cạnh thứ hai thú vị. Cách tiếp cận truyền thống là quan sát những gì mọi người đang làm, làm cho nó dễ dàng hơn một chút và trao quyền cho họ. Cách tiếp cận hiện đại mà tôi đã thấy trong 6 tháng qua thì hơi khác một chút: hãy xem model đang cố gắng làm gì và làm cho nó dễ dàng hơn.

Khi chúng tôi bắt đầu xây dựng Claude Code, tôi nghĩ rằng cách mọi người tiếp cận việc thiết kế mọi thứ với LLM là họ đặt model vào một hộp và nói: "Đây là ứng dụng tôi muốn xây dựng. Đây là điều tôi muốn nó làm. Model, bạn sẽ thực hiện một thành phần này của nó. Đây là cách bạn sẽ tương tác với các tools và API, v.v.". Đối với Claude Code, chúng tôi đã đảo ngược điều đó. Chúng tôi nói rằng product chính là model. Chúng tôi muốn phơi bày nó, đặt scaffolding tối thiểu xung quanh nó, cung cấp cho nó bộ tools tối thiểu để nó có thể tự mình thực hiện các tác vụ, quyết định tools nào cần chạy và theo thứ tự nào. Tôi nghĩ rằng rất nhiều điều này chỉ dựa trên latent demand về những gì model muốn làm. Trong nghiên cứu, chúng tôi gọi đây là "đang trên distribution" – bạn muốn xem model đang cố gắng làm gì. Về mặt sản phẩm, latent demand chính là khái niệm tương tự nhưng áp dụng cho một model.

Co-work: Phát Triển Nhanh Chóng và Nguyên Tắc Phát Hành Sớm

Bạn đã nói về Co-work. Tôi thấy bạn chia sẻ khi mới ra mắt rằng đội ngũ của bạn đã xây dựng nó chỉ trong 10 ngày. Điều đó thật điên rồ! Tôi nghĩ nó đã được hàng triệu người sử dụng khá nhanh chóng, chỉ trong 10 ngày. Có câu chuyện nào khác ngoài việc "chúng tôi dùng Claude Code để xây dựng nó và thế là xong" không?

Vâng, buồn cười thật. Claude Code, như tôi đã nói, khi chúng tôi phát hành không lập tức trở thành một cú hit. Nó trở thành một cú hit theo thời gian và có một vài điểm uốn (inflection points). Một là khi Opus 4 ra mắt, nó thực sự tạo ra một điểm uốn lớn, và rồi vào tháng 11 nó lại tạo ra một điểm uốn nữa, và nó cứ tiếp tục tăng trưởng. Tốc độ tăng trưởng ngày càng dốc hơn mỗi ngày. Nhưng trong vài tháng đầu tiên, nó không phải là một cú hit. Mọi người có dùng, nhưng nhiều người không thể hình dung ra cách dùng nó. Họ không biết nó dùng để làm gì. Model khi đó vẫn chưa thực sự tốt.

Co-work khi chúng tôi phát hành thì lại lập tức trở thành một cú hit, hơn hẳn Claude Code lúc ban đầu. Thành thật mà nói, phần lớn công lao thuộc về Felix, Sam, Jenny và đội ngũ đã xây dựng nó. Đó thực sự là một đội ngũ cực kỳ mạnh. Và một lần nữa, Co-work ra đời từ latent demand này. Chúng tôi thấy mọi người sử dụng Claude Code cho những việc không liên quan đến kỹ thuật và chúng tôi đang cố gắng tìm hiểu xem nên làm gì. Vì vậy, trong vài tháng, đội ngũ đã khám phá, thử đủ loại lựa chọn khác nhau, và cuối cùng có người nói: "Được rồi, nếu chúng ta chỉ cần lấy Claude Code và đưa nó vào ứng dụng desktop thì sao?". Đó chính là điều đã hiệu quả.

Và thế là trong 10 ngày, họ hoàn toàn sử dụng Claude Code để xây dựng nó. Co-work thực sự có một hệ thống bảo mật rất tinh vi được tích hợp sẵn, về cơ bản là những guard rails để đảm bảo model hoạt động đúng cách, không đi chệch hướng. Ví dụ, chúng tôi đi kèm với một virtual machine hoàn chỉnh. Và Claude Code đã tự viết tất cả codebase này. Vì vậy, chúng tôi chỉ cần suy nghĩ về cách làm cho nó an toàn hơn một chút, tự định hướng hơn một chút cho những người không phải là kỹ sư. Nó đã được triển khai hoàn toàn bằng Claude Code, mất khoảng 10 ngày. Chúng tôi ra mắt sớm. Nó vẫn còn khá thô và chưa hoàn thiện lắm. Nhưng đây là cách chúng tôi học hỏi — cả về mặt product lẫn safety — đó là chúng tôi phải phát hành mọi thứ sớm hơn một chút so với dự kiến để có thể nhận được phản hồi, nói chuyện với người dùng, hiểu được những gì họ muốn, và điều đó sẽ định hình sản phẩm trong tương lai.

Ba Cấp Độ Đảm Bảo An Toàn Mô Hình AI

Vâng, tôi nghĩ điểm đó rất thú vị và độc đáo. Luôn có ý tưởng là phát hành sớm, học hỏi từ người dùng, nhận phản hồi, lặp lại. Việc khó có thể biết AI có khả năng gì và mọi người sẽ cố gắng sử dụng nó như thế nào là một lý do độc đáo để bắt đầu phát hành mọi thứ sớm, điều đó sẽ giúp bạn, như bạn đã mô tả chính xác, hiểu được latent demand trong một thứ mà chúng ta thực sự không biết. Hãy đưa nó ra ngoài và xem mọi người làm gì với nó.

Vâng. Và tại Anthropic, với tư cách là một safety lab, khía cạnh khác của vấn đề đó là safety, bởi vì, bạn biết đấy, khi bạn nghĩ về model safety, có rất nhiều cách khác nhau để nghiên cứu nó. Cấp độ thấp nhất là alignment và mechanistic interpretability. Tức là khi chúng tôi huấn luyện model, chúng tôi muốn đảm bảo nó an toàn. Tại thời điểm này, chúng tôi có công nghệ khá tinh vi để hiểu những gì đang xảy ra trong các neurons để theo dõi nó. Ví dụ, nếu có một neuron liên quan đến sự lừa dối, chúng tôi đang bắt đầu đạt đến điểm có thể theo dõi và hiểu rằng nó đang kích hoạt. Và đây chính là alignment, đây là mechanistic interpretability. Nó giống như lớp thấp nhất.

Lớp thứ hai là evals (đánh giá), và đây về cơ bản là một môi trường phòng thí nghiệm. Model nằm trong một đĩa petri và bạn nghiên cứu nó, bạn đặt nó vào một tình huống tổng hợp và chỉ nói: "Được rồi, model, bạn làm gì và bạn có làm đúng không? Nó có aligned không? Nó có an toàn không?".

Và sau đó, lớp thứ ba là xem model hoạt động như thế nào trong thực tế (in the wild). Khi model trở nên tinh vi hơn, điều này trở nên rất quan trọng bởi vì nó có thể trông rất tốt ở hai lớp đầu tiên nhưng lại không tốt ở lớp thứ ba. Chúng tôi đã phát hành Claude Code rất sớm vì chúng tôi muốn nghiên cứu safety, và chúng tôi thực sự đã sử dụng nó nội bộ tại Anthropic trong khoảng bốn hoặc năm tháng trước khi phát hành, bởi vì chúng tôi không thực sự chắc chắn — đây là agent lớn đầu tiên mà tôi nghĩ mọi người đã phát hành vào thời điểm đó. Nó chắc chắn là coding agent đầu tiên được sử dụng rộng rãi, và vì vậy chúng tôi không chắc liệu nó có an toàn hay không. Vì vậy, chúng tôi thực sự phải nghiên cứu nó nội bộ trong một thời gian dài trước khi cảm thấy hài lòng về điều đó. Và ngay cả từ đó đến nay, chúng tôi đã học được rất nhiều về alignment, rất nhiều về safety mà chúng tôi đã có thể đưa trở lại model, trở lại product.

Đối với Co-work thì khá tương tự. Model ở trong một môi trường mới, nó đang thực hiện những tác vụ không phải là tác vụ kỹ thuật, nó là một agent hoạt động thay mặt bạn. Nó trông tốt về alignment, nó trông tốt về evals. Chúng tôi thử nghiệm nội bộ, nó trông tốt. Chúng tôi thử nghiệm với một vài khách hàng, nó trông tốt. Bây giờ, chúng tôi phải đảm bảo nó an toàn trong thế giới thực. Và đó là lý do tại sao chúng tôi phát hành sớm một chút. Đó là lý do tại sao chúng tôi gọi nó là một research preview. Nhưng vâng, nó không ngừng cải thiện. Và đây thực sự là cách duy nhất để đảm bảo rằng về lâu dài, model được aligned và đang làm đúng việc.

Tính Giải Thích Cơ Chế (Mechanistic Interpretability) và An Toàn Mô Hình

Thật là một lĩnh vực điên rồ mà bạn đang làm việc, nơi có sự cạnh tranh và tốc độ điên cuồng. Đồng thời, có nỗi sợ rằng nếu bạn, bạn biết đấy, vị thần có thể thoát ra và gây tổn hại, và việc tìm kiếm sự cân bằng đó hẳn là rất thách thức. Những gì tôi đang nghe là có ba lớp bạn làm việc với. Có thể là quan sát model suy nghĩ và hoạt động; có các bài kiểm tra eval cho bạn biết điều này đang làm những điều tồi tệ; và sau đó là phát hành sớm. Tôi thực sự chưa nghe nhiều về phần đầu tiên đó. Điều đó thật tuyệt vời. Vậy các bạn có một observability tool có thể cho phép bạn nhìn vào bên trong "não" của model và xem nó đang suy nghĩ như thế nào và đang hướng tới đâu?

Vâng, bạn nên mời Chris Olah tham gia podcast vào một lúc nào đó, bởi vì anh ấy là chuyên gia trong ngành về lĩnh vực này. Anh ấy đã phát minh ra lĩnh vực mà chúng tôi gọi là mechanistic interpretability. Và ý tưởng cốt lõi là, bạn biết đấy, não của bạn là gì? Nó là một tập hợp các neurons được kết nối. Và điều bạn có thể làm là, trong não người hoặc não động vật, bạn có thể nghiên cứu nó ở cấp độ cơ chế này để hiểu các neurons đang làm gì. Điều đáng ngạc nhiên là rất nhiều điều này cũng có thể áp dụng cho model. Vì vậy, model neurons không giống với animal neurons, nhưng chúng hoạt động tương tự nhau theo nhiều cách.

Và vì vậy, chúng tôi đã học được rất nhiều về cách các neurons này hoạt động, về cách một lớp này hoặc một neuron này ánh xạ tới một khái niệm cụ thể, cách các khái niệm được mã hóa, cách model lập kế hoạch, cách nó suy nghĩ trước. Bạn biết đấy, từ rất lâu trước đây, chúng tôi không chắc liệu model chỉ đơn thuần dự đoán next token hay nó đang làm điều gì đó sâu sắc hơn một chút. Bây giờ, tôi nghĩ thực sự có bằng chứng khá mạnh mẽ rằng nó đang làm điều gì đó sâu sắc hơn một chút. Và các cấu trúc để làm điều này hiện nay khá tinh vi, khi các model lớn hơn, không chỉ là một neuron duy nhất tương ứng với một khái niệm. Một neuron có thể tương ứng với hàng tá khái niệm. Và nếu nó được kích hoạt cùng với các neurons khác, điều này được gọi là superposition. Và cùng với nhau, nó đại diện cho một khái niệm tinh vi hơn.

Và đây là điều chúng tôi không ngừng học hỏi. Tại Anthropic, khi chúng tôi suy nghĩ về cách lĩnh vực này phát triển, việc thực hiện điều này một cách an toàn và tốt cho thế giới chính là lý do chúng tôi tồn tại, và đây là lý do tại sao mọi người ở Anthropic đều ở đây. Rất nhiều công việc này chúng tôi thực sự open source. Chúng tôi xuất bản rất nhiều. Và chúng tôi xuất bản rất tự do để nói về điều này, chỉ để chúng tôi có thể truyền cảm hứng cho các labs khác đang làm những điều tương tự để thực hiện nó một cách an toàn. Và đây là điều chúng tôi cũng đã làm cho Claude Code, chúng tôi gọi đây là "cuộc đua lên đỉnh" (race to the top) nội bộ. Ví dụ, đối với Claude Code, chúng tôi đã phát hành một sandbox mã nguồn mở. Đây là một sandbox mà họ có thể chạy agent bên trong, và nó đảm bảo có những boundaries nhất định và nó không thể truy cập mọi thứ trên hệ thống của bạn. Và chúng tôi đã biến nó thành open source và nó thực sự hoạt động với bất kỳ agent nào, không chỉ Claude Code, bởi vì chúng tôi muốn làm cho việc này trở nên thực sự dễ dàng cho những người khác làm điều tương tự. Vì vậy, đây chỉ là nguyên tắc tương tự của "cuộc đua lên đỉnh". Chúng tôi muốn đảm bảo rằng điều này diễn ra tốt đẹp và đây chính là đòn bẩy mà chúng tôi có.

Nỗi Lo Về Năng Suất Khi AI Agent Bị Gián Đoạn

Thật khó tin. Được rồi, tôi chắc chắn muốn dành nhiều thời gian hơn cho điều đó. Tôi sẽ theo dõi với đề xuất này. Một điều khác mà tôi đã nhận thấy trong lĩnh vực này, ở các kỹ sư, quản lý sản phẩm và những người khác làm việc với các agent, là có một loại lo lắng mà mọi người cảm thấy khi agent của họ không hoạt động. Có cảm giác như, "Ôi trời, agent có câu hỏi, mình cần trả lời" hoặc "nó đang bị kẹt ở đâu đó" hoặc "mình đang mất hết productivity này, mình không thể nào, mình cần thức dậy và khởi động lại nó". Bạn có cảm thấy điều đó không? Đội ngũ của bạn có cảm thấy điều đó không? Bạn có cảm thấy đây là một vấn đề chúng ta cần theo dõi và suy nghĩ không?

Tôi luôn có một loạt agent đang chạy. Hiện tại, tôi có khoảng năm agent đang chạy và bất cứ lúc nào, bạn biết đấy, tôi thức dậy và tôi đã lưu một loạt agent.

Kinh nghiệm lập trình với Tác nhân AI

Điều đầu tiên tôi làm khi thức dậy là "Ôi trời, tôi thực sự muốn kiểm tra thứ này". Vì vậy, tôi đã mở ứng dụng Claude iOS app trên điện thoại, vào tab mã, và xem xét hoạt động của tác nhân AI. Tôi đã viết một số code ngày hôm qua và tự hỏi liệu mình có làm đúng không. Tôi đã nghi ngờ một chút nhưng hóa ra là đúng. Nhưng giờ đây, việc kiểm tra này trở nên rất dễ dàng.

Tôi không biết, có một chút lo lắng. Có lẽ cá nhân tôi chưa thực sự cảm thấy điều đó vì tôi luôn có các tác nhân AI chạy mọi lúc. Và tôi cũng không còn bị khóa vào một terminal nữa. Có lẽ một phần ba code của tôi hiện giờ được viết trong terminal, một phần ba dùng ứng dụng máy tính để bàn và một phần ba còn lại dùng ứng dụng iOS. Điều này thật đáng ngạc nhiên vì tôi không nghĩ đây sẽ là cách mình lập trình ngay cả vào năm 2026.

Tôi thích cách bạn vẫn mô tả đó là lập trình, dù thực chất chỉ là nói chuyện với Claude Code để nó lập trình thay bạn. Điều thú vị là giờ đây đây được coi là lập trình. Lập trình bây giờ là mô tả những gì bạn muốn, chứ không phải viết code thực tế.

Tôi tự hỏi, nếu chúng ta cho những người từng lập trình bằng thẻ đục lỗ xem phần mềm hiện đại, họ sẽ nói gì? Thật điên rồ phải không? Tôi nhớ đã đọc một bài viết, có lẽ là từ những phiên bản rất sớm của tạp chí ACM hay gì đó, nơi mọi người nói rằng "không, đó không phải là thứ tương tự, đây không thực sự là lập trình". Và bạn biết đấy, họ gọi đó là programming. Tôi nghĩ coding là một từ khá mới. Nhưng tôi nghĩ đây là một lĩnh vực luôn thay đổi theo cách này.

Chia sẻ cá nhân: Ukraine và Odessa

Anh không biết điều này, nhưng tôi cũng sinh ra ở Ukraine.

À, tôi không biết. Vậy khi nào?

Tôi đến từ Odessa.

Ôi, tôi cũng vậy. (cười)

Cái gì?

Vâng, thật điên rồ.

Wow. Thật khó tin. Một khoảnh khắc đáng nhớ. Có lẽ liên quan một chút.

Anh và gia đình rời đi năm nào?

Chúng tôi đến vào năm 95.

Được rồi. Chúng tôi rời đi năm 88. Sớm hơn một chút.

Ồ, vâng.

Một cuộc sống khác biệt biết bao nếu không rời đi, phải không?

Vâng. Tôi cảm thấy rất may mắn mỗi ngày khi được lớn lên ở đây.

Vâng. Gia đình tôi, bất cứ khi nào có một cái bánh mì nướng hay một bữa ăn, họ chỉ nói "Vì nước Mỹ!". Tôi kiểu "Được rồi, đủ rồi". Nhưng bạn hiểu mà, một khi bạn bắt đầu thực sự nghĩ về cuộc sống có thể đã như thế nào.

Vâng. Vâng. Chính xác. Vâng. Chúng tôi cũng làm bánh mì nướng tương tự, nhưng vẫn là vodka.

Vẫn là vodka. Chắc chắn rồi. (cười)

Lời khuyên xây dựng sản phẩm AI

Được rồi, hãy để tôi hỏi bạn thêm một vài điều ở đây. Bạn đã chia sẻ một số mẹo rất hay về cách tận dụng tối đa AI, cách xây dựng dựa trên AI, cách xây dựng các sản phẩm AI tuyệt vời. Một mẹo bạn chia sẻ là cung cấp cho đội ngũ của bạn càng nhiều tokens càng tốt. Cứ để họ thử nghiệm. Bạn cũng chia sẻ lời khuyên chung là hãy xây dựng hướng tới mô hình mà mô hình đang phát triển tới, chứ không phải mô hình hiện tại. Bạn có lời khuyên nào khác cho những người đang cố gắng xây dựng sản phẩm AI không?

Tôi có lẽ sẽ chia sẻ thêm một vài điều. Thứ nhất là đừng cố gắng đóng khung mô hình. Tôi nghĩ bản năng của rất nhiều người khi xây dựng dựa trên mô hình là họ cố gắng làm cho nó hành xử theo một cách rất cụ thể. Họ coi đây là một thành phần của một hệ thống lớn hơn. Tôi nghĩ một số ví dụ về điều này là mọi người áp đặt các quy trình làm việc rất nghiêm ngặt lên mô hình, ví dụ, bạn phải thực hiện bước một, sau đó bước hai, sau đó bước ba, và bạn có một bộ điều phối rất phức tạp làm điều này. Nhưng thực tế, hầu như luôn luôn bạn sẽ nhận được kết quả tốt hơn nếu bạn chỉ cung cấp cho mô hình các công cụ, cho nó một mục tiêu và để nó tự tìm cách giải quyết. Tôi nghĩ một năm trước bạn thực sự cần rất nhiều giàn giáo nhưng ngày nay bạn không thực sự cần nó nữa.

Vì vậy, bạn biết đấy, tôi không biết gọi nguyên tắc này là gì, nhưng nó giống như "đừng hỏi mô hình có thể làm gì cho bạn". Có lẽ là một cái gì đó như thế này. Hãy suy nghĩ về cách bạn cung cấp cho mô hình các công cụ để làm mọi việc. Đừng cố gắng quản lý quá mức. Đừng cố gắng đóng nó vào một cái hộp. Đừng cố gắng cung cấp cho nó một loạt ngữ cảnh ngay từ đầu. Hãy cung cấp cho nó một công cụ để nó có thể tự lấy ngữ cảnh mà nó cần. Bạn sẽ nhận được kết quả tốt hơn.

Điều thứ hai có lẽ là một phiên bản thậm chí tổng quát hơn của nguyên tắc này, đó chính là The Bitter Lesson. Và thực ra đối với đội ngũ Claude Code, chúng tôi có một điều mà hy vọng người nghe đã đọc, đó là bài đăng trên blog của Rich Sutton cách đây khoảng 10 năm có tên The Bitter Lesson. Và thực ra đó là một ý tưởng rất đơn giản. Ý tưởng của ông là mô hình tổng quát hơn sẽ luôn vượt trội so với mô hình cụ thể hơn, và tôi nghĩ ông ấy đang nói về xe tự lái và các lĩnh vực khác tương tự, nhưng thực ra có rất nhiều hệ quả của The Bitter Lesson. Và đối với tôi, điều lớn nhất chỉ là hãy luôn đặt cược vào mô hình tổng quát hơn và về lâu dài, đừng cố gắng sử dụng các mô hình nhỏ cho công việc. Đừng cố gắng tinh chỉnh. Đừng cố gắng làm bất cứ điều gì trong số này. Có một số trường hợp sử dụng, bạn biết đấy, có một số lý do để làm điều này nhưng hầu như luôn luôn hãy cố gắng đặt cược vào mô hình tổng quát hơn nếu bạn có thể, nếu bạn có sự linh hoạt đó.

Và vì vậy, các quy trình làm việc này về cơ bản là một cách mà, bạn biết đấy, nó không phải là một mô hình tổng quát. Nó đang đặt giàn giáo xung quanh nó. Và nói chung, điều chúng tôi thấy là giàn giáo có thể cải thiện hiệu suất khoảng 10-20% gì đó, nhưng thường thì những lợi ích này sẽ bị xóa sổ khi mô hình tiếp theo ra đời. Vì vậy, tốt hơn hết là chỉ nên đợi cái tiếp theo.

Và tôi nghĩ đây có lẽ là nguyên tắc cuối cùng và là điều mà Claude Code nghĩ rằng đã làm đúng khi nhìn lại. Ngay từ đầu, chúng tôi đã đặt cược vào việc xây dựng cho mô hình của sáu tháng sau, chứ không phải cho mô hình hiện tại. Và đối với các phiên bản rất đầu của sản phẩm, nó chỉ viết rất ít code của tôi vì tôi không tin tưởng nó, bởi vì, bạn biết đấy, nó giống như Sonnet 3.5, sau đó là 3.6 hoặc quên 3.5 new, bất cứ tên nào chúng tôi đặt cho nó. Những mô hình này vẫn chưa giỏi lập trình. Chúng đang dần đạt được điều đó, nhưng vẫn còn khá sớm. Vì vậy, hồi đó mô hình đã làm, bạn đã sử dụng Git cho tôi, nó đã tự động hóa một số thứ nhưng nó thực sự không làm một lượng lớn code của tôi. Và vì vậy, sự đặt cược với Claude Code là tại một thời điểm nào đó, mô hình sẽ đủ tốt để nó có thể viết rất nhiều code.

Và đây là điều mà chúng tôi lần đầu tiên bắt đầu thấy với Opus 4 và Sonnet 4. Opus 4 là mô hình hạng ASL3 đầu tiên của chúng tôi mà chúng tôi phát hành vào tháng 5 và chúng tôi chỉ thấy điểm uốn này bởi vì mọi người bắt đầu sử dụng Claude Code lần đầu tiên và đó là khi sự tăng trưởng của chúng tôi thực sự bùng nổ theo cấp số nhân và như tôi đã nói, nó vẫn ở đó. Vì vậy, tôi nghĩ đây là một số lời khuyên mà tôi thực sự đưa ra cho rất nhiều người, đặc biệt là những người xây dựng startup. Sẽ rất khó chịu vì sự phù hợp sản phẩm với thị trường của bạn sẽ không tốt lắm trong 6 tháng đầu, nhưng nếu bạn xây dựng cho mô hình của 6 tháng tới, khi mô hình đó ra mắt, bạn sẽ lập tức bứt phá và sản phẩm sẽ hoạt động hiệu quả.

Và khi bạn nói xây dựng cho mô hình của 6 tháng tới, bạn nghĩ điều gì sẽ xảy ra? Liệu nó có đơn giản là sẽ làm mọi thứ tốt hơn không? Hay chỉ là "được rồi, nó gần như đủ tốt và đó là dấu hiệu cho thấy nó có thể sẽ tốt hơn ở điều đó"? Có lời khuyên nào về điều đó không?

Tôi nghĩ đó là một cách hay để làm điều đó. Bạn biết đấy, rõ ràng trong một phòng thí nghiệm AI, chúng tôi có thể thấy những cách cụ thể mà nó trở nên tốt hơn. (cười)

Vì vậy, điều đó hơi không công bằng, nhưng chúng tôi cũng cố gắng nói về điều này. Vì vậy, bạn biết đấy, một trong những cách mà nó sẽ trở nên tốt hơn là nó sẽ ngày càng giỏi hơn trong việc sử dụng công cụ và sử dụng máy tính. Đây là một điều mà tôi sẽ đặt cược. Một điều khác là nó sẽ ngày càng tốt hơn trong việc chạy trong thời gian dài. Và đây là một lĩnh vực, bạn biết đấy, có đủ loại nghiên cứu về điều này, nhưng nếu bạn chỉ theo dõi quỹ đạo hoặc, bạn biết đấy, thậm chí từ kinh nghiệm của riêng tôi khi tôi sử dụng Sonnet 3.5 cách đây một năm, nó có thể chạy trong khoảng 15 hoặc 30 giây trước khi bắt đầu đi chệch hướng và bạn thực sự phải hướng dẫn tận tình nó qua bất kỳ nhiệm vụ phức tạp nào. Nhưng ngày nay với Opus 4.6, trung bình nó sẽ chạy khoảng 10, 20, 30 phút mà không cần giám sát và tôi sẽ chỉ khởi động một Claude khác và để nó làm việc khác. Và bạn biết đấy, như tôi đã nói, tôi luôn có một loạt Claude đang chạy. Và chúng cũng có thể chạy hàng giờ hoặc thậm chí hàng ngày. Tôi nghĩ có một số ví dụ mà chúng đã chạy trong nhiều tuần. Và vì vậy tôi nghĩ theo thời gian điều này sẽ trở nên ngày càng bình thường hơn khi các mô hình chạy trong một khoảng thời gian rất dài và bạn không phải ngồi đó và theo dõi sát sao chúng nữa.

Lời khuyên sử dụng Claude Code hiệu quả

Vì vậy, chúng ta vừa nói về các mẹo để xây dựng sản phẩm AI. Có mẹo nào cho người mới sử dụng Claude Code lần đầu hoặc người đã sử dụng Claude Code muốn trở nên giỏi hơn không? Bạn có thể chia sẻ một vài mẹo chuyên nghiệp nào không?

Tôi sẽ đưa ra một lưu ý: không có một cách đúng duy nhất để sử dụng Claude Code. Vì vậy, tôi có thể chia sẻ một số mẹo nhưng thành thật mà nói, đây là một công cụ dành cho developer. Các developer đều khác nhau. Các developer có những sở thích khác nhau. Họ có môi trường khác nhau. Vì vậy, có rất nhiều cách để sử dụng các công cụ này. Không có một cách đúng duy nhất. Bạn phải tự tìm ra con đường của riêng mình. May mắn thay, bạn có thể hỏi Claude Code. Nó có thể đưa ra các đề xuất. Nó có thể chỉnh sửa cài đặt của bạn. Nó hiểu về bản thân nó. Vì vậy, nó có thể giúp ích trong việc đó.

Một vài mẹo mà tôi thấy khá hữu ích nói chung. Thứ nhất là hãy sử dụng mô hình mạnh nhất. Hiện tại đó là Opus 4.6. Tôi luôn bật "tối đa nỗ lực". Điều xảy ra là đôi khi mọi người cố gắng sử dụng một mô hình ít tốn kém hơn như Sonnet hoặc tương tự. Nhưng vì nó kém thông minh hơn, cuối cùng nó lại tốn nhiều tokens hơn để thực hiện cùng một nhiệm vụ. Và vì vậy, thực ra không rõ ràng rằng việc sử dụng một mô hình ít tốn kém hơn là rẻ hơn. Thường thì nó thực sự rẻ hơn và ít tốn tokens hơn nếu bạn sử dụng mô hình mạnh nhất vì nó có thể làm cùng một việc nhanh hơn nhiều với ít phải sửa lỗi hơn, ít phải hướng dẫn tận tình hơn, v.v. Vì vậy, mẹo đầu tiên là hãy sử dụng mô hình tốt nhất.

Mẹo thứ hai là sử dụng chế độ lập kế hoạch (plan mode). Tôi bắt đầu gần như tất cả các tác vụ của mình trong chế độ lập kế hoạch, có lẽ khoảng 80%. Và chế độ lập kế hoạch thực sự rất đơn giản. Tất cả những gì nó làm là chúng tôi đưa một câu vào câu lệnh/lời nhắc của mô hình để nói: "Vui lòng chưa viết bất kỳ code nào". Chỉ vậy thôi. Không có gì phức tạp đang diễn ra. Đó chỉ là điều đơn giản nhất.

Và đối với những người trong terminal, chỉ cần nhấn Shift + Tab hai lần là bạn sẽ vào chế độ lập kế hoạch. Đối với những người trong ứng dụng máy tính để bàn, có một nút nhỏ. Trên web, có một nút nhỏ. Nó sẽ sớm có mặt trên di động nữa.

Chế độ Lập kế hoạch và Đa dạng Giao diện

Chúng tôi cũng vừa triển khai chế độ lập kế hoạch cho tích hợp Slack. Chế độ lập kế hoạch hoạt động như sau: mô hình sẽ tương tác qua lại với bạn. Khi bản kế hoạch đã được duyệt, bạn cho phép mô hình thực thi. Tôi sẽ tự động chấp nhận các chỉnh sửa sau đó, bởi vì nếu kế hoạch đã tốt, nó sẽ thực hiện chỉ trong một lần duy nhất. Với Opus 4.6, mô hình sẽ làm đúng ngay từ lần đầu tiên hầu như mọi lúc.

Mẹo thứ ba có lẽ là hãy thử nghiệm với các giao diện khác nhau. Tôi nghĩ nhiều người khi nghĩ về Claude Code thì nghĩ ngay đến terminal. Tất nhiên, chúng tôi hỗ trợ mọi terminal, như Mac, Windows, hay bất kỳ terminal nào bạn có thể sử dụng, nó đều hoạt động hoàn hảo. Nhưng chúng tôi thực sự hỗ trợ rất nhiều kiểu dáng thiết bị khác, ví dụ như chúng tôi có các ứng dụng iOS và Android, ứng dụng máy tính để bàn, tích hợp Slack và nhiều thứ khác nữa. Vì vậy, tôi khuyên bạn nên thử nghiệm với những giao diện này. Một lần nữa, mỗi kỹ sư là khác nhau, mỗi người xây dựng đều khác nhau. Chỉ cần tìm thứ phù hợp với bạn và sử dụng nó. Bạn không nhất thiết phải dùng terminal; đó vẫn là cùng một tác nhân Claude (Claude agent) đang chạy ở mọi nơi.

Quan điểm về Codex và Phương pháp Phát triển Sản phẩm

Người phỏng vấn: Tuyệt vời. Vài câu hỏi nữa để kết thúc. Bạn nghĩ gì về Codex? Cảm nhận của bạn về sản phẩm đó? Về hướng đi của họ? Và việc họ cạnh tranh trong không gian rất cạnh tranh này với các tác nhân lập trình (coding agents)?

Boris: Thực ra tôi chưa thực sự sử dụng nó, nhưng tôi nghĩ mình đã dùng nó khi nó mới ra mắt. Nó trông khá giống Claude Code đối với tôi, điều đó khá là thú vị. Tôi nghĩ việc có nhiều cạnh tranh hơn là tốt, vì mọi người nên có quyền lựa chọn, và hy vọng điều đó sẽ thúc đẩy tất cả chúng ta làm tốt hơn nữa. Thành thật mà nói, đối với đội ngũ của chúng tôi, chúng tôi chỉ tập trung vào việc giải quyết các vấn đề mà người dùng gặp phải. Vì vậy, chúng tôi không dành nhiều thời gian để xem xét các sản phẩm cạnh tranh. Chúng tôi không thực sự thử các sản phẩm khác. Bạn biết đấy, bạn muốn biết về sự tồn tại của chúng, nhưng đối với tôi, tôi chỉ thích nói chuyện với người dùng, thích cải thiện sản phẩm và hành động dựa trên phản hồi. Vì vậy, mọi thứ thực sự chỉ xoay quanh việc xây dựng một sản phẩm tốt.

Kế hoạch sau AGI: Cuộc sống ở Nhật Bản và Niềm đam mê Miso

Người phỏng vấn: Có lẽ là câu hỏi cuối cùng. Tôi đã nói chuyện với Ben Mann, đồng sáng lập của Anthropic. Anh ấy có nhiều gợi ý mà tôi đã tích hợp trong cuộc trò chuyện của chúng ta. Một câu hỏi anh ấy dành cho bạn là kế hoạch của bạn sau AGI là gì? Bạn nghĩ mình sẽ làm gì? Cuộc sống của bạn sẽ thế nào khi chúng ta đạt đến AGI, dù điều đó có ý nghĩa gì đi nữa?

Boris: Trước khi tôi gia nhập Anthropic, tôi sống ở vùng nông thôn Nhật Bản, và đó là một lối sống hoàn toàn khác. Tôi là kỹ sư duy nhất trong thị trấn, là người nói tiếng Anh duy nhất. Đó là một cảm giác hoàn toàn khác. Vài lần một tuần, tôi đạp xe đến chợ nông sản. Bạn đạp xe qua những cánh đồng lúa và nhiều thứ khác. Đó là một nhịp sống hoàn toàn khác, hoàn toàn đối lập với San Francisco. Một trong những điều tôi thực sự thích là cách chúng tôi làm quen với hàng xóm và xây dựng tình bạn là thông qua việc trao đổi dưa muối. Ở thị trấn chúng tôi sống, mọi người đều làm miso, mọi người đều làm dưa muối. Và tôi đã trở nên khá giỏi làm miso. Tôi đã làm nhiều mẻ, và đây là thứ tôi vẫn làm. Miso là một điều thú vị, nó dạy bạn suy nghĩ bằng những kỹ năng dài hạn (longtime skills). Điều đó rất khác so với kỹ thuật, vì một mẻ miso trắng mất ít nhất ba tháng để làm, còn miso đỏ thì mất hai, ba, bốn năm. Bạn phải rất kiên nhẫn. Bạn trộn nó lên rồi cứ để nó ở đó. Bạn phải cực kỳ, cực kỳ kiên nhẫn.

Điều tôi yêu thích về nó chính là việc suy nghĩ bằng những kỹ năng dài hạn này. Và vâng, tôi nghĩ sau AGI, hoặc nếu tôi không làm việc ở Anthropic, có lẽ tôi sẽ làm miso. [tiếng cười]

Người phỏng vấn: Tôi yêu câu trả lời này. Ben đã nhờ tôi hỏi bạn về chuyện gì với bạn và miso, vì vậy tôi rất thích cách bạn đã trả lời. Được rồi, vậy tương lai có thể là đi sâu vào việc làm miso, trở nên thực sự giỏi trong việc làm miso. Thật tuyệt vời. Boris, buổi nói chuyện này thật đáng kinh ngạc. Tôi cảm thấy chúng ta như những người anh em từ Ukraine vậy. Trước khi đến với phần Lightning Round (Vòng hỏi nhanh) rất thú vị, bạn còn muốn chia sẻ điều gì khác không? Có điều gì bạn muốn nhắn gửi đến người nghe không? Điều gì bạn muốn nhấn mạnh thêm?

Boris: Vâng, tôi nghĩ tôi chỉ muốn nhấn mạnh rằng đối với Anthropic, ngay từ đầu, ý tưởng bắt đầu với lập trình (coding), sau đó đến sử dụng công cụ (tool use), rồi đến sử dụng máy tính đã luôn là cách chúng tôi suy nghĩ. Và đây là cách chúng tôi biết các mô hình sẽ phát triển, hoặc cách chúng tôi muốn xây dựng các mô hình của mình. Đây cũng là cách chúng tôi học hỏi về an toàn, nghiên cứu và cải thiện nó tốt nhất. Vì vậy, mọi thứ đang diễn ra hiện nay, xung quanh việc Claude Code trở thành một doanh nghiệp (business) khổng lồ trị giá nhiều tỷ đô la, và bây giờ tất cả bạn bè của tôi đều dùng Claude Code và họ nhắn tin cho tôi về nó liên tục. Vì vậy, việc điều này trở nên lớn mạnh theo một số cách là một bất ngờ hoàn toàn, bởi vì chúng tôi không biết đây sẽ là sản phẩm đó. Chúng tôi không biết nó sẽ bắt đầu trong một terminal hay bất cứ điều gì như thế này. Nhưng theo một số cách, điều đó hoàn toàn không đáng ngạc nhiên, bởi vì đây đã là niềm tin của chúng tôi với tư cách là một công ty trong một thời gian dài. Đồng thời, nó vẫn cảm thấy rất sớm, bạn biết đấy, hầu hết thế giới vẫn chưa sử dụng Claude Code. Hầu hết thế giới vẫn chưa sử dụng AI. Vì vậy, cảm giác như đây mới chỉ hoàn thành 1% và còn rất nhiều điều phải làm.

Thành công của Claude Code và Tầm nhìn tương lai

Người phỏng vấn: Vâng. Thật điên rồ khi nghĩ về những con số đang được công bố. Các bạn vừa huy động được một khoản tiền khổng lồ. Tôi nghĩ riêng Claude Code đã tạo ra 2 tỷ đô la doanh thu. Tôi nghĩ con số mà các bạn công bố cho Anthropic là 15 tỷ đô la doanh thu. Thật điên rồ khi nghĩ rằng mọi thứ vẫn còn rất sớm và những con số chúng ta đang thấy.

Boris: Vâng. Vâng. Vâng. Thật điên rồ. Và ý tôi là, cách Claude Code tiếp tục phát triển thực sự chỉ là nhờ người dùng. Rất nhiều người sử dụng nó. Họ rất đam mê nó. Họ yêu thích sản phẩm và sau đó họ kể cho chúng tôi về những điều không hoạt động, những điều họ muốn. Và vì vậy, lý do duy nhất khiến nó tiếp tục cải thiện là vì mọi người đang sử dụng nó. Mọi người đang nói về nó. Mọi người liên tục đưa ra phản hồi, và đây là điều quan trọng nhất. Và bạn biết đấy, đối với tôi, đây là cách tôi thích dành cả ngày của mình: nói chuyện với người dùng và làm cho nó tốt hơn cho họ.

Người phỏng vấn: ... và làm miso.

Boris: ... và làm miso. Chà, miso thì không quá phức tạp, bạn chỉ cần đợi thôi, chỉ cần đợi.

Lightning Round: Sách, Phim và TV Show Yêu thích

Người phỏng vấn: Vâng Boris, với điều đó, chúng ta đã đến phần Lightning Round (Vòng hỏi nhanh) rất thú vị. Tôi có năm câu hỏi dành cho bạn, bạn đã sẵn sàng chưa?

Boris: Hãy bắt đầu thôi!

Người phỏng vấn: 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?

Boris: Tôi là một người thích đọc. Tôi sẽ bắt đầu với một cuốn sách kỹ thuật: đó là "Functional Programming in Scala". Đây là cuốn sách kỹ thuật hay nhất mà tôi từng đọc. Nó rất lạ vì có thể bạn sẽ không sử dụng Scala, và tôi không biết điều này còn quan trọng đến mức nào trong tương lai, nhưng có một sự thanh lịch nhất định trong lập trình chức năng (functional programming) và tư duy kiểu (thinking in types), và đây là cách tôi lập trình và cách tôi không thể ngừng suy nghĩ về lập trình. Vì vậy, bạn có thể coi nó là một hiện vật lịch sử. Bạn có thể coi nó là thứ sẽ nâng tầm bạn.

Người phỏng vấn: Tôi yêu cuốn sách chưa từng được nhắc đến này. Cuốn sách yêu thích của tôi.

Boris: Ồ, tuyệt vời. Tuyệt vời. Được rồi. Cuốn thứ hai là "Accelerando" của Charles Stross. Đây có lẽ là thể loại chính của tôi, khoa học viễn tưởng (sci-fi). "Accelerando" là một cuốn sách đáng kinh ngạc, và nó có nhịp độ rất nhanh. Tốc độ ngày càng nhanh hơn, nhanh hơn và nhanh hơn. Tôi cảm thấy nó nắm bắt được bản chất của khoảnh khắc chúng ta đang sống hơn bất kỳ cuốn sách nào khác mà tôi đã đọc. Chỉ riêng tốc độ của nó. Nó bắt đầu khi một sự cất cánh đang diễn ra và đang tiến gần đến điểm kỳ dị (singularity), và nó kết thúc với một ý thức tập thể của tôm hùm đang bay quanh Sao Mộc. Và điều này xảy ra trong khoảng vài thập kỷ. Vì vậy, nhịp độ thật đáng kinh ngạc. Tôi thực sự yêu thích nó.

Có lẽ tôi sẽ giới thiệu thêm một cuốn sách nữa. Đó là "The Wandering Earth" của Cixin Liu. Anh ấy là tác giả của "The Three-Body Problem", tôi nghĩ nhiều người biết anh ấy qua tác phẩm đó. Tôi thực sự nghĩ "The Three-Body Problem" rất tuyệt vời, nhưng tôi thích những truyện ngắn của anh ấy hơn. "The Wandering Earth" là một trong những tập truyện ngắn và nó có một số câu chuyện thực sự tuyệt vời. Nó cũng khá thú vị khi xem khoa học viễn tưởng Trung Quốc vì nó có một góc nhìn rất khác so với khoa học viễn tưởng phương Tây và cách mà ít nhất anh ấy với tư cách là một nhà văn suy nghĩ về nó. Vì vậy, nó thực sự rất thú vị để đọc và được viết rất đẹp.

Thật thú vị khi khoa học viễn tưởng đã chuẩn bị cho chúng ta cách suy nghĩ về nơi mọi thứ đang diễn ra. Giống như nó tạo ra những mô hình này: "À, tôi hiểu, tôi đã đọc về thế giới kiểu này." Vâng. Tôi nghĩ đối với tôi, đây là lý do tôi gia nhập Anthropic. Bạn biết đấy, như tôi đã nói, tôi sống ở một vùng nông thôn này. Tôi suy nghĩ bằng những kỹ năng dài hạn vì mọi thứ ở đó rất chậm, ít nhất là so với SF. Và tất cả những gì bạn làm đều xoay quanh các mùa và dựa trên những loại thực phẩm mất nhiều tháng để chế biến. Đó là cách các sự kiện xã hội được tổ chức, cách bạn sắp xếp thời gian của mình. Bạn đi chợ nông sản và đó là mùa hồng, và bạn biết điều đó vì có khoảng 20 người bán hồng, sau đó tuần tới mùa hồng kết thúc và đó là mùa nho. Vì vậy, đó là những kỹ năng dài hạn và tôi cũng đọc rất nhiều khoa học viễn tưởng vào thời điểm đó. Và khi ở trong khoảnh khắc này, tôi đã suy nghĩ về những thang thời gian dài (long time scales) này. Tôi biết điều này có thể diễn ra như thế nào, và tôi cảm thấy mình phải đóng góp để nó diễn ra tốt đẹp hơn một chút, và đó thực sự là lý do tại sao tôi cuối cùng lại ở Anthropic, và Ben Mann cũng là một phần lớn trong đó.

Người phỏng vấn: Tôi cảm thấy muốn làm một podcast riêng chỉ để nói về thời gian của bạn ở Nhật Bản và hành trình của Boris qua Nhật Bản đến Anthropic, nhưng chúng ta sẽ giữ nó ngắn gọn. Tôi sẽ nhanh chóng giới thiệu cho bạn một cuốn sách khoa học viễn tưởng nếu bạn chưa đọc nó. Bạn đã đọc "A Fire Upon the Deep" chưa?

Boris: À, đây là của Vinge, phải không? Vâng. Tuyệt vời.

Người phỏng vấn: Đúng vậy. Được rồi. Cuốn đó rất thú vị từ góc độ AI và AGI. Rất ít người đã đọc nó.

Boris: Vâng, nó khá dài.

Người phỏng vấn: Vâng, vâng, vâng. Tôi cũng thích "A Deepness in the Sky". Tôi nghĩ đó là phần tiếp theo, phải không?

Boris: Vâng.

Người phỏng vấn: Vâng, vâng, vâng. Tôi nghĩ vậy.

Boris: Vâng. Nó rất dài và phức tạp để bắt đầu, nhưng rất hay. Được rồi. Chúng ta sẽ tiếp tục phần Lightning Round. Bạn có bộ phim hoặc chương trình TV gần đây nào yêu thích không?

Boris: Thực ra tôi không thực sự xem TV hay phim. Tôi không có nhiều thời gian dạo này. Tuy nhiên, tôi đã xem loạt phim "The Three-Body Problem" trên Netflix của Cixin Liu, và tôi thực sự rất thích. Tôi nghĩ đó là một phiên bản chuyển thể tuyệt vời từ loạt sách.

Người phỏng vấn: Vậy là một mẫu số chung của các lãnh đạo AI (AI leaders) là không có thời gian xem TV hoặc phim, điều mà tôi hoàn toàn hiểu.

Sản phẩm và nội dung yêu thích

Có sản phẩm yêu thích nào mà bạn mới khám phá gần đây không? Tôi sẽ thư giãn một chút và nói là Co-work vì đây thực sự là sản phẩm duy nhất đã thay đổi cuộc sống của tôi. Đơn giản vì tôi để nó chạy liên tục, và đặc biệt là tích hợp Chrome của nó rất xuất sắc. Nó đã giúp tôi thanh toán tiền phạt giao thông, hủy một vài gói đăng ký. Lượng công việc nhàm chán mà nó xử lý được thật tuyệt vời.

Tôi cũng không biết đây có phải là một sản phẩm không, nhưng tôi cũng muốn giới thiệu một podcast khác mà tôi thực sự yêu thích, tất nhiên ngoài podcast của Venny, đó là podcast Acquired của Ben và David. Nó thật sự rất tuyệt vời. Tôi cảm thấy cách họ đi sâu vào lịch sử kinh doanh và làm cho nó sống động thực sự rất hay. Tôi khuyên bạn nên bắt đầu với tập về Nintendo nếu bạn chưa nghe.

Sức mạnh và tiềm năng của AI Agent qua Co-work

Với Co-work, để mọi người hiểu rõ hơn nếu họ chưa thử: về cơ bản, bạn gõ yêu cầu công việc, và nó có thể mở Chrome để thực hiện mọi thứ cho bạn. Tôi thấy một người khi nghỉ thai sản từ Anthropic đã dùng nó để điền các biểu mẫu y tế cho anh ấy – những tệp PDF cực kỳ khó chịu mà nó chỉ cần mở trình duyệt, đăng nhập, điền và gửi.

Chính xác. Và nó thực sự hoạt động tốt. Chúng tôi đã thử nghiệm điều này khoảng một năm trước và nó không thực sự hiệu quả vì mô hình chưa sẵn sàng, nhưng bây giờ thì nó đã hoạt động. Thật tuyệt vời. Tôi nghĩ nhiều người chưa thực sự hiểu nó là gì vì họ chưa từng sử dụng AI Agent trước đây. Đối với tôi, nó cảm giác rất giống với Claude Code một năm trước. Nhưng như tôi đã nói, nó đang phát triển nhanh hơn nhiều so với Claude Code trong giai đoạn đầu. Vì vậy, tôi nghĩ nó đang bắt đầu tạo ra bước đột phá.

Cũng có tiện ích mở rộng Chrome mà bạn đã đề cập, bạn có thể sử dụng độc lập, nó nằm trong Chrome và bạn có thể trò chuyện với Claude trong khi nhìn vào màn hình trình duyệt của bạn, nhờ nó làm việc, kể cho bạn về những gì bạn đang xem, tóm tắt những gì bạn đang xem, và những việc tương tự.

Lời khuyên cho người mới dùng Co-work

Đối với những người mới bắt đầu sử dụng Co-work, điều tôi khuyên là: bạn tải ứng dụng Claude Desktop, vào tab Co-work. Nó nằm ngay cạnh tab Code. Điều tôi khuyên là hãy bắt đầu bằng cách nhờ nó sử dụng một tool. Ví dụ như dọn dẹp màn hình nền, tóm tắt email, hoặc bạn biết đấy, trả lời ba email hàng đầu – giờ đây nó cũng tự động trả lời email cho tôi.

Điều thứ hai là kết nối các tool. Ví dụ, nếu bạn kết nối, bạn nói 'hãy xem các email quan trọng của tôi' rồi 'gửi tin nhắn Slack' hoặc 'đưa chúng vào một bảng tính' chẳng hạn. Hay như tôi dùng nó cho toàn bộ project management của mình. Chúng tôi có một bảng tính chung cho cả nhóm. Có một hàng cho mỗi kỹ sư. Mỗi tuần, mọi người điền trạng thái công việc và mỗi thứ Hai, Co-work sẽ kiểm tra và gửi tin nhắn Slack cho mọi kỹ sư chưa điền trạng thái, nên tôi không cần làm việc này nữa. Và đây chỉ là một câu lệnh/lời nhắc. Nó sẽ làm tất cả.

Và điều thứ ba là chạy nhiều phiên bản Claude song song. Với Co-work, bạn có thể chạy bao nhiêu tác vụ tùy thích. Chẳng hạn, tôi bắt đầu một tác vụ, ví dụ, tôi có tác vụ project management đang chạy, sau đó tôi sẽ nhờ nó làm việc khác, rồi việc khác nữa, tôi khởi động chúng và sau đó tôi đi uống cà phê trong khi nó chạy. Có một bài đăng mà tôi sẽ đính kèm, chia sẻ nhiều cách mọi người sử dụng cái mà trước đây là Claude Code và bây giờ có thể thực hiện thông qua Co-work, bởi vì nhiều người đã thốt lên 'Ồ wow, tôi chưa từng nghĩ mình có thể dùng nó cho việc đó!' Và một khi bạn thấy những ví dụ này, tôi nghĩ đó là điều mọi người cần nghe, kiểu như 'Ồ wow, tôi không biết mình có thể làm được điều đó!'

Bài học từ cộng đồng và đánh giá sản phẩm

Vâng, tôi nghĩ nhiều điều này cũng được lấy cảm hứng từ bạn, Venny. Bạn đã có một bài đăng về, à, hình như là '50 trường hợp sử dụng phi kỹ thuật cho Claude' hay gì đó tương tự. Vậy thì thực ra, một trong những quản lý sản phẩm của chúng tôi đã dùng bài đăng đó để đánh giá Co-work trước khi chúng tôi phát hành. Và tôi nghĩ đến thời điểm mà Co-work có thể thực hiện 48 trong số 50 trường hợp sử dụng đó, họ đã nói, 'Được rồi, khá tốt đấy.'

Chà. Tôi không biết điều đó. Thật [tiếng cười] tuyệt vời. À, tôi đã trở thành một người đánh giá. Cảm giác thế nào? Tuyệt vời. Tôi cảm thấy mình có giá trị cho tương lai của trí tuệ nhân tạo (AI). Đây giống như là bước đột phá ngược vậy. [tiếng cười] Chà, thật tuyệt vời. Wow. Được rồi. Tôi tự hỏi hai điều cuối cùng là gì. Dù sao đi nữa, được rồi, hai câu hỏi nữa.

Phương châm sống: Áp dụng lẽ thường

Bạn có phương châm sống yêu thích nào mà bạn thường áp dụng trong công việc hay cuộc sống không? Hãy sử dụng lẽ thường (common sense). Tôi nghĩ rất nhiều thất bại mà tôi thấy, đặc biệt trong môi trường làm việc, là do mọi người không sử dụng lẽ thường. Họ tuân theo một quy trình mà không suy nghĩ. Họ cứ làm một việc mà không suy nghĩ, hoặc họ đang làm một sản phẩm không tốt hoặc một ý tưởng không hay, và họ cứ theo đà mà không suy nghĩ. Tôi nghĩ những kết quả tốt nhất mà tôi thấy là khi mọi người suy nghĩ từ nguyên tắc đầu tiên (first principles) và tự phát triển lẽ thường của riêng mình. Giống như nếu có điều gì đó cảm thấy kỳ lạ, thì bạn biết rằng đó có thể không phải là một ý tưởng hay. Vì vậy, tôi nghĩ đây là lời khuyên duy nhất mà tôi dành cho đồng nghiệp hơn bất cứ điều gì khác.

Tôi cảm thấy riêng điều đó cũng có thể là một cuộc trò chuyện podcast riêng: Lẽ thường là gì? Làm thế nào để xây dựng nó? Nhưng chúng ta sẽ giữ cuộc trò chuyện này ngắn gọn. Câu hỏi cuối cùng. Bạn đã hoạt động tích cực hơn trên Twitter/X. Tôi tò mò tại sao, và trải nghiệm của bạn với Twitter, thế giới Twitter, như thế nào? Bởi vì bạn nhận được rất nhiều tương tác trên Twitter/X.

Tương tác trên Twitter/X và tầm quan trọng của phản hồi

Vậy trong một thời gian dài, tôi đã sử dụng Threads độc quyền vì thực ra tôi đã giúp xây dựng Threads một chút vào thời điểm đó. Và tôi cũng thích thiết kế của nó; đó là một sản phẩm rất gọn gàng. Tôi thực sự thích điều đó. Tôi bắt đầu dùng Twitter vì tôi chán. Vợ tôi và tôi đang đi du lịch khắp châu Âu vào tháng 12. Chúng tôi chỉ kiểu nomading (du mục kỹ thuật số) quanh đó. Chúng tôi đến Copenhagen, đến một vài quốc gia khác nhau. Và đối với tôi, đó chỉ là một kỳ nghỉ coding. Vậy mỗi ngày tôi coding, và đó là kiểu kỳ nghỉ yêu thích của tôi, chỉ để code cả ngày. Thật tuyệt vời.

Và đến một lúc nào đó, tôi hơi chán và hết ý tưởng trong vài giờ. Tôi tự hỏi, 'Được rồi, tôi muốn làm gì tiếp theo?' Và thế là tôi mở Twitter. Tôi thấy một số người tweet về Claude Code, và sau đó tôi bắt đầu trả lời. Và rồi tôi nghĩ, 'Được rồi, có lẽ điều tôi nên làm là tìm kiếm lỗi mà mọi người gặp phải, có thể mọi người có lỗi hoặc loại phản hồi nào đó.' Và thế là tôi tự giới thiệu, hỏi xem mọi người có nhiều lỗi và phản hồi không. Và tôi nghĩ họ khá ngạc nhiên về tốc độ mà chúng tôi có thể xử lý phản hồi ngày nay. Đối với tôi, điều đó rất bình thường. Giống như nếu ai đó có lỗi, tôi có thể khắc phục nó trong vài phút vì tôi chỉ cần dùng Claude, và miễn là mô tả tốt, nó sẽ tự động làm, và sau đó tôi sẽ làm việc khác và trả lời câu hỏi tiếp theo. Nhưng tôi nghĩ đối với nhiều người, điều đó khá ngạc nhiên. Vì vậy, điều đó thực sự tuyệt vời và vâng, trải nghiệm trên Twitter rất tốt. Thật tuyệt khi được tương tác với mọi người và xem họ muốn gì, nghe về lỗi, nghe về tính năng. Tôi thấy những lời phàn nàn gửi đến Nikita Beer hôm nọ trên Twitter về việc họ đăng nhiều luồng (thread) và nó bị lỗi, và tôi đã nghĩ 'Trời ơi, chuyện gì đang xảy ra vậy?'

Vâng. Vâng. Có một lỗi. Tôi hy vọng bây giờ nó đã được sửa.

Kêu gọi hành động và thông tin liên hệ

Tuyệt vời. Ôi Boris, tôi có thể trò chuyện với bạn hàng giờ. Tôi sẽ để bạn đi. Cảm ơn bạn rất nhiều vì đã tham gia. Bạn thật tuyệt vời. Mọi người có thể tìm bạn ở đâu trực tuyến? Làm thế nào để người nghe có thể hỗ trợ bạn?

Vâng, tìm tôi trên Threads hoặc trên Twitter. Đó là nơi dễ nhất. Và làm ơn hãy tag tôi vào các bài viết. Gửi lỗi, gửi yêu cầu tính năng, những gì còn thiếu, chúng tôi có thể làm gì để sản phẩm tốt hơn? Bạn thích gì? Bạn muốn gì? Tôi rất, rất thích nghe những điều đó.

Lời kết từ host

Tuyệt vời. Boris, cảm ơn bạn rất nhiều vì đã ở đây. Tuyệt. Cảm ơn, Venny. Tạm biệt mọi người.

Cảm ơn bạn rất nhiều đã lắng nghe. Nếu bạn thấy nội dung này có giá trị, bạn có thể đăng ký kênh 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 người nghe 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 bạn trong tập tiếp theo.

TL;DR

Trí tuệ nhân tạo (AI), đặc biệt là Claude Code, đang thay đổi cơ bản cách thức lập trình, cho phép các kỹ sư không cần viết mã thủ công và tăng năng suất lên đáng kể (ví dụ 200%).
Vai trò của kỹ sư phần mềm đang chuyển dịch từ người viết mã sang "người xây dựng" hoặc "quản lý sản phẩm," tập trung vào ý tưởng và thiết kế, trong khi AI đảm nhiệm các chi tiết triển khai và sửa lỗi.
Sự phát triển của AI trong lĩnh vực này diễn ra nhanh chóng một cách "cấp số nhân", với bằng chứng là tỷ lệ commit do AI tạo ra trên GitHub tăng vọt, cho thấy một sự thay đổi toàn diện trong ngành kỹ thuật phần mềm.

Điểm chính

Tự động hóa mã nguồn hoàn toàn: Một số kỹ sư cấp cao đã không còn viết mã thủ công, với AI tạo ra 100% code và xử lý các pull request, cho thấy tiềm năng tự động hóa gần như hoàn toàn quá trình viết code.
Chuyển đổi vai trò kỹ sư: Vai trò "kỹ sư phần mềm" đang mờ nhạt, thay thế bằng "builder" hoặc "product manager," nơi trọng tâm dịch chuyển từ việc viết code sang thiết kế hệ thống, quản lý sản phẩm và ý tưởng.
AI Agent và Tool Use: Các mô hình AI như Claude Code đang phát triển thành các "agent" (tác nhân) có khả năng sử dụng công cụ, hành động trong thế giới thực, và tự động sửa lỗi dựa trên phản hồi, báo cáo lỗi và dữ liệu đo xa.
Tăng trưởng và tác động cấp số nhân: Tỷ lệ commit code do AI tạo ra trên GitHub đang tăng trưởng "cấp số nhân" (từ 4% lên dự kiến 20% trong một năm), cho thấy tốc độ thay đổi chóng mặt của ngành kỹ thuật phần mềm.
Ưu tiên mục tiêu và sứ mệnh: Đối với các kỹ sư AI, việc hiểu và gắn bó với "sứ mệnh" của công ty (ví dụ: an toàn AI của Anthropic) có thể quan trọng hơn việc chỉ xây dựng một sản phẩm thú vị.
Chiến lược phát triển sản phẩm ban đầu: Khi xây dựng công cụ AI mới, việc "underresource" (phân bổ nguồn lực dưới mức tối ưu) cho giao diện ban đầu (ví dụ: terminal) có thể giúp tập trung vào cải tiến mô hình cốt lõi và nhanh chóng thích nghi.
Nhu cầu tiềm ẩn và học hỏi từ người dùng: Thành công của các công cụ AI thường đến từ việc đáp ứng "nhu cầu tiềm ẩn" và liên tục học hỏi từ phản hồi của người dùng, đặc biệt trong một lĩnh vực đang phát triển nhanh chóng.

Từ vựng

code — mã nguồn
AI — Trí tuệ nhân tạo
pull request — yêu cầu kéo
agent — tác nhân
năng suất — productivity
kỹ sư phần mềm — software engineer
quản lý sản phẩm — product manager
dữ liệu đo xa — telemetry data
commit — cam kết (trong Git)
tool use — sử dụng công cụ
prototype — nguyên mẫu
terminal — thiết bị đầu cuối
người dùng hoạt động hàng ngày (DAU) — daily active users (DAU)
nhu cầu tiềm ẩn — latent demand
tiện ích mở rộng IDE — IDE extension
phản hồi — feedback
kỹ thuật phần mềm — software engineering
cấp số nhân — exponential (growth)

Nội dung chi tiết

Hiệu suất Lập trình với `AI`

— Người dẫn chương trình: Vâng, vâng. Anh có nhớ việc viết code không?

Tương lai của Lập trình và Vai trò `Kỹ sư Phần mềm`

— Boris Cherny: Vâng, cảm ơn vì đã mời tôi.

Quyết định Quay lại Anthropic: Tầm nhìn Sứ mệnh

Tác động và Tăng trưởng Vượt bậc của `Claude Code`

`AI Agent`, `Tool Use` và Hành trình Phát triển `Claude Code`

Phản ứng ban đầu và Thiết kế giao diện `terminal`

Khởi đầu và Thành công của `Claude Code`

Sự thay đổi nhanh chóng của Kỹ thuật phần mềm

Đổi mới thông qua Thử nghiệm và `Tư duy` theo Cấp số nhân

100% `Mã nguồn` được viết bởi `Claude Code`

Người phỏng vấn: Wow. Ngay cả khi là trưởng nhóm (head of the team).

Người được phỏng vấn: Vâng. Vâng. Vẫn lập trình rất nhiều. Và mỗi ngày tôi phát hành (ship) khoảng 10, 20, 30 pull request gì đó.

Người phỏng vấn: Mỗi ngày?

Người được phỏng vấn: Mỗi ngày. Vâng.

Người phỏng vấn: Lạy Chúa.

Biên giới tiếp theo: `AI` đề xuất ý tưởng và Công việc tổng quát

`AI` hỗ trợ `Quản lý Sản phẩm` và Chu kỳ Phản hồi Nhanh chóng

Claude và Code Review

Năng suất Kỹ sư và Tác động của AI

Thích nghi với Sự thay đổi của AI

Bài học từ Memory Leak: Tầm quan trọng của Tư duy mới

Nguyên tắc Hoạt động: Cấp vốn không đủ và Tốc độ

Tự do Token và Đổi mới

Bạn đã thấy các công ty nào mà chi phí token của họ cao hơn lương không? Bạn có nghĩ rằng đó là một xu hướng mà chúng ta sẽ tìm thấy và thấy không?

Coding như một Công cụ

TI-83.

TI-83 Plus. Vâng, vâng. Chính xác. [tiếng cười]

Tương Lai Của Kỹ Năng Lập Trình Và Sự Thay Đổi Cá Nhân

Người phỏng vấn: Vâng, đó là một câu hỏi hay. Ý tôi là, nó hoàn toàn có thể làm điều đó nếu anh muốn.

Bài Học Lịch Sử Từ Máy In Chữ Nổi

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa `Tác Nhân AI`

Tác Động Đến Việc Làm Và Tương Lai Lạc Quan

Tác động của AI và lời khuyên để thành công

Vậy, đối với những người đang lắng nghe và muốn thành công, muốn trụ vững trong giai đoạn hỗn loạn mà chúng ta đang bước vào, bạn có lời khuyên nào không? Liệu có phải là hãy thử nghiệm với các AI tools, trở nên thành thạo với những công nghệ mới nhất? Có điều gì khác mà bạn khuyên để giúp mọi người đi trước thời đại không?

Tư duy đa ngành và sự thay đổi vai trò trong tương lai

Stakeholder alignment (Sự đồng thuận của các bên liên quan).

Stakeholder alignment. Chính xác. Tôi thực sự nghĩ rằng có một tương lai mà tôi nghĩ đến cuối năm nay chúng ta sẽ bắt đầu thấy những điều này trở nên murkier (mơ hồ) hơn nữa, nơi mà tôi nghĩ ở một số nơi, chức danh software engineer sẽ bắt đầu biến mất và nó sẽ chỉ được thay thế bằng builder hoặc có thể mọi người sẽ trở thành một product manager và mọi người đều code hoặc những điều tương tự.

Quảng cáo: MetaView - Lợi thế không công bằng trong tuyển dụng

Phản hồi về việc sử dụng công cụ AI: Kỹ sư và PM yêu thích, Designer thì sao?

Điều đó cực kỳ thú vị. Tôi rất muốn nói chuyện với những người này, cả trong nhóm "thích hơn" và nhóm "ít thích hơn" để hiểu rõ. Bạn đã liên hệ với ai trong số họ chưa?

Vâng.

Vâng. Vì vậy, có lẽ nếu bạn đang nghe điều này, hãy để lại bình luận nếu bạn cảm thấy công việc của mình ít vui hơn và ít yêu thích công việc của mình hơn, bởi vì những gì bạn đang nói và những gì tôi nghe từ hầu hết mọi người – 70% PMs và kỹ sư đang yêu thích công việc của mình nhiều hơn. Nếu bạn không thuộc nhóm đó, có lẽ có điều gì đó đang xảy ra.

`Claude Desktop App` và Nguyên tắc `Latent Demand`

Vì vậy, điều này hơi native (tự nhiên) hơn, tôi nghĩ, đối với những người không phải là kỹ sư. Và thực sự, điều này quay trở lại việc đưa product đến nơi có người dùng. Bạn không muốn bắt mọi người sử dụng một workflow (quy trình làm việc) khác. Bạn không muốn bắt họ phải cố gắng học một điều mới. Dù mọi người đang làm gì, nếu bạn có thể làm cho điều đó dễ dàng hơn một chút, thì đó sẽ là một product tốt hơn nhiều mà mọi người yêu thích hơn. Và đây chính là nguyên tắc latent demand (nhu cầu tiềm ẩn), mà tôi nghĩ là nguyên tắc quan trọng nhất trong product.

Khai phá `Latent Demand`: Từ `Facebook Marketplace` đến `Co-work`

Nhu Cầu Tiềm Ẩn (Latent Demand) và Cách Tiếp Cận Phát Triển Sản Phẩm AI

Co-work: Phát Triển Nhanh Chóng và Nguyên Tắc Phát Hành Sớm

Ba Cấp Độ Đảm Bảo An Toàn Mô Hình AI

Tính Giải Thích Cơ Chế (Mechanistic Interpretability) và An Toàn Mô Hình

Nỗi Lo Về Năng Suất Khi AI Agent Bị Gián Đoạn

Kinh nghiệm lập trình với Tác nhân AI

Chia sẻ cá nhân: Ukraine và Odessa

Anh không biết điều này, nhưng tôi cũng sinh ra ở Ukraine.

À, tôi không biết. Vậy khi nào?

Tôi đến từ Odessa.

Ôi, tôi cũng vậy. (cười)

Cái gì?

Vâng, thật điên rồ.

Wow. Thật khó tin. Một khoảnh khắc đáng nhớ. Có lẽ liên quan một chút.

Anh và gia đình rời đi năm nào?

Chúng tôi đến vào năm 95.

Được rồi. Chúng tôi rời đi năm 88. Sớm hơn một chút.

Ồ, vâng.

Một cuộc sống khác biệt biết bao nếu không rời đi, phải không?

Vâng. Tôi cảm thấy rất may mắn mỗi ngày khi được lớn lên ở đây.

Vâng. Vâng. Chính xác. Vâng. Chúng tôi cũng làm bánh mì nướng tương tự, nhưng vẫn là vodka.

Vẫn là vodka. Chắc chắn rồi. (cười)

Lời khuyên xây dựng sản phẩm AI

Lời khuyên sử dụng Claude Code hiệu quả

Chế độ Lập kế hoạch và Đa dạng Giao diện

Quan điểm về Codex và Phương pháp Phát triển Sản phẩm

Kế hoạch sau AGI: Cuộc sống ở Nhật Bản và Niềm đam mê Miso

Thành công của Claude Code và Tầm nhìn tương lai

Người phỏng vấn: ... và làm miso.

Boris: ... và làm miso. Chà, miso thì không quá phức tạp, bạn chỉ cần đợi thôi, chỉ cần đợi.

Lightning Round: Sách, Phim và TV Show Yêu thích

Boris: Hãy bắt đầu thôi!

Người phỏng vấn: 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?

Người phỏng vấn: Tôi yêu cuốn sách chưa từng được nhắc đến này. Cuốn sách yêu thích của tôi.

Boris: À, đây là của Vinge, phải không? Vâng. Tuyệt vời.

Người phỏng vấn: Đúng vậy. Được rồi. Cuốn đó rất thú vị từ góc độ AI và AGI. Rất ít người đã đọc nó.

Boris: Vâng, nó khá dài.

Người phỏng vấn: Vâng, vâng, vâng. Tôi cũng thích "A Deepness in the Sky". Tôi nghĩ đó là phần tiếp theo, phải không?

Boris: Vâng.

Người phỏng vấn: Vâng, vâng, vâng. Tôi nghĩ vậy.

Người phỏng vấn: Vậy là một mẫu số chung của các lãnh đạo AI (AI leaders) là không có thời gian xem TV hoặc phim, điều mà tôi hoàn toàn hiểu.

Sản phẩm và nội dung yêu thích

Sức mạnh và tiềm năng của AI Agent qua Co-work

Lời khuyên cho người mới dùng Co-work

Bài học từ cộng đồng và đánh giá sản phẩm

Phương châm sống: Áp dụng lẽ thường

Tương tác trên Twitter/X và tầm quan trọng của phản hồi

Vâng. Vâng. Có một lỗi. Tôi hy vọng bây giờ nó đã được sửa.

Kêu gọi hành động và thông tin liên hệ

Lời kết từ host

Tuyệt vời. Boris, cảm ơn bạn rất nhiều vì đã ở đây. Tuyệt. Cảm ơn, Venny. Tạm biệt mọi người.

Góp ý / Báo lỗiPhát hiện sai sót hoặc có ý tưởng cải thiện?

Hiệu suất Lập trình với AI

Tương lai của Lập trình và Vai trò Kỹ sư Phần mềm

Quyết định Quay lại Anthropic: Tầm nhìn Sứ mệnh

Tác động và Tăng trưởng Vượt bậc của Claude Code

AI Agent, Tool Use và Hành trình Phát triển Claude Code

Phản ứng ban đầu và Thiết kế giao diện terminal

Khởi đầu và Thành công của Claude Code

Sự thay đổi nhanh chóng của Kỹ thuật phần mềm

Đổi mới thông qua Thử nghiệm và Tư duy theo Cấp số nhân

100% Mã nguồn được viết bởi Claude Code

Biên giới tiếp theo: AI đề xuất ý tưởng và Công việc tổng quát

AI hỗ trợ Quản lý Sản phẩm và Chu kỳ Phản hồi Nhanh chóng

Claude và Code Review

Năng suất Kỹ sư và Tác động của AI

Thích nghi với Sự thay đổi của AI

Bài học từ Memory Leak: Tầm quan trọng của Tư duy mới

Nguyên tắc Hoạt động: Cấp vốn không đủ và Tốc độ

Tự do Token và Đổi mới

Coding như một Công cụ

Tương Lai Của Kỹ Năng Lập Trình Và Sự Thay Đổi Cá Nhân

Bài Học Lịch Sử Từ Máy In Chữ Nổi

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa Tác Nhân AI

Tác Động Đến Việc Làm Và Tương Lai Lạc Quan

Tác động của AI và lời khuyên để thành công

Tư duy đa ngành và sự thay đổi vai trò trong tương lai

Quảng cáo: MetaView - Lợi thế không công bằng trong tuyển dụng

Phản hồi về việc sử dụng công cụ AI: Kỹ sư và PM yêu thích, Designer thì sao?

Claude Desktop App và Nguyên tắc Latent Demand

Khai phá Latent Demand: Từ Facebook Marketplace đến Co-work

Nhu Cầu Tiềm Ẩn (Latent Demand) và Cách Tiếp Cận Phát Triển Sản Phẩm AI

Co-work: Phát Triển Nhanh Chóng và Nguyên Tắc Phát Hành Sớm

Ba Cấp Độ Đảm Bảo An Toàn Mô Hình AI

Tính Giải Thích Cơ Chế (Mechanistic Interpretability) và An Toàn Mô Hình

Nỗi Lo Về Năng Suất Khi AI Agent Bị Gián Đoạn

Kinh nghiệm lập trình với Tác nhân AI

Chia sẻ cá nhân: Ukraine và Odessa

Lời khuyên xây dựng sản phẩm AI

Lời khuyên sử dụng Claude Code hiệu quả

Chế độ Lập kế hoạch và Đa dạng Giao diện

Quan điểm về Codex và Phương pháp Phát triển Sản phẩm

Kế hoạch sau AGI: Cuộc sống ở Nhật Bản và Niềm đam mê Miso

Thành công của Claude Code và Tầm nhìn tương lai

Lightning Round: Sách, Phim và TV Show Yêu thích

Sản phẩm và nội dung yêu thích

Sức mạnh và tiềm năng của AI Agent qua Co-work

Lời khuyên cho người mới dùng Co-work

Bài học từ cộng đồng và đánh giá sản phẩm

Phương châm sống: Áp dụng lẽ thường

Tương tác trên Twitter/X và tầm quan trọng của phản hồi

Kêu gọi hành động và thông tin liên hệ

Lời kết từ host

TL;DR

Điểm chính

Từ vựng

Nội dung chi tiết

Hiệu suất Lập trình với AI

Tương lai của Lập trình và Vai trò Kỹ sư Phần mềm

Quyết định Quay lại Anthropic: Tầm nhìn Sứ mệnh

Tác động và Tăng trưởng Vượt bậc của Claude Code

AI Agent, Tool Use và Hành trình Phát triển Claude Code

Phản ứng ban đầu và Thiết kế giao diện terminal

Khởi đầu và Thành công của Claude Code

Sự thay đổi nhanh chóng của Kỹ thuật phần mềm

Đổi mới thông qua Thử nghiệm và Tư duy theo Cấp số nhân

100% Mã nguồn được viết bởi Claude Code

Biên giới tiếp theo: AI đề xuất ý tưởng và Công việc tổng quát

AI hỗ trợ Quản lý Sản phẩm và Chu kỳ Phản hồi Nhanh chóng

Claude và Code Review

Năng suất Kỹ sư và Tác động của AI

Thích nghi với Sự thay đổi của AI

Bài học từ Memory Leak: Tầm quan trọng của Tư duy mới

Nguyên tắc Hoạt động: Cấp vốn không đủ và Tốc độ

Tự do Token và Đổi mới

Coding như một Công cụ

Tương Lai Của Kỹ Năng Lập Trình Và Sự Thay Đổi Cá Nhân

Bài Học Lịch Sử Từ Máy In Chữ Nổi

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa Tác Nhân AI

Tác Động Đến Việc Làm Và Tương Lai Lạc Quan

Tác động của AI và lời khuyên để thành công

Tư duy đa ngành và sự thay đổi vai trò trong tương lai

Hiệu suất Lập trình với `AI`

Tương lai của Lập trình và Vai trò `Kỹ sư Phần mềm`

Tác động và Tăng trưởng Vượt bậc của `Claude Code`

`AI Agent`, `Tool Use` và Hành trình Phát triển `Claude Code`

Phản ứng ban đầu và Thiết kế giao diện `terminal`

Khởi đầu và Thành công của `Claude Code`

Đổi mới thông qua Thử nghiệm và `Tư duy` theo Cấp số nhân

100% `Mã nguồn` được viết bởi `Claude Code`

Biên giới tiếp theo: `AI` đề xuất ý tưởng và Công việc tổng quát

`AI` hỗ trợ `Quản lý Sản phẩm` và Chu kỳ Phản hồi Nhanh chóng

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa `Tác Nhân AI`

`Claude Desktop App` và Nguyên tắc `Latent Demand`

Khai phá `Latent Demand`: Từ `Facebook Marketplace` đến `Co-work`

Hiệu suất Lập trình với `AI`

Tương lai của Lập trình và Vai trò `Kỹ sư Phần mềm`

Tác động và Tăng trưởng Vượt bậc của `Claude Code`

`AI Agent`, `Tool Use` và Hành trình Phát triển `Claude Code`

Phản ứng ban đầu và Thiết kế giao diện `terminal`

Khởi đầu và Thành công của `Claude Code`

Đổi mới thông qua Thử nghiệm và `Tư duy` theo Cấp số nhân

100% `Mã nguồn` được viết bởi `Claude Code`

Biên giới tiếp theo: `AI` đề xuất ý tưởng và Công việc tổng quát

`AI` hỗ trợ `Quản lý Sản phẩm` và Chu kỳ Phản hồi Nhanh chóng

Tác Động Của AI Đến Các Vai Trò Khác Và Định Nghĩa `Tác Nhân AI`

`Claude Desktop App` và Nguyên tắc `Latent Demand`

Khai phá `Latent Demand`: Từ `Facebook Marketplace` đến `Co-work`