1) Hallucinated Libraries & APIs
AI có thể tự tin gọi một hàm hoặc thư viện không hề tồn tại
Đây là một trong những điểm mù phổ biến nhất khi dùng AI để code. AI có thể viết ra tên package, method, option cấu hình hoặc tham số “nghe rất hợp lý”, nhưng thực tế lại không có thật. OpenAI cũng nói rõ rằng mô hình có thể tạo ra thông tin không chính xác, thậm chí nghe rất tự tin khi đang sai.
Điều này không chỉ là cảm giác. Một nghiên cứu lớn về package hallucination trong code do LLM sinh ra đã chạy 576.000 mẫu sinh code và cho thấy tỷ lệ package ảo trung bình ít nhất 5,2% ở mô hình thương mại và 21,7% ở mô hình mã nguồn mở, đồng thời ghi nhận hơn 205.000 tên package ảo khác nhau. Nghĩa là đây là một hiện tượng có thật, có quy mô, và đủ lớn để gây rủi ro thực tế cho đội kỹ thuật.
Ví dụ: bạn hỏi AI cách upload file bằng một SDK mới. AI gợi ý một hàm như uploadFileWithChecksum() hoặc một option như autoRetryPolicy: "balanced". Tên hàm rất hợp lý, cách dùng rất mượt, nhưng IDE không autocomplete và docs chính thức cũng không có. Nếu không kiểm tra lại sớm, bạn có thể mất hàng giờ debug thứ vốn chưa từng tồn tại.
Cách tự bảo vệ: mọi package, API, method hoặc config lạ do AI đưa ra nên được kiểm tra ngay bằng docs chính thức, changelog hoặc autocomplete trong IDE trước khi dùng thật.
Nguồn nên đọc:
1. OpenAI Help Center: hiện tượng hallucination và khuyến nghị phải kiểm tra lại thông tin.
2. Paper We Have a Package for You! về package hallucination trong code-generating LLMs.
2) Architecture vs. Code-Level Evaluation
Chạy được chưa chắc đã là đúng cách
Khi mới dùng AI, nhiều người có xu hướng kiểm tra một điều rất đơn giản: “Code có chạy không?” Nhưng trong kỹ thuật phần mềm, câu hỏi đắt tiền hơn là: “Đây có phải cách giải đúng cho bài toán này không?” AI thường trả lời tốt trong phạm vi câu hỏi được đặt ra, nhưng không tự động nhắc rằng có thể bạn đang giải sai bài toán ở cấp độ kiến trúc.
Một cách nhìn rất thực tế là benchmark coding hiện nay chủ yếu đo khả năng giải issue hoặc sửa task trong một khung nhất định. Chẳng hạn, SWE-bench Verified là một tập 500 bài toán đã được con người lọc lại để đánh giá khả năng xử lý issue phần mềm. Nó rất hữu ích để đo “giải task kỹ thuật”, nhưng bản thân benchmark đó không phải là thước đo đầy đủ cho việc chọn kiến trúc hệ thống. Ngay cả Anthropic cũng lưu ý rằng chỉ riêng cấu hình hạ tầng có thể làm benchmark agentic coding dao động vài điểm phần trăm, đôi khi còn lớn hơn khoảng cách giữa các model top đầu.
Ví dụ: bạn hỏi AI cách đồng bộ dữ liệu đơn hàng giữa hai hệ thống. AI đưa ra một cron job polling mỗi 30 giây. Cách đó có thể chạy được, dễ demo, dễ test. Nhưng trong bối cảnh thật, hướng đúng có thể là event-driven hoặc outbox pattern để tránh trễ dữ liệu, lỗi lặp và khó audit. Ở đây, AI không sai về cú pháp. Nó chỉ có thể đang sai ở cấp độ tư duy giải pháp.
Cách tự bảo vệ: sau khi AI viết code xong, hãy luôn hỏi thêm một vòng: “Có pattern chuẩn nào cho use case này không?”, “Trade-off của cách này là gì?”, “Nó có scale được không?”, “Nó có hợp với kiến trúc hiện tại của team không?”
Nguồn nên đọc:
1. SWE-bench Verified: mô tả đây là tập 500 bài toán đã được con người xác nhận.
2. Anthropic Engineering: benchmark coding có thể bị nhiễu bởi cấu hình hạ tầng.
3) Prompts Shape the Quality Ceiling
Kết quả tệ nhiều khi không phải do model yếu, mà do prompt quá mơ hồ
OpenAI hướng dẫn rất rõ rằng prompt nên rõ, cụ thể, đủ ngữ cảnh, và thường cần chỉnh dần theo phản hồi nhận được. Nói cách khác, nhiều khi chất lượng đầu ra chạm trần của prompt trước khi chạm trần của model.
Điều này cũng có bằng chứng thực nghiệm trong code generation. Paper về Structured Chain-of-Thought Prompting for Code Generation cho thấy chỉ cần thay đổi cách hướng dẫn mô hình suy nghĩ, hiệu năng đã có thể tăng đáng kể; cụ thể, SCoT prompting cải thiện Pass@1 lên tới 13,79% so với CoT prompting trong các thiết lập của nghiên cứu.
Ví dụ: câu “Viết middleware auth cho tôi” thường chỉ ra một đoạn code chung chung. Nhưng nếu bạn ghi rõ: “Node 22, Express 5, JWT RS256, không thêm dependency mới, phải xử lý token hết hạn và malformed token, log không lộ dữ liệu nhạy cảm, giữ đúng convention hiện tại của team”, kết quả thường tốt hơn hẳn.
Cách tự bảo vệ: hãy coi prompt như một bản đặc tả ngắn. Nêu rõ ngôn ngữ, framework, version, input, output, constraint, edge case, và cả những điều “không được làm”.
Nguồn nên đọc:
1. OpenAI Help Center: prompt nên rõ, cụ thể, và cần iterative refinement.
2. Paper Structured Chain-of-Thought Prompting for Code Generation.
4) Working Outside Your Domain
Dùng AI ở mảng mình chưa vững là lúc dễ bị “lừa” nhất
Nếu bạn không đủ nền tảng để phản biện đầu ra, bạn cũng khó biết khi nào AI đang sai. Đây là lý do điểm mù “làm việc ngoài domain chuyên môn” rất nguy hiểm. Một backend engineer nhờ AI viết crypto, một frontend engineer nhờ AI tối ưu database, hay một junior dev nhờ AI viết policy cloud đều có chung một rủi ro: AI nghe rất thuyết phục, nhưng người dùng không đủ nền để bắt lỗi.
Anthropic đã làm một thử nghiệm ngẫu nhiên có đối chứng với 52 người tham gia và phát hiện rằng nhóm dùng AI khi học một thư viện Python mới có điểm mastery thấp hơn 17% so với nhóm tự code bằng tay. Họ cũng nhấn mạnh rằng cách dùng AI rất quan trọng: những người dùng AI để hỏi thêm, xin giải thích và xây hiểu biết thì giữ bài tốt hơn nhóm chủ yếu để AI sinh code hộ.
Ví dụ: một kỹ sư chưa từng tối ưu SQL hỏi AI cách làm query nhanh hơn. AI đề xuất thêm index hoặc rewrite query. Đề xuất đó có thể đúng, cũng có thể sai. Nhưng nếu người dùng không hiểu execution plan, cardinality và trade-off read/write, họ gần như không có cách nào tự tin biết nên tin chỗ nào.
Cách tự bảo vệ: ở mảng ngoài chuyên môn, hãy dùng AI để học, không dùng AI để tin ngay. Và nếu code đi vào production, nên có domain owner hoặc người nhiều kinh nghiệm hơn review lại.
Nguồn nên đọc:
1. Anthropic Research: How AI assistance impacts the formation of coding skills.
5) Training Cutoffs & Outdated Advice
AI có thể đang cho bạn lời khuyên “đúng ngày xưa”, nhưng sai với stack hiện tại
Một câu trả lời nghe rất trôi chảy không có nghĩa là nó còn đúng với version bạn đang dùng. Các hệ sinh thái như frontend, cloud, data hoặc Python đổi rất nhanh. Chỉ riêng vài ví dụ gần đây: React 19 ra mắt ngày 5/12/2024, Next.js 15 stable ra mắt ngày 21/10/2024, còn Pydantic V2 có hẳn một migration guide chính thức vì có nhiều breaking changes và thay đổi API đáng kể.
Node cũng cho thấy nhịp thay đổi version rất nhanh. Tại thời điểm hiện tại, trang release chính thức ghi rõ v25 là Current, v24 là Active LTS, còn v22 là Maintenance LTS. Nghĩa là nếu bạn hỏi AI mà không nói rõ version, nó rất dễ trộn kiến thức giữa nhiều thời điểm khác nhau.
Ví dụ: bạn đang dùng Pydantic V2 nhưng AI lại viết theo phong cách V1. Ý tưởng tổng thể có thể đúng, nhưng tên method, cách validate, namespace import hoặc cách serialize đã thay đổi. Kết quả là team phải sửa lại, repo lẫn phong cách cũ mới, và review mất thời gian hơn.
Cách tự bảo vệ: khi prompt về code, luôn ghi rõ framework và version. Ví dụ: “Viết theo React 19”, “Tương thích Next.js 15”, “Dùng Pydantic V2, tránh API V1”.
Nguồn nên đọc:
(TBU)
6) Compounding Small Errors
Nhiều lỗi nhỏ nối tiếp nhau có thể đẩy cả hướng đi lệch hẳn
Điểm mù này rất hay gặp trong các phiên làm việc dài với AI. Một giả định sai nhỏ ở bước đầu chưa chắc gây hậu quả ngay. Nhưng nếu các bước sau tiếp tục xây trên giả định đó, toàn bộ hướng triển khai có thể đi lệch mà bạn không nhận ra. Ta có thể gọi đây là hiện tượng “compounding small errors”.
Nghiên cứu Lost in the Middle cho thấy mô hình có thể dùng thông tin kém đi khi thông tin quan trọng nằm ở giữa một ngữ cảnh dài. Hiệu năng thường tốt hơn khi thông tin liên quan nằm ở đầu hoặc cuối context, và giảm rõ khi nó bị “chôn” vào giữa. Điều này giải thích vì sao trong các phiên làm việc dài, AI có thể dần bỏ quên constraint quan trọng từ ban đầu.
Ví dụ: ở đầu phiên bạn dặn rất rõ “không thêm Redis”, “không thêm queue”, “giữ monolith hiện tại”. Sau nhiều lượt hỏi, AI bắt đầu gợi ý background job, event bus, cache layer. Không hẳn vì nó cố tình làm sai, mà vì các ràng buộc ban đầu đã dần bị chìm trong cuộc hội thoại dài.
Cách tự bảo vệ: sau vài lượt trao đổi, nên dán lại yêu cầu chính. Nhắc lại constraint, nhắc lại version, nhắc lại điều cấm làm. Đừng giả định AI sẽ giữ nguyên mọi thứ qua cả một phiên dài.
Nguồn nên đọc:
1. Lost in the Middle trên ACL Anthology.
7) Skill Atrophy & Over-Reliance
Kỹ năng không mất ngay, nhưng sẽ mòn dần nếu mình ngừng tự làm
Đây là một rủi ro rất khó nhận ra. Khi dùng AI thường xuyên, bạn vẫn có thể thấy mình làm việc nhanh hơn. Nhưng nếu hầu hết việc phân tích, phác thảo giải pháp, viết code và gỡ lỗi đều được AI làm hộ, kỹ năng cốt lõi của bạn có thể yếu dần mà không có tín hiệu cảnh báo rõ ràng. Kỹ năng không biến mất ngay, mà bị bào mòn từ từ.
Kết quả từ nghiên cứu của Anthropic cũng đi cùng hướng đó. Nhóm dùng AI khi học một thư viện Python mới có điểm mastery thấp hơn 17%, trong khi lợi ích tăng tốc hoàn thành bài không đạt ngưỡng ý nghĩa thống kê. Nói cách khác, nếu mục tiêu là thật sự nắm được kỹ năng mới, việc để AI làm hộ quá nhiều có thể khiến bạn “xong việc” nhưng không “xây năng lực”.
Ví dụ: trước đây bạn có thể tự lần bug từ log tới nguyên nhân gốc. Sau vài tháng quá quen với AI, bạn vẫn hoàn thành task nhanh, nhưng lại ngày càng khó tự giải thích vì sao giải pháp hiện tại là đúng, hoặc khó viết lại từ đầu nếu không có AI ngồi cạnh.
Cách tự bảo vệ: chủ động giữ lại một phần “tập cơ” cho bản thân. Thỉnh thoảng tự giải một bài không dùng AI. Thỉnh thoảng tự debug đến gốc. Và nếu bạn không thể giải thích solution bằng lời của mình, coi như bạn chưa review xong.
Nguồn nên đọc:
1. Anthropic Research về tác động của AI tới việc hình thành kỹ năng coding.
8) The “Lost in the Middle” Problem
Có context dài không có nghĩa là AI dùng tốt toàn bộ context đó
Đây là điểm rất nhiều người hiểu nhầm. Mô hình có context window lớn không đồng nghĩa với việc nó dùng tốt mọi thông tin nằm trong context đó. Lost in the Middle chỉ ra rằng hiệu năng thường cao nhất khi thông tin quan trọng nằm ở đầu hoặc cuối ngữ cảnh, và giảm đi khi thông tin đó nằm ở giữa.
Bên cạnh đó, chuyện “ghi nhớ qua phiên làm việc” còn phụ thuộc vào từng công cụ và thiết lập. ChatGPT hiện có saved memories, reference chat history và project memory; Projects trong ChatGPT có built-in memory cho các chat và file trong project. Claude Code cũng có hai hệ thống memory riêng và đều được nạp ở đầu mỗi cuộc hội thoại. Vì vậy, rủi ro thật không phải là “tool nào cũng quên hết”, mà là người dùng dễ giả định sai cách mà tool đang nhớ.
Ví dụ: bạn nghĩ rằng AI “đã biết” coding style của dự án vì hai hôm trước đã trao đổi rồi. Nhưng thực tế, tuỳ công cụ và cấu hình, phiên hiện tại có thể không mang theo đầy đủ bối cảnh cũ. Kết quả là AI trả lời theo kiểu chung chung, còn bạn thì lại tưởng nó đang hiểu repo rất sâu.
Cách tự bảo vệ: đừng giả định memory đang hoạt động theo cách bạn tưởng. Trong các phiên quan trọng, hãy nhắc lại các constraint chính và xác nhận công cụ đó thực sự có memory hay repo context ở mức nào.
Nguồn nên đọc:
1. Lost in the Middle trên ACL Anthology.
2. OpenAI Projects: built-in project memory.
3. OpenAI Memory FAQ.
4. Claude Code memory docs.
9) Security & Compliance Blind Spots
Code đúng chức năng chưa chắc đã đúng về bảo mật
AI thường tối ưu để hoàn thành yêu cầu trước mắt. Nhưng “chạy được” không đồng nghĩa với “an toàn”. OWASP mô tả rất rõ rủi ro Insecure Output Handling: nếu đầu ra của LLM không được kiểm tra, làm sạch và xử lý cẩn thận trước khi đưa sang các hệ thống khác, nó có thể tạo đường cho các rủi ro downstream như thực thi lệnh, lộ dữ liệu hoặc khai thác các thành phần phía sau.
Ở cấp độ code generation, một nghiên cứu năm 2025 cho thấy phần lớn các mô hình được đánh giá vẫn sinh ra code có lỗ hổng với tỷ lệ từ 9,8% đến 42,1% tuỳ benchmark và loại lỗi bảo mật. Điều này nhắc rất rõ rằng “nhờ AI viết secure code” không có nghĩa là “secure by default”.
NIST cũng đã phát hành tài liệu riêng cho quản trị rủi ro GenAI và một community profile của SSDF cho phát triển phần mềm an toàn với GenAI. Tinh thần chung của các tài liệu này là: rủi ro GenAI phải được quản trị theo quy trình, không thể chỉ tin vào output.
Ví dụ: bạn nhờ AI viết một endpoint upload file. Endpoint hoạt động. Nhưng AI quên validate loại file, không giới hạn đường dẫn, và log ra tên file kèm dữ liệu nhạy cảm. Chạy demo thì ổn. Đưa vào production thì rủi ro lại nằm ở những chỗ “không được hỏi tới”.
Cách tự bảo vệ: các vùng như auth, crypto, input handling, secrets, PII, logging và tích hợp hệ thống bên ngoài nên luôn đi qua security review, static analysis và kiểm tra theo policy nội bộ.
Nguồn nên đọc:
1. OWASP LLM02: Insecure Output Handling.
2. Paper Guiding AI to Fix Its Own Flaws.
4. NIST GenAI Profile và NIST SP 800-218A.
10) Codebase Context Is Tool + Configuration Dependent
AI có hiểu repo của bạn hay không còn phụ thuộc vào công cụ và cách cấu hình
Nhiều người dùng AI có một giả định rất nguy hiểm: “Công cụ này chắc đang hiểu toàn bộ repo của mình.” Thực tế, điều đó phụ thuộc rất nhiều vào từng sản phẩm. GitHub Copilot nói rõ rằng repo có thể được tự động index để cải thiện câu trả lời có ngữ cảnh, và còn cho phép thêm repository custom instructions để Copilot hiểu repo tốt hơn. Điều đó cho thấy repo context là có thật, nhưng nó là thứ phụ thuộc tính năng và cấu hình, không phải mặc định vô hạn.
Với ChatGPT, Projects có built-in memory cho chat và file trong project. Với Claude Code, tài liệu chính thức nói công cụ này có thể đọc codebase, sửa file, chạy lệnh, và có các memory system được nạp vào đầu mỗi cuộc trò chuyện. Với Aider, tài liệu giải thích rằng nó dùng repo map để gửi cấu trúc quan trọng của codebase vào ngữ cảnh và còn tự kéo thêm file liên quan khi cần.
Ví dụ: bạn tưởng AI đã thấy toàn bộ repo nên chỉ hỏi “sửa bug này giúp tôi”. Nhưng thực ra tool chỉ đang thấy vài file được thêm vào chat, hoặc index chưa cập nhật, hoặc không có hướng dẫn repo-specific. Kết quả là câu trả lời nghe rất hợp lý nhưng lại dựa trên ngữ cảnh thiếu.
Cách tự bảo vệ: trước khi giao việc cho AI, hãy biết rõ công cụ đang nhìn thấy gì: file nào được thêm, repo có index chưa, memory có bật không, custom instructions có chưa, và file nhạy cảm có bị loại khỏi phạm vi hay không.
Kết lại phần “10 Critical Blind Spots”
Nếu gói gọn lại, 10 điểm mù này đều xoay quanh một ý rất quan trọng: AI không chỉ có thể sai, mà còn có thể sai theo cách khiến kỹ sư tưởng là đúng. Đó là lý do vì sao khi dùng AI để lập trình, việc quan trọng nhất không phải là “làm sao ra code nhanh hơn”, mà là “làm sao kiểm tra được điều mình chưa biết mình đang bỏ sót”.
Nguồn nên đọc:
1. GitHub Copilot repository indexing.
2. GitHub Copilot custom instructions.
3. OpenAI Projects memory.
4. Claude Code overview và memory docs.
5. Aider repo map và usage docs.
