Vibe coding giúp bạn dựng bản MVP để test thị trường với tốc độ rất nhanh. Nhưng nếu không nhìn nhận kỹ các rủi ro về bảo mật, nghẽn tài nguyên và nợ kỹ thuật để chủ động chuẩn hóa đúng thời điểm, sản phẩm sẽ rất khó sống sót khi đưa vào vận hành thực tế.
Bài 06: Lợi và hại khi vibe coding cùng AI
Trong quá trình tự dựng các công cụ nội bộ và sản phẩm nhỏ suốt hơn một năm qua, mình nhận thấy một thực tế: dùng AI để viết mã nguồn giúp chúng ta đi từ con số không đến một bản chạy được nhanh chưa từng thấy. Nhưng cũng chính tốc độ đó lại là thứ dễ làm chúng ta chủ quan nhất.
Vibe coding không giải quyết được hết mọi bài toán kỹ thuật như nhiều người vẫn nghĩ, nhưng nó cũng không phải thứ đồ chơi chỉ để làm demo. Bản chất vấn đề là công nghệ luôn có hai mặt rõ ràng: cái được (lợi) và cái mất (hại).
Mỗi khi ngồi làm việc với AI để dựng một tính năng hay một sản phẩm mới, mình luôn nhìn nhận kỹ cả hai mặt này.
Mặt lợi: Rút ngắn thời gian ra mắt MVP để test thị trường
Mặt lợi lớn nhất và rõ ràng nhất của vibe coding là tốc độ.
Trước đây, để dựng một webapp có đầy đủ giao diện, database, đăng nhập và luồng xử lý cơ bản, một nhóm phát triển có thể mất từ vài tuần đến cả tháng. Giờ đây với sự hỗ trợ của AI, một người có thể nhanh chóng hoàn thiện một bản dùng thử (MVP) chạy được sau vài buổi làm việc.
Mục tiêu lớn nhất ở giai đoạn này không phải là tạo ra một kiến trúc hoàn hảo, mà là đưa sản phẩm ra môi trường thực tế sớm nhất có thể để đo lường phản hồi của người dùng.
Thay vì mất thời gian ngồi họp bàn hay phỏng đoán nhu cầu thị trường trên giấy, bạn có ngay một bản phần mềm chạy được để kiểm chứng xem người ta có thực sự cần nó hay không. Với những người làm sản phẩm độc lập kiểu indie dev hoặc các team khởi nghiệp nhỏ, đây là một lợi thế cạnh tranh rất lớn.
Mặt hại: Ảo tưởng về năng lực của AI và thực tế vận hành
Việc nhanh chóng có được một sản phẩm chạy được rất dễ tạo ra một thiên kiến tai hại. Nhiều bạn thường nghĩ rằng AI làm được hết rồi, cần gì phải bận tâm đến kỹ thuật hay kiến trúc bên dưới nữa.
Khi thấy ứng dụng chạy trơn tru trên máy cá nhân, chúng ta rất dễ lầm tưởng rằng sản phẩm thế là đã hoàn thiện. Nhưng thực tế, AI chỉ đang giải quyết phần bề nổi — tức là giao diện và các luồng chạy thuận lợi (happy path).
Khi đưa vào vận hành thực tế, code do AI tự sinh thường để lộ ba vấn đề lớn:
1. Thiếu góc nhìn bao quát và rủi ro bảo mật:
AI rất hay sinh code theo prompt của bạn mà không hề chú ý đến mức độ ảnh hưởng (impact) tới tổng thể hệ thống hay tính an toàn dữ liệu.
Khá điển hình là trường hợp bạn báo lỗi ở đâu nó sẽ sửa đúng ngay chỗ đó, chứ không tự rà soát xem những tính năng liên quan có bị ảnh hưởng hay không. Hoặc bạn giao nó làm tính năng A thì nó làm đúng tính năng A để hoàn thành yêu cầu, thay vì phân tích xem tính năng A sẽ tác động tới những luồng dữ liệu nào khác để xử lý cho trọn vẹn.
Thời điểm mình bắt đầu vọc vibe code cũng thế. Lúc đó mình làm cái tool đơn giản thôi là phân tích kỹ thuật (technical analysis - TA) cho cổ phiếu dựa vào các dữ liệu sẵn có. (giờ mình đã phát triển thành 1 tool với nhiều tính năng hơn hẳn: stock-bot)
Ban đầu thấy ứng dụng chạy rất trơn tru, AI dựng cả bảng điều khiển danh mục nhìn rất bắt mắt và báo lãi danh mục lên tới hơn 40%. Nhưng khi mình ngồi rà soát kỹ lại logic kế toán thì mới thấy AI tiện tay mapping nhầm trường ngữ nghĩa giữa vốn ban đầu và lợi nhuận, trong khi thực tế danh mục lúc đó chỉ lãi vỏn vẹn 0.8%.
Chưa kể, khi bảo AI sửa logic kiểm tra dữ liệu, nó viết một hàm cục bộ trong file nạp dữ liệu đè lên bộ điều phối chính, làm hệ thống tự động bỏ qua không cập nhật giá cho hàng loạt mã mà mình không hề hay biết.
Chính vì làm việc cục bộ như vậy, code AI sinh ra rất dễ hớ hênh: để lộ API key hoặc secret token thẳng trong mã nguồn giao diện; chỉ kiểm tra dữ liệu ở phía người dùng mà bỏ quên validate ở backend; hoặc phân quyền lỏng lẻo khiến người dùng chỉ cần thay đổi ID trên thanh địa chỉ là xem hoặc sửa được dữ liệu của người khác (lỗ hổng IDOR).
Cách xử lý thực tế: Không bao giờ nhận code AI nhắm mắt. Với mỗi đoạn code AI sửa, hãy yêu cầu nó giải trình rõ phạm vi ảnh hưởng tới các file khác, và bắt buộc kiểm tra lại luồng phân quyền ở backend.
2. Khó mở rộng và nghẽn tài nguyên:
Code do AI viết thường chạy mượt khi chỉ có một vài người truy cập thử nghiệm. Nhưng nó thường thiếu cơ chế kiểm soát ngoại lệ, xử lý bất đồng bộ sơ sài dễ gây tranh chấp dữ liệu (race condition).
Khi dữ liệu bắt đầu phình to hoặc lượng người dùng đồng thời tăng lên (CCU tăng), hệ thống rất dễ bị nghẽn nếu AI viết các truy vấn database lồng bên trong vòng lặp hoặc bỏ quên việc đánh index cho các bảng dữ liệu chính.
Như trường hợp công cụ phân tích cổ phiếu của mình: khi chỉ chạy thử vài chục mã trên máy cá nhân thì rất mượt, nhưng khi mở rộng quét hơn 1.800 mã toàn thị trường với hàng triệu dòng dữ liệu nến, máy tính lập tức dính lỗi tràn bộ nhớ và treo cứng tiến trình chạy ngầm. AI còn tự động gọi API phân tích tin tức lặp đi lặp lại khiến tài khoản chạm trần hạn mức chi phí chỉ sau một đêm.
Cách xử lý thực tế: Đặt ngưỡng cảnh báo tài nguyên máy chủ, luôn chủ động rà soát các câu lệnh truy vấn database và đặt hạn mức chi phí (quota limit) cho các dịch vụ bên thứ ba để tránh tình trạng tài khoản bị trừ tiền ngoài tầm kiểm soát.
3. Code chắp vá và khó bảo trì lâu dài:
Ở thời điểm đang ngồi làm, gặp lỗi gì bạn gửi tiếp cho AI thì nó sửa rất nhanh. Nhưng sau vài tuần quay lại hoặc khi cần mở rộng thêm tính năng mới, bạn sẽ thấy codebase rơi vào tình trạng chắp vá như một căn nhà lắp ghép vội.
Cùng một bài toán xử lý dữ liệu nhưng mỗi file lại được AI viết theo một cấu trúc khác nhau. Vì người làm không thực sự nắm rõ luồng dữ liệu từ đầu đến cuối, việc sửa một chỗ làm phát sinh lỗi ở ba chỗ khác là điều rất thường gặp.
Cách xử lý thực tế: Sau mỗi chu kỳ prompt thành công một tính năng, hãy yêu cầu AI tổng hợp lại luồng dữ liệu và viết chú thích rõ ràng cho các hàm cốt lõi trước khi chuyển sang việc tiếp theo.
Vậy chúng ta nên làm gì?
Hiểu rõ hai mặt lợi và hại không phải để bài trừ vibe coding, mà là để biết cách kiểm soát nó phục vụ cho công việc.
Theo những gì đã làm thì mình có một vài kinh nghiệm như sau:
1. Đưa sản phẩm cho nhóm nhỏ kiểm chứng thực tế
Đừng ngồi ngắm sản phẩm trên máy hay vội vàng viết thêm quá nhiều tính năng. Ngay khi có bản MVP dùng được, bạn nên gửi ngay cho một nhóm nhỏ gồm khách hàng tiềm năng, đồng nghiệp hoặc bạn bè để kiểm tra.
Ở giai đoạn này, cách hiệu quả nhất là quan sát trực tiếp người dùng thao tác hoặc hỏi thẳng phản hồi của họ:
- Sản phẩm có giải quyết đúng nhu cầu cốt lõi không?
- Trải nghiệm thao tác có dễ hiểu không?
- Tính năng chạy thực tế có ổn định không hay phát sinh lỗi?
- Luồng sử dụng từ đầu đến cuối có bị vướng ở bước nào không?
Đây mới là những thứ bạn nên quan tâm đầu tiên.
Tuy nhiên, có một nguyên tắc bắt buộc: dù làm nhanh để thử nghiệm, bạn tuyệt đối không được phép bỏ qua các lớp bảo vệ cốt lõi ngay từ ngày đầu. Đó là không để lộ API key hay secret token, bắt buộc kiểm tra dữ liệu ở backend, và bảo vệ an toàn cho thông tin cá nhân của người dùng.
2. Thiết lập vòng lặp phản hồi liên tục
Sau khi gửi bản thử nghiệm đi, bạn sẽ nhận về rất nhiều góp ý thực tế. Lúc này, hãy tận dụng đúng thế mạnh của AI để tạo thành một vòng lặp: tiếp nhận phản hồi, yêu cầu AI tinh chỉnh và sửa lỗi, sau đó gửi lại để người dùng thử tiếp.
Cứ lặp lại như vậy cho đến khi sản phẩm chạy ổn định và giải quyết đúng nhu cầu của nhóm người dùng thử nghiệm.
3. Nhận diện tín hiệu để bắt đầu chuẩn hóa hệ thống
Bạn không thể giữ cách làm tạm bợ này mãi. Tín hiệu rõ ràng nhất để bạn dừng giai đoạn làm nhanh và bắt tay vào chuẩn hóa hệ thống là: khi có khách hàng trả tiền đầu tiên, khi người dùng thực tế bắt đầu quay lại sử dụng đều đặn sau tuần đầu, hoặc khi khối lượng dữ liệu phình to vượt ngưỡng chịu tải của máy cá nhân.
Như trường hợp dự án phân tích cổ phiếu của mình, khi dữ liệu tích lũy phình to lên hơn 6 triệu bản ghi và cần hệ thống chạy tự động ổn định sau mỗi phiên đóng cửa sàn, mình buộc phải dừng cách làm chắp vá để chuyển sang giai đoạn chuẩn hóa:
- Tách bạch rõ môi trường, đưa toàn bộ ứng dụng lên máy chủ Docker Linux thay vì chạy các script rời bằng công cụ lập lịch trên máy cá nhân.
- Chuyển sang cơ sở dữ liệu PostgreSQL bài bản, đánh index cho các bảng dữ liệu lớn và chuẩn hóa cấu trúc dữ liệu.
- Tách riêng các luồng: container cơ sở dữ liệu, container API và luồng xử lý dữ liệu ngầm độc lập.
- Rà soát lại toàn bộ các endpoint backend, kiểm tra chặt chẽ việc phân quyền và xác thực người dùng.
4. Chuẩn hoá quy trình làm việc
Để tránh làm việc "vô tổ chức" thì cá nhân mình khuyên là nếu bạn đã xác định đc ý tưởng và có ý định làm nghiêm túc (dù là trước hay sau phase mvp) thì nên làm một các chuẩn chỉ. Vibe coding không có nghĩa mình sẽ bỏ qua hết các quy trình trong phát triển phần mềm, nó chỉ đơn giản là mình làm các quy trình này nhanh hơn mà tôi. Chúng ta vẫn nên làm 1 cách có hệ thống từ tài liệu thiết kế, danh sách tính năng, quy trình chính của hệ thống...tới các test case... để khi các bạn maintain hoặc enhance các tính năng thì không chỉ bạn mà cả agent nó đọc lại context dự án để làm cũng sẽ tiện hơn rất nhiều.
Trách nhiệm của người làm sản phẩm
Vibe coding cùng AI giúp chúng ta rút ngắn đáng kể khoảng cách từ một ý tưởng đến một sản phẩm chạy được ngoài đời.
Nhưng AI chỉ là công cụ hỗ trợ thực thi. Sự an toàn, tính ổn định và khả năng sống sót của sản phẩm ngoài đời thực hoàn toàn phụ thuộc vào sự tỉnh táo và trách nhiệm giải trình của chính bạn.
Tận dụng tốc độ của AI để kiểm chứng ý tưởng nhanh, nhưng phải luôn giữ quyền kiểm soát kiến trúc và chủ động chuẩn hóa hệ thống đúng thời điểm — đó mới là cách làm bền vững.
