
Bảy đánh giá quan trọng của người sáng lập Claude Code tại Hội nghị Sequoia
Tuyển chọn TechFlowTuyển chọn TechFlow

Bảy đánh giá quan trọng của người sáng lập Claude Code tại Hội nghị Sequoia
Các công ty khởi nghiệp thực sự gây ra sự xáo trộn trong ngành trong 10 năm tới có thể nhiều hơn gấp 10 lần so với 10 năm trước.
Tổng hợp: A Ảnh
Chia sẻ của Boris Cherny – người sáng lập Claude Code – tại hội nghị Sequoia chứa lượng thông tin rất lớn; nhiều quan điểm trong đó là lần đầu tiên tôi được nghe đầy đủ. Anh chàng này thực sự hiểu khá sâu về AI.
Dưới đây là phần tổng kết cá nhân của tôi.
01 Mã nguồn không còn khan hiếm
Đối với phần lớn các tình huống phát triển phổ biến hiện nay, việc viết mã thủ công bởi con người đang dần trở thành một hoạt động kém hiệu quả.
Trước đây, để triển khai một tính năng, kỹ sư sẽ ngồi xuống, suy nghĩ kỹ lưỡng cách thức thực hiện, rồi từng dòng một gõ mã vào máy tính. Trong quá trình này, giá trị lớn nhất của kỹ sư nằm ở việc: liệu họ có biết viết mã hay không, viết tốt đến đâu và viết nhanh thế nào.
Cách làm việc hiện nay đã khác.
Với cùng một tính năng, vai trò của kỹ sư giờ đây giống như: trước tiên làm rõ yêu cầu, sau đó chia công việc thành nhiều phần giao cho các Agent, thiết lập tiêu chuẩn kiểm tra và cuối cùng xem xét kết quả do Agent tạo ra có đúng hay không — nếu sai thì điều chỉnh prompt và yêu cầu chạy lại.
AI hiện đã có thể xử lý phần lớn các tác vụ lập trình. Dĩ nhiên, chưa phải 100%, vì vẫn còn nhiều kho mã khổng lồ và phức tạp, các ngôn ngữ ít phổ biến hoặc môi trường đặc thù mà các mô hình hiện tại chưa đáp ứng tốt.
Nhìn tổng thể, giá trị cốt lõi của kỹ sư không còn nằm ở khả năng viết mã, mà chuyển sang khả năng phân chia nhiệm vụ, diễn đạt mục tiêu một cách rõ ràng, kiểm tra đánh giá kết quả và quản lý các Agent.
Sự thay đổi này 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 đảm nhận toàn bộ quy trình: từ luyện kim, rèn, đánh bóng đến lắp ráp. Một thợ rèn tay nghề cao đương nhiên rất được trọng dụng.
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 duy nhất, nhưng tổng sản lượng lại tăng gấp hàng chục, thậm chí hàng trăm lần so với thời kỳ thủ công.
Lúc này, nhân tố mang lại giá trị cao nhất trong nhà máy không còn là người thợ giỏi nhất ở một công đoạn cụ thể, mà là người có khả năng thiết kế, vận hành và tối ưu hóa toàn bộ dây chuyền sản xuất.
Người lao động không biến mất, nhưng vai trò của họ đã thay đổi.
Hiện nay, kỹ thuật phần mềm cũng đang bước qua một bước ngoặt tương tự. Bản thân mã nguồn không còn là thứ khan hiếm. Việc biết viết mã đang dần trở thành một kỹ năng nền tảng, giống như việc biết sử dụng PowerPoint.
Thứ thực sự khan hiếm chính là khả năng chuyển đổi những yêu cầu mơ hồ thành các nhiệm vụ rõ ràng, khả năng lựa chọn phương án tối ưu nhất trong số nhiều giải pháp do Agent đề xuất, và khả năng phối hợp nhiều mô hình AI để cùng hoàn thành một công việc.
Nhiều kỹ sư giàu kinh nghiệm ban đầu khó chấp nhận điều này. Việc tự tay viết mã vốn là lý do khiến nhiều người yêu thích ngành này suốt vài chục năm qua.
Giao việc này cho máy móc không chỉ thay đổi phương thức làm việc, mà còn là một lần tái định hình bản sắc nghề nghiệp.
Tuy nhiên, xu thế thì luôn là xu thế.
02 Giống như máy in Gutenberg
Việc lập trình đang chuyển từ một kỹ năng chuyên môn thành một năng lực nền tảng. Sự chuyển dịch này có thể so sánh với sự ra đời của kỹ thuật in ấn ở châu Âu thế kỷ XV.
Trước khi máy in ra đời, toàn châu Âu chỉ khoảng 10% dân số biết chữ. Những người biết chữ thường làm việc cho giới quý tộc không biết chữ, chuyên đảm nhiệm việc đọc và viết thay họ.
Sau đó, máy in xuất hiện. Trong vòng 50 năm, số lượng sách được xuất bản tại châu Âu vượt quá tổng số sách được sản xuất trong suốt một ngàn năm trước đó; giá sách giảm khoảng 100 lần. Sau hàng trăm năm đi kèm (hệ thống giáo dục và cấu trúc kinh tế dần được hoàn thiện), tỷ lệ biết chữ trên toàn cầu mới đạt 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 phiên bản tăng tốc của cuộc cách mạng in ấn. Phần mềm sẽ được dân chủ hóa hoàn toàn trong vài chục năm tới, trở thành thứ bất kỳ ai cũng có thể sử dụng thành thạo.
Cuối cùng, việc xây dựng phần mềm sẽ trở nên tự nhiên như việc gửi tin nhắn.
03 Đâu là năng lực quan trọng nhất?
Khi AI hạ thấp rào cản của việc viết mã xuống mức cực kỳ thấp, yếu tố thực sự phân biệt năng lực của một người chính là “giác quan sản phẩm” và sự am hiểu sâu sắc về một lĩnh vực cụ thể.
Ví dụ: Hai người cùng phát triển một sản phẩm dành riêng cho bác sĩ. Một người là kỹ sư lập trình nhanh, người kia từng làm việc vài năm tại phòng Thông tin Bệnh viện.
Trước đây, kỹ sư có khả năng cao hơn trong việc đưa ý tưởng thành hiện thực, do đó xác suất hoàn thành sản phẩm cũng cao hơn.
Giờ đây, tình thế đảo ngược. Bất kỳ ai cũng đều có thể hiện thực hóa ý tưởng. Lúc này, người thực sự am hiểu quy trình làm việc hàng ngày tại bệnh viện lại trở nên quý giá hơn cả. Bởi anh/cô ấy biết rõ tính năng nào bác sĩ thực sự sẽ dùng, và tính năng nào chỉ nghe có vẻ hợp lý.
Nói cách khác, khi AI san bằng rào cản thực thi, sự chênh lệch về năng lực phán đoán lại càng được khuếch đại.
Điều này trực tiếp làm thay đổi nghĩa của từ “generalist”.
Trước đây, khi nói đến generalist, chúng ta thường ám chỉ một kỹ sư vừa có thể viết ứng dụng iOS, vừa viết được Web, vừa làm được backend. Loại generalist này về bản chất vẫn là “full-stack” trong phạm vi kỹ thuật.
Generalist trong tương lai sẽ là “full-stack liên ngành”.
Có người đồng thời am hiểu sản phẩm, thiết kế và kỹ thuật. Có người lại kết hợp nhuần nhuyễn sản phẩm, khoa học dữ liệu và kỹ thuật. Các tổ hợp như vậy trước đây gần như bất khả thi, bởi mỗi lĩnh vực đều đòi hỏi thời gian đào tạo chuyên sâu kéo dài.
Nhưng hiện nay, AI đã hạ thấp rào cản thực thi ở mọi lĩnh vực, giúp một người có thể bao quát nhiều mảng khác nhau mà vẫn giữ được độ sâu chuyên môn.
Đội ngũ Claude Code chính là ví dụ điển hình. Quản lý kỹ thuật, quản lý sản phẩm (PM), nhà thiết kế, nhà khoa học dữ liệu, chuyên viên tài chính và nhà nghiên cứu người dùng — tất cả đều viết mã.
Nhà thiết kế có thể tự chạy thử nghiệm nguyên mẫu tương tác và trình bày trực tiếp với nhóm, thay vì chỉ vẽ thiết kế rồi chờ kỹ sư triển khai.
Chuyên viên tài chính có thể tự xây dựng công cụ phân tích để chạy mô hình tài chính phức tạp của công ty, không cần xếp hàng chờ đội BI hỗ trợ. Đồng nghiệp làm nghiên cứu người dùng bắt đầu tự xử lý dữ liệu, tự chủ động thực hiện phần công việc trước đây phải nhờ đội dữ liệu phối hợp.
Độ sâu chuyên môn của mỗi người vẫn được bảo toàn. Nhưng dưới sự hỗ trợ của AI, việc viết mã đã trở thành “ngôn ngữ chung” cho tất cả.
04 Hào thành bảo vệ SaaS đang dần sụp đổ
Trong hơn một thập kỷ qua, ngành SaaS đã hình thành một số nguyên tắc gần như được coi là chân lý.
Nguyên tắc đầu tiên là chi phí chuyển đổi. Khi một doanh nghiệp đã sử dụng hệ thống của bạn, hàng năm trời dữ liệu, cấu hình, trường dữ liệu và mối quan hệ phân quyền sẽ dần được tích lũy bên trong.
Việc chuyển sang một hệ thống khác chỉ riêng việc di chuyển nguyên trạng những yếu tố này cũng đủ khiến người ta đau đầu đến mức không muốn động đến.
Nguyên tắc 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 xoay quanh hệ thống SaaS này.
Chuyển đổi hệ thống không chỉ đơn thuần là di chuyển dữ liệu, mà còn là phá bỏ toàn bộ “ký ức cơ bắp” mà công ty đã tích lũy trong nhiều năm qua.
Hai nguyên tắc này cộng lại tạo nên hào thành sâu nhất của ngành SaaS trong quá khứ. Tuy nhiên, khi các mô hình đủ mạnh xuất hiện, logic của vấn đề bắt đầu thay đổi.
Xét về chi phí chuyển đổi: Trước đây, để chuyển từ một hệ thống SaaS sang hệ thống khác, riêng việc khớp các trường dữ liệu và sao chép lại cấu trúc dữ liệu cũng đủ khiến đội kỹ thuật phải tăng ca hàng tháng trời.
Giờ đây, chỉ cần đưa giao diện và cấu trúc dữ liệu của cả hai hệ thống vào mô hình, để nó tự tìm ra mối quan hệ ánh xạ và từng bước tiến gần tới nghiệm tối ưu. Việc vốn mất hàng tháng trời nay có thể cho ra một phiên bản sử dụng được chỉ trong vài ngày.
Xét về khóa quy trình làm việc — điều này còn thú vị hơn. Trước đây, quy trình làm việc có thể “khóa” khách hàng vì bản thân quy trình vốn phức tạp, tiềm ẩn và phụ thuộc vào con người.
Sự thấu hiểu ngầm giữa các nhân viên — như ai cần phê duyệt ai, và bước nào thường bị nghẽn — không thể dễ dàng sao chép nguyên trạng.
Tuy nhiên, các mô hình như Opus 4.7 lại đặc biệt giỏi trong việc đọc hiểu một quy trình phức tạp, phân tích từng phần và tái xây dựng nó trong môi trường mới — thậm chí phiên bản tái tạo còn có thể vận hành trơn tru hơn cả bản gốc.
Do đó, hào thành được xây dựng dựa trên tích lũy dữ liệu và quy trình đang dần tan rã.
Đối với các công ty đang làm SaaS, đây có thể là một tin xấu. Nhưng đối với toàn bộ khách hàng sử dụng SaaS và các đội ngũ đang chuẩn bị xây dựng thế hệ SaaS mới, đây lại là một cơ hội thực sự.
05 Thời đại tuyệt vời nhất cho các nhà khởi nghiệp
Trong 10 năm tới, số lượng công ty khởi nghiệp thực sự gây ra bước đột phá trong ngành có thể tăng gấp 10 lần so với 10 năm trước.
Lý do thực ra khá đơn giản.
Các nhóm nhỏ có thể sử dụng AI để tạo ra sản phẩm ngang tầm hoặc thậm chí vượt trội hơn các tập đoàn lớn. Ngược lại, việc triển khai AI thực sự lại trở thành “tài sản âm” đối với các tập đoàn.
Tại sao lại như vậy?
Một công ty có bề dày hàng chục năm đã hình thành một hệ thống quy trình nghiệp vụ, phân công vị trí, thói quen cộng tác, hệ thống đào tạo và tiêu chí đánh giá KPI hoàn chỉnh. Những yếu tố này trước đây là tài sản, là rào cản cạnh tranh.
Nhưng để tích hợp AI một cách thực sự, toàn bộ hệ thống này đều phải được xem xét lại: quy trình nghiệp vụ cần được tái cấu trúc, toàn bộ nhân viên phải được đào tạo lại, mỗi bước tiến đều vấp phải sức cản nội bộ khổng lồ, và phải phối hợp với N phòng ban, N cấp phê duyệt.
Trong khi đó, một nhóm khởi nghiệp chỉ ba người từ ngày đầu tiên đã lấy AI làm nền tảng mặc định. Họ không gánh nặng lịch sử để loại bỏ, không thói quen nào để thay đổi, và không ai cần thuyết phục. Hôm nay thảo luận rõ ràng, ngày mai chạy ra bản demo, ngày kia đã có thể triển khai cho người dùng sử dụng.
Khoảng cách về tốc độ này thực ra đã tồn tại trước khi có AI. Các công ty khởi nghiệp vốn dĩ đã có lợi thế về tốc độ so với tập đoàn. Nhưng AI đã khuếch đại khoảng cách này lên rất nhiều lần.
Tại sao?
Vì AI càng mạnh, năng lực đòn bẩy mà một người có thể tạo ra trong một đơn vị thời gian càng lớn. Một nhóm nhỏ thực sự tận dụng tốt AI hôm nay có thể đạt năng suất tương đương mười người trước đây, và ngày mai có thể tương đương ba chục người.
Trong khi khối lượng tổ chức của tập đoàn không hề nhẹ đi, mà còn trở nên nặng nề hơn do phải “tiêu hóa” AI. AI càng mạnh, khoảng cách giữa gia tốc của nhóm nhỏ và lực cản của tập đoàn càng giãn rộng.
Đây chính là điều Boris gọi là “tài sản âm”: Không phải tập đoàn thiếu tiền, thiếu người hay thiếu ý chí, mà chính là những “cơ bắp kiếm tiền” từng giúp họ thành công trong quá khứ, nay lại vô tình cản trở AI phát huy giá trị thực sự.
06 MCP sẽ không chết
MCP sẽ không chết.
Sau khi “Skill” nổi lên, nhiều người cho rằng MCP đã trở nên dư thừa. Người sáng lập OpenClaw cũng có quan điểm tương tự.
Tuy nhiên, Boris lại không nghĩ vậy. Ông cho rằng MCP sẽ trở thành “lớp kết nối phần mềm” trong kỷ nguyên AI.
Trước đây, cách kết nối phần mềm trên Internet là thông qua API.
Nhưng vấn đề cốt lõi của API nằm ở chỗ: nó được thiết kế dành riêng cho kỹ sư. Để sử dụng một API, bạn phải tra cứu tài liệu, đăng ký Token, viết mã, khớp các trường dữ liệu và xử lý ngoại lệ. Nói trắng ra, API là dành cho các nhà phát triển con người.
MCP thì khác. Nó cho phép mô hình kết nối trực tiếp và sử dụng ngay lập tức — mô hình tự đọc hiểu và gọi hàm mà không cần một lập trình viên nào làm “phiên dịch” ở giữa.
Do đó, Boris gọi API là “Giao diện dành cho Nhà phát triển Con người” (Human Developer Interface), còn MCP là “Giao thức Giao diện Mô hình” (Model Interface Protocol). Một cái dành cho con người, một cái dành cho mô hình.
Điều này rất giống với giai đoạn trước. Thời kỳ điện thoại di động, tiêu chuẩn là mọi dịch vụ đều phải được “API hóa”. Còn trong kỷ nguyên AI, tiêu chuẩn sẽ là mọi dịch vụ đều phải được “MCP hóa”.
07 Computer Use vẫn giữ vai trò quan trọng
Hiện nay, nhiều người khi bàn về Computer Use cảm thấy hướng đi này có thể không khả thi.
Lý do cũng rất hợp lý: tiêu tốn quá nhiều token, tốc độ chậm và chưa ổn định. Nhìn chung, nó giống một bản demo khoe kỹ thuật hơn là một giải pháp thực sự sẵn sàng áp dụng.
Nhưng Boris lại nhìn nhận vấn đề ở một tầng hoàn toàn khác.
Điều ông thực sự quan tâm là Computer Use giải quyết được痛点 lớn nhất trong việc triển khai AI: trên thực tế, tồn tại rất nhiều hệ thống vừa không có API, vừa không có MCP.
Đặc biệt là trong thế giới doanh nghiệp.
Ai từng làm việc thực tế trong doanh nghiệp đều biết, rất nhiều hệ thống cốt lõi trong công ty đều rất cũ: ERP, hệ thống văn phòng (OA), hệ thống tài chính, hệ thống phê duyệt nội bộ, nền tảng hậu cần chuỗi cung ứng và vô số hệ thống tùy chỉnh khác. Nhiều hệ thống không mở cổng kết nối, không có tài liệu hướng dẫn, cũng không hỗ trợ tự động hóa. Chúng cứ tồn tại đó, và hàng ngày đều được vô số nhân viên thao tác thủ công.
Vậy tại sao không trực tiếp xây dựng API cho những hệ thống này?
Vì việc đó không khả thi. Nhà cung cấp hệ thống có thể đã không còn tồn tại. Phòng IT không có động lực cũng như ngân sách để tái cấu trúc. Phòng nghiệp vụ càng không thể dừng mọi hoạt động để chờ nửa năm hay một năm. Những hệ thống này sẽ chẳng bao giờ đợi được một API hoàn hảo đến “cứu rỗi” chúng.
Trong ngắn hạn, các mô hình lớn nên tiếp tục cải thiện khả năng Computer Use của mình.
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













