AI không thay thế phán đoán kỹ thuật: Xây dựng quy trình làm việc bền vững trong dự án phần mềm

“AI không thay thế phán đoán kỹ thuật — nó làm phán đoán đó quan trọng hơn.”

Đây là thông điệp cốt lõi được đúc kết từ quá trình đưa AI vào các dự án phần mềm thực tế.

Khi sử dụng các công cụ hỗ trợ lập trình bằng AI trong các thử nghiệm cá nhân hoặc đoạn mã nhỏ, kết quả thường rất ấn tượng: yêu cầu ngắn, phản hồi nhanh, mã chạy được ngay. Tuy nhiên, khi đưa AI vào một dự án phần mềm thực tế với codebase lớn, nhiều thành viên cùng tham gia và hệ thống nghiệp vụ phức tạp, cách làm việc dựa thuần vào prompt nhanh chóng bộc lộ các giới hạn kỹ thuật.

Vấn đề thực tế khi dùng AI trong dự án

Trong quá trình làm việc thực tế với AI, các kỹ sư thường gặp phải 4 vấn đề phổ biến sau:

• Mã chạy được nhưng không nhất quán với phần còn lại: AI tạo ra đoạn code đúng cú pháp và chạy được logic đơn lẻ, nhưng đặt tên hàm lệch chuẩn, tổ chức thư mục sai quy hoạch, hoặc dùng một thư viện khác với convention chung của dự án.
• Mất ngữ cảnh liên phiên (Stateless): Phiên làm việc hôm sau, AI không còn nhớ những gì đã thống nhất từ phiên trước. Kỹ sư phải giải thích lại kiến trúc từ đầu.
• Tự ý mở rộng phạm vi (Scope Creep): Khi nhận yêu cầu chỉnh sửa một logic nhỏ, AI thường tiện tay refactor các file xung quanh, đổi chữ ký hàm của module khác hoặc thêm tính năng không ai yêu cầu.
• Khối lượng review mã tăng cao: Đọc và kiểm tra mã do AI sinh ra tốn nhiều thời gian hơn tự viết, do phải rà soát các rủi ro tiềm ẩn về bảo mật, ép kiểu thiếu chặt chẽ hoặc bỏ qua các bước kiểm tra quyền truy cập.

Hậu quả điển hình trên quy mô lớn: mã nguồn nhất quán ở các file từ 1 đến 10, bắt đầu phân rã (code drift) từ file 30 trở đi, và không thể review nổi khi số lượng file chạm ngưỡng 80+.

Thay đổi tư duy: AI không phải autocomplete thông minh hơn

Nguyên nhân cốt lõi của tình trạng trên nằm ở góc nhìn tiếp cận công cụ:

Một developer mới vào dự án dù tiếp thu nhanh nhưng chưa thể nắm ngay toàn bộ quy ước ngầm, ranh giới kiến trúc hay các yêu cầu bảo mật của hệ thống. Thay vì liên tục nhắc nhở thủ công bằng lời trong từng tác vụ, giải pháp bền vững là cung cấp tài liệu quy chuẩn, thiết lập công cụ kiểm tra tự động và phân định phạm vi trách nhiệm rõ ràng.

Prompt là lệnh một lần. Governance system là hạ tầng.

Mô hình 3 tầng: Con người · Hệ thống · AI

Để tích hợp AI an toàn vào dự án dài hạn, quy trình làm việc cần được tổ chức thành 3 tầng phân cấp:

flowchart LR
    subgraph Human_Layer ["Layer 1: Human Engineer"]
        direction TB
        H1["<b>System Thinking & Technical Judgment</b>"]
        H2["<b>Trade-off Decisions & Risk Assessment</b>"]
    end

    subgraph Governance_Layer ["Layer 2: Governance System"]
        direction TB
        G1["<b>1. Convention Files:</b> CLAUDE.md & rules/"]
        G2["<b>2. Confidence Gate:</b> Threshold & Protocols"]
        G3["<b>3. Specialized Agents:</b> Planner, Executor, Reviewer"]
        G4["<b>4. Pre-commit Hooks:</b> Block & Warning"]
    end

    subgraph AI_Layer ["Layer 3: AI Execution"]
        direction TB
        A1["<b>Context Loading & Proposal</b>"]
        A2["<b>Self-Assessment (< 0.7 Escalates)</b>"]
        A3["<b>Execution within Boundaries</b>"]
        A4["<b>Commit & Verification</b>"]
    end

    H1 -->|"Encode rules"| G1
    G1 -->|"Inject context"| A1
    A1 -->|"Evaluate score"| G2
    G2 -->|"Escalate if < 0.7"| H2
    G2 -->|"Approved (>= 0.7)"| G3
    G3 -->|"Plan & Execute"| A3
    A3 -->|"Trigger git hook"| G4
    G4 -->|"Block or pass"| A4
    G4 -->|"Warning review"| H2

• Con người: Đảm nhiệm tư duy hệ thống, phán đoán kỹ thuật và đưa ra các quyết định đánh đổi (trade-offs). Trọng tâm của kỹ sư là mã hóa các phán đoán kỹ thuật thành quy tắc hệ thống, thay vì lặp lại các chỉ dẫn thủ công trong từng câu prompt.
• Hệ thống Governance: Hạ tầng trung gian gồm convention files, pre-commit hooks, specialized agents và các protocols. Hệ thống này nạp ngữ cảnh tự động và thiết lập rào chắn kỹ thuật (guardrails).
• AI: Đóng vai trò thực thi tác vụ với tốc độ cao. AI vận hành trong phạm vi giới hạn đã được hệ thống định sẵn.

4 Lớp Governance kiểm soát AI trong dự án

Quy trình governance được tổ chức thành 4 chốt chặn tuần tự xuyên suốt vòng đời của từng tác vụ AI:

flowchart LR
    P1["<b>1. Convention File</b><br/>Modular rules & context"] --> P2["<b>2. Confidence Gate</b><br/>Score assessment & escalation"]
    P2 --> P3["<b>3. Specialized Agents</b><br/>Planner, Executor, Reviewer"]
    P3 --> P4["<b>4. Pre-commit Hooks</b><br/>Hard block & warning checks"]

Lớp 1 — Convention Files: Nền tảng quy tắc

Convention file là tài liệu quy chuẩn dự án được nạp tự động vào mỗi phiên làm việc với AI (ví dụ CLAUDE.md, AGENTS.md, hoặc system_prompt.md).

Để tránh tình trạng quá tải ngữ cảnh (context window) khiến AI bỏ sót thông tin, convention file nên được chia nhỏ theo mô hình modular:

project-root/
├── CLAUDE.md                  # File gốc: Tổng quan stack, 5-10 quy tắc cứng, index trỏ tới rules
└── rules/
    ├── architecture.md        # Giới hạn kích thước file, ranh giới phân tách module
    ├── security.md            # Xác thực, phân quyền, kiểm tra input, cấm hardcode secrets
    ├── patterns.md            # Quy chuẩn đặt tên, cấu trúc component, kiểu dữ liệu
    └── testing.md             # Tiêu chuẩn coverage, phương pháp viết kiểm thử

Nguyên tắc triển khai:

• File gốc chỉ chứa từ 5 đến 10 quy tắc cứng.
• Không đưa vào các quy tắc lý thuyết chung chung. Mọi quy tắc phải xuất phát từ lỗi thực tế hoặc vấn đề lặp lại trong quá trình phát triển.

Lớp 2 — Confidence Gate: Chốt chặn tự tin trước khi thực thi

Sau khi nạp ngữ cảnh từ convention files, bước nguy hiểm nhất là khi AI nhận yêu cầu nhưng chưa nắm rõ codebase đã vội vàng sinh mã. Khi gặp ngữ cảnh chưa rõ ràng, AI có xu hướng tự đưa ra giả định ngầm dẫn đến lỗi lan truyền (code drift).

Để chuẩn hóa phản ứng của AI trong các tình huống này, hệ thống áp dụng Confidence Gate và Deviation Protocol:

Đánh giá Confidence Score

Trước khi bắt đầu lập kế hoạch hoặc viết mã, AI phải tự đánh giá mức độ tự tin trên 4 tiêu chí theo thang điểm từ 0 đến 1:

• Scope: Yêu cầu đầu ra có đủ rõ ràng không?
• Target: Đã xác định đúng các file và thành phần liên quan trong codebase chưa?
• Output: Tiêu chí nghiệm thu có đo lường cụ thể được không?
• Risk: Đã nhận diện được các rủi ro ảnh hưởng tới chức năng hiện tại chưa?

Nếu bất kỳ tiêu chí nào đạt điểm dưới 0.7, AI phải dừng lại và đặt câu hỏi cho kỹ sư, tuyệt đối không được tự suy đoán.

Deviation Protocol

Xử lý các tình huống phát sinh trong quá trình thực thi:

• Lỗi cú pháp nhỏ trong phạm vi task: Tự xử lý.
• Yêu cầu thay đổi kiến trúc hoặc lược đồ dữ liệu: Dừng lại và xin ý kiến kỹ sư.
• Phát hiện vấn đề nằm ngoài phạm vi yêu cầu ban đầu: Ghi nhận vào backlog, không tự ý sửa.

Lớp 3 — Specialized Agents: Phân tách vai trò

Khi đã vượt qua Confidence Gate, công việc chuyển sang giai đoạn thực thi. Nếu để một agent duy nhất đảm nhiệm toàn bộ quy trình từ lập kế hoạch, viết code đến kiểm tra, hệ thống mất đi cơ chế kiểm soát chéo. Mô hình cần phân chia thành các agent chuyên trách:

Quy trình phối hợp: Planner đọc convention và xác định phạm vi -> Kỹ sư phê duyệt -> Executor viết mã -> Reviewer kiểm tra.

Lớp 4 — Pre-commit Hooks: Tường phòng thủ tự động

Dù convention file và agent có chặt chẽ đến đâu, vẫn luôn có xác suất AI vi phạm quy chuẩn. Pre-commit Hook là chốt chặn vật lý tự động trên máy lập trình trước khi mã nguồn được commit vào git repository.

Hệ thống kiểm tra được phân thành 2 cấp độ:

flowchart LR
    subgraph AI_Layer ["Layer 1: AI Developer"]
        direction TB
        C1["<b>AI Commit Code</b><br/>Task completed, trigger hook"]
        Fix["<b>Fix & Re-commit</b><br/>Fix issues and retry"]
    end

    subgraph Block_Layer ["Layer 2: Block Gate"]
        direction TB
        G1{"<b>Scan Secrets, .env, Test</b>"}
        B1["<b>Hard Block (Hủy commit)</b><br/>Secrets leaked, .env exposed, test fail"]
    end

    subgraph Warn_Layer ["Layer 3: Warning Gate"]
        direction TB
        G2{"<b>Scan Code Quality & Scope</b>"}
        W1["<b>Warning (Rung cảnh báo)</b><br/>console.log, type any, scope > 15 files"]
    end

    subgraph Human_Layer ["Layer 4: Human Approval"]
        direction TB
        Rev["<b>Scope Verification</b><br/>Review warning & approve"]
        Pass["<b>Approved Git Commit</b><br/>Merged cleanly into repository"]
    end

    C1 --> G1
    G1 -->|"Violations found"| B1
    B1 --> Fix
    Fix --> C1
    G1 -->|"Pass"| G2
    G2 -->|"Warning flagged"| W1
    W1 --> Rev
    Rev -->|"Approved"| Pass
    G2 -->|"No warnings"| Pass

Các bài kiểm tra thực tế cần ưu tiên:

• Quét chuỗi nhạy cảm: Ngăn chặn lộ API token, private key trong commit.
• Chặn type any: Kiểm soát chặt chẽ tính an toàn kiểu dữ liệu trong production code.
• Giới hạn số file thay đổi: Rung cảnh báo khi một commit vượt quá 15 file để ngăn AI tự ý tái cấu trúc ngoài phạm vi task.

Case Study: Tự động hóa sinh kiểm thử trong dự án thực tế

Trong một dự án thực tế mà nhóm mình tham gia, đội ngũ QA ban đầu phải trích xuất thủ công các test case từ GitHub Issues. Quy trình này tốn nhiều thời gian và dễ sót các trường hợp biên.

Nhóm kỹ sư đã xây dựng quy trình AI-assisted Test Generation tích hợp các lớp governance:

flowchart LR
    subgraph Input_Layer ["Layer 1: Input & Artifacts"]
        direction TB
        I1["<b>GitHub Issue #4727</b><br/>Feature request or bug report"]
        Export["<b>Export Excel File</b><br/>Standardized test cases delivered"]
    end

    subgraph Agents_Layer ["Layer 2: Specialized AI Agents"]
        direction TB
        AC["<b>AI Product Owner</b><br/>/generate-acceptance-criteria"]
        COV["<b>AI QA Lead</b><br/>/generate-test-coverage"]
        TC["<b>AI Test Generator</b><br/>/generate-test-cases (TC_001)"]
    end

    subgraph Human_Layer ["Layer 3: Human Gate (QA Engineer)"]
        direction TB
        Review{"<b>MANDATORY: Human Review</b><br/>Audit & approve test coverage<br/><i>(AI blocked until approved)</i>"}
    end

    I1 --> AC
    AC --> COV
    COV --> Review
    Review -->|"Approved"| TC
    TC --> Export

Cách áp dụng các lớp governance trong case study:

• Convention File: CLAUDE.md quy định cách đặt tên test case (TC_001), giới hạn phạm vi ứng dụng và áp dụng nguyên tắc lean testing.
• Specialized Agents: AI đóng vai Product Owner khi trích xuất tiêu chí nghiệm thu (AC) và chuyển sang vai QA Lead khi lập ma trận độ phủ (Coverage).
• Protocols: Bước rà soát độ phủ của con người (Human review) là bắt buộc. AI không thể tự chuyển sang bước sinh test case nếu chưa có phê duyệt.
• Guardrails: Thiết lập anti-patterns cứng, ngăn AI sinh các test case dư thừa (như kiểm tra định dạng thời gian máy khách, tải lại trang).

Kết quả đo lường: Giảm khoảng 70% thời gian viết test case thủ công, đồng thời duy trì tính chuẩn hóa của bộ kiểm thử.

So sánh hiệu quả trước và sau khi áp dụng Governance

Lộ trình triển khai theo từng giai đoạn

Việc xây dựng hệ thống quản trị cho AI nên được thực hiện tuần tự theo mức độ phát triển của dự án:

• Ngày 1: Khởi tạo file CLAUDE.md cơ bản gồm thông tin tech stack, từ 5 đến 10 quy tắc bắt buộc và cấu trúc trỏ tới thư mục rules/.
• Tuần 1: Bổ sung các file quy tắc chi tiết từ các lỗi phát sinh thực tế. Mỗi khi AI lặp lại một lỗi kỹ thuật, hãy mã hóa lỗi đó thành một quy tắc mới.
• Tuần 2–3: Thiết lập Pre-commit Hooks. Bắt đầu với mức cảnh báo (Warning), sau đó nâng lên mức chặn hoàn toàn (Block) đối với việc lộ secret, commit file .env hoặc thiếu kiểm tra xác thực.
• Tháng 2 trở đi: Tách các specialized agents khi quy trình phát sinh các luồng công việc phức tạp; áp dụng Confidence Gate khi yêu cầu nghiệp vụ có tính mơ hồ cao.

Cảnh báo về hiện tượng Governance Bloat

Một rủi ro kỹ thuật khi xây dựng hệ thống quy tắc là việc tích lũy quá nhiều quy định không cần thiết (Governance Bloat). Sau một thời gian, số lượng quy tắc quá lớn sẽ làm cạn kiệt context window của mô hình, gây ra sự chậm trễ hoặc tạo ra các chỉ dẫn mâu thuẫn lẫn nhau.

Quy trình rà soát định kỳ (Quarterly Audit) cần đặt ra 4 câu hỏi cho mỗi quy tắc, hook hoặc agent:

1. Quy tắc này được áp dụng lần cuối khi nào?
2. Quy tắc này giải quyết vấn đề kỹ thuật cụ thể nào trong thực tế?
3. Có phiên bản triển khai nào đơn giản hơn không?
4. Quy tắc này có mâu thuẫn với các quy tắc khác trong hệ thống không?

Hệ thống quản trị cần mở rộng khi phát sinh vấn đề mới và phải được tinh gọn khi vấn đề không còn tồn tại. Việc cắt tỉa (pruning) đóng vai trò quan trọng tương đương với việc xây dựng mới.

Kết luận

Sự phát triển của AI đang dịch chuyển vai trò của kỹ sư phần mềm lên tầng bài toán và thiết kế hệ thống (Problem Layer):

• Tầng thực thi cú pháp và viết mã boilerplate: AI đảm nhiệm với tốc độ cao.
• Tầng tư duy hệ thống, phân tích rủi ro kỹ thuật và đưa ra quyết định đánh đổi: Kỹ sư là yếu tố quyết định.

Trọng tâm công việc của kỹ sư phần mềm hiện nay là mã hóa các phán đoán kỹ thuật tốt nhất vào một hệ thống quản trị nhất quán, thay vì phụ thuộc vào việc nhắc nhở thủ công qua từng phiên làm việc.

Câu hỏi thảo luận

• Nhóm của bạn đang kiểm soát tính nhất quán của mã nguồn do AI sinh ra bằng phương pháp nào?
• Những kiểm tra tự động nào qua pre-commit hook đem lại hiệu quả rõ rệt nhất trong dự án của bạn?