Tránh AI slop: giữ chất lượng code khi vibe coding (2026)

Jasmine, dev dùng Claude Code hằng ngày, đã tự dính và tự sửa AI slop đủ nhiều để viết bài này.

Vibe coding cho tốc độ điên rồ. Nhưng ai đã đẩy AI viết code cả tháng đều gặp cùng một cảm giác: bạn merge một PR "chạy ngon", vài tuần sau mới phát hiện nó sai logic ở edge case, hoặc dựng một tầng abstraction không ai cần. Đó là AI slop. Bài này không chống lại vibe coding - nếu bạn chưa rõ khái niệm, đọc vibe coding là gì trước - mà giúp bạn giữ chất lượng khi vibe coding có kỷ luật.

AI slop là gì? (và vì sao khác "rác AI" mạng xã hội)

AI code slop là code do AI sinh ra tuy compile được và qua test, nhưng vẫn làm mục codebase vì nó nông về cấu trúc, mù convention của dự án, và được lặp lại ở quy mô máy nhanh hơn tốc độ con người kịp review. Nó không phải "code sai hẳn" - nếu sai hẳn thì đã bị bắt ngay. Slop nguy hiểm ở chỗ nó trông đúng.

Cần phân biệt rõ, vì từ "AI slop" đang bị hiểu lệch trên tiếng Việt:

Hai nghĩa khác nhau của "AI slop":

1. Rác nội dung AI - video, ảnh, bài viết rác do AI sản xuất hàng loạt tràn ngập mạng xã hội. Merriam-Webster chọn "slop" là Từ của năm 2025 (công bố 15/12/2025) chính theo nghĩa này. Hầu hết bài tiếng Việt về "AI slop" đang nói về nghĩa này.

2. AI code slop - code kém chất lượng do AI tạo ra, chủ đề của bài này. Đây là góc lập trình, gần như chưa có bài tiếng Việt nào xử lý tử tế.

Nếu bạn tìm "AI slop" để hiểu về rác nội dung mạng xã hội, bài này không dành cho bạn. Nếu bạn là dev đang lo code AI của mình trông đúng mà sai, đọc tiếp. Từ khoá tương đương bạn hay gặp: ai code slop, vibe slop, code AI kém chất lượng.

6 dấu hiệu code AI slop (taxonomy)

Không phải mọi code AI đều là slop. Nhưng slop có "vân tay" khá đặc trưng. Đây là 6 dấu hiệu code AI kém chất lượng mình gặp thường xuyên nhất, mỗi cái kèm một ví dụ để bạn nhận diện nhanh:

1. Trông đúng, sai logic ở edge case. Hàm chạy tốt với input mẫu nhưng vỡ khi gặp chuỗi rỗng, timezone, số âm, hoặc phân trang cuối. Ví dụ: hàm chia trung bình không xử lý mảng rỗng → chia cho 0.
2. Over-engineer / abstraction thừa. AI dựng factory, strategy pattern, generic layer cho một thứ chỉ cần 5 dòng. Ví dụ: một interface + 3 class để format một chuỗi ngày.
3. Mù convention repo. Naming, cấu trúc thư mục, cách handle error khác hẳn phần còn lại của codebase. Ví dụ: dự án dùng Result<T> nhưng AI throw exception lung tung.
4. Ảo giác API / config / package. Gọi hàm không tồn tại, import package sai tên, dùng option config đã bị bỏ. Ví dụ: import { parseDate } from 'date-fns' - trong khi date-fns không export tên đó.
5. Test soi gương implementation. Test được viết để pass đúng cái code vừa sinh, không kiểm hành vi mong đợi. Ví dụ: mock luôn giá trị trả về rồi assert đúng cái mock đó.
6. Hard-code và magic value. Số/URL/key nhét thẳng vào logic thay vì config. Ví dụ: if (userId === 42) hoặc timeout 3000 rải rác khắp nơi.

Vì sao AI slop nguy hiểm hơn nợ kỹ thuật thường

Nợ kỹ thuật do con người tạo ra thường lộ: bạn biết chỗ nào code cẩu thả vì bạn (hoặc đồng đội) đã cắt góc có ý thức. AI slop khác ở ba điểm khiến nó độc hơn.

Thứ nhất, nó trông đã xong. Code có format đẹp, có docstring, có test - mọi tín hiệu bề mặt của "code chất lượng" đều đủ, nên não bạn hạ mức cảnh giác. Thứ hai, nó lan đồng đều ở quy mô máy. Con người cẩu thả một chỗ; AI cẩu thả cùng một kiểu ở 40 file trong một buổi chiều. Thứ ba, nó qua mọi check mà team đang tin. Lint xanh, type xanh, test xanh - vì test cũng do AI viết để soi gương chính code đó.

Con số đáng lo: nghiên cứu của CSET (Center for Security and Emerging Technology, "Cybersecurity Risks of AI-Generated Code", 2024) tìm thấy gần một nửa số snippet do AI sinh chứa lỗi hoặc lỗ hổng bảo mật khai thác được. Nghĩa là: "chạy được" không đồng nghĩa "an toàn để ship".

Một kịch bản quen thuộc: bạn nhờ AI thêm một tính năng nhỏ, nó "tiện tay" refactor luôn ba file liên quan theo một pattern nghe hợp lý. PR xanh, review lướt qua vì "chỉ là refactor", merge. Ba tuần sau, một bug lạ xuất hiện ở module tưởng như không liên quan - vì cái pattern kia đã âm thầm đổi hành vi của một hàm dùng chung. Bạn mất nửa ngày truy ngược, chỉ để nhận ra gốc rễ là một đoạn slop trông vô hại từ lâu.

Kết quả: AI slop tích tụ nhanh hơn nợ kỹ thuật truyền thống, nhưng ẩn kỹ hơn - đến khi lộ thì đã ngấm sâu vào nhiều tầng. Và vì nó lan theo mẫu, sửa một chỗ thường chưa đủ: bạn phải đi tìm tất cả các bản sao mà AI đã rải.

Checklist tránh AI slop khi vibe coding

Đây là phần lõi. Thay vì "review kỹ hơn" chung chung, chia theo 4 giai đoạn của một vòng vibe coding. In ra dán cạnh màn hình cũng được.

Trước khi prompt

• Viết spec / acceptance criteria rõ ràng trước khi gõ prompt. AI không đọc được ý bạn; nó lấp khoảng trống bằng phỏng đoán - và phỏng đoán là nơi slop sinh ra.
• Giao task nhỏ, phạm vi hẹp. Một hàm, một endpoint mỗi lần - dễ review, dễ bắt sai.
• Nạp context: coding standards, kiến trúc, pattern hiện có, file CLAUDE.md. Context nghèo là nguyên nhân số một của slop.

Khi sinh code

• Yêu cầu AI theo đúng convention repo (naming, error handling, cấu trúc) - nói thẳng trong prompt, đừng kỳ vọng nó tự đoán.
• Xác minh mọi API / package / config với docs hiện hành để chống ảo giác. Nếu AI gọi một hàm bạn chưa từng thấy, giả định nó bịa cho đến khi chứng minh ngược lại.

Trước khi merge

• Đọc-hiểu từng dòng. Nguyên tắc bất khả xâm phạm: đừng ship code bạn không hiểu. Nếu không giải thích được vì sao một dòng tồn tại, nó chưa sẵn sàng.
• Review logic + contract + kiến trúc, không chỉ hỏi "chạy được chưa?". Cách review code AI khác hẳn review code người - xem chi tiết trong cách review code AI đúng.
• Đảm bảo test kiểm hành vi mong đợi, không soi gương implementation.
• Đặt lint / type / coverage làm CI gate - nhưng nhớ CI xanh không chứng minh không có slop.
• Kiểm dependency và license mà AI mới thêm vào.

Duy trì

• Lập một "slop catalog": ghi lại các anti-pattern AI hay tạo trong repo của bạn, rồi nạp ngược vào prompt template và rule CI. Codebase càng "dạy" AI, slop càng ít.

Từ khoá liên quan phần này: checklist code AI, context engineering. Không checklist nào diệt 100% slop - nó chỉ hạ xác suất và tốc độ tích tụ.

Ví dụ thật: một đoạn slop và bản đã sửa

Cụ thể hoá bằng một hàm tính giá sau giảm - đúng kiểu "trông đúng mà sai". Đây là bản AI sinh ra đầu tiên:

// BEFORE - AI slop: trông đúng, sai ở nhiều edge case
function applyDiscount(price, discountPercent) {
 const finalPrice = price - (price * discountPercent / 100);
 return finalPrice.toFixed(2);
}

// applyDiscount(100, 20) -> "80.00" ✓ nhìn có vẻ ổn

Nó pass test mẫu, nên dễ bị merge. Nhưng: (1) trả về string chứ không phải number - làm hỏng phép cộng ở nơi khác; (2) không chặn discount âm hoặc > 100; (3) lỗi làm tròn tiền tệ với số thực; (4) không xử lý input không hợp lệ. Bản đã sửa:

// AFTER - sửa slop: rõ contract, chặn edge case
function applyDiscount(priceCents, discountPercent) {
 if (!Number.isInteger(priceCents) || priceCents < 0) {
 throw new Error('priceCents phải là số nguyên không âm (đơn vị: cent)');
 }
 if (discountPercent < 0 || discountPercent > 100) {
 throw new Error('discountPercent phải trong khoảng 0..100');
 }
 // Tính bằng cent (integer) để tránh lỗi làm tròn số thực
 const discount = Math.round(priceCents * discountPercent / 100);
 return priceCents - discount; // trả về number (cent), không phải string
}

Điểm mấu chốt không phải "code sau dài hơn", mà là: bản slop giấu bốn giả định sai sau một vẻ ngoài gọn gàng. Chỉ khi bạn đọc để hiểu contract - kiểu dữ liệu trả về, miền giá trị hợp lệ, cách xử lý tiền - thì slop mới lộ. Đó là lý do "chạy được" không bao giờ đủ.

Context engineering - gốc rễ giảm slop

Sửa slop sau khi merge thì đắt. Rẻ hơn nhiều là chặn nó từ đầu bằng context engineering: cấp cho AI đúng nguyên liệu để nó khỏi phải đoán. Cụ thể là coding standards, sơ đồ kiến trúc, các pattern hiện có trong repo, và một file CLAUDE.md chuẩn mô tả quy ước dự án. Muốn đào sâu cơ chế này, xem context engineering như một kỹ năng riêng.

Context tốt biến AI từ "một dev giỏi mới vào công ty ngày đầu" thành "một dev đã nắm codebase". Cùng một model, chất lượng output chênh nhau rất xa chỉ nhờ context.

Ở quy mô team, giữ context và chuẩn quy trình nhất quán giữa nhiều người là việc khó. Một cách là dùng bộ kit dựng sẵn skills, subagent và workflow chuẩn cho Claude Code - ví dụ bộ kit AgentKit cho Claude Code đóng gói sẵn các quy ước review, cấu trúc và pattern để cả team dùng chung, nhờ đó context và chuẩn không bị trôi mỗi người một kiểu. Nếu muốn xem trực tiếp, bạn có thể xem giá AgentKit (giảm 20% qua link). Không có công cụ nào thay được tư duy của bạn - nhưng chuẩn hoá context là đòn bẩy thật để giảm slop từ gốc.

"Taste" - phán đoán kỹ thuật AI không thay được

Cuối cùng, phòng slop không thể tự động hoá 100%. Nó cần cái mà dân trong nghề gọi là taste: biết khi nào không ship thứ AI vừa tạo, kể cả khi nó "chạy được". Taste là khả năng nhìn một đoạn code và thấy nó sẽ đau ở đâu sau sáu tháng.

AI viết code; con người chịu trách nhiệm từng dòng commit. Khi một bug lên production, không ai chấp nhận lời giải thích "AI viết vậy mà". Taste không mua được, cũng không prompt ra được - nó đến từ việc bạn thật sự đọc, thật sự hiểu, và thật sự chịu trách nhiệm cho những gì mình merge. Đó là ranh giới giữa vibe coding và vibe slop.

Câu hỏi thường gặp (FAQ)

AI slop trong code khác rác AI mạng xã hội thế nào?

Rác AI mạng xã hội là nội dung (video, ảnh, bài) do AI sản xuất hàng loạt - nghĩa phổ biến khiến Merriam-Webster chọn "slop" làm Từ của năm 2025. AI code slop là code AI kém chất lượng: compile được, qua test, nhưng nông về cấu trúc và làm mục codebase. Bài này nói về nghĩa thứ hai.

Vibe coding có chắc chắn tạo ra slop không?

Không. Vibe coding chỉ tạo slop khi thiếu kỷ luật: prompt mơ hồ, không nạp context, và merge code chưa đọc-hiểu. Vibe coding có kỷ luật - spec rõ, context tốt, review kỹ - cho tốc độ AI mà vẫn giữ chất lượng.

Làm sao biết code AI của mình bị slop?

Soi 6 dấu hiệu: trông đúng nhưng sai edge case, over-engineer, mù convention repo, ảo giác API/package, test soi gương implementation, và hard-code magic value. Nếu bạn không giải thích được vì sao một dòng tồn tại, khả năng cao đó là slop.

Dùng test và lint là đủ để chặn slop chưa?

Chưa. Lint và test bắt lỗi bề mặt, nhưng slop thường qua hết vì test do AI viết có thể chỉ soi gương chính code đó. Bạn vẫn cần đọc-hiểu logic, kiểm contract và kiến trúc bằng mắt người.

Công cụ hay kit nào giúp giảm slop?

Gốc rễ là context engineering: nạp coding standards, kiến trúc và pattern qua file như CLAUDE.md. Ở quy mô team, các bộ kit dựng sẵn skills/subagent/workflow chuẩn cho Claude Code giúp giữ context và chuẩn nhất quán. Nhưng công cụ chỉ hỗ trợ - quyết định cuối vẫn là phán đoán của bạn.

Có nên ship code AI mà mình chưa hiểu không?

Không, tuyệt đối không. Đây là nguyên tắc bất khả xâm phạm để tránh slop: nếu không hiểu vì sao code hoạt động, bạn không thể bảo trì, không thể debug, và không thể chịu trách nhiệm khi nó hỏng. Đọc đến hiểu, rồi mới merge.

Kết luận: vibe coding có kỷ luật

AI slop không phải lý do để tránh AI - nó là lý do để dùng AI có kỷ luật. Công thức đơn giản: tốc độ của AI cộng với kỷ luật review của con người bằng code sạch và nhanh. Bỏ vế thứ hai, bạn được slop nhanh. Để đi tiếp, xem lại nền tảng ở vibe coding là gì và nâng kỹ năng kiểm soát chất lượng ở cách review code AI đúng. Viết code là của AI; taste và trách nhiệm vẫn là của bạn.