Martin Fowler nói thẳng tại hội thảo Future of Software Development Retreat lần hai tuần trước: bottleneck đã dịch chuyển. Không còn là code generation nữa. Mà là verification.

Và ẩn trong quan sát đó là một discipline mà hầu hết các engineering teams đang hoàn toàn bỏ qua: harness engineering.

Không phải prompt engineering. Không phải model fine-tuning. Không phải agent orchestration theo nghĩa trừu tượng. Harness engineering — thiết kế có chủ đích các loops, constraints, scaffolding và hệ thống verification bao quanh AI output trước khi nó đến production.

Tôi muốn nói thẳng: nếu team của bạn không có ai đang suy nghĩ về harness design, bạn đang tích lũy rủi ro vô hình với tốc độ mà incident dashboard của bạn chưa thể thấy được.

Harness là gì?

Trong test engineering, test harness là cơ sở hạ tầng chạy tests: fixtures, mocks, runners, reporters. Nó không phải là các tests — mà là hệ thống làm cho việc testing trở nên đáng tin cậy, có thể lặp lại và đáng tin.

AI harness là cùng khái niệm đó áp dụng cho các AI-in-the-loop workflows. Nó không phải là AI model. Mà là mọi thứ xung quanh model đảm bảo output của model được:

• Verify trước khi đến downstream systems
• Constrain trong phạm vi những gì có thể chấp nhận
• Recover được khi model tạo ra output sai
• Observable để bạn có thể track chất lượng theo thời gian

Đây là mental model đơn giản nhất: nếu bạn xóa AI khỏi workflow và thay bằng một human expert, cơ sở hạ tầng nào bạn sẽ xây dựng xung quanh người đó để đảm bảo chất lượng? Cơ sở hạ tầng đó là harness của bạn.

Tại sao Harness Engineering Quan trọng Lúc này

Hai năm trước, AI trong software teams có nghĩa là autocomplete. Vấn đề “harness” rất đơn giản — nếu suggestion sai, developer chỉ cần bỏ qua nó.

Ngày nay, AI đang tạo ra toàn bộ features, viết migration scripts, đề xuất architectural changes, và trong một số trường hợp commit và deploy code một cách tự động. Vấn đề harness hiện là vấn đề production risk.

Data Point từ Anthropic

Anthropic vừa công bố điều gì đó đáng chú ý: họ đã loại bỏ hơn 80% system prompt của Claude Code cho các Claude 5 generation models mà không có regression nào đáng kể về chất lượng. Hàm ý không phải là “model thông minh hơn nên bạn cần ít instructions hơn.” Hàm ý là cách bạn cấu trúc context quan trọng hơn bao nhiêu context bạn cung cấp.

Đó là harness thinking. Họ đang thiết kế hệ thống xung quanh model, không chỉ là model chính nó.

Pattern Incident

Trong các teams tôi tư vấn, các production incidents liên quan đến AI tập trung vào ba loại root cause:

1. AI output chưa được verify đến production (45%): AI tạo ra thứ gì đó có vẻ đúng nhưng sai, và không có verification step nào bắt được nó.
2. Context không có sẵn cho AI (35%): AI không có quyền truy cập vào thông tin nó cần — architecture docs, business rules, system constraints.
3. Recovery path không được thiết kế (20%): AI tạo ra bad output, hệ thống không có graceful degradation path, và failure cascade.

Cả ba đều là harness failures. Không cái nào là model failures.

Năm Thành phần của một Production AI Harness

1. Input Constraints Layer

Những gì đi vào AI quan trọng không kém những gì đi ra. Một harness tốt định nghĩa:

• Context documents: CLAUDE.md, ARCHITECTURE.md, domain-specific constraints mà AI phải nhận
• Prohibited inputs: Không truyền gì vào model (PII, secrets, data không nên rời perimeter của bạn)
• Scope boundaries: AI được phép làm việc trong không gian vấn đề nào

# CLAUDE.md — Ví dụ Input Constraint

## Scope
Bạn đang giúp đỡ với payment service chỉ. KHÔNG:
- Sửa đổi authentication code
- Truy cập trực tiếp user PII fields
- Đề xuất architectural changes mà không flag cho human review

## Context Bắt buộc
Trước khi giải quyết bất kỳ vấn đề nào, đọc: ARCHITECTURE.md, PAYMENT_CONSTRAINTS.md

2. Output Verification Layer

Mọi AI output quan trọng nên đi qua verification trước khi hành động theo nó. Verification có thể là:

• Syntactic: Cái này parse được không? Nó compile không?
• Semantic: Cái này có implement stated intent không?
• Constraint: Cái này có vi phạm bất kỳ rules nào trong ARCHITECTURE.md không?
• Behavioral: Cái này có hoạt động đúng trên representative test suite không?

Insight chính từ harness engineering work của Anthropic: verification không chỉ là testing. Nó là một loop nơi output feed trở lại vào hệ thống với context mới nếu nó fail.

async def verified_ai_generation(prompt: str, constraints: dict) -> str:
    max_attempts = 3
    for attempt in range(max_attempts):
        output = await ai_generate(prompt)
        
        violations = check_constraints(output, constraints)
        if not violations:
            return output
            
        # Feed violations trở lại như context cho lần thử tiếp theo
        prompt = f"{prompt}\n\nOutput trước vi phạm: {violations}\nVui lòng sửa."
    
    raise HarnessVerificationError("Không thể tạo output tuân thủ")

3. Progress Artifact Pattern

Cho các long-running AI agents span nhiều context windows (vấn đề ngày càng tăng khi agentic workflows trở nên chuẩn), bạn cần progress artifact pattern.

Thay vì tin tưởng AI duy trì context qua các sessions, thiết kế harness để duy trì state bên ngoài:

agent-progress.md  ← Được duy trì bởi harness, không phải AI
  ## Completed Steps
  - [x] Phân tích requirements (2026-07-27T10:23:00Z)
  - [x] Tạo schema migration (sha: abc123)
  
  ## Current Step
  - [ ] Implementing service layer (started: 10:45Z)
  
  ## Constraints Applied
  - Không có direct DB access từ service layer
  - Tất cả mutations phải qua repository pattern

AI đọc cái này ở đầu mỗi session. Harness ghi vào nó sau mỗi verified step. Nếu AI đi lạc, harness phát hiện qua last completed step và có thể restart từ known-good state.

4. Observability Integration

Bạn không thể cải thiện những gì bạn không thể đo. AI harnesses cần observability mà con người chưa từng cần:

• Attempt count mỗi task: Bao nhiêu lần thử trước khi AI tạo ra output chấp nhận được?
• Context utilization: AI đang thực sự sử dụng context documents nào?
• Constraint violation rate: AI output vi phạm defined constraints bao thường xuyên?
• Fallback trigger rate: Hệ thống fallback về human review bao thường xuyên?

Trong stack của chúng tôi, chúng tôi push harness metrics lên cùng observability platform như application metrics. Một AI đột nhiên bắt đầu yêu cầu 3+ attempts cho các tasks trước đây chỉ cần 1 là một tín hiệu — của context problem, constraint change, hoặc model behavior shift.

5. Graceful Degradation Path

Mỗi AI-in-the-loop workflow cần một designed failure path. Nếu AI không thể tạo ra verified output trong attempt budget:

• Workflow có pause để human review không?
• Nó fail open (tiếp tục không có AI enhancement) hay fail closed (dừng cho đến khi giải quyết)?
• Ai được notify? SLA là gì?

Đây là standard reliability engineering áp dụng cho AI. Điểm khác biệt là AI failures thường silent — hệ thống tạo ra output, nhưng nó sai. Các degradation paths của bạn cần tính đến silent failures, không chỉ timeouts và exceptions.

Harness Design Thực tế: Một Case Study

Đây là một harness thực tế tôi thiết kế cho automated API documentation generation:

Input Layer:
  - API source code (scoped đến public endpoints chỉ)
  - Existing doc standards (DOCUMENTATION_STYLE.md)
  - Known-bad example patterns để tránh

Generation:
  - Claude tạo documentation draft
  - Attempt budget: 3 lần thử

Verification Layer:
  - Check 1: Mọi public method có doc block không? (Syntactic)
  - Check 2: Code examples trong docs có thực sự compile không? (Behavioral)
  - Check 3: Tất cả parameter descriptions có đủ không? (Semantic)
  - Check 4: Không có internal implementation details nào bị lộ? (Constraint)

Output:
  - Pass: Submit PR với generated docs
  - Fail sau 3 lần: Tạo issue với constraint violations, assign cho human

Observability:
  - Attempt count → Grafana
  - Verification failures theo loại → Grafana
  - Human fallback rate → Weekly review metric

Sau ba tháng, attempt count giảm từ trung bình 2.1 xuống 1.3 khi chúng tôi tinh chỉnh input constraints. Human fallback rate giảm từ 18% xuống 4%. Chất lượng docs được cải thiện không phải vì chúng tôi thay đổi model — chúng tôi không thay đổi. Chúng tôi cải thiện harness.

Xây dựng Discipline Harness Engineering

Harness engineering không phải là AI engineering và không phải là test engineering. Đây là discipline hybrid đòi hỏi:

1. Kiến thức hệ thống sâu: Bạn không thể constrain những gì bạn không hiểu
2. Failure mode thinking: Điều gì có thể đi sai, và impact là gì?
3. Feedback loop design: Hệ thống cải thiện như thế nào theo thời gian?
4. Observability instinct: Bạn cần đo gì để biết nó có hoạt động không?

Về mặt thực tế, trong team 8 engineers, bạn có thể cần một người có primary focus là harness design cho các AI workflows quan trọng nhất của bạn. Không phải full-time — nhưng có chủ đích, không phải tình cờ.

Quỹ đạo Tương lai

Quan sát của Fowler từ hội thảo đáng suy ngẫm: chúng ta đang đối mặt với apprenticeship crisis khi AI thay thế con đường junior-engineer. Nhưng discipline harness engineering là một nơi mà các experienced engineers có giá trị không thể thay thế.

Bạn cần kiến thức hệ thống để viết constraints tốt. Bạn cần kinh nghiệm failure mode để thiết kế recovery paths tốt. Bạn cần wisdom production để biết cần observe gì.

Đây không phải là vai trò AI sẽ tự động hóa sớm. Đây là vai trò mà AI làm cho nó cần thiết.

---

Nếu bạn đang xây dựng các harness engineering practices tại công ty của mình, tôi rất muốn so sánh notes. Liên hệ tôi trên LinkedIn.