Gần đây, ai cũng đang nói về “vibe coding” (lập trình theo cảm hứng). Nếu bạn chưa từng nghe đến khái niệm này thì… bạn đang sống dưới tảng đá nào vậy?
Mọi người cũng đang bàn tán về việc vibe coding tuyệt vời như thế nào. À mà cũng có người bảo là nó tệ kinh khủng.
Nhưng nếu chúng ta có thể tận dụng được cả hai mặt tốt nhất của nó thì sao? Xin giới thiệu: phương pháp mà tôi gọi là “vibe-but-verify coding” — cảm hứng có kiểm chứng.
Có gì sai với Vibe Coding?
Với những ai “sống dưới hang đá”, vibe coding là khi bạn “quên luôn đoạn code tồn tại” và để AI tự làm hết mọi việc. Bạn bảo nó làm điều gì đó, và nó làm, (lý thuyết là) tốt và nhanh hơn bạn.
Vấn đề là: khi nó không làm được việc, hoặc làm theo cách ngớ ngẩn. Cả lập trình viên và người không biết code đều sẽ gặp khó khăn khi AI tự đẩy mình vào vòng lặp lỗi hoặc liên tục phá hỏng những chức năng vốn đang hoạt động tốt — và không bao giờ hoàn thiện được 30% cuối của dự án.
Có thể chia vấn đề của vibe coding thành ba nhóm chính:
- AI không làm đúng điều bạn muốn.
- AI làm đúng điều bạn muốn, nhưng làm hỏng những thứ đang hoạt động.
- AI làm đúng điều bạn muốn, nhưng theo cách nguy hiểm hoặc gây lỗi cho một số người dùng.
Vibe-but-verify ra đời để khắc phục các vấn đề trên mà vẫn giữ được tính linh hoạt và khả năng của AI.
Giới thiệu “Vibe-but-Verify Coding”
Hãy xem vibe-but-verify coding như một hình thức lai giữa lập trình truyền thống và vibe coding.
Ý tưởng là con người (tức là bạn) sẽ viết các bài kiểm thử tự động để xác minh rằng đoạn code do AI viết thực sự làm đúng chức năng như mong muốn.
Trong vibe coding, có một quy tắc:
- Bỏ qua code sản phẩm; để AI viết hết.
Nhưng trong vibe-but-verify coding thì lại có hai quy tắc:
- Bỏ qua code sản phẩm; để AI viết hết.
- Tự bạn viết phần kiểm thử; không cho AI đụng vào.
Bằng cách này, bạn buộc đầu ra không xác định của AI trở nên có kiểm soát, ít nhất ở những phần quan trọng. Bạn có thể viết nhiều loại test khác nhau để kiểm tra các yếu tố như bảo mật, hiệu năng, đúng chức năng… và để phần còn lại cho AI.
Nói cách khác, bạn đảm bảo AI làm đúng việc, làm đúng cách và tiếp tục làm đúng về sau — vì đó vốn dĩ là mục đích của kiểm thử tự động.
Làm thử một ví dụ
Trước tiên, bạn nên nói rõ với AI rằng đừng động vào phần kiểm thử, dù trong prompt hay thông qua các rule ở Cursor/Windsurf.
Ví dụ, tôi có một dòng rule trong Cursor như sau:
Do not edit any tests.
(Đừng chỉnh sửa bất kỳ bài test nào.)
Một hình thức của vibe-but-verify coding là viết test trước, sau đó yêu cầu AI viết code sao cho pass được các test đó — bạn có thể gọi là Test-Driven AI Development (nếu bạn là dân nerd chính hiệu).
Ví dụ, dưới đây là bài kiểm thử tôi viết trong một project nhỏ:
import { expect, test } from "@playwright/test" test("renders correctly", async ({ page }) => { await page.goto("./") await expect(page).toHaveTitle("Competition Helper") await expect(page.getByRole("heading", { name: "Competition Helper" })).toBeVisible() await expect(page.getByRole("textbox", { name: "Media URL" })).toBeVisible() await expect(page.getByRole("spinbutton", { name: "Run Length (seconds)" })).toBeVisible() await expect(page.getByRole("spinbutton", { name: "Lead-up Time (seconds)" })).toBeVisible() await expect(page.getByRole("spinbutton", { name: "Reminder Time (seconds before end)" })).toBeVisible() await expect(page.getByRole("button", { name: "Start" })).toBeVisible() await expect(page.getByRole("button", { name: "Reset" })).toBeVisible()
})
Sau đó, tôi nói với AI:
“Implement the changes necessary to make the tests pass” (Hãy thực hiện các thay đổi cần thiết để các bài test này pass)
Và nó đã làm được.
Phải thành thật mà nói, tôi hơi bất ngờ và khá phấn khích khi thấy điều này hoạt động ngay từ lần đầu.
Với những bài test phức tạp hơn, có thể sẽ cần chỉnh sửa thêm, nhưng quy trình và kết quả cơ bản vẫn giữ nguyên.
Bạn cũng có thể thêm một rule khác như:
“After making changes, run the tests again. If they don’t pass, fix it.” (Sau khi sửa đổi, hãy chạy lại các bài test. Nếu chưa pass, hãy sửa tiếp.)
Như bạn thấy, với cách tiếp cận này, bạn đang xây dựng một bản đặc tả tính năng có kiểm chứng. Khi test pass, bạn biết chắc là chức năng đã hoàn tất.
Và đây cũng là lý do không nên để AI viết phần kiểm thử — chẳng khác nào “người mù dắt người mù”. AI không nên tự quyết định mình cần làm gì — đó là việc của con người (ít nhất là cho đến khi AI nổi dậy).
To Infinity and Beyond
Nếu vibe coding có thể đưa bạn từ “zero đến prototype” chỉ trong vài phút, thì vibe-but-verify có thể đưa bạn vượt qua cái mốc 30% cuối ấy.
Có thể đây chính là cách nên làm — con người và AI hợp tác trong một mối quan hệ cộng sinh để tạo ra những thứ mà cả hai không thể làm một mình.
Vậy còn những người không biết lập trình — nhóm người vốn là đối tượng chính của vibe coding thì sao? Họ bị bỏ lại sao? Có thể là không. Có thể kiểm thử tự động không nhất thiết phải viết bằng code. Có thể trong tương lai sẽ có công cụ mới để đáp ứng nhu cầu đó mà không cần biết lập trình.
Dù điều gì xảy ra, hãy nhớ rằng: công nghệ mới chỉ tồn tại khoảng 0% lịch sử nhân loại (làm tròn xuống). Tất cả những thứ này đều vô cùng mới mẻ. Không ai biết tương lai sẽ ra sao.
Cảm ơn các bạn đã theo dõi!