Bỏ qua đến nội dung chính

Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next

TL;DR

  • Claude code đã trải qua giai đoạn phát triển ban đầu khó khăn nhưng bùng nổ mạnh mẽ với các bản phát hành mô hình Opus 4 trở đi, khiến Boris Cherny – người tạo ra nó – hiện viết 100% mã của mình bằng AI.
  • Tương lai của phát triển phần mềm sẽ chứng kiến sự trỗi dậy của "người đa năng đa ngành", những cá nhân giỏi nhiều lĩnh vực như kỹ thuật, thiết kế, sản phẩm và khoa học dữ liệu, nhờ AI dân chủ hóa kỹ năng mã hóa.
  • AI sẽ làm giảm giá trị của các "hào chắn kinh doanh" truyền thống như chi phí chuyển đổi và sức mạnh quy trình, nhưng tăng cường tầm quan trọng của hiệu ứng mạng và tài nguyên độc quyền, tạo ra cơ hội vàng cho các startup xây dựng giải pháp AI nguyên bản.

startup opportunity

Past — specialists: eng, design, PM, data

Claude Code — Boris writes 100% with AI

Multi-disciplinary generalists

Old moats erode — switching costs, process

New moats matter — network effects, proprietary data

Điểm chính

  • Việc phát triển Claude code được thúc đẩy bởi nhận định về "sự chậm trễ của sản phẩm so với khả năng của mô hình", tức là các mô hình AI có thể làm được nhiều hơn những gì sản phẩm hiện có khai thác.
  • Thành công của Claude code là sự kết hợp giữa chất lượng mô hình và các quyết định sản phẩm chiến lược, tập trung vào việc tạo ra trải nghiệm người dùng tuyệt vời và xây dựng thứ mà "mọi người yêu thích".
  • Boris Cherny sử dụng Claude code để viết gần như 100% mã của mình, gửi hàng chục PRs mỗi ngày, cho thấy tiềm năng của AI trong việc tăng năng suất lập trình cá nhân lên mức đáng kể.
  • Thiết lập làm việc cá nhân của Boris bao gồm việc quản lý hàng trăm Tác nhân (AI) cùng lúc và sử dụng hàng tá loop (vòng lặp) để tự động hóa các tác vụ lặp lại như giám sát PRs, sửa lỗi CI hay tổng hợp phản hồi.
  • Tính năng /looproutines (tương tự nhưng chạy trên máy chủ) được nhấn mạnh là tương lai để tự động hóa công việc lặp đi lặp lại và duy trì các tác vụ ngay cả khi không có sự can thiệp trực tiếp.
  • AI sẽ thúc đẩy sự xuất hiện của các "người đa năng đa ngành" trong các nhóm phát triển, nơi mọi thành viên (kỹ sư, quản lý sản phẩm, nhà thiết kế) đều có thể viết mã và đóng góp vào nhiều khía cạnh của sản phẩm.
  • AI sẽ làm suy yếu các "hào chắn kinh doanh" dựa trên chi phí chuyển đổi và sức mạnh quy trình, nhưng củng cố những yếu tố như hiệu ứng mạng, kinh tế theo quy mô và tài nguyên độc quyền.
  • Thời điểm hiện tại là cơ hội tốt nhất cho các startup để xây dựng và đột phá, vì họ có thể phát triển các giải pháp AI nguyên bản mà không gặp phải sức cản nội bộ như các công ty lớn.

Từ vựng

  • Claude code — Claude code (Tên sản phẩm)
  • Tác nhân (AI) — AI Agent
  • PMF (Product Market Fit) — Sự phù hợp giữa sản phẩm và thị trường
  • CLI — Command Line Interface (Giao diện dòng lệnh)
  • PRs (Pull Requests) — Yêu cầu kéo
  • /loop — Tính năng vòng lặp (trong Claude code)
  • hào chắn kinh doanh — Business Moats
  • chi phí chuyển đổi — Switching Costs
  • hiệu ứng mạng — Network Effects
  • dân chủ hóa phần mềm — Democratize Software

Nội dung chi tiết

Giới Thiệu Claude code và Boris Cherny

Chào mừng diễn giả tiếp theo của chúng ta. Giơ tay lên nào, ai ở đây dùng Claude code? Được rồi, giơ tay lên nào, ai ở đây mắc chứng cuồng Claude code? Thôi nào các bạn, [hắng giọng] không sao đâu. Đội của tôi vẫn thường nói đùa rằng tôi mắc chứng cuồng Claude code, điều đó có thể đúng hoặc không.

Chúng tôi rất vinh dự có Boris Cherny ở đây hôm nay. Boris là người tạo ra, cha đẻ của Claude code. Trong quá trình thực hiện điều đó, anh ấy đã có một vị trí quan trọng trong việc tái định hình phương pháp phát triển phần mềm hiện đại. Chúng tôi thực sự biết ơn Boris vì đã dành thời gian trò chuyện với chúng tôi hôm nay. Chúng tôi biết rằng toàn bộ sự phát triển phần mềm dường như đang đặt trên vai anh. Vì vậy, cảm ơn anh đã dành thời gian quý báu của mình để có mặt cùng chúng tôi hôm nay. Người phỏng vấn Boris là Lauren Reader từ đội của chúng tôi. Cảm ơn. [tiếng vỗ tay]

Bối Cảnh về Boris Cherny

Bạn đã lấy mất câu mở đầu của tôi, Asia. Chúng tôi đã hỏi ai ở đây dùng Claude code. Rất nhiều người giơ tay. Thật tuyệt vời. Cảm ơn Boris đã tham gia cùng chúng tôi. Rất đặc biệt khi có bạn ở đây. Là một căn phòng đầy những người xây dựng, tôi nghĩ bạn đang thay đổi hoàn toàn cách xây dựng. Vì vậy, tôi rất tò mò muốn khám phá cách bạn suy nghĩ về tương lai của phần mềm, mã hóa và những gì chúng ta nên dành thời gian rảnh rỗi của mình.

Tôi sẽ cung cấp thêm một chút thông tin về bạn để mọi người có thêm ngữ cảnh. Ngoài việc tạo ra Claude code, Boris thực sự là một kỹ sư của các kỹ sư. Bạn đã viết rất nhiều mã trong suốt sự nghiệp của mình, viết sách giáo khoa về mã, bao gồm cả lập trình bằng TypeScript. Lần cuối chúng ta trò chuyện, bạn đã không viết một dòng mã nào trong năm qua, hoặc ít nhất là cho đến năm 2026, đó là một sự thay đổi khá lớn. Còn có một điều ít người biết, hồi trung học, tôi đã viết một hướng dẫn về cách viết BASIC cho máy tính TI-83 Plus. Tôi vừa tìm kiếm nó, nó thực sự vẫn còn trên internet. Nó cực kỳ đáng xấu hổ, vì vậy xin đừng tìm kiếm nó. Nhưng nó [tiếng cười] vẫn tồn tại. Chúng tôi chắc chắn sẽ tìm thấy nó.

Nguồn Gốc và Sự Phát Triển của Claude code

Chúng ta sẽ bắt đầu với một vài câu hỏi ở đây. Có lẽ chúng ta sẽ bắt đầu với một chút lịch sử của Claude code, cách bạn bắt đầu nó, và sau đó chúng ta sẽ có nhiều câu hỏi và trả lời từ khán giả cho phần này. Vì vậy, hãy bắt đầu suy nghĩ về các câu hỏi của bạn, và chúng tôi rất muốn chuyển sang phần hỏi đáp sớm. Nhân tiện, đối với những người dùng Claude code, mọi người chủ yếu dùng CLI phải không? Được rồi, phần lớn là CLI? Khá nhiều. Phần lớn là ứng dụng desktop? Phần lớn là VS Code hay JetBrains IDE? Thực ra không nhiều lắm. Khác? Dạo này tôi chủ yếu dùng iOS. [tiếng cười] Được rồi. Tuyệt.

Vâng, tôi đã bắt đầu Claude code một cách khá tình cờ theo nhiều cách. Tôi đã tham gia nhóm này vào cuối năm 2024. Đó là một dạng vườn ươm trong Anthropic, được gọi là Anthropic Labs. Và nhóm đó đã hoàn thành mục đích của mình. Chúng tôi đã tạo ra Claude code, MCP và ứng dụng desktop. Đó là một nhóm chỉ có vài người trong chúng tôi. Vì vậy, giống như một nhóm đổi mới. Chúng tôi đã xây dựng thứ chúng tôi muốn xây dựng, và chúng tôi đã giải tán nhóm. Hiện tại, nhóm thực ra đã quay lại với vòng hai. Mike Krieger, người là giám đốc sản phẩm tại Anthropic và từng là một trong những người sáng lập Instagram, đang dẫn dắt nhóm đó.

Lý do tôi bắt đầu làm việc về mã hóa là chúng tôi cảm thấy có một "sự chậm trễ của sản phẩm so với khả năng của mô hình". Tôi đoán mọi người ở đây dùng từ đó rất nhiều. Nhưng chúng tôi chắc chắn dùng từ này rất nhiều trong phòng thí nghiệm. Có một ý tưởng rằng mô hình có thể làm tất cả những điều mà chưa có sản phẩm nào nắm bắt được. Và vào cuối năm 2024, khi chúng tôi xem xét mã hóa, cách chúng tôi làm mã hóa, công nghệ tiên tiến lúc bấy giờ là gợi ý tự động (type ahead). Đó là bạn mở IDE của mình và bạn nhấn tab và bạn có thể hoàn thành từng dòng một. Đó là điều mà Sonnet 3.5 lần đầu tiên cho phép. Nhưng cảm giác là chúng tôi thực sự có thể tiến xa hơn thế rất nhiều. Và mô hình gần như đã sẵn sàng cho bước tiến lớn tiếp theo. Vì vậy, chúng tôi không cần phải làm gợi ý tự động nữa, chúng tôi chỉ cần có Tác nhân (AI) viết tất cả mã.

Những Thách Thức Ban Đầu và Bước Ngoặt

Và thế là tôi đã xây dựng nó, và nó thực sự không hoạt động trong 6 tháng đầu tiên. Nó không thực sự tốt. Nó hầu như không thể sử dụng được. Tôi đã dùng nó để viết khoảng 10% mã của mình hoặc gì đó. Và ngay cả sau khi chúng tôi phát hành Claude code ban đầu, nó cũng không phải là một cú hit lớn. Có rất nhiều người đã sử dụng nó, nhưng nó không có sự tăng trưởng theo cấp số nhân như ngày nay. Điều đó bắt đầu với Opus 4 vào tháng 5. Và tôi nhớ điều đó rất rõ ràng. Đó là khi sự tăng trưởng theo cấp số nhân bắt đầu, và sau đó nó tiếp tục tăng trưởng mạnh mẽ với mỗi bản phát hành mô hình. Nó bắt đầu với Opus 4, sau đó là 4.5, rồi 4.6, bây giờ là 4.7. Nó cứ tiếp tục tăng trưởng. Nhưng về cơ bản, chúng tôi đang cố gắng xây dựng thứ gì đó "trước PMF", và chúng tôi biết rằng nó sẽ không có PMF trong 6 tháng vì chúng tôi đang xây dựng cho mô hình tiếp theo. Và đó là ý tưởng xuyên suốt. Đối với Anthropic nói chung, chúng tôi luôn rất tập trung. Chúng tôi luôn quan tâm đến kinh doanh và doanh nghiệp, an toàn và mã hóa. Đó luôn là cách chúng tôi muốn xây dựng. Và vì vậy, tại một thời điểm nào đó, chúng tôi biết rằng chúng tôi muốn xây dựng một sản phẩm. Chúng tôi không biết chính xác chúng tôi muốn gì. Vì vậy, đây đã trở thành dự án sản phẩm được đặt cược. Đó là một câu chuyện đáng kinh ngạc, đặc biệt là việc nó là một tai nạn.

"Mã Hóa Đã Được Giải Quyết"?

Bạn đã từng nói rằng bạn nghĩ mã hóa đã được giải quyết. Nếu đây là một trong ba sản phẩm tốt nhất từ Anthropic, bạn có thể cho chúng tôi biết thêm về ý của bạn, và điều gì có thể vẫn chưa được giải quyết, hoặc những vấn đề thứ cấp nào có thể phát sinh? Được rồi. Tôi có thể hỏi một câu hỏi khác cho cả phòng. Ai viết 100% mã của mình bằng tay? Ai viết 100% mã của mình bằng một Tác nhân (AI) như Claude code? Được rồi. Ai ở đâu đó giữa hai lựa chọn đó? Được rồi. Vậy là, giải quyết được khoảng 50%. [tiếng cười]

Ý tôi là, đối với tôi thì đó là 100%. Cơ sở mã của Claude code, bạn biết đấy, nó đã bị rò rỉ, nên mọi người đều biết. Nó khá đơn giản. Chỉ là TypeScriptReact. Không có bí mật lớn nào cả. Không có gì thực sự phức tạp. Lý do chúng tôi chọn TypeScriptReact là vì nó rất phù hợp với mô hình. Khi chúng tôi bắt đầu xây dựng cơ sở mã, mô hình không thông minh như ngày nay, vì vậy ngôn ngữ và framework rất quan trọng. Ngày nay, nó có thể viết bất cứ thứ gì, và nó có thể học các ngôn ngữ mới, các framework mới mà nó chưa từng thấy. Nhưng hồi đó, bạn muốn sử dụng thứ gì đó khá phổ biến. Vì vậy, tôi nghĩ khá sớm chúng tôi đã đạt đến điểm mà mô hình chỉ viết 100% mã. Và đối với chúng tôi, điều này xảy ra vào khoảng tháng 10, tháng 11 năm ngoái. Và vì vậy, đối với tôi ngày nay, mô hình viết 100% mã của tôi. Tôi gửi, bạn biết đấy, thường là vài chục PRs mỗi ngày. Có một ngày tuần trước tôi đã gửi khoảng 150 PRs trong một ngày. Đó là một kỷ lục. Tôi chỉ cố gắng đẩy giới hạn xem tôi có thể đi xa đến đâu. Nhưng vâng, đối với tôi thì nó đã được giải quyết.

Tuy nhiên, điều này không phải lúc nào cũng đúng. Có những cơ sở mã rất lớn, phức tạp. Có những ngôn ngữ hơi lạ mà mô hình chưa giỏi. Và bạn biết đấy, như mọi người ở đây đều biết, nó đang dần tốt hơn. Thông thường câu trả lời chỉ là chờ mô hình tiếp theo.

Thiết Lập Làm Việc Cá Nhân của Boris

Bạn có thể kể cho chúng tôi nghe về thiết lập cá nhân của bạn không? Bạn đã kể cho chúng tôi nghe về nó vài ngày trước. Nó khá "điên rồ".

Vâng. Tôi đã chia sẻ thiết lập cá nhân của mình khoảng 6 tháng trước hoặc gì đó trên Twitter. Và thật buồn cười, tôi thực sự chia sẻ nó mà không nhận ra rằng nó sẽ gây bất ngờ cho bất kỳ ai. Đó chỉ là cách tôi viết mã. [tiếng cười] Và nó đã thay đổi kể từ đó. Nó đã thay đổi. Bây giờ, thực ra hầu hết công việc của tôi tôi làm từ điện thoại. Và vì vậy, tôi không biết liệu các bạn có thể nhìn thấy điều này không, nhưng tôi có ứng dụng Claude, và nếu bạn mở ứng dụng Claude, ở phía bên trái, có tab mã này, và tôi chỉ có rất nhiều phiên đang chạy. Các bạn có thể không nhìn thấy nó.

Hỏi: Bao nhiêu phiên?

Thông thường tôi có khoảng 5 đến 10 phiên. Và sau đó các phiên đó thường có rất nhiều Tác nhân (AI), vì vậy tôi nghĩ hiện tại có lẽ vài trăm Tác nhân (AI) đang hoạt động. Thông thường mỗi đêm tôi có khoảng vài nghìn Tác nhân (AI) đang làm những công việc chuyên sâu hơn. Có một vài cách để quản lý nó. Một là bạn yêu cầu Claude sử dụng một loạt các Tác nhân (AI) phụ để làm việc. Thực ra, điều mà tôi đang ngày càng sử dụng nhiều hơn là loop. Đây là /loop, và nó là thứ tuyệt vời nhất. Nó là thứ đơn giản nhất mà hoạt động hiệu quả. Tất cả những gì nó làm là bạn yêu cầu Claude sử dụng cron để lên lịch một tác vụ vào một thời điểm nào đó trong tương lai, và đó là một tác vụ lặp lại. Và nó có thể chạy mỗi phút, mỗi 5 phút, mỗi ngày, tùy theo tần suất bạn muốn lên lịch. Và ở thời điểm này, tôi có hàng tá loop đang chạy cho các công việc. Vì vậy, tôi có một loop đang giám sát các PRs của tôi, như sửa CI, tự động rebase. Tôi có một loop khác giữ cho CI hoạt động ổn định. Vì vậy, nếu có một bài kiểm tra không ổn định hay gì đó, nó sẽ đi sửa. Tôi có một loop khác lấy phản hồi từ Twitter và nhóm chúng lại cho tôi mỗi 30 phút. Vì vậy, tôi chỉ có rất nhiều loop này chạy bất cứ lúc nào. Tôi cảm thấy loop là tương lai ở thời điểm này. Nếu bạn chưa thử nghiệm với nó, tôi đặc biệt khuyên bạn nên làm vậy. Và chúng tôi cũng vừa ra mắt routines, là cùng một thứ nhưng hoạt động trên máy chủ. Vì vậy, ngay cả khi bạn đóng laptop, nó vẫn tiếp tục hoạt động.

Tương Lai của Các Nhóm Phát Triển

Đó là thiết lập cá nhân của bạn. Hãy kể cho chúng tôi nghe về việc bạn nghĩ các nhóm sẽ trông như thế nào trong tương lai. Làm thế nào bạn suy rộng từ tất cả công việc bạn đang làm để giữ cho mọi người trong nhóm tiến lên, hiểu được ngữ cảnh, hay bạn nghĩ chúng ta cần giao phó nhiều hơn cho các Tác nhân (AI) để nó hoạt động?

Tôi nghĩ rằng, thật khó để đưa ra dự đoán, nhưng tôi ở đây để đưa ra dự đoán, vì vậy tôi sẽ cố gắng. Tôi cảm thấy cách mọi thứ đang diễn ra là nhìn chung sẽ có nhiều "người đa năng" hơn so với hiện nay. Và ngày nay khi chúng ta nói về người đa năng, tôi nghĩ phần lớn chúng ta đang nói về những người vẫn là kỹ sư. Vì vậy, họ vẫn viết mã, nhưng có thể họ là "kỹ sư sản phẩm". Vậy có lẽ khi chúng ta nói người đa năng, đó là một người, bạn biết đấy, họ làm iOS và web và máy chủ chẳng hạn. Đó là một người đa năng trong kỹ thuật. Nhưng tôi nghĩ điều chúng ta sẽ bắt đầu thấy nhiều hơn là những người đa năng "đa ngành". Vì vậy, đây là những kỹ sư rất giỏi về kỹ thuật sản phẩm, nhưng cũng rất giỏi về thiết kế. Hoặc rất giỏi về sản phẩm và khoa học dữ liệu và kỹ thuật.

Tôi không biết. Đó là điều mà chúng tôi đang bắt đầu thấy trong đội của mình. Thực tế, rất nhiều người trong nhóm Claude code là những người đa năng trên các lĩnh vực khác nhau. Mọi người trong nhóm chúng tôi đều viết mã. Vì vậy, như quản lý kỹ thuật của chúng tôi, quản lý sản phẩm, các nhà thiết kế, nhà khoa học dữ liệu, người phụ trách tài chính, nhà nghiên cứu người dùng của chúng tôi, mọi người trong nhóm chúng tôi đều viết mã. Và vì vậy, bạn biết đấy, họ là chuyên gia về một lĩnh vực nào đó, nhưng bây giờ mọi người cũng đều viết mã. Và bạn biết đấy, tôi thấy một số người gật đầu, nhưng tôi cá rằng điều đó thực sự không quá ngạc nhiên đối với những người trong căn phòng này vì tôi cá là bạn cũng đang thấy những điều tương tự. [hắng giọng]

Tương Lai của Phần Mềm và Sản Phẩm

Tôi sẽ có một câu hỏi yêu thích nữa, sau đó chúng ta sẽ mở cho khán giả. Chúng ta đã nói một chút về những thay đổi trong mã hóa. Tôi tò mò về những gì bạn thấy đang thay đổi trong thế giới phần mềm hoặc các sản phẩm phần mềm.

[transcript bị gián đoạn]

AI và Năng suất Code

Tôi nghĩ khi chúng ta thấy AI làm cho việc viết code rẻ hơn 10 hoặc 100 lần, điều gì sẽ xảy ra với giá trị của các sản phẩm được tạo ra bằng phần mềm? Liệu chúng ta có đang đối mặt với một SaaS apocalypse không? Anh nghĩ điều này sẽ diễn ra như thế nào? Và một lần nữa, anh sẽ phải đưa ra một dự đoán khác. Câu hỏi về SaaS apocalypse là câu hỏi yêu thích của tôi.

Tác động của AI đến Hào chắn Kinh doanh

Tôi nghĩ có hai điều sẽ xảy ra, và tôi không nghĩ cả hai đều là những điều mọi người đã nói đến. Điều thứ nhất là: Có ai ở đây là thính giả của Acquired không? Giống như podcast Acquired ấy? Vâng, đó là podcast hay nhất. Tôi thực sự đã có dịp thực hiện một buổi unplugged với họ vào tuần trước, và tôi cảm thấy như mình được gặp các thần tượng của mình vì các người dẫn chương trình rất tuyệt.

Họ có ý tưởng về "Bảy Quyền Năng" (Seven Powers), và đây giống như Hamilton; anh ấy đã viết một cuốn sách về điều này, và đây là bảy hào chắn trong kinh doanh. Tôi nghĩ điều sẽ xảy ra là vì AI, một số hào chắn này sẽ trở nên quan trọng hơn, và một số sẽ ít quan trọng hơn. Chẳng hạn, một điều trở nên ít quan trọng hơn là chi phí chuyển đổi (switching costs) vì bạn chỉ cần sử dụng mô hình và có thể chuyển từ thứ này sang thứ khác. Một điều khác trở nên ít quan trọng hơn là sức mạnh quy trình (process power) vì đối với các công ty có hào chắnworkflowprocess, Claude đang trở nên thực sự giỏi trong việc tìm ra process. Và đặc biệt với phiên bản 4.7, nó có thể hill climb (tối ưu dần) bất cứ thứ gì. Vì vậy, nếu bạn cho nó một mục tiêu và bảo nó lặp lại cho đến khi hoàn thành, nó sẽ làm được. Tôi nghĩ đây là mô hình đầu tiên làm được điều đó. Vì vậy, tôi nghĩ những điều này sẽ trở nên ít quan trọng hơn, nhưng tôi nghĩ các hào chắn trước đây thực sự vẫn còn quan trọng. Đó là hiệu ứng mạng (network effects), kinh tế theo quy mô (scale economies), tài nguyên độc quyền (cornered resources), và những thứ tương tự. Những điều này không thực sự thay đổi với AI.

Cơ hội Vàng cho các Startup

Điều thứ hai là nếu bạn nhìn vào số lượng các startup hiện nay hoặc, nói là, trong 10 năm qua, tôi nghĩ số lượng các startup trong 10 năm tới sẽ phá vỡ mọi thứ sẽ tăng lên gấp 10 lần. Bởi vì ngay bây giờ, bạn có thể là một startup nhỏ, bạn có thể xây dựng một thứ có giá trị tương đương một công ty lớn, và bạn thực sự có thể cạnh tranh trực tiếp vì công ty lớn phải phát triển quy trình kinh doanh của họ, họ phải phát triển cách họ làm việc, họ phải đào tạo lại mọi người để sử dụng công nghệ, và họ sẽ đối mặt với rất nhiều sức cản nội bộ đối với điều đó. Nhưng bạn biết đấy, không ai ở đây gặp vấn đề đó. Nếu bạn bắt đầu từ đầu, bạn có thể xây dựng với AI một cách nguyên bản từ gốc. Vì vậy, tôi không biết. Tôi nghĩ đây là thời điểm tốt nhất để xây dựng. Đây là thời điểm tốt nhất để trở thành một startup. Có rất nhiều sự phá vỡ sắp tới. Vì vậy, rốt cuộc thì vẫn có hy vọng cho chúng ta. Cảm ơn, Boris.

Thành công của Claude Code: Mô hình hay Quyết định Sản phẩm?

Tôi muốn mở phần hỏi đáp cho khán giả nếu ai có câu hỏi nào. Dan? (Dan) Vâng, tôi tò mò. Anh nói rằng anh đã xây dựng trong 6 tháng trước khi có product market fit (sự phù hợp giữa sản phẩm và thị trường), nhưng bây giờ, khi các mô hình đã đủ tốt, anh gán công lao thành công của Claude Code bao nhiêu phần cho mô hình so với các quyết định sản phẩm trong lĩnh vực sản phẩm?

(Diễn giả) À, tôi nghĩ đó có lẽ là sự kết hợp. Vâng, tôi nghĩ đó là sự kết hợp. Tôi nghĩ nếu bạn hỏi tôi khoảng một năm trước, tỷ lệ có lẽ là 50/50. Có lẽ, tôi không biết. Nếu bạn hỏi tôi 6 tháng trước, tỷ lệ sẽ là 50/50. (Dan) Thế còn trong 2 năm nữa thì sao? (Diễn giả) Ồ, 2 năm nữa thì tôi không biết, anh bạn. Chúng tôi chỉ lập kế hoạch trong khoảng một tuần. (Dan) Vài tháng. Khi nào đó trong tương lai. [tiếng cười] (Diễn giả) Nhân tiện, tôi nghĩ lý do tỷ lệ là 50/50 là vì, bạn biết đấy, tôi đã tham gia YC (Y Combinator) ngày trước. Tôi là người đầu tiên được thuê ở một công ty YC và tôi đã thực hiện nhiều startup. Và trong các startup, điều mà họ luôn nhấn mạnh với bạn, đặc biệt là ở YC, đó là "xây dựng thứ gì đó mà mọi người yêu thích". Vì vậy, không quan trọng sản phẩm là gì, không quan trọng mô hình và tất cả những thứ này. Cuối cùng, bạn vẫn phải xây dựng một thứ mà mọi người yêu thích. Và tôi nghĩ đó là lý do tại sao sản phẩm lại quan trọng: chúng tôi chú ý rất nhiều đến từng chi tiết nhỏ để khi bạn sử dụng nó cả ngày, đó là một trải nghiệm thực sự tuyệt vời.

Sự Phát triển của Mô hình và Cơ Chế Điều Khiển

Tôi nghĩ khi mô hình trở nên tốt hơn, harness (cơ chế điều khiển) sẽ ít quan trọng hơn. Và tôi nghĩ điều chúng tôi đang cân nhắc bây giờ là làm thế nào để phát triển harness? Ví dụ, làm thế nào để biến vòng lặp (loops) thành một yếu tố hạng nhất? Làm thế nào để dễ dàng hơn trong việc chạy nhiều tác nhân (AI)? À, bạn biết đấy, tác nhân phụ (sub-agents) là một ý tưởng. Chúng tôi đang phát triển nhiều thứ khác nữa. Nhưng tôi nghĩ trong một năm nữa, mô hình sẽ được căn chỉnh tốt hơn nhiều. Và như vậy, tất cả các cơ chế an toàn mà chúng ta có ngày nay xung quanh prompt injection (tiêm lệnh), xác minh tĩnh (static verification) các lệnh, và chế độ quyền hạn (permission modes), con người trong vòng lặp (human in the loop), tất cả những thứ này sẽ trở nên ít quan trọng hơn vì mô hình sẽ tự động làm điều đúng đắn. Vâng, đó là dự đoán của tôi. Cảm ơn. (Diễn giả) Anh muốn ném cái hộp không, Dan? [khịt mũi] Tuyệt vời.

Dân chủ hóa Phần mềm: Từ Kỹ năng Chuyên biệt đến Kỹ năng Phổ biến

Để nhìn rộng hơn một chút khỏi phần mềm, tôi nghĩ Claude Code đã tạo ra một thay đổi văn hóa vài tháng trước khi nó dân chủ hóa việc xây dựng phần mềm. Bạn có thể thấy các chủ cửa hàng tự xây dựng phần mềm cho riêng mình hoặc thậm chí lập trình vi điều khiển để điều khiển đèn khi có người mở cửa. Anh có thấy trong tương lai, việc xây dựng phần mềm sẽ trở thành một kỹ năng như Microsoft Office không? Tức là, đó là một thứ mà mọi người đều có thể làm, không chỉ những người trong ngành công nghệ? (Diễn giả) Ồ Chúa ơi, vâng. Vâng. Vâng. Tôi nghĩ nó sẽ còn hơn thế nữa. Tôi nghĩ nó sẽ là, tôi không biết. Nó sẽ là một kỹ năng như, vâng, như tôi biết cách gửi tin nhắn văn bản.

Tôi nghĩ, bạn biết đấy, hai thể loại tôi đọc chủ yếu là khoa học viễn tưởng (sci-fi) và lịch sử công nghệ. Đây là những gì tôi đọc rất nhiều. Tôi nghĩ trong lịch sử công nghệ, có một điều mà đối với tôi là sự song song rõ ràng nhất cho những gì đang xảy ra bây giờ. Và đó là vào những năm 1400, máy in ở châu Âu. Điều đã xảy ra là trước máy in, về cơ bản 10% dân số châu Âu biết chữ. Họ biết đọc và viết. Họ thường được các vua chúa không biết chữ thuê mướn. Và công việc của họ là, bạn biết, công việc của họ là đọc và viết, và đây không phải là điều mà ai cũng biết làm. [khịt mũi] Máy in được phát minh, sau đó có thêm hai máy in nữa, và trong 50 năm sau máy in đầu tiên, có nhiều tài liệu được xuất bản ở châu Âu hơn trong hàng nghìn năm trước đó. Và trong cùng thời kỳ đó, chi phí tài liệu, chi phí một cuốn sách, đã giảm khoảng 100 lần. Và sau đó, bạn biết đấy, phải mất vài trăm năm vì, bạn biết đấy, học đọc và viết rất khó. Bạn cần hệ thống giáo dụcchính phủ, và không phải ai cũng có thể làm việc ở nông trại, v.v. Nhưng trong vài trăm năm tiếp theo, tỷ lệ biết chữ toàn cầu đã tăng lên khoảng 70%. Và như vậy, bạn biết đấy, bây giờ tất cả chúng ta đều có thể đọc và viết, và bạn không cần bằng cấp về đọc và viết để biết cách đọc và viết. Mặc dù vẫn có những nhà văn chuyên nghiệp, và đó là một nghề mà bạn có thể làm.

Vì vậy, tôi nghĩ điều sắp xảy ra, và nó sẽ nhanh hơn 50 năm rất nhiều, là phần mềm sẽ trở thành một thứ được dân chủ hóa hoàn toàn, mà bất cứ ai cũng có thể làm. Và bạn biết đấy, có rất nhiều hệ quả từ điều này. Ví dụ, giả sử bạn đang viết phần mềm kế toán. Người giỏi nhất để viết phần mềm kế toán, tôi nghĩ ngay cả ngày nay, không phải là một kỹ sư, mà là một kế toán giỏi thực sự vì họ hiểu miền kiến thức (domain) rất rõ, và viết code (coding) là phần dễ. Nắm vững miền kiến thức mới là phần khó. Và tôi nghĩ đây rõ ràng là tương lai.

Khoảng cách Công nghệ và Quy trình Tổ chức

Vì vậy, một trong những điều Greg nói là các bạn đang sống trong tương lai một chút vì các bạn có quyền truy cập vào các mô hình và các tác nhân (AI). Claude Code là một công cụ nội bộ trước khi các bạn phát hành nó. Vậy khoảng cách giữa vị trí của các bạn trong kỹ thuật (engineering) và phần còn lại của thế giới là bao lâu? Là một tháng? Ba tháng? Sáu tháng? Và khoảng cách đó đang lớn dần hay nhỏ đi theo thời gian?

(Diễn giả) Vâng, về mặt nội bộ, chúng tôi sử dụng các mô hình giống như mọi người khác. Đối với chúng tôi, dog fooding (tự dùng sản phẩm của mình) thực sự rất quan trọng. Vì vậy, chúng tôi sử dụng những gì mọi người ở đây đều dùng. Bạn biết đấy, chúng tôi sử dụng một chút Mythos để thử, và sau đó chúng tôi sử dụng rất nhiều Opus 4.7 để dog food và viết phần lớn code của mình. Tôi nghĩ về phía mô hình, thực sự không có khoảng cách. Bạn biết đấy, nó khá giống Mythos, và bạn biết đấy, một phiên bản nào đó hoặc một hậu duệ nào đó của nó sẽ có sẵn cho mọi người vào một thời điểm nào đó. Tôi nghĩ về phía sản phẩm, có lẽ có một khoảng cách lớn hơn nhiều. Và điều đó liên quan đến việc chúng tôi thay đổi tất cả các quy trình của mình. Chẳng hạn, nếu bạn nói chuyện với những người ở Anthropic, chúng tôi sử dụng Claude cho mọi thứ theo đúng nghĩa đen. Và các Claude của chúng tôi nói chuyện cả ngày; khi tôi coding, khi các Claude của tôi đang coding trong một vòng lặp, chúng sẽ giao tiếp qua Slack để nói chuyện với các Claude khác của những người khác cũng đang chạy trong một vòng lặp để tìm ra các ẩn số (unknowns). Chúng tôi không còn bất kỳ code nào được viết thủ công ở công ty nữa. Tất cả SQL đều do các mô hình viết. Mọi thứ đều được xây dựng bởi các mô hình.

Vì vậy, tôi nghĩ thực ra nơi chúng tôi dẫn đầu không phải là công nghệ vì công nghệ mà chúng tôi có sẵn cũng có sẵn cho mọi người ở đây, bởi vì về cơ bản, chúng tôi đang xây dựng một nền tảng (platform). Và vì vậy, đối với chúng tôi, điều thực sự quan trọng là các nhà phát triển có thể sử dụng cùng thứ mà chúng tôi đang dùng và chúng tôi dog food mọi thứ chúng tôi phát hành. Nhưng tôi nghĩ thực sự có một sự dẫn đầu lớn hơn nhiều trong cấu trúc tổ chức và quy trình tổ chức. Và đây là một nơi mà, bạn biết đấy, hy vọng chúng tôi có thể thảo luận về nó ở những nơi như thế này và mọi người cũng có thể học hỏi và phát triển. Vâng, và tôi nghĩ đó là một trong những lợi thế mà các startup có. Bắt đầu ở đó dễ dàng hơn rất nhiều.

Tiến hóa Multi-Agent và Prompting hiệu quả

(Jared) Vâng, ừm, lần trước chúng ta nói chuyện, tôi nghĩ anh có đề cập là chúng ta đã nói một chút về multi-agent (đa tác nhân), và lúc đó nó rất nhiều trong code tại một sự kiện Sequoia trước đây, và anh có nói rằng có một số thứ đang được phát triển trong pipeline và những điều anh đang suy nghĩ. Bây giờ rõ ràng có slash batch, có slash loop, có sub-teams (đội nhóm phụ), có teams (đội nhóm). Anh có thể nói thêm về việc ở cấp độ mô hình và ở cấp độ harness (cơ chế điều khiển), làm thế nào các bạn đưa tiên nghiệm (priors) vào cấp độ harness, làm thế nào hàm mục tiêu (objective function) đang thay đổi cấp độ mô hình để cải thiện trải nghiệm xung quanh việc ủy quyền công việc, khởi tạo các tác nhân (AI) tốt hơn? Bởi vì rất nhiều công việc có thể song song hóa (parallelizable). Bạn có thể làm rất nhiều việc nhanh hơn rất nhiều, và tôi cảm thấy như mình phải tự thêm trực giác của mình vào khi nào thì song song hóa mọi thứ thay vì mô hình tự hiểu rằng bạn có thể khởi tạo 10 tác nhân phụ (sub-agents) cho một việc gì đó.

(Diễn giả) Vâng, ý tôi là về phía sản phẩm, nó thực sự chỉ liên quan đến prompting (ra lệnh/nhắc lệnh). Đó là cách nó hoạt động. Và vì vậy, bạn biết đấy, chúng tôi điều chỉnh các prompt để giúp mô hình thực hiện công việc song song nhiều hơn. Nhưng thành thật mà nói, khi mô hình trở nên tốt hơn, nó tự nhiên làm điều này. Và vì vậy, một thứ như loop, tôi thực sự thấy 4.7 bắt đầu tự làm. Điều này thực sự tuyệt vời. Nó giống như nó làm điều gì đó như, bạn biết đấy, tôi sẽ nói với nó, "Hãy truy vấn dữ liệu này." Và nó nói, "Này, tôi nhận thấy dữ liệu đang thay đổi theo thời gian. Tôi sẽ bắt đầu một vòng lặp và tôi sẽ gửi cho bạn một báo cáo sau mỗi 30 phút." Và tôi nói, "Tuyệt vời. Bạn có thể gửi nó cho tôi qua Slack không?" Và sau đó nó sử dụng Slack MCP để làm điều đó. Vì vậy, tôi nghĩ thực ra theo thời gian, không phải người dùng phải tìm ra cách sử dụng công cụ tốt hơn. Và nếu đó là trường hợp, thì đó thực sự là một vấn đề thiết kế sản phẩm (product design problem) và tôi đang làm không tốt. Thực sự là mô hình phải làm những điều này tốt hơn và chúng tôi phải prompting nó để nó tự nhiên làm được điều này.

Xu hướng Điện toán: Cục bộ hay Đám mây?

Hiện tại, có vẻ như rất nhiều người trong chúng ta đang sử dụng, ừm, như Claude hoặc Codex hay những công cụ này trên đám mây để thực hiện phần lớn tài nguyên tính toán của mình. Nhưng sau đó, có một số người ủng hộ rất mạnh mẽ việc có Trí tuệ nhân tạo của bạn hoạt động cục bộ. Và tôi có thể hình dung rằng theo thời gian, khi các mô hình có trọng số công khai (open-weight models) và những thứ khác bắt kịp, điều này có thể trở thành một khả năng lớn hơn để mọi người nhận được hỗ trợ lập trình chất lượng cao. Vì vậy, tôi tò mò về tầm nhìn của bạn, ví dụ, trong vài năm tới. Bạn có thấy mọi người vẫn thực sự phụ thuộc vào tài nguyên tính toán tập trung trên đám mây, hay có một sự chuyển hướng sang "Ồ, tất cả chúng ta đều có các Tác nhân (AI) cục bộ mà chúng ta có thể tin cậy, và chúng không bị hạn chế băng thông cùng các lợi ích khác"? Vâng, tôi nghĩ, ừm, tôi không biết. Có lẽ có một vài cách để trả lời điều đó. Tôi nghĩ rằng, có lẽ, cách cơ bản nhất để trả lời là: "Điều đó không quan trọng." Bởi vì tôi nghĩ bây giờ chúng ta đang đạt đến điểm mà mô hình có thể tự mình tìm ra. Vì vậy, tôi nghĩ rằng trong vài năm tới, mô hình sẽ tự động làm tất cả mã. Nó sẽ khởi động các Tác nhân (AI). Nó sẽ xây dựng các môi trường. Và vì vậy, nếu nó quyết định rằng "Thực ra, tôi sẽ sử dụng các mô hình cục bộ để làm điều này," thì bạn biết đấy, đó là điều nó sẽ làm. Tôi không nghĩ đây sẽ là những quyết định mà chúng ta, với tư cách là kỹ sư, sẽ phải đưa ra nữa.

Tích hợp Công cụ và Luồng công việc với Co-work

Chúng ta còn thời gian cho một vài câu hỏi nữa, vậy tôi có thể đặt câu hỏi này. Jamie. Nester. Cảm ơn bạn. Có vẻ như một trong những quyết định tuyệt vời với Claude Code là tận dụng thực tế rằng rất nhiều công cụluồng công việc của nhà phát triển là cục bộ. Nhưng điều đó không nhất thiết luôn đúng đối với công việc tri thức tổng quát với, bạn biết đấy, công cụ đám mây. Tôi tò mò bạn đang suy nghĩ thế nào về điều này với Co-work: Làm thế nào để bạn cung cấp cho Co-work đủ quyền truy cập vào các công cụ mà chúng ta sử dụng để nó có thể mạnh mẽ theo cùng một cách mà Claude Code làm cho các nhà phát triển?

Vâng, đó là một câu hỏi thực sự tuyệt vời. Tôi biết khi tôi ở một công ty lớn, chúng tôi đã mất khoảng 5 năm để chuyển tất cả các môi trường sang từ xa. Đó là một công việc rất lớn, đặc biệt ở quy mô lớn. Nhưng đối với công việc tri thức, phần lớn nó đã có sẵn với các dịch vụ như SalesforceDocs và những thứ tương tự. Đối với chúng tôi, câu trả lời luôn là đơn giản nhất: đó là MCP. Vì vậy, cùng một trình kết nối MCP mà bạn có trong Claude AI, bạn có thể kết nối với Salesforce, bạn kết nối Google Docs, Google Calendar. Và sau đó Co-work có thể sử dụng nó. Claude CLI có thể sử dụng nó. Claude Code ở mọi nơi đều có thể sử dụng nó. Và đối với các hệ thống không có MCPs, bạn có nghĩ rằng đó là nơi sử dụng máy tính (computer use) sẽ là một cơ hội lớn không?

Vâng, tôi nghĩ sử dụng máy tính là một thuật ngữ bao quát. Vì vậy, tôi nghĩ hiện tại, theo như tôi biết, tôi nghĩ Anthropic đang khá dẫn đầu về computer use. Và vì vậy, nếu bạn sử dụng nó thông qua Co-work, nó khá tốt. Nó có thể sử dụng gần như bất kỳ phần mềm nào bạn có trên máy tính của mình. Nó rất chậm, nhưng hiện tại nó hoạt động khá tốt, đặc biệt với phiên bản 4.7. Vâng, nhưng tôi nghĩ nếu không thì MCP là câu trả lời. Và bạn biết đấy, tất cả những thứ này không thực sự quan trọng lắm. Nó có thể là MCPs, APIs, chỉ một dạng truy cập lập trình nào đó vì mô hình không quan tâm. Đối với mô hình, đó chỉ là các token.

Cơ hội Phát triển Sản phẩm Tương lai

Được rồi, chúng ta còn thời gian cho một câu hỏi nữa. Ryan. Sean, bạn có muốn chuyền (mic) không? Cảm ơn. Bạn đã có lần ám chỉ điều này, nhưng nếu cách đây một thời gian bạn nhận thấy product overhang và nghĩ đến việc xây dựng một sản phẩm mà sau đó sẽ trở nên thú vị hơn khi các mô hình trở nên tốt hơn, bạn có thể nói, dù chỉ một cách mơ hồ, về hình dạng của một sản phẩm mà bạn sẽ xây dựng hôm nay mà bạn nghĩ rằng có thể trở nên thú vị hơn nhiều khi các mô hình cải thiện trong 6 tháng đến một năm tới không?

Vâng, Claude Design tôi nghĩ là một ví dụ rất hay. Nó khá tốt hôm nay. Nó sẽ còn tốt hơn nhiều. Ngoài ra, chúng tôi cũng đang phát triển một vài thứ cho Claude Code sẽ ra mắt trong những tuần tới. Vì vậy, bạn sẽ thấy chúng. Và sau đó, tôi nghĩ, ừm, tôi nghĩ loopbatch và những thứ tương tự xoay quanh việc song song hóa các Tác nhân (AI) một cách lớn, điều đó sẽ ngày càng tốt hơn. Và sử dụng máy tính cũng là một ví dụ tốt khác. Được rồi, Boris. Cảm ơn rất nhiều vì đã tham gia cùng chúng tôi. Tôi nghĩ chúng ta sẽ ở lại đây thêm một chút nữa nếu ai có câu hỏi. [tiếng vỗ tay] Cảm ơn các bạn.

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