Loading...

AI có đang làm ngành IT khắc nghiệt hơn?

Giới thiệu

Chào các bạn,

Mấy tháng gần đây mình thấy trên Facebook có một kiểu nội dung lặp lại rất nhiều trong mảng IT: AI giúp làm việc nhanh hơn, ít người hơn nhưng vẫn ra nhiều output hơn. Nhìn ở bề mặt thì điều đó đúng. Mình cũng đang dùng AI gần như mỗi ngày trong công việc, và rõ ràng có rất nhiều đầu việc chạy nhanh hơn trước.

Nhưng nếu chỉ dừng ở chỗ “AI giúp tiết kiệm thời gian” thì mình nghĩ vẫn thiếu một nửa bức tranh. Vì ở góc nhìn người đi làm, nhất là BA, dev, tester, PM, designer…, chuyện đang xảy ra không chỉ là làm nhanh hơn. Nó còn là bị kỳ vọng nhiều hơn, phải tự học nhiều hơn, phải biết rộng hơn, và thậm chí phải tự bỏ thêm tiền để theo kịp mặt bằng mới.

Trong bài này mình muốn chia sẻ một góc nhìn khá thẳng: AI là tốt, nhưng không phải cứ tốt cho công ty là tốt tương đương cho người lao động. Nó tạo ra năng suất, nhưng áp lực, chi phí và sự cạnh tranh đi kèm cũng tăng lên rất rõ.

AI đúng là giúp công việc IT chạy nhanh hơn

Nói cho công bằng thì AI thật sự rất mạnh ở nhiều việc, và mình nghĩ không nên phủ nhận phần này.

Với BA, AI có thể hỗ trợ:

  • viết nhanh user story
  • tóm tắt họp
  • giải thích tài liệu kỹ thuật
  • hỗ trợ vẽ flow, diagram, wireframe
  • tổng hợp domain knowledge ban đầu
  • draft nhanh các tài liệu như SRS, PRD, BRD, URD
  • hỗ trợ làm prototype ban đầu

Với dev, AI có thể hỗ trợ:

  • gợi ý code
  • vibe coding để ra bản đầu nhanh hơn
  • lên kế hoạch code hoặc chia nhỏ task
  • viết unit test ban đầu
  • giải thích code cũ
  • hỗ trợ debug hướng xử lý
  • rút ngắn thời gian đọc tài liệu, syntax, boilerplate

Với tester hoặc manual QC, AI cũng có thể hỗ trợ:

  • draft test case nhanh hơn
  • gợi ý test scenario và edge case
  • tóm tắt requirement để test bám scope hơn
  • hỗ trợ viết các script automation ban đầu
  • hỗ trợ phân tích bug report hoặc log để khoanh vùng nhanh hơn

Minh họa AI hỗ trợ nhiều vai trò IT

Nếu nhìn ở mức độ từng tác vụ thì đây là cải thiện rất thật. Những phần trước đây mất nhiều giờ để làm bản đầu, bây giờ có thể xuống còn vài chục phút. Một BA trước đây phải tốn khá nhiều thời gian để viết SRS, vẽ diagram hoặc làm prototype, thì giờ có thể ra bản nháp nhanh hơn rất nhiều. Dev cũng vậy. Tester cũng vậy.

Vấn đề là công việc không dừng ở chỗ “ra nháp nhanh hơn”.

Nhưng nhanh hơn không đồng nghĩa với nhẹ hơn

Đây là chỗ mình thấy nhiều người bắt đầu mệt.

Trong môi trường công ty, năng suất tăng không tự động đồng nghĩa với việc khối lượng việc giảm xuống. Trái lại, điều mình thấy phổ biến hơn là:

  • làm nhanh hơn thì bị giao thêm việc
  • phản hồi nhanh hơn thì bị kỳ vọng nhanh hơn
  • ra nhiều output hơn thì phải cover nhiều scope hơn
  • tự xử lý được nhiều việc hơn thì trách nhiệm cá nhân cũng nặng hơn

Tức là AI không chỉ là công cụ tiết kiệm thời gian. Trong mắt doanh nghiệp, nó còn là công cụ để tăng output trên mỗi người.

Ví dụ trước đây một BA có thể mất khá nhiều thời gian để viết SRS, chỉnh cấu trúc tài liệu, vẽ flow, làm prototype, tổng hợp note từ meeting. Bây giờ nhiều phần đó chạy nhanh hơn. Nhưng đổi lại, BA thường sẽ bị kéo sang:

  • thêm dự án
  • thêm stakeholder
  • thêm vòng review
  • thêm yêu cầu đổi gấp từ business
  • thêm trách nhiệm chuẩn hóa output từ AI

Với dev cũng tương tự. Việc gõ code thuần có thể nhanh hơn, nhưng đổi lại lại phải:

  • review kỹ hơn phần AI sinh ra
  • kiểm tra logic kỹ hơn
  • kiểm tra security, performance, side effects
  • dành thời gian sửa những đoạn “nhìn có vẻ đúng nhưng thật ra sai”
  • đôi lúc phải ôm thêm những phần trước đây được xem là ngoài phạm vi, ví dụ deploy hoặc setup linh tinh để giữ tốc độ release

Với tester, test case có thể ra nhanh hơn, nhưng đổi lại áp lực thường chuyển sang:

  • review test coverage kỹ hơn
  • kiểm tra chỗ AI bỏ sót
  • hiểu sản phẩm sâu hơn để không test kiểu bề mặt
  • học thêm automation hoặc công cụ mới để không bị đứng yên

Nói ngắn gọn, cái giảm đi là thời gian làm tay ở một số bước. Nhưng cái tăng lên là:

  • độ rộng đầu việc
  • áp lực deadline
  • trách nhiệm review
  • yêu cầu ra quyết định
  • cường độ tự học

Minh họa áp lực năng suất và đầu việc tăng lên

Đó là lý do nhiều người có cảm giác rất lạ: “đỡ cực hơn về thao tác, nhưng lại mệt hơn về tinh thần”.

BA, dev, tester đang bị kéo sang một mặt bằng kỳ vọng mới

Theo mình, AI không chỉ làm thay đổi tốc độ làm việc. Nó còn làm thay đổi định nghĩa của một người “làm được việc”.

Với BA

Trước đây chỉ riêng việc viết tài liệu cho gọn, rõ, đủ ý đã tốn rất nhiều thời gian. Bây giờ, khi AI giúp draft nhanh SRS, PRD, BRD, URD, dựng flow, tóm tắt họp, làm prototype, thì kỳ vọng đặt lên BA cũng đổi theo.

BA bây giờ không chỉ viết tài liệu, mà còn phải:

  • biết dùng AI để draft nhanh
  • biết lên prototype nhanh hơn
  • biết review đầu ra thay vì tin tuyệt đối
  • biết tóm tắt và chuẩn hóa output
  • biết xây dựng quy trình làm việc với AI
  • biết chỗ nào nên dùng AI, chỗ nào phải làm tay

Thậm chí ở vài team, BA còn phải nghĩ theo kiểu:

  • prompt nào dùng cho discovery
  • prompt nào dùng cho phân tích requirement
  • prompt nào dùng cho draft tài liệu
  • đầu ra nào cần human review bắt buộc
  • phần nào có thể đưa vào workflow lặp lại

Tức là BA không còn chỉ làm tài liệu nữa. BA phải biết cách biến AI thành một phần của quy trình làm việc.

Với dev

Dev cũng vậy.

Trên lý thuyết, AI giúp gợi ý code, vibe coding, lên plan cho implementation, viết unit test, giải thích code cũ, hỗ trợ debug. Nhưng đổi lại, công việc của dev bây giờ dễ bị kéo theo một hướng khác:

  • phải code nhanh hơn
  • phải ra feature nhanh hơn
  • phải check code AI sinh ra kỹ hơn
  • phải tự giữ chất lượng logic
  • phải giữ tốc độ release
  • đôi lúc phải tự lo thêm những phần như deploy, cấu hình, integration, monitoring

Nghe thì có vẻ công cụ mạnh hơn, nhưng thực tế là phần “gõ code” có thể nhẹ đi, còn phần “chịu trách nhiệm cho sản phẩm chạy ổn” lại nặng lên.

Mình thấy đây là chỗ dễ mệt nhất. Vì AI có thể cho một cảm giác rất nguy hiểm: output đến nhanh, nhưng nếu logic sai thì hậu quả vẫn do con người gánh.

Với tester

Tester hoặc manual QC là nhóm mình nghĩ cũng chịu áp lực khá rõ, nhưng lại ít được nói tới hơn.

Nếu AI giúp draft test case nhanh hơn, tóm tắt requirement nhanh hơn, gợi ý bug scenario nhanh hơn, thì điều công ty dễ nghĩ là:

  • test phải chạy nhanh hơn
  • coverage phải rộng hơn
  • số lượng test case phải nhiều hơn
  • regression phải gọn hơn
Đọc thêm  15 điểm UI/UX cho mảng banking hay và cần lưu ý - phần 1

Nhưng trong thực tế, cái phần khó của tester không chỉ là gõ test case. Cái khó là:

  • hiểu requirement có lỗ hổng ở đâu
  • nhìn ra edge case nào đáng test
  • biết bug nào thật sự đáng ưu tiên
  • giao tiếp với BA/dev để chốt expected behavior

Vậy nên với manual QC, AI có thể khiến áp lực chuyển từ “viết nhiều” sang “review nhiều hơn và phải giỏi hơn”. Chưa kể thêm một áp lực mới là:

  • phải học thêm automation testing
  • phải học cách dùng AI để hỗ trợ test
  • phải tự nghiên cứu nhiều kỹ năng mới hơn trước để đáp ứng JD tuyển dụng

Nói cách khác, AI không hẳn làm tester nhẹ việc. Nó chỉ đổi dạng áp lực.

Chi phí để theo kịp AI không hề miễn phí

Đây là phần mình thấy rất nhiều bài viết trên mạng ít nói thẳng.

Khi ai đó bảo “cứ dùng AI là sẽ làm nhanh hơn”, họ thường không nói rõ cái giá phải trả để làm được điều đó ổn định mỗi ngày.

Một số chi phí rất thực tế là:

  • tiền mua token hoặc subscription
  • tiền dùng nhiều tool khác nhau để thử
  • tiền học thêm khóa học
  • tiền trả cho các app phụ trợ
  • thời gian tự nghiên cứu workflow
  • thời gian thử sai để biết model nào hợp với việc nào

Không phải công ty nào cũng trả tiền AI cho nhân viên. Có nơi không hỗ trợ gì. Có nơi hỗ trợ một phần. Có nơi cho dùng nhưng chỉ giới hạn vài tool cơ bản. Phần còn lại nhiều khi nhân viên phải tự bỏ tiền túi ra.

Điều này dẫn tới một nghịch lý khá buồn:

  • chi phí cá nhân tăng
  • thời gian học tăng
  • áp lực công việc tăng
  • nhưng lương chưa chắc tăng tương ứng

Chưa kể để dùng AI tốt, nhiều người không chỉ mua một tool. Họ phải thử:

  • ChatGPT
  • Gemini
  • Claude
  • các AI coding tool
  • các tool hỗ trợ diagram, prototype, note, search, agent workflow

Tức là để “không bị tụt lại”, người đi làm không chỉ phải giỏi hơn. Họ còn phải bỏ thêm thời gian và tiền để duy trì năng lực đó.

Lương chưa chắc tăng, nhưng kỳ vọng công việc lại tăng

Đây là chỗ mình nghĩ nhiều người đã cảm thấy rồi, chỉ là ít khi nói to ra.

AI phát triển không đồng nghĩa với việc lương trong ngành IT sẽ tăng tương ứng. Trong một số trường hợp, điều ngược lại còn có thể xảy ra:

  • công ty nghĩ rằng có AI rồi thì junior cũng phải làm được nhiều hơn trước
  • công ty nghĩ rằng một middle có thể gánh khối lượng gần bằng 1.5 người
  • công ty dùng AI như một lý do để siết cost hoặc tăng lương chậm hơn

Nói cách khác, năng suất có thể tăng nhưng phần chia lại cho người lao động chưa chắc tăng theo.

Thậm chí áp lực còn nặng hơn ở mấy chỗ sau:

  • deadline vẫn vậy nhưng tốc độ kỳ vọng cao hơn
  • số người không tăng nhưng khối lượng output tăng
  • lương giữ nguyên nhưng trách nhiệm rộng hơn
  • công việc cần ít thao tác tay hơn nhưng lại cần judgment tốt hơn

Mình nghĩ đây là lý do vì sao nhiều người trong IT hiện tại có cảm giác “AI giúp mình chạy nhanh hơn thật, nhưng cuộc sống không hề nhẹ hơn”.

Làm sản phẩm riêng có phải là lối thoát?

Nhiều người sẽ nghĩ: nếu đi làm công ty bị ép output như vậy, thôi tự làm sản phẩm riêng với AI có phải chủ động hơn không?

Theo mình, là có thể chủ động hơn ở vài điểm, nhưng không hẳn là khỏe hơn.

Điểm tích cực là:

  • build nhanh hơn trước
  • test idea rẻ hơn trước
  • không cần team lớn ngay từ đầu
  • có thể ra MVP nhanh hơn

Nhưng nút thắt bây giờ nằm ở chỗ khác: làm ra sản phẩm không còn là lợi thế đủ lớn nữa.

Chỉ cần nhìn vào Facebook hoặc các group về vibe coding, các bạn sẽ thấy sản phẩm được tạo ra liên tục:

  • landing page
  • app nhỏ
  • tool nội bộ
  • chatbot
  • SaaS đơn giản
  • automation mini cho một ngách rất hẹp

Minh họa làn sóng sản phẩm AI và cạnh tranh tăng

Điều đó làm cạnh tranh tăng lên rất nhiều. Nghĩa là:

  • build nhanh hơn không chỉ có mình bạn
  • ra MVP nhanh hơn không chỉ có mình bạn
  • thử idea rẻ hơn cũng không chỉ có mình bạn

Vậy nên nếu trước đây biết code là một rào cản mạnh, thì bây giờ rào cản đó đã thấp hơn. Lợi thế bắt đầu chuyển sang:

  • distribution
  • marketing
  • content
  • network
  • bán hàng
  • hiểu khách hàng và đi thị trường nhanh

Tức là làm sản phẩm riêng không phải là lối thoát tự động. Nó chỉ chuyển bài toán từ “mình có build được không?” sang “mình có cạnh tranh nổi không?”.

Vậy người đi làm IT nên nâng cấp gì trong giai đoạn này?

Mình không nghĩ giải pháp là chống lại AI. Chuyện đó không thực tế. Cái thực tế hơn là phải nhìn rõ: nếu AI trở thành mặc định, mình cần mạnh ở tầng nào để không bị kéo xuống vai trò chỉ còn làm những phần dễ bị thay thế nhất.

1. Biết dùng nhiều model, không chỉ một tool

Không phải biết ChatGPT là đủ. Nhiều lúc các bạn còn phải biết thêm:

  • Gemini
  • Claude
  • AI coding tools
  • các tool hỗ trợ research, note, prototype, diagram

Không phải để khoe dùng nhiều, mà để biết:

  • việc nào hợp model nào
  • model nào mạnh ở reasoning, model nào mạnh ở code, model nào hợp với viết tài liệu
  • khi nào nên dùng tool đơn lẻ, khi nào nên ghép workflow

Nếu chỉ biết một công cụ ở mức bề mặt, rất dễ dừng ở chỗ “hỏi cho vui”. Trong khi mặt bằng mới đòi hỏi dùng AI như một phần thực sự của công việc.

2. Biết xây workflow áp dụng AI và tăng tự động hóa

Đây là kỹ năng mình nghĩ sẽ ngày càng đáng giá.

Ví dụ:

  • BA biết dựng workflow từ meeting note -> summary -> draft requirement -> review checklist -> prototype outline
  • dev biết dựng workflow từ ticket -> plan -> code draft -> unit test -> review checklist
  • tester biết dựng workflow từ requirement -> draft test case -> edge case expansion -> review list -> automation suggestion

Sự khác biệt không còn chỉ là “biết prompt”. Sự khác biệt là biết biến AI thành quy trình lặp lại được.

3. Giữ năng lực review và ra quyết định

AI ra output nhanh, nhưng tốc độ không thay thế được judgment.

Thứ khó bị thay thế hơn vẫn là:

  • chọn hướng đúng
  • thấy rủi ro
  • phát hiện lỗ hổng logic
  • ưu tiên đúng việc
  • biết chỗ nào không nên tin output của AI

Ở đây, người đi làm nào quá phụ thuộc AI nhưng không giữ năng lực review thì rất dễ rơi vào trạng thái ra output nhanh nhưng chất lượng không bền.

4. Giữ domain knowledge và communication như lợi thế dài hạn

Mình nghĩ đây là hai thứ càng ngày càng quan trọng:

  • hiểu domain thật
  • giao tiếp đủ rõ để align được người khác

Vì khi mọi người đều tạo output nhanh hơn, thứ tạo khác biệt sẽ là:

  • ai hiểu bài toán thật hơn
  • ai đặt câu hỏi đúng hơn
  • ai nhìn ra impact thật sự
  • ai khiến team ra quyết định nhanh hơn mà vẫn đúng hướng

Nói ngắn gọn, AI làm cho phần “sản xuất bản nháp” rẻ đi. Nhưng phần “hiểu đúng vấn đề và chốt được hướng đi tốt” lại càng đáng giá hơn.

Kết bài

Mình vẫn nghĩ AI là một công cụ rất mạnh, và nếu biết dùng thì nó giúp ngành IT chạy nhanh hơn thật.

Nhưng nếu nhìn ở góc độ người lao động, câu chuyện không chỉ là “làm nhanh hơn”. Nó còn là:

  • bị kỳ vọng nhiều hơn
  • phải học nhiều hơn
  • phải tự review nhiều hơn
  • phải rộng vai hơn
  • phải cạnh tranh với nhiều người hơn
  • và đôi khi còn phải tự bỏ thêm tiền để theo kịp cuộc chơi

Vậy nên nếu hỏi AI có đang làm ngành IT khắc nghiệt hơn không, thì câu trả lời của mình là: có, ít nhất là ở góc độ áp lực, mặt bằng kỳ vọng và mức độ cạnh tranh.

Điều còn lại không phải là né AI, mà là phải chủ động hơn trong cách dùng nó, trong cách xây workflow, và trong việc giữ những năng lực mà AI chưa thể thay mình gánh trách nhiệm cuối cùng.

Hoang Phan

Author: hoangphan

Hoàng xuất phát là dân kỹ thuật phần mềm, tham gia mảng phát triển phần mềm từ 2017 đến nay. Mình muốn mang những trải nghiệm cá nhân chia sẻ đến anh em, từ đó anh em thấy gì hay thì có thể tham khảo sử dụng, mà dỡ thì anh em góp ý giúp nhé.  

Leave a Reply

Your email address will not be published.

You may use these <abbr title="HyperText Markup Language">html</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*