Blog này được viết trong bối cảnh những ngày có quá nhiều luồng suy nghĩ không thể dừng lại cho đến khi tìm được một đích đến tạm gọi là “đúng” và “chuẩn” cho những khái niệm có vẻ dường như đâu đó vô tình đang bị xâu xé đến mức chỉ còn lại một nửa sự thật.

“Engineering” trong ngành phần mềm nghĩa là gì?

Thuật ngữ software engineering lần đầu được dùng chính thức tại hội nghị NATO năm 1968 khi mà ngành phần mềm đang trải qua cái gọi là software crisis: hàng loạt dự án thất bại, trễ deadline, vượt budget, deliver ra sản phẩm không đáng tin. Nguyên nhân cốt lõi là cách làm việc ad-hoc, thiếu hệ thống. (University of Nevada)

Người được ghi nhận đã đặt tên cho discipline này là Margaret Hamilton — nhà khoa học máy tính tại MIT, người phát triển phần mềm cho chương trình Apollo. Theo vài tài liệu, bà dùng chữ software engineering với chủ đích đặt để ngành phần mềm ngang bằng các ngành kỹ thuật khác. Nhưng dĩ nhiên, không phải ai cũng đón nhận cách nghĩ này – có thể vì nó quá mới, hoặc cũng có thể vì tác giả không phải đàn ông.

Định nghĩa phổ biến nhất hiện nay: software engineering là ứng dụng một cách có hệ thống, có kỷ luật, và đo lường được vào việc phát triển, vận hành, và bảo trì phần mềm. Ba từ quan trọng — có hệ thống, có kỷ luật, đo lường được — chính là thứ phân biệt engineering với coding đơn thuần, hay làm theo cảm tính.

Cũng có lẽ vì thế nên khi ghép chữ engineering vào prompt, context, harness, các tác giả muốn thể hiện quan điểm rằng: ba “thứ” này cần được làm có hệ thống, có kỷ luật, và đo lường được.

Prompt Engineering — từ học thuật đến kỹ năng mềm

Theo Py tìm hiểu, thuật ngữ prompt engineering xuất hiện lần đầu trong giới học thuật NLP khoảng 2021, khi Pengfei Liu và cộng sự công bố paper “Pre-train, Prompt, and Predict” — hệ thống hoá paradigm mới: thay vì fine-tune model cho từng task, người ta bắt đầu thiết kế prompt để “hướng dẫn” model có sẵn làm việc mình muốn. Lúc đó, đây rõ ràng là engineering — đòi hỏi hiểu biết sâu về cách model hoạt động, về cấu trúc ngôn ngữ, về template design.

Sau khi ChatGPT ra mắt cuối 2022, mọi thứ thay đổi. “Prompt engineer” bỗng trở thành job title xuất hiện trên LinkedIn. Mọi người đều đang prompt — kể cả những người không biết đó là tên gọi cái họ đang làm. Karpathy nhận xét thẳng: người ta liên tưởng prompt với “short task descriptions you’d give an LLM in your day-to-day use” — và cái liên tưởng đó không sai. Chính vì vậy, ông thích dùng context engineering hơn để mô tả việc build sản phẩm AI thật.

Context Engineering — engineering thật, sinh ra từ production

Thuật ngữ này được chính thức hoá vào giữa 2025. Tobi Lütke — CEO Shopify — tweet định nghĩa gọn: “Context engineering là nghệ thuật cung cấp đủ context để task có thể được giải quyết bởi LLM.” Andrej Karpathy đồng tình ngay và thêm vào: “Trong mọi LLM app production, context engineering là nghệ thuật và khoa học tinh tế của việc lấp đầy context window bằng đúng thông tin cần thiết cho bước tiếp theo.”

Karpathy đưa một mental model rất thú vị: LLM là CPU, context window là RAM. Vai trò của context engineering là quyết định thứ gì được load vào RAM đó — đúng lúc, đúng lượng, đúng format. Nếu prompt engineering là viết instruction, thì context engineering là thiết kế toàn bộ môi trường thông tin mà AI vận hành bên trong.

Nhưng ẩn dụ này có một giới hạn đáng chú ý: trong máy tính thật, nhồi đầy RAM chỉ làm hệ thống chậm đi, không làm nó sai đi. Còn với LLM, “RAM” của AI không chỉ chứa dữ liệu — nó còn ảnh hưởng trực tiếp đến chất lượng tư duy của “CPU”. Nhồi quá nhiều thông tin vào context window có thể làm model trả lời kém chính xác hơn. Đó chính xác là lý do context engineering cần được thiết kế cẩn thận, không phải cứ inject nhiều là tốt.

Context của một cuộc hội thoại không chỉ gồm câu hỏi người dùng vừa gõ. Nó còn có thể bao gồm system prompt, conversation history, retrieved documents từ knowledge base (RAG), user metadata như lịch sử đơn hàng hay ticket đang mở, và tool results từ các API được gọi trong quá trình xử lý.

Harness Engineering — lớp ít được nhắc đến nhất, nhưng không thể thiếu

Nếu prompt và context là những gì bạn đưa vào AI, thì harness engineering là hệ thống để bạn biết AI đang làm đúng hay không.

Thuật ngữ eval harness có gốc từ giới ML research — EleutherAI’s lm-evaluation-harness, ra đời để benchmark language models một cách có hệ thống, đã là công cụ chuẩn trong cộng đồng nghiên cứu trước khi khái niệm “harness engineering” được dùng rộng hơn trong product development. Đến 2025–2026, khi AI agents được deploy ở quy mô production, harness engineering trở thành một discipline riêng — với các tool như Promptfoo, DeepEval, Braintrust được xây dựng specifically để serve nhu cầu này.

Một eval harness production cơ bản gồm ba thành phần:

1. Golden datasets — Tập hợp input thực tế và expected output được team đánh giá là chuẩn: vài trăm câu hỏi user thật, kèm câu trả lời mà team đồng ý là đúng — về nội dung, tone, và cách xử lý.
2. LLM-as-judge — Dùng một model để tự động đánh giá output theo rubric định sẵn. Thay vì human review từng response, bạn define tiêu chí và để AI chấm theo tiêu chí đó. Một nghiên cứu thực tế với DeepEval cho thấy evaluator model capability quan trọng đáng kể — llama-3-3-70b catch được tất cả known failures, trong khi các model nhỏ hơn bỏ sót 4–5 case.
3. CI/CD integration — Mỗi lần prompt thay đổi, mỗi lần model update, eval chạy tự động. Nếu score tụt dưới ngưỡng, deployment bị block.

Nhưng có một điểm Py thấy quan trọng cần nói thêm: để harness thực sự là engineering chứ không phải phó mặc cho một hộp đen khác, vẫn phải làm meta-evaluation — tức là kiểm tra lại xem chính con LLM-as-judge có đang chấm đúng ý con người hay không. Nếu user nói “Tôi thích không gian yên tĩnh nhưng có nhạc nền”, con judge có hiểu đúng sự mâu thuẫn đó không? Human-in-the-loop ở đây không phải dấu hiệu của hệ thống yếu — mà là chốt chặn cuối cùng của bất kỳ AI engineering nào làm đúng nghĩa.

Theo Py hiểu, đây là chỗ thú vị nhất — và cũng nhức đầu nhất — của harness trong AI. Nếu dừng lại mà nghĩ kỹ: ta đang dùng một hệ thống bất định để chấm điểm một hệ thống bất định khác, rồi lại cần người để kiểm tra lại con chấm điểm đó. Một vòng lặp không bao giờ thực sự khép lại. Nói vậy không có nghĩa là harness vô dụng — mà là kỳ vọng cần được đặt đúng chỗ. Harness không tự động hoá hoàn toàn việc đánh giá chất lượng. Nó chỉ giúp team tốn ít công sức hơn để phát hiện ra vấn đề — và đó, với Py, đã là đủ để coi nó là đáng làm.

Và có một đánh đổi khác mà Py thấy ít được nói đến hơn: trong AI engineering, không bao giờ có điểm 100% tuyệt đối. PO sẽ là người phải chọn — hệ thống này thà nói “Tôi không biết” (giảm tỷ lệ trả lời, tức Recall thấp) còn hơn là bịa ra câu trả lời sai (cần Precision cao)? Hay ngược lại? Đây không phải câu hỏi kỹ thuật — đây là câu hỏi về tính cách của sản phẩm bạn đang build.

Py chưa có kinh nghiệm trực tiếp build harness. Nhưng nhìn vào case study thực tế với 100+ AI agent deployments: “Các team ship AI thành công không phải những team có model tốt nhất. Họ là những team có evaluation infrastructure tốt nhất. Models là commodities. Evaluation là differentiation.”

Ví dụ về Xsy-peasy và vai trò của PO

Tiếp tục lấy Xsy-peasy làm ví dụ – startup booking workshop “chỉ” tồn tại trên anpylogue. Context là user dành nhiều thời gian browse danh sách workshop, nhưng conversion rate thấp hơn kỳ vọng. Nguyên nhân đã được phân tích trong bài Pareto, đó là decision fatigue: càng nhiều lựa chọn, user càng mất thời gian quyết định và càng dễ bỏ ngang.

Một trong những hướng giải quyết là build một AI booking assistant. Thay vì để user tự lọc qua hàng chục workshop, AI hỏi thêm vài câu ngắn để thu hẹp lựa chọn. Sau 2–3 câu, AI suggest 1–2 workshop phù hợp nhất thay vì liệt kê cả danh sách. Đơn giản, nhưng để cái “đơn giản” đó hoạt động đúng thì không thể đơn giản:

Prompt: PO không cần gõ XML hay viết few-shot JSON, nhưng phải định nghĩa cho AI hiểu thế nào là một câu hỏi “tự nhiên”. Ví dụ: PO quy định AI phải tự đánh giá xem câu trả lời của user đã đủ dữ kiện chưa trước khi suggest, thay vì vồ vập đưa ra gợi ý ngay từ câu đầu. Hay AI nên hỏi về cảm xúc mong muốn (“bạn muốn thử thứ gì đó mới hoàn toàn, hay muốn quay lại thứ bạn từng thích?”) thay vì hỏi về thuộc tính workshop. Đây là tư duy chiến lược mà engineer sẽ dịch thành cấu trúc chain-of-thought, few-shot examples, và system instruction cụ thể.

Context: Câu trả lời của user trong cuộc hội thoại đó là context rõ ràng nhất, nhưng không phải thứ duy nhất AI cần. PO cần cân nhắc: inject thêm lịch sử booking trước đó không? Cho AI thấy workshop nào đang còn slot hay giữ lại để tránh bias? Nếu user từng book workshop vẽ tranh hai lần, AI có nên ưu tiên category đó không? Mỗi lựa chọn đó đều ảnh hưởng trực tiếp đến chất lượng suggest và không có cái nào là câu hỏi kỹ thuật thuần túy.

Harness: Sau khi ship, PO cần định nghĩa “suggest tốt trông như thế nào.” Không phải chỉ “user click vào workshop được suggest”, vì user có thể click mà vẫn không book. Acceptance criteria thực sự là: suggest đúng category so với preference user đã express, không suggest workshop đã full, response trong 2 giây. Engineer dùng những tiêu chí đó để build golden dataset và LLM-as-judge rubric.

Điều Py nghiệm ra sau khi research không phải là “có ba khái niệm mới cần học.” Mà là: trong một AI product, PO cần chủ động ở cả ba lớp và mỗi lớp đòi hỏi một loại đóng góp khác nhau.

Ở lớp prompt, PO là người hiểu rõ sản phẩm cần AI nói gì và nói như thế nào với từng đối tượng, tone, boundary, cách xử lý các tình huống edge case.

Ở lớp context, PO là vị trí có đủ business context để quyết định thông tin nào thật sự cần thiết ở từng bước. Engineer có thể build RAG pipeline, nhưng quyết định inject thêm thứ gì, bỏ bớt thứ gì, ở thứ tự nào, đó là product decision, không phải technical decision.

Ở lớp harness, PO là người đặt acceptance criteria: định nghĩa “đúng” nghĩa là gì trước khi engineer build golden dataset hay LLM-as-judge rubric. Nếu PO không define được “response tốt trông như thế nào”, thì harness chỉ là infrastructure rỗng, đo mà không biết đo cái gì.

Nói vậy chứ Py cũng chưa làm được cả ba đủ tốt. Nhưng ít nhất, Py biết mình cần hỏi gì, cần quyết định gì, và cần phối hợp với ai thay vì để mặc cho team tự xử rồi nhận kết quả cuối. Py không nghĩ ba khái niệm này sẽ giúp mình kiểm soát hoàn toàn sự bất định của AI. Nhưng hiểu “đúng” cho Py biết mình đang đứng ở đâu, cụ thể hơn là vẫn biết cách mình làm có khả năng có hiệu quả hay không thay vì cứ ship rồi cầu may. Với Py, đó là điểm neo cần thiết giữa một kỷ nguyên mà mọi thứ đang thay đổi quá nhanh ngoài kia.

Highly recommend đọc thêm:

• Andrej Karpathy trên X, 25/6/2025 — nguồn gốc câu quote về context engineering
• LangChain: Context Engineering for Agents — giải thích kỹ các thành phần context
• Towards Data Science: Building an Evaluation Harness — 12-metric framework từ 100+ deployments

(Trong bài viết có một số đoạn tổng hợp thông tin được gen bằng AI)

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này.

Chúc bạn nhiều may mắn và bình an.

Anpy