Tránh AI Slop
Cách để tránh việc AI tạo ra code kém chất lượng
"AI slop" dùng để chỉ các đầu ra rác mà AI tạo ra khi prompt không rõ ràng, thiếu ngữ cảnh hay model yếu dùng cho task phức tạp.
Trong lập trình, AI slop là code rác, màu mè, nhiều abstraction không cần thiết, comment dài dòng. Mặc dù syntax đúng nhưng sai khi không phù hợp với kiến trúc codebase.

1. "AI Slop" khác với "Developer Slop"
Việc AI tạo ra sản phẩm có lỗ hổng bảo mật, lộ toàn bộ cấu trúc API ở response,... thì không hẳn là AI slop, mà là DEVELOPER SLOP =)) - người tạo ra sản phẩm không hiểu rõ về lập trình, về kiến trúc của một sản phẩm công nghệ. Còn khi đã biết thì nó như một phần checklist công việc vậy, không thể đổ lỗi cho AI.
Nguyên tắc: Garbage in, garbage out. Đầu vào cho AI kém chất lượng từ prompting đến thiếu trải nghiệm trong chuyên môn của người làm sản phẩm thì đầu ra khó để kỳ vọng là không có sai lầm.
2. AI Slop trong lập trình trông như nào?
Các biểu hiện của AI slop trong lập trình
| Biểu hiện | Ví dụ |
|---|---|
| Over-abstraction | Tự thêm/import các abstraction layer không cần thiết |
| Generic naming | DataProcessor, HelperUtils, ServiceManager |
| Kitchen-sink imports | Import toàn bộ thư viện cho 1 hàm đơn giản |
| Defensive overkill | Code try-catch cho những hàm không thể fail |
| Defensive underkill | Không có error handling ở chỗ cần thiết, không nắm được môi trường production để implement security, guardrails |
| Feature creep | Tự động thêm tính năng nhỏ, caching, dòng chảy logic mà mình không yêu cầu (Phép màu cho người lệ thuộc vào AI nhưng ác mộng cho hệ thống phức tạp) |
Vì sao điều này xảy ra
Chủ yếu là do người dùng chứ sao. Lỗi và lỗ hổng khi code thì dù có AI hay không, người làm công nghệ sẽ luôn gặp phải. Không có AI thì cũng code không tốt do thiết kiến thức, kinh nghiệm, mất thời gian trong việc refactor và xử lý lỗi. Nhiều người thì bê nguyên code của người khác về rồi gọt nó cho tới khi nó work.
AI cũng vậy thôi, tất cả phụ thuộc vào thái độ của người thực thi khi tiếp cận công việc của mình. Bạn dùng AI mà không có trách nhiệm tự bù lại kiến thức cho những phần nó code mà mình không hiểu gì, không tìm setup chỉn chu unit testing, CI/CD, version control,... thì lỗi thuộc về mình chứ không thể trách công cụ.
Dĩ nhiên, có điều là AI coding ngày sẽ càng có xu hướng hiện thực hoá ý tưởng của người dùng với ít bối cảnh và công sức nhất có thể. Lovable, Emergent, v0,... được sinh ra để làm vậy. Nhưng điều đó không có nghĩa là mình bỏ đi trách nhiệm "nghiêm túc với nghề".
3. Nguyên tắc tránh AI Slop
1. Context, đặc biệt chú ý đến context
Yêu cầu AI thực thi mà không cung cấp context tốt là sai lầm lớn nhất. Đưa cho AI môi trường thực tế của mình và các thông tin xoay xung quanh vấn đề, tính năng, mục tiêu,... mà mình muốn đạt được là key để output chất lượng.
Cần bao gồm:
- Pattern đang có trong codebase
- Thư viện đang dùng
- Quy ước đặt tên của team
- Use case cụ thể
Cách team AI làm: File CLAUDE.md cho Claude Code biết về stack, pattern, và preferences trước khi nó viết bất cứ gì. Khi prompt thì luôn cung cấp bối cảnh rõ ràng.
Ví dụ, khi gặp lỗi và muốn AI giải quyết, hãy cung cấp:
- User Story: Cách mà lỗi đó đã xảy ra về phía hành trình người dùng. Đã đi qua các bước như nào, tương tác ở đâu. Điều này cung cấp bối cảnh về cách để replicate lỗi đó.
- Log lỗi: Cung cấp log lỗi chi tiết, bao gồm stack trace, thông tin về môi trường (browser, deployment environment),... Điều này giúp AI hiểu rõ hơn về gốc rễ của lỗi, và các điều kiện xung quanh lỗi.
Case thực tế Bạn dùng Bun thay vì NodeJS, nhưng prompt không nói gì về môi trường runtime. Đa phần khi AI code với Javascript, nó sẽ mặc định assume NodeJS do NodeJS phổ biến nhất trong training data của LLM.
Bạn gặp lỗi trong build command, AI check thì vẫn thấy "npm run build" là đúng, không hiểu sao lại sai. Khi đó, phải cung cấp bối cảnh về runtime của mình từ đầu, không thì AI sẽ có xu hướng tìm lỗi không tồn tại ở những nơi khác, dẫn tới hỏng codebase.
2. Giới hạn scope thực thi
Sai lầm: Yêu cầu mở - "Thêm yếu tố tính điểm giống Duolingo đi". Điều này mời gọi over-engineering, feature creep, architectural mess. Khi bạn để lại những khoảng trống lớn phó mặc cho AI điền vào, dĩ nhiên là rất mừng khi nó điền tốt, đúng ý mình. Đồng thời, bạn phải kỳ vọng là nó cũng có thể điền không ra gì.
Cách sửa: Nói rõ những gì mình KHÔNG muốn. Thay vì nói AI implement feature tính điểm, thì hãy thử prompt rộng nhưng làm rõ về "Negative Prompting" - những gì mình không muốn, những gì mình muốn bỏ qua, những gì mình muốn giữ đơn giản. Điều này giúp AI hiểu rõ ràng về giới hạn và tránh việc thêm thắt không cần thiết.
Ví dụ: "Hãy thêm yếu tố tính điểm như Duolingo. Lưu ý rằng không được thêm dependency mới, phải theo pattern hiện có trong codebase, không tự động thêm tính năng khác như streak hay punishment."
3. Thực thi theo từng bước
Sai lầm: One-shot prompting - "Thêm hệ thống tính điểm hoàn chỉnh giống Duolingo đi." Mình kỳ vọng AI làm hết tất cả cho tới khi nhận được kết quả hoàn chỉnh. Toàn bộ những phần ở giữa mình không nắm được. Nó ra quyết định là vì sao, kiến trúc là gì, có dependency nào,... mình đều không biết.
Điều này sinh ra vấn đề giống như việc thiếu context, nghĩa là mình sẽ phải chịu trách nhiệm cho những lỗ hổng mà mình phó mặc công cụ điền vào.
Cách sửa: Chia nhỏ khối lượng công việc thành các bước và cộng tác với AI để xử lý từng bước đó. Điều này giúp mình:
- Kiểm soát được kiến trúc, tech stack của sản phẩm
- Sở hữu cách giải quyết vấn đề và quyết định được đưa ra
- Tăng level kiến thức và tư duy một cách nhanh chóng
Ví dụ về các bước tiếp cận khi muốn thêm tính điểm cho người dùng:
- Mô tả mong muốn cụ thể cho sản phẩm và sử dụng Duolingo làm high-level concept reference.
Ví dụ: "Tôi muốn có một hệ thống tính điểm cho người dùng dựa trên số lượng bài tập họ hoàn thành mỗi ngày. Điểm sẽ được cộng dồn hàng ngày và reset vào cuối tuần. Mỗi bài tập hoàn thành sẽ cộng 10 điểm vào tổng điểm của người dùng. Hoàn thành bài tập liên tiếp sẽ tạo ra 'streak', nghĩa là điểm thưởng cho chuỗi sẽ tăng cận biên."
- Tham khảo AI để cùng lên kế hoạch chi tiết, đặc biệt là thống nhất về kiến trúc và tech stack khi triển khai, cũng như các edge case cần note để xử lý.
Ví dụ: "Hãy giúp tôi research sâu để lên kế hoạch chi tiết để triển khai hệ thống tính điểm này. Tôi đang nghĩ về việc sử dụng Node.js cho backend và MongoDB cho database. Hãy xác định cấu trúc dữ liệu cho người dùng và điểm số, cũng như cách xử lý các edge case như người dùng bỏ lỡ một ngày và mất streak."
- Yêu cầu thực thi từng phần một, commit và review từng phần một. Điều này giúp mình bắt slop sớm, và có version control rõ ràng để retrace khi cần.
Ví dụ: Thay vì "Thêm tính năng authentication đi", thì mình chia nhỏ thành "Thêm login screen và proxy mọi page khác ngoài landing page", "Lưu session token vào cookie", "Thêm tính năng check trạng thái đăng nhập". Mỗi phần đều review được. Bắt slop sớm.