- "Vibe coding" là trạng thái lập trình mà người dùng đắm chìm hoàn toàn, quên đi sự tồn tại của mã, giúp cả những người không chuyên kỹ thuật cũng có thể xây dựng ứng dụng toàn diện.
- Trước sự tăng trưởng theo cấp số nhân của khả năng AI, việc "vibe code" một cách có trách nhiệm trong môi trường sản phẩm là cần thiết để tận dụng AI mà không bị quá tải bởi việc xem xét mã thủ công.
- Để làm điều này, cần đóng vai trò "quản lý sản phẩm" cho AI, tập trung vào việc tạo mã ở "nút lá" của codebase, và thiết kế hệ thống với các cơ chế kiểm chứng mạnh mẽ để đảm bảo chất lượng mà không cần đọc sâu mã nguồn.
Vibe coding in prod | Code w/ Claude
- Đóng vai trò "Quản lý sản phẩm" cho AI: Cung cấp cho tác nhân AI (như Claude) ngữ cảnh, yêu cầu, thông số kỹ thuật và ràng buộc chi tiết như bạn sẽ làm với một thành viên mới trong nhóm, thay vì chỉ đưa ra những câu lệnh ngắn gọn.
- Đầu tư thời gian vào việc xây dựng kế hoạch chi tiết với AI: Dành 15-20 phút tương tác qua lại với AI để cùng nhau xây dựng một kế hoạch tổng thể, bao gồm các tệp sẽ thay đổi và mẫu mã cần tuân theo, trước khi AI bắt đầu thực thi.
- Tập trung vibe coding vào các "nút lá" (leaf nodes): Sử dụng AI để tạo mã cho các phần của codebase không có gì phụ thuộc vào chúng và ít khả năng thay đổi, giảm thiểu rủi ro nợ kỹ thuật ở các khu vực quan trọng.
- Bảo vệ kiến trúc cốt lõi (core architecture) bằng đánh giá thủ công: Đối với các phần quan trọng, nền tảng của hệ thống, hãy duy trì sự hiểu biết sâu sắc và tiến hành đánh giá thủ công kỹ lưỡng để đảm bảo khả năng mở rộng, dễ hiểu và linh hoạt.
- Thiết kế hệ thống với khả năng kiểm chứng rõ ràng: Tạo ra các bài kiểm thử chấp nhận, kiểm thử tải (stress tests) và thiết kế đầu vào/đầu ra của hệ thống AI sao cho dễ dàng kiểm chứng bởi con người, cho phép xác nhận tính đúng đắn mà không cần đọc mã nguồn bên dưới.
- Chấp nhận quản lý thực thi mà không cần hiểu sâu: Học cách đánh giá chất lượng và sự đúng đắn của công việc AI thông qua kết quả, hành vi và các điểm kiểm tra xác minh, tương tự như cách các nhà quản lý đánh giá công việc của chuyên gia mà không cần chuyên môn sâu về triển khai.
- Phát triển khả năng đặt câu hỏi đúng đắn: Khả năng cung cấp hướng dẫn và đặt các câu hỏi chiến lược cho AI là chìa khóa để vibe coding thành công; điều này vẫn đòi hỏi một mức độ hiểu biết kỹ thuật nhất định.
vibe coding— lập trình theo cảm hứng/dựa trên cảm tínhAI agent— tác nhân AIproduction environment (prod)— môi trường sản phẩm/môi trường productionfeedback loop— vòng lặp phản hồitech debt— nợ kỹ thuậtleaf nodes— nút lá (trong cấu trúc mã)core architecture— kiến trúc cốt lõiproduct manager (PM)— quản lý sản phẩmverifiability— khả năng kiểm chứngstress tests— kiểm thử tải
Giới thiệu về Vibe Coding và Tác nhân AI
Chào mừng mọi người. Tôi ở đây để nói về chủ đề yêu thích của mọi người: vibe coding, và một cách hơi gây tranh cãi, làm thế nào để vibe code một cách có trách nhiệm trong môi trường production. Vậy hãy cùng tìm hiểu vibe coding là gì.
Trước hết, tôi là Eric. Tôi là một nhà nghiên cứu tại Anthropic, tập trung vào các Tác nhân AI lập trình. Tôi là tác giả, cùng với Barry Zayn, của tài liệu "Building Effective Agents", nơi chúng tôi đã phác thảo những kiến thức khoa học và phương pháp hay nhất để tạo ra các Tác nhân AI, bất kể ứng dụng nào. Đây là một chủ đề rất gần gũi với tôi. Năm ngoái, tôi đã bị gãy tay khi đang đạp xe đi làm và phải bó bột trong hai tháng, và Claude đã viết tất cả mã của tôi trong hai tháng đó. Vì vậy, việc tìm ra cách thực hiện điều này một cách hiệu quả thực sự quan trọng đối với tôi, và may mắn thay, tôi đã có thể tìm ra cách đó và giúp đưa nó vào nhiều sản phẩm khác của Anthropic cũng như các mô hình AI của chúng tôi thông qua nghiên cứu của mình.
Định nghĩa Vibe Coding
Hãy bắt đầu bằng việc tìm hiểu vibe coding là gì. Rất nhiều người thường nhầm lẫn vibe coding với việc sử dụng Trí tuệ nhân tạo (AI) một cách rộng rãi để tạo mã. Nhưng tôi nghĩ điều này không hoàn toàn đúng. Nhiều người đang sử dụng Cursor hoặc Copilot. Đó là rất nhiều Trí tuệ nhân tạo, và phần lớn mã đến từ AI chứ không phải do họ tự viết. Nhưng tôi nghĩ rằng khi bạn vẫn đang trong một vòng lặp phản hồi chặt chẽ với một mô hình AI như vậy, đó không phải là vibe coding thực sự. Khi tôi nói vibe coding, tôi nghĩ chúng ta cần đến định nghĩa của Andrej Karpathy, theo đó vibe coding là khi bạn hoàn toàn "đắm chìm vào cảm hứng, đón nhận sự tăng trưởng theo cấp số nhân, và quên rằng mã thậm chí còn tồn tại." Tôi nghĩ phần quan trọng ở đây là "quên rằng mã thậm chí còn tồn tại."
Lý do điều này quan trọng là vì vibe coding là lúc những người không làm kỹ thuật trong ngành thực sự bắt đầu hứng thú với việc tạo mã. Copilot và Cursor rất tuyệt, nhưng chỉ dành cho các kỹ sư. Nhưng một người không biết lập trình, đột nhiên với vibe coding, họ có thể tự mình viết mã cho toàn bộ một ứng dụng. Và đây là một điều thực sự thú vị và là một bước đột phá lớn đối với nhiều người.
Tất nhiên, có rất nhiều nhược điểm. Bạn có những người lần đầu tiên lập trình mà không thực sự biết mình đang làm gì. Và bạn sẽ nói: "Này, những điều ngẫu nhiên đang xảy ra, mức sử dụng API của tôi đã đạt tối đa." Mọi người đang bỏ qua đăng ký, tạo ra những thứ ngẫu nhiên trên cơ sở dữ liệu (DB). Vì vậy, đây là một mặt trái của vibe coding đã bắt đầu xảy ra. Và những mặt tích cực của vibe coding mà bạn thấy đều là những thứ có rủi ro thấp. Đó là những người xây dựng trò chơi điện tử, xây dựng các dự án phụ vui vẻ, những thứ mà có lỗi cũng không sao.
Tại sao Vibe Coding lại Quan trọng?
Vậy tại sao chúng ta lại quan tâm đến vibe coding? Nếu nó có vẻ là thứ mà rủi ro rất cao nếu bạn làm cho một sản phẩm thực tế, và những trường hợp thành công nhất của nó là những ví dụ "đồ chơi" hoặc những điều vui vẻ có rủi ro rất thấp. Và câu trả lời của tôi cho câu hỏi tại sao chúng ta nên quan tâm đến vibe coding là vì sự tăng trưởng theo cấp số nhân. Độ dài của tác vụ mà Trí tuệ nhân tạo có thể thực hiện đang tăng gấp đôi sau mỗi bảy tháng. Hiện tại, chúng ta đang ở mức khoảng một giờ. Và điều đó không sao cả. Bạn không cần vibe code. Bạn có thể để Cursor làm việc cho bạn. Bạn có thể để Claude Code viết một tính năng mất một giờ. Và bạn có thể xem xét tất cả mã đó. Và bạn vẫn có thể tham gia sâu sắc khi AI đang viết rất nhiều mã của bạn. Nhưng điều gì sẽ xảy ra vào năm tới? Điều gì sẽ xảy ra vào năm sau đó? Khi AI đủ mạnh để có thể tạo ra công việc của cả một ngày cho bạn cùng một lúc, hoặc công việc của cả một tuần, không có cách nào chúng ta có thể theo kịp nếu chúng ta vẫn cần phải di chuyển theo sát từng bước. Điều đó có nghĩa là nếu chúng ta muốn tận dụng sự tăng trưởng theo cấp số nhân này, chúng ta sẽ phải tìm cách đón nhận nó một cách có trách nhiệm và tìm cách tận dụng tác vụ này.
Tôi nghĩ phép ẩn dụ yêu thích của tôi ở đây giống như các trình biên dịch. Tôi chắc chắn rằng trong những ngày đầu của trình biên dịch, nhiều nhà phát triển thực sự không tin tưởng chúng. Họ có thể sử dụng trình biên dịch, nhưng họ vẫn đọc hợp ngữ mà nó xuất ra để đảm bảo nó trông giống như cách họ sẽ viết hợp ngữ. Nhưng điều đó không mở rộng được. Đến một lúc nào đó, bạn bắt đầu cần làm việc trên các hệ thống AI đủ lớn mà bạn chỉ cần tin tưởng vào hệ thống AI đó. Tuy nhiên, câu hỏi là làm thế nào để làm điều đó một cách có trách nhiệm? Và tôi nghĩ thách thức của tôi đối với toàn bộ ngành công nghiệp phần mềm trong vài năm tới là làm thế nào chúng ta sẽ vibe code trong môi trường production và thực hiện điều đó một cách an toàn? Và câu trả lời của tôi là chúng ta sẽ quên rằng mã tồn tại, nhưng không quên rằng sản phẩm tồn tại.
Quản lý Thực thi mà Không Cần Hiểu Sâu
Trở lại với phép ẩn dụ về trình biên dịch, tất cả chúng ta vẫn biết rằng có hợp ngữ nằm bên dưới, nhưng hy vọng hầu hết chúng ta không cần thực sự nghĩ về hợp ngữ đó là gì. Nhưng chúng ta vẫn có thể xây dựng phần mềm tốt mà không cần hiểu hợp ngữ đó. Và tôi nghĩ chúng ta sẽ đạt đến cấp độ tương tự với phần mềm. Và một điều tôi thực sự muốn nhấn mạnh là đây không phải là một vấn đề mới. Làm thế nào một Giám đốc Công nghệ (CTO) quản lý một chuyên gia trong một lĩnh vực mà bản thân Giám đốc Công nghệ (CTO) không phải là chuyên gia? Làm thế nào một Quản lý sản phẩm (PM) xem xét một tính năng kỹ thuật khi bản thân họ không thể đọc tất cả mã đã tạo ra nó? Hoặc làm thế nào một Giám đốc điều hành (CEO) kiểm tra công việc của kế toán khi bản thân họ không phải là chuyên gia về kế toán tài chính? Và đây là tất cả các vấn đề đã tồn tại hàng trăm hoặc hàng nghìn năm. Và chúng ta có giải pháp cho chúng.
Một Giám đốc Công nghệ (CTO) vẫn có thể viết các bài kiểm tra chấp nhận cho một chuyên gia làm việc cho họ. Ngay cả khi họ không hiểu việc triển khai bên dưới, họ có thể thấy rằng các bài kiểm tra chấp nhận này đạt và công việc có chất lượng cao. Một quản lý sản phẩm có thể sử dụng sản phẩm mà nhóm kỹ thuật của họ đã xây dựng và đảm bảo rằng nó hoạt động như mong đợi, ngay cả khi họ không viết mã. Và một Giám đốc điều hành (CEO) có thể kiểm tra nhanh các dữ kiện chính mà họ hiểu và các lát cắt dữ liệu để họ có thể xây dựng niềm tin vào mô hình AI tài chính tổng thể, mặc dù bản thân họ có thể không phải là chuyên gia về cách toàn bộ hệ thống vận hành.
Và vì vậy, suy nghĩ về những ví dụ này, việc quản lý các triển khai mà bản thân bạn không hiểu thực sự là một vấn đề có từ nền văn minh. Và mọi nhà quản lý trên thế giới thực sự đã và đang giải quyết vấn đề này. Chỉ có chúng ta là các kỹ sư phần mềm không quen với điều này. Chúng ta quen với việc là những chuyên viên độc lập, nơi chúng ta hiểu toàn bộ chiều sâu của ngăn xếp công nghệ (stack). Nhưng đó là điều mà để trở nên năng suất nhất, chúng ta sẽ cần phải từ bỏ theo cách mà mọi nhà quản lý để trở nên năng suất nhất sẽ cần phải từ bỏ một số chi tiết. Và giống như chúng ta là các kỹ sư phần mềm, chúng ta từ bỏ một số chi tiết về việc hiểu bản thân hợp ngữ đang xảy ra bên dưới. Và cách bạn làm điều này trong khi vẫn an toàn và có trách nhiệm là tìm một lớp trừu tượng mà bạn có thể xác minh, ngay cả khi không biết việc triển khai bên dưới nó.
Vấn đề Nợ Kỹ thuật và Chiến lược Mã hóa
Tuy nhiên, hôm nay tôi có một lưu ý về nợ kỹ thuật (tech debt). Hiện tại không có cách tốt để đo lường hoặc xác thực nợ kỹ thuật (tech debt) mà không tự đọc mã. Hầu hết các hệ thống AI khác trong cuộc sống, như ví dụ về kế toán, PM, bạn có những cách để xác minh những điều bạn quan tâm mà không cần biết việc triển khai. Nợ kỹ thuật (Tech debt), tôi nghĩ, là một trong những điều hiếm hoi mà thực sự không có cách tốt để xác thực ngoài việc là một chuyên gia về chính việc triển khai. Vì vậy, đó là điều mà hiện tại chúng ta không có cách tốt để xác thực.
Tuy nhiên, điều đó không có nghĩa là chúng ta không thể làm điều này. Nó chỉ có nghĩa là chúng ta cần phải rất thông minh và có mục tiêu, nơi chúng ta có thể tận dụng mã. Câu trả lời của tôi cho điều này là tập trung vào các nút lá (leaf nodes) trong cơ sở mã của chúng ta. Và ý tôi là các phần của mã và các phần của hệ thống AI của chúng ta mà không có gì phụ thuộc vào chúng. Chúng là một tính năng cuối cùng. Chúng là những chi tiết nhỏ cuối cùng hơn là những thứ là nhánh chính hoặc nhánh phụ bên dưới chúng, như ở đây trong màu trắng. Ở đây, các chấm màu cam là tất cả các nút lá (leaf nodes) này, nơi mà thực sự, nếu bạn có một hệ thống AI như thế này, thì cũng không sao nếu có nợ kỹ thuật (tech debt) trong các nút lá (leaf nodes) này bởi vì không có gì khác phụ thuộc vào chúng. Chúng không có khả năng thay đổi. Chúng không có khả năng có thêm những thứ được xây dựng dựa trên chúng. Ngược lại với những thứ màu trắng ở đây, các nhánh chính và nhánh phụ cơ bản của hệ thống AI của bạn, đó là kiến trúc cốt lõi mà chúng ta là các kỹ sư vẫn cần phải hiểu sâu sắc vì đó là những gì sẽ thay đổi. Đó là những gì những thứ khác sẽ được xây dựng dựa trên. Và điều rất quan trọng là chúng ta phải bảo vệ những điều đó và đảm bảo rằng chúng vẫn có khả năng mở rộng, dễ hiểu và linh hoạt.
Bây giờ, một điều tôi sẽ nói ở đây là các mô hình AI đang ngày càng tốt hơn. Và vì vậy, chúng ta có thể đến một thế giới mà điều này ngày càng đi sâu hơn, nơi chúng ta tin tưởng các mô hình AI ngày càng nhiều hơn để viết mã có khả năng mở rộng và không có nợ kỹ thuật (tech debt). Việc sử dụng các mô hình AI Claude 4 trong một hoặc hai tuần qua tại Anthropic là một điều thực sự thú vị. Và tôi đã tin tưởng chúng nhiều hơn so với Claude 3.7. Vì vậy, tôi nghĩ rằng điều này sẽ thay đổi và ngày càng nhiều stack chúng ta sẽ có thể làm việc theo cách này.
Cách Vibe Coding Hiệu quả: Tư duy Quản lý Sản phẩm
Vậy hãy nói về cách thành công trong vibe coding. Và lời khuyên chính của tôi ở đây là đừng hỏi Claude có thể làm gì cho bạn, mà hãy hỏi bạn có thể làm gì cho Claude. Tôi nghĩ khi bạn vibe coding, bạn về cơ bản đang đóng vai trò là một quản lý sản phẩm cho Claude. Vì vậy, bạn cần suy nghĩ như một quản lý sản phẩm. Một nhân viên mới trong nhóm của bạn sẽ cần hướng dẫn hoặc ngữ cảnh nào để thành công trong tác vụ này? Tôi nghĩ nhiều khi chúng ta quá quen với việc thực hiện một cuộc trò chuyện qua lại rất nhanh với AI kiểu "hãy tạo tính năng này, sửa lỗi này". Nhưng một con người nếu đó là ngày đầu tiên đi làm và bạn chỉ nói "này, hãy triển khai tính năng này", không đời nào bạn mong đợi họ thực sự thành công. Bạn cần cho họ một chuyến tham quan cơ sở mã. Bạn cần cho họ biết các yêu cầu, thông số kỹ thuật và ràng buộc thực tế mà họ cần hiểu là gì. Và tôi nghĩ rằng khi chúng ta vibe code, đó trở thành trách nhiệm của chúng ta để cung cấp thông tin đó cho Claude để đảm bảo rằng nó có tất cả ngữ cảnh tương tự và được thiết lập để thành công.
Khi tôi làm việc với các tính năng cùng Claude, tôi thường dành 15 hoặc 20 phút để thu thập hướng dẫn vào một câu lệnh duy nhất và sau đó để Claude thực thi. Và 15 hoặc 20 phút đó không chỉ là tôi tự viết câu lệnh bằng tay. Đây thường là một cuộc trò chuyện riêng biệt, nơi tôi tương tác qua lại với Claude. Nó đang khám phá cơ sở mã, tìm kiếm các tập tin. Chúng tôi cùng nhau xây dựng một kế hoạch nắm bắt được bản chất của những gì tôi muốn, những tập tin nào sẽ được thay đổi, những mẫu nào trong cơ sở mã nó nên tuân theo. Và một khi tôi có sản phẩm đó, tất cả thông tin đó, thì tôi sẽ cung cấp cho Claude, có thể trong một ngữ cảnh mới hoặc nói, "này, hãy thực hiện kế hoạch này." Và tôi thường thấy rằng một khi tôi đã nỗ lực thu thập tất cả thông tin đó, Claude có tỷ lệ thành công rất, rất cao trong việc hoàn thành một cái gì đó một cách rất tốt.
Và điều khác tôi sẽ nói ở đây là bạn cần phải có khả năng đặt đúng câu hỏi. Và mặc dù tiêu đề của bài nói chuyện của tôi, tôi không nghĩ rằng vibe coding trong Claude dành cho tất cả mọi người. Tôi không nghĩ rằng những người hoàn toàn không có kỹ năng kỹ thuật nên đi và cố gắng xây dựng một doanh nghiệp hoàn toàn từ đầu. Tôi nghĩ điều đó nguy hiểm vì họ không thể đặt đúng câu hỏi. Họ không thể là một quản lý sản phẩm hiệu quả cho Claude khi họ làm điều đó. Và vì vậy, họ sẽ không thành công.
Chúng tôi gần đây đã hợp nhất một thay đổi 22.000 dòng mã vào cơ sở mã học tăng cường (reinforcement learning) trong môi trường production của chúng tôi, phần lớn được viết bởi Claude. Vậy làm thế nào chúng tôi đã làm điều này một cách có trách nhiệm? Và vâng, đây là ảnh chụp màn hình thực tế của diff từ GitHub cho yêu cầu hợp nhất mã (PR). Điều đầu tiên là chúng tôi đã hỏi chúng tôi có thể làm gì cho Claude. Đây không chỉ là một câu lệnh duy nhất mà sau đó chúng tôi đã hợp nhất. Vẫn có những ngày làm việc của con người đã được đầu tư vào việc đưa ra các yêu cầu, hướng dẫn Claude và tìm ra hệ thống AI nên là gì.
Quản lý Dự án và Hiệu quả Phát triển
Chúng tôi thực sự đã đảm nhận vai trò là product manager của Claude trong tính năng này. Sự thay đổi chủ yếu tập trung vào các leaf nodes trong cơ sở mã của chúng tôi, nơi chúng tôi biết rằng việc có một chút nợ kỹ thuật là chấp nhận được, bởi vì chúng tôi không mong đợi những phần này của cơ sở mã cần thay đổi trong tương lai gần. Đối với những phần mà chúng tôi cho là quan trọng và cần có khả năng mở rộng, chúng tôi đã tiến hành đánh giá thủ công rất kỹ lưỡng. Cuối cùng, chúng tôi đã thiết kế cẩn thận các kiểm thử tải (stress tests) để đảm bảo độ ổn định. Chúng tôi đã thiết kế toàn bộ hệ thống AI sao cho nó có đầu vào và đầu ra có thể kiểm chứng dễ dàng bởi con người. Hai yếu tố cuối cùng này đã cho phép chúng tôi tạo ra các điểm kiểm tra có thể xác minh, nhờ đó chúng tôi có thể đảm bảo rằng thay đổi này là chính xác ngay cả khi không cần hiểu hoặc đọc toàn bộ triển khai bên dưới. Mối quan tâm lớn nhất của chúng tôi là độ ổn định, và chúng tôi đã có thể đo lường điều đó ngay cả khi không đọc mã bằng cách tạo ra các kiểm thử tải này và chạy chúng trong thời gian dài. Chúng tôi cũng có thể xác minh tính đúng đắn dựa trên đầu vào và đầu ra của hệ thống AI mà chúng tôi đã thiết kế. Về cơ bản, chúng tôi đã thiết kế hệ thống AI này để dễ hiểu và dễ kiểm chứng ngay cả khi chúng tôi không đọc tất cả mã. Và cuối cùng, bằng cách kết hợp những điều đó, chúng tôi đã tự tin về thay đổi này giống như bất kỳ thay đổi nào khác mà chúng tôi đã thực hiện đối với cơ sở mã của mình, nhưng lại hoàn thành nó chỉ trong một phần rất nhỏ thời gian và công sức so với việc viết và đánh giá từng dòng mã đó theo cách thủ công. Tôi nghĩ một trong những điều thực sự thú vị về điều này không chỉ là nó đã tiết kiệm cho chúng tôi một tuần thời gian của con người. Mà việc biết rằng chúng tôi có thể làm điều này đã khiến chúng tôi suy nghĩ khác về kỹ thuật của mình, về những gì chúng tôi có thể làm. Và giờ đây, khi một điều gì đó chỉ tốn một ngày thay vì hai tuần, bạn nhận ra rằng bạn có thể tạo ra các tính năng lớn hơn và những thay đổi lớn hơn nhiều, giống như chi phí biên của phần mềm thấp hơn, và điều đó cho phép bạn tiêu thụ và xây dựng nhiều phần mềm hơn. Vì vậy, tôi nghĩ đó là điều thực sự thú vị về điều này, không chỉ là tiết kiệm thời gian, mà giờ đây cảm giác như: "Ồ, những thứ sẽ mất hai tuần, hãy cứ làm đi. Nó chỉ mất một ngày thôi." Và đó là điều thú vị ở đây.
Lời khuyên để vibe coding có trách nhiệm trong môi trường sản phẩm
Để lại cho các bạn những suy nghĩ cuối cùng về cách vibe code có trách nhiệm trong môi trường sản phẩm (prod): Hãy là product manager của Claude. Đừng hỏi Claude có thể làm gì cho bạn, mà hãy hỏi bạn có thể làm gì cho Claude. Tập trung việc vibe coding của bạn vào các leaf nodes, không phải kiến trúc cốt lõi và hệ thống nền tảng, để nếu có nợ kỹ thuật thì nó sẽ được kiểm soát và không nằm ở các khu vực quan trọng. Hãy suy nghĩ về khả năng kiểm chứng và làm thế nào bạn có thể biết liệu thay đổi này có đúng hay không mà không cần phải tự mình đọc mã. Cuối cùng, hãy nhớ về cấp số nhân. Hôm nay, việc bạn không vibe code có thể không sao, nhưng trong một hoặc hai năm nữa, đó sẽ là một bất lợi rất lớn. Nếu bạn tự mình yêu cầu đọc hoặc viết từng dòng mã, bạn sẽ không thể tận dụng làn sóng mô hình AI mới nhất có khả năng thực hiện những tác vụ rất lớn cho bạn. Và bạn sẽ trở thành nút thắt cổ chai nếu chúng ta không giỏi điều này. Vì vậy, tóm lại, đó là việc vibe coding có trách nhiệm trong môi trường sản phẩm. Và tôi nghĩ đây sẽ trở thành một trong những thách thức lớn nhất đối với ngành kỹ thuật phần mềm trong vài năm tới. Cảm ơn. Và tôi có rất nhiều thời gian cho câu hỏi.
Học hỏi và cải thiện với Tác nhân AI
Trước đây, chúng ta đã dành rất nhiều thời gian để giải quyết các vấn đề cú pháp (syntax problems) hoặc thư viện (libraries) hoặc kết nối giữa các thành phần của mã. Và đó là cách chúng ta học vibe code. Nhưng bây giờ chúng ta học như thế nào? Làm thế nào để chúng ta trở nên giỏi hơn trong vibe code? Làm thế nào để chúng ta hiểu biết hơn để trở thành product manager giỏi hơn của Tác nhân AI? Vâng, tôi nghĩ đây là một câu hỏi thực sự thú vị. Và tôi nghĩ có những lý do để rất lo lắng về điều này, và cũng có những lý do để rất lạc quan về điều này. Tôi nghĩ lý do để lo lắng, như bạn đã đề cập, là chúng ta sẽ không phải trải qua cuộc đấu tranh và vất vả đó. Tôi nghĩ điều đó thực ra là ổn. Tôi đã gặp một số giáo sư của tôi ở trường đại học, những người sẽ nói: "Ôi trời, các lập trình viên ngày nay không giỏi bằng vì họ chưa bao giờ phải tự viết mã assembly. Họ không thực sự cảm nhận được nỗi đau khi phải làm cho thứ gì đó chạy thực sự nhanh." Tôi nghĩ khía cạnh tích cực của điều này là tôi thấy mình có thể tìm hiểu mọi thứ nhanh hơn rất nhiều bằng cách sử dụng các công cụ AI này. Rất nhiều lần khi tôi lập mã với Claude, tôi sẽ đánh giá mã và nói: "Này, Claude, tôi chưa bao giờ thấy thư viện này trước đây. Hãy nói cho tôi biết về nó. Tại sao bạn lại chọn nó thay vì một cái khác?" Và việc có một lập trình viên cặp đôi luôn ở đó, một lần nữa, tôi nghĩ điều sẽ thay đổi là những người lười biếng sẽ không học. Họ sẽ chỉ trượt qua. Nhưng nếu bạn dành thời gian và bạn muốn học, có tất cả những tài nguyên tuyệt vời này. Và Claude sẽ giúp bạn hiểu những gì nó đã vibe code cho bạn. Điều khác tôi muốn nói là để học một số điều cấp cao hơn về những gì làm cho một dự án thành công, tính năng nào giúp bạn đạt được sự phù hợp giữa sản phẩm và thị trường (product market fit) so với những tính năng thất bại, chúng ta sẽ có thể thử nghiệm nhiều hơn rất nhiều. Tôi cảm thấy đặc biệt là các kỹ sư hệ thống hoặc kiến trúc sư, thường phải mất hai năm để thực hiện một thay đổi lớn trong cơ sở mã và thực sự hiểu liệu đó có phải là một quyết định kiến trúc tốt hay không. Và nếu chúng ta có thể rút ngắn thời gian đó xuống còn sáu tháng, tôi nghĩ các kỹ sư đang đầu tư vào thời gian của chính họ và cố gắng học hỏi sẽ có thể học được nhiều bài học gấp bốn lần trong cùng một khoảng thời gian theo lịch, miễn là họ nỗ lực cố gắng.
Cân bằng thông tin trong quy trình tiền kế hoạch
Về quy trình tiền kế hoạch của bạn, sự cân bằng giữa việc cung cấp quá nhiều và quá ít thông tin là như thế nào? Bạn có cung cấp toàn bộ tài liệu yêu cầu sản phẩm (product requirement document) không? Có một mẫu chuẩn hóa nào mà bạn tập hợp trước khi thực sự bắt đầu vibe coding không? Vâng, tôi nghĩ điều đó phụ thuộc rất nhiều vào những gì bạn quan tâm. Tôi sẽ nói rằng nếu đối với những việc mà tôi không thực sự quan tâm đến cách nó thực hiện, tôi sẽ không nói gì về chi tiết triển khai. Tôi sẽ chỉ nói đây là yêu cầu của tôi, đây là những gì tôi muốn ở cuối cùng. Có những lúc khác khi tôi hiểu rõ cơ sở mã và tôi sẽ đi sâu hơn nhiều, ví dụ như: "Này, đây là những lớp bạn nên sử dụng để triển khai logic này. Hãy xem ví dụ này về một tính năng tương tự." Tôi nghĩ tất cả đều phụ thuộc vào những gì bạn quan tâm cuối cùng. Tuy nhiên, tôi cũng muốn nói rằng các mô hình AI của chúng tôi hoạt động tốt nhất khi bạn không ràng buộc quá mức chúng. Vì vậy, tôi sẽ không dành quá nhiều nỗ lực để tạo ra một định dạng nghiêm ngặt hoặc bất cứ điều gì. Tôi sẽ chỉ nghĩ về nó như một kỹ sư cấp dưới, bạn sẽ cung cấp cho họ những gì để họ thành công.
Bảo mật trong vibe coding
Xin lỗi về những gì bạn đang nói. Bạn đã cân bằng hiệu quả và an ninh mạng như thế nào? Vài tháng trước có những báo cáo về 10 ứng dụng được vibe code hàng đầu rất dễ bị tấn công và rất nhiều thông tin quan trọng đã bị rò rỉ. Chà, không phải rò rỉ mà là được chứng minh là đã bị rò rỉ. Và người làm điều đó thậm chí không phải là một tin tặc chuyên nghiệp. Vậy thì, làm thế nào bạn cân bằng việc có thể giữ mọi thứ an toàn ngay cả ở cấp độ leaf node và đồng thời hiệu quả, bởi vì một thứ gì đó có thể hiệu quả nhưng không an toàn? Vâng, đó là một câu hỏi tuyệt vời. Và tôi nghĩ tất cả đều quy về điểm đầu tiên này, đó là hãy là product manager của Claude và hiểu đủ về ngữ cảnh để về cơ bản biết cái gì là nguy hiểm, cái gì an toàn và nơi nào bạn nên cẩn thận. Và tôi nghĩ, vâng, những điều thu hút nhiều sự chú ý về vibe coding là những người không có kinh nghiệm code đang làm những điều này. Và điều đó không sao cả. Nó tuyệt vời cho trò chơi, tuyệt vời cho sự sáng tạo và cho phép mọi người tạo ra. Nhưng tôi nghĩ đối với hệ thống sản xuất (production systems), bạn cần biết đủ về những câu hỏi cần hỏi để hướng dẫn Claude đi đúng hướng. Và đối với trường hợp nội bộ của chúng tôi trong ví dụ này, đó là một thứ hoàn toàn offline. Và vì vậy, chúng tôi biết rằng không có bất kỳ, chúng tôi rất, rất tự tin rằng không có vấn đề bảo mật nào có thể xảy ra với nó. Trong trường hợp của chúng tôi, nó được chạy trong một cái gì đó hoàn toàn offline. Vì vậy, đây là về những người bạn đề cập là "không có kinh nghiệm". Và có lẽ tôi không nên nói như vậy. Không có kinh nghiệm vibe coding trong môi trường sản phẩm cho một hệ thống quan trọng. Tôi sẽ nói vậy.
Tương lai của Phát triển Phần mềm và AI
Nhưng nếu chúng ta nhìn vào các con số, phải không, chưa đến 0,5% dân số thế giới là các nhà phát triển phần mềm. Và phần mềm là một cách tuyệt vời để mở rộng các ý tưởng. Vậy bạn nghĩ các sản phẩm cần thay đổi như thế nào? Để giúp mọi người dễ dàng vibe code và xây dựng phần mềm hơn, đồng thời tránh một số vấn đề mà chúng ta gặp phải khi mọi người rò rỉ khóa API (API keys) và những thứ tương tự? Đó thực sự là một câu hỏi tuyệt vời. Và tôi sẽ rất vui khi thấy nhiều sản phẩm và khuôn khổ (frameworks) xuất hiện mà có thể chứng minh được tính đúng đắn (provably correct). Và có lẽ ý tôi là tôi chắc chắn mọi người có thể xây dựng một số hệ thống backend mà các phần xác thực (auth parts) quan trọng, các phần thanh toán (payment parts) được xây dựng sẵn cho bạn. Và tất cả những gì bạn phải làm là điền vào lớp giao diện người dùng (UI layer). Và bạn có thể vibe code điều đó. Và về cơ bản, nó cung cấp cho bạn một số môi trường cách ly (sandboxes) điền vào chỗ trống tốt đẹp để đặt mã của bạn. Tôi cảm thấy có rất nhiều điều như vậy có thể tồn tại. Có lẽ ví dụ đơn giản nhất là sản phẩm/vật phẩm của Claude (Claude artifacts), nơi Claude có thể giúp bạn viết mã được lưu trữ ngay tại Claude AI để hiển thị. Và tất nhiên, điều đó an toàn vì nó rất hạn chế. Không có xác thực, không có thanh toán, nó chỉ giao diện người dùng (front end only). Nhưng có lẽ đó là một ý tưởng sản phẩm hay mà ai đó nên thực hiện ở đây là xây dựng một cách nào đó để tạo ra một hệ thống lưu trữ (hosting system) có thể chứng minh được tính đúng đắn, có thể có một backend mà bạn biết là an toàn, bất kể sự cố nào xảy ra ở giao diện người dùng. Nhưng tôi hy vọng mọi người sẽ xây dựng các công cụ tốt bổ sung cho vibe coding.
Phát triển Hướng Kiểm Thử (TDD) với Claude
Vậy đối với phát triển hướng kiểm thử (test driven development), bạn có lời khuyên nào không? Bởi vì tôi thường thấy Claude chỉ đưa ra toàn bộ triển khai và sau đó viết trường hợp kiểm thử (test cases). Đôi khi chúng thất bại. Và sau đó tôi chỉ muốn, bạn biết đấy, tôi đang cố gắng nhắc nhở nó viết trường hợp kiểm thử trước. Nhưng tôi cũng không muốn, bạn biết đấy, tự mình xác minh chúng vì tôi chưa thấy chúng trong triển khai. Vậy bạn có một cách tiếp cận lặp lại nào mà, bạn biết đấy, bạn đã bao giờ thử nó cho phát triển hướng kiểm thử chưa? Vâng, vâng. Tôi chắc chắn rằng phát triển hướng kiểm thử rất, rất hữu ích trong vibe coding. Miễn là bạn có thể hiểu các trường hợp kiểm thử là gì. Ngay cả khi không có điều đó, nó cũng giúp Claude tự tự nhất quán hơn một chút. Ngay cả khi bạn không tự mình xem các kiểm thử. Nhưng rất nhiều lần tôi muốn nói rằng Claude dễ dàng đi sâu vào việc viết các kiểm thử quá cụ thể về triển khai. Khi tôi cố gắng làm điều này, rất nhiều lần tôi sẽ khuyến khích, tôi sẽ đưa cho Claude các ví dụ như: "Này, chỉ cần viết ba kiểm thử đầu cuối (end to end tests) và, bạn biết đấy, thực hiện luồng xử lý thành công (happy path) và trường hợp lỗi (error case) này và trường hợp lỗi khác." Và tôi khá mang tính quy định về việc tôi muốn kiểm thử phải chung chung và kiểm thử đầu cuối. Tôi nghĩ điều đó giúp đảm bảo đó là thứ mà tôi có thể hiểu và đó là thứ mà Claude có thể làm mà không đi sâu vào chi tiết quá nhiều. Tôi cũng sẽ nói rằng rất nhiều lần khi tôi vibe coding, phần duy nhất của mã, hoặc ít nhất là phần đầu tiên của mã mà tôi đọc là các kiểm thử để đảm bảo rằng, bạn biết đấy, nếu tôi đồng ý với các kiểm thử và các kiểm thử vượt qua, thì tôi cảm thấy khá hài lòng về mã. Điều đó hoạt động tốt nhất nếu bạn có thể khuyến khích Claude viết các kiểm thử đầu cuối rất tối giản. Tôi nghĩ đó là điều tốt cho cuộc nói chuyện rất hấp dẫn này.
Khái niệm "Embrace Exponentials"
Tôi cũng đánh giá cao việc bạn đã làm được điều mà nhiều người chưa làm, đó là cố gắng diễn giải một trong những câu khá đặc biệt trong bài đăng gốc của Karpathy: "embrace exponentials". Vì vậy, tôi tự hỏi liệu tôi có thể hỏi kỹ hơn một chút và nói rằng, làm thế nào để tôi biết mình đã "ôm lấy exponentials" (embrace exponentials)? Chính xác thì việc tuân theo lời khuyên đó có nghĩa là gì, và có thể đào sâu hơn một chút về điều mà tôi nghĩ nó muốn truyền tải. Có lẽ nó dẫn đến việc các mô hình AI sẽ ngày càng tốt hơn. Bạn có nghĩ có lý khi nói rằng chỉ riêng việc các mô hình AI sẽ tốt hơn không có nghĩa là chúng sẽ tốt hơn ở mọi khía cạnh có thể tưởng tượng mà chúng ta hy vọng không? Vậy, làm thế nào để tôi "ôm lấy exponentials"?
Vâng, hoàn toàn chính xác. Tôi nghĩ bạn đã gần đúng với câu nói kiểu như, hãy cứ tiếp tục giả định rằng các mô hình AI sẽ tốt hơn. Nhưng nó còn hơn thế nữa. Ý tưởng, exponential, không chỉ là chúng sẽ tiếp tục tốt hơn, mà là chúng sẽ tốt hơn nhanh hơn chúng ta có thể tưởng tượng. Và điều đó giống như khi bạn, bạn có thể nhìn thấy hình dạng của các chấm ở đây. Nó không chỉ là việc nó đang dần tốt lên. Mà là nó đang tốt lên và sau đó thì nó trở nên vượt trội. Tôi nghĩ câu nói hài hước khác mà tôi nghe được từ đây, đây là trong bài nói chuyện của Dario và Mike Krieger: "Machines of Loving Grace không phải là khoa học viễn tưởng. Đó là một lộ trình sản phẩm." Mặc dù nghe có vẻ rất xa vời, nhưng khi bạn đang trên một đường cong exponential, mọi thứ sẽ trở nên điên rồ rất, rất nhanh và nhanh hơn bạn mong đợi. Và tôi nghĩ, nếu bạn nói chuyện với một người làm máy tính vào những năm 90, họ sẽ nói: "Tuyệt vời, chúng ta có vài kilobyte RAM. Chúng ta có thêm vài kilobyte RAM." Nhưng nếu bạn tua nhanh đến thời điểm hiện tại, chúng ta có terabyte. Và nó không chỉ là việc nó tốt gấp đôi. Mà là mọi thứ đã tốt hơn hàng triệu lần. Và đó là điều xảy ra với exponentials trong suốt 20 năm. Vì vậy, chúng ta không nên nghĩ về 20 năm. Bây giờ chúng ta nên nghĩ về điều gì sẽ xảy ra nếu những mô hình AI này thông minh và nhanh hơn hàng triệu lần so với hiện tại, điều đó thật điên rồ. Chúng ta thậm chí không thể nghĩ về ý nghĩa của điều đó. Cũng giống như cách mà một người làm máy tính vào những năm 90, tôi không nghĩ họ có thể nghĩ về điều gì sẽ xảy ra với xã hội nếu một chiếc máy tính nhanh hơn hàng triệu lần so với những gì họ đang làm việc. Nhưng đó là điều đã xảy ra. Và đó là ý nghĩa của exponential, là nó sẽ trở nên vượt trội? Vâng.
Quy trình làm việc với Claude Code và Quản lý Ngữ cảnh
Tôi có một vài, à tôi có một câu hỏi, nhưng nó gồm hai phần. Phần đầu tiên, khi nói đến coding, tôi có hai quy trình làm việc khác nhau. Một là khi tôi sử dụng thiết bị đầu cuối, và một là khi tôi sử dụng VS Code hoặc Cursor. Bạn sử dụng quy trình làm việc nào? Và nếu bạn sử dụng Claude Code trong thiết bị đầu cuối, bạn thu gọn ngữ cảnh (compact) thường xuyên như thế nào? Bởi vì tôi thấy rằng các hàm của tôi sẽ nhận một tên mới khi tôi viết mã theo cảm tính (vibe code) trong thời gian dài. Hoặc mọi thứ chỉ đơn giản là đi chệch hướng, và ngay cả khi tôi thu gọn ngữ cảnh, điều đó vẫn xảy ra. Nếu tôi tạo một tài liệu để hướng dẫn nó, tôi vẫn phải đưa nó trở lại đúng hướng. Vâng, một câu hỏi hay. Tôi làm cả hai. Tôi thường viết mã với Claude Code mở trong thiết bị đầu cuối của VS Code. Và tôi sẽ nói rằng Claude Code đang thực hiện hầu hết việc chỉnh sửa, và tôi đang xem xét mã khi tôi làm việc trong VS Code. Điều đó không phải là vibe coding thực sự theo nghĩa ở đây, hoặc có thể tôi chỉ đang xem xét các kiểm thử từ nó. Tôi thích thu gọn ngữ cảnh hoặc chỉ bắt đầu một cuộc trò chuyện mới. Đại loại là bất cứ khi nào tôi đưa Claude đến một điểm dừng tốt, nơi tôi cảm thấy như, với tư cách là một lập trình viên con người, khi nào thì tôi sẽ dừng lại và nghỉ giải lao và có thể đi ăn trưa rồi quay lại? Nếu tôi cảm thấy mình đang ở giai đoạn đó, đó là một thời điểm tốt để thu gọn ngữ cảnh. Vì vậy, có lẽ tôi sẽ bắt đầu bằng cách nhờ Claude tìm tất cả các tệp liên quan và lập một kế hoạch. Và sau đó tôi sẽ nói, được rồi, hãy viết tất cả những điều này vào một tài liệu và sau đó tôi sẽ thu gọn ngữ cảnh. Và điều đó loại bỏ 100.000 token mà chúng tôi đã sử dụng để tạo kế hoạch đó và tìm tất cả các tệp này, cô đọng nó lại thành vài nghìn token.
Tăng cường tốc độ và làm quen với Cơ sở mã mới
Này, một câu hỏi tiếp theo từ câu hỏi trước của anh ấy là, bạn đã sử dụng những công cụ nào khác cùng với Claude Code để tăng tốc độ một chút, ví dụ như chạy nhiều phiên bản Claude Code cùng lúc bằng cách sử dụng git worktrees và sau đó hợp nhất một vài thứ hoặc stack PR chẳng hạn. Đó có phải là điều bạn tự mình thực hiện hay bạn sẽ khuyên người khác làm theo không? Câu hỏi thứ hai là, làm thế nào để bạn tiếp cận một phần của cơ sở mã mà bạn không thực sự quen thuộc, một cách rất có cấu trúc và với một phương pháp kỹ thuật tốt, nhưng bạn muốn gửi một yêu cầu hợp nhất mã (PR) thật nhanh và bạn muốn làm điều đó một cách thực sự tốt chứ không phải vibe code nó? Vậy, những cách của bạn khi sử dụng Claude Code để giúp thực hiện cả hai điều này là gì?
Vâng. Tôi chắc chắn sử dụng cả Claude Code lẫn Cursor. Và tôi sẽ nói rằng thông thường tôi sẽ bắt đầu công việc với Claude Code và sau đó tôi sẽ dùng Cursor để khắc phục các vấn đề hoặc nếu tôi có những thay đổi rất cụ thể mà tôi biết chính xác thay đổi mà tôi muốn thực hiện cho tệp này, tôi sẽ tự mình làm điều đó với Cursor và nhắm vào chính xác các dòng mà tôi biết cần chỉnh sửa. Phần thứ hai của câu hỏi của bạn là, à vâng, làm thế nào để làm quen với một phần mới của cơ sở mã. Trước khi tôi bắt đầu cố gắng viết tính năng, tôi sử dụng Claude Code để giúp tôi khám phá cơ sở mã. Vì vậy, tôi có thể nói như, cho tôi biết phần off diễn ra ở đâu trong cơ sở mã này hoặc bạn biết đấy, điều gì đó xảy ra ở đâu trong cơ sở mã này. Hãy cho tôi biết các tính năng tương tự như thế này và hãy để nó cho tôi biết tên tệp, các lớp mà tôi nên xem xét. Và sau đó sử dụng điều đó để cố gắng xây dựng một hình dung trong đầu để đảm bảo rằng tôi có thể làm điều này và không vibe code, đảm bảo rằng tôi vẫn có thể nắm bắt tốt những gì đang diễn ra. Và sau đó tôi làm việc với tính năng đó cùng với Claude. Cảm ơn rất nhiều. Tôi sẽ ở đây và Can Miller có thể trả lời các câu hỏi khác.
TL;DR
- "Vibe coding" là trạng thái lập trình mà người dùng đắm chìm hoàn toàn, quên đi sự tồn tại của mã, giúp cả những người không chuyên kỹ thuật cũng có thể xây dựng ứng dụng toàn diện.
- Trước sự tăng trưởng theo cấp số nhân của khả năng AI, việc "vibe code" một cách có trách nhiệm trong môi trường sản phẩm là cần thiết để tận dụng AI mà không bị quá tải bởi việc xem xét mã thủ công.
- Để làm điều này, cần đóng vai trò "quản lý sản phẩm" cho AI, tập trung vào việc tạo mã ở "nút lá" của codebase, và thiết kế hệ thống với các cơ chế kiểm chứng mạnh mẽ để đảm bảo chất lượng mà không cần đọc sâu mã nguồn.
Điểm chính
- Đóng vai trò "Quản lý sản phẩm" cho AI: Cung cấp cho tác nhân AI (như Claude) ngữ cảnh, yêu cầu, thông số kỹ thuật và ràng buộc chi tiết như bạn sẽ làm với một thành viên mới trong nhóm, thay vì chỉ đưa ra những câu lệnh ngắn gọn.
- Đầu tư thời gian vào việc xây dựng kế hoạch chi tiết với AI: Dành 15-20 phút tương tác qua lại với AI để cùng nhau xây dựng một kế hoạch tổng thể, bao gồm các tệp sẽ thay đổi và mẫu mã cần tuân theo, trước khi AI bắt đầu thực thi.
- Tập trung vibe coding vào các "nút lá" (leaf nodes): Sử dụng AI để tạo mã cho các phần của codebase không có gì phụ thuộc vào chúng và ít khả năng thay đổi, giảm thiểu rủi ro nợ kỹ thuật ở các khu vực quan trọng.
- Bảo vệ kiến trúc cốt lõi (core architecture) bằng đánh giá thủ công: Đối với các phần quan trọng, nền tảng của hệ thống, hãy duy trì sự hiểu biết sâu sắc và tiến hành đánh giá thủ công kỹ lưỡng để đảm bảo khả năng mở rộng, dễ hiểu và linh hoạt.
- Thiết kế hệ thống với khả năng kiểm chứng rõ ràng: Tạo ra các bài kiểm thử chấp nhận, kiểm thử tải (stress tests) và thiết kế đầu vào/đầu ra của hệ thống AI sao cho dễ dàng kiểm chứng bởi con người, cho phép xác nhận tính đúng đắn mà không cần đọc mã nguồn bên dưới.
- Chấp nhận quản lý thực thi mà không cần hiểu sâu: Học cách đánh giá chất lượng và sự đúng đắn của công việc AI thông qua kết quả, hành vi và các điểm kiểm tra xác minh, tương tự như cách các nhà quản lý đánh giá công việc của chuyên gia mà không cần chuyên môn sâu về triển khai.
- Phát triển khả năng đặt câu hỏi đúng đắn: Khả năng cung cấp hướng dẫn và đặt các câu hỏi chiến lược cho AI là chìa khóa để vibe coding thành công; điều này vẫn đòi hỏi một mức độ hiểu biết kỹ thuật nhất định.
Từ vựng
vibe coding— lập trình theo cảm hứng/dựa trên cảm tínhAI agent— tác nhân AIproduction environment (prod)— môi trường sản phẩm/môi trường productionfeedback loop— vòng lặp phản hồitech debt— nợ kỹ thuậtleaf nodes— nút lá (trong cấu trúc mã)core architecture— kiến trúc cốt lõiproduct manager (PM)— quản lý sản phẩmverifiability— khả năng kiểm chứngstress tests— kiểm thử tải
Nội dung chi tiết
Giới thiệu về Vibe Coding và Tác nhân AI
Chào mừng mọi người. Tôi ở đây để nói về chủ đề yêu thích của mọi người: vibe coding, và một cách hơi gây tranh cãi, làm thế nào để vibe code một cách có trách nhiệm trong môi trường production. Vậy hãy cùng tìm hiểu vibe coding là gì.
Trước hết, tôi là Eric. Tôi là một nhà nghiên cứu tại Anthropic, tập trung vào các Tác nhân AI lập trình. Tôi là tác giả, cùng với Barry Zayn, của tài liệu "Building Effective Agents", nơi chúng tôi đã phác thảo những kiến thức khoa học và phương pháp hay nhất để tạo ra các Tác nhân AI, bất kể ứng dụng nào. Đây là một chủ đề rất gần gũi với tôi. Năm ngoái, tôi đã bị gãy tay khi đang đạp xe đi làm và phải bó bột trong hai tháng, và Claude đã viết tất cả mã của tôi trong hai tháng đó. Vì vậy, việc tìm ra cách thực hiện điều này một cách hiệu quả thực sự quan trọng đối với tôi, và may mắn thay, tôi đã có thể tìm ra cách đó và giúp đưa nó vào nhiều sản phẩm khác của Anthropic cũng như các mô hình AI của chúng tôi thông qua nghiên cứu của mình.
Định nghĩa Vibe Coding
Hãy bắt đầu bằng việc tìm hiểu vibe coding là gì. Rất nhiều người thường nhầm lẫn vibe coding với việc sử dụng Trí tuệ nhân tạo (AI) một cách rộng rãi để tạo mã. Nhưng tôi nghĩ điều này không hoàn toàn đúng. Nhiều người đang sử dụng Cursor hoặc Copilot. Đó là rất nhiều Trí tuệ nhân tạo, và phần lớn mã đến từ AI chứ không phải do họ tự viết. Nhưng tôi nghĩ rằng khi bạn vẫn đang trong một vòng lặp phản hồi chặt chẽ với một mô hình AI như vậy, đó không phải là vibe coding thực sự. Khi tôi nói vibe coding, tôi nghĩ chúng ta cần đến định nghĩa của Andrej Karpathy, theo đó vibe coding là khi bạn hoàn toàn "đắm chìm vào cảm hứng, đón nhận sự tăng trưởng theo cấp số nhân, và quên rằng mã thậm chí còn tồn tại." Tôi nghĩ phần quan trọng ở đây là "quên rằng mã thậm chí còn tồn tại."
Lý do điều này quan trọng là vì vibe coding là lúc những người không làm kỹ thuật trong ngành thực sự bắt đầu hứng thú với việc tạo mã. Copilot và Cursor rất tuyệt, nhưng chỉ dành cho các kỹ sư. Nhưng một người không biết lập trình, đột nhiên với vibe coding, họ có thể tự mình viết mã cho toàn bộ một ứng dụng. Và đây là một điều thực sự thú vị và là một bước đột phá lớn đối với nhiều người.
Tất nhiên, có rất nhiều nhược điểm. Bạn có những người lần đầu tiên lập trình mà không thực sự biết mình đang làm gì. Và bạn sẽ nói: "Này, những điều ngẫu nhiên đang xảy ra, mức sử dụng API của tôi đã đạt tối đa." Mọi người đang bỏ qua đăng ký, tạo ra những thứ ngẫu nhiên trên cơ sở dữ liệu (DB). Vì vậy, đây là một mặt trái của vibe coding đã bắt đầu xảy ra. Và những mặt tích cực của vibe coding mà bạn thấy đều là những thứ có rủi ro thấp. Đó là những người xây dựng trò chơi điện tử, xây dựng các dự án phụ vui vẻ, những thứ mà có lỗi cũng không sao.
Tại sao Vibe Coding lại Quan trọng?
Vậy tại sao chúng ta lại quan tâm đến vibe coding? Nếu nó có vẻ là thứ mà rủi ro rất cao nếu bạn làm cho một sản phẩm thực tế, và những trường hợp thành công nhất của nó là những ví dụ "đồ chơi" hoặc những điều vui vẻ có rủi ro rất thấp. Và câu trả lời của tôi cho câu hỏi tại sao chúng ta nên quan tâm đến vibe coding là vì sự tăng trưởng theo cấp số nhân. Độ dài của tác vụ mà Trí tuệ nhân tạo có thể thực hiện đang tăng gấp đôi sau mỗi bảy tháng. Hiện tại, chúng ta đang ở mức khoảng một giờ. Và điều đó không sao cả. Bạn không cần vibe code. Bạn có thể để Cursor làm việc cho bạn. Bạn có thể để Claude Code viết một tính năng mất một giờ. Và bạn có thể xem xét tất cả mã đó. Và bạn vẫn có thể tham gia sâu sắc khi AI đang viết rất nhiều mã của bạn. Nhưng điều gì sẽ xảy ra vào năm tới? Điều gì sẽ xảy ra vào năm sau đó? Khi AI đủ mạnh để có thể tạo ra công việc của cả một ngày cho bạn cùng một lúc, hoặc công việc của cả một tuần, không có cách nào chúng ta có thể theo kịp nếu chúng ta vẫn cần phải di chuyển theo sát từng bước. Điều đó có nghĩa là nếu chúng ta muốn tận dụng sự tăng trưởng theo cấp số nhân này, chúng ta sẽ phải tìm cách đón nhận nó một cách có trách nhiệm và tìm cách tận dụng tác vụ này.
Tôi nghĩ phép ẩn dụ yêu thích của tôi ở đây giống như các trình biên dịch. Tôi chắc chắn rằng trong những ngày đầu của trình biên dịch, nhiều nhà phát triển thực sự không tin tưởng chúng. Họ có thể sử dụng trình biên dịch, nhưng họ vẫn đọc hợp ngữ mà nó xuất ra để đảm bảo nó trông giống như cách họ sẽ viết hợp ngữ. Nhưng điều đó không mở rộng được. Đến một lúc nào đó, bạn bắt đầu cần làm việc trên các hệ thống AI đủ lớn mà bạn chỉ cần tin tưởng vào hệ thống AI đó. Tuy nhiên, câu hỏi là làm thế nào để làm điều đó một cách có trách nhiệm? Và tôi nghĩ thách thức của tôi đối với toàn bộ ngành công nghiệp phần mềm trong vài năm tới là làm thế nào chúng ta sẽ vibe code trong môi trường production và thực hiện điều đó một cách an toàn? Và câu trả lời của tôi là chúng ta sẽ quên rằng mã tồn tại, nhưng không quên rằng sản phẩm tồn tại.
Quản lý Thực thi mà Không Cần Hiểu Sâu
Trở lại với phép ẩn dụ về trình biên dịch, tất cả chúng ta vẫn biết rằng có hợp ngữ nằm bên dưới, nhưng hy vọng hầu hết chúng ta không cần thực sự nghĩ về hợp ngữ đó là gì. Nhưng chúng ta vẫn có thể xây dựng phần mềm tốt mà không cần hiểu hợp ngữ đó. Và tôi nghĩ chúng ta sẽ đạt đến cấp độ tương tự với phần mềm. Và một điều tôi thực sự muốn nhấn mạnh là đây không phải là một vấn đề mới. Làm thế nào một Giám đốc Công nghệ (CTO) quản lý một chuyên gia trong một lĩnh vực mà bản thân Giám đốc Công nghệ (CTO) không phải là chuyên gia? Làm thế nào một Quản lý sản phẩm (PM) xem xét một tính năng kỹ thuật khi bản thân họ không thể đọc tất cả mã đã tạo ra nó? Hoặc làm thế nào một Giám đốc điều hành (CEO) kiểm tra công việc của kế toán khi bản thân họ không phải là chuyên gia về kế toán tài chính? Và đây là tất cả các vấn đề đã tồn tại hàng trăm hoặc hàng nghìn năm. Và chúng ta có giải pháp cho chúng.
Một Giám đốc Công nghệ (CTO) vẫn có thể viết các bài kiểm tra chấp nhận cho một chuyên gia làm việc cho họ. Ngay cả khi họ không hiểu việc triển khai bên dưới, họ có thể thấy rằng các bài kiểm tra chấp nhận này đạt và công việc có chất lượng cao. Một quản lý sản phẩm có thể sử dụng sản phẩm mà nhóm kỹ thuật của họ đã xây dựng và đảm bảo rằng nó hoạt động như mong đợi, ngay cả khi họ không viết mã. Và một Giám đốc điều hành (CEO) có thể kiểm tra nhanh các dữ kiện chính mà họ hiểu và các lát cắt dữ liệu để họ có thể xây dựng niềm tin vào mô hình AI tài chính tổng thể, mặc dù bản thân họ có thể không phải là chuyên gia về cách toàn bộ hệ thống vận hành.
Và vì vậy, suy nghĩ về những ví dụ này, việc quản lý các triển khai mà bản thân bạn không hiểu thực sự là một vấn đề có từ nền văn minh. Và mọi nhà quản lý trên thế giới thực sự đã và đang giải quyết vấn đề này. Chỉ có chúng ta là các kỹ sư phần mềm không quen với điều này. Chúng ta quen với việc là những chuyên viên độc lập, nơi chúng ta hiểu toàn bộ chiều sâu của ngăn xếp công nghệ (stack). Nhưng đó là điều mà để trở nên năng suất nhất, chúng ta sẽ cần phải từ bỏ theo cách mà mọi nhà quản lý để trở nên năng suất nhất sẽ cần phải từ bỏ một số chi tiết. Và giống như chúng ta là các kỹ sư phần mềm, chúng ta từ bỏ một số chi tiết về việc hiểu bản thân hợp ngữ đang xảy ra bên dưới. Và cách bạn làm điều này trong khi vẫn an toàn và có trách nhiệm là tìm một lớp trừu tượng mà bạn có thể xác minh, ngay cả khi không biết việc triển khai bên dưới nó.
Vấn đề Nợ Kỹ thuật và Chiến lược Mã hóa
Tuy nhiên, hôm nay tôi có một lưu ý về nợ kỹ thuật (tech debt). Hiện tại không có cách tốt để đo lường hoặc xác thực nợ kỹ thuật (tech debt) mà không tự đọc mã. Hầu hết các hệ thống AI khác trong cuộc sống, như ví dụ về kế toán, PM, bạn có những cách để xác minh những điều bạn quan tâm mà không cần biết việc triển khai. Nợ kỹ thuật (Tech debt), tôi nghĩ, là một trong những điều hiếm hoi mà thực sự không có cách tốt để xác thực ngoài việc là một chuyên gia về chính việc triển khai. Vì vậy, đó là điều mà hiện tại chúng ta không có cách tốt để xác thực.
Tuy nhiên, điều đó không có nghĩa là chúng ta không thể làm điều này. Nó chỉ có nghĩa là chúng ta cần phải rất thông minh và có mục tiêu, nơi chúng ta có thể tận dụng mã. Câu trả lời của tôi cho điều này là tập trung vào các nút lá (leaf nodes) trong cơ sở mã của chúng ta. Và ý tôi là các phần của mã và các phần của hệ thống AI của chúng ta mà không có gì phụ thuộc vào chúng. Chúng là một tính năng cuối cùng. Chúng là những chi tiết nhỏ cuối cùng hơn là những thứ là nhánh chính hoặc nhánh phụ bên dưới chúng, như ở đây trong màu trắng. Ở đây, các chấm màu cam là tất cả các nút lá (leaf nodes) này, nơi mà thực sự, nếu bạn có một hệ thống AI như thế này, thì cũng không sao nếu có nợ kỹ thuật (tech debt) trong các nút lá (leaf nodes) này bởi vì không có gì khác phụ thuộc vào chúng. Chúng không có khả năng thay đổi. Chúng không có khả năng có thêm những thứ được xây dựng dựa trên chúng. Ngược lại với những thứ màu trắng ở đây, các nhánh chính và nhánh phụ cơ bản của hệ thống AI của bạn, đó là kiến trúc cốt lõi mà chúng ta là các kỹ sư vẫn cần phải hiểu sâu sắc vì đó là những gì sẽ thay đổi. Đó là những gì những thứ khác sẽ được xây dựng dựa trên. Và điều rất quan trọng là chúng ta phải bảo vệ những điều đó và đảm bảo rằng chúng vẫn có khả năng mở rộng, dễ hiểu và linh hoạt.
Bây giờ, một điều tôi sẽ nói ở đây là các mô hình AI đang ngày càng tốt hơn. Và vì vậy, chúng ta có thể đến một thế giới mà điều này ngày càng đi sâu hơn, nơi chúng ta tin tưởng các mô hình AI ngày càng nhiều hơn để viết mã có khả năng mở rộng và không có nợ kỹ thuật (tech debt). Việc sử dụng các mô hình AI Claude 4 trong một hoặc hai tuần qua tại Anthropic là một điều thực sự thú vị. Và tôi đã tin tưởng chúng nhiều hơn so với Claude 3.7. Vì vậy, tôi nghĩ rằng điều này sẽ thay đổi và ngày càng nhiều stack chúng ta sẽ có thể làm việc theo cách này.
Cách Vibe Coding Hiệu quả: Tư duy Quản lý Sản phẩm
Vậy hãy nói về cách thành công trong vibe coding. Và lời khuyên chính của tôi ở đây là đừng hỏi Claude có thể làm gì cho bạn, mà hãy hỏi bạn có thể làm gì cho Claude. Tôi nghĩ khi bạn vibe coding, bạn về cơ bản đang đóng vai trò là một quản lý sản phẩm cho Claude. Vì vậy, bạn cần suy nghĩ như một quản lý sản phẩm. Một nhân viên mới trong nhóm của bạn sẽ cần hướng dẫn hoặc ngữ cảnh nào để thành công trong tác vụ này? Tôi nghĩ nhiều khi chúng ta quá quen với việc thực hiện một cuộc trò chuyện qua lại rất nhanh với AI kiểu "hãy tạo tính năng này, sửa lỗi này". Nhưng một con người nếu đó là ngày đầu tiên đi làm và bạn chỉ nói "này, hãy triển khai tính năng này", không đời nào bạn mong đợi họ thực sự thành công. Bạn cần cho họ một chuyến tham quan cơ sở mã. Bạn cần cho họ biết các yêu cầu, thông số kỹ thuật và ràng buộc thực tế mà họ cần hiểu là gì. Và tôi nghĩ rằng khi chúng ta vibe code, đó trở thành trách nhiệm của chúng ta để cung cấp thông tin đó cho Claude để đảm bảo rằng nó có tất cả ngữ cảnh tương tự và được thiết lập để thành công.
Khi tôi làm việc với các tính năng cùng Claude, tôi thường dành 15 hoặc 20 phút để thu thập hướng dẫn vào một câu lệnh duy nhất và sau đó để Claude thực thi. Và 15 hoặc 20 phút đó không chỉ là tôi tự viết câu lệnh bằng tay. Đây thường là một cuộc trò chuyện riêng biệt, nơi tôi tương tác qua lại với Claude. Nó đang khám phá cơ sở mã, tìm kiếm các tập tin. Chúng tôi cùng nhau xây dựng một kế hoạch nắm bắt được bản chất của những gì tôi muốn, những tập tin nào sẽ được thay đổi, những mẫu nào trong cơ sở mã nó nên tuân theo. Và một khi tôi có sản phẩm đó, tất cả thông tin đó, thì tôi sẽ cung cấp cho Claude, có thể trong một ngữ cảnh mới hoặc nói, "này, hãy thực hiện kế hoạch này." Và tôi thường thấy rằng một khi tôi đã nỗ lực thu thập tất cả thông tin đó, Claude có tỷ lệ thành công rất, rất cao trong việc hoàn thành một cái gì đó một cách rất tốt.
Và điều khác tôi sẽ nói ở đây là bạn cần phải có khả năng đặt đúng câu hỏi. Và mặc dù tiêu đề của bài nói chuyện của tôi, tôi không nghĩ rằng vibe coding trong Claude dành cho tất cả mọi người. Tôi không nghĩ rằng những người hoàn toàn không có kỹ năng kỹ thuật nên đi và cố gắng xây dựng một doanh nghiệp hoàn toàn từ đầu. Tôi nghĩ điều đó nguy hiểm vì họ không thể đặt đúng câu hỏi. Họ không thể là một quản lý sản phẩm hiệu quả cho Claude khi họ làm điều đó. Và vì vậy, họ sẽ không thành công.
Chúng tôi gần đây đã hợp nhất một thay đổi 22.000 dòng mã vào cơ sở mã học tăng cường (reinforcement learning) trong môi trường production của chúng tôi, phần lớn được viết bởi Claude. Vậy làm thế nào chúng tôi đã làm điều này một cách có trách nhiệm? Và vâng, đây là ảnh chụp màn hình thực tế của diff từ GitHub cho yêu cầu hợp nhất mã (PR). Điều đầu tiên là chúng tôi đã hỏi chúng tôi có thể làm gì cho Claude. Đây không chỉ là một câu lệnh duy nhất mà sau đó chúng tôi đã hợp nhất. Vẫn có những ngày làm việc của con người đã được đầu tư vào việc đưa ra các yêu cầu, hướng dẫn Claude và tìm ra hệ thống AI nên là gì.
Quản lý Dự án và Hiệu quả Phát triển
Chúng tôi thực sự đã đảm nhận vai trò là product manager của Claude trong tính năng này. Sự thay đổi chủ yếu tập trung vào các leaf nodes trong cơ sở mã của chúng tôi, nơi chúng tôi biết rằng việc có một chút nợ kỹ thuật là chấp nhận được, bởi vì chúng tôi không mong đợi những phần này của cơ sở mã cần thay đổi trong tương lai gần. Đối với những phần mà chúng tôi cho là quan trọng và cần có khả năng mở rộng, chúng tôi đã tiến hành đánh giá thủ công rất kỹ lưỡng. Cuối cùng, chúng tôi đã thiết kế cẩn thận các kiểm thử tải (stress tests) để đảm bảo độ ổn định. Chúng tôi đã thiết kế toàn bộ hệ thống AI sao cho nó có đầu vào và đầu ra có thể kiểm chứng dễ dàng bởi con người. Hai yếu tố cuối cùng này đã cho phép chúng tôi tạo ra các điểm kiểm tra có thể xác minh, nhờ đó chúng tôi có thể đảm bảo rằng thay đổi này là chính xác ngay cả khi không cần hiểu hoặc đọc toàn bộ triển khai bên dưới. Mối quan tâm lớn nhất của chúng tôi là độ ổn định, và chúng tôi đã có thể đo lường điều đó ngay cả khi không đọc mã bằng cách tạo ra các kiểm thử tải này và chạy chúng trong thời gian dài. Chúng tôi cũng có thể xác minh tính đúng đắn dựa trên đầu vào và đầu ra của hệ thống AI mà chúng tôi đã thiết kế. Về cơ bản, chúng tôi đã thiết kế hệ thống AI này để dễ hiểu và dễ kiểm chứng ngay cả khi chúng tôi không đọc tất cả mã. Và cuối cùng, bằng cách kết hợp những điều đó, chúng tôi đã tự tin về thay đổi này giống như bất kỳ thay đổi nào khác mà chúng tôi đã thực hiện đối với cơ sở mã của mình, nhưng lại hoàn thành nó chỉ trong một phần rất nhỏ thời gian và công sức so với việc viết và đánh giá từng dòng mã đó theo cách thủ công. Tôi nghĩ một trong những điều thực sự thú vị về điều này không chỉ là nó đã tiết kiệm cho chúng tôi một tuần thời gian của con người. Mà việc biết rằng chúng tôi có thể làm điều này đã khiến chúng tôi suy nghĩ khác về kỹ thuật của mình, về những gì chúng tôi có thể làm. Và giờ đây, khi một điều gì đó chỉ tốn một ngày thay vì hai tuần, bạn nhận ra rằng bạn có thể tạo ra các tính năng lớn hơn và những thay đổi lớn hơn nhiều, giống như chi phí biên của phần mềm thấp hơn, và điều đó cho phép bạn tiêu thụ và xây dựng nhiều phần mềm hơn. Vì vậy, tôi nghĩ đó là điều thực sự thú vị về điều này, không chỉ là tiết kiệm thời gian, mà giờ đây cảm giác như: "Ồ, những thứ sẽ mất hai tuần, hãy cứ làm đi. Nó chỉ mất một ngày thôi." Và đó là điều thú vị ở đây.
Lời khuyên để vibe coding có trách nhiệm trong môi trường sản phẩm
Để lại cho các bạn những suy nghĩ cuối cùng về cách vibe code có trách nhiệm trong môi trường sản phẩm (prod): Hãy là product manager của Claude. Đừng hỏi Claude có thể làm gì cho bạn, mà hãy hỏi bạn có thể làm gì cho Claude. Tập trung việc vibe coding của bạn vào các leaf nodes, không phải kiến trúc cốt lõi và hệ thống nền tảng, để nếu có nợ kỹ thuật thì nó sẽ được kiểm soát và không nằm ở các khu vực quan trọng. Hãy suy nghĩ về khả năng kiểm chứng và làm thế nào bạn có thể biết liệu thay đổi này có đúng hay không mà không cần phải tự mình đọc mã. Cuối cùng, hãy nhớ về cấp số nhân. Hôm nay, việc bạn không vibe code có thể không sao, nhưng trong một hoặc hai năm nữa, đó sẽ là một bất lợi rất lớn. Nếu bạn tự mình yêu cầu đọc hoặc viết từng dòng mã, bạn sẽ không thể tận dụng làn sóng mô hình AI mới nhất có khả năng thực hiện những tác vụ rất lớn cho bạn. Và bạn sẽ trở thành nút thắt cổ chai nếu chúng ta không giỏi điều này. Vì vậy, tóm lại, đó là việc vibe coding có trách nhiệm trong môi trường sản phẩm. Và tôi nghĩ đây sẽ trở thành một trong những thách thức lớn nhất đối với ngành kỹ thuật phần mềm trong vài năm tới. Cảm ơn. Và tôi có rất nhiều thời gian cho câu hỏi.
Học hỏi và cải thiện với Tác nhân AI
Trước đây, chúng ta đã dành rất nhiều thời gian để giải quyết các vấn đề cú pháp (syntax problems) hoặc thư viện (libraries) hoặc kết nối giữa các thành phần của mã. Và đó là cách chúng ta học vibe code. Nhưng bây giờ chúng ta học như thế nào? Làm thế nào để chúng ta trở nên giỏi hơn trong vibe code? Làm thế nào để chúng ta hiểu biết hơn để trở thành product manager giỏi hơn của Tác nhân AI? Vâng, tôi nghĩ đây là một câu hỏi thực sự thú vị. Và tôi nghĩ có những lý do để rất lo lắng về điều này, và cũng có những lý do để rất lạc quan về điều này. Tôi nghĩ lý do để lo lắng, như bạn đã đề cập, là chúng ta sẽ không phải trải qua cuộc đấu tranh và vất vả đó. Tôi nghĩ điều đó thực ra là ổn. Tôi đã gặp một số giáo sư của tôi ở trường đại học, những người sẽ nói: "Ôi trời, các lập trình viên ngày nay không giỏi bằng vì họ chưa bao giờ phải tự viết mã assembly. Họ không thực sự cảm nhận được nỗi đau khi phải làm cho thứ gì đó chạy thực sự nhanh." Tôi nghĩ khía cạnh tích cực của điều này là tôi thấy mình có thể tìm hiểu mọi thứ nhanh hơn rất nhiều bằng cách sử dụng các công cụ AI này. Rất nhiều lần khi tôi lập mã với Claude, tôi sẽ đánh giá mã và nói: "Này, Claude, tôi chưa bao giờ thấy thư viện này trước đây. Hãy nói cho tôi biết về nó. Tại sao bạn lại chọn nó thay vì một cái khác?" Và việc có một lập trình viên cặp đôi luôn ở đó, một lần nữa, tôi nghĩ điều sẽ thay đổi là những người lười biếng sẽ không học. Họ sẽ chỉ trượt qua. Nhưng nếu bạn dành thời gian và bạn muốn học, có tất cả những tài nguyên tuyệt vời này. Và Claude sẽ giúp bạn hiểu những gì nó đã vibe code cho bạn. Điều khác tôi muốn nói là để học một số điều cấp cao hơn về những gì làm cho một dự án thành công, tính năng nào giúp bạn đạt được sự phù hợp giữa sản phẩm và thị trường (product market fit) so với những tính năng thất bại, chúng ta sẽ có thể thử nghiệm nhiều hơn rất nhiều. Tôi cảm thấy đặc biệt là các kỹ sư hệ thống hoặc kiến trúc sư, thường phải mất hai năm để thực hiện một thay đổi lớn trong cơ sở mã và thực sự hiểu liệu đó có phải là một quyết định kiến trúc tốt hay không. Và nếu chúng ta có thể rút ngắn thời gian đó xuống còn sáu tháng, tôi nghĩ các kỹ sư đang đầu tư vào thời gian của chính họ và cố gắng học hỏi sẽ có thể học được nhiều bài học gấp bốn lần trong cùng một khoảng thời gian theo lịch, miễn là họ nỗ lực cố gắng.
Cân bằng thông tin trong quy trình tiền kế hoạch
Về quy trình tiền kế hoạch của bạn, sự cân bằng giữa việc cung cấp quá nhiều và quá ít thông tin là như thế nào? Bạn có cung cấp toàn bộ tài liệu yêu cầu sản phẩm (product requirement document) không? Có một mẫu chuẩn hóa nào mà bạn tập hợp trước khi thực sự bắt đầu vibe coding không? Vâng, tôi nghĩ điều đó phụ thuộc rất nhiều vào những gì bạn quan tâm. Tôi sẽ nói rằng nếu đối với những việc mà tôi không thực sự quan tâm đến cách nó thực hiện, tôi sẽ không nói gì về chi tiết triển khai. Tôi sẽ chỉ nói đây là yêu cầu của tôi, đây là những gì tôi muốn ở cuối cùng. Có những lúc khác khi tôi hiểu rõ cơ sở mã và tôi sẽ đi sâu hơn nhiều, ví dụ như: "Này, đây là những lớp bạn nên sử dụng để triển khai logic này. Hãy xem ví dụ này về một tính năng tương tự." Tôi nghĩ tất cả đều phụ thuộc vào những gì bạn quan tâm cuối cùng. Tuy nhiên, tôi cũng muốn nói rằng các mô hình AI của chúng tôi hoạt động tốt nhất khi bạn không ràng buộc quá mức chúng. Vì vậy, tôi sẽ không dành quá nhiều nỗ lực để tạo ra một định dạng nghiêm ngặt hoặc bất cứ điều gì. Tôi sẽ chỉ nghĩ về nó như một kỹ sư cấp dưới, bạn sẽ cung cấp cho họ những gì để họ thành công.
Bảo mật trong vibe coding
Xin lỗi về những gì bạn đang nói. Bạn đã cân bằng hiệu quả và an ninh mạng như thế nào? Vài tháng trước có những báo cáo về 10 ứng dụng được vibe code hàng đầu rất dễ bị tấn công và rất nhiều thông tin quan trọng đã bị rò rỉ. Chà, không phải rò rỉ mà là được chứng minh là đã bị rò rỉ. Và người làm điều đó thậm chí không phải là một tin tặc chuyên nghiệp. Vậy thì, làm thế nào bạn cân bằng việc có thể giữ mọi thứ an toàn ngay cả ở cấp độ leaf node và đồng thời hiệu quả, bởi vì một thứ gì đó có thể hiệu quả nhưng không an toàn? Vâng, đó là một câu hỏi tuyệt vời. Và tôi nghĩ tất cả đều quy về điểm đầu tiên này, đó là hãy là product manager của Claude và hiểu đủ về ngữ cảnh để về cơ bản biết cái gì là nguy hiểm, cái gì an toàn và nơi nào bạn nên cẩn thận. Và tôi nghĩ, vâng, những điều thu hút nhiều sự chú ý về vibe coding là những người không có kinh nghiệm code đang làm những điều này. Và điều đó không sao cả. Nó tuyệt vời cho trò chơi, tuyệt vời cho sự sáng tạo và cho phép mọi người tạo ra. Nhưng tôi nghĩ đối với hệ thống sản xuất (production systems), bạn cần biết đủ về những câu hỏi cần hỏi để hướng dẫn Claude đi đúng hướng. Và đối với trường hợp nội bộ của chúng tôi trong ví dụ này, đó là một thứ hoàn toàn offline. Và vì vậy, chúng tôi biết rằng không có bất kỳ, chúng tôi rất, rất tự tin rằng không có vấn đề bảo mật nào có thể xảy ra với nó. Trong trường hợp của chúng tôi, nó được chạy trong một cái gì đó hoàn toàn offline. Vì vậy, đây là về những người bạn đề cập là "không có kinh nghiệm". Và có lẽ tôi không nên nói như vậy. Không có kinh nghiệm vibe coding trong môi trường sản phẩm cho một hệ thống quan trọng. Tôi sẽ nói vậy.
Tương lai của Phát triển Phần mềm và AI
Nhưng nếu chúng ta nhìn vào các con số, phải không, chưa đến 0,5% dân số thế giới là các nhà phát triển phần mềm. Và phần mềm là một cách tuyệt vời để mở rộng các ý tưởng. Vậy bạn nghĩ các sản phẩm cần thay đổi như thế nào? Để giúp mọi người dễ dàng vibe code và xây dựng phần mềm hơn, đồng thời tránh một số vấn đề mà chúng ta gặp phải khi mọi người rò rỉ khóa API (API keys) và những thứ tương tự? Đó thực sự là một câu hỏi tuyệt vời. Và tôi sẽ rất vui khi thấy nhiều sản phẩm và khuôn khổ (frameworks) xuất hiện mà có thể chứng minh được tính đúng đắn (provably correct). Và có lẽ ý tôi là tôi chắc chắn mọi người có thể xây dựng một số hệ thống backend mà các phần xác thực (auth parts) quan trọng, các phần thanh toán (payment parts) được xây dựng sẵn cho bạn. Và tất cả những gì bạn phải làm là điền vào lớp giao diện người dùng (UI layer). Và bạn có thể vibe code điều đó. Và về cơ bản, nó cung cấp cho bạn một số môi trường cách ly (sandboxes) điền vào chỗ trống tốt đẹp để đặt mã của bạn. Tôi cảm thấy có rất nhiều điều như vậy có thể tồn tại. Có lẽ ví dụ đơn giản nhất là sản phẩm/vật phẩm của Claude (Claude artifacts), nơi Claude có thể giúp bạn viết mã được lưu trữ ngay tại Claude AI để hiển thị. Và tất nhiên, điều đó an toàn vì nó rất hạn chế. Không có xác thực, không có thanh toán, nó chỉ giao diện người dùng (front end only). Nhưng có lẽ đó là một ý tưởng sản phẩm hay mà ai đó nên thực hiện ở đây là xây dựng một cách nào đó để tạo ra một hệ thống lưu trữ (hosting system) có thể chứng minh được tính đúng đắn, có thể có một backend mà bạn biết là an toàn, bất kể sự cố nào xảy ra ở giao diện người dùng. Nhưng tôi hy vọng mọi người sẽ xây dựng các công cụ tốt bổ sung cho vibe coding.
Phát triển Hướng Kiểm Thử (TDD) với Claude
Vậy đối với phát triển hướng kiểm thử (test driven development), bạn có lời khuyên nào không? Bởi vì tôi thường thấy Claude chỉ đưa ra toàn bộ triển khai và sau đó viết trường hợp kiểm thử (test cases). Đôi khi chúng thất bại. Và sau đó tôi chỉ muốn, bạn biết đấy, tôi đang cố gắng nhắc nhở nó viết trường hợp kiểm thử trước. Nhưng tôi cũng không muốn, bạn biết đấy, tự mình xác minh chúng vì tôi chưa thấy chúng trong triển khai. Vậy bạn có một cách tiếp cận lặp lại nào mà, bạn biết đấy, bạn đã bao giờ thử nó cho phát triển hướng kiểm thử chưa? Vâng, vâng. Tôi chắc chắn rằng phát triển hướng kiểm thử rất, rất hữu ích trong vibe coding. Miễn là bạn có thể hiểu các trường hợp kiểm thử là gì. Ngay cả khi không có điều đó, nó cũng giúp Claude tự tự nhất quán hơn một chút. Ngay cả khi bạn không tự mình xem các kiểm thử. Nhưng rất nhiều lần tôi muốn nói rằng Claude dễ dàng đi sâu vào việc viết các kiểm thử quá cụ thể về triển khai. Khi tôi cố gắng làm điều này, rất nhiều lần tôi sẽ khuyến khích, tôi sẽ đưa cho Claude các ví dụ như: "Này, chỉ cần viết ba kiểm thử đầu cuối (end to end tests) và, bạn biết đấy, thực hiện luồng xử lý thành công (happy path) và trường hợp lỗi (error case) này và trường hợp lỗi khác." Và tôi khá mang tính quy định về việc tôi muốn kiểm thử phải chung chung và kiểm thử đầu cuối. Tôi nghĩ điều đó giúp đảm bảo đó là thứ mà tôi có thể hiểu và đó là thứ mà Claude có thể làm mà không đi sâu vào chi tiết quá nhiều. Tôi cũng sẽ nói rằng rất nhiều lần khi tôi vibe coding, phần duy nhất của mã, hoặc ít nhất là phần đầu tiên của mã mà tôi đọc là các kiểm thử để đảm bảo rằng, bạn biết đấy, nếu tôi đồng ý với các kiểm thử và các kiểm thử vượt qua, thì tôi cảm thấy khá hài lòng về mã. Điều đó hoạt động tốt nhất nếu bạn có thể khuyến khích Claude viết các kiểm thử đầu cuối rất tối giản. Tôi nghĩ đó là điều tốt cho cuộc nói chuyện rất hấp dẫn này.
Khái niệm "Embrace Exponentials"
Tôi cũng đánh giá cao việc bạn đã làm được điều mà nhiều người chưa làm, đó là cố gắng diễn giải một trong những câu khá đặc biệt trong bài đăng gốc của Karpathy: "embrace exponentials". Vì vậy, tôi tự hỏi liệu tôi có thể hỏi kỹ hơn một chút và nói rằng, làm thế nào để tôi biết mình đã "ôm lấy exponentials" (embrace exponentials)? Chính xác thì việc tuân theo lời khuyên đó có nghĩa là gì, và có thể đào sâu hơn một chút về điều mà tôi nghĩ nó muốn truyền tải. Có lẽ nó dẫn đến việc các mô hình AI sẽ ngày càng tốt hơn. Bạn có nghĩ có lý khi nói rằng chỉ riêng việc các mô hình AI sẽ tốt hơn không có nghĩa là chúng sẽ tốt hơn ở mọi khía cạnh có thể tưởng tượng mà chúng ta hy vọng không? Vậy, làm thế nào để tôi "ôm lấy exponentials"?
Vâng, hoàn toàn chính xác. Tôi nghĩ bạn đã gần đúng với câu nói kiểu như, hãy cứ tiếp tục giả định rằng các mô hình AI sẽ tốt hơn. Nhưng nó còn hơn thế nữa. Ý tưởng, exponential, không chỉ là chúng sẽ tiếp tục tốt hơn, mà là chúng sẽ tốt hơn nhanh hơn chúng ta có thể tưởng tượng. Và điều đó giống như khi bạn, bạn có thể nhìn thấy hình dạng của các chấm ở đây. Nó không chỉ là việc nó đang dần tốt lên. Mà là nó đang tốt lên và sau đó thì nó trở nên vượt trội. Tôi nghĩ câu nói hài hước khác mà tôi nghe được từ đây, đây là trong bài nói chuyện của Dario và Mike Krieger: "Machines of Loving Grace không phải là khoa học viễn tưởng. Đó là một lộ trình sản phẩm." Mặc dù nghe có vẻ rất xa vời, nhưng khi bạn đang trên một đường cong exponential, mọi thứ sẽ trở nên điên rồ rất, rất nhanh và nhanh hơn bạn mong đợi. Và tôi nghĩ, nếu bạn nói chuyện với một người làm máy tính vào những năm 90, họ sẽ nói: "Tuyệt vời, chúng ta có vài kilobyte RAM. Chúng ta có thêm vài kilobyte RAM." Nhưng nếu bạn tua nhanh đến thời điểm hiện tại, chúng ta có terabyte. Và nó không chỉ là việc nó tốt gấp đôi. Mà là mọi thứ đã tốt hơn hàng triệu lần. Và đó là điều xảy ra với exponentials trong suốt 20 năm. Vì vậy, chúng ta không nên nghĩ về 20 năm. Bây giờ chúng ta nên nghĩ về điều gì sẽ xảy ra nếu những mô hình AI này thông minh và nhanh hơn hàng triệu lần so với hiện tại, điều đó thật điên rồ. Chúng ta thậm chí không thể nghĩ về ý nghĩa của điều đó. Cũng giống như cách mà một người làm máy tính vào những năm 90, tôi không nghĩ họ có thể nghĩ về điều gì sẽ xảy ra với xã hội nếu một chiếc máy tính nhanh hơn hàng triệu lần so với những gì họ đang làm việc. Nhưng đó là điều đã xảy ra. Và đó là ý nghĩa của exponential, là nó sẽ trở nên vượt trội? Vâng.
Quy trình làm việc với Claude Code và Quản lý Ngữ cảnh
Tôi có một vài, à tôi có một câu hỏi, nhưng nó gồm hai phần. Phần đầu tiên, khi nói đến coding, tôi có hai quy trình làm việc khác nhau. Một là khi tôi sử dụng thiết bị đầu cuối, và một là khi tôi sử dụng VS Code hoặc Cursor. Bạn sử dụng quy trình làm việc nào? Và nếu bạn sử dụng Claude Code trong thiết bị đầu cuối, bạn thu gọn ngữ cảnh (compact) thường xuyên như thế nào? Bởi vì tôi thấy rằng các hàm của tôi sẽ nhận một tên mới khi tôi viết mã theo cảm tính (vibe code) trong thời gian dài. Hoặc mọi thứ chỉ đơn giản là đi chệch hướng, và ngay cả khi tôi thu gọn ngữ cảnh, điều đó vẫn xảy ra. Nếu tôi tạo một tài liệu để hướng dẫn nó, tôi vẫn phải đưa nó trở lại đúng hướng. Vâng, một câu hỏi hay. Tôi làm cả hai. Tôi thường viết mã với Claude Code mở trong thiết bị đầu cuối của VS Code. Và tôi sẽ nói rằng Claude Code đang thực hiện hầu hết việc chỉnh sửa, và tôi đang xem xét mã khi tôi làm việc trong VS Code. Điều đó không phải là vibe coding thực sự theo nghĩa ở đây, hoặc có thể tôi chỉ đang xem xét các kiểm thử từ nó. Tôi thích thu gọn ngữ cảnh hoặc chỉ bắt đầu một cuộc trò chuyện mới. Đại loại là bất cứ khi nào tôi đưa Claude đến một điểm dừng tốt, nơi tôi cảm thấy như, với tư cách là một lập trình viên con người, khi nào thì tôi sẽ dừng lại và nghỉ giải lao và có thể đi ăn trưa rồi quay lại? Nếu tôi cảm thấy mình đang ở giai đoạn đó, đó là một thời điểm tốt để thu gọn ngữ cảnh. Vì vậy, có lẽ tôi sẽ bắt đầu bằng cách nhờ Claude tìm tất cả các tệp liên quan và lập một kế hoạch. Và sau đó tôi sẽ nói, được rồi, hãy viết tất cả những điều này vào một tài liệu và sau đó tôi sẽ thu gọn ngữ cảnh. Và điều đó loại bỏ 100.000 token mà chúng tôi đã sử dụng để tạo kế hoạch đó và tìm tất cả các tệp này, cô đọng nó lại thành vài nghìn token.
Tăng cường tốc độ và làm quen với Cơ sở mã mới
Này, một câu hỏi tiếp theo từ câu hỏi trước của anh ấy là, bạn đã sử dụng những công cụ nào khác cùng với Claude Code để tăng tốc độ một chút, ví dụ như chạy nhiều phiên bản Claude Code cùng lúc bằng cách sử dụng git worktrees và sau đó hợp nhất một vài thứ hoặc stack PR chẳng hạn. Đó có phải là điều bạn tự mình thực hiện hay bạn sẽ khuyên người khác làm theo không? Câu hỏi thứ hai là, làm thế nào để bạn tiếp cận một phần của cơ sở mã mà bạn không thực sự quen thuộc, một cách rất có cấu trúc và với một phương pháp kỹ thuật tốt, nhưng bạn muốn gửi một yêu cầu hợp nhất mã (PR) thật nhanh và bạn muốn làm điều đó một cách thực sự tốt chứ không phải vibe code nó? Vậy, những cách của bạn khi sử dụng Claude Code để giúp thực hiện cả hai điều này là gì?
Vâng. Tôi chắc chắn sử dụng cả Claude Code lẫn Cursor. Và tôi sẽ nói rằng thông thường tôi sẽ bắt đầu công việc với Claude Code và sau đó tôi sẽ dùng Cursor để khắc phục các vấn đề hoặc nếu tôi có những thay đổi rất cụ thể mà tôi biết chính xác thay đổi mà tôi muốn thực hiện cho tệp này, tôi sẽ tự mình làm điều đó với Cursor và nhắm vào chính xác các dòng mà tôi biết cần chỉnh sửa. Phần thứ hai của câu hỏi của bạn là, à vâng, làm thế nào để làm quen với một phần mới của cơ sở mã. Trước khi tôi bắt đầu cố gắng viết tính năng, tôi sử dụng Claude Code để giúp tôi khám phá cơ sở mã. Vì vậy, tôi có thể nói như, cho tôi biết phần off diễn ra ở đâu trong cơ sở mã này hoặc bạn biết đấy, điều gì đó xảy ra ở đâu trong cơ sở mã này. Hãy cho tôi biết các tính năng tương tự như thế này và hãy để nó cho tôi biết tên tệp, các lớp mà tôi nên xem xét. Và sau đó sử dụng điều đó để cố gắng xây dựng một hình dung trong đầu để đảm bảo rằng tôi có thể làm điều này và không vibe code, đảm bảo rằng tôi vẫn có thể nắm bắt tốt những gì đang diễn ra. Và sau đó tôi làm việc với tính năng đó cùng với Claude. Cảm ơn rất nhiều. Tôi sẽ ở đây và Can Miller có thể trả lời các câu hỏi khác.