Vấn Đề Harness: Khi AI Briefs Khiến Bạn Tốn Gấp Đôi Thay Vì Tiết Kiệm

Góc nhìn cá nhân của Thuận Lương — Tech Lead, người xây dựng hệ thống Agentic AI, và cũng là người đã nhận quá nhiều “AI brief” trong thời gian gần đây.

1. Con Orchestrator Không Chịu Delegate

Mình kể các bạn nghe chuyện này.

Ba tuần trước mình debug một lỗi. Nhưng không phải lỗi bình thường — không phải null pointer, không phải race condition, không phải memory leak. Lỗi này thuộc dạng “hành vi.” Con agent giỏi nhất trong hệ thống của mình… giỏi quá.

Mình đang build một hệ thống multi-agent cho khách hàng. Kiến trúc trên giấy thì đẹp lắm:

Orchestrator Agent — chạy Claude Opus 4.5, full quyền truy cập tools, context window tối đa. Nhiệm vụ: phân tách task phức tạp, giao cho agent chuyên môn, giám sát tiến độ, đảm bảo chất lượng.
Code Agent — viết code, refactor code.
Research Agent — tìm tài liệu, phân tích thư viện, đọc docs.
Review Agent — check code quality, security, best practices.
Test Agent — viết và chạy test, validate hành vi.

Bốn agent chuyên môn. Một coordinator. Phân cấp rõ ràng. Trên lý thuyết thì hoàn hảo.

Thực tế thì sao?

Dấu Hiệu Đầu Tiên

Mình đưa cho hệ thống một task: “Build REST API cho user authentication với JWT, password hashing, rate limiting, và role-based access control.”

Orchestrator nhận task. Nó có full context — requirements, tech stack, constraints. Nó có access đến mọi tool: đọc file, viết code, chạy terminal, search web.

Nó lẽ ra phải làm thế này:

1. Phân tách task thành subtasks
2. Giao "Design auth schema" → Research Agent
3. Giao "Implement JWT middleware" → Code Agent
4. Giao "Write security tests" → Test Agent
5. Giao "Review OWASP compliance" → Review Agent
6. Giám sát, tích hợp, verify

Nó thực tế làm thế này:

1. "Để tui làm luôn cho nhanh."
2. Tự research JWT best practices (bỏ qua Research Agent)
3. Tự viết toàn bộ auth module (bỏ qua Code Agent)
4. Tự viết tests (bỏ qua Test Agent)
5. Tự review code của chính mình (bỏ qua Review Agent)
6. "Xong rồi! Đây là auth system hoàn chỉnh."

Output thì… được. Code chạy. Test pass. Nhưng bốn agent chuyên môn? Ngồi chơi. Orchestrator ôm hết.

Tại Sao Nó Làm Vậy?

Nghĩ thử từ góc nhìn của model. Orchestrator là Claude Opus 4.5 — một trong những model mạnh nhất hiện tại. Nó có:

Trí thông minh tối đa — subtask nào nó cũng xử lý được
Tất cả tools — file system, code execution, web search, đủ cả
Full context — biết hết project, requirements, constraints
Nhiệm vụ đảm bảo chất lượng — mà muốn đảm bảo chất lượng thì cách tốt nhất là… tự làm?

Từ góc nhìn năng lực thuần túy, delegate là kém hiệu quả. Orchestrator làm nhanh hơn, ít overhead phối hợp hơn, nhất quán hơn so với việc route qua bốn agent riêng biệt với context window riêng và khả năng hiểu sai.

Orchestrator không bị lỗi. Nó quá giỏi. Nó đang đưa ra quyết định hợp lý cục bộ: “Mình làm tốt hơn và nhanh hơn delegate.” Và nó đúng — cho bất kỳ task đơn lẻ nào.

Nhưng cho cả hệ thống? Thảm họa.

Hệ Quả Dây Chuyền

Khi Orchestrator ôm hết:

Mất lợi thế chuyên môn hóa. Review Agent đã được fine-tune với security prompts, OWASP checklists, vulnerability databases. Self-review của Orchestrator thì chung chung.
Mất xử lý song song. Bốn agent có thể chạy cùng lúc. Orchestrator làm tuần tự hết.
Cạn context window. Context của Orchestrator đầy ắp chi tiết implementation thay vì coordination metadata. Đến task thứ ba, nó mất dần bức tranh tổng thể.
Single point of failure. Orchestrator hallucinate ở một subtask? Không ai kiểm tra. Không có checks and balances.
Không scale được. Bạn thêm được agent chuyên môn. Bạn không thêm được Orchestrator.

Mình xem logs và thấy pattern rõ ràng: model càng mạnh, càng không chịu delegate. Model yếu hơn (ví dụ Claude Haiku) ở vị trí Orchestrator lại delegate tốt hơn — vì nó biết nó không thể làm hết. Nhưng model yếu cũng đưa ra quyết định coordination tệ hơn.

Nghịch lý: cần model mạnh để coordinate tốt, nhưng model mạnh thì không chịu coordinate.

Mình cần một giải pháp giữ được trí thông minh coordination của model mạnh nhưng ngăn nó nhúng tay vào implementation.

Mình cần một Harness.

2. Giải Pháp Harness

Harness, trong bối cảnh Agentic AI, là một tập hợp constraints và guardrails bao quanh một agent để giữ nó đúng vai trò. Giống như dây cương trên con ngựa — bạn không giảm sức mạnh con ngựa, bạn điều hướng nó.

Đây là những gì mình xây:

Tool Restrictions

Can thiệp trực tiếp nhất. Mình gỡ bỏ tools mà Orchestrator không nên có:

# Trước: Orchestrator có mọi thứ
orchestrator_tools = [
    file_read, file_write, code_execute,
    web_search, delegate_task, monitor_progress,
    approve_output, request_revision
]

# Sau: Orchestrator chỉ có thể coordinate
orchestrator_tools = [
    delegate_task,        # Giao việc cho specialist
    monitor_progress,     # Kiểm tra tiến độ agent
    approve_output,       # Chấp nhận hoặc từ chối kết quả
    request_revision,     # Gửi lại để sửa
    read_summary,         # Đọc tóm tắt tổng quan (không phải raw code)
    ask_clarification     # Hỏi thêm thông tin từ user
]

Không viết file. Không chạy code. Không search web. Orchestrator không thể implement bất cứ thứ gì. Nó chỉ có thể delegate, monitor, và approve.

Đây là thay đổi có tác động lớn nhất. Khi Orchestrator cố viết code, tool call fail. Nó buộc phải delegate.

Output Validators

Ngay cả khi không có implementation tools, model thông minh có thể cố nhét code vào delegation message — gần như implement trong instruction. Mình thêm validators:

def validate_orchestrator_output(output):
    """Đảm bảo orchestrator đang delegate, không implement."""

    # Flag nếu output chứa code block trên 10 dòng
    code_blocks = extract_code_blocks(output)
    for block in code_blocks:
        if len(block.lines) > 10:
            return ValidationError(
                "Orchestrator output chứa implementation code. "
                "Hãy delegate implementation cho specialist agent."
            )

    # Flag nếu output không chứa delegation action
    if not contains_delegation(output):
        return ValidationError(
            "Orchestrator output phải bao gồm ít nhất một "
            "delegation đến specialist agent."
        )

    return ValidationSuccess()

Role Enforcement trong System Prompt

Constraint “mềm”. Chỉ dẫn rõ ràng, tường minh về ranh giới vai trò:

## Vai trò của bạn: ORCHESTRATOR

Bạn là COORDINATOR. Bạn KHÔNG PHẢI là implementer.

Trách nhiệm:
- Phân tách task phức tạp thành subtasks
- Giao subtask cho agent chuyên môn ĐÚNG
- Giám sát tiến độ và chất lượng
- Đảm bảo tích hợp giữa các components
- Ra quyết định kiến trúc

Bạn KHÔNG BAO GIỜ được:
- Viết implementation code (delegate cho Code Agent)
- Nghiên cứu chi tiết (delegate cho Research Agent)
- Review code từng dòng (delegate cho Review Agent)
- Viết hoặc chạy test (delegate cho Test Agent)

Nếu bạn muốn "làm nhanh cho xong," DỪNG LẠI.
Impulse đó nghĩa là bạn nên delegate.

Feedback Loops

Khi Orchestrator vi phạm constraints, hệ thống không chỉ block — nó giải thích tại sao và bắt thử lại:

def handle_violation(orchestrator_output, violation_type):
    feedback = f"""
    PHÁT HIỆN VI PHẠM VAI TRÒ: {violation_type}

    Output của bạn bị block vì chứa implementation thay vì delegation.
    Nhớ rằng:
    - Bạn là COORDINATOR
    - Việc của bạn là GIAO VIỆC, không phải LÀM VIỆC
    - Các specialist agent tồn tại là có lý do

    Hãy reformulate response thành DELEGATION:
    1. Agent chuyên môn nào nên handle task này?
    2. Mô tả task là gì?
    3. Acceptance criteria là gì?
    4. Context nào specialist cần?

    Thử lại.
    """
    return retry_with_feedback(feedback)

Kết Quả

Sau khi implement Harness:

Tỷ lệ delegation của Orchestrator: từ ~15% lên ~95%
Chất lượng hoàn thành task: cải thiện 30% (specialist với focused prompts làm tốt hơn Orchestrator kiêm nhiệm)
Throughput song song: cải thiện 3.2x (nhiều agent chạy cùng lúc)
Hiệu quả context: Orchestrator duy trì project-level context qua 50+ subtasks thay vì chìm trong implementation details ở task thứ 10

Harness hoạt động. Nhưng nó khó. Ngay cả với constraints tường minh, Orchestrator vẫn thỉnh thoảng cố lén implement. Mình phải iterate validators, siết tool restrictions, và tinh chỉnh feedback loops trong nhiều tuần.

Và đây là với máy tính. Với hệ thống mình có toàn quyền kiểm soát. Với rules deterministic mình enforce bằng code.

Nên câu hỏi mình mất ngủ suy nghĩ là:

Nếu giữ AI agent ở đúng vai trò coordination đã khó thế này… thì con người thì sao?

3. Bây Giờ Nói Chuyện Công Ty Các Bạn

Mình vẽ cho các bạn một bức tranh.

Trong hệ thống multi-agent AI:

Hệ thống AI	Công ty của bạn
Orchestrator Agent	CEO / Manager / Product Owner
Specialist Agents	Senior Developers / Tech Leads
Tools (code, search, execute)	AI tools (ChatGPT, Claude, Copilot)
Context window	Kiến thức business, chiến lược, tầm nhìn
Harness	???

Thấy vấn đề chưa?

CEO hay product manager của bạn chính là Orchestrator. Họ có:

Năng lực cao — hiểu business, thị trường, người dùng
Tất cả tools — vừa có access GPT-4, Claude, Copilot, Cursor, v0, Bolt
Context tối đa — biết chiến lược công ty, ngân sách, timeline, chính trị nội bộ
Áp lực ship nhanh — “Cái này cần xong hôm qua”

Quen không? Cùng nguyên liệu như Orchestrator Agent của mình. Cùng kết quả luôn.

Họ bắt đầu tự làm thay vì delegate.

Không phải vì họ là manager tệ. Không phải vì họ không tin team. Mà vì — giống hệt AI Orchestrator — họ có thể. Tools ngay đó. AI ngay đó. Họ có thể generate code, build prototypes, tạo full implementations trong một buổi chiều.

Và giống hệt AI Orchestrator, họ đưa ra quyết định hợp lý cục bộ: “Mình làm nhanh hơn viết brief rồi chờ team.”

Nhưng hệ quả cấp hệ thống thì giống y:

Mất lợi thế chuyên môn (kinh nghiệm của dev team bị bypass)
Mất xử lý song song (một người làm tuần tự hết)
Cạn context (manager chìm trong implementation details thay vì strategy)
Single point of failure (không review, không second opinion)
Không scale được

Orchestrator Agent ít nhất còn có lý do — nó là language model tối ưu hóa cho con đường trực tiếp nhất. Còn bạn?

4. Vấn Đề “AI Brief”

Đây là inbox của mình hai năm trước:

Subject: Tính năng mới — User Dashboard

Chào Thuận,

Tụi anh cần một dashboard cho users. Yêu cầu chính:
- Hiển thị tổng quan tài khoản (số dư, giao dịch gần đây)
- Cho phép lọc theo khoảng thời gian
- Xuất CSV
- Responsive trên mobile

Target users: ~500 users
Timeline: 2 tuần
Budget: [thảo luận riêng]

Sắp xếp call nói chuyện chi tiết nhé.

Gọn. Rõ. Đây là bài toán, đây là constraints, mình bàn solution cùng nhau.

Đây là inbox của mình bây giờ:

Subject: Tính năng mới — User Dashboard (xem file đính kèm)

Chào Thuận,

Anh đã build gần hết rồi. Xem file đính kèm:
- dashboard-spec.md (47 trang)
- dashboard-prototype.html (prototype chạy được với biểu đồ)
- dashboard-api-design.md (REST API với 23 endpoints)
- dashboard-timeline.xlsx (Gantt chart do AI tạo)
- dashboard-cost-analysis.md (so sánh pricing với đối thủ)
- dashboard-architecture.svg (sơ đồ microservices)

Anh làm được khoảng 80% rồi. Em chỉ cần:
- Dọn lại code cho sạch
- Đưa lên production
- Deploy

Nhanh thôi vì phần lớn anh làm xong rồi. Báo giá nhé.

Để mình kể các bạn nghe trong những file đính kèm đó thực tế có gì.

Bản Spec 47 Trang

Được tạo bằng cách dump 5 dòng requirement ban đầu vào Claude kèm prompt “viết product specification toàn diện.” Nó bao gồm:

User personas (4 nhân vật hư cấu với tên, tuổi, và hồ sơ hành vi)
User journey maps (với trạng thái cảm xúc ở từng bước)
Information architecture (sitemap 15 trang cho cái lẽ ra là một dashboard duy nhất)
Wireframes mô tả bằng markdown (không phải wireframe thật, chỉ là mô tả dài dòng)
Data model (schema chuẩn hóa đến mức DBA nào đọc cũng khóc)
API specification (23 endpoints trong khi bạn cần khoảng 5)
Security requirements (copy từ OWASP top 10 không có context)
Performance requirements (“phải xử lý 10 triệu concurrent users” — cho 500 active users)
Accessibility requirements (copy nguyên từ WCAG không có ưu tiên hóa)
Testing strategy (unit, integration, e2e, load, security, accessibility — cho một dashboard)
Deployment strategy (Kubernetes với auto-scaling, blue-green deployments — cho 500 users)

47 trang AI-generated text nghe rất toàn diện nhưng phản ánh zero phán đoán của con người về cái gì thực sự quan trọng cho sản phẩm này, công ty này, user base này.

Prototype “Chạy Được”

File HTML với inline CSS và JavaScript. Dùng Chart.js cho biểu đồ, có dark mode toggle, responsive layout, animated transitions. Trông rất đẹp.

Nhưng:

Dùng localStorage làm “database”
Data là JSON hardcode
Filtering “hoạt động” bằng cách ẩn DOM elements
Không có authentication
Không có error handling
“API calls” là setTimeout với fake data
Tách cái gì hay ra khỏi đống này tốn công hơn build lại từ đầu

API Design

23 REST endpoints. Một vài highlights:

GET /api/v1/dashboard/widgets — hệ thống widget (không có trong requirements)
POST /api/v1/dashboard/widgets/reorder — kéo thả widget (không có trong requirements)
GET /api/v1/dashboard/analytics/predictive — predictive analytics (hoàn toàn không có trong requirements)
WebSocket /ws/dashboard/realtime — real-time updates (cho 500 users xem số dư)

AI generate ra dashboard có thể là gì trong kịch bản feature-complete, enterprise-grade nhất. Không phải dashboard nên là gì cho công ty nhỏ với 500 users và timeline 2 tuần.

Gantt Chart

File Excel đẹp lung linh với task bars màu sắc, dependencies, milestones, phân bổ resource. Ước tính 3 ngày.

Ba ngày. Cho hệ thống microservices, 23 API endpoints, WebSocket real-time, predictive analytics, và Kubernetes deployment. Ba ngày.

AI tạo timeline dựa trên mô tả của cái nó generate ra — không phải dựa trên thực tế.

Kết Luận Của Manager

“Anh làm được khoảng 80% rồi. Em dọn lại thôi.”

Đây chính là Orchestrator không có Harness ở dạng con người. Anh ấy đã làm 80% của một cái gì đó. Nhưng cái gì đó ấy không aligned với cái thực sự cần build. Và giờ mình phải xử lý cả bài toán thật LẪN cái AI solution đang nằm chình ình trên đó như cái nhà xây trên nền móng sai.

5. Tại Sao Khối Lượng Công Việc Nhân Đôi

Để mình đi qua từng bước thực tế xảy ra khi mình nhận một “AI brief” như trên.

Bước 1: Reverse Engineer Bài Toán Thật (2-4 giờ)

Đầu tiên, mình phải tìm ra bài toán thật là gì. Nhớ nhé, requirement ban đầu là 5 dòng. Nhưng nó bị chôn dưới 47 trang AI-generated specification.

Mình phải đọc hết và tách:

Cái manager thực sự muốn (dashboard với số dư và giao dịch)
Cái AI hallucinate (predictive analytics, widget system, real-time WebSocket)
Cái manager nghĩ mình muốn vì AI gợi ý (microservices, Kubernetes)
Cái thực sự cần cho 500 users với timeline 2 tuần

Giai đoạn reverse engineering này không tồn tại khi brief là bullet points. Bullet points chính là problem statement. Giờ mình phải trích xuất problem statement từ một solution mà có thể phản ánh hoặc không phản ánh nó.

Bước 2: Validate Approach (2-4 giờ)

Approach của AI có đúng không? Kiểm tra:

Kiến trúc: Microservices cho dashboard 500 users? Không. Một service với vài endpoints là đủ. Microservices chỉ riêng setup infrastructure đã ăn hết timeline.
Database design: Schema có 12 tables cho cái cần 3-4 tables. Một số tables cho features không có trong requirements.
API design: 23 endpoints. Dashboard thực tế cần: lấy thông tin user, lấy giao dịch (có filter), xuất CSV. 3 endpoints. Cùng lắm 5 với auth.
Frontend: Prototype trông đẹp nhưng kiến trúc không dùng được. Rebuild hoàn toàn với proper state management, API integration, error handling.
Performance: Spec ghi “10 triệu concurrent users.” Thực tế là 500 active users. Hai con số này cần kiến trúc hoàn toàn khác nhau.

Bước 3: Cuộc Trò Chuyện Khó Xử (1-2 giờ)

Giờ mình phải nói với manager: “Cảm ơn anh đã bỏ công, nhưng mình cần bắt đầu lại.”

Đây là phần tệ nhất. Họ bỏ mấy tiếng với AI. Họ có cảm giác sở hữu với output. Họ đã show cho stakeholders. Họ đã hứa timeline dựa trên estimate 3 ngày của AI.

Và giờ mình nói: “80% anh làm thực ra đang khiến phần còn lại khó hơn, không dễ hơn. Và không phải 3 ngày — mà là 2 tuần, đúng bằng thời gian nếu mình bắt đầu với proper brief.”

Cuộc trò chuyện này khó về mặt cảm xúc, nhạy cảm về mặt chính trị, và cần thiết về mặt kỹ thuật. Nó không tồn tại trước thời AI briefs.

Bước 4: Thiết Kế Solution Thật (4-8 giờ)

Giờ mình làm cái lẽ ra mình sẽ làm nếu nhận bullet points: suy nghĩ về bài toán, thiết kế solution phù hợp, đưa ra quyết định kiến trúc dựa trên constraints thật.

Nhưng mình làm trong khi đầu óc vẫn vướng víu cái AI solution. Manager sẽ hỏi: “Sao em không dùng kiến trúc microservices anh đã design?” Mình lại phải giải thích — lần nữa — tại sao monolith tốt hơn cho scale của họ.

Bước 5: Build (phần việc thật)

Cuối cùng, phần luôn luôn mất 2 tuần thì vẫn mất 2 tuần.

Tính Toán

Trước AI briefs:

Nhận bullet-point brief: 15 phút
Meeting clarification: 1 giờ
Thiết kế solution: 4-8 giờ
Build: 2 tuần
Tổng: ~2 tuần + 1 ngày

Sau AI briefs:

Nhận AI brief: 30 phút (chỉ riêng mở hết file)
Reverse engineer bài toán thật: 2-4 giờ
Validate AI approach: 2-4 giờ
Cuộc trò chuyện khó xử: 1-2 giờ
Thiết kế lại đúng cách: 4-8 giờ
Build: 2 tuần
Tổng: ~2 tuần + 2-3 ngày

AI brief thêm 1-2 ngày công việc. Không giảm. Thêm.

Và đây là kịch bản tốt — developer pushback sớm. Kịch bản xấu là developer cố “làm cho chạy” với kiến trúc AI, và project 2 tuần biến thành 6 tuần.

Phép Ẩn Dụ Nền Nhà

Tưởng tượng bạn là kiến trúc sư. Khách hàng đến nói: “Tôi muốn một ngôi nhà. Yêu cầu: 3 phòng ngủ, 2 phòng tắm, bếp, và garage.”

Tốt. Bạn sẽ thiết kế cái phù hợp với lô đất, ngân sách, nhu cầu gia đình.

Giờ tưởng tượng cùng khách hàng nói: “Tôi muốn một ngôi nhà. Nhưng trước tiên, tôi đã đổ nền rồi. Nền cho biệt thự 10 phòng ngủ. Tôi tìm blueprint trên mạng. Anh cứ xây nhà 3 phòng ngủ trên cái nền 10 phòng ngủ này.”

Bạn không thể “dùng phần tốt” của cái nền đó. Nền biệt thự 10 phòng ngủ khác cơ bản với nền nhà 3 phòng ngủ. Tường chịu lực ở vị trí khác. Đường ống khác. Điện khác.

Bạn có hai lựa chọn:

Xây nhà 3 phòng ngủ lệch lạc trên nền 10 phòng ngủ (over-engineered, lãng phí, kỳ cục)
Phá nền và làm lại (lãng phí hết “công sức” của khách)

Cả hai đều tệ hơn nếu khách chỉ nói “3 phòng ngủ, 2 phòng tắm, bếp, garage” và để bạn thiết kế từ đầu.

Đó là AI brief. Nó đổ nền trước khi kiến trúc sư nhìn thấy lô đất.

6. “Human Harness” Trông Như Thế Nào

OK đã xác lập vấn đề. Câu hỏi là: làm gì?

Nhớ Harness mình build cho AI Orchestrator? Cùng nguyên tắc áp dụng cho con người. Implementation khác thôi.

Nguyên tắc 1: Tool Restrictions — Dùng AI Để Khám Phá, Không Phải Implement

Khi Orchestrator có code execution tools, nó viết code. Khi mình gỡ tools đó, nó delegate.

Cho managers: dùng AI như công cụ nghiên cứu, không phải công cụ production.

Cách dùng AI tốt cho briefs:

“Những tính năng phổ biến trong user dashboard là gì?” (khám phá)
“Những cân nhắc security cho financial dashboard là gì?” (nghiên cứu)
“Giúp tôi diễn đạt rõ tôi cần gì từ dashboard này” (làm rõ)
“Tôi nên hỏi dev team những câu hỏi gì?” (chuẩn bị)

Cách dùng AI tệ cho briefs:

“Build cho tôi bản specification dashboard hoàn chỉnh” (implementation)
“Viết API design cho dashboard này” (implementation)
“Tạo prototype chạy được” (implementation)
“Tạo project timeline với estimates” (implementation không có chuyên môn)

Ranh giới rõ ràng: AI giúp bạn suy nghĩ. Nó không suy nghĩ thay bạn.

Nguyên tắc 2: Output Validators — Kiểm Tra Brief Trước Khi Gửi

AI Orchestrator của mình có validators kiểm tra: “Đây là delegation hay implementation?”

Managers nên tự kiểm tra tương tự trước khi gửi brief:

Brief Validator Checklist:

Brief này mô tả BÀI TOÁN, không phải solution?
Brief này nêu MỤC TIÊU, không phải implementation?
Brief này liệt kê CONSTRAINTS (timeline, budget, users), không phải kiến trúc?
Brief này dưới 2 trang? (Trên 2 trang = bạn đang implement)
Senior developer đọc xong có thể design BA solution khác nhau không? (Nếu không, bạn đã chọn solution rồi)
Brief này có chừa chỗ cho team kỹ thuật ra quyết định kiến trúc không?

Nếu “brief” của bạn fail checklist này, bạn không phải đang delegate — bạn đang implement. Và bạn có thể không có chuyên môn kỹ thuật để implement tốt.

Nguyên tắc 3: Role Enforcement — Nhớ Bạn Đang Trả Tiền Cho Cái Gì

Mình nói với Orchestrator: “Bạn là COORDINATOR, không phải IMPLEMENTER.”

Cùng thông điệp cho managers: bạn đang trả tiền cho phán đoán của senior developer, không phải tốc độ gõ phím.

Khi bạn gửi developer bản AI implementation và nói “dọn lại giúp anh,” bạn đang nói: “Anh không đánh giá cao chuyên môn của em. Anh chỉ cần người bấm nút deploy.”

Đó không phải việc senior developers làm. Đó không phải cái bạn đang trả tiền. Bạn đang trả tiền cho:

Phân tích bài toán: Hiểu nhu cầu thật đằng sau requirement
Thiết kế solution: Chọn kiến trúc đúng cho constraints
Quyết định trade-off: Cân bằng tốc độ, chất lượng, chi phí, khả năng bảo trì
Nhận diện rủi ro: Phát hiện cái có thể sai trước khi nó sai
Kinh nghiệm: Biết cái gì hoạt động ở scale của bạn vì đã thấy chuyện gì xảy ra ở các scale khác

AI không làm tốt những thứ này vì AI không biết công ty bạn, users, năng lực team, infrastructure, technical debt, hay scale thật. AI generate solutions hợp lý. Senior developers thiết kế solutions phù hợp.

Nguyên tắc 4: Feedback Loops — Trả Lại Cuộc Họp

Mình biết. Không ai thích họp. Nhưng nhớ cuộc họp làm gì?

Quy trình cũ:

Manager gửi brief (problem statement)
Meeting thảo luận
Developers hỏi những câu manager chưa nghĩ đến
Manager học thêm về constraints kỹ thuật
Cùng nhau đạt shared understanding
Developers thiết kế solution
Meeting review design
Build

Quy trình này chậm. Đôi khi bực bội. Nhưng nó phục vụ mục đích quan trọng: shared understanding.

Manager hiểu tại sao một số approach không khả thi. Developers hiểu business context. Tất cả aligned trước khi viết một dòng code.

Quy trình AI brief:

Manager + AI generate solution hoàn chỉnh
Manager gửi cho developers như “kế hoạch”
Developers nhận cái họ không được tham vấn
Không shared understanding, không thảo luận, không alignment
Developers hoặc pushback (khó xử) hoặc âm thầm vật lộn

Cuộc họp là Harness feedback loop phiên bản con người. Nó buộc alignment. Nó ngăn Orchestrator (manager) đi quá xa trên con đường implementation.

Trả lại cuộc họp. Hoặc ít nhất cuộc trò chuyện. Thậm chí 30 phút call mà manager nói “đây là cái anh cần và tại sao” có giá trị hơn bản spec 47 trang do AI generate.

Nguyên tắc 5: Gắn Nhãn AI Output Rõ Ràng

Nếu bạn nhất định phải đính kèm AI output trong brief (đôi khi nó hữu ích — AI giỏi generate ví dụ, explore khả năng, identify edge cases), gắn nhãn rõ ràng:

## Yêu Cầu Dashboard (từ Product team)
- Hiển thị tổng quan tài khoản (số dư, giao dịch gần đây)
- Lọc theo khoảng thời gian
- Xuất CSV
- Responsive trên mobile
- Target: 500 active users
- Timeline: 2 tuần

## AI Exploration (KHÔNG PHẢI design cuối cùng — chỉ để tham khảo)
Phần sau được Claude generate để explore các approach khả thi.
Team kỹ thuật nên dùng làm background context, không phải
specification.

[AI output ở đây]

Framing đơn giản này thay đổi mọi thứ. Nó nói với developer: “Anh biết đây không phải design. Anh đưa em làm context, không phải instruction. Em là người design.”

7. Nghịch Lý

Đây là cái khiến mình mất ngủ:

Chính năng lực khiến AI mạnh mẽ — khả năng generate output toàn diện, chi tiết, trông chuyên nghiệp — cũng chính là cái gây ra vấn đề.

Nếu AI generate output tệ rõ ràng, không ai dùng nó làm brief. Nhưng AI generate output trông rất tốt. Format chuẩn, coverage toàn diện, ngôn ngữ chuyên nghiệp, cấu trúc logic. Nó pass “trông đúng” test dễ dàng.

Vấn đề là “trông đúng” và “đúng thật” rất khác nhau.

Bản spec 47 trang trông toàn diện hơn brief 5 dòng. Nhưng brief 5 dòng đại diện cho phán đoán thật của con người về cái gì quan trọng, còn spec 47 trang đại diện cho AI pattern-matching trên cái specifications thường chứa.

Prototype chạy được trông như tiến bộ. Nhưng đó là tiến bộ theo hướng có thể sai, xây trên giả định chưa validate, dùng kiến trúc không fit constraints.

Sơ đồ microservices trông chuyên nghiệp hơn “mình dùng monolith đơn giản.” Nhưng cho 500 users, monolith là câu trả lời đúng và microservices là câu trả lời sai, bất kể diagram đẹp cỡ nào.

Vẻ ngoài chất lượng không phải chất lượng. Điều này đúng cho AI-generated code, AI-generated specs, và AI-generated briefs. Chất lượng đến từ reasoning đằng sau output — và khi bạn delegate reasoning cho AI, bạn mất chất lượng ngay cả khi giữ được vẻ ngoài.

Parallel với AI Orchestrator chính xác tuyệt đối:

AI Orchestrator (Không Harness)	Manager (Không Process)
Tự làm thay vì delegate	Tạo implementation thay vì brief
Bypass specialist agents	Bypass chuyên môn team kỹ thuật
Dùng tools bừa bãi	Dùng AI tools không phán đoán
Output chạy được nhưng không phù hợp	Spec trông chuyên nghiệp nhưng không phù hợp
Cần tool restrictions để đúng vai	Cần process để đúng vai
Cần output validators	Cần brief checklists
Cần role enforcement	Cần vai trò rõ ràng
Cần feedback loops	Cần meetings/conversations

Giải pháp hai bên giống nhau: Harness.

Cho AI agents, mình build bằng code. Cho con người, mình build bằng process.

Nhưng insight quan trọng: Harness không phải hình phạt. Nó là enabler. Orchestrator Agent của mình trở nên giỏi hơn khi mình thêm Harness. Nó ra quyết định coordination tốt hơn, duy trì context tốt hơn, và tạo ra outcomes tốt hơn cho cả hệ thống. Nó chỉ phải ngừng tự làm.

Managers dùng AI khôn ngoan — cho exploration, research, và preparation thay vì implementation — trở thành managers tốt hơn. Họ đến meetings với câu hỏi tốt hơn, context tốt hơn, hiểu biết sâu hơn. Họ chỉ phải ngừng làm việc của developer.

Harness không giảm sức mạnh. Nó tập trung sức mạnh.

8. Brief Tốt Trông Như Thế Nào?

Vì mình đã dành cả bài phàn nàn về brief tệ, mình show cho các bạn brief tốt. Ngay cả — đặc biệt là — trong thời đại AI.

Brief Tốt (Thời Đại Hậu AI)

# User Dashboard

## Bài Toán
Users hiện không có cách nào xem tình trạng tài khoản nhanh.
Họ gọi support ~30 lần/tuần hỏi về số dư và giao dịch gần đây.
Mình muốn giảm support calls bằng cách cho users tự xem.

## Mục Tiêu
1. Giảm 50% support calls loại "hỏi số dư"
2. Cho users thấy rõ tình trạng tài khoản
3. Cho users tìm giao dịch cụ thể mà không cần gọi support

## Thông Tin Chính
- Active users: ~500 (tăng ~10%/tháng)
- Data chính: số dư tài khoản, lịch sử giao dịch
- Users yêu cầu: lọc theo ngày, xuất CSV
- Phải chạy tốt trên mobile (60% users dùng mobile)

## Constraints
- Timeline: 2 tuần cho MVP
- Budget: [thảo luận riêng]
- Phải tích hợp auth system hiện tại (JWT, chi tiết với dev team)
- Backend: Python/FastAPI, Frontend: React

## Những gì mình EXPLORE với AI (background context, không phải spec)
Mình hỏi Claude về dashboard patterns phổ biến và có vài gợi ý
thú vị về data visualization. Đính kèm conversation để tham khảo.
Approach kỹ thuật 100% do team quyết định.

## Câu Hỏi Mở
- Có nên có notifications không? (Chưa chắc cần cho MVP)
- Real-time updates hay manual refresh? (Support team nói manual là đủ)
- Có concerns gì về data privacy cho transaction view không?

Để ý brief này làm gì:

Nêu bài toán (support calls, không phải “cần dashboard”)
Định nghĩa thành công (giảm 50% support calls, không phải “23 API endpoints”)
Cung cấp constraints (500 users, 2 tuần, tech stack hiện tại)
Chừa solution space mở (dev team quyết định kiến trúc)
Đính kèm AI exploration như context, gắn nhãn rõ ràng
Hỏi câu hỏi thay vì đưa câu trả lời

Brief này mất 20 phút viết. Bản AI spec mất 3 giờ. Và brief này sẽ dẫn đến sản phẩm tốt hơn, build nhanh hơn, ít xung đột hơn.

9. Chuyện Báo Giá

Mình nhịn lâu rồi, nhưng vì bài này đang nói thật thì nói luôn…

Khi bạn gửi mình bản specification 47 trang do AI generate với prototype chạy được và nói “80% xong rồi, dọn lại thôi,” đây là cái bạn thực sự yêu cầu mình làm:

Đọc và hiểu 47 trang spec (thời gian: tiền)
Xác định cái nào relevant cái nào AI hallucinate (thời gian: tiền)
Reverse-engineer bài toán thật (thời gian: tiền)
Nói chuyện khó xử về lý do mình không dùng spec của bạn (thời gian: năng lượng cảm xúc: tiền)
Thiết kế solution đúng (thời gian: tiền)
Build nó (thời gian: tiền)
Giải thích tại sao nó trông khác cái bạn kỳ vọng (thời gian: tiền)

So sánh với:

Đọc brief 1 trang (thời gian: ít)
Hỏi câu hỏi làm rõ (thời gian: tiền, nhưng productive)
Thiết kế solution (thời gian: tiền)
Build nó (thời gian: tiền)

Quy trình đầu có 7 bước. Quy trình sau có 4 bước. Ba bước thừa tồn tại hoàn toàn vì cái AI “brief.”

Nên khi bạn hỏi báo giá và nói “nên rẻ hơn vì anh đã làm phần lớn bằng AI,” câu trả lời trung thực là: nó nên đắt hơn vì bạn đã làm việc khó hơn.

Pricing model đúng cho năm 2026 không phải “AI làm 80%, trả 20%.” Mà là “AI khiến 20% còn lại khó hơn, nên trả 120%.”

Nhưng mình biết nếu mình nói vậy, bạn sẽ tìm người rẻ hơn không pushback bản spec AI. Rồi bạn sẽ mất 6 tuần và 3x ngân sách để học tại sao kiến trúc microservices do AI generate không hoạt động cho 500 users.

Nên mình chỉ nói: mình bàn về cái bạn thực sự cần nhé. Mang AI exploration làm context. Nhưng để mình làm việc mình — cái việc bạn đang trả tiền cho.

Và… mình chưa tăng gấp đôi giá đâu. Mình đang nhịn lắm rồi đấy.

10. Kết Luận: Xây Harness Của Bạn

Dù bạn đang build hệ thống AI agent hay quản lý team phần mềm, bài học giống nhau:

Sức mạnh không có process tạo ra hỗn loạn.

AI agent mạnh không có Harness sẽ tự làm hết, bypass specialists nó lẽ ra phải coordinate. Manager mạnh với AI tools sẽ tự làm hết, bypass developers họ lẽ ra phải empower.

Fix giống nhau trong cả hai trường hợp:

Restrict tools — Dùng AI cho exploration, không phải implementation
Validate output — Kiểm tra brief với delegation checklist
Enforce roles — Bạn là coordinator. Để team là implementers.
Close feedback loop — Nói chuyện. Trả lại cuộc họp.
Focus sức mạnh — Business knowledge của bạn + chuyên môn kỹ thuật của team = solution đúng

Harness không giới hạn sức mạnh. Nó điều hướng sức mạnh.

Xây Harness của bạn. Developers sẽ cảm ơn. Sản phẩm sẽ tốt hơn. Timeline sẽ ngắn hơn.

Và tech lead của bạn sẽ không phải viết blog post passive-aggressive về briefs của bạn.

Cảm ơn cộng đồng tech Việt Nam vì những cuộc trò chuyện đã truyền cảm hứng cho bài viết này. Đặc biệt cảm ơn khách hàng của mình — thật lòng — có thể sẽ gửi mình một AI-generated response cho bài viết này.

Nếu bạn là manager đang đọc và cảm thấy bị tấn công: mình không tấn công bạn. Mình đang cố giúp cả hai. AI tools rất tuyệt vời. Chỉ cần dùng khôn ngoan.

Nếu bạn là developer đang đọc và gật đầu: share cho manager đi. Hoặc không. Mình hiểu chính trị.

PS: Đừng có ép giá mình xuống nha… mình chưa tăng gấp đôi rate mà đã nhịn dữ lắm rồi đó! 😄

Thuận Lương là Tech Lead tại Việt Nam, chuyên về hệ thống Agentic AI và full-stack development. Ban ngày build kiến trúc multi-agent, ban đêm debug vấn đề phối hợp giữa con người và agent. Rate rất hợp lý. Hiện tại.

Xuất nội dung

Vấn Đề Harness: Khi AI Briefs Khiến Bạn Tốn Gấp Đôi Thay Vì Tiết Kiệm

Vấn Đề Harness: Khi AI Briefs Khiến Bạn Tốn Gấp Đôi Thay Vì Tiết Kiệm

1. Con Orchestrator Không Chịu Delegate

Dấu Hiệu Đầu Tiên

Tại Sao Nó Làm Vậy?

Hệ Quả Dây Chuyền

2. Giải Pháp Harness

Tool Restrictions

Output Validators

Role Enforcement trong System Prompt

Feedback Loops

Kết Quả

3. Bây Giờ Nói Chuyện Công Ty Các Bạn

4. Vấn Đề “AI Brief”

Bản Spec 47 Trang

Prototype “Chạy Được”

API Design

Gantt Chart

Kết Luận Của Manager

5. Tại Sao Khối Lượng Công Việc Nhân Đôi

Bước 1: Reverse Engineer Bài Toán Thật (2-4 giờ)

Bước 2: Validate Approach (2-4 giờ)

Bước 3: Cuộc Trò Chuyện Khó Xử (1-2 giờ)

Bước 4: Thiết Kế Solution Thật (4-8 giờ)

Bước 5: Build (phần việc thật)

Tính Toán

Phép Ẩn Dụ Nền Nhà

6. “Human Harness” Trông Như Thế Nào

Nguyên tắc 1: Tool Restrictions — Dùng AI Để Khám Phá, Không Phải Implement

Nguyên tắc 2: Output Validators — Kiểm Tra Brief Trước Khi Gửi

Nguyên tắc 3: Role Enforcement — Nhớ Bạn Đang Trả Tiền Cho Cái Gì

Nguyên tắc 4: Feedback Loops — Trả Lại Cuộc Họp

Nguyên tắc 5: Gắn Nhãn AI Output Rõ Ràng

7. Nghịch Lý

8. Brief Tốt Trông Như Thế Nào?

Brief Tốt (Thời Đại Hậu AI)

9. Chuyện Báo Giá

10. Kết Luận: Xây Harness Của Bạn

Bình luận

Vấn Đề Harness: Khi AI Briefs Khiến Bạn Tốn Gấp Đôi Thay Vì Tiết Kiệm