Vibe Coding: Nên hiểu và áp dụng như thế nào?

Vào ngày 3 tháng 2 năm 2025, Andrej Karpathy đã chia sẻ một dòng tweet về một kiểu lập trình mới mà ông đang khám phá, và ông gọi nó là vibe coding.

Khái niệm này nhanh chóng trở nên phổ biến trong giới công nghệ và AI, đến mức ai cũng bắt đầu nói về vibe coding. Thậm chí, nhiều người đã sử dụng AI để lập trình từ trước đó nhưng không biết gọi cách làm của mình là gì, và Andrej đã làm một việc tuyệt vời khi đặt tên cho nó.

Chỉ trong vài ngày, vibe coding đã trở thành một thuật ngữ quen thuộc trong thế giới công nghệ. Mọi người phát cuồng vì nó và tạo ra những sản phẩm khó tin. Cứ vài ngày lại có người tuyên bố rằng giờ đây chúng ta không còn cần đến kỹ sư phần mềm nữa.

Ở cấp độ công việc, chúng tôi cũng đã "vibe coding" như thếtrong gần 1 năm qua, chỉ khác cách gọi tên.

Còn ở bên ngoài, dạo quanh nhiều cộng đồng lớn trên Reddit thì thấy sau vài tháng, mã nguồn được tạo ra bởi một số vibe coder đã bị hack, bị sập, và gây ra những vấn đề nghiêm trọng. Trong khi đó, một số vibe coder khác lại đang kiếm được rất nhiều tiền từ chính cách làm này.

Một số người trên các cộng đồng công nghệ cho rằng vibe coding chỉ là bong bóng? Rằng chúng ta có một thứ gì đó tốt hơn vibe coding, một thứ thực sự hoạt động hiệu quả khi kết hợp với AI.

Nhưng trước hết, hãy bắt đầu từ nền tảng.

I. Vibe Coding là gì?

Trước khi đi sâu vào những vấn đề của vibe coding, chúng ta cần định nghĩa rõ vibe coding thực sự là gì.

Trong nhiều thập kỷ, việc tạo ra phần mềm đòi hỏi con người phải học cách suy nghĩ theo kiểu máy tính, vốn thường ngược lại với cách con người suy nghĩ tự nhiên. Kết quả là hàng triệu người có trực giác sản phẩm rất tốt nhưng chưa từng ship được gì, vì con đường phía trước trông quá thách thức về mặt kiến thức (lập trình). Con đường đó có độ dốc quá cao đến nỗi gần như cản trở những ai không phải là lập trình viên có thể leo lên được.

Vibe coding làm phẳng đoạn dốc đó, cho phép ý tưởng được chuyển thẳng thành prototype chạy được. Vì vậy nó không giống một cải tiến nhỏ, mà giống như một cánh cổng vừa được mở ra cho tất cả mọi người.

Vấn đề nằm ở chỗ, mỗi người lại có một cách hiểu khác nhau:

• Kiểu A: Thực hiện phần lớn công việc bằng các prompt tiếng Anh thông thường, nhưng vẫn đọc và hiểu code
• Kiểu B: Bỏ qua code hoàn toàn, chỉ prompt
• Kiểu C: Người không phải developer viết code thông qua AI
• Kiểu D: Sử dụng tính năng autocomplete trong IDE

Vậy định nghĩa của bạn là gì?

II. Từ định nghĩa của bạn

Bây giờ, dựa trên định nghĩa vibe coding của riêng bạn, bạn sẽ đánh giá xem nó có đúng hay không. Để tôi giải thích.

Nếu định nghĩa của bạn nghiêng về Kiểu B hoặc Kiểu C, và bạn muốn xây dựng một phần mềm có thể được người dùng thật sử dụng, thì tôi nghĩ bạn cần nhìn nhận lại vấn đề sâu sắc hơn.

Vibe coding, đối với Kiểu B và Kiểu C, nên được hiểu đúng bản chất của nó: bạn có thể xây dựng một prototype cơ bản cho ý tưởng trong đầu mình, hoặc những công cụ nhỏ phục vụ cho nhu cầu cá nhân. Nếu bạn kỳ vọng nhiều hơn thế, đó có thể lỗi kỳ vọng từ bạn, chứ không phải lỗi của vibe coding.

Kiểu A và Kiểu D thực ra không phải là vibe coder. Họ đang dùng AI để viết code. Nếu bạn biết cách viết code và sử dụng kiến thức đó trong quá trình nhờ AI hỗ trợ, thì bạn không phải đang vibe coding. Bạn có thể ngừng nói với mọi người rằng bạn đã vibe-coded ứng dụng này.

Đối với kiểu D, nếu bạn sử dụng các IDE như Cursor, Kiro (AWS), Google Antigravity đang nổi thời gian gần đây, thì chắc hẳn bạn sẽ thấy rằng các IDE này phù hợp ở các dạng:

• Mỗi tháng bạn nhảy qua lại giữa 5 ý tưởng SaaS còn dang dở. Bạn muốn thử nghiệm nhanh để trả lời câu hỏi: Cái SaaS này có đáng tồn tại không?
• Bạn sẵn sàng đánh đổi kiểm soát chặt chẽ để lấy đòn bẩy cực lớn từ AI
• Nhưng hãy chấp nhận rằng:
  • Chất lượng sẽ không đồng đều.
  • Bạn sẽ debug logic của agent, không chỉ debug code.
  • Độ ổn định không được đảm bảo.

III. Đến giấc mơ hay bong bóng

Ví dụ khi tôi nói Vibe coding là tương lai hoặc chỉ là bong bóng, các bạn hoàn toàn có thể bỏ qua. Tôi chỉ là một người ngồi trước bàn phím, làm tốt công việc Product Management của mình.

Bởi vì tôi chỉ là người đọc thông tin, tự trải nghiệm và đón nhận cơn sóng vibe coding này như bao người khác.

Nhưng khi Garry Tan, CEO của Y Combinator, cái nhà máy sản xuất unicorn của Thung lũng Silicon, nói điều đó, thì đó lại là một câu chuyện hoàn toàn khác. Tại sao phải trả 30 USD mỗi user mỗi tháng cho một bộ SaaS quá cồng kềnh, trong khi sắp tới ngay cả dân vận hành không biết code cũng có thể vibe-code ra một giải pháp custom chỉ trong một cuối tuần?

Lập luận này nghe rất đã tai. Những công ty này sẽ đẩy xu hướng này lên cực hạn. Đây là sân chơi cạnh tranh của những công ty này (nếu bạn để ý những công ty được nhắc tới trong bài của Garry).

Đó là giấc mơ nhỏ xinh của mọi Vibe Coder chưa từng phải bảo trì một codebase legacy lúc 3 giờ sáng ngày thứ Bảy hoặc xuyên đêm và liên tục trong nhiều ngày.

Đó là giấc mơ coi phần mềm chỉ đơn giản là tính năng, là mấy cái nút bấm để ra kết quả. Nếu câu nói đó là sự thật, thì các bạn đã có thể xây Google hay OpenAI chỉ với một chiếc laptop 500 đô. Đây là một kiểu pitch hoàn hảo cho nhà đầu tư.

Đây là giấc mơ tối thượng về hiệu suất, làm việc với cấu trúc mới, và với các công cụ custom hoàn hảo. Cá nhân tôi đã có những giấc mơ như thế này thì thời đi học, từ những chuỗi ngày đầu tiên gõ từng dòng HTML.

Nhưng trong thế giới thực, mọi chuyện chưa bao giờ chỉ xoay quanh việc ai làm nhanh hơn. OpenAI là công ty đầu tiên cho thế giới thấy AI là gì, nhưng tới bây giờ, Google mới là kẻ đang thống trị với việc liên tục ra mắt Gemini 3.0 Pro, Nano Banana Pro, Veo 3.1 và hàng tá các dịch vụ khác.

IV. Thử tìm hiểu vấn đề

Vấn đề thật sự không phải là tốc độ viết code, mà là hệ quả của nó.

Các IDE hoạt động theo kiểu AI-DLC (khái niệm do AWS đặt ra) mang lại tốc độ và đòn bẩy rất lớn, nhưng cũng đi kèm nhiều rủi ro nếu không được kiểm soát chặt chẽ. Các hạn chế chính bao gồm:

• Nợ kỹ thuật (tech debt)
• Lỗ hổng bảo mật
• Đường cong học tập cao (Learning curve)
• Sự phụ thuộc quá mức vào AI:
• và chi phí khó dự đoán

1. Tích tụ nợ kỹ thuật

Mã nguồn do AI sinh ra tuy nhanh nhưng thường thiếu tầm nhìn kiến trúc dài hạn hoặc không tuân thủ đầy đủ các best practices. Nếu không được senior developer review kỹ lưỡng, hệ thống có thể nhanh chóng tích tụ nợ kỹ thuật nghiêm trọng, gây khó khăn cho việc bảo trì và mở rộng về sau.

Yếu tố này thường bị bỏ qua hoặc đánh đổi lấy tốc độ.

2. Lỗ hổng bảo mật

Các công cụ AI có thể đề xuất những pattern mã không an toàn, ví dụ như SQL injection, hard-coded secrets, hoặc thay đổi các đoạn code nhạy cảm về bảo mật mà không có phán đoán của con người về mức độ rủi ro chấp nhận được. Nếu không được validate cẩn thận, nguy cơ bị tấn công hoặc rò rỉ dữ liệu sẽ tăng cao.

Yếu tố này cũng thường bị bỏ qua hoặc đánh đổi lấy tốc độ. Chỉ khi có vấn đề thực sự thì yếu tố bảo mật mới được đem ra mổ xẻ và khắc phục.

3. Nhu cầu giám sát chặt chẽ của con người

AI-DLC đòi hỏi human-in-the-loop ở mọi checkpoint quan trọng. Nếu thiếu sự giám sát này, đội ngũ có thể đi rất nhanh nhưng sai hướng, dẫn đến lỗi lan truyền qua nhiều lớp của hệ thống và khó sửa chữa về sau.

Tại sao tôi nói khó sửa chữa về sau. Có 2 vế:

Vế 1: Lỗi trong hệ thống phần mềm có tính lan truyền, AI giúp làm nhanh nên lan truyền càng nhanh (nếu có lỗi xảy ra)

Lan truyền là một đặc tính tự nhiên. Vì vậy rủi ro lớn nhất không phải là có bug, mà là đến lúc phát hiện thì chi phí sửa cực cao.

Vế 2: Chi phí sửa quy ra số tiền bạn phải trả cho các bên cung cấp dịch vụ AI

Bạn hình dung chi phí sửa như thế này:

• Có thể bạn yêu cầu sửa 1 lỗi đơn giản nhưng AI sẽ viết lại toàn bộ code, nghĩa là chi phí sử dụng (trả tiền cho token) tăng thêm sau mỗi lần sửa 1 lỗi đơn giản. Tôi từng thấy một bạn Product Design sửa nút Next, Previous của slider mà AI phải code lại nhiều lần trong 1 ngày mà vẫn chưa giải quyết được.
• Nếu sai ở quy mô lớn, lan rộng, ăn sâu vào kiến trúc thì Chi phí sửa ở đây là đập đi xây lại một phần hệ thống hoặc cả hệ thống. Rủi ro này nếu tồn tại ở các prototype thì có thể chấp nhận được.

Trong AI-DLC có một thuật ngữ là Context Engineering (cũng xuất phát từ Andrej), khi Context gốc bị mất, không ai nhớ vì sao quyết định đó tồn tại.

Thực ra, Context Engineering không phải là một khái niệm hoàn toàn mới. Đây là sự đồng thuận dần hình thành trong ngành cùng với làn sóng AI Agent năm 2025.

Theo hiểu biết của tôi, đây vẫn là một khái niệm đang thịnh hành nhưng định nghĩa còn mơ hồ. Tuy nhiên, rõ ràng nó sẽ trở thành một kỹ năng quan trọng không thể tránh khỏi trong phát triển AI trong tương lai.

Trong AI-DLC, Context là code. Code có thể refactor, context sai thì phải rewrite toàn bộ. Hay nói đơn giản hơn context yếu thì gần như rất khó sửa hoặc không còn khả năng sửa.

Human oversight trong AI-DLC thực chất là việc giám sát và điều khiển Context, không phải giám sát từng dòng code. Con người không cạnh tranh với AI ở Tốc độ viết code mà sẽ thực thi ở vai trò khác là làm sao "Xác định đúng bài toán".

Vì vậy chi phí sửa (quy ra tiền) ở đây chính là chi phí của một hoặc vài người được ủy quyền làm việc trực tiếp với AI.

4. Nguy cơ suy giảm kỹ năng của lập trình viên

Việc quá phụ thuộc vào AI cho các tác vụ như debug hoặc refactor có thể làm giảm khả năng tư duy giải quyết vấn đề và hiểu sâu code của developer. Khi gặp các issue phức tạp, đội ngũ có thể gặp khó khăn vì thiếu nền tảng kỹ năng cốt lõi.

Đây là sự đánh đổi lớn nhất và sẽ có tác động rõ rệt nhất.

5. Suy giảm ngữ cảnh và thiếu nhất quán

Các cuộc hội thoại dài với AI dễ gặp vấn đề mất ngữ cảnh, khi mô hình quên các quyết định trước đó. Điều này dẫn đến chất lượng code không đồng đều, hoặc buộc phải reset context và bắt đầu lại nhiều lần, gây gián đoạn workflow.

Thực tế tôi đã gặp: team Product Design thiết kế 5-6 features của cùng 1 sản phẩm. Trải qua 3 ngày thì AI mất ngữ cảnh, dẫn đến gây khó khăn trong việc cập nhật 1 thay đổi nhỏ về UX.

Các đặc điểm nổi bật:

• AI phải nhớ bằng token, không nhớ bằng logic
• Khi vượt ngưỡng, AI quên dần quyết định cũ
• Output sau không còn nhất quán với output trước

7. Thiên lệch từ dữ liệu huấn luyện

Những bias tồn tại trong dữ liệu huấn luyện của AI có thể dẫn đến các quyết định tự động không phù hợp với mục tiêu hoặc sai lệch. Đây là một rủi ro nghiêm trọng, đặc biệt với các hệ thống có ảnh hưởng lớn, và cần được theo dõi cũng như giảm thiểu một cách chủ động trong quy trình phát triển.

Rủi ro này cũng đặc biệt nguy hiểm nếu người tham gia làm việc với AI không đủ khả năng phân biệt quyết định của AI ở mức độ nào.

Ngay cả OpenAI cũng thừa nhận rằng thêm dữ liệu và compute không thể loại bỏ hoàn toàn hallucination. Lỗi của AI là điều không thể tránh khỏi.

V. Nhìn vào thực tế

Phần nguy hiểm nhất của phong trào Vibe Coding không nằm ở code tệ, mà ở việc chúng ta dần mất khả năng critical thinking từ não bộ.

Khi bạn dùng AI cho các công việc lặp đi lặp lại, bạn ngừng suy nghĩ về chúng. Bạn chuyển gánh nặng nhận thức cho máy.

Theo thời gian, chuyên môn của bạn bị bào mòn. Bạn trở nên phụ thuộc. Bạn không còn nhận ra khi AI sai.

Các bạn làm chung với tôi có đưa ra chung nhận định: "Em mới vibe code 1 tuần mà cảm giác đầu không suy nghĩ gì được, cảm thấy lười suy nghĩ".

Nếu ai cũng vibe-code theo phong trào, thì sẽ không còn ai thực sự hiểu logic nghiệp vụ vận hành ra sao. Chúng ta đang đánh đổi khả năng thích nghi dài hạn lấy tốc độ ngắn hạn.

Khi model AI thay đổi hoặc hệ thống sập, công ty sẽ hoàn toàn bất lực vì không ai còn nhớ cách lái xe bằng tay.

Ngược lại, chúng ta đều đồng ý một điều: tốc độ xây dựng sản phẩm đã thay đổi vĩnh viễn. AI là một co-pilot tuyệt vời cho những developer hiểu rõ nền tảng. Một senior có thể dùng Vibe Coding như co-pilot. Họ hiểu nguyên lý, họ biết cách

Khi build sản phẩm thực thụ bằng vibe coding, chúng tôi nhận ra rằng, vẫn phải có người thật sự đọc đống code mà robot viết ra. Và có một số thực tế mà chúng tôi rút ra được:

• Vibe coding hay AI-DLC bằng IDE thì nó là một công cụ giúp khuếch đại năng lực của team, chứ không thay thế được nền tảng kiến thức kỹ thuật phần mềm cốt lõi.
• Nếu bạn không nhận ra được kiến trúc do AI định nghĩa, cách xử lý lỗi đúng chuẩn, hay các lỗ hổng bảo mật, thì bạn cũng không thể đánh giá hiệu quả code do AI sinh ra
• Khi hệ thống gặp sự cố trong môi trường production, bạn phải hiểu chuyện gì đã xảy ra và cách khắc phục, bất kể đoạn code đó do ai viết. Cho nên kỹ năng debug vẫn cực kỳ quan trọng.
• Khi AI lo phần chi tiết triển khai, thì khả năng thiết kế hệ thống vững chắc, có khả năng mở rộng và chịu tải mới là giá trị cốt lõi bạn mang lại
• Business logic không thể outsource cho AI. AI không hiểu người dùng của bạn, thị trường của bạn, hay lợi thế cạnh tranh của bạn. Chính những hiểu biết này mới là thứ định hướng cho AI xây dựng đúng sản phẩm.

VI. Vibe Coding Handover

Cho đến lúc này, hy vọng bạn đã hiểu rằng những người thuộc Kiểu A và Kiểu D đang thực sự kiếm được tiền và gia tăng năng suất nhờ vibe coding.

Nhưng hiện nay, các công cụ AI đã trở nên thông minh và chính xác đến mức bạn hoàn toàn có thể là Kiểu B hoặc Kiểu C, mà vẫn kiếm được tiền và tăng năng suất gấp 10 lần. Tuy nhiên, để làm được điều đó, bạn phải học một thứ mới.

Có một điều ngày càng rõ ràng: AI chắc chắn sẽ tồn tại lâu dài và đang thực sự tạo ra tác động lên cuộc sống của con người.

Nhưng, vẫn có một chữ “nhưng”.

Chúng ta cần tận dụng AI cao tay hơn trong quá trình Vibe Coding.

Điểm thay đổi quan trọng đầu tiên không chỉ là build nhanh hơn, mà là build trở nên dễ tiếp cận về mặt tâm lý. Cột mốc đầu tiên không còn là học stack để build thứ gì đó , mà là làm cho thứ đó xuất hiện.

Tốc độ là sản phẩm thật sự ở giai đoạn đầu

Startup sống còn dựa vào việc học nhanh xem khách hàng thực sự muốn gì. Vibe coding nén phần lớn quá trình đó vào vòng lặp thử nghiệm. Những thứ từng mất vài ngày giờ có thể xảy ra trong một buổi chiều.

Điều này thay đổi hoàn toàn tính kinh tế của việc thử nghiệm, vì bạn có thể kiểm tra nhiều hướng đi trước khi commit, và dùng demo chạy được để nhận feedback sắc bén hơn bất kỳ slide deck nào.

Vì prototype sinh ra là để tạm thời

Có một loại phần mềm không được sinh ra để tồn tại lâu dài, mà để trả lời một số câu hỏi cơ bản:

• API này có đáp ứng nhu cầu không?
• User có hiểu workflow này không?
• Có ai thực sự muốn tính năng này không?

Vibe coding tỏa sáng trong bối cảnh này, vì nó tối ưu cho bằng chứng tức thì, chứ không phải cấu trúc dài hạn. Khi mục tiêu là học hỏi chứ không phải trường tồn, khả năng tạo ra rồi bỏ đi nhanh không phải là sự lười biếng hay cẩu thả, mà là chiến lược

Cái bẫy đầu tiên xuất hiện

Nguy hiểm xuất hiện khi một prototype trở nên có vẻ thật (trông như thể user sẽ xài thật trên production) mà chưa từng được verify và xây lại.

Một demo thu hút user, tạo ra hào hứng, hoặc sự ủng hộ nội bộ rất dễ trở thành nền móng cho feature tiếp theo, rồi tiếp theo nữa, và một năm sau nó trở thành sản phẩm.

Đó là lúc vibe coding hangover bắt đầu. Những shortcut kiến trúc ban đầu từ vô hại trở thành giới hạn cấu trúc. Hệ thống vẫn chạy, nhưng mỗi thay đổi đều khó hơn, mong manh hơn, và khó đoán hơn đáng lẽ phải có.

Công việc hàng ngày = Bảo trì

Codebase được sinh ra từ prompt nhanh có thể tích tụ độ phức tạp nhanh hơn tốc độ hiểu biết của con người. Những thay đổi nhỏ có thể lan ra hàng loạt file, vì code được tạo ra như output chứ không phải như một hệ thống được thiết kếtừ trong tư duy của người làm.

Khi vibe code, ban đầu bạn sẽ thấy UI có vẻ đúng ý mình. Khi chưa ưng ý, bạn sẽ sửa bằng prompt, cứ thế qua mỗi lần chưa ứng ý, bạn sẽ nhận được một giao diện theo mong muốn.

Đó là lúc bạn cần hiểu từ khi vibe code, dự án bắt đầu giống như một ngôi nhà có dây điện giấu trong tường. Chạm một công tắc thì năm phòng khác tắt đèn.

Chi phí thay đổi trở nên khó đoán, và chính sự bất định này mới là thứ làm team chậm lại.

Khoảng cách giữa "demo chạy được "và “sản phẩm chạy được"

Lập trình truyền thống xây dựng năng lực thông qua vòng lặp dự đoán và sửa sai. Bạn hình thành mô hình trong đầu, triển khai nó, thấy cái gì gãy, rồi điều chỉnh hiểu biết. Vòng lặp này khó chịu, nhưng chính nó tạo ra trực giác.

Vibe coding có thể phá vỡ vòng lặp đó nếu nó trở thành thói quen outsource việc suy nghĩ, thay vì tăng tốc suy nghĩ. Builder học cách hỏi AI sửa lỗi, thay vì hiểu vì sao lỗi tồn tại. Kết quả là tiến độ trông rất nhanh lúc đầu, nhưng năng lực đứng yên, và vấn đề chỉ lộ ra khi AI không còn giải được bài toán mới đủ nhanh.

Vì sao senior nhanh hơn, còn junior bị kẹt

Engineer dày dạn có thể dùng vibe coding như bộ khuếch đại, vì họ đã biết thế nào là hệ thống tốt, và nhận ra khi AI sai một cách rất tự tin. Họ đọc code nhanh, phát hiện lỗi kiến trúc, và refactor được.

Người ít kinh nghiệm thiếu đi cái la bàn nội tại đó, nên khó đánh giá output có bền vững, dễ bảo trì hay an toàn hay không. Nghịch lý nằm ở chỗ vibe coding khuếch đại chuyên môn rất tốt, nhưng không đảm bảo tạo ra chuyên môn.

Kết luận không phải là “đừng vibe code”, mà là “vibe có trách nhiệm”

Vibe coding cực kỳ mạnh cho việc khám phá, prototype nhanh, và những thứ có thể bỏ đi. Nó trở nên nguy hiểm khi dự án bước sang giai đoạn sở hữu dài hạn, nơi độ tin cậy, bảo mật, và khả năng bảo trì mới là sản phẩm thật.

Cách tiếp cận lành mạnh nhất là hybrid. Dùng vibe coding để chạm nhanh tới các loại prototype chạy được. Khi ý tưởng chứng minh có giá trị, các thực hành engineering có chủ đích sẽ tiếp quản các phần còn lại.

VII. Quy tắc an toàn

Nếu thứ bạn build với mục đích được tạo ra để bỏ đi, vibe coding là siêu năng lực.

Nếu thứ bạn build được tạo ra để tồn tại, vibe coding chỉ nên là bản nháp đầu tiên.

Lợi thế bền vững của phần mềm không nằm ở việc ship được một lần, mà ở khả năng ship liên tục một cách tự tin. Khi mức độ hiểu biết tăng lên, sự do dự trước thay đổi sẽ giảm dần. Vibe coding có thể đưa bạn đến trạng thái chạy được rất nhanh, nhưng chỉ có sự hiểu biết mới giúp bạn xây dựng thứ có thể chạm tới được người dùng.