Sổ Tay Thực Chiến SDD Spec-Driven Development
“Khi AI có thể viết code nhanh gấp mười lần, cái bẫy lớn nhất không phải là code chậm, mà là đi lạc hướng với tốc độ ánh sáng.”
📌 Bài 2 (Thực chiến cầm tay chỉ việc): Hướng dẫn thực hành chi tiết từng bước áp dụng Spec-Driven Development (SDD) vào dự án.
- 📖 Bài 1 (Tư duy & Lý thuyết): Bí Mật Vibe Coding: Bắt AI Làm Thợ, Giữ Lấy Cái Đầu Bằng SDD
- 📥 Tải về Ebook SDD (PDF): Download SDD-Ebook.pdf
Tài liệu đúc kết toàn diện và thực chiến từ cuốn sách Spec-Driven Development (SDD), giúp kỹ sư, Tech Lead và Product Owner thoát khỏi “cơn sốt vibe coding” để xây dựng hệ thống phần mềm có kiến trúc vững chắc, kiểm thử bọc lót và ngữ cảnh sống cùng AI.
🧭 Mô hình tổng thể
┌──────────────────────────────────────────────┐
│ 🧠 CON NGƯỜI (Ý Định & Quyết Định) │
│ 1. Business Requirement ➔ 2. Use Case │
└──────────────────────┬───────────────────────┘
│ (Đặc tả ngữ cảnh)
┌──────────────────────▼───────────────────────┐
│ 📜 BẢN ĐẶC TẢ SỐNG (Giao Diện Trung Tâm) │
│ 3. Entity Model ➔ 4. Acceptance Criteria │
└──────────────────────┬───────────────────────┘
│ (Prompt & Constraints)
┌──────────────────────▼───────────────────────┐
│ 🤖 AI & HỆ THỐNG (Hiện Thực Hóa) │
│ 🛡️ Test Suite ➔ ⚙️ Clean Code (Adapter) │
└──────────────────────────────────────────────┘
Luồng Traceability chuẩn:
[Business Requirement] ➔ [Use Case] ➔ [Entity Model] ➔ [Acceptance Criteria] ➔ [Test Suite] ➔ [Clean Code]
⚠️ Cái bẫy Vibe Coding và sự trỗi dậy của Spec
Vibe coding là trạng thái dev ngồi cạnh AI, ra lệnh bằng ngôn ngữ tự nhiên: “Thử thêm cái này xem”, “Sửa lại tí”, “Trông ổn rồi đấy, merge thôi”.
Ở tuần đầu tiên, năng suất tăng vọt. Nhưng đến tháng thứ tư khi nghiệp vụ thay đổi, một tính năng tưởng như mất hai ngày lại ngốn mất hai tuần. Tại sao?
- Yêu cầu nằm trong đầu người, không nằm trong hệ thống: Khi PO nói “cho vay tiêu dùng nhỏ”, trong đầu họ có cả ma trận điều kiện về tuổi, lịch sử nợ, hạn mức. AI chỉ đoán mò một phần, code trở thành mớ hỗn độn giữa nghiệp vụ thật và suy diễn của mô hình.
- AI không có ký ức dài hạn của team: AI không tham gia họp sprint, không biết thỏa thuận miệng nào là tạm thời cho MVP, điều nào là bắt buộc pháp lý. Nếu không viết ra, với AI chúng hoàn toàn vô hình.
- Cảm giác an toàn giả từ test do AI tự sinh: AI viết code rồi tự viết test dựa trên chính code đó chỉ chứng minh được “code đang làm đúng thứ nó vừa viết”, chứ không chứng minh được “hệ thống đang đáp ứng đúng thứ doanh nghiệp cần”.
- Loại nợ kỹ thuật mới: Code không có ngữ cảnh. Code rất sạch, test xanh mướt, nhưng không ai dám sửa vì không ai hiểu ý định ban đầu.
Định nghĩa Spec-Driven Development (SDD): Spec đứng ở vị trí trung tâm để con người thống nhất ý định; AI viết code, test và tài liệu xoay quanh nó. Khi có gì sai lệch, sửa spec trước rồi mới sửa code.
🏗️ Bốn tầng yêu cầu: Khung xương sống của Spec
Để AI không bị “ảo giác” và lập trình viên không bị lạc lối, mọi đặc tả kỹ thuật cần đi qua 4 tầng rành mạch:
┌────────────────────────────────────────────────────────┐
│ 1. Business Requirement (BR): Vì sao làm? │
│ Mục tiêu kinh doanh, KPI đo lường, In/Out Scope │
├────────────────────────────────────────────────────────┤
│ 2. Use Case (UC): Ai làm gì? │
│ Actor, Trigger, Precondition, Main Flow, Exception │
├────────────────────────────────────────────────────────┤
│ 3. Entity Model (Domain): Dùng những khái niệm nào? │
│ Ubiquitous Language, Aggregate, State Lifecycle │
├────────────────────────────────────────────────────────┤
│ 4. Acceptance Criteria (AC): Làm sao biết là đúng? │
│ Given - When - Then ➔ Chuyển dịch 1-1 sang Test │
└────────────────────────────────────────────────────────┘
1. Business Requirement (BR)
Trả lời câu hỏi: Tại sao phải làm tính năng này? Gồm:
- Bối cảnh nghiệp vụ và mục tiêu đo lường được (KPI).
- Ranh giới phạm vi rõ ràng:
In Scope(MVP làm gì) vàOut of Scope(tuyệt đối không làm gì ở giai đoạn này).
2. Use Case (UC) sống được
Một Use Case hữu ích trong kỷ nguyên AI cần tối thiểu:
- ID: Duy nhất (vd:
UC-042) để lần vết từ commit, code đến incident. - Actor: Ai khởi chạy (khách hàng, admin, hệ thống ngoài, cron job)?
- Trigger: Khi nào kích hoạt (click button, nhận webhook, chạm mốc thời gian)?
- Preconditions & Postconditions: Điều kiện tiên quyết và trạng thái sau khi hoàn tất.
- Main Flow & Alternate/Exception Flow: Các bước thành công và các ngã rẽ xử lý lỗi.
3. Entity Model & Ngôn ngữ chung (Ubiquitous Language)
Đừng bao giờ prompt AI bằng tên bảng vô nghĩa như tbl_dh_v2(id, ma_kh, tt). Hãy nói về Domain: Order có nhiều OrderItem, thuộc về một Customer, sở hữu vòng đời trạng thái: draft, awaiting_payment, paid, cancelled.
Khi có Entity Model rõ, AI tự động hiểu business invariant và sinh ra các guard clause chặt chẽ.
4. Acceptance Criteria (AC) dạng Given-When-Then
Đây là cây cầu nối trực tiếp từ Spec sang Test Suite tự động:
AC-1: Thanh toán hợp lệ trong thời gian mở
Given: QRSession còn hiệu lực 5 phút
When: Cổng thanh toán gửi webhook báo thành công khớp order_id và amount
Then: Order chuyển sang trạng thái paid
And: Gửi email xác nhận trong vòng 10 giây
🧩 Hexagonal Architecture: Bệ phóng hoàn hảo cho SDD
Tại sao kiến trúc Lục giác (Hexagonal / Ports & Adapters) lại trở thành cặp bài trùng với AI?
┌──────────────────────────────────────┐
│ ADAPTER NGOÀI │
│ (HTTP, CLI, Webhook, Cron, UI) │
│ │ │
│ ▼ │
│ ┌───────────────────────────┐ │
│ │ PORT (Inbound) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ DOMAIN CORE / USECASE │ │
│ │ (Chứa toàn bộ Business │ │
│ │ Invariants & Entities) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ PORT (Outbound) │ │
│ └───────────────────────────┘ │
│ │ │
│ ▼ │
│ (Postgres, Redis, Stripe, Mail) │
│ ADAPTER NGOÀI │
└──────────────────────────────────────┘
- Bảo vệ lõi nghiệp vụ (Domain Core): Spec chính là mô tả của Domain Core. Phần lõi này hoàn toàn độc lập với framework, cơ sở dữ liệu hay third-party API.
- AI làm việc cực tốt ở tầng Adapter: Việc viết code cắm vào cơ sở dữ liệu, gọi API đối tác, hay render UI là phần việc có pattern lặp lại cao. Con người giữ chắc phần Core, để AI tha hồ sinh code tầng Adapter.
⚡ 6 Nguyên tắc vàng của Spec-Driven Development
Được chắt lọc từ chuẩn mực kỹ nghệ AI Unified Process (AIUP):
[1. Requirements-Driven] ──────► Spec dẫn dắt Code (Spec First)
│
[2. AI-Assisted] ──────► AI thực thi lặp lại, Con người quyết định
│
[3. Iterative] ──────► Spec là tài liệu sống, tiến hóa qua phản hồi
│
[4. Test-Protected] ──────► Test bọc theo AC, bảo vệ khi AI regenerate
│
[5. Stakeholder-Centric] ──────► Ngôn ngữ chung, PO và Dev cùng đọc hiểu
│
[6. Traceable] ──────► Truy vết 1-1: BR ➔ UC ➔ AC ➔ Test ➔ Code
- Requirements-Driven (Spec dẫn dắt Code): Khi có thay đổi, sửa spec trước. Trong code review, bất kỳ PR nào thêm field, đổi logic hay thêm flow mà không gắn kèm Spec ID đều bị gắn nhãn
needs-spec. - AI-Assisted (AI hỗ trợ, người làm chủ): Giao cho AI phần CRUD, mapping, boilerplate, sinh test theo AC. Giữ lại cho con người: chính sách tiền bạc, hạn mức tín dụng, bảo mật và kiến trúc lõi.
- Iterative Improvement (Lặp để học): Đừng cố vẽ spec hoàn hảo trong ngày đầu. Spec sống cùng sản phẩm, chỉnh sửa dần khi va chạm nghiệp vụ thực tế.
- Test-Protected (Bảo vệ bằng kiểm thử): Khi AI sinh lại (regenerate) code, điều gì đảm bảo nó không làm hỏng tính năng cũ? Đó chính là test suite bọc kín từng AC.
- Stakeholder-Centric (Lấy bên liên quan làm trung tâm): Spec không viết bằng code giả hay thuật toán hàn lâm. Spec phải viết bằng ngôn ngữ mà PO, BA, kế toán và QA đều đọc và phản biện được.
- Traceable (Truy vết hai chiều): Từ một dòng code hay test, chỉ mất 10 giây để tìm ra nó sinh ra vì AC nào, thuộc Use Case nào và giải quyết bài toán kinh doanh nào.
🚀 Greenfield: Từ số 0 lên số 1 trong 5 ngày với SDD
Hành trình xây dựng một ứng dụng mới từ con số không (Case study: Hệ thống chấm công & nghỉ phép nội bộ):
Ngày 1: INCEPTION Ngày 2: ELABORATION Ngày 3 & 4: IMPLEMENT Ngày 5: SHIP & LEARN
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ • Chốt BR-001 │ ──► │ • Entity Model │ ──► │ • Viết AC chi │ ──►│ • Deploy staging │
│ • In/Out Scope │ │ • Use Case Stubs │ │ tiết │ │ • Thu thập phản │
│ • Liệt kê UC stubs│ │ • Actor & Events │ │ • AI sinh code & │ │ hồi thực tế │
└──────────────────┘ └──────────────────┘ │ test theo AC │ │ • Cập nhật spec │
└──────────────────┘ └──────────────────┘
Ngày 1: Inception & Business Requirement Catalog
- Ngồi lại 2 tiếng giữa PO và Tech Lead để xác định mục tiêu và ranh giới.
- Tạo file
BR-001-attendance-system.mdghi rõ: mục tiêu giảm thời gian duyệt nghỉ phép < 24h, MVP chỉ làm web (không làm mobile app, không tích hợp máy chấm công vân tay). - Liệt kê danh sách các Use Case stub:
UC-001-login,UC-002-attendance-check,UC-003-request-leave,UC-004-approve-leave.
Ngày 2: Elaboration, Entity Model & Diagram
- Phác thảo Entity Model:
Employee,AttendanceRecord,LeaveRequest. - Ghi rõ các Business Invariant: Một LeaveRequest chỉ trừ số ngày phép khi đã chuyển sang trạng thái APPROVED.
- Sắp xếp cấu trúc thư mục
/specstrong Git repo.
Ngày 3 & 4: Chi tiết hóa AC và để AI triển khai
-
Bổ sung Given-When-Then cho từng Use Case (AC-1: Gửi đơn hợp lệ, AC-2: Từ chối ngày quá khứ, AC-3: Từ chối khi hết ngày phép còn lại).
-
Đưa spec vào cho AI agent (Claude Code, Cursor, Copilot) với prompt có khuôn khổ rõ ràng.
-
Prompt mẫu:
Hãy đọc kỹ file
specs/use-cases/UC-003-request-leave.mdvàspecs/entities/entity-model.md. Nhiệm vụ:
- Viết bộ Unit Test trong
tests/unit/leave-request.spec.tsphủ toàn bộ các kịch bản AC-1, AC-2, AC-3.- Triển khai Domain Service
LeaveRequestServiceđể vượt qua toàn bộ các test trên.- Không tự ý thêm trường hoặc thay đổi logic ngoài các AC đã định nghĩa.
Ngày 5: Deploy, nghiệm thu và vòng lặp phản hồi
- Chạy CI/CD, kiểm tra tỷ lệ 100% AC Test pass.
- Demo cho PO. Khi phát hiện quy tắc mới (ví dụ: không cho xin nghỉ trùng ngày lễ quốc gia), không sửa code vội; ghi nhận vào
BR-001 v2, cập nhật AC rồi mới cho AI tái sinh logic.
🛡️ Brownfield: 5 bước áp SDD vào Legacy Code
Làm việc với một codebase 5 năm tuổi, 300.000 dòng code, không tài liệu, người viết gốc đã nghỉ việc. Đừng dại dột chọn con đường “Big Bang Rewrite” (viết lại từ đầu) vì bạn sẽ rơi vào đầm lầy bỏ sót các rule ngầm mà hệ thống đang chạy.
%%{init: {"flowchart": {"wrappingWidth": 260}}}%%
flowchart TD
S1["🛑 <b>BƯỚC 1: ĐÓNG BĂNG VÙNG NÓNG</b><br/>Khoanh vùng module cần sửa, không lan man"]
S2["🔍 <b>BƯỚC 2: REVERSE-SPEC BẰNG AI</b><br/>Đọc schema & code cũ sinh bản thảo Spec"]
S3["🗣️ <b>BƯỚC 3: ĐỐI CHẤT NGHIỆP VỤ</b><br/>Ngồi với Ops/Finance xác nhận rule thật"]
S4["📸 <b>BƯỚC 4: GOLDEN MASTER TEST</b><br/>Chụp snapshot hành vi hiện tại làm lưới bảo vệ"]
S5["✂️ <b>BƯỚC 5: TÁCH HÀM & REFACTOR</b><br/>Strangler Fig: Chạy song song code mới/cũ"]
S1 --> S2 --> S3 --> S4 --> S5
Bước 1: Khoanh vùng “điểm nóng” (Freeze Hotspots)
Không cố đặc tả toàn bộ hệ thống cũ. Chỉ khoanh vùng module sắp sửa phải thêm tính năng hoặc sửa lỗi nghiêm trọng.
Bước 2: Dùng AI truy ngược đặc tả (Reverse-engineering Spec)
Cho AI đọc bảng database, code controller và service cũ để trích xuất Entity Model và danh sách Use Case tạm thời.
- Prompt mẫu:
Đọc file
legacy/BillingCalculator.javavà schema SQL đính kèm. Hãy trích xuất:
- Danh sách các khái niệm Entity chính và mối quan hệ giữa chúng.
- Liệt kê các Use Case nghiệp vụ ẩn bên trong hàm
calculate().- Các nhánh if-else đặc biệt (discount, thuế, phạt) và đặt câu hỏi nghi vấn về tính hợp lệ của chúng.
Bước 3: Đối chất với chuyên gia nghiệp vụ (Human Alignment)
Cầm bản thảo spec AI vừa sinh đi hỏi kế toán, vận hành: “Khoản giảm giá 10% này cho ai? Rule này còn dùng không?”. Loại bỏ code rác đã chết và bổ sung các rule bất thành văn vào Spec.
Bước 4: Khóa an toàn bằng Characterization Test (Golden Master)
Trước khi đụng vào code cũ, chạy 1.000 dữ liệu thực tế trong quá khứ qua hàm cũ và lưu lại output chính xác từng xu. Đây là tấm lưới bảo hiểm tối thượng: bất kỳ refactor nào làm lệch output Golden Master đều bị chặn lại.
Bước 5: Tách hàm theo mô hình Strangler Fig
Chia hàm 800 dòng thành các Use Case độc lập (UC-019-base-fee, UC-020-weekend-surcharge, UC-021-discount). Viết class mới theo chuẩn SDD, bọc qua Feature Flag chạy song song cả code cũ và code mới trong 2 tuần để đối chiếu trước khi ngắt hoàn toàn code cũ.
👥 Vận hành Team Spec-Driven hằng ngày
Phân công vai trò trong kỷ nguyên SDD
| Vai trò | Trách nhiệm chính trong SDD | Việc KHÔNG nên làm |
|---|---|---|
| Product Owner (PO / BA) | Viết BR, định nghĩa phạm vi, duyệt Use Case và AC trước khi dev code. | Đẩy user story 3 dòng cho dev rồi phó mặc cho AI đoán mò. |
| Tech Lead / Architect | Chuẩn hóa Entity Model, kiến trúc Port/Adapter, duyệt Traceability. | Bỏ mặc spec trôi dạt; sa đà vào gõ code thủ công thay vì dẫn dắt kiến trúc. |
| Developer | Cùng PO làm nét AC, điều phối AI sinh code & test khớp spec, refactor. | Cắm đầu vibe coding với AI mà không cập nhật lại spec khi đổi logic. |
| QA / Tester | Soi spec ngay từ Ngày 1: AC có mâu thuẫn không? Viết E2E test theo AC. | Ngồi chờ code xong ở cuối sprint mới nhảy vào test thủ công. |
| Engineering Manager | Theo dõi Spec Coverage, thời gian onboard và gỡ nghẽn quy trình. | Đếm số dòng code hay số commit để đánh giá năng suất. |
Cấu trúc Git Repository khuyến nghị (Mô hình Baseline & Changes)
Học tập mô hình hiện đại từ OpenSpec, tách biệt giữa trạng thái hiện tại (specs/) và các đề xuất thay đổi đang tiến hành (changes/):
my-project/
├── specs/ # Baseline: Hệ thống HIỆN TẠI đang chạy thế nào
│ ├── business-requirements/ # Danh mục BR-xxx
│ ├── use-cases/ # Danh mục UC-xxx kèm AC chi tiết
│ └── entities/ # Entity Model & Domain Invariants
├── changes/ # Đang thảo luận hoặc đang implement
│ ├── change-012-add-qr-payment/
│ │ ├── proposal.md # Đề xuất lý do & phương án
│ │ ├── delta-specs.md # Điểm khác biệt so với baseline
│ │ └── tasks.md # Danh sách đầu việc cho AI và Dev
│ └── archive/ # Nơi lưu lại các change đã hoàn thành
└── src/ # Mã nguồn triển khai
Quy trình Code Review 2 pha (Two-Phase Review)
PHA 1: SPEC PR (Duyệt ý định) PHA 2: CODE PR (Duyệt hiện thực)
┌───────────────────────────────┐ ┌───────────────────────────────┐
│ • Chỉ sửa các file trong │ │ • Chứa code và test suite │
│ specs/ hoặc changes/ │ merge │ • Reviewer: Tech Lead & Devs │
│ • Reviewer: PO/BA & Tech Lead │ ───────► │ • Tiêu chí: Mọi AC đều có test│
│ • Tiêu chí: Nghiệp vụ đúng, │ │ chặn; code sạch, đúng port; │
│ AC rõ ràng, không mơ hồ │ │ 100% trace về Spec ID │
└───────────────────────────────┘ └───────────────────────────────┘
4 Chỉ số sức khỏe đo lường hiệu quả SDD
- Spec Coverage: Tỷ lệ % các Use Case trên production có tài liệu đặc tả và AC hợp lệ (Mục tiêu: 100% cho Greenfield, >70% cho vùng nóng Brownfield).
- AC Test Ratio: Tỷ lệ % các Acceptance Criteria được tự động hóa bằng test suite (Mục tiêu: >90%).
- Trace Ratio: Tỷ lệ commit và PR có gắn mã ID hợp lệ (
BR-xxx,UC-xxx). - Regeneration Success Rate: Khả năng đưa spec cho AI sinh lại toàn bộ handler/service mà test vẫn pass (Đây là bài kiểm tra đỉnh cao chứng minh tính độc lập của đặc tả).
Lộ trình áp dụng 30 - 60 - 90 ngày
- 30 ngày đầu (Thử nghiệm vi mô): Chọn 1 use case nhỏ nhưng có thật, 1 dev tiên phong và 1 PO cởi mở. Thiết lập folder
/specs, áp dụng format Given-When-Then và tập prompt AI sinh test trước khi sinh code. - 60 ngày tiếp theo (Mở rộng module): Chuẩn hóa quy trình Spec PR trước Code PR. Đưa “Spec updated” vào Definition of Done của cả team. Bắt đầu đo AC Test Ratio.
- 90 ngày (Chuẩn hóa toàn diện): Áp dụng cấu trúc
specs/vàchanges/. Thực hiện reverse-spec cho các vùng nóng của legacy code khi cần sửa tính năng.
🛑 Khi nào KHÔNG nên dùng SDD?
SDD là công cụ mạnh mẽ nhưng không phải cây đũa thần cho mọi bài toán:
- Prototype vứt đi (Throwaway POC): Ứng dụng demo cho nhà đầu tư vào thứ Hai, dùng một lần rồi bỏ; hãy thoải mái vibe coding với AI để đạt tốc độ tối đa.
- Spike nghiên cứu công nghệ: Cần 2 ngày để thử nghiệm xem thư viện vector database nào nhanh hơn; không cần viết BR hay UC.
- Script tự động hóa cục bộ: Shell script cá nhân, migration script chạy 1 lần.
📋 Biểu mẫu thực chiến (Templates)
Mẫu Use Case chuẩn: specs/use-cases/UC-XXX-Name.md
# UC-XXX: <Tên Use Case bằng ngôn ngữ nghiệp vụ>
## Metadata
- **ID:** UC-XXX
- **Bounded Context:** <Core / Billing / Identity / ...>
- **Thuộc BR:** BR-YYY
- **Status:** draft | reviewed | implemented | deprecated
- **Owner:** <Tên PO và Dev phụ trách>
- **Last Updated:** YYYY-MM-DD
## Actor
<Ai kích hoạt: Khách hàng, Quản trị viên, Hệ thống ngoài, Cron Job>
## Trigger
<Sự kiện bắt đầu: Bấm nút thanh toán, Webhook đến, Đúng 00:00 mỗi ngày>
## Preconditions
- <Điều kiện bắt đầu: Người dùng đã đăng nhập, Giỏ hàng > 0 đ>
## Main Flow
1. Khách hàng chọn phương thức thanh toán QR.
2. Hệ thống kiểm tra tính hợp lệ và tạo QRSession mới.
3. Hệ thống hiển thị mã QR kèm đồng hồ đếm ngược 15 phút.
## Alternate & Exception Flows
- **2a. Cổng thanh toán báo lỗi:** Hệ thống thông báo thử lại và ghi log incident.
- **3a. Hết thời gian đếm ngược:** QRSession hủy, chuyển về trạng thái expired.
## Acceptance Criteria
### AC-1: <Tên tiêu chí 1>
- **Given:** <Bối cảnh ban đầu>
- **When:** <Hành động kích hoạt>
- **Then:** <Kết quả mong đợi trên hệ thống>
- **And:** <Hệ quả kèm theo: email, event, log>🎯 Tóm tắt bỏ túi (Take away)
| Trọng tâm cốt lõi | Nguyên lý sống còn trong SDD | Hành động thực chiến ngay ngày mai |
|---|---|---|
| Tư duy nền tảng | AI viết code rất nhanh nhưng không có ngữ cảnh; Spec là giao diện làm việc bền vững giữa người và AI. | Ngừng prompt tùy hứng; viết tóm tắt Use Case và AC trước khi mở chat với AI. |
| 4 Tầng yêu cầu | Tách bạch: BR (Tại sao) ➔ UC (Ai làm gì) ➔ Entity (Khái niệm nào) ➔ AC (Làm sao biết đúng). | Chuẩn hóa format AC theo Given-When-Then để làm đầu vào sinh test tự động. |
| Kiến trúc phù hợp | Hexagonal Architecture cô lập Domain Core khỏi Adapter; AI làm rất tốt ở tầng Adapter. | Giữ logic nghiệp vụ thuần túy không dính dáng tới framework hay SQL query. |
| Chống nợ Brownfield | Không Big Bang Rewrite; dùng AI reverse-spec và dựng Golden Master test làm lưới an toàn. | Khoanh vùng module cần sửa, bọc test snapshot trước khi cho AI refactor. |
| Vận hành team | Tách riêng Spec PR và Code PR; spec đi trước, code bám đuôi; đo lường bằng AC Coverage. | Đưa mục “Spec updated & AC covered” vào Definition of Done của sprint. |
Tương lai của kỹ sư phần mềm không nằm ở việc gõ phím nhanh hơn AI, mà nằm ở năng lực tư duy kiến trúc, thấu hiểu bài toán nghiệp vụ và khả năng thiết kế những bản đặc tả chính xác đến mức bất kỳ cỗ máy nào cũng có thể hiện thực hóa an toàn.