Yêu cầu nghe rất rõ: làm luồng nhập dữ liệu an toàn hơn. Có tên tệp, có hiện tượng lỗi, có cả đề nghị viết kiểm thử. Chỉ từ chừng đó, một mô hình đã có thể tạo ra bản sửa trông khá thuyết phục. Nhưng phần quyết định bản sửa ấy có an toàn hay không lại nằm ở nơi khác: tác vụ retry cũ, tài liệu xử lý sự cố, ranh giới tenant, kiểu CSV lạ mà một khách hàng vẫn gửi, và cảnh báo chỉ bật sau nửa đêm.
Đó là giới hạn đầu tiên cần nhìn thẳng: prompt không phải là hệ thống. Nó chỉ là một lời yêu cầu từ một góc nhìn. Lời yêu cầu có thể kể đúng vấn đề đang lộ ra, nhưng thường không mang đủ những ràng buộc khiến một giải pháp trở nên an toàn. AI làm tốt trong chiếc khung được trao; nó kém hơn nhiều ở việc nhận ra chiếc khung ấy đang thiếu cạnh nào.
Mã nguồn thật giúp lấp khoảng trống đó. Các import, nơi hàm được gọi, kiểm thử, feature flag, schema và nhánh xử lý lỗi kể một câu chuyện dài hơn câu chữ trong prompt. Có khi bản sửa đã nằm trong một helper sẵn có. Có khi thay đổi phải đặt ở usecase chứ không phải handler. Cũng có khi lỗi người dùng nhìn thấy đến từ hình dạng dữ liệu, chẳng liên quan mấy đến hàm được nhắc tên. Không đọc nguồn, mô hình chỉ đang đoán hình từ bóng.
Rồi còn bằng chứng vận hành. Nhật ký, trace, tác vụ thất bại, bản ghi trong cơ sở dữ liệu, ảnh chụp trình duyệt và nguyên văn thông báo lỗi giữ cho lời giải thích bám vào thực tế. Một câu trả lời có thể rất trôi chảy mà vẫn kể sai chuyện đã xảy ra. Thay đổi càng quan trọng, ta càng cần chạm vào hệ thống đang chạy trước khi đụng tới môi trường thật.
Ràng buộc nghiệp vụ là lớp prompt thường không tự mang theo. AI có thể suy ra các mẫu phổ biến, nhưng không tự biết bất biến nào đội ngũ xem là không được phép phá. Nó không biết dòng tiền phải được ghi theo kiểu append-only, dữ liệu tenant phải được giới hạn ngay trong truy vấn repository, một mobile client cũ vẫn đọc field sắp bỏ, hay kill switch tồn tại vì một sự cố trước đây từng ảnh hưởng người dùng thật.
Vì thế, context engineering không đơn giản là viết prompt dài hơn. Viết dài có thể hữu ích, nhưng việc khó hơn là chọn đúng bằng chứng cho AI dựa vào: đặc tả, kiểm thử đang thất bại, các tệp liên quan, nhật ký tại thời điểm lỗi. Ta cũng cần yêu cầu nó nói rõ phần chưa chắc, thay vì lấp chỗ trống bằng giọng điệu tự tin.
Phán đoán của con người vẫn là phần chịu lực. Có người phải quyết định câu trả lời được tạo ra có hợp với hệ thống mà mình thực sự sở hữu hay không. Việc ấy không phải một cái gật đầu cho có ở cuối quy trình. Nó bắt đầu từ cách đặt câu hỏi, tiếp tục ở việc chọn nguồn, từ chối đường tắt nghe hợp lý nhưng không an toàn, rồi khép lại bằng kiểm chứng. Con người không nhất thiết phải gõ từng dòng; trách nhiệm thì vẫn phải ở gần.
Một thói quen tốt là buộc câu trả lời quay lại chỉ rõ nền tảng của nó. Tệp nào chứng minh nhận định này? Kiểm thử nào sẽ hỏng nếu bỏ bản sửa? Dòng nhật ký nào xác nhận hiện tượng? Quy tắc nghiệp vụ nào bảo vệ ca biên? Khi chưa chỉ được về bằng chứng, đó mới là một giả thuyết nháp, chưa phải kế hoạch triển khai.
AI hữu ích hơn khi ta không bắt prompt gánh quá sức chứa của nó. Prompt mở cuộc trao đổi; bằng chứng của hệ thống và người chịu trách nhiệm mới quyết định câu trả lời có thật sự thuộc về nơi ấy hay không.