Khi Nào Không Nên Dùng AI Để Viết Code?
AI viết code rất nhanh. Nhưng nhanh không luôn đồng nghĩa với đúng, an toàn, hay đáng tin. METR cho thấy trong một thử nghiệm với 16 developer giàu kinh nghiệm xử lý 246 issue thực tế, nhóm được phép dùng AI lại chậm hơn 19% so với khi làm thủ công (METR, 2025). Điều đó không có nghĩa bạn nên bỏ AI. Nó chỉ có nghĩa là có những tình huống mà giao hẳn phần viết code cho AI là quyết định tệ.
Điểm chính
- AI không phải lúc nào cũng giúp code nhanh hơn; METR ghi nhận mức chậm hơn 19% trên issue thực tế.
- Các đoạn code liên quan bảo mật, business logic và kiến trúc thường cần bạn tự làm thủ công.
- Câu hỏi đúng không phải “AI có viết được không?” mà là “nếu sai, ai sẽ trả giá?”.
Vì sao “AI viết được” không có nghĩa là “nên giao cho AI”?
METR cho thấy developer thường đánh giá quá cao lợi ích của AI: trước bài test họ kỳ vọng AI giúp nhanh hơn 24%, nhưng kết quả thực tế lại là chậm hơn 19% (METR, 2025). Điều đó cho thấy AI coding dễ tạo ảo giác tiến bộ. Bạn thấy output hiện ra rất nhanh, nhưng phần hiểu, kiểm tra và sửa hậu quả có thể còn lâu hơn.
Vấn đề cốt lõi là AI đoán pattern rất giỏi, nhưng không chịu trách nhiệm cho production. Stack Overflow Developer Survey 2024 cho biết 66,1% developer khó chịu vì họ không tin hẳn output của AI, còn 64,6% nói AI thiếu context của codebase (Stack Overflow, 2024). Vậy nên, nếu một task đòi hỏi hiểu hệ thống thật sự, bạn nên cẩn thận trước khi để AI cầm lái.
Theo Stack Overflow Developer Survey 2024, 64,6% developer cho rằng điểm yếu lớn của AI coding tools là thiếu context về codebase hiện tại. Khi công cụ không thấy đủ business rule, dependency và ràng buộc nội bộ, output “trông đúng” vẫn có thể sai ngay ở chỗ quan trọng nhất.
1. Khi code đụng vào bảo mật hoặc dữ liệu nhạy cảm
Một nghiên cứu tại CCS cho thấy ở bài tập SQL, nhóm dùng AI sinh lời giải dính SQL injection tới 36%, trong khi nhóm không dùng AI chỉ là 7% (CCS, 2023). Đây là lý do rõ nhất để không giao hẳn những đoạn auth, permission, token, query builder hay input validation cho AI. Những chỗ này sai một lần là đủ mệt.
Nếu bạn dùng AI ở đây, hãy dùng nó để gợi ý checklist, không phải để viết bản cuối. Bạn vẫn nên tự viết tay các đoạn truy cập dữ liệu, xác thực người dùng và kiểm soát quyền. Đặc biệt với security-sensitive code, review thủ công không phải bước thêm vào sau cùng. Nó là bước chính.
Tôi thấy một bẫy phổ biến là developer chỉ nhìn syntax và quên mất mô hình đe dọa. Nhưng lỗ hổng bảo mật hiếm khi lộ ra ở bề mặt code. Nó nằm ở giả định sai: ai gọi endpoint này, dữ liệu đến từ đâu, và nếu input bị sửa ác ý thì chuyện gì xảy ra?
2. Khi bạn chưa hiểu rõ codebase hiện tại
Theo Stack Overflow Developer Survey 2024, 64,6% developer nói AI tools thiếu context về codebase. Vì vậy, nếu chính bạn còn chưa hiểu flow hiện tại, để AI viết tiếp thường chỉ làm bạn có cảm giác mình đã hiểu. Thực tế thì chưa.
AI có thể sinh ra function mới rất trơn tru. Nhưng nó không biết vì sao service này từng được tách kỳ lạ, vì sao một validation phải đặt trước bước mapping, hay vì sao hệ thống đang giữ lại một edge case tưởng như vô lý. Những chi tiết đó chỉ lộ ra khi bạn đọc code cũ, đọc ticket cũ và hiểu lịch sử thay đổi.
Theo khảo sát Stack Overflow 2024, chỉ 2,3% developer nói họ “highly trust” độ chính xác của output từ AI tools. Mức độ tin thấp như vậy là lời nhắc hợp lý: nếu task phụ thuộc mạnh vào context nội bộ, AI nên là phụ tá đọc nhanh, không phải người viết thay bạn.
3. Khi bạn đang debug bug khó hoặc lỗi production
SWE-bench cho thấy trên 2.294 issue thực tế từ 12 repo Python, model tốt nhất trong paper gốc chỉ giải được 1,96% task (SWE-bench, 2023). Điều đó không có nghĩa AI vô dụng khi debug. Nó chỉ cho thấy bug thật ở cấp repo thường khó hơn rất nhiều so với việc hoàn thành một snippet đẹp trong editor.
AI khá ổn ở việc gợi ý nguyên nhân có thể có. Nhưng khi lỗi dính tới dữ liệu thật, timing, race condition, cache, state cũ hay log lộn xộn, bạn vẫn phải tự điều tra. Bạn cần timeline, metrics, query, request payload và hiểu hệ thống đang chạy ngoài đời thế nào. AI không tự đi lần log thay bạn được.
Trong những lúc debug căng nhất, thứ giúp nhanh nhất thường không phải prompt hay hơn. Nó là việc quay lại câu hỏi gốc: lỗi bắt đầu từ lúc nào, ai bị ảnh hưởng, và thay đổi nào xuất hiện ngay trước đó? AI có thể giúp bạn đỡ sót checklist. Nhưng root cause thì vẫn phải do bạn lần ra.
4. Khi code chạm vào logic nghiệp vụ quan trọng
Stack Overflow 2024 cho thấy 66,1% developer không tin hẳn output của AI ở nơi làm việc. Với business logic quan trọng như tính tiền, chấm công, phân quyền, hoàn tiền hay áp khuyến mãi, mức độ nghi ngờ đó là hoàn toàn hợp lý. Những chỗ này đúng cú pháp thôi là chưa đủ.
AI thường sinh code theo pattern phổ biến nhất. Nhưng business rule thật lại đầy ngoại lệ: gói cũ khác gói mới, khách hàng enterprise khác self-serve, hợp đồng cũ khác hợp đồng sau ngày A. Nếu bạn giao logic này cho AI quá sớm, bạn đang lấy xác suất trung bình của Internet để quyết định một quy tắc rất riêng của sản phẩm mình.
Một câu hỏi đơn giản để tự kiểm tra là: nếu đoạn code này sai, ai sẽ phát hiện đầu tiên? Nếu câu trả lời là kế toán, khách hàng hoặc production alert, vậy bạn nên tự viết tay, hoặc ít nhất tự phác logic trước rồi mới để AI giúp dọn câu chữ.
5. Khi bạn đang đưa ra quyết định kiến trúc hoặc refactor lớn
METR 2025 cho thấy developer có thể cảm thấy AI giúp mình nhanh hơn ngay cả khi kết quả thực tế ngược lại. Với quyết định kiến trúc, cái giá của ảo giác đó còn cao hơn nhiều. Chọn sai boundary, tách module sai chỗ hoặc refactor nhầm abstraction có thể làm đội chậm hàng tháng.
AI rất hợp để đề xuất vài phương án. Nhưng chọn phương án nào thì vẫn cần con người cân đối trade-off: năng lực đội ngũ, cách deploy, chi phí migration, thứ tự rollout, và mức độ chịu lỗi của hệ thống. Đây là chỗ bạn cần suy nghĩ thủ công nhiều nhất. Muốn nhanh thật à? Hãy để AI giúp tổng hợp option, còn quyết định cuối nên do bạn và team chịu trách nhiệm.
Vậy AI nên dùng tốt nhất ở đâu?
METR cho thấy AI không luôn tăng tốc ở task thực tế, nhưng điều đó không phủ nhận giá trị của nó. AI vẫn rất hữu ích cho boilerplate, test scaffolding, đổi tên, viết script ngắn, giải thích API, tạo draft tài liệu hoặc gợi ý test case. Nói ngắn gọn: hãy giao cho AI phần lặp lại, còn giữ lại cho mình phần đòi hỏi hiểu ngữ cảnh và chịu trách nhiệm cuối cùng.
Câu hỏi thường gặp
Có phải bài này đang khuyên ngừng dùng AI để code?
Không. Stack Overflow 2024 cho thấy phần lớn developer vẫn đang dùng hoặc thử dùng AI, nhưng chỉ 2,3% nói họ highly trust kết quả. Thông điệp ở đây không phải “đừng dùng”, mà là “đừng giao hẳn những phần sai một ly đi một dặm”.
Junior dev có nên dùng AI coding không?
Có, nhưng càng mới càng cần dùng có kỷ luật. Khi chỉ 64,6% developer phàn nàn rằng AI thiếu context codebase, bạn càng không nên coi output là lời giải cuối. Junior có thể dùng AI để học nhanh hơn, nhưng vẫn nên tự giải thích lại từng đoạn code trước khi commit.
Làm sao biết một task nên giao cho AI hay tự viết?
Hãy tự hỏi ba câu: task này có đụng bảo mật không, có phụ thuộc context nội bộ không, và nếu sai thì chi phí sửa là gì? Nếu một trong ba câu trả lời là “cao”, khả năng lớn bạn nên tự làm thủ công trước. AI lúc đó nên đóng vai reviewer phụ, không phải tác giả chính.
Kết luận
Đừng hỏi “AI có viết được không?”. Hãy hỏi “đoạn này có đáng để mình tin AI đến mức nào?”. Với bảo mật, business logic, debugging khó, context nội bộ và quyết định kiến trúc, câu trả lời thường là: không đủ để giao toàn bộ. Dùng AI như một copilot thì rất mạnh. Dùng AI như người chịu trách nhiệm thay bạn thì rất dễ trả giá.
Nguồn tham khảo
- METR — Báo cáo
Early 2025 AI experienced OS dev study: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ - Stack Overflow Developer Survey 2024 — Mục
AI: https://survey.stackoverflow.co/2024/ai - SWE-bench paper — Bài báo
SWE-bench: https://arxiv.org/abs/2310.06770 - CCS 2023 — Bài nghiên cứu
Do Users Write More Insecure Code with AI Assistants?: https://arxiv.org/html/2211.03622
Bình luận