Cái rào giữa các vai trò không phải tự nhiên có
Để hiểu chuyện gì đang xảy ra, tôi cần quay lại một chút.
Ngành phần mềm chúng ta xây dựng những cái rào này không phải vì lý do kỹ thuật. Mà vì lý do tổ chức.
PM/BA tách ra khỏi dev vì dev ngày xưa thiếu, PM/BA giỏi khảo sát nhưng không giỏi code, nên tối ưu nhất là phân vai. Tester tách ra vì test là một nghề riêng – có phương pháp, có mindset, có kỹ thuật chuyên biệt (boundary, equivalence partition, exploratory testing…). Dev tách biệt khỏi product vì "để dev tập trung code thôi cho tốt".
Hồi tôi mới ra trường, dự án nhỏ, team 3-4 người, một người kiêm cả code, khảo sát, test và triển khai. Tôi không có PM riêng, không có tester riêng. Mọi thứ gói trong một đầu người.
Rồi team lớn dần. Quy trình được cài đặt. Role được tách ra. Rào giới được dựng lên – không phải bằng gạch, mà bằng "đó không phải việc của tôi".
Và bây giờ, AI đang phá những cái rào đó. Không phải vì công nghệ quá mạnh – mà vì công nghệ làm cho việc "vượt rào" trở nên rẻ đến mức không ai phải nghĩ nhiều khi làm.
PM giờ đọc được code – và đó không phải là chuyện nhỏ
Cách đây 5 năm, một PM mở file code sẽ thấy như đọc chữ cái Maya cổ đại. Ngôn ngữ khác, cú pháp khác, mental model khác. PM chỉ có thể giao tiếp với dev qua "spec", và cái spec đó thường là bản dịch một chiều từ ngôn ngữ business sang ngôn ngữ kỹ thuật – mà dịch sai thì dev vẫn phải tự hiểu lại.
Giờ thì khác.
Một PM có Cursor, GitHub Copilot hay Claude Code trong tay có thể mở một file React, đọc phần lớn logic, đặt câu hỏi "nếu user click vào đây thì state nào thay đổi", và nhận được câu trả lời. Không phải lúc nào cũng chính xác – nhưng đủ tốt để PM nắm được hệ thống đang nói gì.
Và khi PM hiểu code, điều kỳ lạ xảy ra: PM không cần phải trở thành dev. PM vẫn là PM. Nhưng giờ PM là một PM có thể đọc, đánh giá, và đặt câu hỏi có chiều sâu hơn về technical trade-off.
Có một bạn PM từng chia sẻ với tôi: "Trước đây tôi viết spec kiểu 'làm cho hệ thống recommend tốt hơn'. Giờ tôi viết spec kiểu 'khi user có 5 lượt click trong 30 giây, model X sẽ recall từ cache Y và trả về top 5 item với confidence > 0.7'. Cùng là một feature, nhưng spec thứ hai dev làm trong 2 ngày, spec đầu làm trong 2 tuần và đi 3 vòng sửa".
Đó không phải PM trở thành dev. Đó là PM đang trở thành một PM khác – một PM có cùng công cụ với dev.
Và điều tương tự đang xảy ra ở chiều ngược lại.
Tester không còn đứng ngoài codebase
Sự phân bổ giữa dev và tester đã thay đổi mạnh trong vài năm qua, theo chiều tester ngày càng mỏng đi. Nếu mười năm trước gần như team nào cũng có tester riêng và số lượng tương xứng với dev, thì giờ nhiều team nhỏ chỉ có một tester cho cả nhóm hoặc thậm chí không có ai chuyên trách. Stack Overflow Developer Survey 2025 (gần 50.000 người tham gia, 177 quốc gia) ghi nhận QA/Test chỉ chiếm khoảng 8.4% tổng số người trả lời, với mức lương trung vị cũng thấp hơn đáng kể so với các vai trò khác. Hướng đi rõ ràng: vai trò tester truyền thống đang bị nén lại.
Con số này không phải vì AI "giết chết" tester. Mà vì AI đã thay đổi hoàn toàn cách test được thực hiện.
Cách đây 5 năm, một tester giỏi là người viết manual test case tỉ mỉ trong Excel, biết cách exploratory test, và đặt bug chính xác cho dev fix. Bây giờ, một tester giỏi là người:
- Dùng Playwright + Codegen để record user flow → tự động generate test script
- Dùng AI để generate test case từ acceptance criteria
- Dùng property-based testing để cover edge case mà manual test không bao giờ nghĩ tới
- Đọc được code test do AI generate, sửa và bổ sung
Anh tester tôi vừa nhắc ở đầu bài – anh ấy không trở thành dev. Nhưng anh ấy không còn đứng ngoài codebase. Repo giờ có cả code test của dev và code test của anh ấy, cùng review chung trong PR.
Và quan trọng hơn: anh ấy không phải viết toàn bộ test script. AI generate, anh ấy review và chỉnh. Công việc tester không mất đi – nó chuyển từ "viết test" sang "kiểm soát chất lượng test mà AI viết".
Đây là chi tiết quan trọng mà nhiều bạn bỏ qua khi bàn về AI và nghề tester. Không phải AI thay thế tester. Mà là AI làm cho tester có thể mở rộng phạm vi ảnh hưởng của mình – từ test thủ công sang cả design test và review automation.
Dev phải involve vào product và test – và đó là lực cản lớn nhất
Đây là phần khó nhất, và cũng là phần mà nhiều bạn dev trẻ sẽ thấy… không thoải mái.
PM giờ đọc được code. Tester giờ viết được test. Câu hỏi ngược lại: dev có đang involve vào product và test không?
Câu trả lời: phải. Không phải vì sếp yêu cầu. Mà vì nếu không, dev sẽ tụt lại.
Lý do rất đơn giản: khi AI generate code, dev không còn là người duy nhất viết code nữa. PM có thể viết được một cái prototype đơn giản. Tester có thể viết được test script. Designer có thể generate UI code. Cái mà dev làm tốt nhất không còn là "code" – mà là hiểu product, đánh giá trade-off, và đảm bảo chất lượng.
Một dev giỏi năm 2026 không chỉ code. Dev giỏi:
- Đọc và hiểu user story đủ sâu để đặt câu hỏi với PM: "case này user làm gì?", "metric thành công là gì?", "có cần support offline không?"
- Tự viết test cho feature của mình – không phải vì "test là việc của tester", mà vì AI không biết business logic sâu bằng người viết feature
- Review code của chính mình trước khi push, vì AI đã generate quá nhiều code mà dev không đọc hết
Tôi đã nói chuyện với vài team lead về điều này. Một bạn nói thẳng: "Một năm trước tôi chỉ review code của dev. Giờ tôi review cả spec của PM, test của tester, và UI prompt của designer. Công việc của tôi không nhẹ đi – nó thay đổi hình dạng".
"Cognitive debt" – cái giá của việc xóa rào mà không có nền tảng
Nhưng tôi phải nói thẳng một điều: không phải ai xóa rào cũng tốt.
Có một nghiên cứu pre-print từ MIT Media Lab (Kosmyna et al., 2025, arXiv:2506.08872) mà tôi đọc gần đây làm tôi dừng lại khá lâu. Họ dùng EEG để đo hoạt động não của 54 người viết essay, chia làm 4 nhóm:
- Brain-only (không dùng AI): kết nối neural cao, recall trung bình 92%, ownership cực cao
- Search-assisted (Google/Wiki): kết nối neural trung bình, recall ~74%
- AI-Dependent (để AI viết gần hết): kết nối neural yếu, recall chỉ 17%, ownership rất thấp
- AI-Augmented (tự viết trước, rồi dùng AI để cải thiện): kết nối neural moderate-high, recall ~68%
Có một chi tiết đáng suy ngẫm: trong nhóm AI-Dependent, 83% số người không thể quote lại đoạn văn họ vừa "viết" với AI, ngay sau khi viết xong. Họ đã mất quyền sở hữu với chính sản phẩm của mình.
Nghiên cứu này chưa peer-review, sample size nhỏ, và cần thận trọng khi diễn giải. Nhưng nó gợi lên một câu hỏi mà tôi nghĩ team nào cũng nên tự hỏi:
Khi PM đọc code bằng AI, tester viết test bằng AI, dev viết code bằng AI – ai là người thực sự hiểu sản phẩm?
Nếu tất cả mọi người đều phụ thuộc AI để vượt qua rào giới của mình, thì không ai thực sự vượt qua. Mọi người đều ở trên AI – không ai đứng trên đất.
Đây là cognitive debt mà nghiên cứu MIT gọi tên: khoản nợ về nhận thức tích lũy khi chúng ta để AI làm thay những việc mà lẽ ra chúng ta phải tự hiểu.
Vai trò nào còn lại khi đã xóa rào?
Tôi nghĩ nhiều về câu hỏi này trong vài tháng qua. Và đây là cách tôi nhìn.
Không phải vai trò nào "chết". Cả PM, tester, dev đều vẫn ở đó. Nhưng hình dạng của mỗi vai trò đang thay đổi:
- PM không còn là người viết spec rồi ném qua tường cho dev. PM là người hiểu đủ sâu để đồng thiết kế với dev – và biết khi nào nên nhường quyết định kỹ thuật cho dev, khi nào cần đặt câu hỏi sâu hơn. PM giỏi là PM có thể "đọc" được codebase và nói được business impact.
- Tester không còn là người ngồi viết test case thủ công. Tester giỏi là người thiết kế test strategy, kiểm soát chất lượng test mà AI sinh ra, và cover những khu vực mà AI chưa biết cách test (security, accessibility, edge case business-specific).
- Dev không còn là người code nhiều nhất. Dev giỏi là người hiểu product đủ sâu để quyết định nên build gì, build như thế nào, và khi nào nên dừng lại. Dev vẫn code – nhưng code giờ chỉ là một phần công việc, không phải toàn bộ.
Nói cách khác: AI không xóa vai trò, AI xóa rào giới giữa vai trò. Và khi rào giới mỏng đi, mỗi người phải tự quyết định mình muốn mở rộng sang phía nào.
Một số dev sẽ mở rộng sang product. Một số PM sẽ mở rộng sang technical. Một số tester sẽ trở thành dev thực thụ. Một số khác sẽ đào sâu vào chuyên môn – security, performance, data – để trở thành người không thể bị thay thế.
Không có con đường nào đúng cho tất cả mọi người.
Gửi các bạn đang xây team trong kỷ nguyên AI
Tôi không có câu trả lời gọn cho team nào đang vật lộn với câu hỏi "tổ chức thế nào giờ". Nhưng có vài thứ tôi thấy các team đang làm tốt:
1. Không ai bị "giữ trong rào" nữa. Team tốt là team nơi PM được khuyến khích đọc code, tester được khuyến khích commit, dev được khuyến khích hỏi về product. Đừng xây policy cấm ai đó vượt rào.
2. Nhưng mỗi người vẫn phải có "nền" của mình. AI giúp bạn vượt rào nhanh hơn. Nhưng nếu bạn không có nền, bạn đang đứng trên AI chứ không phải đứng trên đất. PM phải hiểu business. Tester phải hiểu test methodology. Dev phải hiểu system design. AI là đòn bẩy, không phải nền móng.
3. Cognitive debt là thật. Đừng để cả team phụ thuộc AI để "biết" điều mà lẽ ra phải tự biết. Một dự án mà ai cũng dùng AI để hiểu code của nhau, thì không ai thực sự hiểu code. Đầu tư vào việc tự đọc, tự test, tự phân tích – dù AI có thể làm nhanh hơn.
4. Định vị lại bằng câu hỏi "tôi giải quyết vấn đề gì", không phải "tôi làm công việc gì". PM giỏi không phải người viết spec hay. PM giỏi là người giúp team build đúng thứ. Dev giỏi không phải người code nhiều. Dev giỏi là người giúp team hiểu được sản phẩm của mình.
Tôi nghĩ đến một ngày nào đó, khi nhìn lại giai đoạn này, chúng ta sẽ thấy đây là một trong những cuộc tái cấu trúc lao động thú vị nhất trong ngành phần mềm. Ranh giới mềm đi, vai trò nới ra, mỗi người tự định hình bản thân trong tầm nhìn của công cụ.
Nhưng – và đây là điều cuối tôi muốn nói – đừng nhầm "rào mềm" với "không có nền". Một người có thể vượt rào nhanh bằng AI, nhưng nếu không có căn bản, thì khi AI sai, người đó cũng không nhận ra điều đó.
Các bạn đang sống trong giai đoạn thú vị nhất của ngành. Đừng lãng phí nó bằng cách chỉ ngồi nhìn AI làm.
Bạn đang chọn mở rộng sang phía nào – product, kỹ thuật, hay chuyên sâu vào một lĩnh vực mà AI chưa chạm tới?
/Son Do – believe in basic
#1percentbetter #believeinbasic #careercraft #aiforsoftwareteams #developerlife
