Singing Bonus

Special Gifts

Freelancer

Full-time

AI Engineer (Middle/Senior)

Tester

Manual QC Engineer (Middle)

Business Analyst (Junior/Middle)

Network

Network Engineer (Junior)

Java

Java Developer (Middle/Senior)

DevOps

DevOps Engineer (Mid/Senior)

Angular

Angular Developer (Middle)

React Native

React Native Developer (Middle/Senior)

Senior Java Developer

<html><body>Nếu trước đây QC Engineer phải dành nhiều thời gian đọc requirement, phân tích scenario và viết từng test case, thì AI đang giúp rút ngắn đáng kể quá trình này. Từ user story hay acceptance criteria, các công cụ AI đã có thể đề xuất test scenario, edge case, thậm chí hỗ trợ tạo automation script. Khi việc “viết test case” ngày càng dễ được tự động hóa, câu hỏi đặt ra không còn đơn giản là AI có thay thế QC hay không, mà là: QC Engineer sẽ cần tạo ra giá trị ở đâu khi AI đã có thể đảm nhận một phần công việc quen thuộc? AI đang thay đổi cách test case được tạo ra Một trong những ứng dụng rõ nhất của Generative AI trong software testing là khả năng tạo test case từ requirement, source code hoặc mô tả chức năng. Thay vì bắt đầu từ một trang trắng, QC có thể sử dụng AI để nhanh chóng tạo danh sách happy path, negative case, boundary case hoặc exception scenario ban đầu. GitHub hiện đã hướng dẫn cách sử dụng Copilot để hỗ trợ tạo unit test và integration test. Tuy nhiên, tài liệu của GitHub cũng lưu ý rằng những test được tạo bởi AI vẫn cần được review, đặc biệt khi scenario phức tạp hoặc công cụ không có đủ context về hệ thống. (<a href="https://docs.github.com/en/copilot/tutorials/write-tests">GitHub Docs</a>) Điều này không khiến test design trở nên không cần thiết. Ngược lại, nó thay đổi cách QC sử dụng thời gian. Thay vì dành nhiều giờ để tạo từng test case cơ bản, tester có thể bắt đầu với một bộ scenario do AI đề xuất, sau đó tập trung vào coverage, risk và những trường hợp AI chưa nhìn thấy. IBM cũng ghi nhận AI đang được ứng dụng trong QA để hỗ trợ tạo test case, phát hiện defect, xác định những thay đổi code có rủi ro cao và tự động hóa một phần functional, regression hay performance testing. (<a href="https://www.ibm.com/think/insights/quality-assurance-in-software-testing-with-ai">IBM</a>) Khi đó, câu hỏi quan trọng sẽ dần chuyển từ “Còn test case nào nữa không?” sang “Test case nào thực sự đáng để ưu tiên?” Từ viết test case sang đánh giá rủi ro Giả sử requirement chỉ ghi: “Người dùng có thể thanh toán đơn hàng bằng thẻ tín dụng.” AI có thể nhanh chóng đề xuất các trường hợp như thanh toán thành công, sai CVV, thẻ hết hạn, thiếu số thẻ hoặc giao dịch bị từ chối. Đây đều là những test case cần thiết, nhưng chúng mới chỉ phản ánh những tình huống tương đối dễ nhận biết. Một QC Engineer có kinh nghiệm có thể đặt thêm những câu hỏi khác: Nếu payment gateway trả về success nhưng hệ thống nội bộ timeout thì chuyện gì xảy ra? Nếu người dùng bấm thanh toán hai lần vì mạng chậm, liệu họ có bị charge hai lần? Nếu tiền đã bị trừ nhưng order creation thất bại, hệ thống xử lý reconciliation thế nào? Khả năng đặt ra những câu hỏi như vậy không đến từ việc biết viết nhiều test case hơn. Nó đến từ hiểu biết về hệ thống, business flow, historical bugs và khả năng đánh giá impact khi một chức năng gặp lỗi. Đây chính là khoảng cách giữa sinh test case và tư duy testing. AI có thể giúp tạo ra 50 hoặc 100 scenario trong thời gian rất ngắn, nhưng QC vẫn cần quyết định scenario nào nên test trước, đâu là flow quan trọng với người dùng và trường hợp nào tuy ít xảy ra nhưng có thể gây tổn thất lớn nếu bị bỏ sót. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/105-kTgzJ8hpkHlFs9W41AdkIaBBhddQYA2yr7wiyPOX.webp"></figure>Business knowledge sẽ trở thành lợi thế lớn hơn Khi nhiều người cùng có thể sử dụng AI để tạo test case, việc biết vận hành một công cụ AI sẽ khó trở thành lợi thế lâu dài. Khác biệt sẽ nằm nhiều hơn ở khả năng hiểu sản phẩm và domain. Một lỗi hiển thị trên trang setting và một lỗi khiến transaction bị ghi nhận hai lần đều là bug, nhưng business impact hoàn toàn khác nhau. AI có thể giúp nhận diện một số pattern kỹ thuật, nhưng nếu không được cung cấp đầy đủ context, nó khó tự biết flow nào đang trực tiếp ảnh hưởng đến doanh thu, dữ liệu nhạy cảm hay compliance. Vì vậy, QC trong fintech cần hiểu transaction, payment lifecycle và reconciliation. QC trong e-commerce cần hiểu promotion, inventory, checkout và order lifecycle. Những lĩnh vực như logistics, healthcare hay enterprise software cũng có những business rule riêng mà tester cần nắm được. Domain knowledge giúp QC không chỉ hỏi “Feature này có chạy đúng không?”, mà còn hiểu “Nếu nó chạy sai, điều gì sẽ xảy ra với người dùng và doanh nghiệp?” Trong bối cảnh AI ngày càng mạnh ở phần tạo nội dung, khả năng hiểu vấn đề phía sau requirement có thể trở thành một trong những năng lực khó thay thế hơn. QC sẽ phải kiểm tra cả những test do AI tạo ra Có một thay đổi khá thú vị khi AI tham gia sâu hơn vào testing: QC không chỉ kiểm thử sản phẩm mà còn cần đánh giá chất lượng của chính những test được AI tạo ra. Một automation script có thể chạy thành công nhưng chưa chắc đã là một test tốt. Assertion có thể quá yếu, test data chưa đủ đại diện hoặc test đang xác nhận implementation hiện tại thay vì behavior thực sự được yêu cầu. Tương tự, AI có thể tạo hàng chục test case nhưng nhiều case chỉ khác nhau rất nhỏ. Test suite lớn hơn không đồng nghĩa khả năng phát hiện defect tốt hơn. Một systematic review năm 2025 về việc sử dụng Large Language Models trong unit test generation ghi nhận validation và repair là những bước quan trọng để cải thiện chất lượng test do AI tạo ra, trong khi khả năng phát hiện lỗi vẫn còn những hạn chế nhất định. (<a href="https://arxiv.org/abs/2511.21382">arXiv</a>) Vì vậy, QC sẽ cần biết cách review output của AI: Test này có thực sự kiểm tra business rule không? Assertion đã đủ mạnh chưa? Có edge case quan trọng nào bị bỏ sót không? Những test mới có thực sự tăng coverage hay chỉ làm test suite dài hơn? AI có thể tạo bản nháp rất nhanh. Nhưng tester vẫn phải quyết định bản nháp đó có đủ tốt để sử dụng hay không. Exploratory testing có thể ngày càng có giá trị AI đặc biệt mạnh khi bài toán có pattern rõ và context tương đối đầy đủ. Trong khi đó, nhiều defect ngoài thực tế lại xuất hiện từ những hành vi mà requirement không mô tả. Người dùng có thể mở hai tab cùng lúc, refresh trong lúc transaction đang xử lý, quay lại màn hình cũ sau khi session hết hạn hoặc chuyển mạng khi đang upload file. Những hành vi như vậy không phải lúc nào cũng xuất hiện trong một bộ test case được tạo từ requirement. Đó là nơi exploratory testing phát huy giá trị. Thay vì chỉ thực hiện các bước đã được định nghĩa sẵn, tester chủ động khám phá sản phẩm, kết hợp nhiều hành vi, thử phá vỡ assumption và đặt câu hỏi về những tình huống mà team chưa từng nghĩ tới. IBM cũng lưu ý rằng việc có nhiều automated checks chạy thành công có thể tạo ra cảm giác an toàn trong khi sản phẩm vẫn tồn tại usability issue hoặc những vấn đề ngoài pattern được định nghĩa trước. (<a href="https://www.ibm.com/think/insights/quality-assurance-in-software-testing-with-ai">IBM</a>) Khi phần testing lặp lại được AI và automation xử lý nhiều hơn, khả năng tìm ra “những điều chúng ta chưa biết là cần phải test” có thể trở thành một lợi thế lớn hơn của QC Engineer. QC cần technical hơn, nhưng không nhất thiết trở thành Developer Sử dụng AI tốt không chỉ là biết viết prompt. Muốn biết một test script do AI tạo ra có hợp lý hay không, QC vẫn cần hiểu application hoạt động như thế nào. Kiến thức về API, database, logs, network request, authentication và cách các service giao tiếp với nhau sẽ giúp tester nhìn sâu hơn vào nguyên nhân lỗi. Với Automation QC, nền tảng programming, version control, testing framework và CI/CD càng trở nên quan trọng. AI có thể giúp viết một đoạn Playwright hoặc API test nhanh hơn, nhưng tester vẫn cần hiểu đoạn code đang làm gì, tại sao nó fail và liệu cách xây dựng đó có đủ maintainable khi hệ thống mở rộng. Vì vậy, bộ kỹ năng của QC trong giai đoạn tới có thể được hình dung theo công thức: Testing mindset + Domain knowledge + Technical skills + AI literacy. Xu hướng này cũng đang xuất hiện trong các certification mới. ISTQB Certified Tester – Testing with Generative AI đề cập đến prompt engineering cho software testing, đánh giá output của GenAI và những rủi ro như hallucination, bias hay data privacy. (<a href="https://istqb.org/istqb-announces-minor-update-to-certified-tester-testing-with-generative-ai-ct-genai/">ISTQB</a>) Không chỉ dùng AI để test, QC còn phải biết test sản phẩm AI AI không chỉ thay đổi công cụ làm việc của QC. Nó còn xuất hiện ngày càng nhiều bên trong sản phẩm. Với software truyền thống, một input thường đi kèm một expected output khá rõ. Nhưng với Generative AI, cùng một prompt có thể tạo ra những kết quả khác nhau giữa các lần chạy. Việc kiểm thử vì thế không phải lúc nào cũng có thể dựa trên logic “input A phải bằng chính xác output B”. QC có thể cần đánh giá thêm hallucination, bias, robustness, safety, consistency hay khả năng chống prompt injection. ISTQB Certified Tester AI Testing Version 2.0 cũng đã bổ sung các nội dung liên quan đến testing Generative AI và Large Language Models, bao gồm exploratory testing, red teaming, input data testing và risk-based testing. (<a href="https://istqb.org/istqb-releases-certified-tester-ai-testing-ct-ai-syllabus-version-2-0/">ISTQB</a>) Tương lai của nghề vì vậy có thể đi theo hai hướng song song: dùng AI để test software nhanh hơn và học cách test những software sử dụng AI. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/104-ws6l71hxi6ogMoQDfz8m8eQ8Cx9S5WAb6IPVc2L1.webp"></figure>Junior và Senior QC sẽ cần thay đổi khác nhau Những task AI dễ hỗ trợ nhất hiện nay cũng là nhiều công việc quen thuộc ở level Junior: tạo test case cơ bản từ requirement, chuẩn bị test data, viết checklist hoặc xây dựng một số automation script đơn giản. Điều này không có nghĩa Junior QC sẽ biến mất. Nhưng việc “biết viết test case” có thể không còn đủ để tạo lợi thế như trước. Junior QC có thể cần tiếp cận API testing, SQL, test design technique, debugging và automation sớm hơn, đồng thời học cách đánh giá thay vì đơn thuần sử dụng output của AI. Với Middle và Senior QC, kỳ vọng sẽ dịch chuyển rõ hơn về test strategy, risk assessment, requirement analysis và quality decision. Giá trị không nằm ở việc một Senior có thể viết nhiều test case hơn Junior bao nhiêu, mà ở khả năng xác định đâu là thứ cần được kiểm tra trước khi sản phẩm release. Khi AI tăng tốc phần execution, phần judgment sẽ ngày càng quan trọng. QC Engineer nên chuẩn bị gì từ bây giờ? QC không nhất thiết phải chạy theo mọi công cụ AI mới xuất hiện. Quan trọng hơn là học cách đưa AI vào workflow một cách có kiểm soát. Thay vì chỉ hỏi “hãy viết test case cho feature này”, tester có thể cung cấp thêm business rules, known risks, architecture hoặc historical bugs rồi yêu cầu AI tìm missing scenario, challenge assumption hoặc đề xuất những khu vực cần exploratory testing. Song song đó, những kỹ năng nền tảng vẫn cần được củng cố: requirement analysis, risk-based testing, exploratory testing, domain knowledge, API, SQL, automation và debugging. Cách nhìn về productivity cũng có thể thay đổi. Một QC giỏi trong tương lai chưa chắc là người tự tay viết 200 test case. Đó có thể là người dùng AI tạo 200 candidate cases, nhanh chóng loại bỏ những case ít giá trị, bổ sung những scenario AI bỏ sót và xác định được 10 trường hợp quan trọng nhất cần kiểm tra trước release. AI không kết thúc nghề QC, nhưng sẽ thay đổi cách QC tạo giá trị AI đang giúp việc tạo test case và test script nhanh hơn, và những phần testing mang tính lặp lại nhiều khả năng sẽ tiếp tục được tự động hóa. Nhưng software quality chưa bao giờ chỉ được quyết định bởi số lượng test case hay số automated tests đang chạy xanh. Một sản phẩm tốt còn phụ thuộc vào việc đội ngũ hiểu đâu là rủi ro cần ưu tiên, requirement nào chưa đủ rõ và người dùng có thể hành động ngoài dự đoán ra sao. Khi AI đảm nhận nhiều hơn phần “viết test như thế nào”, QC Engineer sẽ cần tạo giá trị nhiều hơn ở những câu hỏi khó hơn: “Tại sao phải test?”, “Nên test điều gì trước?” và “Điều gì có thể xảy ra mà chúng ta chưa nghĩ tới?” AI có thể sinh test case. Nhưng khả năng nhìn thấy rủi ro phía sau những test case đó vẫn là nơi QC Engineer tạo ra khác biệt. </body></html>

Khi AI có thể tự sinh test case, viết test script và hỗ trợ automation, QC Engineer sẽ cần thay đổi kỹ năng và cách tạo giá trị như thế nào?

QC Engineer sẽ thay đổi thế nào khi AI tự sinh test case?

<html><body>Sự xuất hiện của AI chỉ khiến hạn chế này trở nên rõ ràng hơn. Khi chi phí để tạo ra code ngày càng thấp, câu hỏi dành cho Software Engineer có thể dần chuyển từ “Bạn đã viết được bao nhiêu?” sang “Những gì bạn xây dựng tạo ra giá trị gì, đáng tin cậy đến đâu và giúp sản phẩm, hệ thống hay đội ngũ tiến lên như thế nào?”. Nếu những xu hướng của giai đoạn 2025–2026 tiếp tục, cách đánh giá Software Engineer trong năm 2027 nhiều khả năng sẽ dựa trên một tập hợp tiêu chí rộng hơn rất nhiều so với code output. Tại sao số dòng code ngày càng ít ý nghĩa? Hãy đặt hai Developer cạnh nhau. Developer A viết 1.000 dòng code để xây một feature, trong khi Developer B nhận ra phần lớn logic có thể được đơn giản hóa, tái sử dụng component có sẵn và giải quyết cùng bài toán với 200 dòng. Nếu chỉ nhìn vào lượng output, Developer A có vẻ năng suất hơn. Nhưng nếu nhìn vào maintainability, complexity, khả năng tái sử dụng và chi phí vận hành dài hạn, kết quả có thể hoàn toàn ngược lại. Vấn đề này càng rõ khi AI tham gia sâu hơn vào development workflow. Stack Overflow Developer Survey 2025 ghi nhận 84% người tham gia đang sử dụng hoặc có kế hoạch sử dụng AI trong quá trình phát triển phần mềm; riêng nhóm Professional Developer, 51% cho biết họ sử dụng AI hằng ngày. (<a href="https://survey.stackoverflow.co/2025/ai?utm_source=chatgpt.com">Stack Overflow</a>) GitHub cũng ghi nhận lượng hoạt động phát triển phần mềm tăng mạnh trong năm 2025, với khoảng 986 triệu code pushes và trung bình 43,2 triệu pull request được merge mỗi tháng. Tuy nhiên, GitHub lưu ý rằng các con số này chỉ phản ánh hoạt động quan sát được và không đủ để kết luận AI trực tiếp tạo ra mức tăng trưởng đó. (<a href="https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/?utm_source=chatgpt.com">GitHub Octoverse</a>) Điều này dẫn đến một khác biệt quan trọng: chúng ta đang ngày càng có khả năng tạo ra nhiều code hơn, nhưng nhiều code hơn không đồng nghĩa với nhiều giá trị hơn. Vì vậy, nếu lượng code không còn là tín hiệu đủ mạnh, trọng tâm đánh giá Software Engineer sẽ cần dịch chuyển sang những yếu tố phản ánh kết quả thực sự của công việc. Từ Code Output sang Business Impact Một trong những thay đổi dễ thấy nhất có thể là cách các team nhìn vào impact. Thay vì chỉ quan tâm Developer đã hoàn thành bao nhiêu ticket, tạo bao nhiêu commit hay merge bao nhiêu pull request, câu hỏi quan trọng hơn sẽ là: thay đổi này đã tạo ra kết quả gì sau khi đi vào production? Một Developer tối ưu hệ thống để giảm thời gian xử lý transaction từ ba giây xuống còn dưới một giây có thể tạo ra impact lớn hơn việc hoàn thành nhiều feature nhưng ít người sử dụng. Tương tự, một thay đổi nhỏ giúp giảm số lượng support ticket, cải thiện conversion rate hoặc loại bỏ một quy trình thủ công cũng có thể mang lại giá trị đáng kể dù số dòng code rất ít. DORA hiện đưa các yếu tố như Business Impact, End-User Satisfaction và Product Quality vào những lĩnh vực có thể được theo dõi song song với Developer Performance và Delivery. (<a href="https://dora.dev/research/2025/questions/?utm_source=chatgpt.com">DORA</a>) Điều này có nghĩa Software Engineer trong tương lai không chỉ cần biết code mình hoạt động như thế nào, mà còn cần hiểu code đó phục vụ mục tiêu nào của sản phẩm và business. Khả năng kết nối một technical decision với kết quả cuối cùng có thể trở thành một phần rõ ràng hơn trong cách đánh giá engineering performance. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/futurism-perspective-digital-nomads-lifestyle-Fw1vJl8dK8NLenlCwocsv7R5yjwbkeEq2FEBI9FP.webp"></figure>Khả năng giải quyết đúng vấn đề sẽ quan trọng hơn việc implement thật nhanh AI có thể giúp Developer đi rất nhanh từ một requirement rõ ràng đến implementation. Nhưng trong thực tế, requirement hiếm khi hoàn toàn rõ ngay từ đầu. Một câu như “trang này load chậm”, “hệ thống cần scale” hay “khách hàng muốn export report” có thể ẩn phía sau nhiều nguyên nhân và nhu cầu khác nhau. Một Software Engineer có giá trị không chỉ là người có thể implement solution được giao, mà còn là người biết xác định vấn đề thực sự cần giải quyết. Điều đó đòi hỏi khả năng đặt câu hỏi, kiểm tra assumption, phân biệt symptom với root cause và cân nhắc xem có cần xây thêm thứ gì hay không. Trong một số trường hợp, giải pháp tốt nhất thậm chí có thể là loại bỏ code, thay đổi process hoặc tận dụng một capability đã có thay vì tạo thêm feature mới. Khi AI làm cho phần implementation trở nên nhanh hơn, problem framing sẽ ngày càng quan trọng. Nếu giải sai bài toán, tốc độ viết code nhanh hơn chỉ giúp đội ngũ đi sai hướng nhanh hơn mà thôi. Chất lượng quyết định kỹ thuật có thể trở thành một thước đo lớn hơn AI có thể đề xuất microservices, monolith, Redis, Kafka, Kubernetes hoặc hàng loạt architectural pattern chỉ trong vài giây. Tuy nhiên, giá trị thực sự không nằm ở việc biết nhiều công nghệ nhất mà ở khả năng lựa chọn giải pháp phù hợp với bối cảnh cụ thể. Mỗi technical decision đều chứa trade-off. Microservices có thể hỗ trợ scale độc lập nhưng đồng thời làm tăng operational complexity. Caching có thể cải thiện performance nhưng tạo thêm bài toán consistency. Một abstraction giúp tái sử dụng code nhưng cũng có thể khiến một module đơn giản trở nên khó hiểu và khó maintain hơn. Software Engineer càng có kinh nghiệm càng được kỳ vọng nhìn thấy những đánh đổi này trước khi chúng trở thành vấn đề ở production. DORA 2025 mô tả AI trong software development như một “amplifier”: công nghệ này có thể khuếch đại cả điểm mạnh lẫn điểm yếu vốn tồn tại trong hệ thống và tổ chức. Lợi ích vì vậy không chỉ phụ thuộc vào AI tool mà còn vào nền tảng engineering, workflow, testing và cách team đưa ra quyết định. (<a href="https://dora.dev/research/2025/dora-report/?utm_source=chatgpt.com">DORA</a>) Trong bối cảnh đó, engineering judgment có thể trở thành một dạng productivity mới. Không phải ai đưa ra nhiều quyết định hơn sẽ tốt hơn, mà là ai có thể đưa ra những quyết định phù hợp hơn và giảm số lần hệ thống phải trả giá cho lựa chọn sai. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/MES_1300-qEhBCsXUFFumhU0KPOJ1CfRztyeXKXKynu962Twx.webp"></figure>Ship nhanh vẫn phải đi cùng chất lượng và độ ổn định Một Engineer có thể tạo feature rất nhanh, nhưng nếu mỗi lần deploy đều kéo theo production incident thì velocity cao không còn mang nhiều ý nghĩa. Vì vậy, software delivery ngày càng được nhìn dưới cả hai góc độ: tốc độ và sự ổn định. DORA sử dụng các chỉ số như change lead time, deployment frequency, failed deployment recovery time và change fail rate để đánh giá khả năng đưa thay đổi vào production nhanh chóng mà vẫn kiểm soát được rủi ro. (<a href="https://dora.dev/guides/dora-metrics/?utm_source=chatgpt.com">DORA Metrics</a>) Cách tiếp cận này phản ánh một thực tế quan trọng: một Software Engineer không chỉ chịu trách nhiệm cho việc code được merge, mà còn cho những gì xảy ra sau khi thay đổi đó đi vào hệ thống thật. Vì thế, những năng lực như automated testing, observability, monitoring, rollback strategy, incident response và khả năng thiết kế hệ thống có resilience tốt có thể ngày càng được tính vào khái niệm “performance” của một Engineer. Nói cách khác, tốc độ ship sẽ có giá trị hơn khi nó không đánh đổi bằng stability. Khả năng kiểm chứng AI-generated code sẽ trở thành năng lực cốt lõi AI càng tạo code tốt, vai trò của Developer càng ít nằm ở việc tự tay gõ từng dòng và nhiều hơn ở khả năng đánh giá output được tạo ra. Stack Overflow Developer Survey 2025 cho thấy 46% Developer không tin tưởng độ chính xác của output từ AI, trong khi tỷ lệ tin tưởng là 33%. Đồng thời, 66% người tham gia cho biết họ từng gặp trường hợp AI đưa ra solution “gần đúng nhưng chưa hoàn toàn đúng”, còn 45% cho biết debugging AI-generated code có thể tốn thời gian hơn. (<a href="https://survey.stackoverflow.co/2025/ai?utm_source=chatgpt.com">Stack Overflow</a>) Điều này tạo ra một nghịch lý thú vị: AI càng có khả năng viết nhiều code, khả năng đọc và review code của con người càng trở nên quan trọng. Một Software Engineer giỏi phải đủ sâu về kỹ thuật để nhận ra assumption sai, edge case bị bỏ sót, security vulnerability, concurrency issue, performance bottleneck hay một đoạn logic đúng về syntax nhưng sai với business rule. Trong workflow có AI, Developer vì vậy không chỉ là code creator mà còn đóng vai trò quality gate. Việc “biết code” sẽ dần bao gồm cả khả năng kiểm chứng, phản biện và chịu trách nhiệm với code dù phần implementation ban đầu được tạo bởi con người hay AI. Giá trị cá nhân sẽ được nhìn rộng hơn qua tác động lên cả team Engineering impact không dừng ở output của một cá nhân. Một Senior Engineer dành vài ngày xây internal library, chuẩn hóa deployment pipeline hoặc cải thiện CI/CD có thể không trực tiếp ship nhiều feature trong sprint đó, nhưng công việc ấy có thể giúp hàng chục Developer khác làm việc nhanh hơn trong nhiều tháng sau. Nghiên cứu về Developer Experience của GitHub cho thấy productivity còn liên quan đến những yếu tố như flow state, cognitive load và feedback loop thay vì chỉ lượng output kỹ thuật. (<a href="https://github.blog/news-insights/research/good-devex-increases-productivity/?utm_source=chatgpt.com">GitHub</a>) Microsoft Research năm 2026 cũng giới thiệu EngThrive, một hệ thống đo engineering productivity xoay quanh ba chiều Speed, Ease và Quality, đồng thời sử dụng Thriving như một guardrail cho trải nghiệm Developer. Hướng tiếp cận này tiếp tục củng cố xu hướng chuyển từ đo activity sang đo outcome. (<a href="https://www.microsoft.com/en-us/research/publication/engthrive-make-it-fast-and-easy-to-do-great-work/?utm_source=chatgpt.com">Microsoft Research</a>) Vì vậy, một Engineer có thể được đánh giá không chỉ qua việc bản thân họ làm nhanh đến đâu, mà còn qua khả năng tạo leverage cho cả team. Mentoring, documentation, xây reusable tooling, cải thiện developer experience hay giảm cognitive load đều là những đóng góp khó thể hiện bằng số dòng code nhưng có impact dài hạn. Ownership sẽ kéo dài từ requirement đến production Một ticket được đánh dấu “Done” không có nghĩa vấn đề đã thực sự được giải quyết. Feature có thể đã merge nhưng không ai sử dụng, API đã deploy nhưng latency tăng, hoặc bug đã được fix nhưng root cause vẫn chưa được xử lý. Trong cách làm việc dựa trên outcome, ownership không kết thúc khi pull request được approve. Engineer cần quan tâm tới toàn bộ vòng đời của thay đổi: requirement có được hiểu đúng không, implementation có phù hợp không, deployment có an toàn không, metric sau release thay đổi như thế nào và hệ thống có phát sinh vấn đề gì sau đó. Sự chuyển dịch này có thể khiến Software Engineer được đánh giá ngày càng nhiều bằng khả năng chịu trách nhiệm với kết quả cuối cùng thay vì chỉ với phần code được giao. Đây cũng là một trong những điểm phân biệt rõ giữa task completion và engineering ownership.<img src="https://api.careers.saigontechnology.com/storage/ck-editor/97-QyX0lmkcq0eDHOkdhAC3nfqcADbCWzOuvLcQlaXc.webp">Vậy Software Engineer 2027 sẽ được đánh giá bằng gì? Khó có một metric duy nhất đủ sức trả lời câu hỏi này. Thay vì lines of code, commit hay số ticket hoàn thành, performance của Software Engineer có thể được nhìn qua nhiều chiều cùng lúc: impact tạo ra cho user và business, chất lượng technical decision, khả năng giải quyết đúng vấn đề, chất lượng và reliability của hệ thống, tốc độ delivery, mức độ leverage tạo ra cho cả team, khả năng sử dụng và kiểm chứng AI cũng như mức ownership từ requirement đến production. Không phải tất cả những yếu tố này đều dễ chuyển thành một con số, nhưng software engineering vốn chưa bao giờ là công việc có thể được mô tả đầy đủ bằng một dashboard duy nhất. Việc AI làm giảm chi phí tạo code chỉ khiến các tổ chức phải nhìn rõ hơn đâu mới là phần giá trị thực sự của một Engineer. Code vẫn quan trọng, nhưng ngày càng giống phương tiện hơn là đích đến Khả năng coding sẽ không biến mất. Software Engineer vẫn cần hiểu programming language, framework, database, concurrency, testing, security và architecture đủ sâu để biết hệ thống đang vận hành như thế nào. Thậm chí, trong một môi trường nơi ngày càng nhiều code được AI tạo ra, nền tảng kỹ thuật vững có thể còn quan trọng hơn để Developer nhận ra khi output của AI không đáng tin cậy. Thứ đang thay đổi không phải là việc code còn quan trọng hay không, mà là vai trò của nó trong cách đánh giá một Engineer. Coding có thể ngày càng trở thành phương tiện để tạo ra impact thay vì bản thân nó là thước đo của impact. Năm 2027, chúng ta có thể vẫn viết code, review pull request và fix bug giống như hiện nay. Nhưng câu hỏi để nhận diện một Software Engineer giỏi có lẽ sẽ ít dần là “Bạn viết được bao nhiêu code?” và nhiều hơn là “Sau khi bạn tham gia, sản phẩm, hệ thống và đội ngũ đã tốt hơn như thế nào?”. Trong một thế giới nơi AI có thể tạo code trong vài giây, đó có thể chính là loại giá trị khó tự động hóa nhất. </body></html>

Nếu một AI coding agent có thể tạo hàng trăm dòng code trong vài phút, liệu “viết được bao nhiêu code” còn là cách hợp lý để đánh giá một Software Engineer? Thực tế, số dòng code vốn chưa bao giờ là thước đo hoàn hảo cho năng suất kỹ thuật. GitHub cũng chỉ ra rằng việc lấy lines of code làm chỉ số chính có thể tạo ra những động lực sai và không phản ánh đầy đủ những gì Developer thực sự đóng góp trong một ngày làm việc.

Software Engineer 2027 sẽ được đánh giá bằng gì nếu không còn là số dòng code?

<html><body>Thoạt nhìn, đây có thể được xem là một làn sóng layoffs mới của ngành công nghệ. Nhưng nếu nhìn rộng hơn, những gì diễn ra trong năm 2026 cho thấy một chuyển dịch lớn hơn nhiều: Big Tech không đơn thuần thu nhỏ bộ máy — họ đang thiết kế lại cách một công ty công nghệ vận hành trong kỷ nguyên AI. Và điều đó có thể là tín hiệu cho những thay đổi tiếp theo của toàn bộ thị trường công nghệ. 2026: Khi “tăng trưởng” không còn đồng nghĩa với “tăng headcount” Trong nhiều năm, đặc biệt ở giai đoạn công nghệ tăng trưởng nóng, mở rộng business thường đi cùng với một công thức khá quen thuộc: thêm sản phẩm, thêm thị trường và thêm nhân sự. Năm 2026 cho thấy công thức đó đang thay đổi. Tháng 1, Amazon công bố cắt 16.000 vị trí corporate, nâng tổng số nhân sự bị ảnh hưởng kể từ tháng 10/2025 lên khoảng 30.000 người. Công ty nhấn mạnh mục tiêu giảm tầng nấc quản lý, tăng ownership và loại bỏ bureaucracy trong tổ chức. Meta cũng triển khai kế hoạch cắt khoảng 8.000 việc làm trong năm, song song với việc tái phân bổ hàng nghìn nhân sự sang các sáng kiến liên quan đến AI workflow và giảm các vị trí quản lý. Đến tháng 7, Microsoft thông báo cắt khoảng 4.800 vị trí, tương đương 2,1% lực lượng lao động toàn cầu, trong một đợt tái cấu trúc lớn tập trung vào Xbox và commercial sales. Công ty khẳng định những vị trí bị loại bỏ không đơn giản là được “thay thế bởi AI”, nhưng cũng thừa nhận AI đang thay đổi cách công việc được thực hiện. Điều đáng chú ý nằm ở nghịch lý: Big Tech giảm nhân sự ở một số khu vực nhưng không hề giảm tham vọng đầu tư. Ngược lại, cuộc đua AI đang khiến chi tiêu tăng lên ở quy mô chưa từng có. Microsoft, Amazon, Alphabet và Meta được dự báo chi tổng cộng khoảng 725 tỷ USD vốn đầu tư trong năm 2026, phần lớn phục vụ data center, chip, cloud và hạ tầng AI. Vì vậy, câu chuyện của năm 2026 không đơn giản là “công nghệ đang thiếu tiền”. Nó giống một cuộc tái phân bổ nguồn lực hơn. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/063d51b3-cf48-45a8-8bf6-b740e152ed45-151252-1779438668944-1779438669435824973208%20(1)-OJr6XoJegMZqb0oVwavWm6EZcMaThiIJ0eYiJsF9.webp"></figure>1. AI đang chuyển từ “công cụ hỗ trợ” thành một phần của operating model Trong vài năm đầu của Generative AI, câu hỏi phổ biến trong doanh nghiệp là: Chúng ta có thể dùng AI ở đâu?” Đến 2026, câu hỏi đang dần trở thành: “Nếu AI đã tồn tại trong gần như mọi workflow, tổ chức này nên được thiết kế lại như thế nào?” Đó là một thay đổi rất lớn. AI không còn chỉ xuất hiện dưới dạng chatbot hoặc coding assistant. Công nghệ này đang được đưa vào software development, customer support, sales, marketing, analytics, operations và nhiều quy trình nội bộ khác. Khi một phần công việc có thể được tự động hóa hoặc thực hiện nhanh hơn, doanh nghiệp bắt đầu đánh giá lại:  <ul><li>Một team thực sự cần bao nhiêu người? </li><li>Có cần nhiều tầng quản lý như trước? </li><li>Công việc nào nên tự động hóa? </li><li>Công việc nào cần con người đưa ra quyết định? </li><li>Một nhân sự có AI hỗ trợ có thể đảm nhận phạm vi công việc lớn hơn đến đâu? </li></ul>Đây cũng là lý do layoffs và AI thường xuất hiện trong cùng một cuộc thảo luận, nhưng quan hệ giữa hai yếu tố này không đơn giản theo công thức “AI xuất hiện → con người bị thay thế”. Trong trường hợp Microsoft, công ty trực tiếp nhấn mạnh rằng các vị trí bị loại bỏ không phải đơn thuần được thay thế bằng AI; vấn đề lớn hơn là cách công việc, mô hình kinh doanh và cấu trúc tổ chức đang thay đổi. Nói cách khác, AI đang trở thành chất xúc tác khiến doanh nghiệp đặt lại câu hỏi về cách họ vận hành. 2. Cuộc đua AI đang buộc Big Tech phải lựa chọn nơi đặt nguồn lực AI không hề “rẻ”. Phía sau một model hay một AI assistant là GPU, chip chuyên dụng, data center, điện năng, networking, storage và đội ngũ nghiên cứu – kỹ thuật có chi phí rất cao. Meta, chẳng hạn, dự kiến có thể chi tới 145 tỷ USD cho AI infrastructure trong năm 2026 và đang phát triển chip AI riêng nhằm tăng năng lực tính toán cũng như giảm sự phụ thuộc vào nhà cung cấp bên ngoài. Ở quy mô toàn ngành, khoản đầu tư AI khổng lồ này đang tạo áp lực mới: nhà đầu tư không chỉ muốn nghe doanh nghiệp nói rằng họ đang “đầu tư cho tương lai”, mà còn muốn thấy AI có thể tạo ra productivity, revenue hoặc margin như thế nào. Khi hàng trăm tỷ USD được chuyển sang infrastructure, compute và AI talent, những business unit tăng trưởng chậm, cấu trúc dư thừa hoặc dự án có ROI không rõ ràng sẽ bị soi xét kỹ hơn. Đó là lý do nhiều đợt restructuring hiện nay có thể được hiểu theo một logic khá đơn giản: Không phải Big Tech ngừng đầu tư. Họ đang quyết liệt hơn trong việc lựa chọn thứ đáng để đầu tư. Microsoft là một ví dụ. Trong khi tăng mạnh chi tiêu AI, công ty đồng thời tái cấu trúc Xbox sau nhiều năm đầu tư lớn nhưng hiệu quả kinh doanh chưa đáp ứng kỳ vọng. Tái cấu trúc vì thế không chỉ là bài toán tiết kiệm chi phí. Nó còn là bài toán portfolio management: đâu là lĩnh vực cần tiếp tục đặt cược và đâu là nơi nguồn lực nên được chuyển đi. 3. Mô hình tổ chức “flatter” đang dần trở thành một ưu tiên Một từ xuất hiện thường xuyên trong các cuộc tái cấu trúc gần đây là layers. Amazon muốn giảm tầng quản lý và bureaucracy. Meta cũng hướng tới việc loại bớt managerial roles trong một số thay đổi tổ chức. Điều này phản ánh một xu hướng rộng hơn. Khi thông tin có thể được tổng hợp nhanh hơn bằng AI, analytics trở nên accessible hơn và một số workflow được tự động hóa, doanh nghiệp có ít lý do hơn để duy trì quá nhiều tầng trung gian chỉ để truyền đạt thông tin hoặc điều phối công việc. Mô hình mà nhiều công ty hướng tới có thể sẽ là: team nhỏ hơn → ownership lớn hơn → decision-making nhanh hơn → ít tầng phê duyệt hơn. Điều đó không có nghĩa manager sẽ biến mất. Nhưng vai trò của manager có thể thay đổi. Thay vì chủ yếu kiểm soát tiến độ hoặc điều phối thông tin, giá trị sẽ nằm nhiều hơn ở khả năng đưa ra quyết định, phát triển con người, giải quyết vấn đề phức tạp và tạo direction cho team. Nói cách khác, AI không chỉ thay đổi individual contributor. Nó cũng đang thay đổi management. 4. “Có việc làm hay không?” có lẽ không còn là câu hỏi quan trọng nhất Mỗi khi xuất hiện một đợt layoffs lớn, câu hỏi dễ xuất hiện nhất là: “AI có đang lấy mất việc làm trong ngành công nghệ?” Nhưng có lẽ một câu hỏi hữu ích hơn là: “Giá trị của từng loại công việc đang thay đổi như thế nào?” Bởi cùng thời điểm một số vị trí bị cắt giảm, cuộc cạnh tranh giành AI talent vẫn diễn ra quyết liệt. Meta, chẳng hạn, tiếp tục tuyển những AI researcher cấp cao để củng cố Meta Superintelligence Labs trong tháng 8/2026. Tức là thị trường có thể đồng thời xảy ra hai điều tưởng như trái ngược: layoff ở một nhóm công việc và talent war ở một nhóm khác. Điều đó cho thấy thị trường việc làm công nghệ không nhất thiết đang đơn giản “co lại”. Nó đang tái định giá skill. Những phần việc mang tính lặp lại, có quy trình rõ ràng hoặc phụ thuộc nhiều vào việc tổng hợp – chuyển tiếp thông tin sẽ chịu áp lực tự động hóa lớn hơn. Ngược lại, giá trị có xu hướng dịch chuyển về những năng lực khó đóng gói thành một prompt: hiểu business context, thiết kế architecture, đưa ra judgment, giải quyết ambiguity, giao tiếp với stakeholder, bảo đảm security, dẫn dắt team và biến AI thành kết quả kinh doanh thực tế. Và ngay cả với developer, designer, BA, QC hay marketer, câu hỏi mới cũng không còn đơn giản là: “Bạn có biết sử dụng AI không?” Mà sẽ dần trở thành: “AI giúp bạn tạo ra kết quả tốt hơn đến mức nào?” 5. Productivity đang trở thành một KPI quan trọng hơn headcount Trong mô hình tăng trưởng cũ, quy mô đội ngũ thường phần nào phản ánh quy mô doanh nghiệp. Một công ty tăng trưởng nhanh có thể tuyển thêm hàng nghìn nhân sự. Nhưng trong mô hình mới, nhà đầu tư và lãnh đạo có thể quan tâm nhiều hơn tới những chỉ số như: “Revenue per employee. Output per engineer. Cost per transaction. Time-to-market.” Nếu AI cho phép một team 10 người tạo ra output tương đương team 15 người trước đây, câu hỏi của doanh nghiệp sẽ không phải là: “Chúng ta có thể tuyển thêm bao nhiêu người?” mà là: “Chúng ta có thực sự cần tuyển thêm hay không?” Điều này có thể khiến thị trường tuyển dụng công nghệ trở nên selective hơn. Company vẫn tuyển, nhưng justification cho mỗi vị trí có thể cao hơn. Candidate không chỉ cạnh tranh với candidate khác mà còn phải chứng minh rằng vai trò đó tạo ra giá trị trong một môi trường mà automation ngày càng mạnh. Đây có lẽ là một trong những thay đổi quan trọng nhất mà làn sóng restructuring 2026 đang báo hiệu. 6. Từ “AI adoption” sang “AI-native organization” Giai đoạn đầu của AI transformation chủ yếu xoay quanh việc đưa thêm công cụ vào quy trình hiện tại. <ul><li>Developer có Copilot. </li><li>Marketing có AI content tool. </li><li>Customer Service có chatbot. </li><li>Data team có AI assistant. </li></ul>Nhưng việc gắn AI lên một quy trình cũ chưa chắc tạo ra transformation. Bước tiếp theo mà Big Tech đang thử nghiệm khó hơn nhiều: thiết kế lại chính quy trình đó dựa trên giả định rằng AI đã tồn tại ngay từ đầu. Khi đó, câu hỏi không phải: “AI có thể hỗ trợ nhân viên này như thế nào?” mà là: “Nếu bắt đầu xây team này từ đầu trong năm 2026, với những khả năng AI hiện có, chúng ta sẽ thiết kế team như thế nào?”. Đây là sự khác biệt giữa một doanh nghiệp using AI và một tổ chức thực sự AI-native. Và restructuring có thể chính là giai đoạn khó tránh khỏi trong quá trình chuyển từ mô hình thứ nhất sang mô hình thứ hai. <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/man-communicating-with-artificial-intelligence-through-isolated-screen-device-2YsVfvn5Ko00ZByBCl8taVFOfhVMgfeBC5cPWd7r.webp"></figure>Vậy làn sóng tái cấu trúc Big Tech 2026 thực sự đang nói lên điều gì? Nếu chỉ nhìn vào con số layoffs, bức tranh rất dễ trở nên bi quan. Nhưng nhìn ở cấp độ chiến lược, những gì đang diễn ra cho thấy một sự dịch chuyển phức tạp hơn. Big Tech đang chuyển từ mô hình tăng trưởng bằng quy mô sang tăng trưởng bằng leverage. <ul><li>Leverage từ AI. </li><li>Leverage từ automation. </li><li>Leverage từ infrastructure. </li><li>Leverage từ những team nhỏ nhưng có khả năng tạo ra output lớn hơn. </li></ul>Vì vậy, 2026 có thể không phải là năm ngành công nghệ “ngừng tuyển người”. Nó có thể là năm ngành công nghệ bắt đầu đặt ra một tiêu chuẩn khác cho việc vì sao cần tuyển một người. Đối với doanh nghiệp, bài toán sẽ là tìm được điểm cân bằng giữa AI, con người và cấu trúc tổ chức. Đối với người làm công nghệ, lợi thế cạnh tranh sẽ ngày càng ít nằm ở khả năng hoàn thành một task đơn lẻ, mà nhiều hơn ở khả năng giải quyết một problem trọn vẹn — với AI như một phần tự nhiên trong cách làm việc. Và nếu làn sóng tái cấu trúc của Big Tech thường là chỉ báo sớm cho phần còn lại của ngành công nghệ, thì những thay đổi đang diễn ra trong năm 2026 có lẽ mới chỉ là bước khởi đầu. </body></html>

Amazon cắt giảm 16.000 vị trí corporate. Meta triển khai kế hoạch giảm khoảng 8.000 nhân sự. Microsoft tiếp tục tái cấu trúc với 4.800 vị trí bị ảnh hưởng. Trong khi đó, hàng trăm tỷ USD vẫn đang được các tập đoàn công nghệ đổ vào AI, data center và hạ tầng điện toán.

Thrive To Code Your Dreams With Saigon Technology

Empower the world with what we build

work life

Life at Saigon Technology

Thrive To Code Your Dreams With .css-aofjdm{color:var(--chakra-colors-green);}Saigon Technology

Empower the world with what we build

work life

Life at Saigon Technology

Thrive To Code Your Dreams With Saigon Technology