#270 - Sự dịch chuyển về kỳ vọng
Thích nghi với AI không dừng lại ở việc làm chủ công cụ, mà là nâng cấp tiêu chuẩn đầu ra của chính mình. Bài viết phân tích những 'kỳ vọng' đang dịch chuyển âm thầm tác động lên mọi vài trò khác nhau
Chào các bạn, tiếp nối số trước Grokking chúng mình đã đề cập đến các góc nhìn và về việc AI ảnh hưởng chung đến các lĩnh vực, cũng như giới công nghệ nói riêng, nơi áp dụng AI chủ động và tích cực nhất nhưng cũng là nơi đang chịu ảnh hưởng đầu tiên và mạnh mẽ nhất.
Trong số này, chúng mình mong muốn đưa thêm một góc nhìn xoay quanh việc ảnh hưởng cụ thể vào yếu tố nào và ảnh hưởng ra sao đối với những vai trò khác nhau trong giới công nghệ. Khi AI trở thành công cụ để khuếch đại khả năng của kĩ sư, đánh đổi là điều không tránh khỏi.
Cụ thể hơn, trong một báo cáo tổng hợp bởi AppKnox gần đây - AI and Developer Burnout Report 2025, báo cáo đề cập tới việc AI tái định hình (reshape) tính chất công việc, và cũng như cả định nghĩa về quá tải (burnout) kèm theo sự xuất hiện một dạng căng thẳng mới - cognitive and emotional burnout.
Từ việc được sở hữu công cụ mới, tốt hơn, nhanh hơn, đến việc xuất hiện dạng căng thẳng mới, liệu anh em kĩ sư đã có dịp nhìn lại yếu tố gì đang thay đổi thầm lặng như con sóng ngầm? Thay vì mải cố gắng theo đuổi để làm chủ/điều khiển công cụ mới này?
Theo góc nhìn của mình, sự kỳ vọng - sự kỳ vọng giữa stakeholders với kĩ sư, giữa sếp và team, cũng như giữa các thành viên trong team - là tác nhân chính, gốc rễ đang tái định hình ngành công nghiệp phần mềm, để dân công nghệ thích nghi và phát triển như đề cập ở các số trước. Dưới đây là một số bài viết và báo cáo có liên quan, để làm rõ kỳ vọng đã và đang dịch chuyển ra sao.
The Productivity Paradox of AI
1. Nghịch lý Jevons: Càng hiệu quả, càng... tốn kém
A look at how Jevons’ 19th-century paradox is playing out in modern code — where every leap in efficiency creates more developers, not fewer.
Bài viết vận dụng “Nghịch lý Jevons” để phản biện nỗi lo AI sẽ thay thế lập trình viên. Lịch sử cho thấy khi công nghệ giúp tăng năng suất và giảm chi phí (như động cơ hơi nước hay Cloud computing), nhu cầu tiêu thụ lại bùng nổ. Tương tự, khi AI giúp viết code nhanh và rẻ hơn, thế giới sẽ không cắt giảm nhân sự, mà sẽ xây dựng số lượng phần mềm khổng lồ hơn bao giờ hết.
2. Sự tiến hóa: Từ "Viết code" sang "Điều phối"
Atlassian’s internal data shows engineers spend only 16% of their week actually coding. The rest goes to coordination, debugging, testing, deployment, and documentation — areas now ripe for AI augmentation.
AI đang “dân chủ hóa” việc lập trình: nó hạ thấp rào cản gia nhập nhưng lại nâng cao tiêu chuẩn về sự xuất sắc. Sẽ không mất nhiều thời gian để một người mới gia nhập thị trường nhờ được hỗ trợ loại bỏ các “overhead” trong ngành (ví dụ kiến thức ngôn ngữ lập trình, vận hành hệ thống, deploy ứng dụng,…) nhưng sẽ cần làm quen với tư duy “nhạc trưởng” sớm hơn bao giờ hết.
3. Tương lai của tuyển dụng
According to LinkedIn’s 2025 Emerging Jobs Report, demand for AI-fluent software engineers has surged nearly 60% year-over-year, and Glassdoor data shows compensation premiums of 15–25% for developers proficient in AI frameworks and orchestration tools. The emergence of this new breed of engineer reflects a profound shift in leverage: the ability to command AI as an extension of one’s own reasoning.
Các bài phỏng vấn thuật toán truyền thống sẽ dần lỗi thời. Thay vào đó, thị trường sẽ tìm kiếm những kỹ sư biết cách tận dụng AI làm đòn bẩy để giải quyết bài toán thực tế hiệu quả. Về vấn đề này chúng mình cũng đã có đề cập chi tiết hơn tại đây.
Tóm lại, vẫn là điều anh em kĩ sư “động viên nhau”, AI đang mở ra một kỷ nguyên mới nơi tư duy hệ thống và khả năng thích ứng quan trọng hơn kỹ năng gõ code đơn thuần.
Where Architects Sit in the Era of AI
Bài viết đưa ra góc nhìn cụ thể hơn cho một vị trí, mà đối với cá nhân mình, tưởng chừng là người ít bị ảnh hưởng, thậm chí còn giá trị còn được tăng lên cao - Architects.
What does it mean to be an architect when architectural thinking can be automated?
Một câu hỏi nêu ra trong bài đã khiến mình “goosebumped”, điều chỉ 5-6 tháng trước còn là khoảng gap giữa senior engineers/architects với AI giờ đã được bắt kịp với các mô hình thinking mạnh mẽ từ các ông lớn công nghệ.
1. Sự chuyển dịch: tái định nghĩa như là một “Meta-designer”
Thay vì trực tiếp thiết kế mọi thứ như trước đây, thông qua các cuộc họp và buổi brainstorm cùng cộng sự, Architect sẽ chuyển sang vai trò điều phối các AI agents thông qua mô hình “3 Vòng lặp”:
In the Loop: Cộng tác song song. AI đưa ra các phương án, con người ra quyết định cuối cùng.
On the Loop: AI tự vận hành trong giới hạn cho phép. Architect đóng vai trò giám sát và can thiệp khi cần thiết.
Out of the Loop: AI tự chủ hoàn toàn. Architect tập trung thiết kế các cơ chế quản trị và an toàn.
2. Những cái bẫy mới: Sự thui chột và Ảo giác
Quyền năng của AI đi kèm với những rủi ro chí mạng cho nghề nghiệp:
Skill Atrophy: Quá phụ thuộc vào AI sẽ làm mòn “trực giác” và “kiến thức ngầm” – những kinh nghiệm xương máu không có trong sách vở, được tích luỹ bơi quá trình làm việc lâu năm từ những Architects dày dặn.
Sự tự tin giả tạo: AI có thể đưa ra thiết kế sai lầm với giọng điệu vô cùng chắc chắn. Văn hóa làm việc cần chuyển từ “tin tưởng” sang “thẩm định” (verification).
Dù bài viết đề cập phần lớn đến level Architects, dưới góc nhìn là một kĩ sư Senior-level, mình thấy có một sự liên hệ mật thiết đến công việc hằng ngày, nơi đã có nhiều lúc trực giác phát huy hiệu quả ở những thời điểm mình nghi ngờ ý kiến của AI dù chưa đủ kinh nghiệm để chỉ mặt đặt tên sự nghi ngờ đó.
DORA Report 2024/2025 (Google Cloud)
Bên cạnh các thống kê về sự áp dụng (adoption) và hiệu suất làm việc (productivity), báo cáo đề cập tới 3 kiểu “kỳ vọng” mới:
1. AI cải thiện tốc độ (throughput) nhưng làm tăng sự bất ổn (instability)
So với báo cáo năm trước, AI đã bắt đầu giúp tăng tốc độ phân phối phần mềm, nhưng nó cũng đi kèm với việc gia tăng tỷ lệ lỗi hoặc sự cố khi triển khai, cho thấy các hệ thống cơ bản chưa kịp thích nghi.
AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development.
2. Cần đầu tư vào hệ thống tổ chức để gặt hái thành quả từ AI
Lợi nhuận từ đầu tư AI không đến từ bản thân công cụ, mà từ việc cải thiện hệ thống nền tảng, quy trình và sự liên kết của đội ngũ.
“The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams.”
3. AI chưa giúp giảm áp lực (Burnout) hay sự ma sát (Friction) trong công việc
Mặc dù AI tăng năng suất cá nhân, nhưng nó không (hoặc chưa) giúp giảm bớt sự kiệt sức hay những rào cản trong quy trình làm việc nếu văn hóa và hệ thống không thay đổi.
“Despite all the benefits, friction remains unaffected, burnout stays flat, and delivery instability rises—unless the surrounding system and culture changes.”
Góc nhìn tác giả
Từ những bài viết và thống kê, ta có thể thấy rằng việc thích nghi trong thời gian tới không chỉ về thích nghi với công nghệ, công cụ mới mà còn để thích nghi với kỳ vọng mới. Thích nghi là hiểu rằng “luật chơi” đã thay đổi. Sếp của bạn, khách hàng của bạn, và cả team của bạn đang âm thầm thay đổi tiêu chuẩn đánh giá về một việc làm “xong” (definition of done).
Kết hợp với quan sát cá nhân và vốn kinh nghiệm ít ỏi đang có, mình có thể gói gọn một số “luật chơi” đã và đang dịch chuyển đối với:
1. Interns/Junior
Trước đây, Junior được phép sai sót cú pháp, được phép chậm để nghiên cứu, để làm quen công cụ. Đó là những giá trị bề nổi (explicit) mà tổ chức từng chấp nhận trả phí để bạn học.
Nhưng nay, AI đã làm những việc đó tốt hơn, nhanh hơn và rẻ hơn bất kỳ Junior nào. AI có thể giúp triển khai một tính năng hay thậm chỉ cả một framework trong 30 phút, nhưng liệu những dòng code đó có chứa lỗ hổng logic nào không? Có dễ maintain hay không? Hay chúng đang trở thành tech debt từ khi vừa được commit?
Kỳ vọng của Seniors dành cho bạn đã thay đổi:
Trước đây: “Em implement tính năng này chưa? Có khó khăn nào trong lúc triển khai không?”
Bây giờ: “Em có hiểu tại sao AI lại chọn thư viện này thay vì thư viện kia không? “Em có tin nó không hallucinate hàm này không?” Hay: “Mình còn cách nào khác tốt hơn không?”
Mấu chốt nằm ở chỗ, Juniors thường vẫn sẽ không được kỳ vọng làm nhanh hơn, trước đây có 4 tiếng bao gồm 3 tiếng để code và 1 tiếng test - bây giờ vẫn 4 tiếng: 30 phút code, 30 phút test thì dùng 3 tiếng còn lại như thế nào, ngồi chơi hay tự phản biện?
2. Senior Engineers
Khi khoảng cách về tốc độ viết code giữa Senior và Junior đang thu hẹp lại, tại sao công ty vẫn cần trả lương cao cho Senior?
Senior không còn được trả lương để thể hiện kỹ năng giải thuật hay triển khai hệ thống phức tạp. Họ được kỳ vọng để nói "KHÔNG".
Nói không khi được yêu cầu một loạt thay đổi trong thời gian ngắn, vì họ cần biết họ có thể và không thể kiểm soát được những chuyện gì sẽ xảy ra.
Nói không khi có một thay đổi cần được xác nhận yếu tố lịch sử hay ngữ cảnh, vì khi AI đã có sức mạnh thu thập những thông tin bề nổi (explicit), thì ngữ cảnh lịch sử (implicit) là những thứ sẽ được Seniors nắm rõ nhất.
Hay, như ở bài viết về Architects ở trên, nói không khi trực giác của người làm trong ngành “mách bảo”.
Lưu ý: việc nói không một cách khéo léo không đơn giản, hi vọng chúng mình sẽ có dịp đề cập tới ở các số sau.
3. Managers
Có lẽ đây là phần khó nhất, khi những gì mình quan sát hay nghe và đọc được cũng vẫn chỉ là bề nổi, và cũng chưa đủ kinh nghiệm để đánh giá toàn bộ bức tranh hay phần tảng băng chìm. Do đó, có thể sẽ nghe khá chung chung và mình chấp nhận điều đó.
Đây là vị trí chịu áp lực gọng kìm, từ sự thay đổi chóng mặt về công nghệ, tốc độ deliver của đội ngũ, đến kỳ vọng về chất lượng và thời gian đến từ bên ngoài. Sự chuyển dịch về kỳ vọng kéo theo mối quan tâm không còn nhiều về tiến độ, mà về rủi ro đối với công nghệ và con người.
Kỳ vọng nền (baseline) về chất lượng sản phẩm của team được nâng lên, code được commit và deploy liên tục, AI có thể đưa ra quyết định về mặt kiến trúc, vậy làm sao để thiết lập các "Guardrails" (hàng rào bảo vệ) để đảm bảo team không biến thành những công nhân đi dọn rác cho AI về sau?
Khi kỳ vọng về work rate (lượng công việc của team trong đơn vị thời gian) cũng được nâng lên nhờ có AI hỗ trợ, lúc này liệu “đảm bảo kịp tiến độ” có còn tập trung chính của Manager? Hay giờ đây kỳ vọng lên người quản lý dịch chuyển thành người giữ nhịp độ, đảm bảo các mắt xích về con người vận hành bền bỉ, chính xác, không bị kiệt quệ?
(trước đây Grokking cũng đã có một bài viết về Một tuần làm việc của Engineering Manager, mình cũng tự hỏi liệu sau những biến động từ AI, câu chuyện đã khác hơn bao nhiêu phần trăm?)
Kết: có vẻ khi máy móc đang tự làm tốt dần khả năng của chính nó, chúng ta cũng cần làm tốt những gì mặt con người cần làm? cô đọng từ ví dụ trên: sự hoài nghi (junior), thấu hiểu ngữ cảnh (senior) và quản trị rủi ro (manager).
— sudo — ngồi nhìn SQL hằng ngày
Một bài viết dài cho số #270 để kết lại năm 2025, để có một góc nhìn trực diện về kỳ vọng đã thay đổi mà có thể hằng ngày mình vô tình chưa đề cập thẳng thắng với nhau.
Cảm ơn mọi người đã đọc đến đây.
Chúc mọi người có một kì nghỉ giáng sinh tĩnh lặng cho một năm mới sẵn sàng.
What is essential is invisible to the eye