Nếu dạo một vòng LinkedIn hoặc Twitter, bạn sẽ thấy vô số bài viết với những tuyên bố gây sốc: “AI sẽ thay thế QA”, “Product Manager sẽ tự viết code”, hay “1 Dev bây giờ bằng 10 Dev ngày xưa”.

Dưới góc nhìn của một Engineering Manager hoặc System Architect, những tuyên bố này vừa thiếu dữ liệu thực tế (Data), vừa làm mất uy tín (Credibility). Trong môi trường Enterprise, việc áp dụng AI không làm biến mất các vai trò, mà nó làm Dịch chuyển Nút thắt cổ chai (Shift the Bottleneck).

Khi tốc độ viết code tăng lên 10x, nút thắt lập tức chuyển sang khâu: Làm rõ Yêu cầu (Requirements/Specs) và Kiểm định Kiến trúc (Architecture Review).

Đây là lúc bạn phải vứt bỏ quy trình Scrum/Agile truyền thống và xây dựng một Mô hình Vận hành (Operating Model) mang tính kỹ thuật cao hơn.

1. Tư Duy Mới: Spec-First Development

Trong SDLC (Software Development Life Cycle) truyền thống, Dev thường đọc lướt một cái Jira ticket sơ sài, sau đó vừa code vừa mò mẫm logic (Trial and Error).

Với AI, làm như vậy là tự sát. Nếu bạn cung cấp một context mơ hồ, LLM sẽ ngay lập tức “bịa” ra (hallucinate) các luồng logic rác rưởi nhưng trông có vẻ cực kỳ chuyên nghiệp.

Workflow Mới (Spec-First):

  1. Human Design: Dev/Architect dành 70% thời gian để viết file Markdown (Specs), định nghĩa rõ Interface, Cấu trúc Database, và các Điều kiện biên (Boundary Conditions).
  2. AI Execution: Ném file Specs chuẩn xác này vào IDE (Cursor/Windsurf). AI mất 3 phút để đổ (gen) hàng ngàn dòng code.
  3. Architecture Review Loop: Dev dành 30% thời gian còn lại đóng vai trò là “Người kiểm duyệt” (Reviewer) xem mã nguồn có phá vỡ Bounded Context (DDD) hay không.

💡 Sự thật về nghề QA: QA không hề biến mất. Thay vì test thủ công bằng chuột, QA chuyển sang viết Automation Script hoặc cấu hình Prompt cho hệ thống Agentic CI/CD (Bài 4) để tạo rào chắn bảo vệ hệ thống.

2. Ranh Giới Ủy Quyền (AI Escalation Boundary)

Đây là chính sách kỹ thuật (Technical Policy) bắt buộc phải có để giữ cho hệ thống Enterprise không bị sụp đổ. Không phải cái gì sinh ra từ AI cũng được phép merge vào Production.

Bạn phải định nghĩa rõ Ranh giới Đỏ (Red Zone) và Ranh giới Xanh (Green Zone) cho LLM.

🟢 Green Zone (AI được phép tự trị - High Automation)

  • Boilerplate & CRUD APIs: Các controller, repository, DTOs cơ bản.
  • Test Generation: Sinh Unit Test, Mocks, và E2E Test (dựa trên Specs).
  • Refactoring Code Cũ: Chuyển đổi cú pháp, tách hàm (với điều kiện đã có test cover).
  • Data Transformation: Map dữ liệu từ hệ thống A sang DTO của hệ thống B.

🔴 Red Zone (Cấm AI tự quyết - Human Mandatory)

Ở những khu vực này, lỗi logic đồng nghĩa với việc đi tù hoặc phá sản. Code sinh ra (nếu có) phải bị soi xét cực đoan bởi Senior Engineers.

  • Auth & RBAC Logic: Phân quyền người dùng, mã hóa Token, session management. (Lỗ hổng ở đây sẽ làm lộ toàn bộ dữ liệu người dùng).
  • Payment & Financial Gateways: Thuật toán tính tiền, khấu trừ ví, tích hợp Stripe/PayPal.
  • Distributed Transactions (Saga/Outbox): Logic roll-back dữ liệu giữa nhiều Microservices khi mạng bị rớt. (LLM tư duy chuỗi rất kém trong các kịch bản lỗi mạng).
  • Infrastructure Policy: Terraform scripts lõi cấp phát quyền IAM hoặc mở cổng Security Group trên AWS.

3. Định Nghĩa Hoàn Thành Mới (New Definition of Done - DoD)

Để quản trị chất lượng (AI Quality Ownership), tiêu chuẩn “Done” của một tính năng phải được nâng cấp. Một task trên Jira chỉ được đóng lại khi thỏa mãn:

  1. Prompt Traceability: PR (Pull Request) đã ghi rõ đoạn code này được sinh ra từ LLM nào và file Context gốc là gì (để phục vụ Audit sau này).
  2. Boundary Coverage: Đã có Unit Test bao phủ 100% các điều kiện biên (Null, Âm, Max) được quét qua bởi Agentic CI/CD.
  3. Escalation Compliance: Nếu có sửa đổi liên quan đến Red Zone (như sửa logic thanh toán), bắt buộc phải có Approve từ Principal Engineer (không dùng AI Reviewer).
  4. No Deterministic Violations: Vượt qua hoàn toàn các lớp kiểm tra kiến trúc tĩnh (như cấm import chéo giữa các domain).

4. Quyền Sở Hữu Chất Lượng (AI Quality Ownership)

[Anti-pattern]: Đổ lỗi cho AI Khi hệ thống có bug trên Production, Dev giải trình: “Do con Claude 3.5 nó sinh code sai chứ em không biết”.

Đây là tư duy độc hại nhất trong một AI-Native Team. Máy móc không có trách nhiệm pháp lý, con người mới có.

Operating Model mới phải quy định rõ: Người đưa ra Prompt là người Sở hữu (Own) kết quả của đoạn code đó. Lập trình viên giờ đây đóng vai trò như một Người chỉ huy (Orchestrator). Nếu lính của bạn (AI) bắn nhầm mục tiêu do bạn đưa tọa độ sai, lỗi là ở bạn.

Tổng Kết

Một AI-Native Engineering Team không phải là tập hợp của những người biết dùng công cụ nhanh nhất, mà là tổ chức sở hữu quy trình SDLC kỷ luật nhất. Việc thiết lập Ranh giới ủy quyền (Escalation Boundary) và bắt buộc tư duy Spec-First chính là liều thuốc giải cho nợ kỹ thuật.

Đến đây, tổ chức của bạn đã có một bộ máy sản xuất (Team) mạnh mẽ và an toàn. Nhưng ở góc độ Ban Quản Trị Hệ Thống (Platform / SRE), bạn vẫn đang “mù lòa”. Bạn không biết team đang đốt bao nhiêu nghìn Token mỗi ngày, cũng không biết tỷ lệ AI trả lời sai ngữ cảnh là bao nhiêu.

Đó là lý do chúng ta phải bước sang Bài 6 — AI Observability & Production Governance: Xây dựng hệ thống giám sát và Evals (Đánh giá) — trái tim của việc vận hành AI trong Enterprise.