Vấn đề cốt lõi
Một coding agent (Claude Code, Cursor, Copilot Agent, Cline...) không "biết" codebase của bạn. Nó chỉ biết những gì bạn nạp vào context window ở thời điểm chạy. Cùng một model, cùng một prompt "viết hàm tính thuế VAT", nhưng nếu agent không thấy file pricing.py hiện có, nó sẽ bịa ra một cấu trúc mới, đặt sai tên biến, và bạn mất 30 phút sửa. Đó không phải lỗi model — đó là lỗi context.
Prompt Engineering = viết câu lệnh tốt. Context Engineering = thiết kế toàn bộ thông tin mà agent nhìn thấy: code liên quan, quy ước dự án, ví dụ mẫu, lịch sử hội thoại, kết quả tool. Với coding agent, context engineering quan trọng hơn nhiều, vì code là hệ thống có ràng buộc chặt.
Ví dụ cụ thể
Bạn yêu cầu: "Thêm endpoint xóa user."
- Không có context: agent tạo
DELETE /user, dùng raw SQL, không có auth check, đặt tên khác quy ước dự án. - Có context (agent thấy
routes/user.py, thấy bạn dùng decorator@require_admin, thấy repository pattern): agent tạoDELETE /users/{id}đúng chuẩn, gọiUserRepository.delete(), thêm@require_admin. Chạy được ngay.
Bốn nguồn context của một coding agent
- System / project instructions — file
CLAUDE.md,.cursorrules: quy ước bền vững. - Retrieved code — file agent đọc/grep được lúc chạy.
- Conversation history — yêu cầu và phản hồi trước đó trong phiên.
- Tool results — output của test, lint,
git diff, log lỗi.
Khung tư duy: Signal-to-Noise
Mỗi token trong context có thể là tín hiệu (giúp agent quyết định đúng) hoặc nhiễu (làm loãng, gây nhầm). Mục tiêu không phải nhồi càng nhiều càng tốt, mà tối đa tỷ lệ tín hiệu/nhiễu.
Context tốt = (code liên quan trực tiếp)
+ (quy ước cần tuân)
+ (ví dụ đúng 1-2 cái)
- (file không liên quan)
- (lịch sử lạc đề)
Các bước để bắt đầu tư duy đúng
- Trước mỗi yêu cầu, tự hỏi: "Agent cần THẤY gì để làm đúng?"
- Liệt kê 2-4 file/hàm liên quan trực tiếp.
- Xác định 1-2 quy ước bắt buộc (naming, layer, error handling).
- Nếu có mẫu chuẩn, chỉ agent tới một ví dụ đã đúng trong repo.
- Loại bỏ mọi thứ không phục vụ tác vụ hiện tại.
Checklist "đủ context chưa?"
- [ ] Agent thấy code sẽ bị ảnh hưởng?
- [ ] Agent biết quy ước đặt tên / cấu trúc?
- [ ] Có ví dụ mẫu để bắt chước?
- [ ] Định nghĩa "xong" rõ ràng (test pass? build ok?)
- [ ] Đã loại nhiễu không liên quan?
So sánh với cách làm cũ
Nhiều lập trình viên dùng agent như một chatbot: gõ yêu cầu, chờ code, dán vào IDE, chạy thử, thấy sai thì gõ lại. Cách này lãng phí vì mỗi vòng lặp agent vẫn thiếu bối cảnh cốt lõi. Người làm context engineering tốt thì ngược lại: họ đầu tư 2-3 phút chuẩn bị (mở đúng file, nhắc quy ước, chỉ ví dụ mẫu) để đổi lấy output đúng ngay lần đầu. Với một tính năng vừa, chênh lệch có thể là 5 lần thử so với 1 lần chạy được.
Hãy hình dung agent như một lập trình viên giỏi nhưng mới vào dự án ngày đầu tiên: rất thạo ngôn ngữ, nhưng không biết cấu trúc, quy ước hay lịch sử của bạn. Bạn sẽ không giao việc cho người đó rồi bỏ mặc — bạn chỉ cho họ file liên quan, nói rõ chuẩn, đưa một ví dụ. Context engineering chính là làm điều đó một cách có hệ thống, mỗi lần.
Sai lầm thường gặp
- Nhồi cả repo vào context — tưởng nhiều là tốt, thực ra làm loãng tín hiệu và tốn token, agent dễ bám vào chi tiết sai.
- Cho rằng agent "nhớ" cấu trúc dự án — nó không nhớ gì giữa các phiên nếu bạn không ghi ra file chỉ dẫn.
- Đổ lỗi cho model khi agent bịa — phần lớn trường hợp là do thiếu context, không phải model kém.
- Prompt hoàn hảo nhưng context rỗng — câu lệnh hay đến mấy cũng vô nghĩa nếu agent không thấy code cần sửa.
- Coi agent như người biết tuốt — hãy đối xử với nó như đồng nghiệp mới: cần được chỉ đường bằng thông tin, không phải bằng niềm tin.