Vibe Coding

Level: L6 — AI Coding & Vibe Coding (Bài 4/12)

Ghi chú thuật ngữ quan trọng

Thuật ngữ “vibe coding” do Andrej Karpathy đặt ra (2/2025) vốn nghĩa là “Accept All mọi thay đổi, không đọc lại code” — ông tự nhận chỉ phù hợp “dự án cuối tuần dùng rồi bỏ” [S97]. Đây không phải cách Level 6 dạy. Bài này dùng đúng tên gọi phổ biến (“Vibe Coding”, theo Blueprint V1) cho quy trình xây dựng nhanh bằng ngôn ngữ tự nhiên, nhưng luôn giữ nguyên tắc kiểm soát đã học ở bài 53/57 (đọc lại thay đổi, xác nhận trước khi tin dùng) — gần với hướng mà chính Karpathy gọi là “agentic engineering” từ 2026, hơn là định nghĩa gốc năm 2025.

Ranh giới phạm vi

Bài này không dạy lại mô hình tinh thần (đã học bài 53) hay công cụ Claude Code (đã học bài 57). Bài này dừng lại ở khi có 1 prototype chạy được cục bộ — chưa deploy công khai (đó là bài 63).

1. Mục tiêu học tập

Sau bài này, bạn có thể:

• Giải thích đúng nguồn gốc và rủi ro thật của “vibe coding” theo nghĩa gốc — và vì sao Level 6 áp dụng 1 phiên bản có kỷ luật hơn.
• Thực hiện quy trình 3 bước xây dựng nhanh: Mega Prompt → Phỏng vấn → Lặp lại, dùng Claude Code (đã học bài 57).
• Bắt đầu xây dựng dự án tích lũy Level 6: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt — tới trạng thái “chạy được cục bộ”.
• Biết chính xác vì sao luôn đọc lại thay đổi trước khi chấp nhận, dựa trên số liệu rủi ro thật, không phải cảm tính.

2. Khái niệm cốt lõi

Vì sao cần minh bạch hoá thuật ngữ: Simon Willison, 1 nhà phát triển có ảnh hưởng, chỉ ra ranh giới rõ: “nếu 1 LLM viết mọi dòng code nhưng bạn đã review, test, và hiểu hết — đó không còn là vibe coding theo đúng nghĩa, đó là dùng LLM như 1 trợ lý gõ chữ” [S97]. Level 6 chủ động chọn vế thứ 2 (dùng AI như trợ lý gõ chữ rất nhanh, không phải giao toàn quyền) — dù vẫn dùng tên gọi phổ biến “Vibe Coding” cho quy trình, để nhất quán với tên bài trong Blueprint V1.

Vì sao đây không phải cảnh báo hình thức: dữ liệu thực tế cho thấy rủi ro của “vibe coding” theo đúng nghĩa gốc (không review) là có thật, đo lường được: code có AI đồng tác giả (không qua review kỹ) chứa 1,7 lần nhiều lỗi nghiêm trọng hơn, lỗ hổng bảo mật cao hơn 2,74 lần so với code được viết/review cẩn thận [S97]. Đây chính là lý do Level 6 dành hẳn 4 bài sau (59-62: Debug, Refactor, Testing, Security) để bù đắp đúng những rủi ro này — không phải nội dung thừa.

Quy trình 3 bước (điều chỉnh từ workflow gốc, dừng trước Deploy) [dựa trên S17, đã điều chỉnh theo đúng ranh giới đã phê duyệt]:

1. Mega Prompt — mô tả toàn bộ ý tưởng sản phẩm cho Claude Code trong 1 lần, đặt AI vào vai trò “đối tác kỹ thuật” hiểu rõ mục tiêu tổng thể, không chỉ từng lệnh rời rạc.
2. Phỏng vấn — để Claude Code (hoặc bạn chủ động) đặt câu hỏi làm rõ trước khi xây — đúng tinh thần “khám phá trước khi triển khai” đã học ở bài 57 (Plan mode).
3. Lặp lại — xây từng phần nhỏ, xem kết quả, điều chỉnh, lặp lại — dừng khi có 1 phiên bản chạy được, đúng mô hình 4 lớp đã học ở bài 55.

3. Tại sao nội dung này quan trọng

Đây là bài đầu tiên bạn thực sự xây dựng sau 3 bài nền tảng — nhưng cũng là điểm dễ “trượt” nhất về đúng rủi ro đã nêu ở mục 2: tốc độ của quy trình này dễ khiến người mới quên mất nguyên tắc “luôn xác nhận” đã học. Giữ đúng kỷ luật ngay từ lần xây dựng đầu tiên quan trọng hơn tốc độ.

4. Cơ chế hoạt động

Phân định AI vs con người (áp dụng cụ thể cho quy trình 3 bước):

	Điều bạn cần hiểu	Điều AI có thể thực hiện	Điều bạn phải xác nhận
Mega Prompt	Mục tiêu sản phẩm là gì, phạm vi tới đâu	Đề xuất kiến trúc kỹ thuật cụ thể	Kiến trúc đề xuất có khớp mô hình 4 lớp (bài 55) và khả thi với bạn không
Phỏng vấn	Câu hỏi AI đặt ra thường chỉ ra góc bạn chưa nghĩ tới	Tự đặt câu hỏi làm rõ	Trả lời đúng, không trả lời qua loa cho nhanh
Lặp lại	Mỗi vòng lặp nên nhỏ, dễ kiểm tra	Viết/sửa code từng phần	Đọc lại từng thay đổi trước khi chấp nhận (đây là điểm khác biệt cốt lõi với “vibe coding” nguyên gốc)

5. Mental model

Nếu bài 53 dạy bạn vai trò “người thiết kế + người kiểm tra công trình”, bài này là lúc bạn thực sự đứng công trường lần đầu: bạn mô tả toàn bộ ngôi nhà muốn xây (Mega Prompt), thợ xây hỏi lại vài điểm chưa rõ (Phỏng vấn), rồi xây từng phòng một, bạn đi kiểm tra sau mỗi phòng thay vì đợi xây xong cả nhà mới nhìn lại (Lặp lại) — không phải “giao chìa khóa rồi đi nghỉ mát” (đó là “vibe coding” nguyên gốc, rủi ro cao).

6. Hướng dẫn từng bước

Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.

1. Viết Mega Prompt — mô tả đầy đủ: “Xây 1 ứng dụng ghi chú cá nhân, người dùng có thể thêm/xem/xóa ghi chú, lưu trữ lâu dài (đúng mô hình 4 lớp bài 55). Tính năng AI tóm tắt sẽ thêm sau (bài 64) — hiện tại chỉ cần CRUD ghi chú cơ bản chạy đúng.”
2. Trả lời phỏng vấn — Claude Code có thể hỏi: dùng ngôn ngữ/framework nào, lưu dữ liệu ở đâu, giao diện đơn giản tới mức nào. Trả lời cụ thể, ưu tiên lựa chọn đơn giản nhất cho người mới.
3. Lặp lại theo từng tính năng nhỏ:
   • Vòng 1: giao diện thêm 1 ghi chú mới.
   • Vòng 2: xem danh sách ghi chú đã lưu.
   • Vòng 3: xóa 1 ghi chú.
   • Sau mỗi vòng: đọc lại thay đổi (dùng Checkpoint/Permission đã học bài 57), chạy thử, xác nhận đúng trước khi sang vòng tiếp theo.
4. Dừng lại khi có 1 prototype chạy được trên máy bạn — chưa cần deploy (bài 63), chưa cần debug sâu (bài 59), chưa cần tính năng AI tóm tắt (bài 64) — đây chỉ là nền tảng CRUD cơ bản.

7. Ví dụ thực tế

Ví dụ Mega Prompt cụ thể cho dự án tích lũy:

Xây 1 ứng dụng web ghi chú cá nhân đơn giản.

Mục tiêu: người dùng thêm, xem, xóa ghi chú văn bản. Dữ liệu lưu lại
lâu dài (không mất khi đóng trình duyệt).

Phạm vi hiện tại: CHỈ cần CRUD cơ bản (Create/Read/Delete), CHƯA cần
tính năng AI tóm tắt (sẽ thêm sau).

Trước khi bắt đầu, hỏi tôi bất kỳ điều gì chưa rõ về công nghệ hay
cách tổ chức dự án.

Đây chính là bước “Mega Prompt” — đủ chi tiết để Claude Code hiểu đúng phạm vi (đặc biệt lưu ý câu “CHƯA cần tính năng AI tóm tắt” — tránh AI làm vượt phạm vi vòng lặp hiện tại).

8. Prompt/template/workflow

Xây [loại sản phẩm].
Mục tiêu: [1-2 câu mô tả chức năng cốt lõi].
Phạm vi hiện tại: [CHỈ cần gì, CHƯA cần gì].
Trước khi bắt đầu, hỏi tôi bất kỳ điều gì chưa rõ.

[ ] Đã đọc lại thay đổi Claude Code vừa thực hiện chưa?
[ ] Đã chạy thử tính năng vừa xây chưa?
[ ] Kết quả có đúng như Mega Prompt mô tả không?
[ ] Sẵn sàng sang vòng lặp tiếp theo, hay cần sửa trước?

9. Visual hoặc diagram cần thiết

Hình 6.4 — Quy trình 3 bước Mega Prompt → Phỏng vấn → Lặp lại, dừng khi có prototype chạy được cục bộ — chưa deploy.

10. Bài tập thực hành

1. Viết Mega Prompt cho dự án ghi chú cá nhân theo khung ở mục 8 (hoặc điều chỉnh ý tưởng theo ý bạn, miễn giữ đủ 4 lớp kiến trúc đã học bài 55).
2. Trả lời phỏng vấn của Claude Code một cách cụ thể.
3. Thực hiện ít nhất 2 vòng lặp xây dựng (thêm ghi chú + xem danh sách), áp dụng checklist sau mỗi vòng.
4. Dừng lại đúng lúc — xác nhận bạn có 1 prototype chạy được cục bộ, chưa cố deploy hay thêm tính năng AI (việc đó thuộc các bài sau).

11. Checklist

Đặt lại checklist

• Hiểu đúng nguồn gốc/rủi ro thật của 'vibe coding' nguyên nghĩa.
• Thực hiện được quy trình 3 bước Mega Prompt → Phỏng vấn → Lặp lại.
• Luôn đọc lại thay đổi trước khi chấp nhận, không 'Accept All' mù quáng.
• Có 1 prototype CRUD cơ bản chạy được cục bộ cho dự án tích lũy.

12. Lỗi thường gặp

• Áp dụng đúng “vibe coding” nghĩa gốc — Accept All không đọc — đây chính xác là rủi ro đã có số liệu thật, không phải giả định.
• Mega Prompt quá mơ hồ (“làm cho tôi 1 app ghi chú”) — thiếu phạm vi rõ ràng khiến AI tự đoán, dễ lệch ý.
• Cố làm hết mọi tính năng trong 1 vòng lặp lớn thay vì chia nhỏ — khó kiểm tra, khó phát hiện lỗi nằm ở đâu.
• Cố deploy ngay trong bài này — đi ngược ranh giới đã phê duyệt; deploy thuộc về bài 63, có quy trình bảo mật/hosting riêng cần học trước.

13. Giới hạn & khi nào KHÔNG nên áp dụng

• Bài này không dạy debug sâu khi có lỗi phức tạp — đó là bài 59.
• Bài này không dạy triển khai công khai — đó là bài 63.
• Với sản phẩm thật sự quan trọng/production ngay từ đầu (không phải học tập), quy trình “lặp lại nhanh” này vẫn cần bổ sung đầy đủ testing (bài 61) và security review (bài 62) trước khi coi là hoàn chỉnh — không chỉ dừng ở “chạy được”.

14. An toàn & quản trị (Safety/Governance)

Rủi ro đã đo lường được, không phải khuyến nghị “cho chắc”

Code AI-đồng-tác-giả không qua review có tỷ lệ lỗi nghiêm trọng cao hơn 1,7 lần, lỗ hổng bảo mật cao hơn 2,74 lần so với code được review cẩn thận [S97]. Không bao giờ áp dụng “Accept All” xuyên suốt 1 dự án nghiêm túc, kể cả khi tốc độ ban đầu có vẻ hấp dẫn hơn.

15. Best practices

1. Viết Mega Prompt càng cụ thể càng tốt về phạm vi — đặc biệt nêu rõ “CHƯA cần” để tránh AI làm vượt phạm vi hiện tại.
2. Giữ mỗi vòng lặp đủ nhỏ để bạn có thể đọc và hiểu hết thay đổi trong vài phút — nếu 1 vòng lặp tạo ra thay đổi quá lớn để đọc hết, chia nhỏ hơn.
3. Dừng đúng lúc — hoàn thành đúng phạm vi Mega Prompt đã đặt ra, không cố “tiện thể” làm thêm việc ngoài phạm vi bài này.

16. Nội dung nâng cao (không bắt buộc)

Karpathy — người đặt ra thuật ngữ “vibe coding” — đến 2026 đã tự chuyển sang gọi cách làm việc có giám sát là “agentic engineering”, mô tả: “bạn không còn tự viết code trực tiếp 99% thời gian, bạn đang điều phối các agent làm việc đó và đóng vai trò giám sát” [S97] — mô tả này khớp gần như chính xác với cách Level 6 tiếp cận toàn bộ hành trình.

17. Nguồn tham khảo

[S97] Vibe Coding, Wikipedia (Tier 2) — nguồn gốc thuật ngữ, định nghĩa gốc của Karpathy, tranh cãi (Simon Willison, Andrew Ng), số liệu rủi ro (CodeRabbit, GitClear) · [S17] Claude Code Cho Người Không Biết Code, Phan Đông Giang (Tier 3) — khung quy trình 3 bước Mega Prompt-Phỏng vấn-Lặp lại (đã điều chỉnh, dừng trước bước Deploy nguyên gốc) · Dẫn chiếu (không trích dẫn mới): bài 53 (mental model), bài 55 (kiến trúc 4 lớp), bài 57 (Claude Code, Checkpoint/Permission).

18. Ngày kiểm chứng

Định nghĩa và số liệu rủi ro kiểm chứng qua nguồn Tier 2 (S97) ngày 2026-07-12 — đây là thuật ngữ văn hóa/cộng đồng đang tiếp tục tiến hóa nhanh (chính người đặt ra thuật ngữ đã đổi cách gọi trong vòng 1 năm), khuyến nghị re-verify định nghĩa phổ biến trước khi xuất bản chính thức.