Tôi là một software engineer, năm nay tròn 10 năm kinh nghiệm. Tôi bắt đầu sự nghiệp với web frontend (hồi đó debug frontend dễ hơn với tôi, nên tôi chọn hướng đó), rồi nhanh chóng chuyển sang web backend và không quay lại.
Qua một loạt cơ duyên, sau khi vào backend, tôi làm việc trong các domain liên quan tới finance, bookkeeping và payment processing — nơi tôi có nhiều quyền tự chủ và quan hệ thẳng thắn với Product Manager cũng như stakeholders.
Tôi học được rất nhiều về domain và cách viết phần mềm cho nó: PCI compliance, double-entry ledger, escrow, reconciliation, payment lifecycle, bank transfer idempotency, v.v.
Việc tập trung trở thành chuyên gia về domain này, theo tôi lúc đó, là hiển nhiên — để nổi bật trong một ngành mà nhu cầu specialist đang tăng.
Trụ cột thứ nhất bị xói mòn: chuyên môn domain
Năm ngoái tôi vào một công ty finance — khác với các công ty cũ vốn chỉ có payment/finance là một phần, công ty này thuần finance.
Họ ôm AI rất nhiệt tình: tôi nhận tài khoản ChatGPT và Claude Enterprise từ ngày đầu tiên, được khuyến khích dùng cho research, exploration, kể cả coding — kèm cảnh báo rằng vẫn phải review và chịu trách nhiệm cho từng dòng vào production.
Một trong những project đầu của tôi là viết lại legacy online payment system — một mớ hỗn độn. Họ thuê tôi (một phần) vì kinh nghiệm trước đó của tôi với hệ thống tương tự.
Công ty này yêu cầu “Design Doc” viết trước khi code phải đọc được bởi cả engineer lẫn product manager — không đi sâu kỹ thuật, mà mang góc nhìn kiến trúc. Bản đầu tôi viết gần như không dùng AI (lúc đó tôi còn gọi LLM là “stochastic parrot” — quan điểm tôi giờ đã bỏ) và submit.
Tôi tin vào kiến thức mình và nghĩ không LLM nào thay thế được.
Rồi manager gọi: code anh ship tốc độ tốt đấy, nhưng Design Doc viết quá chậm. Anh có dùng AI không? Anh nên dùng nhiều hơn.
“Không đời nào ăn thua”, tôi nghĩ, nhưng vẫn đồng ý. Models thời đó chưa tốt như bây giờ, nhưng cũng cho speed-up đáng kể cho việc viết, kể cả ra quyết định.
Và tôi bắt đầu nhận ra: toàn bộ kiến thức tôi tích lũy qua năm tháng — trade-off giữa các implementation, cách acquiring hoạt động, cách structure idempotency để chống double-charge, tất cả — đang trở thành vô dụng. Models vẫn cần steering, nhưng đã nối được các điểm về cách kiến trúc những hệ thống như vậy, vốn là phần khó nhất, chỉ phát triển trong não bạn sau nhiều năm trải nghiệm thực. Đó là cú sốc đầu tiên của tôi.
Nhưng thôi, tôi nghĩ — chúng làm được vì có cả tỷ bài viết về cách những thứ đó hoạt động, kèm technical documentation và blog post giải thích cách áp dụng. Với con người mất nhiều năm để học, nhưng đó là training data nên models nhặt nhanh.
Cái models sẽ không bao giờ giỏi, nơi con người vẫn tỏa sáng, là debug! Tôi có kinh nghiệm debug race condition và distributed system trong production. Đó là tấm vé long-term employability của tôi.
Trụ cột thứ hai bị xói mòn: debug và distributed systems
Sau khi LLM viết được docs và giúp plan implementation, chúng bắt đầu giỏi coding. Hype Claude Code nửa cuối 2025, rồi Codex, rồi loạt khác. Dù trước đó tôi dùng LLM viết unit test hàng ngày, tôi chưa tin chúng viết full implementation.
Bước tiếp theo tự nhiên là kéo AI vào việc viết code. Thật ra tôi thấy thích. Tôi thích ship sản phẩm lên production và thấy users vui ngang việc thích coding, nên đổi một cái mình thích lấy cái mình cũng thích — fair thôi.
LLM giỏi code nhưng vẫn chưa debug được mớ hỗn độn nó (hoặc con người) để lại, nên vai trò tôi vẫn lớn hơn việc lái robot — vẫn còn vé employability.
Mọi thứ tưởng ổn.
Rồi MCP, agentic workflow và Claude 4.5 đến, và trời bắt đầu sụp.
Claude 4.5 nói thật chưa tốt lắm. Solve khoảng 60% bug nếu cho stack trace và context (một Sentry link với Sentry MCP enabled là đủ trong hầu hết case). Đôi khi đưa solution nghe có lý nhưng hoàn toàn sai.
Nhưng lần này tôi không còn nghi ngờ máy nữa. Tôi thấy những bug ngày xưa mất full 1 ngày debug giờ bị one-shot bởi Claude Code. Tất nhiên chưa phải tất cả ngay lúc này, nhưng pattern đã rõ.
Rồi 4.6, 4.7, GPT 5.5, Opus 4.8, DataDog MCP… Giờ tôi có CLI one-shot bug xuyên distributed systems. Bug mà trước đây tôi không solve được. Bug mà lẽ ra mất 2 ngày full-time debug. Bug xuyên distributed systems thiếu distributed observability. 90% bug giờ bị one-shot, kể cả race condition kỳ quái, corner-case bất ngờ, third-party integration issue, undocumented API edge case — đủ cả. Tôi gần như không cần can thiệp.
Tất nhiên tôi vẫn employable vì cần ai đó review code và steer robot. Nhưng giờ tôi chỉ là một off-the-shelf engineer. Không còn domain expertise nào mà một Sr. engineer khác đang steer LLM không match được. Toàn bộ finance/payment expertise của tôi, toàn bộ intuition về debug và distributed system tích lũy qua mồ hôi nước mắt — giờ đã promptable.
Người ta dạy chúng ta generalist và specialist đều có chỗ. Nhưng giờ thị trường đang nhào nặn mọi người thành generalist. Không xấu per se, cho đến khi nhìn vào kinh tế cung-cầu: nếu ai cũng là generalist, giá generalist sẽ giảm nếu không có demand tương xứng. Và chúng ta đều biết demand đang khô cạn.
Trụ cột thứ ba — chưa xói mòn: code quality và architecture
Tôi còn một trụ cột đứng vững: code quality và software architecture — cái giờ bị quy gọn thành “taste”.
Suốt sự nghiệp, tôi luôn thích refactor, luôn trân trọng code tốt, luôn đàm phán thời gian trong sprint cho nó. DDD, Hexagonal, Clean Architecture — biết hết. Tôi thích chủ đề này, thích bàn về trade-off và các idea khác nhau về cách shape codebase. Tôi thực sự thích.
Đây là trụ cột cuối cùng. Trừ việc không ai còn quan tâm.
Agent làm việc khá tệ trong giữ codebase gọn gàng. Nếu không steer, chúng sẽ vướng circular dependency sớm hơn bạn nghĩ. Sẽ duplicate code. Thêm comment vô nghĩa. Trộn pure function với side-effect. Bỏ qua nguyên tắc SOLID.
Đáng lẽ chuyện đó giúp con người còn việc làm. Trừ việc kỹ năng này giờ bị quy thành “taste”. Và không chỉ đổi tên — ngành đang chuyển sang thế giới nơi code organization ít quan trọng hơn.
Đúng, con người vẫn nên steer agent để tránh codebase spaghetti với dependency graph rối. Không ai muốn codebase rated F — đụng vào là vỡ. Nhưng C hay D? Giờ ok. Không ai cần codebase A hay B nữa, vì chúng giờ viết cho LLM, không phải cho con người đọc.
Tôi không tranh luận chuyện này tốt hay xấu. Nếu source code giờ viết cho máy đọc chứ không phải người, thì target máy có khi lại đúng.
Nhưng đó lại là một trụ cột nữa của expertise tôi đang bị xói mòn. Một mảng lớn kiến thức tôi tích lũy về chủ đề này không còn giá trị mấy. Toàn bộ thời gian tôi bỏ ra — đọc sách, làm bài tập thực tế, bàn luận với engineer khác, viết ADR — đang trở nên vô dụng.
Giờ thì sao?
Tôi vẫn có việc và thấy mình vẫn có việc (ít nhất ở công ty này) trong tương lai gần. Nhưng tôi không biết phải nghĩ gì về long-term.
Tôi mất 10 năm (hơn nếu tính cả kinh nghiệm phi-chuyên-nghiệp) để giỏi những thứ đang ngày càng mất giá. Trụ cột cuối cùng của expertise giờ bị quy thành “taste” và chắc cũng không trụ được lâu.
Và tôi biết không chỉ tôi. Khoảng 8 tháng trước có đợt layoff ở công ty hiện tại (họ nói không liên quan AI). Vài ex-coworker xuất sắc bị cho nghỉ, đến giờ vẫn đang tìm việc. Đa số gặp đúng vấn đề tôi vừa nói: domain expertise của họ không đủ để stand out nữa.
Công ty giờ hiring lại cho vài vị trí, và domain familiarity không còn là differentiator mạnh. Trước kia ghi “Software Engineer - Area”. Giờ chỉ ghi “Software Engineer” — assignment team đến sau khi nhận offer.
Tất nhiên điều này tốt cho những engineer xuất sắc chưa có cơ hội đào sâu domain, giờ có cơ hội tốt hơn để có việc. Nhưng cũng buồn khi nghĩ những engineer xuất sắc khác đã dành cả đời tích domain knowledge giờ phải tranh cùng một làn đường.
Cách duy nhất để giữ employability long-term có vẻ là dịch chuyển domain expertise sang thứ LLM khó giỏi sớm. Nhưng còn gì để chọn?
Tôi đã nghĩ tới việc quay lại đại học, học Toán, Statistics, Machine Learning nâng cao, rồi apply role research ở một frontier lab. Trừ chuyện không có frontier lab nào ở nước tôi, vài lab tồn tại thì đang ngập đơn, và tôi có chuyện gia đình khiến việc chuyển nước khác khó khăn. Đến lúc tôi đủ điều kiện nhảy, có khi RSI đã làm researcher cũng trở nên lỗi thời.
Có lẽ tôi nên cân nhắc biến hobby mộc của mình thành nghề chính…