Harness Engineering là gì? Chuẩn hóa code AI trong team

Harness Engineering là gì? Bí quyết ép AI sinh ra cùng một chất lượng code

TL;DR

• Harness Engineering là cách thiết kế phần mềm để ép mọi AI model tạo ra code cùng chuẩn, cùng chất lượng.
• Kỹ thuật này dựa trên 3 trụ: tài liệu hóa cấu trúc (CPS/PRD), linter bắt buộc, và hệ đánh giá riêng cho từng tổ chức.
• Nhờ harness tốt, có thể thay Claude, GPT, Gemini… mà vẫn giữ được kiến trúc, naming, file tree gần như y hệt.
• Linter gắn với Git hook giúp AI chỉ có thể commit code tuân thủ đúng thiết kế, chuẩn hóa toàn bộ repository.
• Evaluation “đo sức khỏe” AI mỗi ngày, giống Datadog cho hệ thống, nhưng dành cho AI agent và RAG.

---

Harness Engineering là một phương pháp thiết kế phần mềm giúp bất kỳ AI model nào — Claude, Codex, Gemini, GPT — cũng bị “ép” sinh ra cùng một kiểu code, cùng cấu trúc và cùng chất lượng. Thay vì chỉ dựa vào prompt hay “vibe coding”, phương pháp này gom tài liệu thiết kế, linter và hệ thống đánh giá vào một khung thống nhất để kiểm soát AI một cách có hệ thống.

Related: AI và tương lai nghề lập trình: 12 bài học sống còn

Related: AI thời hậu code: 12 bài học từ workflow Anthropic

Related: Claude Code và cái chết của việc gõ code | 12 bài học

Related: AI và tương lai nghề lập trình: 12 insight then chốt

Trong môi trường doanh nghiệp — nơi model AI đổi liên tục và team bảo trì thường không phải team triển khai ban đầu — chính lớp “ép buộc có chủ đích” này là thứ phân biệt PoC đẹp mắt với sản phẩm thực sự sống được nhiều năm.

Bài này tổng hợp kinh nghiệm thực chiến của một Forward Deployed Engineer (FDE) đang triển khai các dự án AI trong doanh nghiệp lớn, minh họa qua ví dụ nền tảng giao đồ ăn, và đi trọn vòng: từ thu thập yêu cầu, phân tích thiết kế, ép code bằng linter, đến thiết kế hệ evaluation riêng cho từng tổ chức.

---

Harness Engineering là gì và tại sao quan trọng trong thời đại AI?

Harness Engineering là một kỹ thuật xây dựng phần mềm buộc AI model phải tạo ra output tuân thủ sẵn các nguyên tắc thiết kế và quy tắc code đã định. Thay vì phụ thuộc vào “độ thông minh” hay phong cách riêng của từng mô hình, kỹ thuật này biến tài liệu thiết kế, linter và framework đánh giá thành một bộ khung bao quanh AI.

Nói cách khác, Harness Engineering biến AI từ “nghệ sĩ sáng tác code” thành “thợ lành nghề” — phải làm theo bản vẽ chi tiết, không được tự ý phá thiết kế.

Dù dùng Claude, OpenAI Codex, Gemini hay bất kỳ LLM nào, kết quả cuối vẫn hội tụ về cùng một chuẩn: cùng design system, cùng file structure, cùng naming convention. Đây là tính idempotent (bất biến đầu ra) — khái niệm cốt lõi của toàn bộ phương pháp.

Điểm mấu chốt ở đây là tránh phụ thuộc model. Hôm nay Claude mạnh, mai GPT ra phiên bản mới, ngày kia Gemini cải thiện — nhưng hệ thống vẫn sống ổn vì harness mới là “nguồn sự thật” (source of truth), không phải bản thân model. Trên thực tế, đây là sự khác biệt rõ nhất giữa team dùng AI một cách có kỷ luật và team đang “vibe coding” chờ model không hallucinate.

Vai trò Forward Deployed Engineer (FDE) — vốn xuất phát từ Palantir — đặc biệt phù hợp với Harness Engineering. FDE trực tiếp làm việc với khách hàng, định nghĩa yêu cầu, và dùng AI để đi từ Zero đến One, nên họ cần một cách để:

• Chuyển yêu cầu mơ hồ thành kiến trúc rõ ràng.
• Cho AI code nhanh nhưng vẫn dễ bảo trì, audit, và chuyển giao cho đội SI hoặc nội bộ khách hàng.

Trong bối cảnh nhiều doanh nghiệp Việt đang nói về “AI Transformation”, Harness Engineering là phương pháp luận để những lời hứa đó không dừng lại ở slide trình chiếu.

---

Quy trình Harness Engineering qua ví dụ nền tảng giao đồ ăn

Quy trình Harness Engineering là một chuỗi sáu bước giúp biến yêu cầu thô từ khách hàng thành phần mềm chạy được, kèm guardrail cho AI. Trong ví dụ nền tảng giao đồ ăn, toàn bộ flow này được áp dụng song song cho nhiều AI model để kiểm tra mức độ hội tụ về chất lượng.

Bốn thành phần phần mềm trong nền tảng giao đồ ăn gồm:

• Ứng dụng đặt món cho người tiêu dùng.
• Ứng dụng cho tài xế giao hàng.
• Ứng dụng cho nhà hàng nhận và xử lý đơn.
• Hệ thống admin quản trị toàn bộ nền tảng.

Điều thú vị là nhiều khách hàng ban đầu chỉ nghĩ đến một app cho người dùng. Trong các buổi làm việc, FDE sẽ từng bước gỡ rối yêu cầu, chỉ ra rằng nếu không có app tài xế, app nhà hàng và admin thì luồng vận hành thực tế sẽ gãy ở nhiều chỗ — đôi khi khá nghiêm trọng.

Một trong những giá trị lớn nhất của FDE là khả năng “dịch” yêu cầu mơ hồ thành các thành phần hệ thống rõ ràng.

Sáu bước của quy trình:

1. Thu thập yêu cầu.
2. Lên kế hoạch (Plan) & meeting log.
3. Phân tích thiết kế (CPS, PRD).
4. Thiết kế kiến trúc.
5. Sinh code + áp dụng linter.
6. Evaluation theo tiêu chí doanh nghiệp.

Khi áp dụng đồng thời cho ba model (Claude, Codex, Gemini) và bốn module phần mềm, tổng cộng có 12 output code được sinh ra. Nếu harness được thiết kế đúng, 12 output này sẽ gần như giống nhau về cấu trúc thư mục, design system và naming convention.

Đây là bài test rất thực dụng: nếu thay model mà repo trông “như một người viết” thì harness của bạn đang làm việc tốt.

---

Plan phase là gì và làm sao chuyển cuộc họp lộn xộn thành CPS?

Plan phase là giai đoạn biến cuộc trò chuyện tự do với khách hàng thành tài liệu có cấu trúc, có thể dùng làm input cho AI và đội kỹ thuật. Meeting Log là sản phẩm trung tâm của giai đoạn này.

Trong mô hình FDE, một tuần thường có 2–3 lần khách hàng onsite và mỗi ngày chia làm bốn khung meeting: sáng và chiều, trước và sau giờ làm. Mỗi phiên họp đều gồm review kết quả phiên trước và chốt mục tiêu đầu ngày/cuối ngày.

Nguyên tắc vàng của các buổi họp này: không giới hạn khách hàng nói gì.

Ngay cả khi FDE đi họp đôi, nếu một người có xu hướng ngắt lời khách, người còn lại sẽ chủ động nhắc giữ không gian mở — đôi khi chỉ bằng ánh mắt. Lý do rất rõ: khách hàng nói càng chi tiết thì đội ngũ càng có nhiều dữ liệu sống, và mọi câu chuyện đều có thể biến thành constraint, rule hoặc user case trong thiết kế.

Khi Meeting Log đủ dày, FDE tổng hợp thành tài liệu CPS (Context – Problem – Solution). Khung này bắt nguồn từ văn hóa họp nội bộ của Palantir:

• Context: Bối cảnh khách hàng đang ở đâu, hệ thống cũ là gì, quy trình hiện tại thế nào.
• Problem: Họ đang gặp vấn đề kinh doanh, vận hành, dữ liệu ở những điểm nào.
• Solution: Đề xuất giải pháp — trong đó AI là một phần của hệ thống, không phải phép màu.

Tài liệu CPS thường được lưu trên GitHub của khách hàng như “hồ sơ bệnh án”, cập nhật liên tục suốt dự án, và build thành PDF bằng LaTeX ở đầu và cuối dự án như một deliverable chuyên nghiệp.

Khi bạn bắt đầu luyện thói quen viết CPS cho từng tính năng lớn, việc nói chuyện với AI — và với đồng đội — sẽ rõ ràng hơn hẳn. Câu “Em code theo cảm giác” sẽ xuất hiện ít đi rất nhiều.

---

Thiết kế phân tích (Design Analysis) là gì và liên quan DDD như thế nào?

Thiết kế phân tích (Design Analysis) là giai đoạn chuyển CPS thành “bộ xương” của phần mềm, bao gồm nguyên tắc, khái niệm và cấu trúc dữ liệu. Bước này đặt ra sân khấu để AI chỉ việc mã hóa — không tự bịa thêm kiến trúc.

Trình tự tư duy được dùng là “Nguyên tắc → Định nghĩa → Cấu trúc → Luồng dữ liệu” theo hướng top-down. Cụ thể:

1. Đặt nguyên tắc (Principle) ở tầng cao nhất.
Ví dụ với dự án AI agent:

• Không được phép có hallucination.
• Bắt buộc có “human in the loop”.
• Bắt buộc log đầy đủ cho audit.

2. Định nghĩa khái niệm (Definition).
Chuẩn hóa toàn bộ thuật ngữ domain: “đơn hàng”, “chuyến giao”, “merchant”, “customer service ticket”… Xác định quan hệ và thứ bậc giữa chúng.

3. Xây dựng cấu trúc và luồng dữ liệu.
Từ các khái niệm đã chốt, hình thành model dữ liệu, API, event, luồng xử lý.

Domain-Driven Design (DDD) là phương pháp luận chủ đạo ở đây — để đảm bảo phần mềm phản ánh đúng mô hình kinh doanh thực, không phải một kiến trúc kỹ thuật tự phát mà AI nghĩ ra.

Giai đoạn này cũng là lúc PRD (Product Requirements Document) ra đời. Trên thực tế, rất ít khách hàng đọc PRD thật kỹ. Họ phản hồi trên phần mềm thật — từ chuyện rất nhỏ như “không thích nút này” đến chuyện lớn như “phải thêm một module mới”.

Do đó, vai trò chính của PRD là giữ sự thống nhất thiết kế trong nội bộ team, giúp lập trình viên mới join hiểu hệ thống nhanh, và trở thành knowledge asset sống lâu hơn cả code.

Ở nhiều công ty Việt, PRD thường bị xem là “thủ tục”. Nhưng trong môi trường AI kết hợp Harness Engineering, nó trở thành input quan trọng cho prompt, cho linter rule, và cho evaluation scenario về sau — bỏ qua nó là bỏ qua một phần lớn giá trị của harness.

---

Linter trong Harness Engineering là gì và làm sao tạo ra tính “idempotent”?

Linter trong Harness Engineering là cơ chế ép buộc code của AI phải tuân thủ triệt để các quy tắc đã định — từ tên file đến cấu trúc import — trước khi được phép đi vào repository. Đây là “cánh tay kỹ thuật” chính của harness.

Lấy ví dụ: khi xây trang “danh sách nhà hàng”, AI có thể nghĩ ra nhiều tên khác nhau — restaurant-list-page, restaurant-search-page, restaurants-page… Với Harness Engineering, domain quy định luôn dùng danh từ số nhiều làm tên file, không được phép dùng suffix như “list”, “detail”, “search”. Các rule này được cài vào linter, khiến mọi tên không đúng chuẩn đều bị chặn ngay.

Một khi tên file đã cố định, các lớp quy tắc tiếp theo tự nhiên kéo theo: tên class bên trong, tên helper function, thứ tự import theo alphabet, quy tắc export trong barrel file.

Linter chạy tự động ở thời điểm commit qua Git Hook. Nghĩa là AI có thể sinh ra code “tự do” — nhưng chỉ phần code tuân thủ đầy đủ quy tắc mới được phép đi qua cổng commit.

Kết quả thử nghiệm cho thấy cảm giác dev lúc này giống làm việc với một “design system cho code”: thiết kế vẫn tự do ở mức ý tưởng, nhưng sản phẩm đầu ra phải qua một lò ép khuôn nhất định trước khi được lưu vào repo.

Chiến lược này còn mở ra một khả năng thú vị — và nó đã tồn tại trước thời “vibe coding”. Khi gặp bug trong một chức năng, thay vì refactor khó đoán, FDE có thể xóa toàn bộ file đó, nói rõ interface và mong muốn trong prompt, rồi để AI sinh lại từ đầu theo cùng linter và cấu trúc cũ. Vì mọi thứ đã được chuẩn hóa, việc “regenerate” như vậy nhanh và khá an toàn.

Nhược điểm và lý do vẫn đáng áp dụng

Nhược điểm lớn nhất: guardrail tối ưu cho con người đọc có thể không tối ưu cho AI model. Model có phong cách sinh code riêng để tiết kiệm token — khi bị ép theo convention lạ, nó có thể dùng token kém hiệu quả hơn.

Nhưng trong môi trường enterprise, ưu tiên số một là code phải dễ đọc với con người và hệ thống phải dễ bảo trì bởi đội không có internet, không xài AI. Lợi ích dài hạn của linter vượt xa chi phí thêm về token và thời gian. Nhiều team SI nhận bàn giao hệ thống có harness kiểu này và học rất nhanh dù không hề tham gia giai đoạn build — đó là minh chứng rõ nhất.

---

Evaluation trong Harness Engineering là gì và vì sao phải “may đo” cho từng doanh nghiệp?

Evaluation trong Harness Engineering là hệ thống kiểm tra liên tục xem AI có đang hoạt động đúng mong đợi của doanh nghiệp hay không, bằng các chỉ số đo được và dashboard theo dõi dài hạn. Đây là lớp cuối cùng — nhưng là lớp bảo hiểm chất lượng quan trọng nhất.

Trong các hệ thống RAG (Retrieval-Augmented Generation), thường dùng bốn chỉ số đánh giá:

• Context Relevance: Câu trả lời có dùng đúng ngữ cảnh được cung cấp không.
• Answer Faithfulness: Câu trả lời có bám sát nguồn, tránh bịa đặt không.
• Source Accuracy: Dẫn nguồn và trích dẫn có chính xác không.
• Completeness: Câu trả lời có bỏ sót ý quan trọng không.

Nhưng mỗi doanh nghiệp có “khẩu vị rủi ro” khác nhau. Có tổ chức chấp nhận “hỏi 100 lần, sai 20 lần cũng được, miễn là luôn trả lời.” Tổ chức khác lại muốn: “Hỏi 100 lần, nếu không chắc thì im lặng, chỉ cần sai dưới 10 lần.” Hai yêu cầu này dẫn đến hai hệ thống evaluation hoàn toàn khác nhau — và đây là lý do không thể dùng chung một bộ chỉ số cho mọi khách hàng.

FDE cùng khách hàng thảo luận, thống nhất kịch bản nào bắt buộc phải chính xác gần tuyệt đối và kịch bản nào có thể chấp nhận sai sót nhỏ để đổi lấy sự tiện lợi.

Về mặt kỹ thuật, có thể dựa trên các phương pháp evaluation của framework như LangChain rồi bổ sung chỉ số riêng. Tài liệu tham khảo:

• https://python.langchain.com/docs/guides/evaluation
• https://platform.openai.com/docs/guides/evals

Hệ thống này giống Datadog trước đây dùng để giám sát tốc độ phản hồi dịch vụ — nhưng giờ là “Agent Dog”, giám sát chất lượng AI agent theo ngày, theo tháng, theo năm.

Dashboard evaluation mang lại hai lớp giá trị: đội triển khai theo dõi được sức khỏe hệ thống sau khi bàn giao, và khách hàng nhìn thấy quy trình kiểm soát rõ ràng thay vì cảm giác “AI trả lời hay thì dùng, không hay thì thôi.” Theo trải nghiệm với vài dự án internal AI, việc có hay không có bảng theo dõi kiểu này là ranh giới giữa hệ thống được dùng thật và hệ thống bị bỏ quên sau vài tháng.

---

Làm sao để Harness Engineering trở thành “văn hóa” trong đội?

Đưa Harness Engineering vào tổ chức là bài toán chia sẻ mô hình tư duy, không chỉ là chuyện phát file template hay share repo mẫu. Mô hình này yêu cầu cả team cùng hiểu tại sao lại đặt ra những nguyên tắc đó và khi nào nên phá luật, khi nào phải giữ.

Trong ví dụ được chia sẻ, toàn bộ code đặt trong GitHub team repository để ai cũng xem được, log và tài liệu lưu trên Notion, giao tiếp vận hành trên Slack — hoặc ở Việt Nam là Zalo cho chat nhóm. Chỉ với ba công cụ này, bất kỳ FDE nào cũng có thể tiếp quản hoặc tham chiếu dự án người khác mà không cần giải thích từ đầu.

Quan trọng hơn bản thân coding convention là lý do đằng sau mỗi quyết định thiết kế. Mỗi dự án có KPI, khách hàng, ràng buộc khác nhau, nên không thể có một bộ “chuẩn cứng” áp dụng cho tất cả. Thay vào đó, đội cần thống nhất vài nguyên tắc cốt lõi bắt buộc mọi dự án phải tuân theo, rồi tổ chức các buổi review nội bộ cố định trong tuần để chia sẻ thiết kế và phản biện lẫn nhau.

Quá trình này hình thành “trí tuệ tập thể”, nơi kinh nghiệm ẩn (tacit knowledge) dần được viết hóa thành explicit knowledge — tương tự cách các hãng tư vấn lớn như McKinsey hay BCG chuẩn hóa framework của họ qua nhiều năm.

Nếu không có các buổi review kiểu này, Harness Engineering rất dễ trở thành “nghi thức cá nhân” — mỗi người làm một kiểu, và tổ chức không tích lũy được gì dài hạn. Đây là điểm thất bại phổ biến nhất khi các team cố áp dụng phương pháp này mà không có cấu trúc chia sẻ kiến thức đi kèm.

---

Làm sao bắt đầu Harness Engineering từ con số 0?

Bắt đầu Harness Engineering là một quyết định ý thức: code của mình phải hội tụ về một hướng tất yếu, không ngẫu hứng. Không cần framework đồ sộ. Chỉ cần bốn bước thực tế.

1. Viết rõ nguyên tắc (Principle) và quy tắc code

Bước đầu tiên là viết ra thay vì chỉ “ngầm hiểu”: cách xử lý lỗi (error handling) mặc định, quy tắc đặt tên file, thư mục, class, function, thứ tự import, cách group module.

Khi thử nghiệm với vài repo thực tế, chỉ riêng việc document hóa những điều này đã tăng độ nhất quán của code AI sinh ra lên rõ rệt — đặc biệt khi cho model đọc các rule đó ngay trong prompt.

2. Gắn Linter với Git Hook để ép commit “sạch chuẩn”

Chọn linter phù hợp ngôn ngữ (ESLint, Pylint, Biome…) và nối nó vào pre-commit hook. AI có thể generate code tự do, nhưng commit nào không qua linter thì đơn giản là không được push.

Sau vài vòng regenerate, AI bắt đầu “học” theo convention một cách tự nhiên vì bất cứ lệch lạc nào cũng bị linter chặn lại. Không cần nhắc nhở trong prompt — cơ chế tự làm việc.

Tài liệu tham khảo:

• ESLint: https://eslint.org/docs/latest/use/getting-started
• pre-commit: https://pre-commit.com/

3. Tập viết CPS cho mỗi chức năng lớn

Rèn thói quen viết CPS ngắn gọn cho từng feature:

• Context: Chức năng này nằm ở đâu trong quy trình tổng thể.
• Problem: Nó giải quyết nỗi đau cụ thể nào của người dùng.
• Solution: Cách tiếp cận, ràng buộc, quy tắc.

Không cần tài liệu dài. Vài đoạn rõ ràng đã đủ để tạo ngữ cảnh tốt cho AI trong prompt và giúp đồng đội hiểu tại sao code trông như vậy.

4. Chốt tiêu chí Evaluation ngay từ đầu

Trước khi code, thống nhất khi nào coi AI system là “hoạt động đúng” và mức độ sai chấp nhận được là bao nhiêu. Nếu bỏ qua bước này, sau khi deploy sẽ rất khó tranh luận về chất lượng vì không có chuẩn chung để đối chiếu.

Giá trị thực sự của Harness Engineering không nằm ở ngày demo. Nó nằm ở thời điểm hệ thống được chuyển giao cho khách hàng và sống qua nhiều năm thay đổi model. Một harness được thiết kế tốt trở thành tài sản bền vững: dev mới join hiểu nhanh toàn bộ bối cảnh, thay model AI vẫn giữ nguyên chất lượng, và doanh nghiệp tin tưởng hơn khi nhìn thấy quy trình kiểm soát rõ ràng — không chỉ là “AI trả lời hay thì dùng”.

---

Câu hỏi thường gặp

Q: Harness Engineering là gì và khác gì so với chỉ viết prompt tốt?

A: Harness Engineering là phương pháp ép AI sinh code theo nguyên tắc thiết kế, linter và hệ evaluation đã định sẵn. Khác với việc chỉ tối ưu prompt, nó bổ sung thêm tầng kiểm soát kỹ thuật (linter, Git hook) và tầng giám sát chất lượng dài hạn (evaluation dashboard), giúp kết quả ổn định dù thay đổi model.

Q: Vai trò của Forward Deployed Engineer (FDE) trong Harness Engineering là gì?

A: FDE là kỹ sư được “cắm” trực tiếp tại khách hàng để định nghĩa yêu cầu, xây prototype từ 0 đến 1 bằng AI. Trong Harness Engineering, họ chịu trách nhiệm dẫn dắt từ Meeting Log, CPS, PRD đến kiến trúc, linter rule và tiêu chí evaluation, đảm bảo sản phẩm AI có thể bàn giao và bảo trì lâu dài.

Q: Tại sao linter lại quan trọng đến vậy trong Harness Engineering?

A: Linter hiện thực hóa các quy tắc code dưới dạng kiểm tra tự động ở thời điểm commit. Nó buộc mọi code — kể cả do AI sinh — phải tuân thủ file naming, cấu trúc import, class naming… trước khi được lưu vào repo, tạo ra tính nhất quán và khả năng bảo trì cao cho hệ thống.

Q: CPS và PRD khác nhau như thế nào trong quy trình này?

A: CPS tập trung vào việc mô tả bối cảnh – vấn đề – giải pháp ở mức khái quát, thường được xây từ Meeting Log với khách hàng. PRD chi tiết hóa yêu cầu sản phẩm ở mức tính năng, flow, trạng thái, được dùng chủ yếu để giữ thống nhất thiết kế trong nội bộ và giúp dev mới nắm hệ thống nhanh.

Q: Làm sao bắt đầu áp dụng Harness Engineering ở quy mô nhỏ?

A: Bắt đầu từ một dự án nhỏ bằng cách viết rõ vài nguyên tắc code cốt lõi, cấu hình linter với pre-commit hook, tập viết CPS ngắn cho mỗi tính năng, và thỏa thuận một vài chỉ số đánh giá chất lượng AI đơn giản. Khi những thực hành này chứng minh hiệu quả, có thể dần mở rộng thành phương pháp chuẩn cho cả team.