Có một khảo sát nội bộ mình đọc được cuối 2025: hơn 60% dev junior-mid nói họ lo AI sẽ thay thế công việc của mình trong 2-3 năm tới. Nhưng ít ai hỏi đúng câu hỏi. Câu hỏi đúng không phải “AI có viết code giỏi hơn mình không” — rõ ràng là có, ở rất nhiều task. Câu hỏi đúng là: “phần nào trong công việc của mình AI không làm được, và mình có đang đầu tư vào đúng phần đó không”.
Đây là bài cuối trong series 3 bài về system design mindset. Bài 1 nói về định nghĩa và 3 trụ cột. Bài 2 nói cách áp dụng vào công việc hằng ngày. Bài này trả lời câu hỏi lớn nhất: vì sao mindset này — không phải tốc độ gõ code — mới là thứ quyết định bạn có bị thay thế hay không.
AI giỏi trả lời, dở đặt câu hỏi đúng
Bản chất của các mô hình AI hiện tại — kể cả những mô hình mạnh nhất — là giỏi sinh ra giải pháp cho một câu hỏi đã được đóng khung sẵn. Cho nó một spec rõ ràng, nó viết code nhanh và ít lỗi hơn phần lớn dev. Nhưng nó không đứng trong context thật của bạn: không biết team bạn có 2 người hay 20 người, không biết deadline tuần sau có áp lực gì từ phía kinh doanh, không biết lần trước feature tương tự đã fail vì lý do gì.
System design mindset về bản chất là khả năng đóng khung câu hỏi đúng, trước khi cần câu trả lời. Đó là phần AI yếu nhất — không phải vì nó “không đủ thông minh”, mà vì đóng khung câu hỏi đòi hỏi ngữ cảnh sống, thứ chỉ có người trong cuộc mới có đủ.
AI trả lời tốt câu hỏi bạn đưa ra. Giá trị của bạn nằm ở việc đưa ra câu hỏi nào.
3 lý do cụ thể mindset này là lợi thế cạnh tranh thật, không phải lý thuyết suông
1. Trade-off judgment cần trách nhiệm, mà trách nhiệm thì không thể outsource cho một API
Khi một quyết định kiến trúc sai, hậu quả rơi vào người ký tên chấp nhận nó — không phải vào công cụ đề xuất nó. Doanh nghiệp trả lương cho người chịu trách nhiệm về quyết định, không chỉ cho người gõ ra dòng code cuối cùng. Đây là lý do vì sao vai trò Tech Lead, Staff Engineer không biến mất dù AI coding mạnh lên — vì bản chất công việc đó chưa bao giờ là gõ code nhanh nhất.
2. Context sống là thứ AI luôn thiếu, dù dữ liệu training có lớn cỡ nào
Bạn biết vì sao lần trước team drop tính năng X giữa chừng. Bạn biết partner bên thứ ba nào hay đổi API không báo trước. Bạn biết user thật của mình bấm nút “quên mật khẩu” nhiều gấp 3 lần so với số liệu benchmark ngành. Loại context này không nằm trong bất kỳ training data nào — nó nằm trong lịch sử làm việc thật của bạn với hệ thống thật. Càng tích lũy lâu, khoảng cách này càng khó thu hẹp bằng prompt.
3. Người có mindset hệ thống dùng AI hiệu quả hơn gấp nhiều lần — tạo ra vòng lặp lợi thế kép
Đây là điểm ít người nói: không phải “system thinker” và “người dùng AI giỏi” là hai nhóm tách biệt. Người có mindset hệ thống biết đưa đúng constraint vào prompt, biết chỗ nào nên tin AI và chỗ nào phải tự kiểm tra kỹ, biết cách chia một bài toán lớn thành từng phần nhỏ để AI xử lý từng phần chính xác hơn. Nói cách khác: AI không thay thế người có mindset này — nó khuếch đại họ lên. Còn với người không có mindset, AI chỉ giúp họ tạo ra sai lầm nhanh hơn và ở quy mô lớn hơn.
Nói thẳng: mindset không phải lá chắn tuyệt đối
Cần thẳng thắn ở đây: system design mindset không phải bùa hộ mệnh. Nếu ngành co lại vì lý do kinh tế vĩ mô, nếu công ty cắt giảm vì lý do không liên quan gì đến năng lực cá nhân, không có mindset nào cứu được vị trí đó. Điều mindset này làm được là tăng xác suất bạn là người được giữ lại trong nhóm còn sót, và tăng tốc độ bạn tìm được vị trí tương đương nếu phải chuyển. Đó là lợi thế xác suất, không phải sự đảm bảo.
Cách xây dựng mindset này theo thời gian, không phải sau một khóa học
Mindset không hình thành qua đọc lý thuyết — nó hình thành qua lặp lại chu trình dự đoán → quan sát thực tế → điều chỉnh. Vài cách thực hành cụ thể:
- Sau mỗi lần hệ thống lỗi, tự viết post-mortem ngắn 5 dòng: nguyên nhân gốc là gì, mình đã dự đoán được không, lần sau nhận biết dấu hiệu này ở đâu
- Chủ động xin tham gia design review, kể cả khi không phải người quyết định cuối — mục tiêu là quan sát cách người khác đặt câu hỏi
- Với mỗi tính năng đã build 3-6 tháng trước, quay lại tự hỏi: giả định ban đầu của mình đúng bao nhiêu phần trăm
- Đọc post-mortem của các công ty lớn khi họ công bố sự cố (thường có trên blog kỹ thuật) — đây là kho case study miễn phí, thực tế hơn bất kỳ khóa học nào
Self-check: bạn đang ở đâu trên đường cong này
- Bạn có thể giải thích trade-off của quyết định kỹ thuật gần nhất bằng 2 câu, không cần mở code lên xem lại không?
- Lần cuối feature bạn build bị lỗi, bạn có dự đoán được nguyên nhân trước khi debug không?
- Bạn có đang dùng AI để tăng tốc phần “viết”, trong khi vẫn tự giữ phần “quyết định” không?
- Khi review code người khác, câu hỏi cuối cùng bạn đặt ra là về cú pháp hay về hệ thống?
Nếu phần lớn câu trả lời là “chưa”, không sao — đó chính xác là lý do series này tồn tại. Quay lại bài 1 và bài 2, chọn đúng 1 tip, áp dụng trong 2 tuần tới trước khi thêm tip thứ hai.
AI không lấy đi công việc của người có mindset hệ thống. Nó lấy đi công việc của người coi lập trình chỉ là gõ code theo yêu cầu — và đó chưa bao giờ là phần giá trị nhất của công việc này, kể cả trước khi AI xuất hiện.
Tóm lại những gì cần nhớ:
- AI giỏi trả lời câu hỏi có sẵn, dở đặt câu hỏi đúng trong context sống
- 3 lợi thế thật: trách nhiệm không thể outsource, context sống tích lũy theo thời gian, và mindset khuếch đại hiệu quả dùng AI
- Đây là lợi thế xác suất, không phải bùa hộ mệnh tuyệt đối
- Xây dựng qua chu trình dự đoán — quan sát — điều chỉnh, không qua một khóa học
Việc cụ thể để làm ngay hôm nay: chọn 1 sự cố hoặc bug gần nhất bạn xử lý, viết post-mortem 5 dòng theo mẫu ở trên. Chỉ 5 dòng, không cần hoàn hảo — quan trọng là bắt đầu chu trình.
Chúc anh em code vui! 🚀
Tags: #systemdesign #softwareengineering #careerdev #aicareer
Có một khảo sát nội bộ mình đọc được cuối 2025: hơn 60% dev junior-mid nói họ lo AI sẽ thay thế công việc của mình trong 2-3 năm tới. Nhưng ít ai hỏi đúng câu hỏi. Câu hỏi đúng không phải “AI có viết code giỏi hơn mình không” — rõ ràng là có, ở rất nhiều task. Câu hỏi đúng là: “phần nào trong công việc của mình AI không làm được, và mình có đang đầu tư vào đúng phần đó không”.