Bạn Không Cần AI Viết Code Nhanh Hơn — Bạn Cần Nó Không Phá Dự Án

AI viết code rất nhanh. Nhưng một dòng code sai có thể kéo theo cả tuần sửa lỗi.

Yêu cầu mơ hồ
      ↓
AI đoán business rule
      ↓
Code chạy được
      ↓
Flow cũ bị phá
      ↓
Developer trả giá

AI không nên chỉ là autocomplete cao cấp.

AI nên làm việc như một kỹ sư trong team: hiểu mục tiêu, biết giới hạn, nhìn thấy rủi ro và chứng minh kết quả.

🧭 1. Đừng đưa task, hãy đưa một “hợp đồng”

Một câu như:

“Hãy implement task này.”

chưa đủ để AI làm đúng.

Trước khi code, task cần trả lời:

Business goal   → Vì sao cần thay đổi?
In scope        → Được sửa những gì?
Out of scope    → Không được đụng vào gì?
Expected        → Hành vi nào phải xảy ra?
Acceptance      → Dựa vào đâu để biết đã đúng?
Risk            → Flow cũ nào có thể bị ảnh hưởng?

Nếu acceptance criteria chưa rõ, việc đầu tiên của AI phải là hỏi và phát hiện phần thiếu — không phải tự đoán.

Không có tiêu chí đúng thì không thể chứng minh code đúng.

🗺️ 2. Trước khi sửa code, hãy vẽ Impact Map

Một thay đổi nhỏ trên UI có thể đi xuyên qua nhiều tầng:

Route
  ↓
Page / Component
  ↓
Helper / Store
  ↓
Service
  ↓
API
  ↓
Flow khác dùng chung logic

AI cần tìm trước:

• file xử lý route và component chính;
• helper, store hoặc service dùng chung;
• pattern xử lý warning/error;
• test hiện có;
• các consumer có thể bị regression.

Kết quả không phải là một danh sách file, mà là bản đồ ảnh hưởng:

Task: thay đổi channel selection
          │
          ├─ channel helper
          │      └─ business rule chọn channel
          │
          ├─ Export A
          │      └─ dùng channel đã chọn
          │
          ├─ Export B
          │      └─ dùng chung helper
          │
          └─ tests
                 └─ kiểm tra behavior cũ và mới

Không có Impact Map, AI rất dễ sửa đúng một component nhưng bỏ sót ba flow đang dùng cùng logic.

🧱 3. Chia thay đổi thành những lát nhỏ

AI thường muốn “tiện tay” refactor thêm: đổi tên, tách component, thay pattern error và dọn cả module.

Đó là cách một task nhỏ biến thành một PR không thể review.

Ghi nhận behavior cũ
        ↓
Viết hoặc cập nhật test
        ↓
Sửa một rule / helper
        ↓
Kiểm tra consumer thứ nhất
        ↓
Kiểm tra consumer thứ hai
        ↓
Chạy regression

Mỗi lát thay đổi phải trả lời được:

1. Nó đổi behavior nào?
2. Kiểm tra bằng gì?
3. Có thể rollback riêng không?

Với code legacy chưa có test, hãy tạo characterization test trước. Test này ghi lại behavior hiện tại để biết thay đổi mới có phá nó hay không; nó không mặc định rằng behavior cũ là tối ưu.

AI được phép đề xuất mở rộng. Kỹ sư quyết định phạm vi.

🔍 4. Đừng báo “xong” khi chưa có bằng chứng

“Chạy được trên máy local” chưa phải là bằng chứng đủ mạnh.

Code change
    │
    ├─ Static check / lint
    ├─ Unit test cho business rule
    ├─ Flow test cho consumer
    ├─ Regression test
    └─ Build giống CI

Một báo cáo tốt phải nói rõ:

• đã đổi gì;
• flow nào bị ảnh hưởng;
• flow nào cố ý không đổi;
• command/test nào đã pass;
• rủi ro nào vẫn còn.

AI có thể giúp tạo code, test và báo cáo. Người chịu trách nhiệm cuối cùng vẫn là kỹ sư review thay đổi.

🎯 5. Tóm tắt bỏ túi (Take away)

Nếu bạn quên hết những gì vừa đọc, chỉ cần nhớ bảng này là đủ: