Vibe Coding: Khi AI viết code, lập trình viên còn vai trò gì?
Hãy tưởng tượng bạn muốn xây dựng một ứng dụng mới.
Trước đây, bạn sẽ mở trình soạn thảo code, chọn một framework, bắt đầu viết các file, rồi dành hàng giờ để gỡ lỗi và điều chỉnh.
Ngày nay, bạn có thể bắt đầu chỉ với một câu duy nhất:
Tôi muốn một ứng dụng quản lý chi tiêu có đăng nhập, bảng điều khiển và biểu đồ thể hiện chi tiêu hàng tháng.
Sau đó, bạn để AI bắt đầu làm việc.
Nó viết code.
Nó tạo các file.
Nó chạy dự án.
Nó phát hiện lỗi.
Và nó chỉnh sửa những gì nó đã viết.
Còn bạn?
Thay vì tự viết từng dòng code, bạn trở thành người mô tả điều mình muốn và đánh giá những gì đã được xây dựng.
Đây chính là bản chất của Vibe Coding.
Nhưng ở đây có một câu hỏi đáng để dừng lại:
Nếu AI có thể viết code... vai trò của lập trình viên đã trở thành gì?
📌 Hãy lưu bài viết này ngay từ bây giờ, vì chúng ta không chỉ nói về một cách viết code mới, mà còn về sự thay đổi đang diễn ra trong cách phần mềm được xây dựng.
Câu hỏi quan trọng nhất cuối cùng sẽ không phải là: AI có thể viết code không?
Mà là:
Bạn có biết điều gì nên được xây dựng, tại sao, và những gì đã được xây dựng có xứng đáng với sự tin tưởng của bạn không?
Vibe Coding thực sự là gì?
Thuật ngữ Vibe Coding nghe có vẻ như một phương pháp lập trình mới, nhưng thực ra nó mô tả một sự thay đổi lớn hơn trong cách phần mềm được xây dựng.
Trong lập trình truyền thống, bạn nghĩ ra giải pháp rồi chuyển nó thành code.
Bạn quyết định kiến trúc.
Bạn chọn các thư viện.
Bạn viết các hàm.
Bạn xử lý lỗi.
Và bạn kiểm thử từng phần.
Trong Vibe Coding, bạn bắt đầu từ một vị trí khác:
Bạn mô tả những gì bạn muốn xây dựng, sau đó để AI đảm nhận phần lớn việc chuyển mô tả đó thành code.
Bạn có thể bắt đầu, ví dụ, với:
Tôi muốn một trang đăng nhập đơn giản, tương thích với di động, sử dụng email và mật khẩu.
AI tạo ra code.
Bạn chạy thử.
Bạn nhận thấy mình không thích thiết kế.
Vì vậy bạn nói:
Hãy làm thiết kế đơn giản hơn, và thêm thông báo rõ ràng khi nhập dữ liệu sai.
Nó chỉnh sửa code.
Sau đó bạn phát hiện một vấn đề khác.
Bạn yêu cầu sửa nó.
Rồi bạn thêm một tính năng mới.
Và cứ thế bắt đầu một vòng lặp hoàn toàn khác với cách mà các lập trình viên từng quen thuộc.
Sự khác biệt thực sự không phải là AI viết code
Và đây là một điểm rất quan trọng.
AI đã có khả năng viết code từ lâu.
Vậy tại sao Vibe Coding lại trở thành một chủ đề khác biệt?
Bởi vì ý tưởng không phải là:
"AI giúp tôi viết code."
Mà là:
"Tôi xem AI như người thực hiện phần lớn quy trình lập trình, còn tôi điều hướng và đánh giá kết quả."
Và đây là một sự khác biệt cơ bản.
Trong trường hợp đầu, bạn vẫn là lập trình viên chính, và AI chỉ hỗ trợ bạn.
Trong trường hợp thứ hai, bạn chuyển dịch nhiều hơn về phía người xác định yêu cầu, kiểm thử kết quả và quyết định điều gì cần thay đổi.
🤯
Vibe Coding không chỉ giúp viết code nhanh hơn... nó thay đổi ý nghĩa của việc trở thành một lập trình viên.
Ở đây, bức tranh lớn hơn bắt đầu hiện ra.
Bởi vì khi bạn giảm thời gian viết code, bạn sẽ thấy thời gian của mình chuyển sang những việc khác:
Suy nghĩ về sản phẩm.
Xác định những gì nên được xây dựng.
Kiểm thử những gì đã được xây dựng.
Phát hiện những gì đang sai.
Và xác định những gì cần thay đổi.
Đây là lý do tại sao Vibe Coding không chỉ là một cách viết code nhanh hơn.
Nó là một nỗ lực thay đổi ai sẽ thực hiện từng bước trong quy trình xây dựng phần mềm.
Câu hỏi bây giờ không phải là AI có thể viết một ứng dụng hay không...
Điều đó đã trở nên rõ ràng.
Câu hỏi khó hơn:
Điều gì xảy ra khi ứng dụng bắt đầu hoạt động, nhưng bạn không biết chính xác nó được xây dựng như thế nào?
Từ viết code đến mô tả điều bạn muốn
Để hiểu rõ hơn về Vibe Coding, hãy so sánh cách một lập trình viên từng làm việc và cách họ có thể làm việc ngày nay.
Trong lập trình truyền thống, bạn bắt đầu với một ý tưởng:
Tôi muốn một hệ thống quản lý chi tiêu.
Nhưng chỉ riêng ý tưởng này thôi là chưa đủ.
Bạn phải biến nó thành các yêu cầu, sau đó chọn công nghệ phù hợp, thiết kế cơ sở dữ liệu, xây dựng giao diện, viết API, kết nối các phần lại với nhau, kiểm thử hệ thống và sửa lỗi.
Mỗi bước đều đòi hỏi các quyết định kỹ thuật.
Với Vibe Coding, bạn có thể bắt đầu từ cùng một ý tưởng, nhưng thay vì tự mình chuyển nó thành hàng trăm chi tiết lập trình, bạn mô tả cho AI những gì bạn muốn sản phẩm làm được.
Sau đó, nó bắt đầu chuyển mô tả này thành một bản triển khai cụ thể.
Lập trình truyền thống
Ý tưởng → Yêu cầu → Kiến trúc → Viết code → Gỡ lỗi → Kiểm thử hệ thống → Triển khai
Lập trình truyền thống
Vibe Coding
Ý tưởng → Mô tả yêu cầu → AI xây dựng → Chạy và trải nghiệm → Phản hồi → AI chỉnh sửa → Kiểm thử và đánh giá
Hãy chú ý sự khác biệt.
Trong phương pháp đầu tiên, code là phương tiện chính giữa ý tưởng của bạn và sản phẩm.
Trong phương pháp thứ hai, mô tả, trải nghiệm và đánh giá trở thành phần lớn hơn trong quy trình, trong khi AI đảm nhận phần lớn việc chuyển ý tưởng thành code.
Ở đây xuất hiện một trong những sự chuyển dịch quan trọng nhất của Vibe Coding:
Bạn không còn phải luôn biết cách viết mọi thứ... nhưng bạn phải biết cách xác định những gì nên tồn tại.
Điều này không có nghĩa là kiến thức kỹ thuật đã trở nên vô giá trị.
Hoàn toàn ngược lại.
Việc tạo ra code càng dễ dàng, thì khả năng đánh giá nó và hiểu được những tác động của nó càng trở nên quan trọng.
Bởi vì cuối cùng, bạn sẽ không chỉ hỏi:
Ứng dụng có hoạt động không?
Thay vào đó, bạn sẽ cần hỏi:
Nó có được xây dựng đúng cách không?
Khi code chỉ còn là phương tiện
Một điều quan trọng đang diễn ra ở đây.
Trong lập trình truyền thống, rất nhiều thời gian được dành để chuyển một ý tưởng thành các chỉ dẫn mà máy tính hiểu được.
Bạn biết mình muốn xây dựng gì, nhưng bạn phải tự chuyển ý tưởng này thành:
Các hàm, các thành phần, API, truy vấn cơ sở dữ liệu, quản lý trạng thái, và nhiều thứ khác.
Phần này chính là lý do khiến việc học lập trình mất rất nhiều thời gian.
Nhưng Vibe Coding cố gắng thu hẹp khoảng cách này.
Thay vì nhiệm vụ chính của bạn là:
Làm thế nào để tôi viết code này?
Nó trở thành:
Tôi muốn điều gì xảy ra?
Đây là một thay đổi nhỏ về từ ngữ, nhưng rất lớn về cách tư duy.
Hãy tưởng tượng bạn muốn thêm tính năng tìm kiếm vào một ứng dụng.
Một lập trình viên truyền thống có thể bắt đầu suy nghĩ:
Endpoint là gì?
Tôi sẽ xử lý State như thế nào?
Tôi có nên dùng Debouncing không?
Tôi sẽ viết Query như thế nào?
Tôi sẽ xử lý phân trang như thế nào?
Tôi sẽ hiển thị trạng thái tải như thế nào?
Tôi sẽ xử lý lỗi như thế nào?
Trong Vibe Coding, bạn có thể bắt đầu từ một mức cao hơn:
Thêm tính năng tìm kiếm sản phẩm nhanh, với kết quả tức thì, trạng thái tải và thông báo rõ ràng khi không tìm thấy kết quả nào.
AI cố gắng chuyển mô tả này thành các chi tiết kỹ thuật.
Ở đây, giá trị của lập trình viên trở nên gắn liền hơn với khả năng biết những chi tiết cần phải có ngay từ đầu.
💡
Khi viết code trở nên rẻ hơn, biết viết gì trở nên quan trọng hơn biết viết như thế nào.
Nhưng ở đây có một cái bẫy lớn.
Bởi vì nếu bạn không biết mình đang tìm kiếm điều gì...
Bạn sẽ không biết liệu AI có chọn đúng giải pháp hay không.
Nó có thể đưa cho bạn code chạy được.
Nó có thể trông rất xuất sắc.
Và có thể không có lỗi nào xuất hiện khi chạy ứng dụng.
Tuy nhiên, quyết định kỹ thuật đằng sau đoạn code này có thể tồi.
Ở đây, vấn đề thực sự của Vibe Coding bắt đầu.
Khiến AI viết code thì dễ hơn nhiều so với việc biết liệu đoạn code nó viết có đáng giữ lại hay không.
Code chạy được... nhưng nó có tốt không?
Ở đây bắt đầu vấn đề không xuất hiện trong lần thử nghiệm đầu tiên.
Bạn có thể nhờ AI xây dựng một hệ thống đăng nhập, nó viết code, bạn chạy ứng dụng và thấy mọi thứ hoạt động.
Bạn đăng ký một tài khoản.
Bạn đăng nhập.
Bạn đăng xuất.
Và bạn quay lại lần nữa.
Mọi thứ trông thật hoàn hảo.
Bạn tự nhủ:
Xong rồi.
Nhưng nếu có một lỗ hổng bảo mật không xuất hiện trong bài kiểm thử của bạn thì sao?
Nếu truy vấn cơ sở dữ liệu không được tối ưu thì sao?
Nếu có một vấn đề sẽ xuất hiện khi số lượng người dùng lên tới 100.000 thay vì 100 thì sao?
Nếu AI sử dụng một thư viện cũ hoặc một cấu trúc khiến việc phát triển dự án trở nên khó khăn hơn sau vài tháng thì sao?
Ở đây chúng ta chạm đến một khác biệt cơ bản:
Làm cho code chạy được là một chuyện... còn xây dựng một chương trình tốt lại là chuyện khác.
Hãy tưởng tượng bạn nhờ AI:
Thêm hệ thống thanh toán vào ứng dụng.
Và quả thực, nó đã tạo trang thanh toán và kết nối với API, mọi thứ đều hoạt động khi kiểm thử.
Nhưng bạn đã kiểm chứng chưa:
- Điều gì xảy ra nếu kết nối bị ngắt giữa lúc thanh toán?
- Quy trình có thể bị thực hiện hai lần do nhầm lẫn không?
- Số tiền có được xác minh trên máy chủ không?
- Dữ liệu nhạy cảm có được bảo vệ không?
- Điều gì xảy ra nếu thanh toán thất bại sau khi số tiền đã bị trừ?
- Người dùng có thể thao túng yêu cầu không?
Đây không phải là những câu hỏi về việc viết code.
Đây là những câu hỏi về kỹ thuật phần mềm.
Ở đây, giá trị của kinh nghiệm con người xuất hiện.
⚠️
Đoạn code nguy hiểm nhất mà AI viết không phải là đoạn code chứa lỗi... mà là đoạn code chạy được trong khi bạn không biết nó sai.
Đây là lý do Vibe Coding không có nghĩa là lập trình viên không còn cần hiểu về lập trình.
Nó có thể có nghĩa là điều hoàn toàn ngược lại.
Việc tạo ra code càng dễ dàng, thì việc phát hiện code kém chất lượng càng trở nên quan trọng.
AI có thể đưa cho bạn bản đầu tiên chỉ trong vài phút.
Nhưng câu hỏi mà nó không phải lúc nào cũng tự trả lời được là:
Đây có phải là cách đúng để xây dựng hệ thống này không?
Vibe Coding có giết chết lập trình không?
Ở đây, cuộc tranh luận thực sự bắt đầu.
Bởi vì sự xuất hiện của Vibe Coding khiến một câu hỏi cũ trở nên cấp thiết hơn:
Nếu AI có thể viết code, tại sao tôi phải học lập trình?
Câu trả lời nhanh có thể là:
Bởi vì AI vẫn sẽ cần một lập trình viên.
Nhưng chỉ riêng câu trả lời này là chưa đủ.
Bởi vì sự thật là một phần công việc mà lập trình viên từng làm đã bắt đầu chuyển sang AI.
Viết Boilerplate?
Đã trở nên dễ dàng hơn.
Tạo Components?
Đã trở nên nhanh hơn.
Viết CRUD API?
Đã trở nên nhanh hơn.
Chuyển thiết kế thành giao diện?
Đã trở nên dễ dàng hơn.
Viết các bài kiểm thử ban đầu?
Đã trở nên nhanh hơn.
Vì vậy, chúng ta không thể nói rằng không có gì thay đổi.
Mọi thứ đã thay đổi thật sự.
Nhưng sai lầm là đánh đồng lập trình với viết code.
Lập trình viên không bán cho công ty số dòng code mà họ có thể viết.
Công ty không cần 10.000 dòng code.
Họ cần một hệ thống giải quyết được vấn đề.
Đây là một khác biệt rất lớn.
Nếu AI có thể viết 10.000 dòng trong một giờ, nhưng hệ thống đầy lỗi...
Chúng ta chẳng đạt được gì.
Nhưng nếu một lập trình viên có thể xây dựng hệ thống đúng đắn chỉ với 1.000 dòng code, với kiến trúc tốt, bảo mật và kiểm thử đầy đủ...
Đó mới là giá trị thực sự.
⚔️ Điều gì xảy ra với vai trò của lập trình viên?
Sự chuyển dịch có thể được đơn giản hóa như sau:
Lập trình truyền thống
Lập trình viên trực tiếp chịu trách nhiệm viết code, triển khai các chi tiết kỹ thuật, tìm kiếm cú pháp phù hợp, xử lý lỗi thủ công và xây dựng các phần của hệ thống từ đầu. Phần lớn thời gian của họ dành để chuyển ý tưởng thành các chỉ dẫn mà máy tính hiểu được.
Với Vibe Coding
Lập trình viên tập trung nhiều hơn vào việc xác định yêu cầu, đưa ra các quyết định kỹ thuật, phân tích vấn đề, điều hướng AI, sau đó đánh giá và chỉnh sửa những gì được xây dựng. Thay vì tập trung vào việc tự triển khai từng chi tiết, phần lớn sự tập trung của họ chuyển sang kết quả cuối cùng và chất lượng của hệ thống đang được xây dựng.
Điều này không có nghĩa là lập trình viên sẽ rời bỏ code hoàn toàn.
Nó có nghĩa là code có thể không còn là phần lớn nhất trong giá trị mà họ mang lại.
🤯
Vibe Coding không loại bỏ lập trình viên... nhưng nó làm giảm giá trị của phần công việc vốn dựa vào việc viết code thủ công.
Ở đây, câu hỏi trở nên chính xác hơn:
Lập trình viên chỉ biết viết code liệu có còn đủ không?
Rất có thể...
Không.
Bởi vì người chỉ biết cú pháp có thể bị thay thế phần lớn bởi AI hỗ trợ kỹ năng đó.
Nhưng người hiểu được:
Tại sao chúng ta xây dựng hệ thống này?
Nó nên hoạt động như thế nào?
Có những rủi ro gì?
Chúng ta kiểm thử nó như thế nào?
Và điều gì xảy ra khi nó thất bại?
Kinh nghiệm của họ vẫn còn rất giá trị.
Thực tế, những kỹ năng này có thể trở nên quan trọng hơn khi việc tạo ra code trở nên dễ dàng hơn.
Vibe Coding có phù hợp với tất cả mọi người không?
Ở đây chúng ta phải phân biệt giữa khả năng sử dụng Vibe Coding và năng lực sử dụng nó một cách hiệu quả.
Đúng vậy, một người không có nhiều kinh nghiệm lập trình giờ đây hoàn toàn có thể xây dựng một ứng dụng đơn giản bằng AI.
Và điều này rất quan trọng.
Bởi vì rào cản để thử một ý tưởng mới đã trở nên thấp hơn rất nhiều.
Một người có ý tưởng cho một dự án nhỏ không còn bị buộc phải học tất cả các chi tiết lập trình trước khi nhìn thấy phiên bản đầu tiên của ý tưởng mình.
Họ có thể bắt đầu, thử nghiệm, chỉnh sửa và học hỏi ngay trong quá trình xây dựng.
Nhưng vấn đề bắt đầu khi chuyển từ:
Tôi muốn thử một ý tưởng
sang:
Tôi muốn xây dựng một hệ thống thực sự mà mọi người phụ thuộc vào.
Ở đây, câu chuyện hoàn toàn khác.
Hãy tưởng tượng ai đó đã xây dựng một cửa hàng thương mại điện tử hoàn chỉnh bằng Vibe Coding.
Giao diện hoạt động.
Sản phẩm hiển thị.
Giỏ hàng hoạt động.
Và đăng nhập hoạt động.
Dự án có thể trông rất thành công.
Nhưng điều gì xảy ra khi họ cần thay đổi cách tính giá?
Hoặc khi một lỗi xuất hiện mà họ không thể tái hiện lại?
Hoặc khi hai thư viện xung đột với nhau?
Hoặc khi họ phát hiện ra thiết kế cơ sở dữ liệu không phù hợp?
Lúc này, nói với AI rằng:
Sửa cái này
Sẽ là chưa đủ, bởi vì trước tiên bạn cần hiểu chính vấn đề.
Đây là sự khác biệt giữa việc sử dụng Vibe Coding như một công cụ hỗ trợ bạn xây dựng...
Và việc sử dụng nó như một sự thay thế hoàn toàn cho việc hiểu những gì bạn đang xây dựng.
💡
Vibe Coding đã giảm chi phí khởi đầu trong lập trình, nhưng nó không xóa bỏ chi phí của sự hiểu biết.
Thực tế, nó có thể khiến sự hiểu biết trở nên quan trọng hơn.
Bởi vì người hiểu được chuyện gì đang xảy ra có thể dùng AI như một đòn bẩy khổng lồ.
Còn người không hiểu chuyện gì đang xảy ra, họ có thể xây dựng được thứ gì đó một cách nhanh chóng...
Nhưng họ có thể không biết tại sao nó hoạt động, khi nào nó sẽ ngừng hoạt động và làm thế nào để sửa nó khi nó hỏng.
Khi nào Vibe Coding là một ý tưởng tuyệt vời... và khi nào nó trở thành rủi ro?
Vibe Coding không phải là giải pháp thay thế phù hợp cho mọi loại phần mềm.
Trong một số trường hợp, nó có thể là một trong những cách nhanh nhất để đi từ ý tưởng đến một mô hình hoạt động.
Muốn xây dựng một nguyên mẫu?
Tuyệt vời.
Muốn thử một ý tưởng trước khi đầu tư nhiều thời gian và tiền bạc?
Tuyệt vời.
Muốn tạo một Landing Page, một công cụ nội bộ đơn giản hay một dự án cá nhân?
Ở đây, tốc độ mà Vibe Coding mang lại có thể là một lợi thế rất lớn.
Thay vì dành nhiều ngày để thiết lập dự án và viết những phần lặp lại, bạn có thể đạt được phiên bản ban đầu trong thời gian ngắn, sau đó bắt đầu thử nghiệm chính ý tưởng.
Đây là một điểm rất quan trọng:
Đôi khi bạn không cần code hoàn hảo... bạn trước tiên cần biết liệu ý tưởng có đáng để xây dựng hay không.
Nhưng bức tranh sẽ thay đổi khi chương trình chịu trách nhiệm về những thứ nhạy cảm.
Một hệ thống xử lý thanh toán.
Một ứng dụng lưu trữ dữ liệu cá nhân.
Một hệ thống y tế.
Một nền tảng tài chính.
Một hệ thống xác thực.
Hoặc bất kỳ chương trình nào mà một lỗi nhỏ có thể dẫn đến mất tiền, rò rỉ dữ liệu hoặc gián đoạn dịch vụ.
Ở đây, nói rằng:
"Ứng dụng chạy được."
Sẽ là chưa đủ. Thay vào đó, bạn phải biết nó hoạt động như thế nào, tại sao nó hoạt động và điều gì có thể xảy ra khi ai đó cố sử dụng nó theo cách bạn không lường trước.
⚔️ Quy tắc đơn giản
Chi phí của sai lầm càng cao, bạn càng ít có thể dựa vào Vibe Coding mà không có sự đánh giá kỹ thuật thực sự.
Nếu bạn đang xây dựng một công cụ nhỏ cho riêng mình, tốc độ có thể quan trọng hơn sự hoàn hảo.
Nhưng nếu bạn đang xây dựng một hệ thống mà hàng nghìn người dùng sẽ phụ thuộc, thì kiến trúc, bảo mật, kiểm thử và đánh giá không phải là những thứ có thể bỏ mặc cho may rủi.
Ở đây, cách tốt nhất để sử dụng Vibe Coding hiện ra:
Đừng dùng nó để thay thế kỹ thuật phần mềm.
Hãy dùng nó để tăng tốc kỹ thuật phần mềm.
Và đó là một khác biệt lớn.
Làm thế nào để sử dụng Vibe Coding đúng cách?
Sự khác biệt giữa một người dùng Vibe Coding để xây dựng thứ gì đó thực sự và một người chỉ bấm vào AI rồi lấy kết quả đầu tiên, không nằm ở công cụ họ sử dụng.
Sự khác biệt nằm ở cách làm việc.
Sai lầm lớn nhất là đưa cho AI một ý tưởng khổng lồ và yêu cầu nó xây dựng toàn bộ dự án cùng một lúc.
Ví dụ:
"Hãy xây cho tôi một cửa hàng thương mại điện tử hoàn chỉnh với đăng nhập, thanh toán, bảng điều khiển, thông báo và hệ thống giao hàng."
Bạn có thể thực sự nhận được một dự án chạy được.
Nhưng nhiệm vụ càng lớn, việc biết được chuyện gì đã xảy ra bên trong càng khó, và việc phát hiện cũng như sửa lỗi càng trở nên phức tạp.
Cách tốt nhất là xử lý dự án theo từng giai đoạn.
Bắt đầu với mục tiêu.
Sau đó nhờ AI lập kế hoạch.
Tiếp theo, xây dựng một tính năng.
Chạy thử.
Kiểm thử.
Đánh giá code.
Sau đó chuyển sang tính năng tiếp theo.
Bằng cách này, bạn không để AI xây dựng dự án thay bạn...
Mà bạn khiến nó xây dựng cùng bạn từng bước một.
📊 Một quy trình đơn giản cho Vibe Coding
🎯 Mục tiêu → 📝 Kế hoạch → 🤖 AI xây dựng → ▶️ Chạy và trải nghiệm → 🔍 Đánh giá → 🐛 Phát hiện lỗi → 🤖 AI chỉnh sửa → ✅ Kiểm thử → 🚀 Chuyển sang bước tiếp theo
Một quy trình đơn giản cho Vibe Coding
Điều quan trọng nhất:
Đừng chấp nhận code mà bạn không hiểu chức năng của nó trong những phần quan trọng của hệ thống.
Bạn không bắt buộc phải ghi nhớ từng dòng code mà AI đã viết.
Nhưng bạn phải biết điều gì đang diễn ra trong kiến trúc, dữ liệu di chuyển như thế nào, điểm yếu nằm ở đâu và cách xử lý lỗi ra sao.
💡
Hãy dùng AI để tăng tốc độ của bạn, chứ không phải để thay thế sự hiểu biết của bạn.
Khi bạn sử dụng Vibe Coding theo cách này, tốc độ mà AI mang lại sẽ trở thành một lợi thế thực sự.
Bởi vì bạn không để nó dẫn dắt dự án...
Bạn dẫn dắt, và nó thực thi.
Bạn có nên học lập trình nếu sử dụng Vibe Coding?
Ở đây xuất hiện một trong những câu hỏi được hỏi nhiều nhất về Vibe Coding:
Nếu AI có thể viết code, tại sao tôi phải học lập trình?
Câu trả lời không phải là ai cũng nên trở thành một kỹ sư phần mềm chuyên nghiệp.
Nhưng nếu bạn muốn chuyển từ việc chỉ thử một ý tưởng sang xây dựng các chương trình thực sự và phụ thuộc vào chúng, thì việc hiểu về lập trình sẽ vẫn rất quan trọng.
Không nhất thiết theo cách cũ.
Bạn không cần phải ghi nhớ hàng trăm dòng cú pháp trước khi xây dựng dự án đầu tiên của mình.
Và bạn không cần tự viết toàn bộ phần Boilerplate.
Nhưng bạn phải hiểu những điều giúp bạn có khả năng đánh giá những gì AI tạo ra.
Chẳng hạn như:
- Cách API hoạt động.
- Cách ứng dụng làm việc với cơ sở dữ liệu.
- Cách dữ liệu di chuyển giữa các phần của hệ thống.
- Ý nghĩa của Xác thực và Phân quyền.
- Cách phát hiện lỗi.
- Cách kiểm thử hoạt động.
- Kiến trúc nghĩa là gì.
- Các vấn đề bảo mật có thể xuất hiện ở đâu.
Bởi vì khi bạn biết những điều cơ bản này, bạn có thể nhìn vào code do AI viết và đặt ra những câu hỏi đúng đắn.
Nếu bạn không biết chúng, bạn có thể thấy một dự án đẹp đẽ đang hoạt động trước mắt...
Và cho rằng nó tốt.
Ở đây, phong cách học lập trình có thể thay đổi.
Thay vì dành nhiều thời gian cố ghi nhớ mọi thứ trước khi xây dựng bất kỳ dự án nào, bạn có thể học trong lúc xây dựng.
Muốn biết API hoạt động như thế nào?
Hãy dùng AI để xây dựng một cái, sau đó nhờ nó giải thích.
Muốn hiểu về cơ sở dữ liệu?
Hãy tạo một bảng, viết các truy vấn và xem dữ liệu di chuyển như thế nào.
Muốn hiểu về Xác thực?
Hãy áp dụng nó, sau đó cố hiểu từng bước đang diễn ra phía sau.
Theo cách này, AI trở thành một người thầy, một trợ lý và một chất xúc tác cùng lúc.
Nhưng có một quy tắc bạn không được phá vỡ:
⚠️
Đừng để AI học lập trình thay bạn. Hãy dùng nó để học lập trình nhanh hơn.
Bởi vì sự khác biệt giữa hai cách này sẽ hiện ra ngay khi vấn đề đầu tiên xuất hiện mà một lời nhắc (Prompt) không thể giải quyết.
Điều gì sẽ xảy ra với lập trình viên?
Có lẽ đây là câu hỏi khiến Vibe Coding khác biệt so với chỉ một công cụ mới.
Bởi vì chúng ta không chỉ nói về một chương trình giúp bạn viết code nhanh hơn, mà còn về khả năng hình thái công việc của lập trình viên tự nó thay đổi.
Trước đây, phần lớn thời gian trong ngày của một lập trình viên dành để chuyển các yêu cầu thành code.
Đọc yêu cầu.
Tìm kiếm giải pháp.
Viết code.
Kiểm thử.
Sửa lỗi.
Sau đó lặp lại vòng lặp.
Khi AI có thể đảm nhận phần lớn những nhiệm vụ này, việc lập trình viên chuyển sự tập trung sang những việc khác là điều tự nhiên.
Câu hỏi sẽ ít liên quan đến:
Làm thế nào để tôi viết cái này?
Và liên quan nhiều hơn đến:
Cách tốt nhất để xây dựng cái này là gì?
Và đó là một khác biệt lớn.
Hãy tưởng tượng một lập trình viên trước một dự án mới.
Thay vì bắt đầu bằng việc viết file đầu tiên, họ có thể bắt đầu bằng việc xác định yêu cầu, sau đó nhờ AI đề xuất một kiến trúc, thảo luận các phương án, tạo nguyên mẫu và viết các bài kiểm thử ban đầu.
Sau đó, họ bắt đầu đánh giá lại các quyết định.
Phát hiện một vấn đề.
Thay đổi thiết kế.
Yêu cầu một điều chỉnh.
Kiểm thử kết quả.
Và cuối cùng quyết định những gì sẽ được đưa vào Production.
Trong trường hợp này, lập trình viên không hề biến mất.
Nhưng trọng tâm công việc của họ đã dịch chuyển.
Từ việc viết từng chi tiết...
Sang việc đưa ra những quyết định định hình sản phẩm.
Điều này có thể khiến một số kỹ năng trở nên kém quan trọng hơn tương đối, trong khi giá trị của những kỹ năng khác tăng lên.
Những kỹ năng mà việc thực hiện thủ công có thể giảm bớt
- Viết Boilerplate.
- Tạo các component lặp lại.
- Viết CRUD truyền thống.
- Chuyển đổi các thiết kế đơn giản thành code.
- Tìm kiếm cú pháp cho từng vấn đề nhỏ.
Những kỹ năng trở nên quan trọng hơn
- Thiết kế hệ thống.
- Kiến trúc.
- Gỡ lỗi.
- Bảo mật.
- Kiểm thử.
- Hiểu logic nghiệp vụ.
- Đánh giá code.
- Khả năng xác định vấn đề một cách chính xác.
- Khả năng đánh giá chất lượng của giải pháp.
Sửa lỗi này.
Nó gợi ý một điều chỉnh.
Bạn thử.
Vấn đề vẫn còn đó.
Bạn yêu cầu một điều chỉnh khác.
Rồi điều chỉnh thứ ba.
Đột nhiên bạn thấy mình bị mắc kẹt trong một vòng lặp thử nghiệm, bởi vì bạn không hiểu rõ được những gì đang xảy ra bên trong hệ thống.
Ở đây vấn đề không phải là AI yếu kém.
Vấn đề là bạn không biết nên hỏi nó những câu hỏi nào.
⚠️
Việc hoàn toàn phụ thuộc vào Vibe Coding có thể khiến bạn giỏi tạo ra code... nhưng yếu trong việc hiểu nó.
Vì vậy, có sự khác biệt giữa người nói:
AI đã xây dựng ứng dụng cho tôi.
Và người nói:
Tôi dùng AI để xây dựng ứng dụng, nhưng tôi hiểu Kiến trúc của nó, và tôi biết cách kiểm thử, sửa lỗi và phát triển nó.
Người thứ nhất sở hữu một sản phẩm.
Người thứ hai sở hữu một năng lực.
Và năng lực này sẽ theo bạn ngay cả khi công cụ bạn dùng hôm nay biến mất và một công cụ mới xuất hiện vào ngày mai.
Vì vậy, cách tốt nhất để đối phó với Vibe Coding không phải là để AI suy nghĩ thay bạn.
Mà là khiến nó mở rộng khả năng tư duy và xây dựng của bạn.
Bởi vì mục tiêu cuối cùng không phải là trở thành người có thể khiến AI viết nhiều code nhất.
Mục tiêu là trở thành người biết thứ gì nên được xây dựng, và làm thế nào để đảm bảo những gì được xây dựng xứng đáng được giới thiệu ra thế giới.
Lưu ý: Vibe Coding không có nghĩa là xây dựng mọi thứ bằng AI
Ở đây chúng ta cần sửa một quan niệm sai lầm rất phổ biến.
Khi nghe đến thuật ngữ Vibe Coding, nhiều người có thể tưởng tượng rằng cách lý tưởng là mở một công cụ AI và yêu cầu nó xây dựng toàn bộ dự án, rồi chờ kết quả.
Nhưng điều này thường không phải là cách sử dụng tốt nhất ý tưởng này.
Sức mạnh thực sự xuất hiện khi bạn biết phần nào của quy trình xây dựng đáng để giao cho AI, và phần nào bạn nên giữ lại cho mình.
Ví dụ, bạn có thể để AI xử lý:
- Tạo Boilerplate (mã khung).
- Xây dựng các Component lặp đi lặp lại.
- Viết các bài kiểm thử ban đầu.
- Chuyển đổi thiết kế thành code.
- Gợi ý giải pháp cho một vấn đề cụ thể.
- Phân tích lỗi.
- Thực hiện Refactoring.
- Viết tài liệu cho các phần của dự án.
Đổi lại, bạn giữ lại những quyết định cần sự hiểu biết về ngữ cảnh:
- Lựa chọn Kiến trúc.
- Xác định Logic nghiệp vụ.
- Quyết định về bảo mật.
- Thiết kế các hệ thống nhạy cảm.
- Xem xét những phần code quan trọng.
- Xác định những gì được đưa lên Production.
- Xác định liệu giải pháp được gợi ý có thực sự phù hợp ngay từ đầu hay không.
🤯 Ý tưởng quan trọng nhất
Vibe Coding không phải là để AI làm việc thay bạn.
Đó là việc để AI đảm nhận những phần không cần tiêu tốn thời gian và kinh nghiệm của bạn, để bạn có thể tập trung vào những phần thực sự cần kinh nghiệm của mình.
Ở đây lập trình viên trở thành người dẫn dắt quy trình.
Đưa ra định hướng.
Đặt ra các ràng buộc.
Xem xét kết quả.
Và can thiệp khi cần một quyết định không thể giao cho máy móc.
Vibe Coding tốt nhất không phải là cách khiến AI viết nhiều code nhất... mà là cách khiến lập trình viên tập trung vào những điều đáng để suy nghĩ.
Đây có lẽ là sự khác biệt quan trọng nhất giữa việc sử dụng Vibe Coding như một lối tắt cho việc lập trình...
Và sử dụng nó như một cách mới để xây dựng phần mềm.
Một lập trình viên nên học gì trong thời đại Vibe Coding?
Nếu việc viết code đã trở nên dễ dàng và nhanh chóng hơn, điều này không có nghĩa là lập trình viên cần ít kỹ năng hơn.
Nó có nghĩa là loại kỹ năng họ cần đã bắt đầu thay đổi.
Mục tiêu không còn là trở thành người nhanh nhất trong việc viết Cú pháp.
AI có thể giúp bạn điều đó.
Điều quan trọng nhất là trở thành người có thể nhìn vấn đề từ trên cao, hiểu hệ thống, và phát hiện liệu giải pháp do AI gợi ý có thực sự phù hợp hay không.
Vì vậy, một nhóm kỹ năng sẽ trở nên rõ ràng quan trọng hơn.
1 - Hiểu kiến thức nền tảng về lập trình
Bạn không cần phải ghi nhớ mọi thứ.
Nhưng bạn phải hiểu cách mọi thứ hoạt động:
Biến, Hàm, API, Cơ sở dữ liệu, Xác thực, HTTP, Git.
Bởi vì nếu thiếu những kiến thức nền tảng này, bạn sẽ khó biết điều gì đang xảy ra khi AI mắc lỗi.
2 - Thiết kế hệ thống và Kiến trúc
Việc xây dựng các thành phần càng trở nên dễ dàng, thì cách liên kết các thành phần đó với nhau càng trở nên quan trọng.
Cơ sở dữ liệu có được thiết kế đúng không?
API có phù hợp không?
Hệ thống có khả năng mở rộng không?
Việc lựa chọn công nghệ có hợp lý không?
Đây là những quyết định không thể thu gọn vào việc chỉ viết code.
3 - Phát hiện và sửa lỗi
Việc nhờ AI sửa lỗi thì dễ.
Nhưng lập trình viên giỏi là người có thể hiểu:
Nguyên nhân của vấn đề là gì?
Nó xảy ra ở đâu?
Và tại sao nó lại xảy ra?
Sau đó dùng AI để đạt được giải pháp nhanh hơn.
4 - Kiểm thử phần mềm
Khi AI có thể viết code nhanh chóng, việc kiểm thử code này càng trở nên quan trọng hơn.
Nói "Nó chạy được với tôi" thôi là chưa đủ.
Bạn phải tự hỏi:
"Liệu nó có còn hoạt động khi điều kiện thay đổi không?"
Ở đây xuất hiện tầm quan trọng của Kiểm thử đơn vị (Unit Tests), Kiểm thử tích hợp (Integration Tests) và các trường hợp biên (Edge Cases).
5 - Bảo mật phần mềm
Và đây là một trong những điểm nguy hiểm nhất.
AI có thể viết Xác thực, Thanh toán và API trong thời gian ngắn.
Nhưng việc có code không có nghĩa là nó an toàn.
Bạn phải hiểu ít nhất những nguyên tắc cơ bản cho phép bạn phát hiện ra các lỗ hổng và những thực hành nguy hiểm.
💡
Trong thời đại Vibe Coding, giá trị của bạn sẽ không nằm ở khả năng viết từng dòng code... mà nằm ở khả năng biết dòng nào đáng để viết ngay từ đầu.
Điều này không có nghĩa là việc học lập trình trở nên kém quan trọng hơn.
Thực tế, nó có thể còn quan trọng hơn đối với những ai muốn vượt qua giai đoạn "Tôi có thể xây dựng một thứ hoạt động" để đến giai đoạn "Tôi có thể xây dựng một thứ đáng tin cậy."
Lập trình viên sẽ trở nên kém quan trọng hơn hay quan trọng hơn?
Có lẽ đây là nghịch lý lớn nhất trong thời đại Vibe Coding.
Thoạt nhìn, có vẻ như AI đang đảm nhận một phần lớn công việc của lập trình viên.
Nhưng đồng thời, nó mở ra cánh cửa để lập trình viên hoàn thành những việc mà trước đây cần nhiều thời gian và một đội ngũ lớn hơn.
Lập trình viên từng dành hàng giờ để viết code lặp đi lặp lại giờ có thể dùng thời gian đó để hiểu về sản phẩm.
Còn lập trình viên từng mắc kẹt ở một vấn đề kỹ thuật nhỏ thì giờ có thể nhanh chóng thử nghiệm nhiều giải pháp.
Và lập trình viên từng cần nhiều ngày để xây dựng bản mẫu (prototype) giờ có thể đạt được một phiên bản có thể kiểm thử chỉ trong thời gian ngắn.
Vì vậy vấn đề không phải là:
Lập trình viên sẽ biến mất?
Câu hỏi đúng hơn là:
Loại lập trình viên nào sẽ trở nên có giá trị hơn?
Giá trị của người có lợi thế chính chỉ là tốc độ viết code có khả năng sẽ giảm đi.
Bởi vì tốc độ này đã trở thành thứ mà AI có thể nhân lên đáng kể.
Nhưng giá trị của lập trình viên có thể hiểu vấn đề, thiết kế hệ thống, phát hiện lỗi, đưa ra quyết định đúng đắn và xem xét những gì AI tạo ra...
Có thể sẽ tăng cao hơn.
Bởi vì AI có thể tạo ra nhiều phương án nhanh chóng.
Nhưng vẫn cần ai đó quyết định:
Phương án nào là tốt nhất?
🤯
AI càng giỏi viết code bao nhiêu, thì một lập trình viên giỏi càng ít phụ thuộc vào việc viết code và càng phụ thuộc vào việc hiểu nó bấy nhiêu.
Ở đây có thể xảy ra một sự thay đổi quan trọng trong định nghĩa về "lập trình viên".
Có lẽ lập trình viên trong tương lai sẽ không chỉ là người ngồi hàng giờ trước trình soạn thảo code.
Mà là người có thể nắm bắt một vấn đề thực tế, biến nó thành một hệ thống hoạt động, sử dụng AI như một phần của quy trình xây dựng, và sau đó chịu trách nhiệm về kết quả cuối cùng.
Code vẫn sẽ tồn tại.
Nhưng cách để đạt được nó...
Có thể sẽ thay đổi đáng kể.
Tốc độ dừng lại ở đâu và trách nhiệm bắt đầu từ đâu?
Có một điều khiến Vibe Coding khác biệt so với việc chỉ sử dụng một công cụ mới.
Tốc độ giờ đây gần như ai cũng có thể đạt được.
Nhưng tốc độ một mình không đảm bảo một kết quả tốt.
Hai người có thể dùng cùng một công cụ, yêu cầu xây dựng cùng một ứng dụng, và nhận được kết quả hoàn toàn khác nhau.
Người thứ nhất yêu cầu:
Xây cho tôi một ứng dụng quản lý kho hàng.
Sau đó chấp nhận kết quả đầu tiên.
Còn người thứ hai bắt đầu bằng việc xác định yêu cầu, chia nhỏ dự án, kiểm thử từng phần, xem xét các quyết định quan trọng, và đảm bảo bảo mật cũng như hiệu suất trước khi coi dự án đã hoàn thành.
Công cụ là một.
Nhưng cách sử dụng nó hoàn toàn khác nhau.
Chính tại đây, trách nhiệm của lập trình viên được thể hiện.
Khi bạn để AI viết một phần lớn code, điều này không có nghĩa là bạn đã từ bỏ trách nhiệm với code đó.
Nếu một lỗi xảy ra trên Production, câu trả lời sẽ không phải là:
AI là người viết ra nó.
Người dùng không quan tâm ai viết code.
Họ quan tâm sản phẩm hoạt động.
Và công ty không thể nói với khách hàng:
Vấn đề là do AI.
Bởi vì trách nhiệm cuối cùng thuộc về đội ngũ đã quyết định sử dụng code này và đưa nó ra thị trường.
⚠️
Khả năng thực thi của AI càng tăng, thì tầm quan trọng của con người quyết định điều gì nên được thực thi càng lớn.
Điều này đặt ra một quy tắc rất quan trọng cho Vibe Coding:
Đừng giao trách nhiệm cho AI chỉ vì bạn đã giao việc thực thi cho nó.
Bạn có thể để nó viết code.
Bạn có thể để nó gợi ý Kiến trúc.
Bạn có thể để nó tìm kiếm lỗi.
Bạn có thể để nó viết các bài kiểm thử.
Nhưng cuối cùng...
Bạn là người quyết định điều gì xứng đáng được đưa đến người dùng.
Chính tại đây, Vibe Coding chuyển từ một cách viết chương trình nhanh chóng...
Thành một bài kiểm tra thực sự về khả năng tư duy, xem xét và ra quyết định của lập trình viên.
Điều gì còn lại cho lập trình viên sau Vibe Coding?
Vibe Coding không làm cho việc lập trình trở nên vô giá trị, nhưng nó đã thay đổi nơi giá trị được tạo ra.
Code đã trở nên dễ tạo ra hơn, nhưng việc hiểu vấn đề, thiết kế giải pháp, xem xét kết quả, phát hiện lỗi và chịu trách nhiệm về sản phẩm lại càng trở nên quan trọng hơn.
Lập trình viên được hưởng lợi từ sự thay đổi này không phải là người cố gắng cạnh tranh với AI trong việc viết code nhanh chóng.
Mà là người biết khi nào nên sử dụng nó, nên yêu cầu nó làm gì, và cách xem xét những gì nó tạo ra.
💡
Tương lai không dành cho lập trình viên viết code nhanh hơn AI... mà dành cho lập trình viên biết thứ gì nên được xây dựng và tại sao.
Cuối cùng, có lẽ câu hỏi không còn là:
AI sẽ lấy đi công việc của lập trình viên sao?
Mà đã trở thành:
Lập trình viên đã sẵn sàng làm việc theo một cách mới chưa?
Kết luận: Lập trình viên không biến mất... nhưng họ đang thay đổi
Vibe Coding không có nghĩa là lập trình đã kết thúc.
Cũng không có nghĩa là bất kỳ ai mô tả một ý tưởng cho AI rồi trở thành kỹ sư phần mềm.
Điều đã thay đổi là vị trí của con người trong quy trình xây dựng.
AI đã trở nên có khả năng viết những phần lớn code, tạo bản mẫu, sửa lỗi và thực hiện các tác vụ lặp đi lặp lại.
Nhưng vẫn còn những câu hỏi không thể bỏ qua:
Chúng ta đang xây dựng điều gì?
Tại sao chúng ta xây dựng nó?
Đây có phải là cấu trúc đúng không?
Hệ thống có an toàn không?
Nó có thể được tin cậy không?
Và điều gì xảy ra khi nó gặp sự cố?
Chính tại đây, giá trị của lập trình viên được thể hiện.
Không phải là người tự viết từng dòng code...
Mà là người hiểu vấn đề, dẫn dắt quy trình xây dựng, xem xét những gì AI tạo ra và chịu trách nhiệm về kết quả.
🔥
Có lẽ tương lai của lập trình không phải là viết nhiều code hơn... mà là xây dựng những thứ tốt hơn bằng cách dùng ít code hơn.
Vibe Coding sẽ không biến tất cả mọi người thành lập trình viên.
Nhưng nó sẽ khiến lập trình viên biết sử dụng nó đúng cách trở nên nhanh hơn và có năng lực hơn trước.
Và câu hỏi thực sự không còn là:
AI có thể viết code không?
Nó đã chứng minh điều đó.
Câu hỏi lúc này:
Bạn có biết nó nên xây dựng điều gì không?
Chính tại đây bắt đầu sự khác biệt giữa người sử dụng Vibe Coding...
Và người thực sự xây dựng bằng nó.
📌 Trước khi bạn đóng bài viết... hãy ghi nhớ quy tắc này
Nếu bạn định sử dụng Vibe Coding, đừng coi nó như một cách để trốn tránh việc lập trình.
Hãy coi nó như một cách để nâng cao khả năng xây dựng của bạn.
Bắt đầu từ ý tưởng, làm rõ yêu cầu, để AI giúp bạn trong khâu thực thi, sau đó xem xét và kiểm thử mọi thứ quan trọng.
Và hãy luôn nhớ:
Tốc độ không đồng nghĩa với chất lượng.
Code chạy được chưa chắc là code tốt.
Và một AI có thể xây dựng chưa chắc đã biết thứ gì nên được xây dựng.
Vì vậy, khả năng sử dụng AI của bạn càng tăng lên bao nhiêu, hãy đảm bảo đồng thời tăng khả năng hiểu, xem xét và ra quyết định của bạn bấy nhiêu.
Trong Vibe Coding, thời gian bạn dành để viết code có thể giảm đi... nhưng đừng để nó làm giảm thời gian bạn dành để suy nghĩ.
📌 Nếu bạn thấy bài viết này đã thay đổi cách suy nghĩ của bạn, hãy lưu nó vào Bookmarks (Dấu trang) của bạn.
Không chỉ vì nó giải thích một công cụ mới...
Mà vì nó giải thích một sự thay đổi trong cách phần mềm được xây dựng, và vai trò của lập trình viên có thể thay đổi như thế nào với sự phổ biến của Vibe Coding.
Và nếu bạn có ý kiến khác, hoặc thấy rằng Vibe Coding sẽ thay đổi lập trình theo một cách khác mà tôi chưa đề cập, hãy cho tôi biết trong phần bình luận. Tôi sẽ rất vui khi được đọc và trao đổi.
Chuẩn bị và viết bởi: Adel Ahmed
💙 Nếu bạn thấy bài viết hữu ích, đừng quên lưu nó (Bookmark) và chia sẻ với bạn bè của bạn quan tâm đến lập trình và AI, vì bài viết này có thể là điểm khởi đầu để hiểu về cách thức xây dựng phần mềm đang thay đổi, không chỉ cách viết code.
