Việc nào AI làm tốt, việc nào cần chuyên gia

Sáu ô ở lớp 5 của sơ đồ, mổ từng ô: vì sao AI mạnh ở front-end và test, vì sao nó hụt ở UX, logic nghiệp vụ và bảo mật — và bạn làm gì ở phần hụt đó.

Lớp 5 trong sơ đồ Vibe Stack chia việc thành hai màu. Đây không phải cách chia theo cảm tính — nó theo một quy luật duy nhất:

AI làm tốt những việc có tiêu chí đúng/sai nằm ngay trong mã. Nó hụt ở những việc mà tiêu chí nằm ngoài mã — trong đầu người dùng, trong nghiệp vụ, trong tiền bạc.

Nút bấm sai màu thì nhìn là thấy, và AI cũng "thấy" được qua mã. Một báo cáo tính sai 2% doanh thu thì chạy vẫn mượt, không ai thấy, kể cả AI.

Ô xanh 1 — Code giao diện (front-end) AI làm tốt

Vì sao mạnh: dữ liệu huấn luyện khổng lồ, mẫu lặp lại nhiều, và vòng phản hồi cực ngắn — bạn mở trang, sai là thấy ngay trong 3 giây.

Giao thẳng được: dựng bố cục, chuyển giao diện sang bản mobile, làm bảng có sắp xếp và lọc, làm form, hiệu ứng, biểu đồ, trạng thái rỗng/đang tải.

Vẫn phải kiểm, 4 chỗ:

1. Bấm thật trên điện thoại thật. AI không bấm được. Nút nằm dưới bàn phím ảo, vùng chạm nhỏ hơn ngón tay — nó không thấy.
2. Tương phản chữ. AI hay chọn chữ xám nhạt trên nền trắng, trông sang trên màn hình đẹp, không đọc nổi ngoài nắng.
3. Chữ tiếng Việt bị bẻ dòng. Nhãn nút tiếng Việt dài hơn tiếng Anh ~30%. "Xuất báo cáo tháng" tràn ra chỗ mà "Export" vừa khít.
4. Nhất quán. Lượt này nó bo góc 8px, lượt sau 12px. Phải ra đề "dùng đúng màu và cỡ chữ đang có".

Ô xanh 2 — Viết và chạy test AI làm tốt

Vì sao mạnh: test là việc lặp, có tiêu chí rành mạch, và tốn công gõ — đúng ba thứ AI giỏi nhất. Đây cũng là ô bị bỏ phí nhiều nhất: người ta nhờ AI viết tính năng rồi tự kiểm bằng tay.

Việc giao được ngay:

Viết một script Node kiểm app đang chạy ở <url>, không cần thư viện ngoài:
1. GET /api/don-hang → mã 200, trả về mảng, mỗi phần tử có đủ
   id, ma_don, ten_khach, tong_tien
2. POST /api/don-hang thiếu trường bắt buộc → PHẢI trả 400, không phải 500
3. POST hai lần cùng một ma_don → lần hai phải bị từ chối
4. GET /api/don-hang không có cookie phiên → phải trả 401

In ra bảng: tên phép thử | mong đợi | thực tế | ĐẠT/HỎNG.
Thoát với mã khác 0 nếu có phép hỏng, để CI chặn được.

Chạy script đó trong GitHub Actions là bạn có lưới an toàn tự động — thứ mà một người làm một mình rất khó tự dựng bằng tay.

Giới hạn: AI viết test theo mã đang có, nên nó có xu hướng test rằng mã làm đúng cái nó đang làm — kể cả khi cái đó sai nghiệp vụ. Phép thử số 3 và 4 ở trên là loại AI thường không tự nghĩ ra; bạn phải nêu.

Ô xanh 3 — Đọc log, tìm và sửa lỗi (debug) AI làm tốt

Vì sao mạnh: gỡ lỗi là việc lần theo bằng chứng — có thông báo lỗi, có số dòng, có log. Đó đúng là thứ AI làm nhanh hơn người, vì nó đọc 2.000 dòng log trong hai giây và không bỏ sót.

Giao thẳng được: đọc log lỗi và chỉ ra nguyên nhân gốc, lần theo chuỗi gọi hàm, tìm chỗ sai cú pháp, giải thích một thông báo lỗi khó hiểu, dò xem một biến bị gán sai ở đâu.

Ba ràng buộc khi giao:

1. Đưa bằng chứng, đừng đưa cảm nhận. Chép nguyên văn thông báo lỗi kèm số dòng. "Web tôi bị lỗi" thì nó đoán; Cannot read properties of null at index.html:214 thì nó biết.
2. Tách điều tra khỏi sửa chữa. "Chỉ đọc và chạy lệnh đọc. Nói nguyên nhân gốc. Chưa được sửa gì." Bạn đọc kết luận, thấy đúng, rồi mới cho sửa. Thiếu bước này, một lần sửa mò giữa sự cố có thể biến một lỗi thành hai.
3. Ba lượt không xong thì dừng. Vấn đề không nằm ở chỗ bạn nghĩ. /clear, rồi đặt câu hỏi nhỏ hơn một bậc.

Giới hạn: AI giỏi tìm lỗi làm app hỏng thấy được. Nó rất kém với lỗi im lặng — tính sai 2% tiền, lệch múi giờ, hiểu sai nghiệp vụ — vì không có thông báo lỗi nào để lần theo. Loại đó rơi xuống ô vàng số 2.

Ô vàng 1 — UX/UI: thiết kế trải nghiệm Cần chuyên gia

Phân biệt cho rõ: code giao diện (xanh) là dựng cái đã quyết; thiết kế trải nghiệm (vàng) là quyết dựng cái gì.

AI không biết — và không thể biết từ mã — những thứ này:

• Nhân viên của bạn nhập liệu khi đang đứng ngoài đường, một tay cầm hàng. Nghĩa là form 12 ô là hỏng, dù nó đẹp.
• Chị kế toán chỉ tin con số khi xuất được ra Excel. Biểu đồ đẹp mấy cũng không thay được nút xuất file.
• Chủ doanh nghiệp mở app mỗi ngày một lần, 30 giây, để xem đúng một con số. Trang chủ phải là con số đó, không phải menu 8 mục.

Ba điều trên không nằm trong bất kỳ file nào. Chúng nằm ở chỗ bạn ngồi cạnh người dùng và nhìn họ làm.

Việc của bạn ở ô này — làm được ngay, không cần học thiết kế:

1. Xem người thật dùng, 15 phút, không nói gì. Đừng hướng dẫn, đừng giải thích. Chỗ họ ngập ngừng là chỗ hỏng.
2. Đếm số lần chạm để làm xong việc chính. Mục tiêu: giảm được một chạm là thắng lớn.
3. Hỏi "việc này anh/chị đang làm thế nào?" trước khi thiết kế. Thường họ đã có một cuốn sổ hoặc một file Excel — bắt chước thứ tự trong đó, đừng phát minh lại.

Rồi đưa kết quả cho AI dưới dạng ràng buộc: "Màn hình nhập đơn tối đa 4 ô, nhập được bằng một tay, ô Số lượng là nút +/− chứ không phải bàn phím."

Ô vàng 2 — Logic nghiệp vụ và dữ liệu (API) Cần chuyên gia

Đây là ô nguy hiểm nhất, vì sai ở đây không hiện ra.

Bốn nhóm AI hay sai, và cả bốn đều im lặng:

Cả bốn đều chạy mượt và vượt qua mọi bài test mà AI tự nghĩ ra.

Việc của bạn ở ô này:

1. Đối chiếu tay với dữ liệu thật, ít nhất một lần, cho mọi tính năng dính tiền hoặc ngày. Lấy 10 bản ghi thật, tính bằng máy tính cầm tay, so với app. Không có cách nào thay được việc này.
2. Luôn hỏi ngược lại AI ba câu: "Nếu dữ liệu rỗng thì sao? Nếu người dùng bấm hai lần thì sao? Nếu hai người làm cùng lúc thì sao?"
3. Quyền phải chặn ở máy chủ. Luật một câu: nút bị ẩn không phải là phân quyền.

Ô vàng 3 — Review và bảo mật Cần chuyên gia

AI review mã của người khác khá tốt. Review mã của chính nó vừa viết thì kém hẳn — nó đã "tin" vào cách hiểu của mình từ lượt trước.

Hai mẹo lấy lại phần lớn giá trị:

1. Tách phiên. Gõ /clear, rồi mở phiên mới và đưa mã vào như mã lạ: "Đây là mã của một người khác. Tìm chỗ sai." Chất lượng khác hẳn.

2. Review theo danh sách cố định, không hỏi chung chung:

Đọc thay đổi này và chỉ trả lời đúng 6 câu, mỗi câu một dòng:
1. Có chỗ nào ghi đè hoặc xóa mất dữ liệu cũ không?
2. Có truy vấn SQL nào nối chuỗi thay vì dùng .bind() không?
3. Có đường API nào thiếu kiểm quyền ở phía máy chủ không?
4. Có khóa bí mật, mật khẩu, số điện thoại thật nào trong mã không?
5. Có truy vấn danh sách nào thiếu LIMIT không?
6. Có thay đổi hành vi mặc định mà tôi không yêu cầu không?

Không có thì trả lời "không". Đừng thêm góp ý ngoài 6 câu này.

Danh sách đóng chặn được bệnh "góp ý trang trí", và nó bắt đúng những thứ đắt tiền.

Giới hạn cứng của AI — hai điều không thương lượng

Sơ đồ ghi ở góc: "Không giữ khóa · Không tự deploy." Hai câu này là ranh giới, không phải lời khuyên.

1. AI không giữ khóa. Khóa API, mật khẩu, token nằm trong Secrets ở lớp 6, không nằm trong mã mà AI đọc. Đừng dán khóa vào chat để "nó cấu hình cho nhanh". Bí mật và token.

2. AI không tự đưa bản mới lên cho người dùng. Mọi thay đổi đi qua cổng ở lớp 4: Pull Request → test → link preview → bạn bấm duyệt. Việc AI chạy được lệnh deploy không có nghĩa là nó được phép quyết định deploy. Khoảng cách giữa hai điều đó chính là nghề của bạn.

Có một lý do thực dụng, ngoài chuyện an toàn: khi app hỏng, người gọi điện cho khách là bạn. Trách nhiệm không ủy quyền được, nên quyền quyết định cũng không nên ủy quyền.

Đọc project này và chấm theo 6 ô, mỗi ô một dòng, mỗi dòng
nói rõ BẰNG CHỨNG trong mã:

1 Front-end — giao diện có nhất quán màu/cỡ chữ không?
2 Test/QA — có file test nào không? CI có chạy nó không?
3 UX — màn hình chính cần mấy thao tác để làm xong việc chính?
4 API/nghiệp vụ — tiền lưu kiểu gì? ngày giờ xử lý múi giờ thế nào?
   có đường API nào thiếu kiểm quyền phía máy chủ không?
5 Review/bảo mật — có SQL nối chuỗi, có khóa trong mã, có
   truy vấn thiếu LIMIT không?
6 Debug — có chỗ nào nuốt lỗi (catch rỗng, catch không ghi log)
   khiến sau này không lần ra nguyên nhân không?

Chỉ nêu những gì đọc được trong mã. Không đoán, không khen.