Đừng chọn nghề AI bằng bảng xếp hạng FOMO

Đừng chọn nghề AI bằng bảng xếp hạng FOMO

AI đang tạo ra người thắng rất lớn, nhưng team đi làm thật cần một khung quyết định tỉnh hơn: thử nhỏ, đo đúng, và biết khi nào dừng.

Có một kiểu họp mình thấy ngày càng quen: 9 giờ sáng, cà phê còn chưa tan đá, một bạn trong team đã thả vào Slack câu “AI sắp thay hết dev chưa?”, kèm một link về startup AI tăng giá, layoffs, hoặc ai đó ở San Francisco vừa giàu lên mức nghỉ hưu.

Không khí sau đó thường chia làm hai phe. Một phe muốn nhảy ngay sang “làm AI”. Phe còn lại âm thầm mở LinkedIn, sửa headline thành “AI-powered something”. Cả hai đều có lý do để lo. Nhưng nếu bạn là người đang phải triển khai AI trong team, câu hỏi quan trọng hơn không phải là “AI đang hot cỡ nào?” mà là: “Mình nên đặt cược kỹ năng, dự án, và thời gian team vào đâu để không bị cuốn theo tiếng ồn?”

Tuần này, các tín hiệu nhìn hơi trái chiều: một nhóm nhỏ trong làn sóng AI có thể đã đạt mức tài sản cực lớn; Robinhood muốn mở thêm sản phẩm để nhà đầu tư phổ thông tiếp cận venture; Cloudflare nói AI khiến 1.100 vị trí trở nên lỗi thời trong lúc doanh thu đạt kỷ lục; Intel tăng giá cổ phiếu mạnh dù phần thực thi vẫn còn nhiều câu hỏi; còn trong coding, ranh giới giữa vibe coding và agentic engineering đang mờ đi.

Bài này không bàn chuyện ai giàu hơn ai. Mình muốn đưa bạn một memo ra quyết định: đừng chọn hướng AI theo bảng xếp hạng người thắng; hãy chọn theo khả năng kiểm soát failure mode của chính bạn.

Sơ đồ minh họa cho bài Đừng chọn nghề AI bằng bảng xếp hạng FOMO

Sơ đồ tóm tắt ý chính của bài viết.

Bài toán thật: AI không chỉ là cơ hội, nó là bộ lọc

Làn sóng AI hiện tại hơi giống một màn boss fight trong game: cùng một con boss, nhưng người có gear xịn, party tốt, và checkpoint gần sẽ thấy “khó nhưng vui”; người khác thì chết đi sống lại ở cùng một đoạn map.

Trong công việc, “gear” ở đây không chỉ là biết prompt hay dùng tool mới. Nó gồm:

Hiểu lầm phổ biến là: AI thưởng cho người học tool nhanh nhất. Thực tế phũ hơn: AI thường thưởng cho người đứng gần điểm nghẽn thật nhất.

Nếu bạn chỉ biết “dùng AI cho nhanh”, bạn dễ bị thay bởi một người khác cũng dùng AI cho nhanh. Nhưng nếu bạn biết biến một quy trình mơ hồ thành hệ thống có kiểm soát — có input, output, tiêu chí pass/fail, guardrail — bạn đang ở vị trí khác hẳn.

Guardrail là hàng rào kiểm soát để hệ thống không chạy quá phạm vi an toàn. Trong đời thường, nó giống việc bạn cho người mới phụ trách trả lời khách hàng, nhưng bắt buộc phải có danh sách câu không được nói, trường hợp phải chuyển lên senior, và log để xem lại.

Ba lựa chọn trước mặt team practitioner

Nếu tuần này bạn đang tự hỏi “nên làm gì với AI?”, mình thấy có ba hướng phổ biến.

| Lựa chọn | Hợp với ai | Điểm mạnh | Rủi ro |
|---|---|---|---|
| Chạy theo tool mới | Cá nhân muốn tăng tốc việc hằng ngày | Học nhanh, thấy kết quả ngay | Dễ nhầm demo đẹp với năng lực bền |
| Chuyển hẳn sang build sản phẩm AI | Founder, product team có bài toán rõ | Có upside lớn nếu đúng timing | Đốt thời gian vào thị trường chưa chắc cần |
| Nâng cấp workflow hiện tại bằng AI | Team đang có nghiệp vụ, dữ liệu, khách hàng | Dễ đo, dễ kiểm soát, ít ảo tưởng hơn | Không hào nhoáng, cần kỷ luật vận hành |

Nếu là team Việt Nam 5-20 người, mình nghiêng mạnh về lựa chọn thứ ba. Không phải vì nó “an toàn” theo kiểu đứng yên, mà vì nó cho bạn quyền học AI từ dữ liệu thật của mình.

Ví dụ cụ thể: team support đang mất nhiều thời gian phân loại ticket. Đừng bắt đầu bằng “làm chatbot thay nhân viên”. Hãy bắt đầu bằng một lớp AI đề xuất nhãn: billing, bug, onboarding, complaint. Người thật vẫn duyệt. Sau một tuần, bạn đo xem AI gợi ý đúng đến đâu, sai kiểu gì, và có giúp giảm thời gian xử lý không.

Đây là khác biệt giữa vibe coding và agentic engineering. Vibe coding là để AI tạo thứ gì đó rồi bạn xem chạy được không. Agentic engineering là dùng AI như một tác nhân trong quy trình kỹ thuật có kiểm soát: có test, có review, có giới hạn quyền, có cách rollback khi hỏng. Trong công việc thật, đoạn sau mới đáng đưa vào production.

Khung quyết định: gần tiền, gần lỗi, gần quyền sửa

Mình đề xuất một khung 3 câu hỏi trước khi team chọn bất kỳ sáng kiến AI nào:

1. Việc này có gần tiền không?

“Gần tiền” không nhất thiết là trực tiếp tạo doanh thu. Nó có thể là giảm churn, tăng tốc sales response, rút ngắn thời gian xử lý đơn, hoặc giảm lỗi khiến khách hàng rời đi.

Nếu một use case AI nghe vui nhưng không ai biết nó ảnh hưởng metric nào, hãy để nó ở backlog. AI nội bộ rất dễ thành khu vui chơi: ai cũng demo được, nhưng hết quý không ai chứng minh được tác động.

2. Việc này có gần lỗi không?

AI nên được đặt ở nơi team nhìn thấy lỗi nhanh. Nếu sai mà ba tháng sau mới phát hiện, đó là vùng nguy hiểm.

Failure mode là kiểu hỏng lặp lại của hệ thống. Ví dụ: AI phân loại nhầm ticket khẩn cấp thành bình thường; AI tóm tắt thiếu điều khoản quan trọng trong hợp đồng; AI viết code chạy được nhưng mở lỗ hổng bảo mật.

Một use case tốt cho giai đoạn đầu là nơi lỗi có thể bị bắt bởi người thật, test tự động, hoặc rule đơn giản.

3. Team có quyền sửa không?

Đây là câu hỏi nhiều người bỏ qua. Nếu bạn chỉ “gắn AI” vào một workflow do phòng khác sở hữu, không có quyền đổi process, không có dữ liệu log, không có người duyệt output, bạn sẽ mắc kẹt.

AI trong team không nên là skin mới phủ lên quy trình cũ. Nó cần quyền thay đổi cách nhận việc, cách kiểm tra, cách bàn giao.

Nói thẳng ra thì: nếu bạn không kiểm soát được checkpoint, đừng lao vào đánh boss.

Việc thử trong một buổi: chọn một tác vụ có đường lui

Bạn không cần lập “AI transformation roadmap” dài 40 trang. Một buổi chiều đủ để bắt đầu bằng bài test nhỏ.

Chọn một tác vụ có đủ 5 điều kiện sau:

Hình dung thế này: team product mỗi tuần đọc feedback khách hàng từ nhiều kênh. Thay vì yêu cầu AI “phân tích insight chiến lược”, hãy giao việc nhỏ hơn:

Nhiệm vụ: phân loại 50 feedback gần nhất thành 5 nhóm.
Output cần có:
- Nhóm vấn đề
- Mức độ khẩn cấp: thấp / vừa / cao
- Một câu trích dẫn đại diện
- Trường hợp không chắc thì ghi: cần người duyệt
Không được tự suy đoán tính năng chưa được nhắc tới.

Sau đó, lấy 20 kết quả ra review thủ công. Đừng chỉ hỏi “đúng không?”. Hỏi kỹ hơn:

Nếu sau một buổi bạn không thấy đường đo, đừng scale. Coi như vừa respawn đúng lúc, chưa mất cả chiến dịch.

Tiêu chí dừng: thứ cứu team khỏi FOMO

Trong cơn sốt AI, tiêu chí bắt đầu thường rất nhiều, tiêu chí dừng thì ít. Đây là lỗi vận hành.

Trước khi mở rộng một workflow AI, hãy viết sẵn ba điều kiện dừng:

  1. Dừng nếu không giảm tải rõ rệt cho người duyệt. Nếu AI tạo thêm việc kiểm tra, nó chưa phải automation, nó là debt mới.
  2. Dừng nếu lỗi tập trung ở vùng rủi ro cao. Ví dụ sai ở ticket billing quan trọng, dữ liệu cá nhân, hoặc quyết định ảnh hưởng khách hàng.
  3. Dừng nếu không ai sở hữu chất lượng output. AI không có owner là một cái máy phát sinh tranh cãi.

Điểm này liên quan trực tiếp đến chuyện layoffs và “AI làm vị trí trở nên lỗi thời”. Với team đang làm thật, phản ứng đúng không phải là hoảng rồi nhảy vào mọi tool. Phản ứng đúng là tách việc của mình thành hai lớp:

Bạn muốn dịch chuyển công sức sang lớp thứ hai càng sớm càng tốt.

Khuyến nghị của mình: farm exp ở workflow, không farm tin nóng

Nếu là mình, tuần này mình sẽ không dùng tin AI để quyết định “nghề nào sẽ giàu”. Mình sẽ dùng nó như tín hiệu rằng: khoảng cách giữa người biết vận hành AI và người chỉ dùng AI cho vui đang rộng ra.

Kế hoạch thực tế:

Điều bạn nên nghĩ khác sau bài này: AI career không phải cuộc thi chọn đúng logo công ty hay tool đang hot; nó là cuộc chơi tích lũy quyền kiểm soát quy trình. Người có quyền đo, sửa, và chịu trách nhiệm cho output sẽ bền hơn người chỉ đứng ngoài đoán sóng.

Còn nếu Slack sáng mai lại có link “AI tạo thêm triệu phú mới”, cứ đọc cho vui. Nhưng đừng để timeline của người khác cầm tay lái career của mình — game này không có nút pause ngoài đời.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo