AI viết code hộ rồi, dev còn cần học gì nữa? Phần 2: Gửi những người đang ở vạch xuất phát
Bài trước tôi viết về chuyện “AI viết code hộ rồi, dev còn cần học gì nữa?”, và tôi đoán có vài bạn QA đang trong hành trình chuyển dịch sang engineer đọc xong sẽ hơi chùn chân: “Dev kỳ cựu còn phải lo trau dồi nền tảng, vậy mình mới bắt đầu thì cửa nào?”
Bài này tôi viết riêng cho các bạn. Và tôi muốn nói ngay từ đầu: nếu đọc kỹ bài trước, các bạn sẽ thấy nó không phải tin xấu cho người mới. Nó là tin xấu cho người không chịu học. Còn với người xuất phát từ QA, tôi cho rằng đây là thời điểm vào nghề tốt một cách bất ngờ. Để tôi giải thích vì sao, bằng số liệu chứ không phải lời động viên suông.
Tin tốt thứ nhất: chưa bao giờ rào cản vào nghề thấp đến thế
Mười năm trước, một người chuyển từ QA sang dev phải tự bơi qua một đại dương: tài liệu khô khan, lỗi compile khó hiểu, không ai ngồi cạnh giải thích vì sao đoạn code này chạy còn đoạn kia thì không. Bây giờ thì khác.
Theo GitHub Octoverse 2025, gần 80% dev mới trên GitHub dùng Copilot ngay trong tuần đầu tiên. Còn khảo sát Stack Overflow 2025 cho thấy trong nhóm người đang học lập trình, 73% đã dùng AI tools, riêng nhóm dùng hằng ngày là gần 40%. Nghĩa là dùng AI để học không phải đường tắt đáng xấu hổ; nó đang trở thành con đường chính thống.
Các bạn có thứ mà thế hệ trước không có: một “đồng nghiệp” kiên nhẫn vô hạn, sẵn sàng giải thích cùng một khái niệm theo mười cách khác nhau, không bao giờ chê câu hỏi ngớ ngẩn, trực 24/7. Vấn đề duy nhất là dùng nó như mentor hay dùng nó như máy photocopy. Tôi sẽ quay lại điểm này ở cuối bài.
Tin tốt thứ hai: xuất phát điểm QA là lợi thế kép
Đây là điều tôi muốn các bạn tin nhất, vì nó có dữ liệu chống lưng hẳn hoi.
Luận điểm trung tâm của bài trước là: AI đã biến mọi dev thành reviewer. Code giờ rẻ, nhưng niềm tin vào code thì đắt. Nhìn các con số: báo cáo bảo mật của Veracode 2025 kiểm tra code sinh ra từ hơn 100 mô hình AI và phát hiện 45% chứa lỗ hổng bảo mật. Khảo sát Stack Overflow ghi nhận nỗi bực bội số một với AI, được 66% dev nêu ra, là code “gần đúng nhưng không đúng hẳn”. Còn DORA Report 2025 chỉ ra rằng thời gian tiết kiệm được ở khâu viết code đang chảy sang khâu kiểm tra và xác minh.
Giờ đọc lại đoạn trên và tự hỏi: kiểm tra, xác minh, soi lỗi, không tin vào thứ trông-có-vẻ-đúng, đó chẳng phải là mô tả công việc của QA sao?
Một dev truyền thống phải học cách nghi ngờ code. Các bạn được trả lương để nghi ngờ trong suốt sự nghiệp. Tư duy “cái này sẽ lỗi ở đâu?”, thói quen nghĩ đến edge case trước khi nghĩ đến happy path, sự lì lợm khi tái hiện một bug khó tái hiện: những thứ đó không phải kỹ năng phụ trong kỷ nguyên AI. Chúng đang trở thành kỹ năng trung tâm.
Và còn lợi thế thứ hai mà tôi thấy rõ ở các bạn QA trong công ty: các bạn nắm nghiệp vụ rất chắc. Đây là thứ đáng giá hơn nhiều người tưởng. AI có thể viết code giỏi, nhưng nó không biết nghiệp vụ của chúng ta: không biết luồng nào là sống còn với khách hàng, dữ liệu nào hợp lệ trong domain này, quy tắc nào có ngoại lệ vào cuối tháng. Trong kỷ nguyên mà phần “viết code” được AI gánh bớt, người hiểu đúng cần build cái gì và mô tả được nó rõ ràng lại càng có giá. Một câu prompt tốt thực chất là một bản mô tả nghiệp vụ tốt, và các bạn đã luyện việc đó nhiều năm qua từng case test. Nói cách khác, các bạn không đi từ con số không; các bạn đã có sẵn hai thứ khó dạy nhất là tư duy kiểm thử và kiến thức nghiệp vụ, và đang đi học nốt phần còn lại.
Vì sao lộ trình e2e test, fix bug, simple task lại hợp lý
Lộ trình công ty đang cho các bạn đi không phải ngẫu nhiên, và tôi muốn chỉ ra logic của nó, vì hiểu vì sao mình đang làm việc này sẽ giúp các bạn đi qua những đoạn chán nản.
Viết e2e test không dạy các bạn góc nhìn người dùng, vì thật ra các bạn đã có sẵn nó từ những năm manual test. Giá trị thật của giai đoạn này nằm ở chỗ khác: nó biến kiến thức kiểm thử sẵn có thành code. Vẫn là những kịch bản test các bạn thuộc lòng, nhưng giờ phải diễn đạt chúng bằng ngôn ngữ lập trình: viết selector, xử lý chờ bất đồng bộ, chuẩn bị và dọn dẹp dữ liệu test. Tức là các bạn học lập trình trên một địa hình mình đã thuộc, nên toàn bộ năng lượng dồn vào việc học code, thay vì vừa học code vừa học nghiệp vụ như một người ngoài bước vào.
Fix bug là cách học một codebase nhanh nhất mà tôi biết. Mỗi bug ép bạn đọc code người khác viết, lần theo luồng dữ liệu, hiểu vì sao nó lỗi, tức là đọc nhiều hơn viết. Mà như bài trước đã nói: trong kỷ nguyên AI, đọc và thẩm định code mới là kỹ năng đắt giá. Các bạn đang luyện đúng cơ bắp mà thị trường cần.
Simple task rồi tiến lên junior dev là lúc bạn bắt đầu tạo ra thay vì chỉ sửa chữa. Đến giai đoạn này, vốn tích lũy từ hai giai đoạn trước, gồm hiểu hệ thống, hiểu codebase, hiểu cách mọi thứ vỡ, biến thành nền móng để code của bạn ít vỡ hơn người khác.
Bốn lời khuyên cụ thể
1. Dùng AI như mentor, không phải máy làm bài hộ. Quy tắc tôi đề xuất: với mỗi đoạn code AI viết cho bạn, hãy hỏi thêm ít nhất một câu “vì sao”. Vì sao dùng cấu trúc này, vì sao không làm cách kia, trade-off là gì. Copy-paste cho qua task thì nhanh hôm nay, nhưng bạn sẽ giậm chân tại chỗ. Hỏi vì sao thì chậm hôm nay, nhưng ba tháng sau bạn là người khác.
2. Mỗi bug là một bài học nền tảng miễn phí. Fix xong đừng đóng ticket ngay. Dành 15 phút tự hỏi: bug này thuộc lớp lỗi nào? Null/undefined? Race condition? Sai kiểu dữ liệu? Lệch timezone? Dần dần bạn sẽ thấy bug không còn là những tai nạn rời rạc mà là những mẫu hình lặp lại. Nhận ra mẫu hình chính là thứ phân biệt người có nền tảng với người không.
3. Đừng vứt bỏ “chất QA” của mình. Nhiều bạn chuyển dịch cố gắng “trở thành dev” đến mức bỏ lại đằng sau chính thứ làm mình có giá trị. Đừng. Khảo sát Stack Overflow cho thấy nỗi bực bội lớn nhất với AI là code “gần đúng nhưng không đúng hẳn”, và phát hiện cái “gần đúng” đó là nghề của các bạn.
4. So sánh mình với mình của tháng trước, không phải với senior ngồi cạnh. Hành trình QA sang engineer đo bằng quý và năm, không phải tuần. Một thước đo thực tế: ba tháng trước bạn đọc đoạn code đó có hiểu không? Giờ thì sao? Nếu câu trả lời là “giờ hiểu rồi”, bạn đang đi đúng hướng, bất kể cảm giác tụt hậu có nói gì.
Lời kết
Bài trước kết thúc bằng câu nói của một senior dev mà tôi quý: “Nắm không chắc thì review tù mù lắm.” Anh ấy nói về nỗi sợ của một dev giỏi khi review thứ mình không nắm vững.
Nhưng lật ngược lại, câu đó cũng là kim chỉ nam cho hành trình của các bạn: nghề này chưa bao giờ cần người nắm chắc đến thế. AI đang viết ra nhiều code hơn bao giờ hết, gần một nửa trong số đó có vấn đề, và ngành này đang khát những người vừa biết code, vừa hiểu nghiệp vụ, vừa mang trong mình sự hoài nghi chuyên nghiệp.
Các bạn không phải đang đuổi theo một chuyến tàu sắp rời ga. Các bạn đang bước lên đúng chuyến tàu, ở đúng sân ga, vào đúng giờ. Việc còn lại chỉ là đừng ngừng học. Mà điều đó thì, như cả hai bài viết này đã nói, là việc của tất cả chúng ta, từ junior đến senior.
Nguồn tham khảo: Stack Overflow Developer Survey 2025 · GitHub Octoverse 2025 · DORA Report 2025 · Veracode 2025 GenAI Code Security Report



