Khi LLM "ăn" mòn sự nghiệp kỹ sư phần mềm: Tôi nên làm gì?

Tôi là một kỹ sư phần mềm và năm nay đánh dấu cột mốc 10 năm kinh nghiệm chuyên nghiệp của tôi. Tôi bắt đầu sự nghiệp với tư cách là một kỹ sư frontend web, nhưng nhanh chóng chuyển sang backend và chưa từng nhìn lại.

Mô phỏng trí tuệ nhân tạo

Thông qua một chuỗi sự tình cờ, khi bước chân vào phát triển backend, tôi đã làm việc trong các vai trò phát triển phần mềm thuộc lĩnh vực tài chính, kế toán và xử lý thanh toán. Tại đây, tôi có quyền tự chủ cao và mối quan hệ thân thiết, cởi mở với các Quản lý sản phẩm (Product Managers) và các bên liên quan.

Tôi đã học được rất nhiều về lĩnh vực này và cách viết các chương trình hiệu quả cho nó: tuân thủ PCI, sổ cái kép (double-entry ledgers), ký quỹ (escrows), đối soát, vòng đời thanh toán, tính nhất quán của chuyển khoản ngân hàng, v.v. Rõ ràng, tôi nên tập trung sự nghiệp của mình để trở thành một chuyên gia trong lĩnh vực này để nổi bật giữa các đồng nghiệp.

Trụ cột đầu tiên bị sụp đổ: Kiến thức chuyên ngành

Năm ngoái, tôi được tuyển dụng bởi một công ty hoạt động trong lĩnh vực tài chính. Công ty này cũng đón nhận AI một cách nồng nhiệt, nên tôi được cấp tài khoản ChatGPT và Claude Enterprise ngay từ ngày đầu tiên và được khuyến khích sử dụng chúng cho nghiên cứu, khám phá và thậm chí là viết mã.

Một trong những dự án đầu tiên của tôi liên quan đến việc cải tạo lại hệ thống thanh toán trực tuyến cũ kỹ, vốn đang rất lộn xộn. Họ thuê tôi vì kinh nghiệm trước đây của tôi trong việc xây dựng hệ thống như vậy.

Khác với các công ty khác mà tôi từng làm việc, họ muốn các "Tài liệu thiết kế" (Design Docs) mà tôi viết trước khi viết mã phải có thể đọc được bởi cả kỹ sư và quản lý sản phẩm — nghĩa là không nên là một bài đi sâu vào kỹ thuật mà nhiều hơn là một góc nhìn kiến trúc. Tôi đã viết tài liệu đầu tiên với sự hỗ trợ tối thiểu của AI và giao nó.

Tôi trân trọng kiến thức của mình và nghĩ rằng không LLM nào có thể thay thế được nó.

Sau đó, quản lý của tôi liên hệ với tôi: mặc dù bạn đang giao mã với tốc độ tốt, nhưng bạn đang mất quá nhiều thời gian để giao các Tài liệu thiết kế. Bạn có đang sử dụng AI không? Bạn nên sử dụng AI nhiều hơn.

"Không thể nào chuyện này lại hiệu quả được", tôi nghĩ thầm trong đầu, nhưng đồng ý. Các mô hình lúc đó không tốt như những gì chúng ta có bây giờ, nhưng chúng thực sự cung cấp một sự tăng tốc tốt cho việc viết của tôi và thậm chí cả việc ra quyết định.

Và sau đó tôi bắt đầu nhận ra: tất cả kiến thức tôi đã tích lũy qua nhiều năm — sự đánh đổi giữa các cách triển khai, cách hoạt động của việc mua lại, cách cấu trúc tính nhất quán để ngăn chặn tính phí trùng, mọi thứ — đang trở nên vô dụng. Mặc dù các mô hình vẫn cần một chút điều hướng, nhưng chúng có thể kết nối các điểm về cách cấu trúc các hệ thống như vậy, điều từng là phần khó nhất chỉ phát triển trong não bộ sau nhiều năm kinh nghiệm thực tế. Đó là cú sốc đầu tiên của tôi.

Nhưng chắc chắn rồi, tôi nghĩ, chúng có thể làm điều đó vì có rất nhiều bài viết trên web về cách những thứ đó hoạt động cùng với tất cả tài liệu kỹ thuật. Đối với con người, có thể mất nhiều thời gian để học tất cả những điều đó, nhưng đó là dữ liệu huấn luyện nên các mô hình có thể tiếp thu nó.

Những thứ mà mô hình sẽ không bao giờ giỏi, và đó là nơi con người sẽ tỏa sáng, chính là gỡ lỗi (debugging)! Tôi đã tích lũy được nhiều kinh nghiệm trong việc gỡ lỗi các tình trạng tranh chấp tài nguyên (race conditions) và hệ thống phân tán trong môi trường sản xuất. Đó là tấm vé đảm bảo việc làm lâu dài của tôi.

Trụ cột thứ hai bị sụp đổ: Gỡ lỗi và hệ thống phân tán

Vì vậy, sau khi LLM bắt đầu giỏi viết tài liệu và giúp lập kế hoạch triển khai thực tế, chúng trở nên giỏi viết mã. Nó bắt đầu vào nửa sau năm 2025 với cơn sốt Claude Code, sau đó Codex ra đời, v.v. Mặc dù tôi đã sử dụng LLM để viết bài kiểm tra đơn vị (unit tests) mỗi ngày trước đó, tôi chưa tin tưởng chúng để viết toàn bộ triển khai.

Bước tiếp theo tự nhiên là đưa nhiều AI hơn vào việc viết mã. Và một cách trung thực, tôi thích điều đó. Tôi thích đưa sản phẩm đến môi trường sản xuất và thấy người dùng hài lòng giống như tôi thích viết mã, vì vậy tôi đang đánh đổi một điều tôi thích lấy một điều khác mà tôi cũng thích, đó là công bằng.

LLM đang trở nên giỏi viết mã, nhưng nó vẫn không thể gỡ lỗi sự lộn xộn để lại (bởi nó hoặc bởi con người), vì vậy tôi vẫn có một vai trò lớn hơn là việc điều hướng con robot — một tấm vé để có việc làm.

Mọi thứ dường như ổn thỏa.

Sau đó đến MCPs (Model Context Protocol), quy trình làm việc tác tử (agentic workflows) và Claude 4.5, và bầu trời bắt đầu sụp đổ.

Màn hình làm việc với mã nguồn

Thành thật mà nói, Claude 4.5 không quá xuất sắc. Nó giải quyết được khoảng 60% lỗi khi được cung cấp stack trace và một số ngữ cảnh (một liên kết Sentry với Sentry MCP được bật là tất cả những gì cần thiết trong hầu hết các trường hợp). Đôi khi nó đưa ra giải pháp nghe có vẻ hợp lý nhưng hoàn toàn sai.

Lần này, tuy nhiên, tôi ngừng nghi ngờ máy móc. Tôi đã thấy những lỗi mà trong quá khứ sẽ dễ dàng mất 1 ngày gỡ lỗi toàn thời gian được Claude Code giải quyết ngay lập tức. Tất nhiên, chưa phải tất cả, nhưng mô hình thì rõ ràng.

Sau đó đến 4.6, 4.7, GPT 5.5, Opus 4.8 và DataDog MCP... Bây giờ tôi có các CLI giải quyết lỗi ngay lập tức trên các hệ thống phân tán cho tôi. Những lỗi mà tôi không thể giải quyết trong quá khứ. Những lỗi sẽ mất 2 ngày gỡ lỗi toàn thời gian. Những lỗi trên các hệ thống phân tán thiếu khả năng quan sát (observability). 90% lỗi được giải quyết ngay lập tức, bao gồm cả các tình trạng tranh chấp kỳ lạ, các trường hợp góc không mong muốn, vấn đề tích hợp bên thứ ba, các trường hợp góc của API không có tài liệu, mọi thứ. Tôi hiếm khi phải can thiệp.

Tất nhiên, tôi vẫn có thể làm việc vì ai đó phải xem xét mã và điều hướng con robot. Nhưng bây giờ tôi chỉ là một kỹ sư phổ thông ngoài thị trường. Tôi không có kiến thức chuyên ngành nào mà một kỹ sư cấp cao khác điều hướng LLM không thể sánh bằng. Tất cả chuyên môn tài chính và thanh toán của tôi, tất cả trực giác gỡ lỗi và kiến thức hệ thống phân tán kiếm được bằng mồ hôi và nước mắt, giờ đây đều có thể được đưa vào câu lệnh (prompt).

Chúng ta được dạy rằng các nhà tổng quát và chuyên gia sẽ luôn có vai trò của họ. Nhưng bây giờ thị trường đang định hình mọi người trở thành những nhà tổng quát. Điều đó vốn dĩ không xấu, cho đến khi bạn nhìn dưới góc độ kinh tế của cung và cầu: nếu mọi người đều là nhà tổng quát, giá của một nhà tổng quát sẽ giảm nếu không có cầu để phù hợp. Và chúng ta đều biết rằng cầu đang cạn kiệt.

Trụ cột thứ ba, cái chưa bị sụp đổ: Chất lượng mã và kiến trúc

Tôi vẫn còn một trụ cột đứng vững, mặc dù: chất lượng mã và kiến trúc phần mềm — thứ mà hiện nay đang bị giảm xuống còn được gọi là "gu thẩm mỹ" (taste).

Trong suốt sự nghiệp của mình, tôi luôn thích tái cấu trúc (refactor), luôn đề cao mã tốt và thương lượng thời gian trong sprint cho việc đó. DDD, Hexagonal, Clean Architecture, bạn biết tất cả những từ ngữ thông dụng đó. Tôi thích chủ đề này, tôi thích thảo luận về sự đánh đổi và các ý tưởng khác nhau về cách định hình các cơ sở mã. Tôi thực sự thích nó.

Đây là trụ cột cuối cùng còn đứng vững. Ngoại trừ rằng giờ không ai còn quan tâm nữa.

Các tác tử (agents) làm việc rất tệ trong việc giữ cho cơ sở mã được tổ chức. Nếu bạn không điều hướng chúng, chúng sẽ gặp vấn đề phụ thuộc vòng tròn sớm hơn bạn nghĩ. Chúng sẽ trùng lặp mã. Thêm các bình luận không cần thiết. Trộn lẫn các hàm thuần túy và tác dụng phụ. Bỏ qua các nguyên lý SOLID.

Điều đó lẽ ra nên giữ cho con người có việc làm, ngoại trừ rằng kỹ năng này hiện đang bị giảm xuống thành từ "gu thẩm mỹ". Nhưng không chỉ là đổi tên, ngành công nghiệp đang chuyển sang một thế giới nơi việc tổ chức mã ít quan trọng hơn.

Chắc chắn, con người nên điều hướng tác tử để ngăn chặn các cơ sở mã kiểu spaghetti với đồ thị phụ thuộc vòng tròn. Chúng ta không muốn các cơ sở mã xếp loại F mà không thể chạm vào mà không làm hỏng thứ gì đó. Nhưng một loại C hoặc D? Giờ thì ổn rồi. Không ai cần các cơ sở mã xếp loại A hoặc B nữa vì chúng được tạo ra cho LLM, không phải để con người đọc.

Tôi không muốn tranh luận liệu điều này vốn dĩ tốt hay xấu. Nếu mã nguồn hiện nay được viết để máy móc đọc chứ không phải con người, việc nhắm đến chúng có thể thực sự ổn.

Nhưng đó là một trụ cột chuyên môn khác của tôi đang bị xói mòn. Một phần lớn kiến thức tôi tích lũy về chủ đề này không còn giá trị lắm nữa. Tất cả thời gian tôi dành cho nó — đọc sách, làm bài tập thực tế, thảo luận với các kỹ sư khác, viết ADRs — đang trở nên vô dụng.

Bây giờ thì sao?

Tôi vẫn đang làm việc và tôi thấy mình vẫn được thuê (ít nhất là ở công ty đó) trong tương lai gần. Nhưng tôi không biết nên nghĩ gì về lâu dài.

Tôi đã dành 10 năm (thậm chí nhiều hơn khi tính cả kinh nghiệm không chuyên nghiệp) để trở nên giỏi những thứ đang ngày càng ít giá trị. Trụ cột chuyên môn cuối cùng của tôi hiện bị giảm xuống thành một "gu thẩm mỹ" và có lẽ sẽ không tồn tại lâu.

Và tôi biết không chỉ có tôi như vậy. Khoảng 8 tháng trước, có một đợt sa thải tại công ty hiện tại của tôi (theo họ thì không liên quan đến AI). Một số cựu đồng nghiệp xuất sắc đã bị sa thải và vẫn đang tìm việc. Hầu hết họ gặp phải vấn đề tương tự như tôi mô tả ở đây: kiến thức chuyên ngành của họ không còn đủ để nổi bật nữa.

Công ty hiện đang tuyển dụng lại cho một vài vai trò và sự quen thuộc với lĩnh vực không còn là yếu tố khác biệt mạnh mẽ nữa. Trước đây chúng tôi đăng tin "Kỹ sư phần mềm - Lĩnh vực". Bây giờ chỉ là "Kỹ sư phần mềm" và việc phân bổ đội nhóm đến sau khi lời mời làm việc được chấp nhận.

Tất nhiên, điều này tốt cho những kỹ sư xuất sắc chưa bao giờ có cơ hội đi sâu vào lĩnh vực và giờ có cơ hội tốt hơn để có được việc làm, nhưng cũng thật buồn khi nghĩ rằng những kỹ sư xuất sắc khác đã dành cả cuộc đời để thu thập kiến thức chuyên ngành giờ đang cạnh tranh trên cùng một đường đua.

Cách duy nhất để duy trì khả năng có việc làm trong dài hạn của tôi bây giờ dường như là chuyển đổi kiến thức chuyên ngành sang một thứ mà LLM sẽ không dễ dàng giỏi. Nhưng còn lại cái gì?

Tôi đã nghĩ đến việc quay lại trường đại học, học Toán, Thống kê, Học máy nâng cao và nộp đơn vào vai trò nghiên cứu tại một phòng thí nghiệm tiên phong. Ngoại trừ rằng không có phòng thí nghiệm tiên phong nào ở đất nước tôi, số ít tồn tại đang ngập trong đơn đăng ký và tôi có việc gia đình khiến việc chuyển sang quốc gia khác trở nên khó khăn. Đến lúc tôi có thể thực hiện bước nhảy vọt đó, RSI (hội chứng chấn thương lặp lại) có thể đã khiến các nhà nghiên cứu trở nên lỗi thời.

Có lẽ tôi nên cân nhắc biến sở thích làm đồ gỗ của mình thành một nghề nghiệp...

Tương lai bất định