Rào cản đã sụp đổ thật … nhưng sụp đổ đến đâu

Cụm từ "Vibe Coding" ra đời từ một bài đăng của Andrej Karpathy trên X vào tháng 2/2025, ông mô tả nó là trạng thái "hoàn toàn buông mình theo cảm giác, chấp nhận tăng tốc phát triển ứng dụng theo cấp số nhân, và quên rằng code vẫn đang tồn tại ở đó". Chưa đầy hai năm sau, chính Karpathy là người đầu tiên rút lại thuật ngữ của mình: tháng 4/2026, tại sự kiện AI Ascent của Sequoia Capital, ông tuyên bố Vibe Coding đã lỗi thời, thay bằng khái niệm "kỹ thuật thiết kế hệ thống tác nhân tự chủ" (agentic engineering), một kỷ luật khó hơn nhiều so với hình ảnh "thư giãn, gõ vài câu là xong" ban đầu. Đến tháng 12/2025, chính ông thừa nhận 80% code của mình là do AI tạo ra nhưng đó là kết quả của một quy trình kiểm soát chặt, không phải kiểu "chấp nhận mọi thay đổi mà không xem qua" như định nghĩa gốc.

Điều đó cho thấy một điều quan trọng: ngay cả người tạo ra thuật ngữ cũng đã đi từ "làm cho vui, dự án xong rồi bỏ đi cũng được" sang "một kỹ thuật làm việc theo kỷ luật thật sự" chỉ trong 14 tháng. Nếu người trong cuộc còn phải điều chỉnh nhanh như vậy, thì bức tranh "một ý tưởng, một tài khoản AI, một server vài đô là đủ để ra sản phẩm" vốn đang lan truyền rộng rãi trong cộng đồng chỉ đúng ở giai đoạn “từ 0 - 1” (tức chưa có gì đến hình thành sản phẩm). Nó không nói về việc sản phẩm đó có sống được hay không.

Vì sao "làm ra được sản phẩm" không còn là chiến thắng

Dữ liệu về thất bại của startup cho thấy một mẫu hình đáng chú ý, dù không phải mới. Theo phân tích của CB Insights trên hàng trăm bản mổ xẻ nguyên nhân thất bại của startup (post-mortem) do chính các nhà sáng lập viết, lý do được nêu nhiều nhất với 42% là "không có nhu cầu thị trường thật sự", bỏ xa lý do đứng thứ hai là "hết tiền" (29%). Con số này được nhiều đơn vị nghiên cứu độc lập trích dẫn lại nhất quán trong nhiều năm.

Điều đáng nói: 42% này được đo trên các startup nói chung, từ thời trước khi Vibe Coding tồn tại, tức là ngay cả khi việc "làm ra sản phẩm" từng tốn nhiều công sức, tốn tiền, tốn thời gian, thì nguyên nhân thất bại phổ biến nhất vẫn không nằm ở khâu xây dựng sản phẩm. Giờ khi rào cản đó gần như biến mất, trực giác cho thấy tỷ trọng của nguyên nhân "không ai cần" sẽ còn lớn hơn nữa vì việc từng khiến người ta phải suy nghĩ kỹ trước khi bắt tay vào làm (chi phí, thời gian) không còn đóng vai trò bộ lọc tự nhiên. Ai cũng có thể làm ra một prototype trong một buổi chiều, kể cả khi chưa ai hỏi liệu có ai cần nó không.

Ra mắt lần đầu là đỉnh cao của sản phẩm, hàng loạt sản phẩm Vibe Coding có biểu đồ commit dày đặc trong tuần ra mắt, sau đó im lặng hoàn toàn. Không phải vì tác giả lười hay kém năng lực. Vấn đề là không ai dạy họ phải làm gì sau khi sản phẩm chạy được, mọi nội dung hướng dẫn làm sản phẩm AI hiện có đều dừng lại đúng ở thời điểm ra mắt.

Vì sao sản phẩm AI không có khái niệm "hoàn thành"

Đây là khác biệt giữa sản phẩm AI và sản phẩm truyền thống. Phần mềm truyền thống có hành vi được viết cứng: bạn viết if-else, nó chạy đúng như vậy một triệu lần liên tiếp. Sản phẩm AI thì khác, hành vi của nó là kết quả lấy mẫu từ một phân phối xác suất tại thời điểm chạy. Phân phối đó dịch chuyển liên tục: khi cách người dùng đặt câu hỏi thay đổi, khi cơ sở tri thức thay đổi, và quan trọng nhất là khi nhà cung cấp mô hình âm thầm cập nhật mô hình AI bạn đang sử dụng.

Đây không phải suy đoán. Một nghiên cứu của các nhà khoa học tại Stanford và UC Berkeley (Chen, Zaharia, Zou - "How Is ChatGPT's Behavior Changing over Time?", 2023) đã đo trực tiếp hiện tượng này bằng cách so sánh cùng một phiên bản model được gọi qua API ở hai thời điểm cách nhau ba tháng. Kết quả đáng kinh ngạc: độ chính xác của GPT-4 khi xác định một số có phải số nguyên tố hay không giảm từ khoảng 84% (tháng 3/2023) xuống còn khoảng 51% chỉ ba tháng sau, do mô hình không còn tuân theo kiểu suy luận từng bước (chain-of-thought) như trước. Tỷ lệ code do GPT-4 sinh ra có thể chạy được ngay cũng giảm mạnh, một phần chỉ vì mô hình bắt đầu tự động thêm dấu ba nháy trước và sau đoạn code, một thay đổi định dạng nhỏ nhưng đủ gây lỗi cú pháp hàng loạt cho những hệ thống đang tự động hoá việc chạy code đó. Nhóm nghiên cứu gọi hiện tượng này là bằng chứng cho thấy hành vi của "cùng một" dịch vụ LLM có thể thay đổi đáng kể trong một khoảng thời gian ngắn và kết luận rằng việc giám sát liên tục là điều bắt buộc, không phải tuỳ chọn.

Nói cách khác: ngay cả khi bạn không đụng vào một dòng Prompt nào, sản phẩm của bạn vẫn có thể "hỏng" theo thời gian, chỉ vì nhà cung cấp mô hình cập nhật sau lưng bạn. Đây là lý do vì sao khái niệm "sản phẩm AI hoàn thành, đóng gói, bàn giao" vốn đúng với phần mềm truyền thống không còn đúng ở đây.

Ba công việc diễn ra sau ngày ra mắt sản phẩm

Ba việc này không làm lần lượt mà làm song song, cùng lúc.

1. Tracking: Biến hành vi người dùng thành dữ liệu có ý nghĩa

Sai lầm phổ biến nhất: trông chờ vào nút "không hài lòng" (dislike). Tỷ lệ người dùng chủ động bấm nút này thấp đến mức không có ý nghĩa thống kê — phản ứng đầu tiên của một người dùng thất vọng không phải là chấm điểm, mà là đóng tab. Tín hiệu thật sự có giá trị đều là tín hiệu bị động, không cố ý:

Đừng trông chờ vào nút “Thích / Không thích”, "Chấm điểm ứng dụng". Tỷ lệ người dùng chủ động bấm nút này thấp đến mức không có ý nghĩa thống kê, người dùng thất vọng thì họ đóng tab đi luôn, chứ không ngồi chấm điểm cho bạn. Muốn biết chỗ nào chưa hoạt động, nhìn vào 4 dấu hiệu này:

• Người dùng thử lại/hỏi lại nhiều lần (re-asking): người dùng đổi cách diễn đạt để hỏi lại đúng vấn đề cũ. Đây là tín hiệu thất bại mạnh nhất vì nó hoàn toàn vô thức.

• Viết lại câu hỏi (rewriting): người dùng chia nhỏ câu hỏi, thêm điều kiện chi tiết, … cho thấy câu trả lời đầu quá chung chung.

• Bỏ giữa chừng: đang luồng ứng dụng / tạo câu trả lời thì người dùng tắt ngang.

• Có sử dụng kết quả: Có tải về kết quả? Câu trả lời có được copy đi dùng hay không. Hệ thống bạn thông minh, tiên tiến đến đâu mà kết quả không sử dụng được cũng vô ích

Việc phân loại thất bại phải theo nguyên nhân, không theo module tính năng, đây là điểm khác biệt căn bản với QA phần mềm truyền thống, vì cùng một triệu chứng (câu trả lời sai) có thể do năm nguyên nhân hoàn toàn khác nhau: lỗi Prompt, lỗi truy xuất (retrieval không tìm đúng tài liệu), ngữ cảnh bị cắt, giới hạn năng lực thật sự của mô hình, hoặc quan trọng nhất, đây không phải lỗi, mà là người dùng đang tự nói cho bạn biết sản phẩm nên làm thêm tính năng gì.

Mỗi trường hợp phát sinh lỗi phải được chuyển thành một mẫu kiểm thử có thể chạy lại được để tìm ra lỗi: đầu vào là gì, hành vi kỳ vọng là gì, tiêu chí đánh giá là gì. Làm được bước này, vài trăm case tích luỹ lại trở thành một bộ đánh giá riêng (private benchmark), thứ không đối thủ nào copy được, vì nó là quá trình tích lũy theo thời gian: họ bắt đầu hôm nay thì cũng cần ba tháng mới đuổi kịp lượng dữ liệu bạn có hôm nay.

2. Iteration: Biết khi nào nên sửa, và sửa ở mức độ nào

Sai lầm phổ biến nhất: Sửa Prompt “case by case” - Sửa đến lần thứ 30, Prompt trở thành một văn bản dài hai nghìn từ mà không dám xoá dòng nào vì không biết dòng nào đang thật sự có tác dụng. Nguyên tắc cần giữ: chỉ sửa khi một nhóm nguyên nhân lỗi tích luỹ đủ số lượng để xác nhận đó là một loại thường gặp, không sửa cho một case đơn lẻ.

Và trước khi sửa, cần phân biệt 2 loại vấn đề:

• Sửa được bằng Prompt: Vấn đề về cách diễn đạt, định dạng, giọng điệu. Tức AI biết cách làm, chỉ là chưa làm đúng ý bạn.

• Sửa Prompt không giải quyết được: Cần thêm công cụ mới, cần chia nhỏ thành nhiều bước, cần thêm nguồn tra cứu, cần người can thiệp. Tức AI là không có đủ thông tin hay khả năng để tự làm trong một lần.

Một cách tự kiểm tra đơn giản: nếu bạn phải viết cả một đoạn giải thích dài trong Prompt để "dạy" mô hình quy trình làm việc - cách suy luận, đó gần như chắc chắn là vấn đề cấu trúc, không phải vấn đề Prompt.

3. Model: Theo dõi AI chạy nền có tự thay đổi hay không

Đây là việc dễ bỏ qua nhất, vì như phần trên đã dẫn chứng, hành vi mô hình có thể thay đổi ngay cả khi bạn không làm gì. Sản phẩm vẫn có thể tự nhiên "hỏng" theo thời gian, chỉ vì bên cung cấp AI âm thầm cập nhật mô hình.

Vì vậy, bộ bài test bạn gom được ở bước 1 không chỉ chạy khi bạn sửa gì đó — mà nên chạy định kỳ, kể cả khi không đổi gì, để phát hiện sớm nếu có gì tự thay đổi ngoài ý muốn.

Khi cân nhắc đổi mô hình, điều quan trọng không phải là điểm số trên bảng xếp hạng công khai (benchmark chung đo năng lực tổng quát, không phải năng lực trong đúng use case của bạn), mà là hiệu năng trên chính bộ case riêng của bạn — và đặc biệt là xem chênh lệch hành vi nằm ở đâu, vì mô hình mới có thể mạnh hơn tổng thể nhưng lại yếu hơn đúng ở loại case quan trọng nhất với bạn.

“Nợ kỹ thuật” khi Vibe Coding bùng nổ ở giai đoạn này

Đây là điều đáng lo nhất với người tự làm sản phẩm một mình.

Báo cáo GenAI Code Security Report 2025 của Veracode, phân tích 80 tác vụ lập trình chuẩn hoá trên hơn 100 mô hình ngôn ngữ lớn cho thấy AI chọn phương án viết code không an toàn trong 45% trường hợp khi có lựa chọn giữa cách viết an toàn và không an toàn. Đáng lo hơn: hiệu năng bảo mật này không cải thiện theo thời gian dù các mô hình mới liên tục sinh code chính xác hơn về mặt cú pháp và logic. Giám đốc công nghệ của Veracode, Jens Wessling, nhận định thẳng: bản chất của Vibe Coding, nơi lập trình viên phó thác cho AI mà thường không nêu rõ yêu cầu bảo mật đồng nghĩa với việc để mô hình tự quyết định thay cho mình, và mô hình chọn sai gần một nửa số lần.

Nói cách khác: lúc mới làm sản phẩm, AI viết code giúp bạn, bạn đọc hiểu từng dòng nhưng không hiểu tại sao nó viết như vậy. Mọi thứ vẫn ổn cho tới khi có người dùng thật gặp lỗi, bạn mở code ra sửa mới phát hiện mình không biết bắt đầu từ đâu, và có thể đang ngồi trên một lỗ hổng bảo mật mà chính mình không hay biết.

Điều gì trong sản phẩm AI của bạn là không thể sao chép

Cách thử: Chụp một tấm ảnh màn hình sản phẩm của bạn, đưa cho một người cùng ngành. Xem họ copy được bao nhiêu?

Sự thật là: gần như mọi thứ nhìn thấy được đều có thể copy. Cách bạn ra lệnh cho AI (Prompt) chỉ cần hỏi khéo vài câu là "câu" ra được, đây là mẹo ai cũng biết. Cách sản phẩm bạn hoạt động bên trong (dùng mấy bước, gọi công cụ gì) người rành nghề soi ra không quá nửa ngày. Các mô hình AI thì ai cũng gọi được qua API. Giao diện thì copy trong một vài dòng lệnh là xong.

Chỉ có hai thứ không nằm trong tấm ảnh chụp màn hình, và cũng là hai thứ duy nhất không copy được:

1. Kho dữ liệu của riêng của bạn, những cuộc hội thoại thật, bằng chính ngôn ngữ của người dùng thật, trong đúng use case của bạn. Nó đặc thù theo bối cảnh, và được tích lũy qua thời gian: đối thủ bắt đầu tích luỹ hôm nay thì vẫn cần đúng khoảng thời gian bạn đã bỏ ra mới đuổi kịp lượng dữ liệu bạn có ở hiện tại.

2. Tốc độ vận hành không phải sự chăm chỉ, mà là một cơ chế. Một đội có ba tuyến việc chạy song song phát hiện vấn đề tự động, quy nguyên nhân có phân loại, xác định sửa lỗi tự động - một vòng lặp có thể rút xuống còn một ngày. Đội không có hệ thống: chờ người dùng than phiền, đoán mò nguyên nhân, gõ thử vài câu xem đã hết lỗi chưa dẫn đến một vòng sửa lỗi mất cả tuần, mà chưa chắc sửa đúng. Chênh lệch 1 tuần với 1 ngày, chạy suốt 1 năm, là chênh lệch cực lớn số lần được sửa lỗi. Và cái này còn lợi kép: mỗi lần sửa xong không chỉ hết 1 lỗi, mà còn thêm 1 kinh nghiệm, thông tin vào kho dữ liệu giúp lần sửa tiếp theo nhanh hơn nữa.

Vậy các tập đoàn lớn thì sao? Nhiều người, nhiều tiền, tự có mô hình riêng, không lẽ vòng lặp tự vá lỗi, tự phát triển còn nhanh hơn?" Câu trả lời: tốc độ sửa lỗi không phụ thuộc vào bạn có bao nhiêu người hay bao nhiêu tiền, mà phụ thuộc vào đường đi từ lúc phát hiện lỗi đến lúc sửa xong ngắn hay dài.

Công ty lớn giỏi ở việc làm AI mạnh hơn, công cụ nhiều hơn, đó là thế mạnh chung. Nhưng người dùng của bạn sẽ hỏi những câu rất riêng, chỉ có trong đúng sản phẩm của bạn, công ty lớn không có thông tin đó, vì đó không phải khách của họ. Với đội ngũ nhỏ như bạn: thấy lỗi buổi sáng, sửa xong buổi trưa, đưa lên dùng luôn trong ngày. Công ty lớn cũng với phần việc tương tự nhưng phải qua duyệt tài liệu, thử nghiệm từng phần, qua nhiều team phối hợp mất nhiều ngày hơn.

Nên hào chắn không nằm ở việc bạn giỏi hơn công ty lớn nói chung, mà ở việc trong đúng mảnh sân nhỏ của mình, bạn xoay chuyển nhanh hơn bất kỳ ai. Nhưng điều này chỉ đúng khi bạn thật sự làm 3 việc ở trên, không phải kiểu "ra mắt trước, tính sau". Việc ghi lại hành vi người dùng, lập bộ bài test, phân loại nguyên nhân lỗi — phải làm ngay từ lúc mới bắt đầu. Để sau mới làm, 3 tháng dữ liệu quý giá nhất đã mất, hoặc lưu thiếu, không dùng được.

Chứng minh năng lực trong thời đại AI

Viết trong hồ sơ xin việc "tôi từng làm một sản phẩm AI" giờ không còn gây ấn tượng gì nữa. Vì AI giúp việc làm ra một cái demo quá dễ, ai cũng có một cái để kể.

Câu hỏi thật sự để phân biệt đẳng cấp là: sau khi ra mắt, bạn đã sửa qua bao nhiêu phiên bản, và mỗi lần vì sao?

Người trả lời được sẽ kể ra được: phiên bản thứ ba vì phát hiện một nhóm người dùng cứ hỏi lại cùng một việc, quy nguyên nhân thì phát hiện do truy xuất không tìm đúng tài liệu, thêm một tầng viết lại truy vấn, tỷ lệ hỏi lại giảm từ bao nhiêu xuống bao nhiêu.

Điều hay ở đây: bạn không cần một sản phẩm hoành tráng mới có kinh nghiệm thật sự quý giá. Một sản phẩm chỉ có 100 người dùng thôi, nhưng bạn bám sát đúng 100 người đó, lắng nghe và sửa liên tục suốt 6 tháng, kinh nghiệm bạn có được vẫn nhiều hơn hẳn người làm ra 10 cái demo rồi bỏ hết, chẳng cái nào đi đến đâu.

Kết luận

Bài đăng ra mắt sản phẩm của bạn không phải điểm kết, mà chỉ mới là điểm bắt đầu.

Câu hỏi quan trọng không phải "bạn đã làm ra sản phẩm gì". Mà là: bao giờ bạn viết bài đăng thứ hai, bài nói rằng "Sau 3 tháng lắng nghe người dùng thật, tôi đã cập nhật thêm những gì"?

Nguồn tham khảo

• Andrej Karpathy, bài đăng gốc về "vibe coding" trên X, tháng 2/2025; và phát biểu tại sự kiện AI Ascent (Sequoia Capital), tháng 4/2026 về khái niệm kế nhiệm "agentic engineering".

• CB Insights, phân tích nguyên nhân thất bại của startup dựa trên các bản mổ xẻ (post-mortem) do nhà sáng lập công bố — "không có nhu cầu thị trường" chiếm 42%, dẫn đầu danh sách.

• Lingjiao Chen, Matei Zaharia, James Zou (Stanford University, UC Berkeley), "How Is ChatGPT's Behavior Changing over Time?", arXiv:2307.09009, 2023.

• Veracode, 2025 GenAI Code Security Report - phân tích 80 tác vụ lập trình trên hơn 100 mô hình ngôn ngữ lớn, công bố 30/07/2025.