Phỏng vấn người đứng đầu Claude Code: Lập trình đã được “giải quyết”, kỹ sư phần mềm cuối cùng sẽ bị thay thế bởi các nhà xây dựng (Builder)
Tuyển chọn TechFlowTuyển chọn TechFlow
Phỏng vấn người đứng đầu Claude Code: Lập trình đã được “giải quyết”, kỹ sư phần mềm cuối cùng sẽ bị thay thế bởi các nhà xây dựng (Builder)
Đừng hỏi AI có thể làm gì cho bạn — hãy trang bị công cụ cho nó và để nó tự hành động.
Chuyên sâu báo cáo Web3Tổng hợp & Dịch thuật: TechFlow
Khách mời: Boris Cherny – Trưởng dự án Claude Code
Dẫn chương trình: Lenny Rachitsky
Nguồn podcast: Lenny's Podcast
Tựa đề gốc: Trưởng dự án Claude Code: Điều gì xảy ra sau khi lập trình đã được “giải quyết”? | Boris Cherny
Ngày phát hành: 19 tháng Hai năm 2026
Tóm tắt các điểm chính
Boris Cherny là người sáng lập và trưởng dự án Claude Code tại Anthropic. Chỉ trong một năm, ông đã biến một nguyên mẫu đơn giản chạy trên terminal thành một công cụ đang thay đổi vai trò của kỹ sư phần mềm và dần ảnh hưởng tới mọi lĩnh vực chuyên môn.
Trong cuộc thảo luận này, các chủ đề sau được đề cập:
- Claude Code đã phát triển như thế nào từ một nguyên mẫu được xây dựng nhanh chóng thành công cụ chiếm 4% tổng số commit công khai trên GitHub, đồng thời số người dùng hoạt động hàng ngày (DAU) tăng gấp đôi trong tháng vừa qua.
- Các nguyên tắc sản phẩm phản trực quan đứng sau thành công của Claude Code.
- Tại sao Boris cho rằng vấn đề lập trình đã “được giải quyết”.
- Các nhu cầu tiềm ẩn định hình Claude Code và Cowork.
- Các lời khuyên thực tiễn nhằm tối đa hóa hiệu quả sử dụng Claude Code và Cowork.
- Tại sao giảm quy mô đội ngũ nhưng cấp quyền sử dụng token không giới hạn lại mang lại sản phẩm AI tốt hơn.
- Lý do Boris từng rời Anthropic để gia nhập Cursor trong thời gian ngắn, rồi chỉ hai tuần sau đã quay lại.
- Ba nguyên tắc cốt lõi mà Boris chia sẻ với mỗi thành viên mới trong đội.
Tóm tắt những quan điểm nổi bật
Sự thật về việc rời đi rồi trở lại Anthropic
- "Điều thu hút tôi đến với Anthropic là sứ mệnh và yếu tố an toàn. Bạn có thể chặn bất kỳ ai ở Anthropic và hỏi họ vì sao lại làm việc ở đây — câu trả lời luôn là 'an toàn'. Cảm giác được thúc đẩy bởi sứ mệnh như vậy khiến tôi đồng cảm sâu sắc. Tôi biết đây là điều cá nhân tôi cần; thiếu nó, tôi sẽ không thể cảm thấy hạnh phúc."
Tại sao Claude Code tăng trưởng nhanh đến vậy?
- "Tại Anthropic, tư duy theo cấp số mũ đã ăn sâu vào DNA — hãy nhìn vào các nhà đồng sáng lập của chúng tôi, ba tác giả đầu tiên của bài báo 'scaling laws'; chúng tôi thực sự suy nghĩ theo cấp số mũ. Nếu bạn vẽ đường cong cấp số mũ biểu thị tỷ lệ mã do Claude Code viết ra, rồi kéo dài đường đó, rõ ràng là cuối năm nay con số sẽ vượt quá 100%."
- "Sáng tạo không có lộ trình cố định — bạn không thể ép buộc nó xảy ra. Bạn phải dành không gian — hay còn gọi là 'cảm giác an toàn' — để mọi người có tâm lý an toàn, biết rằng thất bại cũng không sao, thậm chí 80% ý tưởng đều tệ cũng chẳng vấn đề gì."
Biên giới tiếp theo là gì? Lập trình đã được giải quyết
- "Lập trình cơ bản đã được giải quyết — ít nhất đối với loại lập trình mà tôi làm, đây là một vấn đề đã được giải quyết, vì Claude có thể làm được điều đó. Kể từ tháng Mười Một, tôi chưa tự tay sửa một dòng mã nào. Mỗi ngày tôi gửi mười, hai mươi, ba mươi pull request (PR), và tất cả đều do Claude Code viết."
Phần thưởng bất ngờ từ học chuyển giao (transfer learning)
- "Hiện tượng học chuyển giao rất thú vị — khi bạn huấn luyện mô hình hoàn thành nhiệm vụ X, hiệu suất của nó trên nhiệm vụ Y cũng cải thiện. Ví dụ, kể từ khi chúng tôi ra mắt công nghệ Quad Code (mã tứ phân), quy mô đội kỹ sư của chúng tôi tăng khoảng bốn lần, nhưng đáng kinh ngạc hơn là năng suất của mỗi kỹ sư tăng 200%."
Nguyên tắc đội #1: Chủ ý 'thiếu nguồn lực' (Underfund)
- "Khi một dự án chủ ý 'thiếu nguồn lực', mọi người sẽ buộc phải sử dụng Claude. Nếu bạn giao riêng một kỹ sư cho một dự án, động lực nội tại giúp họ hoàn thành nhanh chóng xuất phát từ mong muốn làm tốt công việc. Và nếu bạn có Claude, bạn có thể dùng nó để tự động hóa khối lượng lớn công việc."
Nguyên tắc đội #2: Cấp quyền sử dụng token không giới hạn cho kỹ sư
- "Đừng tối ưu hóa ngay từ đầu, đừng cắt giảm chi phí ngay từ đầu — hãy đưa càng nhiều token càng tốt vào tay kỹ sư. Việc cấp quyền sử dụng token vô hạn ngay khi gia nhập là một thực tiễn tôi hết sức ủng hộ, bởi điều này trao cho mọi người tự do thử nghiệm những ý tưởng táo bạo. Những ý tưởng đổi mới thú vị nhất thường nảy sinh từ quá trình thử nghiệm đầy nhiệt huyết này."
So sánh với máy in: Phần thú vị đã thay đổi
- "So sánh sát nhất là với máy in. Tôi không còn phải làm những việc nhàm chán — vật lộn với Git, dùng đủ loại công cụ; điều đó chưa bao giờ là phần thú vị. Phần thú vị là suy ngẫm xem mình nên xây dựng điều gì, trò chuyện với người dùng, suy tư về các hệ thống lớn, lên kế hoạch cho tương lai và cộng tác cùng đội nhóm. Giờ đây tôi có thể dành nhiều thời gian hơn cho những việc ấy."
Nghề nghiệp nào sẽ bị thay đổi tiếp theo? Agent bước vào máy tính
- "Tôi nghĩ sẽ là rất nhiều vị trí liền kề kỹ sư — quản lý sản phẩm, thiết kế, khoa học dữ liệu — và cuối cùng mở rộng tới gần như bất kỳ công việc nào có thể thực hiện trên máy tính. Ý nghĩa thực sự của 'Agent': một mô hình ngôn ngữ lớn (LLM) có khả năng sử dụng công cụ — nó không chỉ nói chuyện, mà còn thực sự hành động, tương tác với hệ thống của bạn."
Tái cấu trúc bậc thang nghề nghiệp: 'Builder' thay thế kỹ sư
- "Đến cuối năm, ranh giới giữa các vai trò sẽ ngày càng mờ nhạt. Ở một số nơi, danh xưng 'kỹ sư phần mềm' sẽ bắt đầu biến mất, được thay thế bằng 'Builder', hoặc tất cả đều trở thành quản lý sản phẩm, đồng thời ai cũng viết mã. Người nhận được phần thưởng cao nhất sẽ là những người tò mò, hiểu biết rộng và vượt qua ranh giới nhiều lĩnh vực."
Khung 'nhu cầu tiềm ẩn' phiên bản hiện đại
- "Khung nhu cầu tiềm ẩn truyền thống là quan sát người dùng đang làm gì. Còn khung hiện đại tôi nhận thấy hơi khác: hãy quan sát mô hình đang cố gắng làm gì, rồi khiến việc đó dễ dàng hơn. Sản phẩm chính là mô hình đó, và chúng tôi muốn phơi bày nó một cách đầy đủ nhất, bao bọc nó bằng càng ít 'giàn giáo' càng tốt, để nó tự quyết định chạy công cụ nào và theo thứ tự nào."
Xây dựng Cowork trong 10 ngày bằng AI
- "Cowork ra đời từ 'nhu cầu tiềm ẩn' — chúng tôi nhận thấy người dùng dùng Claude Code để làm những việc phi kỹ thuật. Giải pháp cuối cùng là xây dựng nó trong vòng 10 ngày, hoàn toàn bằng Claude Code. Cowork sở hữu một hệ thống bảo mật cực kỳ tinh vi, và toàn bộ mã cho hệ thống này đều do Claude Code viết."
Hệ thống an toàn ba lớp của Anthropic
- "Lớp đầu tiên là sự căn chỉnh (alignment) và khả năng giải thích cơ học (mechanistic interpretability); lớp thứ hai là đánh giá (Eval) trong môi trường phòng thí nghiệm; lớp thứ ba là quan sát hành vi của mô hình trong thế giới thực. Chúng ta cần phát hành sớm hơn mức độ sẵn sàng mà ta tưởng, để kịp thu thập phản hồi — ngay cả sau khi phát hành, chúng ta vẫn học được rất nhiều điều về sự căn chỉnh và an toàn."
Về 'nỗi lo lắng khi Agent đình trệ'
- "Buổi sáng thức dậy, việc đầu tiên tôi làm là mở ứng dụng Claude iOS trên iPhone để kiểm tra tiến độ của Agent đêm qua. Ở một mức độ nào đó, tôi thực sự cảm thấy lo lắng — kiểu 'có một Agent bị kẹt, tôi đã mất đi rất nhiều năng suất'. Tôi thực sự không ngờ mình sẽ dùng iOS để 'viết mã'."
Các nguyên tắc cốt lõi khi xây dựng sản phẩm AI
- "Đừng hỏi mô hình có thể làm gì cho bạn, mà hãy suy nghĩ cách trang bị công cụ để nó tự làm. Đừng kiểm soát quá mức, đừng nhốt nó vào chiếc hộp. Hãy xây dựng sản phẩm hướng tới mô hình sáu tháng sau, chứ không phải mô hình hôm nay. Khi mô hình đó xuất hiện, sản phẩm của bạn sẽ bứt phá mạnh mẽ."
Mẹo dành cho người dùng chuyên nghiệp: Chế độ Lập kế hoạch (Plan Mode)
- "Tôi bắt đầu khoảng 80% các tác vụ bằng chế độ lập kế hoạch. Thực ra rất đơn giản: chỉ cần thêm một câu vào prompt — 'Xin vui lòng đừng viết bất kỳ đoạn mã nào trước'. Sau khi kế hoạch trông ổn, mới để mô hình thực thi. Dùng mô hình mạnh nhất (Opus 4.6) thường lại rẻ hơn."
Tại sao Boris từng rời Anthropic để gia nhập Cursor (và vì sao ông quay lại)
Lenny (dẫn chương trình): Cách đây khoảng sáu tháng, anh rời Anthropic để gia nhập Cursor, nhưng chỉ hai tuần sau đã quay lại. Điều gì đã xảy ra?
Boris Cherny:
Đây là lần chuyển việc nhanh nhất tôi từng trải qua. Tôi gia nhập Cursor vì là fan cuồng của sản phẩm này, và khi gặp đội ngũ, tôi rất khâm phục họ — một đội tuyệt vời đang làm những điều tuyệt vời. Tôi cũng cảm thấy họ nhìn ra xu hướng lập trình AI sớm hơn nhiều người khác, nên việc xây dựng một sản phẩm tuyệt vời ở đó thực sự hấp dẫn tôi. Nhưng vừa đến nơi, tôi bắt đầu nhận ra điều tôi thực sự nhớ là sứ mệnh của Anthropic — điều vốn dĩ đã thúc đẩy tôi gia nhập Anthropic từ đầu. Trước khi gia nhập, tôi làm việc tại các tập đoàn công nghệ lớn, nhưng tôi muốn làm việc trong một phòng thí nghiệm, theo một cách nào đó góp phần định hình tương lai của thứ 'điên rồ' này.
Điều thu hút tôi đến với Anthropic là sứ mệnh và yếu tố an toàn. Bạn có thể chặn bất kỳ ai ở Anthropic và hỏi họ vì sao lại làm việc ở đây — câu trả lời luôn là 'an toàn'. Cảm giác được thúc đẩy bởi sứ mệnh như vậy khiến tôi đồng cảm sâu sắc. Tôi biết đây là điều cá nhân tôi cần; thiếu nó, tôi sẽ không thể cảm thấy hạnh phúc. Dù công việc có thú vị đến đâu, dù đang xây dựng một sản phẩm tuyệt vời đến mấy, nó cũng không thể thay thế được cảm giác có sứ mệnh. Nhận thức này đến rất nhanh và rõ ràng.
Một năm ra đời Claude Code
Lenny (dẫn chương trình): Hãy quay lại Anthropic và những gì anh đã làm ở đó. Tập podcast này phát hành đúng vào dịp kỷ niệm một năm ra đời Claude Code. Anh hẳn đã đọc báo cáo của SemiAnalysis — báo cáo chỉ ra rằng 4% tổng số commit công khai trên GitHub được tạo bởi Claude Code, và dự đoán đến cuối năm con số này sẽ đạt một phần năm. Ngay trong ngày ghi âm tập podcast này, Spotify vừa đăng tin: kỹ sư giỏi nhất của họ từ tháng Mười Hai đã không tự viết một dòng mã nào, mà hoàn toàn nhờ AI. Anh suy ngẫm gì về ảnh hưởng của một năm vừa qua?
Boris Cherny:
Những con số này thật điên rồ — nhiều hơn rất nhiều so với tôi tưởng tượng, và đây mới chỉ là các commit công khai; nếu tính cả kho lưu trữ riêng tư, con số chắc chắn còn cao hơn nhiều. Nhưng điều khiến tôi thấy điên rồ nhất không phải là con số hiện tại, mà là tốc độ tăng trưởng — vì xét trên mọi phương diện, tốc độ tăng trưởng của Claude Code đang liên tục gia tăng, không chỉ tăng mà còn tăng ngày càng nhanh hơn. Khi khởi động Claude Code, nó chỉ là một 'hack' nhỏ. Anthropic khá rõ ràng về mục tiêu xây dựng một sản phẩm lập trình, và cách công ty xây dựng mô hình lâu nay tuân theo một lộ trình nhất định: trước hết khiến mô hình cực mạnh trong lập trình, sau đó mạnh trong việc sử dụng công cụ, rồi mạnh trong việc sử dụng máy tính — cũng vì lý do an toàn, vì năng lực AI ngày càng mạnh, nên cần phát triển một cách có trách nhiệm.
Câu chuyện ra đời Claude Code
Boris Cherny:
Sau khi gia nhập Anthropic, tôi dành một tháng đầu tiên để xây dựng đủ loại nguyên mẫu kỳ lạ, phần lớn không bao giờ ra mắt; sau đó lại dành một tháng nữa để huấn luyện hậu kỳ (post-training), tìm hiểu sâu về phía nghiên cứu. Tôi cho rằng để làm tốt công việc, bạn thực sự cần hiểu tầng nền dưới công việc của mình. Trong lĩnh vực AI, bạn phải hiểu mô hình ở một mức độ nhất định để làm tốt sản phẩm.
Phiên bản đầu tiên của Claude Code tên là ClaudeCLI, lúc đó thể hiện cách nó sử dụng vài công cụ — khoảnh khắc gây ấn tượng mạnh nhất với tôi là khi tôi cung cấp cho nó một công cụ bash, và nó tự nghĩ ra cách dùng công cụ đó để trả lời câu hỏi của tôi: "Hiện tại tôi đang nghe nhạc gì?". Điều này thật kỳ diệu, vì tôi chưa từng bảo mô hình "dùng công cụ này để làm việc này", mà nó tự suy luận ra. Tôi gửi kết quả này nội bộ, phản ứng nhận được chỉ là hai lượt thích, không hơn. Bởi khi người ta nghĩ về công cụ lập trình, họ nghĩ ngay đến IDE; không ai nghĩ thứ này lại có thể chạy trên terminal. Thiết kế dạng terminal này có phần kỳ lạ, thực sự rất khác biệt. Nhưng lúc đó tôi chọn terminal chỉ vì trong vài tháng đầu chỉ có mình tôi, và terminal là cách dễ nhất để xây dựng.
Đây thực sự là một bài học sản phẩm quan trọng — trong giai đoạn đầu, bạn cần chủ ý giảm bớt nguồn lực đầu tư. Sau đó chúng tôi bắt đầu cân nhắc chuyển sang hình thức khác, nhưng cuối cùng quyết định giữ nguyên terminal, lý do lớn nhất là mô hình tiến bộ quá nhanh, khiến chúng tôi cảm thấy không hình thức nào khác có thể theo kịp tốc độ của nó. Đây là câu hỏi tôi tự hỏi đi hỏi lại suốt những đêm khuya: Mô hình vẫn đang tiến hóa liên tục, chúng ta phải làm gì? Terminal là đáp án duy nhất tôi nghĩ ra lúc đó, và quả nhiên sau khi phát hành, nó nhanh chóng lan rộng, trở thành hiện tượng nội bộ tại Anthropic, số người dùng hoạt động hàng ngày (DAU) tăng gần như thẳng đứng.
Khi chúng tôi phát hành ra bên ngoài vào tháng Hai, nó thực tế chưa thành công ngay lập tức; phải mất nhiều tháng sau, đa số người dùng mới thực sự hiểu rõ sản phẩm này là gì. Nó quá khác biệt, và một phần lý do Claude Code thành công nằm ở khái niệm "nhu cầu tiềm ẩn" — chúng tôi mang công cụ đến đúng nơi người dùng đang làm việc, khiến luồng công việc hiện có trở nên dễ dàng hơn một chút. Tất nhiên, vì chạy trên terminal nên nó có phần xa lạ, bạn cần giữ tâm thế cởi mở để học cách sử dụng. Hiện nay Claude Code đã có mặt trên ứng dụng iOS và Android, ứng dụng máy tính để bàn, phiên bản web, plugin IDE, tích hợp Slack và GitHub — kỹ sư ở đâu, nó có mặt ở đó, và đã trở nên thân thuộc, gần gũi hơn rất nhiều. Việc sản phẩm này có thể hữu ích ngay từ ban đầu đã là một điều bất ngờ. Cùng với sự phát triển của đội ngũ và sản phẩm, từ những startup nhỏ nhất đến các tập đoàn công nghệ khổng lồ nhất, người dùng khắp toàn cầu bắt đầu sử dụng và gửi phản hồi. Nhìn lại một năm qua, chúng tôi liên tục học hỏi từ người dùng — không ai thực sự biết mình đang làm gì, chúng ta chỉ cùng nhau mò mẫm.
Tốc độ AI đang thay đổi phát triển phần mềm
Lenny (dẫn chương trình): Anh ra mắt sản phẩm này cách đây một năm, không phải công cụ đầu tiên giúp người dùng viết mã bằng AI, nhưng trong một năm, toàn ngành kỹ sư phần mềm đã thay đổi mạnh mẽ. Ban đầu mọi người đều nói 'AI viết 100% mã? Không thể nào!', giờ thì lại nói 'Dĩ nhiên rồi, chuyện này đang diễn ra mà!'. Mọi thứ thay đổi quá nhanh.
Boris Cherny:
Tại hội nghị Code with Claude tháng Năm năm 2025, tôi có bài phát biểu ngắn, và trong phần hỏi đáp, có người hỏi tôi dự đoán gì cho cuối năm. Tôi nói: "Đến cuối năm, bạn có thể sẽ không còn cần IDE để viết mã nữa", và chúng tôi đã bắt đầu chứng kiến một số kỹ sư thực sự không dùng IDE nữa. Ngay khi tôi vừa dứt lời, cả hội trường vang lên tiếng hít vào mạnh. Dự đoán này lúc đó nghe thật điên rồ, nhưng tại Anthropic, tư duy theo cấp số mũ đã ăn sâu vào DNA — hãy nhìn vào các nhà đồng sáng lập của chúng tôi, ba tác giả đầu tiên của bài báo "scaling laws"; chúng tôi thực sự suy nghĩ theo cấp số mũ. Nếu bạn vẽ đường cong cấp số mũ biểu thị tỷ lệ mã do Claude Code viết ra, rồi kéo dài đường đó, rõ ràng là cuối năm nay con số sẽ vượt quá 100%. Chính tôi đã làm điều này, và với cá nhân tôi, điều đó đã xảy ra vào tháng Mười Một — và từ đó đến nay vẫn như vậy; hiện nay chúng tôi cũng thấy tình trạng tương tự tại nhiều khách hàng.
Tầm quan trọng của tinh thần thử nghiệm trong đổi mới AI
Lenny (dẫn chương trình): Hành trình anh chia sẻ thật thú vị — cảm giác chơi đùa tùy hứng, xem điều gì sẽ xảy ra. Đây dường như là yếu tố cốt lõi của nhiều đổi mới lớn nhất trong lĩnh vực AI: luôn có người đẩy mô hình đi xa hơn hầu hết người khác.
Boris Cherny:
Có một điều chắc chắn về đổi mới: nó không có lộ trình cố định — bạn không thể ép buộc nó xảy ra. Bạn phải dành không gian — hay còn gọi là 'cảm giác an toàn' — để mọi người có tâm lý an toàn, biết rằng thất bại cũng không sao, thậm chí 80% ý tưởng đều tệ cũng chẳng vấn đề gì. Đồng thời, bạn cũng cần có cơ chế chịu trách nhiệm nhất định: nếu một ý tưởng không hiệu quả, hãy thừa nhận tổn thất và chuyển sang ý tưởng tiếp theo, chứ không nên sa lầy. Trong giai đoạn đầu của Claude Code, tôi hoàn toàn không biết sản phẩm này có hữu ích hay không. Ngay cả khi phát hành ra bên ngoài vào tháng Hai, nó mới chỉ viết khoảng 20% mã của tôi. Đến tháng Năm, con số có thể là 30%, và tôi vẫn dùng Cursor để viết phần lớn mã, cho đến tháng Mười Một mới vượt mốc 100%. Nhưng ngay từ ngày đầu tiên, tôi đã cảm giác như mình đã tìm ra điều gì đó. Mỗi tối, mỗi cuối tuần, tôi đều nghiên cứu sản phẩm này, đôi khi bạn bắt được một manh mối, thì chỉ còn cách theo đuổi đến cùng.
Dòng công việc lập trình hiện tại của Boris (100% do AI thực hiện)
Lenny (dẫn chương trình): Vậy hiện tại toàn bộ mã của anh đều do Claude Code viết — đây là trạng thái lập trình hiện tại của anh sao?
Boris Cherny:
100% mã đều do Claude Code viết. Tôi là một kỹ sư khá năng suất — ngay cả khi làm việc tại Instagram, tôi cũng là một trong những kỹ sư năng suất nhất công ty, và điều này vẫn đúng tại Anthropic. Mỗi ngày tôi gửi mười, hai mươi, ba mươi pull request (PR), và tất cả đều do Claude Code viết. Kể từ tháng Mười Một, tôi chưa tự tay sửa một dòng mã nào.
Tôi vẫn đọc mã — tôi không nghĩ chúng ta đã đến giai đoạn có thể hoàn toàn bỏ qua việc này, đặc biệt khi rất nhiều người đang dùng chương trình của bạn, bạn cần đảm bảo mã đúng và an toàn. Tại Anthropic, chúng tôi cũng có Claude thực hiện kiểm tra mã tự động hoàn toàn — 100% PR đều được Claude kiểm tra, nhưng sau đó vẫn có thêm một lớp kiểm tra thủ công. Các điểm kiểm tra này có ý nghĩa, trừ khi đó là mã hoàn toàn mang tính nguyên mẫu, không thực sự chạy trên hệ thống.
Biên giới tiếp theo là gì
Lenny (dẫn chương trình): 100% mã đều do AI viết — cảm giác như một cột mốc điên rồ, nhưng giờ đây đã trở thành 'dĩ nhiên, đó là thế giới của chúng ta'. Vậy bước chuyển lớn tiếp theo trong cách viết phần mềm là gì?
Boris Cherny:
Tôi cho rằng điều đang xảy ra hiện nay là Claude bắt đầu tự đề xuất ý tưởng. Nó xem xét phản hồi, báo cáo lỗi, dữ liệu đo lường từ xa (telemetry), rồi bắt đầu đề xuất các bản sửa lỗi và tính năng cần phát hành, dần trở nên giống một đồng nghiệp. Thứ hai là, chúng ta bắt đầu mở rộng ra ngoài phạm vi lập trình. Lúc này, có thể nói lập trình cơ bản đã được giải quyết — ít nhất đối với loại lập trình mà tôi làm, đây là một vấn đề đã được giải quyết, vì Claude có thể làm được điều đó.
Vì vậy giờ đây chúng ta bắt đầu đặt câu hỏi: Điều gì tiếp theo? Ngoài lập trình còn gì nữa? Có rất nhiều việc liên quan, tôi nghĩ sẽ đến lượt chúng. Còn có những nhiệm vụ tổng quát hơn — hiện nay tôi dùng Cowork mỗi ngày để xử lý đủ thứ việc hoàn toàn không liên quan đến lập trình, ví dụ như vài ngày trước tôi dùng Cowork để nộp phạt vi phạm đỗ xe, hoặc quản lý toàn bộ dự án của cả đội — đồng bộ thông tin giữa bảng tính và Slack, gửi email, v.v. Vì vậy tôi cho rằng biên giới mới nằm ở đây. Lập trình cơ bản đã được giải quyết, trong vài tháng tới, chúng ta sẽ thấy toàn bộ ngành công nghiệp lần lượt 'giải quyết' các kho mã và ngăn xếp công nghệ.
Lenny (dẫn chương trình): Việc Claude giúp anh nghĩ 'tiếp theo nên làm gì' thật thú vị. Nhiều thính giả là quản lý sản phẩm, có lẽ đang đổ mồ hôi lạnh. Anh dùng Claude để làm điều này như thế nào?
Boris Cherny:
Cách đơn giản nhất là: mở Claude Code hoặc Cowork, trỏ vào một kênh Slack. Chúng tôi có một kênh riêng để thu thập phản hồi nội bộ về Claude Code, kênh này đã tồn tại từ khi sản phẩm mới ra mắt nội bộ, và luôn là dòng phản hồi không ngừng nghỉ. Thời kỳ đầu, mỗi khi có người gửi phản hồi, tôi lập tức vào xử lý, sửa tất cả các vấn đề càng nhanh càng tốt — có thể chỉ một phút, có thể năm phút, chu kỳ phản hồi cực kỳ nhanh. Điều này khiến người dùng cảm thấy được lắng nghe, bởi thông thường khi bạn dùng một sản phẩm và gửi phản hồi, phản hồi đó sẽ biến mất vào 'lỗ đen', khiến bạn không muốn gửi tiếp. Nhưng nếu người dùng cảm thấy được lắng nghe, họ sẽ tiếp tục đóng góp và giúp cải tiến sản phẩm. Giờ đây tôi vẫn làm điều tương tự, nhưng Claude đảm nhận phần lớn công việc.
Lenny (dẫn chương trình): Hiệu năng của Opus 4.6 có cải thiện nhiều không? Nhìn chung, mô hình này tiến bộ ra sao?
Boris Cherny:
Hiệu năng thực sự được cải thiện đáng kể, và tôi cho rằng một phần nguyên nhân là do chúng tôi huấn luyện chuyên sâu cho lập trình. Codex hiện là một trong những mô hình lập trình mạnh nhất thế giới, và hiệu năng của nó vẫn đang không ngừng tăng lên. Ví dụ, phiên bản 4.6 thể hiện hiệu năng rất xuất sắc, nhưng không chỉ huấn luyện cho lập trình mới mang lại tiến bộ. Thực tế, huấn luyện cho các lĩnh vực khác cũng chuyển giao rất tốt sang nhiệm vụ lập trình. Hiện tượng học chuyển giao (transfer learning) này rất thú vị — khi bạn dạy mô hình hoàn thành nhiệm vụ X, hiệu suất của nó trên nhiệm vụ Y cũng cải thiện. Ví dụ, kể từ khi chúng tôi ra mắt công nghệ Quad Code (mã tứ phân), quy mô đội kỹ sư của chúng tôi tăng khoảng bốn lần, nhưng đáng kinh ngạc hơn là năng suất của mỗi kỹ sư tăng 200%, như số lượng pull request gửi đi tăng mạnh — đối với bất kỳ ai nghiên cứu năng suất phát triển, mức tăng này thật khó tin.
Tôi từng làm việc tại Meta, phụ trách quản lý chất lượng mã cho toàn bộ công ty, bao gồm tất cả kho mã của Facebook, Instagram và WhatsApp. Lúc đó, chúng tôi rất chú trọng nâng cao năng suất kỹ sư, bởi cải thiện chất lượng mã sẽ trực tiếp nâng cao hiệu quả phát triển. Tuy nhiên, ngay cả khi hàng trăm kỹ sư cùng nỗ lực trong một năm, năng suất cũng chỉ tăng vài phần trăm.
Chi phí của đổi mới nhanh chóng
Lenny (dẫn chương trình): Điều đáng kinh ngạc hơn là những thay đổi này đã trở nên rất bình thường. Khi nghe những con số này, chúng ta có thể cảm thấy đó là điều hiển nhiên, vì AI đang thay đổi cách làm việc của mình, nhưng sự biến đổi to lớn này đối với phát triển phần mềm, xây dựng sản phẩm và toàn bộ ngành công nghệ là chưa từng có tiền lệ.
Boris Cherny:
Tất nhiên, tốc độ thay đổi nhanh chóng cũng mang lại một số thách thức. Ví dụ cá nhân tôi, do mô hình cập nhật quá nhanh, đôi khi tôi bị mắc kẹt trong tư duy cũ, khó thích nghi với những thay đổi mới. Tôi thậm chí nhận thấy các thành viên mới gia nhập đội, đặc biệt là những người vừa tốt nghiệp, thường làm việc với tư duy tiên phong hơn, phù hợp hơn với trí tuệ nhân tạo tổng quát (AGI), trong khi đôi khi tôi lại có vẻ lạc hậu.
Ví dụ cách đây vài tháng, có một vấn đề rò rỉ bộ nhớ — lượng bộ nhớ sử dụng của Claude Code tăng dần và cuối cùng dẫn đến sập — đây là một vấn đề kỹ thuật phổ biến, cách làm truyền thống là chụp ảnh bộ nhớ (heap snapshot), đưa vào bộ gỡ lỗi (debugger), phân tích bằng công cụ chuyên dụng. Tôi đã làm đúng như vậy. Nhưng một kỹ sư mới trong đội trực tiếp nhờ Claude Code làm, chỉ nói: "Này Claude, có vẻ đang bị rò rỉ, anh có thể tìm ra không?". Claude Code làm chính xác những việc tôi làm — chụp ảnh bộ nhớ, tự viết một công cụ nhỏ để phân tích, một chương trình được sinh ra tức thì, rồi tìm ra vấn đề, gửi pull request, và còn nhanh hơn tôi. Vì vậy, đối với những người đã dùng mô hình lâu năm như chúng tôi, chúng ta phải liên tục điều chỉnh bản thân để bắt kịp hiện tại, chứ không thể cứ mãi sống trong khuôn khổ tư duy của mô hình cũ — nó không còn là Sonnet 3.5 nữa, 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.
Các nguyên tắc làm việc của đội Claude Code
Lenny (dẫn chương trình): Tôi nghe nói anh có một số nguyên tắc làm việc cụ thể trong đội, một trong số đó đại khái là 'Có gì tốt hơn việc tự làm một việc nào đó? Hãy để Claude làm'. Câu chuyện về rò rỉ bộ nhớ anh vừa kể chính là minh chứng hoàn hảo — anh gần như quên mất nguyên tắc của mình, quên mất việc đầu tiên nên nhờ Claude thử.
Boris Cherny:
Còn một điều thú vị nữa là "chủ ý thiếu nguồn lực' (underfund). Khi bạn thiếu nguồn lực, mọi người sẽ buộc phải sử dụng Claude — đây là hiện tượng chúng tôi liên tục quan sát thấy. Đôi khi chúng tôi chỉ giao một kỹ sư cho một dự án, và động lực nội tại giúp họ hoàn thành nhanh chóng xuất phát từ mong muốn làm tốt công việc, muốn sớm hiện thực hóa những ý tưởng hay. Nếu bạn có Claude, bạn có thể dùng nó để tự động hóa khối lượng lớn công việc, nên thiếu nguồn lực là một nguyên tắc.
Một nguyên tắc khác là khuyến khích mọi người hành động nhanh hơn — việc có thể hoàn thành hôm nay thì đừng để đến ngày mai, đây là điều chúng tôi đặc biệt nhấn mạnh trong đội. Giai đoạn đầu điều này rất quan trọng, vì lúc đó chỉ có mình tôi, và lợi thế duy nhất của chúng tôi là tốc độ — đây là cách duy nhất để chúng tôi tồn tại trong thị trường lập trình cạnh tranh khốc liệt. Nhưng cho đến ngày nay, đây vẫn là một trong những nguyên tắc của chúng tôi. Nếu bạn muốn nhanh hơn, một cách tốt là để Claude làm nhiều việc hơn, hai nguyên tắc này hỗ trợ lẫn nhau.
Tại sao phải cấp quyền sử dụng token không giới hạn cho kỹ sư
Lenny (dẫn chương trình): Khái niệm 'chủ ý thiếu nguồn lực' thật thú vị, bởi thông thường người ta nghĩ AI giúp bạn làm được nhiều việc hơn với ít nhân sự hơn. Nhưng anh lại nói: không chỉ AI giúp bạn nhanh hơn, mà nếu bạn dùng ít người hơn, bạn thực tế sẽ khai thác được nhiều hơn từ công cụ AI.
Boris Cherny:
Đúng vậy. Nếu bạn tuyển những kỹ sư giỏi, họ sẽ tìm ra cách để làm được. Đây cũng là chủ đề tôi thường trao đổi với các CTO và lãnh đạo các công ty. Lời khuyên của tôi thường là: Đừng tối ưu hóa ngay từ đầu, đừng cắt giảm chi phí ngay từ đầu — hãy đưa càng nhiều token càng tốt vào tay kỹ sư. Hiện nay bạn bắt đầu thấy một số công ty coi đây là phúc lợi — cấp quyền sử dụng token vô hạn ngay khi gia nhập — đây là thực tiễn tôi hết sức ủng hộ, bởi điều này trao cho mọi người tự do thử nghiệm những ý tưởng táo bạo. Một khi ý tưởng nào đó chứng tỏ hiệu quả, lúc đó mới nghĩ cách mở rộng và tối ưu hóa — lúc đó mới cân nhắc thay Opus bằng Haiku hay Sonnet, hoặc thu nhỏ quy mô, nhưng ngay từ đầu hãy dùng token thật nhiều, xem ý tưởng có hiệu quả không, và trao cho kỹ sư tự do làm điều đó.
Lenny (dẫn chương trình): Người nghe ở đây có thể nghĩ 'Dĩ nhiên rồi, anh làm việc tại Anthropic, anh đương nhiên muốn chúng tôi dùng nhiều token hơn'. Nhưng anh lại nói rằng những ý tưởng đổi mới thú vị nhất sẽ nảy sinh từ quá trình thử nghiệm đầy nhiệt huyết này.
Boris Cherny:
Đúng vậy. Và thực tế là trong quy mô nhỏ, nếu một kỹ sư đang thử nghiệm cá nhân, chi phí token so với lương của họ hoặc các chi phí vận hành khác vẫn còn tương đối thấp. Chi phí thực sự tăng mạnh là khi một thứ gì đó thực sự hiệu quả và bắt đầu mở rộng quy mô — đó mới là thời điểm tối ưu hóa, nhưng đừng làm sớm quá.
Lenny (dẫn chương trình): Anh đã từng thấy công ty nào có chi phí token vượt quá lương chưa?
Boris Cherny:
Tại Anthropic, chúng tôi bắt đầu thấy một số kỹ sư chi tiêu hàng chục nghìn đô la Mỹ mỗi tháng cho token, và cũng bắt đầu thấy tình trạng tương tự tại một số công ty khác.
Kỹ năng lập trình còn quan trọng trong tương lai không
Lenny (dẫn chương trình): Anh có nhớ việc viết mã không? Việc này không còn thuộc về anh nữa với tư cách một kỹ sư phần mềm — điều đó khiến anh thấy buồn không?
Boris Cherny:
Với tôi điều này khá thú vị, bởi tôi học lập trình vì mục đích thực tiễn — tôi là kỹ sư tự học, học chuyên ngành Kinh tế ở trường đại học chứ không học Khoa học Máy tính, nhưng từ cấp hai tôi đã bắt đầu viết chương trình, và ngay từ đầu là vì mục đích thực tiễn. Tôi học lập trình để 'gian lận' — chúng tôi có máy tính đồ họa, và tôi lập trình đáp án vào đó. Năm sau đề khó quá, tôi không biết đề là gì, nên viết một bộ giải phương trình đại số nhỏ để chương trình giải giúp. Sau đó tôi phát hiện có thể dùng dây cáp nhỏ truyền chương trình cho cả lớp, và cả lớp đều đạt điểm A — nhưng cuối cùng bị phát hiện, giáo viên yêu cầu chúng tôi đừng làm vậy nữa. Ngay từ đầu, lập trình với tôi là công cụ để xây dựng thứ gì đó, chứ không phải mục đích tự thân.
Sau này tôi cũng say mê chính việc lập trình — tôi viết một cuốn sách về TypeScript, sáng lập buổi gặp mặt TypeScript lớn nhất thế giới lúc bấy giờ, bởi tôi yêu thích ngôn ngữ này, yêu thích lập trình hàm và hệ thống kiểu. Nhưng lập trình với tôi về bản chất là một công cụ, là cách để làm việc. Tất nhiên không phải ai cũng như vậy, có người thực sự tận hưởng quá trình lập trình. Mỗi người đều khác nhau, và ngay cả khi lĩnh vực này đang thay đổi, vẫn luôn có chỗ cho việc tận hưởng nghệ thuật này, cho việc viết mã bằng tay.
Lenny (dẫn chương trình): Anh lo ngại kỹ năng kỹ sư của mình sẽ thoái hóa không?
Boris Cherny:
Với cá nhân tôi, tôi không quá lo lắng. Lập trình luôn tiến hóa như vậy — từ thẻ đục lỗ, đến công tắc, đến phần cứng, đến giấy bút, rồi đến phần mềm chạy trên máy ảo ngày nay — đây đã là cách chúng ta viết chương trình trong khoảng sáu mươi năm nay. Ở mỗi bước chuyển đổi, đều có người nói "đây không phải lập trình thực sự". Nhưng tôi cho rằng trong tương lai bạn vẫn muốn hiểu tầng nền bên dưới, bởi điều đó giúp bạn trở thành kỹ sư giỏi hơn. Nhưng tình trạng này có lẽ chỉ kéo dài thêm khoảng một năm nữa, sau đó có thể thực sự không còn quan trọng nữa, giống như ngôn ngữ Assembly đối với lập trình viên ngày nay.
Về mặt cảm xúc, tôi luôn cần học điều mới, và với tư cách một lập trình viên, điều này không hề mới mẻ, bởi luôn có framework mới, ngôn ngữ mới. Đây là điều chúng ta rất quen thuộc trong lĩnh vực này. Nhưng đồng thời, điều này không nhất thiết đúng với tất cả mọi người — với một số người, có thể xuất hiện cảm giác mất mát, hoài niệm hoặc thoái hóa kỹ năng.
So sánh với máy in: Tác động của AI
Lenny (dẫn chương trình): Luôn có một câu hỏi: Liệu chúng ta còn cần học lập trình nữa không? Học sinh trong trường còn cần học lập trình nữa không? Từ góc nhìn của anh, có vẻ trong vòng một hoặc hai năm tới, đây có thể sẽ không còn là kỹ năng bắt buộc.
Boris Cherny:
Quan điểm của tôi là đối với những người hiện đang dùng mã tứ phân (Quad Code) hoặc agent thông minh (agents) để lập trình, hiện tại vẫn cần hiểu logic lập trình nền tảng. Nhưng trong vòng một hoặc hai năm tới, sự hiểu biết này có thể sẽ trở nên ít quan trọng hơn.
Gần đây tôi luôn tự hỏi: Sự kiện lịch sử nào có thể dùng làm phép so sánh? Bởi chúng ta cần đặt hiện tượng này vào bối cảnh lịch sử rộng lớn hơn, để xem liệu chúng ta đã từng trải qua một cuộc chuyển đổi công nghệ tương tự chưa. Phép so sánh sát nhất mà tôi nghĩ ra là máy in. Vào giữa thế kỷ XV tại châu Âu, tỷ lệ biết chữ thực sự rất thấp — dưới 1% dân số, chỉ những người sao chép (scribes) mới biết đọc biết viết, làm việc cho quý tộc và vua chúa, nhiều vị quân chủ thậm chí còn mù chữ, rồi Gutenberg và máy in xuất hiện. Có một thống kê điên rồ: trong năm mươi năm sau khi máy in ra đời, số lượng tài liệu in ra nhiều hơn tổng số tài liệu được tạo ra trong một ngàn năm trước đó. Số lượng tài liệu in tăng mạnh, chi phí giảm khoảng một trăm lần trong năm mươi năm tiếp theo. Còn tỷ lệ biết chữ mất khoảng hai trăm năm mới tăng từ dưới 1% lên 70% toàn cầu, bởi việc học đọc học viết rất khó, cần hệ thống giáo dục, cần thời gian rảnh rỗi, không thể suốt ngày làm việc đồng áng.
Tôi nghĩ chúng ta có thể chứng kiến một sự chuyển đổi tương tự. Và có một ghi chép lịch sử thú vị — có người phỏng vấn một người sao chép vào thế kỷ XV, hỏi cảm nhận về máy in, và họ thực sự hào hứng, bởi họ nói: "Điều tôi không thích làm là sao chép từ cuốn sách này sang cuốn sách khác; điều tôi thích làm là vẽ minh họa và bìa cho sách." Tôi rất vui vì giờ đây thời gian của tôi được giải phóng. Với tư cách một kỹ sư, tôi rất đồng cảm với cảm giác này. Tôi không còn phải làm những việc nhàm chán — vật lộn với Git, dùng đủ loại công cụ; điều đó chưa bao giờ là phần thú vị. Phần thú vị là suy ngẫm xem mình nên xây dựng điều gì, trò chuyện với người dùng, suy tư về các hệ thống lớn, lên kế hoạch cho tương lai và cộng tác cùng đội nhóm. Giờ đây tôi có thể dành nhiều thời gian hơn cho những việc ấy.
Lenny (dẫn chương trình): Và điều đáng kinh ngạc là công cụ anh xây dựng cho phép bất kỳ ai đều làm được điều này, ngay cả những người không có nền tảng kỹ thuật. Tôi tự làm một loạt dự án nhỏ, và mỗi khi vướng mắc, Claude đều giúp tôi giải quyết — nỗi đau trước đây khi mất nhiều thời gian xử lý thư viện và phụ thuộc giờ đây đã biến mất.
Boris Cherny:
Đúng vậy. Sáng nay tôi vừa trò chuyện với một kỹ sư, anh ấy dùng Go viết một dịch vụ, đã làm một tháng và chạy khá ổn, rồi tôi hỏi anh ấy cảm thấy thế nào, anh ấy trả lời: "Thực ra tôi vẫn chưa thực sự hiểu rõ Go…" Tôi nghĩ chúng ta sẽ ngày càng thấy nhiều tình huống như vậy — miễn là bạn biết nó chạy đúng và chạy hiệu quả, bạn thực sự không cần hiểu rõ mọi chi tiết.
AI tiếp theo sẽ thay đổi nghề nghiệp nào
Lenny (dẫn chương trình): Anh nghĩ AI tiếp theo sẽ tấn công nhanh nhất vào những vị trí nào? Dù là trong lĩnh vực công nghệ như quản lý sản phẩm, thiết kế, hay ngoài lĩnh vực công nghệ?
Boris Cherny:
Tôi nghĩ sẽ là rất nhiều vị trí liền kề kỹ sư — quản lý sản phẩm, thiết kế, khoa học dữ liệu, và cuối cùng mở rộng tới gần như bất kỳ công việc nào có thể thực hiện trên máy tính, bởi mô hình sẽ ngày càng mạnh hơn trong lĩnh vực này. Cowork là cách đầu tiên tiếp cận những công việc này, nhưng chỉ là bước đầu tiên — tôi nghĩ nó mang AI tác nhân (Agentic AI) đến với những người chưa từng sử dụng nó, giúp mọi người lần đầu tiên có cảm giác thực sự. Nhìn lại lĩnh vực kỹ sư một năm trước, không ai thực sự biết Agent là gì, không ai thực sự dùng nó, nhưng giờ đây nó đã trở thành cách làm việc của chúng ta.
Còn khi tôi nhìn sang công việc phi kỹ thuật hoặc bán kỹ thuật, như sản phẩm và khoa học dữ liệu, AI mà mọi người đang dùng vẫn chủ yếu là dạng hội thoại — chỉ là một chatbot. Từ 'Agent' bị lạm dụng bừa bãi, đã mất đi nhiều ý nghĩa, nhưng nó thực sự có một định nghĩa kỹ thuật rất rõ ràng: một mô hình ngôn ngữ lớn (LLM) có khả năng sử dụng công cụ — nó không chỉ nói chuyện, mà còn thực sự hành động, tương tác với hệ thống của bạn, dùng Google Docs của bạn, gửi email, chạy lệnh trên máy tính. Vì vậy tôi cho rằng bất kỳ công việc nào sử dụng công cụ máy tính đều là ứng viên tiếp theo. Đây cũng là lý do tôi cảm thấy việc làm điều này tại Anthropic rất quan trọng và cấp thiết — chúng tôi nghiêm túc đối với vấn đề này, có các nhà kinh tế học, nhà nghiên cứu chính sách, chuyên gia về tác động xã hội, và chúng tôi muốn thảo luận rộng rãi vấn đề này, để toàn xã hội cùng nhau tìm ra cách ứng phó, bởi điều này không nên chỉ do chúng tôi quyết định.
Lenny (dẫn chương trình): Có một khái niệm 'Nghịch lý Jevons' — khi chúng ta làm được nhiều hơn, chúng ta sẽ thuê thêm người, thực tế không đáng sợ đến thế. Trong quá trình AI trở thành một phần quan trọng của công việc kỹ sư, anh trải qua điều gì? Anh có thuê thêm người không?
Boris Cherny:
Đội Claude Code đang tuyển người, còn cá nhân tôi, tất cả những điều này khiến tôi càng thích công việc hơn. Tôi chưa từng thích lập trình như hiện tại, bởi tôi không còn phải xử lý những chi tiết nhàm chán. Chúng tôi cũng nhận được phản hồi tương tự từ nhiều khách hàng — họ yêu thích Claude Code vì nó khiến lập trình trở lại niềm vui, nhưng điều này sẽ đi về đâu thì khó nói. Tôi vẫn cần tìm kiếm các phép so sánh trong lịch sử, và máy in thực sự là phép so sánh sát nhất — khả năng vốn chỉ nằm trong tay một thiểu số — biết đọc biết viết — giờ đây trở nên phổ biến với tất cả mọi người, về bản chất là quá trình dân chủ hóa. Ai cũng bắt đầu có thể làm điều này, và nếu không có điều này, Phục Hưng sẽ không thể xảy ra, bởi Phục Hưng phần lớn dựa vào việc lan truyền tri thức, ghi chép văn bản — lúc đó không có điện thoại, không có internet, văn bản là cách con người phối hợp quy mô lớn. Tôi hình dung một thế giới như vậy, vài năm nữa, bất kỳ ai cũng có thể lập trình, bất kỳ lúc nào cũng có thể xây dựng phần mềm — điều gì sẽ được giải phóng? Tôi hoàn toàn không thể tưởng tượng nổi, giống như người thế kỷ XV không thể dự đoán điều gì sẽ xảy ra tiếp theo. Nhưng tôi thực sự tin rằng trong giai đoạn chuyển tiếp, điều này sẽ rất phá hủy, gây đau đớn cho nhiều người, và đây là điều toàn xã hội phải cùng nhau thảo luận và ứng phó.
Lời khuyên để thành công trong kỷ nguyên AI
Lenny (dẫn chương trình): Đối với những người muốn đứng vững trong thời đại biến động này, anh có lời khuyên gì? Là dùng nhiều công cụ AI, thành thạo những thứ mới nhất hay còn điều gì khác?
Boris Cherny:
Đây có lẽ là lời khuyên đầu tiên — hãy dùng những công cụ này, tìm hiểu chúng, đừng sợ, hãy mạnh dạn khám phá và bám sát những gì tiên tiến nhất. Lời khuyên thứ hai là: nỗ lực trở thành một người đa năng hơn bao giờ hết. Ví dụ, ở trường đại học, nhiều người học Khoa học Máy tính (CS) học cách viết mã, nhưng ít học những thứ khác, tối đa là một chút kiến trúc hệ thống. Nhưng trong số những kỹ sư hiệu quả nhất mà tôi làm việc hàng ngày, rất nhiều người đa ngành — trong đội Claude Code, tất cả đều viết mã, quản lý sản phẩm viết mã, quản lý kỹ sư viết mã, nhà thiết kế viết mã, kế toán viết mã, nhà khoa học dữ liệu viết mã, tất cả đều viết mã. Và rất nhiều kỹ sư vượt qua ranh giới nhiều lĩnh vực, người giỏi nhất là những người vừa là kỹ sư sản phẩm vừa là kỹ sư hạ tầng, hoặc là kỹ sư sản phẩm có cảm quan thiết kế tốt, hoặc là kỹ sư có trực giác kinh doanh mạnh, hoặc là kỹ sư thích trò chuyện với người dùng và hiểu rõ nhu cầu của họ. Vì vậy tôi nghĩ, người được phần thưởng cao nhất trong vài năm tới sẽ không chỉ là người 'sinh ra cùng AI', biết dùng những công cụ này, mà còn là người tò mò, hiểu biết rộng, vượt qua ranh giới nhiều lĩnh vực, và có thể suy nghĩ về vấn đề họ đang giải quyết từ góc nhìn vĩ mô — chứ không chỉ chăm chăm vào mảng kỹ sư.
Lenny (dẫn chương trình): Anh nghĩ ba ngành kỹ sư, thiết kế và quản lý sản phẩm có giá trị tồn tại lâu dài không, dù hiện nay chúng đang chồng lấn và làm công việc của nhau?
Boris Cherny:
Ngắn hạn thì vẫn tồn tại, nhưng chúng ta bắt đầu thấy những vai trò này có khoảng 50% chồng lấn, nhiều người thực tế đang làm những việc giống nhau, chỉ khác nhau ở chuyên môn. Ví dụ, tôi viết mã nhiều hơn một chút, quản lý sản phẩm của chúng tôi có thể làm nhiều hơn về phối hợp, lập kế hoạch, dự báo và quản lý các bên liên quan. Tôi thực sự tin rằng, đến cuối năm, những ranh giới này sẽ ngày càng mờ nhạt, ở một số nơi, danh xưng 'kỹ sư phần mềm' sẽ bắt đầu biến mất, được thay thế bằng 'Builder', hoặc tất cả đều trở thành quản lý sản phẩm, đồng thời ai cũng viết mã.
Khảo sát: Nghề nghiệp nào hưởng lợi từ AI trong công việc
Lenny (dẫn chương trình): Tôi thực hiện một khảo sát không chính thức trên Twitter, hỏi kỹ sư, quản lý sản phẩm và nhà thiết kế: Kể từ khi áp dụng công cụ AI, bạn có thấy công việc của mình thú vị hơn hay kém thú vị hơn? Trong số kỹ sư và quản lý sản phẩm, 70% nói thú vị hơn, khoảng 10% nói kém thú vị hơn. Nhà thiết kế thì thú vị hơn — chỉ 55% nói thú vị hơn, 20% nói kém thú vị hơn.
Boris Cherny:
Tôi rất muốn nói chuyện với cả hai nhóm để hiểu thêm. Tại Anthropic, phần lớn nhà thiết kế của chúng tôi đều viết mã — đây là điều chúng tôi kiểm tra khi tuyển dụng, và ngay cả với các vị trí phi kỹ thuật, chúng tôi cũng có nhiều vòng phỏng vấn kỹ thuật. Phần lớn nhà thiết kế của chúng tôi rất thích sự thay đổi do AI mang lại, bởi họ không còn phải phiền phức kỹ sư nữa, mà có thể tự vào sửa. Thậm chí một số nhà thiết kế trước đây không viết mã giờ đây bắt đầu viết, điều này rất tốt với họ, bởi họ có thể tự gỡ bỏ những trở ngại. Nhưng tôi rất muốn nghe thêm nhiều trải nghiệm khác nhau, bởi tôi tin rằng tình hình không đồng nhất.
Lenny (dẫn chương trình): Vì vậy nếu bạn đang nghe tập podcast này và thấy mình không còn thích công việc nữa, hãy để lại bình luận nói rõ điều gì khiến bạn không còn vui — bởi đa số, 70% quản lý sản phẩm và kỹ sư đều nói họ thích công việc hơn.
Boris Cherny:
Chúng tôi cũng thấy mọi người dùng các công cụ khác nhau — nhà thiết kế của chúng tôi dùng nhiều hơn ứng dụng Claude trên máy tính để bàn để viết mã, tức là tải ứng dụng về, trong đó có tab mã nằm ngay bên cạnh tab Cowork, thực tế sử dụng hoàn toàn cùng một Agent Claude Code, và có thể chạy đồng thời bao nhiêu phiên Claude tùy thích — chúng tôi gọi đây là 'nhiều phiên Claude song song'. Với những người không phải kỹ sư, tôi nghĩ điều này tự nhiên hơn. Điều này cũng quay lại nguyên tắc 'đưa sản phẩm đến đúng nơi người dùng đang làm việc' — không muốn người dùng thay đổi luồng công việc, không muốn họ cố gắng học một thứ mới, mà bất kể người dùng đang làm gì, nếu giúp việc đó dễ dàng hơn một chút, sản phẩm sẽ tốt hơn và người dùng sẽ thích hơn.
Nguyên tắc 'nhu cầu tiềm ẩn' trong phát triển sản phẩm
Lenny (dẫn chương trình): Anh có thể giải thích nguyên tắc 'nhu cầu tiềm ẩn' không? Anh từng đề cập đến nó khi ra mắt Cowork. Anh có thể giải thích khái niệm này là gì, và điều gì xảy ra khi bạn khai phá được nhu cầu tiềm ẩn?
Boris Cherny:
'Nhu cầu tiềm ẩn' là một ý tưởng như sau: nếu sản phẩm bạn xây dựng bị người dùng 'lạm dụng' theo một cách mà nó hoàn toàn không được thiết kế để sử dụng, nhằm hoàn thành một việc nào đó họ muốn làm, điều này có thể giúp bạn — người xây dựng sản phẩm — hiểu được sản phẩm nên đi đâu tiếp theo. Một ví dụ là Facebook Marketplace. Fiona, người phụ trách nhóm lúc bấy giờ, thường kể câu chuyện này — Facebook Marketplace ra đời từ việc quan sát thấy khoảng 40% bài đăng trong các nhóm Facebook là về mua bán đồ, người dùng đang 'lạm dụng' các nhóm Facebook để mua bán, không ai thiết kế sản phẩm riêng cho việc này, nhưng họ tự tìm ra cách dùng vì nó thực sự hữu ích. Vì vậy rõ ràng nếu bạn xây dựng một sản phẩm chuyên biệt để người dùng mua bán, họ sẽ thích. Facebook Marketplace ra đời theo cách đó, và Facebook Dating cũng tương tự — nếu bạn xem dữ liệu xem hồ sơ cá nhân, 60% lượt xem đến từ những người lạ giới tính khác nhau, đây là một 'hành vi hẹn hò tiềm ẩn', từ đó ra đời sản phẩm Dating.
Khái niệm 'nhu cầu tiềm ẩn' cũng đóng vai trò trong việc ra đời Cowork. Chúng tôi nhận thấy trong sáu tháng qua, rất nhiều người dùng Claude Code hoàn toàn không phải để viết mã. Có người dùng nó để trồng cà chua, có người dùng để phân tích bộ gen của mình, có người dùng để khôi phục ảnh cưới từ ổ cứng hỏng — những mục đích này hoàn toàn không mang tính kỹ thuật, rõ ràng mọi người đang rất vất vả để làm việc này trong terminal, có lẽ chúng ta nên xây dựng một sản phẩm chuyên biệt cho họ.
Tôi nhớ có một ngày đi vào văn phòng, thấy nhà khoa học dữ liệu Brendan của chúng tôi đang chạy Claude Code trong terminal, tôi kinh ngạc — anh ấy làm sao mở được terminal? Đây là một sản phẩm mang tính kỹ sư cao, ngay cả nhiều kỹ sư cũng không muốn dùng terminal. Anh ấy tải Node.js, tải Claude Code, rồi dùng nó để phân tích SQL trong terminal, và tuần sau tất cả nhà khoa học dữ liệu đều làm như vậy. Khi bạn thấy người dùng sử dụng sản phẩm theo cách không phải thiết kế ban đầu để hoàn thành một việc nào đó hữu ích với họ, đây là tín hiệu mạnh mẽ rằng bạn nên xây dựng một sản phẩm chuyên biệt cho việc đó.
Tôi nghĩ hiện nay còn có một chiều kích thú vị thứ hai. Khung nhu cầu tiềm ẩn truyền thống là: quan sát người dùng đang làm gì, rồi khiến việc đó dễ dàng hơn, trao quyền cho họ. Còn khung hiện đại tôi thấy trong sáu tháng qua hơi khác: quan sát mô hình đang cố gắng làm gì, rồi khiến việc đó dễ dàng hơn. Khi chúng tôi xây dựng Claude Code ban đầu, rất nhiều người khi xây dựng thứ gì đó với LLM thường nhốt mô hình vào một chiếc hộp, nói: "Đây là ứng dụng tôi muốn xây dựng, anh chỉ cần làm thành phần này, và tương tác với API theo cách này." Nhưng Claude Code đảo ngược điều này — sản phẩm chính là mô hình đó, chúng tôi muốn phơi bày nó một cách đầy đủ nhất, bao bọc nó bằng càng ít 'giàn giáo' càng tốt, trang bị cho nó một bộ công cụ cơ bản, để nó tự quyết định chạy công cụ nào và theo thứ tự nào. Điều này phần lớn dựa trên 'nhu cầu tiềm ẩn' của chính mô hình — nó muốn làm gì? Trong nghiên cứu, chúng tôi gọi đây là 'phân bố' (distribution), tức là quan sát mô hình đang cố gắng làm gì. Trong góc nhìn sản phẩm, 'nhu cầu tiềm ẩn' chính là phiên bản áp dụng khái niệm này cho mô hình.
Cowork được xây dựng trong 10 ngày như thế nào
Lenny (dẫn chương trình): Nói về Cowork, anh từng nói đội của anh xây dựng nó trong 10 ngày. Làm sao mà làm được vậy?
Boris Cherny:
Claude Code khi ra mắt không phải là một thành công ngay lập tức, mà là một hiện tượng bùng nổ dần theo thời gian, với vài điểm ngoặt then chốt — một lần khi Opus 4 ra mắt, một lần vào tháng Mười Một, và tốc độ tăng trưởng ngày càng nhanh. Nhưng trong vài tháng đầu, nhiều người không biết cách dùng, cũng không hiểu rõ sản phẩm là gì, còn Cowork khi ra mắt thì bùng nổ ngay lập tức, thành công hơn nhiều so với giai đoạn đầu của Claude Code.
Cowork ra đời từ "nhu cầu tiềm ẩn" vừa nói — chúng tôi thấy người dùng dùng Claude Code để làm những việc phi kỹ thuật, và chúng tôi cần suy nghĩ cách ứng phó. Đội đã khám phá trong vài tháng, thử nhiều hướng khác nhau, cuối cùng có người nói: Nếu chúng ta đưa Claude Code vào ứng dụng máy tính để bàn thì sao? Đó chính là giải pháp cuối cùng hiệu quả. Sau đó chúng tôi dùng 10 ngày, hoàn toàn bằng Claude Code để xây dựng nó. Cowork có một hệ thống bảo mật cực kỳ tinh vi, với các rào chắn đảm bảo mô hình không mất kiểm soát — chúng tôi phát hành kèm sản phẩm một máy ảo đầy đủ, và toàn bộ mã cho hệ thống này đều do Claude Code viết. Chúng tôi chỉ cần suy nghĩ rõ ràng: Làm thế nào để khiến nó an toàn và tự chủ hơn một chút đối với người dùng phi kỹ sư? Toàn bộ đều do Claude Code thực hiện, mất khoảng 10 ngày.
Chúng tôi phát hành sớm, lúc đó sản phẩm còn rất thô sơ, nhưng đây là cách chúng tôi học hỏi — dù ở cấp độ sản phẩm hay an toàn, chúng ta cần phát hành sớm hơn mức độ sẵn sàng mà ta tưởng, để kịp thu thập phản hồi, trò chuyện với người dùng, hiểu họ muốn gì, và để những điều đó định hình hướng phát triển của sản phẩm.
Hệ thống an toàn AI ba lớp của Anthropic
Lenny (dẫn chương trình): Triết lý 'phát hành sớm, học hỏi từ người dùng, lặp lại' luôn tồn tại, nhưng anh nói một lý do đặc biệt: bạn thậm chí không biết AI có thể làm gì, người dùng sẽ dùng nó ra sao — đây chính là lý do đặc biệt để phát hành sớm, giúp bạn khám phá 'nhu cầu tiềm ẩn' thực sự nằm ở đâu.
Boris Cherny:
Đúng vậy, và với tư cách một phòng thí nghiệm lấy an toàn làm ưu tiên hàng đầu, một chiều kích khác của việc phát hành là an toàn. Bởi có nhiều cách nghiên cứu an toàn mô hình khác nhau. Nghiên cứu nền tảng nhất là sự căn chỉnh (alignment) và khả năng giải thích cơ học (mechanistic interpretability) — trong quá trình huấn luyện mô hình, chúng tôi muốn đảm bảo nó an toàn, và hiện nay đã có những công nghệ khá trưởng thành để hiểu điều gì đang xảy ra trong các neuron, ví dụ như nếu một neuron liên quan đến hành vi lừa dối được kích hoạt, chúng ta bắt đầu có thể giám sát và hiểu nó. Đây là sự căn chỉnh, đây là khả năng giải thích cơ học, là nền tảng nhất.
Lớp thứ hai là Eval — đây là môi trường phòng thí nghiệm, mô hình ở trong 'đĩa nuôi cấy', bạn nghiên cứu nó trong các tình huống tổng hợp: 'Này mô hình, anh sẽ làm gì? Anh có được căn chỉnh không? Anh có an toàn không?'
Lớp thứ ba là quan sát hành vi của mô hình trong thế giới thực. Khi mô hình ngày càng phức tạp, lớp này trở nên ngày càng quan trọng, bởi mô hình có thể biểu hiện tốt ở hai lớp đầu nhưng chưa chắc ở lớp thứ ba. Chúng tôi phát hành Claude Code sớm là vì muốn nghiên cứu an toàn — trước khi phát hành ra bên ngoài, chúng tôi đã dùng nó nội bộ tại Anthropic khoảng bốn đến năm tháng, bởi đây là Agent đầu tiên được sử dụng quy mô lớn, chúng tôi không chắc nó có an toàn không, nên cần nghiên cứu kỹ lưỡng nội bộ. Dù vậy, ngay sau khi phát hành, chúng tôi vẫn học được rất nhiều điều về sự căn chỉnh và an toàn, và liên tục phản hồi lại cho mô hình và sản phẩm. Cowork cũng tương tự — mô hình ở một tình huống hoàn toàn mới, làm các nhiệm vụ phi kỹ thuật, sự căn chỉnh trông rất tốt, kiểm tra nội bộ trông tốt, thử nghiệm với vài khách hàng cũng tốt, nhưng giờ đây cần đảm bảo nó an toàn trong thế giới thực.
Lenny (dẫn chương trình): Vậy tổng cộng là ba lớp, và anh vừa nhắc đến lớp đầu tiên — có một công cụ quan sát được, cho phép bạn 'nhìn vào bộ não' của mô hình, xem nó đang nghĩ gì, đang đi theo hướng nào. Các anh thực sự có một công cụ để nhìn vào bên trong mô hình, xem cách suy nghĩ và hướng đi của nó.
Boris Cherny:
Anh nên mời Chris Olah lên chương trình podcast này, anh ấy là chuyên gia trong lĩnh vực này, và chính anh ấy đã sáng lập ra lĩnh vực khả năng giải thích cơ học. Ý tưởng cốt lõi là: mô hình về bản chất là một tập hợp các neuron kết nối với nhau, giống như não người hoặc não động vật, và bạn có thể nghiên cứu những neuron này ở cấp độ cơ chế để hiểu chúng đang làm gì. Điều đáng kinh ngạc là điều này cũng áp dụng rất nhiều trên mô hình. Neuron của mô hình khác với neuron của động vật, nhưng về nhiều mặt hành vi lại tương tự. Chúng ta đã học được rất nhiều điều về cách các neuron này hoạt động — tầng nào hay neuron nào tương ứng với khái niệm nào, cách mã hóa các khái niệm cụ thể, mô hình lập kế hoạch như thế nào, và 'dự đoán' về phía trước ra sao.
Rất lâu trước đây, chúng ta còn không chắc mô hình thực sự đang dự đoán token tiếp theo, hay đang làm điều gì sâu sắc hơn. Hiện nay có bằng chứng khá mạnh cho thấy nó thực sự đang làm điều gì đó sâu sắc hơn. Và khi mô hình lớn hơn, cấu trúc cũng phức tạp hơn — một neuron có thể tương ứng với hàng chục khái niệm, và chỉ khi cùng kích hoạt với các neuron khác mới biểu thị khái niệm phức tạp hơn, đây gọi là 'chồng chéo' (superposition). Chúng ta luôn trong quá trình học hỏi, và Anthropic với tư cách một phòng thí nghiệm suy ngẫm về cách lĩnh vực này phát triển, muốn làm điều này vừa an toàn vừa có lợi cho thế giới — đây là lý do tồn tại của chúng tôi, là lý do mỗi người ở đây.
Hầu hết các công việc này chúng tôi công khai mã nguồn, xuất bản rất nhiều, và thảo luận một cách minh bạch, nhằm truyền cảm hứng cho các phòng thí nghiệm khác cũng hành động một cách an toàn. Chúng tôi cũng làm điều này trên Claude Code, gọi là 'cuộc đua hướng lên' — ví dụ chúng tôi công khai mã nguồn một môi trường cách ly (sandbox), nơi bạn có thể chạy Agent, đảm bảo nó có giới hạn truy cập hệ thống, và môi trường cách ly này áp dụng cho mọi Agent, không chỉ riêng Claude Code, bởi chúng tôi muốn người khác cũng dễ dàng làm điều tương tự.
Cảm giác lo lắng khi AI Agent không hoạt động
Lenny (dẫn chương trình): Trong số các kỹ sư, quản lý sản phẩm và những người dùng Agent khác — khi Agent không chạy, sẽ xuất hiện cảm giác lo lắng, kiểu 'có một Agent bị kẹt, tôi đã mất đi rất nhiều năng suất'. Anh có cảm giác này không? Đội của anh có không? Anh có cho rằng đây là vấn đề cần quan tâm không?
Boris Cherny:
Tôi luôn có một loạt Agent đang chạy, ngay lúc này tôi có năm Agent đang hoạt động. Buổi sáng thức dậy, việc đầu tiên tôi làm là mở ứng dụng Claude iOS trên iPhone để kiểm tra tiến độ của Agent đêm qua — bởi hôm trước tôi viết một số mã, nửa đêm nghĩ xem việc mình làm có đúng không, rồi phát hiện là đúng. Vì vậy ở một mức độ nào đó, tôi thực sự cảm thấy lo lắng, nhưng với cá nhân tôi, vì Agent luôn đang chạy nên cảm giác này không quá rõ ràng. Hiện nay khoảng một phần ba mã của tôi đượ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 dùng ứng dụng iOS — điều này thật đáng kinh ngạc với tôi vào năm 2026, tôi thực sự không ngờ mình sẽ dùng iOS để 'viết mã', nhưng đó là thực tế.
Lenny (dẫn chương trình): Anh mô tả nó là 'viết mã', nhưng thực tế là đang trò chuyện với Claude Code để nhờ nó viết mã. Giờ đây 'viết mã' có nghĩa là: mô tả điều bạn muốn, chứ không phải thực sự viết mã.
Boris Cherny:
Tôi đôi khi tự hỏi những người viết chương trình bằng thẻ đục lỗ ngày xưa sẽ nói gì nếu thấy cách 'viết mã' ngày nay. Tôi nhớ đã đọc một bài báo tạp chí rất sớm, người ta nói 'Điều này khác biệt, đây không phải lập trình thực sự'. Gia đình tôi đến từ Liên Xô, tôi sinh ra ở Ukraine, và ông ngoại tôi thực tế là một trong những lập trình viên đầu tiên của Liên Xô, người viết chương trình bằng thẻ đục lỗ. Ông mang những thẻ đục lỗ đó về nhà, và với mẹ tôi, ký ức tuổi thơ về những thẻ đục lỗ là dùng bút chì màu vẽ nguệch ngoạc lên đó — đó là trò chơi của bà, nhưng đó là trải nghiệm 'viết chương trình' của ông. Ông chưa từng chứng kiến thời đại phần mềm, nhưng ở một thời điểm nào đó đã chuyển sang phần mềm, và tôi tin rằng lúc đó có thể đã có một thế hệ 'những lập trình viên lão thành' không quá coi trọng phần mềm, nghĩ rằng 'đó không phải lập trình thực sự'. Nhưng lĩnh vực này luôn tiến hóa như vậy.
Lời khuyên khi xây dựng sản phẩm AI
Lenny (dẫn chương trình): Anh chia sẻ một số lời khuyên tuyệt vời — cấp cho đội càng nhiều token càng tốt, xây dựng sản phẩm hướng tới mô hình sáu tháng sau, chứ không phải mô hình hôm nay. Đối với những người muốn xây dựng sản phẩm AI, anh còn lời khuyên nào khác không?
Boris Cherny:
Thứ nhất là đừng nhốt mô hình vào chiếc hộp. Trực quan của nhiều người là xây dựng các luồng công việc rất nghiêm ngặt: 'Bạn phải làm bước đầu tiên, rồi bước thứ hai, rồi bước thứ ba', sau đó có một bộ điều phối phức tạp. Nhưng gần như luôn luôn, nếu bạn trực tiếp trao công cụ và mục tiêu cho mô hình, để nó tự tìm cách, bạn sẽ đạt được kết quả tốt hơn. Một năm trước bạn có thể thực sự cần rất nhiều 'giàn giáo', nhưng giờ đây thì không cần nữa. Tôi vẫn chưa biết nên gọi nguyên tắc này là gì, nhưng đại khái là: đừng hỏi mô hình có thể làm gì cho bạn, mà hãy suy nghĩ cách trang bị công cụ để nó tự làm. Đừng kiểm soát quá mức, đừng nhốt nó vào chiếc hộp, đừng cung cấp trước cho nó một loạt ngữ cảnh — hãy trao cho nó một công cụ để tự tìm ngữ cảnh cần thiết, bạn sẽ đạt được kết quả tốt hơn.
Thứ hai là 'bài học cay đắng' (Bitter Lesson). Trong đội Claude Code, chúng tôi treo điều này trên tường. Khoảng mười năm trước, Rich Sutton có một bài blog nổi tiếng mang tên 'Bài học cay đắng', ý tưởng cốt lõi rất đơn giản: mô hình tổng quát hơn luôn thể hiện tốt hơn mô hình chuyên biệt hơn. Với tôi, suy luận lớn nhất là: luôn đặt cược vào mô hình tổng quát hơn. Đừng cố gắng tinh chỉnh (fine-tune), đừng cố gắng dùng mô hình nhỏ, đừng xây dựng các luồng công việc cố định — những luồng công việc này về bản chất là từ bỏ tính tổng quát. Thường thì 'giàn giáo' có thể mang lại tăng hiệu năng 10-20%, nhưng những
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
深潮TechFlow
