Hướng dẫn vibe coding hiệu quả: từ ý tưởng đến sản phẩm chạy được mà không đánh đổi chất lượng

Vibe coding đã đi từ một câu đùa trên mạng xã hội thành cách làm việc thật của nhiều người, từ chủ doanh nghiệp tự dựng công cụ nội bộ đến lập trình viên giao việc nhàm chán cho tác tử AI. Câu hỏi thực tế không còn là "có nên dùng không" mà là "dùng đến đâu thì an toàn, và làm thế nào để vừa nhanh vừa không tạo ra một đống mã không ai dám sửa".

Bài này gom lại định nghĩa, cách chọn mức rà soát theo rủi ro, một vòng lặp làm việc 6 bước, cách viết yêu cầu, cách giữ ngữ cảnh gọn, danh sách kiểm tra bảo mật và các sai lầm hay gặp.

Phần hướng dẫn thao tác dựa trên tài liệu chính thức về thực hành tốt nhất của Claude Code (Anthropic) và các bài viết của Simon Willison; công cụ cụ thể có thể khác, nhưng nguyên tắc dùng được cho Cursor, Copilot, Codex hay bất kỳ tác tử lập trình nào.

Điểm chính

• Vibe coding nghĩa hẹp là xây phần mềm bằng AI mà không đọc mã nó viết ra. Khi bạn đọc, kiểm thử và hiểu mã, đó là kỹ thuật phần mềm có AI hỗ trợ. 2 cách làm khác nhau về mức rà soát, và mức nào hợp là do rủi ro quyết định.
• Thử nghiệm cá nhân có thể rà ít. Công cụ nội bộ cần rà phần quyền và dữ liệu. Sản phẩm cho khách hàng cần rà từng thay đổi, kiểm thử tự động và kiểm tra bảo mật.
• Mẹo quan trọng nhất: cho tác tử một cách tự kiểm tra (kiểm thử, lệnh build, ảnh chụp màn hình). Không có kiểm tra tự động, bạn trở thành vòng lặp kiểm chứng duy nhất.
• Ngữ cảnh của tác tử đầy rất nhanh và chất lượng giảm khi đầy. Làm từng việc nhỏ, dọn ngữ cảnh giữa các việc, và nếu sửa 2 lần vẫn sai thì bắt đầu lại với yêu cầu tốt hơn.
• Bí mật, xác thực, phân quyền và dữ liệu cá nhân là những chỗ không nên giao cho "cảm giác". Rà chúng bằng người và công cụ.

Vibe coding là gì, và nó khác gì kỹ thuật có tác tử

Andrej Karpathy đặt ra thuật ngữ này vào tháng 2/2025, mô tả cách lập trình "buông theo cảm giác, đón nhận cấp số nhân và quên rằng mã tồn tại", kể cả việc chấp nhận mọi thay đổi AI đưa ra mà không đọc phần khác biệt. Từ điển Collins sau đó chọn "vibe coding" là từ của năm 2025.

Simon Willison vẽ ranh giới chặt hơn: vibe coding là xây phần mềm bằng mô hình ngôn ngữ mà không xem xét mã nó viết. Nếu bạn đọc, kiểm thử và hiểu toàn bộ mã thì bạn đang dùng AI như trợ lý gõ phím.

Ông đề xuất tên "vibe engineering" vào 7/10/2025 cho cách làm của kỹ sư chuyên nghiệp dùng tác tử để làm nhanh hơn mà vẫn chịu trách nhiệm về phần mềm, rồi sau đó nghiêng sang "agentic engineering" (kỹ thuật có tác tử), cái tên ông ghi nhận là đang thắng thế từ 23/2/2026.

Bài viết ngày 6/5/2026 của ông cho thấy ranh giới đang mờ đi ngay cả với người làm nghề. Ông thừa nhận không còn đọc từng dòng đầu ra của tác tử, ví dụ tin một điểm cuối JSON đơn giản mà không đọc, và lo về "bình thường hóa độ lệch": mỗi lần không rà mà vẫn ổn khiến ta tin tưởng đúng lúc không nên.

Ông so tác tử với dịch vụ nội bộ của một đội khác: đọc tài liệu, dùng thử, chỉ đào vào mã khi có vấn đề. Và ông chỉ ra điều quan trọng: bộ kiểm thử, tài liệu hướng dẫn hay lịch sử commit không còn là dấu hiệu của sự cẩn trọng, vì tác tử tạo ra chúng rất nhanh; bằng chứng mạnh hơn là phần mềm đã được dùng thật hằng ngày.

Chọn mức rà soát theo rủi ro

Thay vì tranh cãi vibe coding tốt hay xấu, hãy coi đó là núm xoay mà bạn đặt tùy việc:

• Mức A, thử nghiệm cá nhân: công cụ chỉ mình bạn dùng, dữ liệu giả hoặc không nhạy cảm, hỏng thì làm lại. Có thể rà ít, chạy thử và nhìn kết quả. Willison cũng nói vibe coding hợp loại việc này.
• Mức B, công cụ nội bộ: cả đội dùng, có dữ liệu thật của doanh nghiệp. Cần rà kỹ phần quyền truy cập và dữ liệu, có kiểm thử cho luồng chính, và có người thứ hai xem trước khi đưa vào dùng.
• Mức C, sản phẩm cho khách hàng: có dữ liệu của người khác, có thanh toán hoặc tài khoản. Cần rà từng thay đổi, kiểm thử tự động, quy trình triển khai có bản xem trước và kiểm tra bảo mật. Willison nói thẳng rằng vibe coding thuần túy cho phần mềm phục vụ người khác là vô trách nhiệm vì đó là thông tin của họ.

Việc hợp để giao rộng cho tác tử: dựng nguyên mẫu, viết tập lệnh, trang giới thiệu, bảng điều khiển nội bộ với dữ liệu mẫu, chuyển đổi dữ liệu, viết kiểm thử, di chuyển mã có cách kiểm chứng rõ. Việc không nên giao mà không rà: xác thực và phân quyền, thanh toán, dữ liệu cá nhân, ranh giới bảo mật và bất cứ thứ gì bạn không có cách kiểm chứng.

Vòng lặp 6 bước

Quy trình dưới đây kết hợp hướng dẫn của Anthropic (khám phá, lập kế hoạch, làm, rồi lưu) với những gì Click Star thấy hiệu quả khi làm việc cùng tác tử.

1. Mô tả kết quả. Một đoạn ngắn: ai dùng, làm được gì, điều gì nằm ngoài phạm vi, thế nào là xong. Với tính năng lớn, bảo tác tử phỏng vấn bạn trước rồi ghi thành tệp SPEC.md.
2. Khám phá và lập kế hoạch. Để tác tử đọc mã và hỏi, chưa sửa gì (chế độ lập kế hoạch). Anthropic lưu ý bước này hữu ích khi phạm vi chưa rõ, sửa nhiều tệp hoặc mã lạ; nếu bạn mô tả được thay đổi bằng một câu thì bỏ qua cho nhanh.
3. Làm từng lát nhỏ. Mỗi lần một tính năng nhỏ, một thay đổi nhỏ. Lát nhỏ dễ kiểm tra, dễ hoàn tác và giữ ngữ cảnh gọn.
4. Kiểm chứng. Chạy kiểm thử, build, linter; với giao diện, so ảnh chụp màn hình với thiết kế. Bắt tác tử đưa bằng chứng (kết quả kiểm thử, lệnh đã chạy) thay vì nói "xong rồi".
5. Rà soát. Đọc phần khác biệt. Với thay đổi lớn hoặc rủi ro, nhờ một ngữ cảnh mới (tác tử khác hoặc người khác) rà lại, vì người viết khó thấy lỗi của chính mình.
6. Lưu. Commit trên nhánh riêng, mở bản xem trước, đọc lại trên môi trường thật rồi mới gộp vào nhánh chính.

Cách viết yêu cầu cho tác tử

Yêu cầu càng cụ thể, càng ít phải sửa. Theo hướng dẫn của Anthropic, 4 cách làm cho yêu cầu cụ thể hơn:

• Giới hạn phạm vi: nói tệp nào, tình huống nào, ưu tiên kiểm thử ra sao. Thay vì "thêm kiểm thử cho foo.py", viết "viết kiểm thử cho foo.py bao quát trường hợp người dùng đã đăng xuất, tránh dùng mock".
• Chỉ nguồn: thay vì hỏi vì sao một API kỳ lạ, bảo "xem lịch sử git của ExecutionFactory và tóm tắt vì sao API thành ra như vậy".
• Chỉ mẫu có sẵn: "xem các widget hiện có ở trang chủ, làm theo mẫu của HotDogWidget để tạo widget lịch mới, không thêm thư viện ngoài những gì dự án đã dùng".
• Mô tả triệu chứng: "người dùng báo đăng nhập lỗi sau khi hết phiên, kiểm tra luồng làm mới token trong src/auth, viết một kiểm thử tái hiện lỗi rồi mới sửa".

Một mẫu yêu cầu Click Star dùng thường xuyên:

Việc cần làm: [một câu].
Phạm vi: chỉ sửa trong [thư mục]. Không đụng vào [những phần khác].
Làm theo mẫu có sẵn ở: [tệp ví dụ].
Cách kiểm tra: chạy [lệnh kiểm thử] và [lệnh build]; mô tả kết quả bạn thấy.
Khi xong: liệt kê tệp đã đổi và những giả định bạn đã đặt ra.

Giữ ngữ cảnh gọn

Hướng dẫn của Anthropic xoay quanh một ràng buộc: cửa sổ ngữ cảnh đầy rất nhanh, và chất lượng giảm khi nó đầy. Mỗi tệp tác tử đọc, mỗi kết quả lệnh đều nằm trong đó. Hệ quả thực hành:

• Dọn ngữ cảnh giữa các việc không liên quan, đừng để một phiên làm đủ thứ.
• Nếu đã sửa tác tử 2 lần cho cùng một vấn đề mà vẫn sai, ngữ cảnh đã đầy các hướng thử hỏng. Mở phiên mới với yêu cầu tốt hơn, thường nhanh hơn là sửa tiếp.
• Với việc cần đọc nhiều tệp để điều tra, giao cho tác tử phụ làm trong ngữ cảnh riêng và chỉ nhận bản tóm tắt.
• Tệp hướng dẫn dự án (như CLAUDE.md) phải ngắn: ghi các lệnh tác tử không đoán được, quy ước khác mặc định, cách chạy kiểm thử, những bẫy đã biết. Bỏ những gì tác tử tự biết bằng cách đọc mã. Tệp quá dài khiến tác tử bỏ qua nửa số quy tắc. Việc bắt buộc phải xảy ra mỗi lần (ví dụ chạy linter sau mỗi lần sửa tệp) nên là một hook chạy tự động, vì hook chắc chắn, còn chỉ dẫn trong tệp chỉ mang tính tham khảo.

Kiểm chứng và rà soát

Anthropic gọi một lỗi quen thuộc là "khoảng trống giữa tin và kiểm": tác tử tạo ra bản triển khai trông hợp lý nhưng bỏ sót trường hợp biên. Cách sửa của họ rất thẳng: nếu bạn không kiểm chứng được thì đừng đưa lên.

Chỉ số của Stanford AI Index 2026 gợi lý do cần cẩn trọng: kết quả trên bộ SWE-bench Verified tăng từ khoảng 60% lên gần 100% chỉ trong một năm, nhưng trên các tác vụ thao tác máy tính có cấu trúc (OSWorld), tác tử thành công khoảng 66% và vẫn hỏng khoảng một trong 3 lần thử. Năng lực tăng nhanh không có nghĩa là bỏ được khâu kiểm tra.

Một vài cách làm cụ thể:

• Cho kiểm thử trước, rồi để tác tử viết mã vượt qua chúng, hoặc ngược lại, nhưng luôn có một cách chạy được để biết đúng hay sai.
• Với giao diện, dán ảnh thiết kế, yêu cầu chụp màn hình kết quả, so sánh và liệt kê khác biệt.
• Với lỗi, đưa thông báo lỗi cụ thể và yêu cầu sửa nguyên nhân gốc, đừng chỉ che lỗi.
• Dùng mô hình thứ hai làm người rà soát với ngữ cảnh mới, nhưng dặn chỉ nêu những khoảng trống ảnh hưởng đến tính đúng đắn hoặc yêu cầu đã nêu. Người rà soát được dặn tìm lỗi thì hầu như luôn tìm ra một ít, và đuổi theo mọi nhận xét dẫn đến thiết kế quá tay.

Bảo mật: danh sách kiểm tra tối thiểu

Đây là phần "cảm giác" không đủ. Trước khi một thứ do AI viết chạm vào dữ liệu thật:

• Bí mật: khóa API, mật khẩu cơ sở dữ liệu không bao giờ nằm trong mã chạy ở trình duyệt hay trong kho mã. Dùng biến môi trường, quét kho mã để tìm khóa lỡ commit, và thu hồi ngay khóa đã lộ.
• Xác thực và phân quyền ở phía máy chủ: đừng tin kiểm tra ở giao diện. Với cơ sở dữ liệu có hỗ trợ (như Supabase, PostgreSQL), bật chính sách bảo mật theo hàng (RLS) và thử bằng tài khoản có quyền thấp.
• Kiểm tra đầu vào: mọi dữ liệu từ người dùng đều không đáng tin. Dùng truy vấn tham số hóa và làm sạch đầu ra để tránh chèn mã.
• Phụ thuộc: tác tử đôi khi gợi ý thư viện không tồn tại hoặc ít người dùng. Kiểm tra tên gói, mức phổ biến và người duy trì trước khi cài.
• Quyền của chính tác tử: chạy trong môi trường cô lập (sandbox) khi có thể, chỉ cho phép sẵn các lệnh bạn tin, và đừng đưa dữ liệu sản xuất vào phiên làm việc.
• Khôi phục: có sao lưu, có cách hoàn tác triển khai, và giới hạn tốc độ cho các điểm cuối công khai.

Làm việc nhóm

• Mọi thay đổi do tác tử viết đi qua nhánh, bản xem trước và rà soát như mã của người, không có đường tắt.
• Mô tả của mỗi yêu cầu gộp nên kèm bằng chứng đã kiểm: kết quả kiểm thử, ảnh chụp, các giả định.
• Giữ tệp hướng dẫn dự án trong kho mã để cả đội cùng cải thiện. Khi tác tử lặp lại một sai lầm, thêm đúng một dòng vào đó, và định kỳ cắt bớt.
• Thống nhất mức rà soát (A, B hay C) cho từng loại dự án để không phải tranh luận từng lần.

7 sai lầm thường gặp

1. Phiên làm việc "tất cả trong một": đang làm việc này, hỏi sang việc khác rồi quay lại, ngữ cảnh đầy thông tin không liên quan.
2. Sửa đi sửa lại cùng một lỗi trên cùng ngữ cảnh thay vì bắt đầu lại với yêu cầu tốt hơn.
3. Tệp hướng dẫn dự án quá dài, nên các quy tắc quan trọng bị chìm.
4. Tin vào kết quả trông hợp lý mà không có kiểm thử hay cách xác minh.
5. Điều tra không giới hạn: bảo tác tử "tìm hiểu" mà không khoanh vùng, nó đọc hàng trăm tệp và lấp đầy ngữ cảnh.
6. Chấp nhận mọi thay đổi không đọc cho phần mềm phục vụ khách hàng.
7. Không dùng quản lý phiên bản, nên khi tác tử làm hỏng thì không có đường quay lại.

Kế hoạch 7 ngày thực hành

• Ngày 1: chọn một công cụ nội bộ nhỏ (mức A hoặc B) và viết mô tả kết quả một đoạn.
• Ngày 2: để tác tử khám phá và lập kế hoạch, bạn đọc kế hoạch và sửa.
• Ngày 3: làm lát đầu tiên, có cách tự kiểm tra, và commit.
• Ngày 4: thêm 2 lát nữa, dọn ngữ cảnh giữa các lát.
• Ngày 5: chạy danh sách kiểm tra bảo mật cho cả công cụ.
• Ngày 6: nhờ một người khác hoặc một ngữ cảnh mới rà soát phần khác biệt.
• Ngày 7: viết tệp hướng dẫn dự án ngắn từ những gì tác tử đã làm sai, và đặt mức rà soát cho loại dự án tiếp theo.