Người sáng lập Claude Code, Boris Cherny, chia sẻ 7 phán đoán quan trọng về AI tại hội nghị Sequoia

Sắp xếp: A Ying

Boris Cherny, người sáng lập Claude Code, đã chia sẻ tại hội nghị Sequoia, nội dung rất phong phú, nhiều quan điểm tôi lần đầu tiên nghe thấy một cách đầy đủ. Anh này thực sự hiểu khá sâu về AI.

Tôi chia sẻ một số điểm tổng kết của mình.

Đối với nhiều bối cảnh phát triển phổ biến, việc viết mã bằng tay đã bắt đầu trở thành một việc kém hiệu quả.

Trước đây, khi một tính năng cần được triển khai, các kỹ sư sẽ ngồi xuống, suy nghĩ kỹ cách thực hiện, sau đó gõ từng dòng mã. Trong quá trình này, giá trị lớn nhất của kỹ sư là: có biết viết mã không, viết có tốt không, và viết có nhanh không.

Cách thức hoạt động hiện tại đã khác đi.

Cùng một chức năng, những gì kỹ sư làm giống như: trước tiên làm rõ yêu cầu, chia nhỏ việc này thành vài phần giao cho Agent, đặt tiêu chí nghiệm thu, sau đó xem kết quả Agent đưa ra có đúng không, nếu sai thì điều chỉnh lời nhắc và cho nó chạy lại.

AI đã có thể xử lý phần lớn các nhiệm vụ lập trình. Tuy nhiên, vẫn chưa đạt 100%, còn nhiều thư viện mã lớn và phức tạp, ngôn ngữ ít phổ biến hoặc môi trường đặc biệt mà các mô hình hiện tại vẫn chưa thể xử lý tốt.

Nhìn chung, giá trị của các kỹ sư đã chuyển từ việc có biết viết mã hay không, sang việc có biết phân chia nhiệm vụ, có biết giải thích rõ mục tiêu, có biết nghiệm thu kết quả và có biết quản lý Agent hay không.

Sự thay đổi này thực sự rất giống với Cách mạng Công nghiệp.

Trước Cách mạng Công nghiệp, một thợ rèn tự mình thực hiện toàn bộ quy trình từ đúc, rèn, đánh bóng đến lắp ráp. Những thợ rèn tay nghề cao tự nhiên sẽ có giá trị cao.

Sau đó, dây chuyền sản xuất ra đời. Mỗi công nhân chỉ phụ trách một công đoạn, nhưng tổng sản lượng lại cao hơn hàng chục đến hàng trăm lần so với thời kỳ thủ công.

Lúc này, vai trò có giá trị nhất trong nhà máy không còn là những thợ thủ công làm tốt nhất một công đoạn nào đó, mà là người có thể thiết kế, quản lý và đảm bảo dây chuyền sản xuất hoạt động trơn tru.

Người lao động không biến mất, nhưng vai trò của người lao động đã thay đổi.

Ngành kỹ thuật phần mềm hiện đang trải qua một bước ngoặt tương tự. Chính mã nguồn không còn là tài nguyên khan hiếm. Việc viết mã đang trở thành kỹ năng cơ bản, giống như việc sử dụng PPT.

Điều thực sự khan hiếm là liệu bạn có thể chia các nhu cầu mơ hồ thành các nhiệm vụ rõ ràng, có thể chọn ra phương án phù hợp nhất trong số các phương án mà Agent đưa ra, và có thể khiến một nhóm AI phối hợp với nhau để hoàn thành một việc gì đó.

Thực ra, nhiều kỹ sư kỳ cựu ban đầu không thể chấp nhận được điều này. Việc tự tay viết mã chính là lý do khiến nhiều người yêu thích ngành này trong vài thập kỷ qua.

Giao việc này cho máy móc, với nhiều người, không chỉ là cách làm việc thay đổi, mà còn là sự tái định danh.

But a trend is a trend.

Lập trình đang từ một kỹ năng chuyên môn trở thành một kỹ năng cơ bản. Việc này có thể so sánh với công nghệ in ấn ở châu Âu thế kỷ 15.

Trước khi kỹ thuật in ấn được phát minh, chỉ khoảng 10% dân số châu Âu biết đọc viết. Những người này thường được các quý tộc không biết đọc viết thuê để giúp đọc và viết thư.

Sau đó, kỹ thuật in ấn ra đời. Trong 50 năm, số lượng sách được xuất bản ở châu Âu vượt quá tổng số sách được xuất bản trong 1.000 năm trước đó, giá sách giảm khoảng 100 lần. Phải mất vài trăm năm nữa để các hệ thống hỗ trợ đi kèm (hệ thống giáo dục, cấu trúc kinh tế dần theo kịp), tỷ lệ biết chữ toàn cầu mới tăng lên mức 70% như ngày nay.

Boris cho rằng, ảnh hưởng của AI đối với phần mềm là một cuộc cách mạng in ấn được tăng tốc. Phần mềm sẽ được dân chủ hóa hoàn toàn trong vài thập kỷ tới, trở thành thứ mà bất kỳ ai cũng có thể sử dụng được.

Cuối cùng, việc làm phần mềm sẽ trở nên tự nhiên như việc gửi tin nhắn.

Khi ngưỡng cửa của việc viết mã bị AI hạ xuống cực thấp, điều thực sự phân biệt năng lực của một người là cảm nhận sản phẩm và sự hiểu biết thực sự về một lĩnh vực cụ thể.

Ví dụ: Hai người cùng muốn phát triển một sản phẩm hướng đến các bác sĩ. Một người là kỹ sư viết code nhanh, người kia từng làm việc vài năm trong khoa thông tin bệnh viện.

Trước đây, kỹ sư có khả năng cao hơn trong việc hiện thực hóa ý tưởng, vì họ có thể biến ý tưởng đó thành hiện thực.

Bây giờ thì ngược lại. Ai cũng có thể hiện thực hóa ý tưởng. Lúc này, người thật sự hiểu quy trình làm việc hàng ngày của bệnh viện lại trở nên quý giá hơn. Vì anh ấy biết những tính năng nào thực sự sẽ được bác sĩ sử dụng, và những tính năng nào chỉ nghe thì có vẻ hợp lý.

Nói cách khác, sau khi AI xóa bỏ rào cản thực thi, sự khác biệt về khả năng phán đoán trở nên rõ rệt hơn.

Sự việc này đã trực tiếp thay đổi ý nghĩa của từ "generalist".

Trước đây, khi chúng ta nói đến generalist, thường ám chỉ một kỹ sư có thể viết cả iOS, Web và backend. Loại generalist này, về bản chất, vẫn là full-stack trong nội bộ kỹ thuật.

Tương lai của chuyên gia tổng hợp là toàn diện và đa ngành.

Có người am hiểu đồng thời về sản phẩm, thiết kế và kỹ thuật. Có người am hiểu đồng thời về sản phẩm, khoa học dữ liệu và kỹ thuật. Sự kết hợp này trước đây gần như không thể, vì mỗi lĩnh vực đều đòi hỏi thời gian dài đào tạo chuyên sâu.

Bây giờ AI đã hạ thấp ngưỡng thực hiện cho từng hạng mục, một người có thể vượt qua nhiều lĩnh vực và vẫn giữ được độ sâu chuyên môn.

Đội ngũ Claude Code chính là như vậy. Quản lý kỹ thuật, PM, nhà thiết kế, nhà khoa học dữ liệu, tài chính, nghiên cứu người dùng, mọi người đều viết mã.

Các nhà thiết kế có thể tự chạy giao diện mẫu để trình bày cho nhóm, thay vì chỉ tạo hình ảnh và chờ kỹ sư thực hiện.

Bộ phận tài chính có thể tự xây dựng một công cụ phân tích để chạy các mô hình tài chính phức tạp của công ty, thay vì phải xếp hàng chờ BI. Các đồng nghiệp trong bộ phận nghiên cứu người dùng bắt đầu tự chạy dữ liệu, tự đảm nhận phần công việc trước đây cần sự phối hợp từ đội ngũ dữ liệu.

Mỗi người vẫn giữ được độ sâu chuyên môn của mình. Nhưng với sự hỗ trợ của AI, việc viết mã đã trở thành ngôn ngữ chung của mọi người.

Trong hơn một thập kỷ qua, ngành SaaS có một vài nguyên tắc được coi như chân lý.

Chi phí chuyển đổi là第一条。Một công ty sau khi sử dụng hệ thống của bạn, trong đó sẽ dần tích lũy dữ liệu, cấu hình, trường, quan hệ quyền hạn trong nhiều năm thậm chí cả chục năm.

Việc chuyển sang một hệ thống khác, chỉ riêng việc di chuyển những thứ này nguyên vẹn ra rồi lại nhập vào đã đủ khiến người ta nản lòng đến mức không muốn động đến.

Điều thứ hai là khóa quy trình làm việc. Các thao tác hàng ngày của nhân viên, hợp tác liên phòng ban và các nút phê duyệt đều được xây dựng xung quanh SaaS này.

Việc thay đổi hệ thống không chỉ là di chuyển dữ liệu, mà là phá bỏ toàn bộ những ký ức cơ bắp mà công ty đã phát triển trong vài năm qua để xây dựng lại từ đầu.

Together, these two elements formed the deepest moat in the SaaS industry in the past. But with a sufficiently strong model, the logic of things begins to change.

Hãy xem xét chi phí chuyển đổi. Trước đây, để chuyển từ một SaaS này sang một SaaS khác, chỉ riêng việc đồng bộ các trường dữ liệu và tái tạo cấu trúc dữ liệu đã đủ khiến đội ngũ kỹ thuật phải làm thêm hàng tháng.

Bây giờ hãy trực tiếp cung cấp giao diện và cấu trúc dữ liệu của cả hai bên cho mô hình, để nó tự mình làm rõ mối quan hệ ánh xạ, từng bước tiến tới giải pháp tối ưu. Những việc trước đây mất vài tháng có thể chỉ cần vài ngày là đã tạo ra được phiên bản có thể sử dụng.

Hãy xem phía khóa quy trình, điều này thú vị hơn. Trước đây, quy trình có thể khóa khách hàng vì chính những quy trình này phức tạp, ẩn và phụ thuộc vào con người.

Sự đồng thuận trong đầu nhân viên về ai tìm ai phê duyệt và bước nào bị kẹt ở đâu không thể sao chép trực tiếp.

Nhưng những mô hình như Opus 4.7 lại đặc biệt giỏi trong việc hiểu, phân tách và tái xây dựng một quy trình phức tạp trong môi trường mới. Thậm chí, phiên bản được tái xây dựng có thể còn trơn tru hơn phiên bản gốc.

Vì vậy, những hàng rào bảo vệ được xây dựng dựa trên sự tích lũy dữ liệu và quy trình đang sụp đổ.

Đây có thể là tin không tốt cho những người đang phát triển SaaS. Nhưng đối với tất cả khách hàng sử dụng SaaS và các đội ngũ đang chuẩn bị xây dựng SaaS thế hệ mới, đây là cơ hội thực sự.

Các công ty khởi nghiệp thực sự làm thay đổi ngành công nghiệp trong 10 năm tới có thể nhiều gấp 10 lần so với 10 năm trước.

Lý do thực ra không phức tạp.

Các đội nhóm nhỏ có thể dùng AI để tạo ra sản phẩm ngang hàng hoặc thậm chí tốt hơn so với các công ty lớn. Ngược lại, các công ty lớn muốn thực sự ứng dụng AI lại trở thành tài sản負.

How to say it?

Một công ty có hơn mười năm lịch sử, đã xây dựng được toàn bộ quy trình kinh doanh, phân công vị trí, thói quen hợp tác, hệ thống đào tạo và hệ thống đánh giá KPI của riêng mình. Những thứ này trong quá khứ là tài sản, là rào cản.

Nhưng để thực sự tích hợp AI vào, mọi thứ đều cần được xem xét lại: các quy trình kinh doanh phải được tái cấu trúc, tất cả nhân viên phải được đào tạo lại, mỗi bước tiến đều gặp phải sự phản kháng nội bộ lớn, cần phối hợp N bộ phận, N cấp phê duyệt.

Một đội ngũ khởi nghiệp gồm ba người đã coi AI là nền tảng mặc định kể từ ngày đầu tiên. Họ không có gánh nặng lịch sử để gỡ bỏ, không có thói quen nào cần thay đổi, và không ai cần được thuyết phục. Hôm nay thảo luận rõ ràng, ngày mai chạy demo, ngày sau đã có thể上线 để người dùng sử dụng.

Sự chênh lệch tốc độ này thực ra trước đây đã tồn tại. Các công ty khởi nghiệp vốn luôn có lợi thế về tốc độ so với các công ty lớn. Nhưng AI đã khuếch đại sự chênh lệch này lên nhiều lần.

Tại sao?

Vì AI càng mạnh, thì một cá nhân trong cùng một đơn vị thời gian có thể khuếch đại đòn bẩy càng lớn. Một nhóm nhỏ thực sự sử dụng tốt AI, sản lượng hôm nay có thể tương đương với mười người trước đây, ngày mai có thể tương đương với ba mươi người trước đây.

Nhưng trọng lượng tổ chức của các công ty lớn không trở nên nhẹ hơn, mà ngược lại, do phải xử lý AI, chúng trở nên nặng hơn. AI càng mạnh, sự chênh lệch giữa gia tốc của các nhóm nhỏ và lực kéo của các công ty lớn càng bị kéo rộng ra.

Đây chính là tài sản âm mà Boris nói đến. Không phải vì các công ty lớn thiếu tiền, thiếu người hay thiếu ý chí, mà là những khả năng từng mang lại lợi nhuận trong quá khứ của họ hiện đang vướng mắc trên con đường AI thực sự phát huy giá trị.

MCP sẽ không chết.

Sau khi Skill trở nên phổ biến, nhiều người cho rằng MCP không còn cần thiết. Người sáng lập OpenClaw cũng có quan điểm tương tự.

But Boris doesn't see it that way. He believes MCP will become the software glue layer of the AI era.

Cách kết nối phần mềm của internet trước đây là API.

Nhưng vấn đề cốt lõi của API là nó được thiết kế dành cho các kỹ sư. Để sử dụng một API, bạn phải đọc tài liệu, xin Token, viết mã, đồng bộ các trường, xử lý ngoại lệ. Nói cách khác, API là dành cho các nhà phát triển con người.

MCP khác biệt. Nó cho phép mô hình kết nối trực tiếp và tự đọc hiểu để điều chỉnh, không cần một lập trình viên dịch thuật thay nó.

Vì vậy, Boris gọi API là Human Developer Interface và MCP là Model Interface Protocol. Một cái dùng cho con người, một cái dùng cho mô hình.

Điều này thực sự rất giống với thời điểm đó. Trong thời đại di động, mọi dịch vụ đều được mặc định là phải được API hóa. Trong thời đại AI, mọi dịch vụ đều được mặc định là phải được MCP hóa.

Nhiều người hiện nay khi nói đến Computer Use, cảm thấy hướng này có thể không khả thi.

Lý do cũng rất hợp lý: tốn quá nhiều Token, chạy chậm và không ổn định. Có vẻ như đây chỉ là một bản demo trình diễn kỹ thuật, còn xa mới đạt được mức độ có thể sử dụng thực tế.

Nhưng Boris nhìn thấy một khía cạnh hoàn toàn khác.

Điều anh ấy thực sự coi trọng là Computer Use đã giải quyết một trong những điểm đau lớn nhất trong việc ứng dụng AI: trong thế giới thực, có rất nhiều hệ thống không có API cũng không có MCP.

Đặc biệt là thế giới doanh nghiệp.

Chỉ khi vào công ty mới biết, bên trong có rất nhiều hệ thống cốt lõi đã cũ kỹ. ERP, OA, hệ thống kế toán, phê duyệt nội bộ, nền tảng chuỗi cung ứng, nhiều hệ thống tùy chỉnh khác. Rất nhiều hệ thống không có giao diện mở, không có tài liệu, không có khả năng tự động hóa. Chúng vẫn tồn tại ở đó, mỗi ngày đều được hàng ngàn nhân viên thao tác thủ công.

Tại sao không trực tiếp tạo API cho chúng?

Vì không thể thực hiện được. Nhà cung cấp phát triển các hệ thống này có thể đã không còn tồn tại. Bộ phận IT không có động lực cũng không có ngân sách để tái cấu trúc.

Bộ phận kinh doanh càng không thể dừng lại chờ đợi sáu tháng hoặc một năm. Những hệ thống này sẽ không bao giờ chờ đợi một API hoàn hảo để cứu lấy chúng.

Trong ngắn hạn, các mô hình lớn vẫn sẽ tiếp tục cải thiện khả năng sử dụng máy tính của mình.