Để AI thay thế

Nếu mọi người cứ tiếp tục đe doạ về một thế giới tương lai bị AI thay thế, thì mình sẽ luyện tập cách sống trong sợ hãi :D

Apr 28, 2026

Tương lai đầy trắc trở

“Quá điên rồi, AI bây giờ đã làm được XXX”, “Một thông báo thay đổi thế giới từ $big_tech_a”, “$tool_x sắp khiến hàng nghìn người mất việc, nếu bạn không chú ý” ... Đó có lẽ là góc nhìn của rất nhiều người, khi các thông tin trên mạng về các loại AI. Đầy đe doạ, mang lại nhiều nỗi lo sợ và hoang mang. Các anh chị em IT coder luôn đi đầu trong danh sách đe doạ và bị đe doạ. Không biết dùng tool, không biết agentic engineering, không được cập nhật với tình hình mới nhất, thì sẽ bị thay đổi, bị layoff, bị đào thải.

blue plastic robot toy — Photo by Emilipothèse on Unsplash

Câu chuyện của AI cũng đã thay đổi nhiều trong vài năm vừa qua, từ một công cụ muôn hình vạn trạng, giờ thì rất nhiều nghiên cứu cũng như benchmark đã được chuyển về việc tác vụ coding, làm sao để có thể code được nhanh, code được nhiều, code được chuẩn hơn.

Mình, với tư cách một coder lỏ — trình độ thì không đến đâu mà thế giới thì tìm mọi cách để thay thế. Để đối diện với nỗi sợ hãi, cách tôi lựa chọn là đối đầu: thử tìm cách dùng AI để thay thế bản thân mình. Cũng như chính mình đã từng kể, lo lắng không có tác dụng gì, nếu có thì hãy biến thời gian dùng cho việc lo lắng vào việc giải quyết vấn đề.

Trải nghiệm nhiều hoàn cảnh

Khi nghe các câu chuyện kể từ các AI bros trên mạng, thì được cái là mọi người luôn kể về chuyện build products, build systems, hoặc là viết ra hàng nghìn dòng code vô cùng nhanh, vô cùng hiệu quả. Tuy nhiên, trong thực tế, thì câu chuyện như vậy sẽ mang tính rất là phiến diện. Khi bạn muốn giải quyết vấn đề, thì bạn phải nắm bắt được tình huống, là bạn đang ở đâu, bạn đang làm cái gì và bạn muốn làm thêm một cái gì.

Khi sản phẩm của bạn mới chỉ nằm trong đầu, hoặc trong những bước sơ khai thử nghiệm, thì việc xây ra một sản phẩm mới nó lại rất là đơn giản. Bạn có một mảnh đất trống, thì bạn thích xây cái gì lên trên nó cũng dễ, chỉ đơn giản là bạn có đủ nguyên liệu. Tuy nhiên, khi sản phẩm của bạn đã đạt đến các mốc sau trong vòng đời sản phẩm: bạn đã có users, bạn đã có những cái khung nhất định mà bạn phải giữ vững, thì lúc đó, bạn sẽ có thêm rất nhiều trở ngại, nhiều lo toan trong việc xây dựng thêm mới. Như là bạn muốn mua nhà chung cư, gia đình bạn đã và đang ở trong đó, và bạn muốn xây dựng để cơi nới thêm vậy. Bạn sẽ lo về diện tích sử dụng và sinh hoạt, về trụ về tường, về đường điện đường nước — không phải muốn làm gì cũng được.

Trước đây, với việc đi code, đụng vào một cái repo mới hoặc một cái repo legacy cũng sẽ mang lại cảm giác vô cùng khác nhau. Cách đơn giản để tăng trải nghiệm, mình chỉ cần tìm cách tiếp cận và tham gia vào các codebase khác nhau, ở những giai đoạn khác nhau: Vọc vạch viết exploratory scripts để ngâm cứu kiến trúc của một hệ thống. Dùng agent để study và gỡ từng mảng của một monorepo legacy với cấu trúc loằng ngoằng. Vibe-code cả một backend services từ đầu. Mỗi vấn đề lại mang cho mình một trải nghiệm hoàn toàn khác nhau. Đôi khi phải viết prompt một cách thật là specific, nhưng có lúc lại có thể bay bổng với việc ideation và thiết kế specs và plans hoàn chỉnh.

Suy nghĩ của mình về việc code, thực ra là có rất nhiều loại coding, và nó hoàn toàn là khác nhau (bạn có thể đọc bài cũ mình từng viết). Như hôm nọ mình có chém gió với mấy đứa bạn về sự khác nhau trong cùng một ngành (ví dụ như ngành tài chính đầu tư thì bạn mua bán options như là một hedge fund thì sẽ hoàn toàn khác với việc bạn đầu tư cơ bản với mục tiêu xã hội), bạn có thể tưởng tượng là code của research, code của data, code của backend frontend, mặc dù đều là code nhưng mà có thể phân hoá rất xa. Xây dựng trải nghiệm với code làm webapp, hay là code của high-throughput data pipelines nó phải khác nhau. Nên nghiên cứu được sự khác biệt khi áp dụng AI trong những bài toán coding cụ thể, trong tình huống cụ thể, thì mình mới hiểu nó hơn được.

Một điều phải công nhận, đó là khi việc viết code nó nhanh hơn, thì từ hướng của một builder, cũng mang lại rất nhiều hứng thú. Mình có cảm giác mình có thể thử nghiệm nhiều thứ hơn, và làm mình cũng thích nghịch qua hơn với việc build các thứ mới. Mình cũng mua thử Claude plan, và cũng thử cảm nhận sự bức bối của một workflow khi đang máu me làm cái gì đó thì hết limits. Tuy nhiên từ phía maintainer của một hệ thống lớn hơn, thì mình cũng mang thêm nhiều nỗi sợ hơn. Làm sao để con agent nó không đi sai hướng và làm những thứ nguy hiểm? Xây dựng những cái harness thế nào để nó ko đi lạc đường? Làm thế nào để hạn chế permission của chính bản thân mình, nếu mà mình có những access nguy hiểm, và không gây ra được tai hoạ?

Thay thế và thay đổi

Đương nhiên, nếu nghe theo lời các chuyên gia mạng, thì để bạn không bị thay thế, thì bạn phải học cách thay đổi. Nhưng thay đổi nó sẽ không nằm ở việc là bạn dùng nhiều tool hơn, áp dụng framework của ông nọ bà kia, hay là hàng ngày lên đọc 100 cái tin về new model release và benchmark. Thay đổi nó nằm ở việc bạn vẫn tiếp tục phát triển bản thân, nắm vững những kỹ năng của mình (và cả điểm yếu), và tìm cách để nâng tầm nó lên với những công cụ mới.

Mình thì nghĩ điều này cũng đúng với cả các doanh nghiệp, hay business, chứ không chỉ với cá nhân. Các công ty vẫn cần phải hiểu về nghiệp vụ, về kinh doanh của bản thân — rồi nghiên cứu cách để phát triển, nâng tầm về hiệu quả, về quy trình, về nhân sự — đó mới là điểm để phát triển, chứ không phải là bạn có dùng AI hay là không. Hô hào về ứng dụng AI, nhưng sản phẩm hay dịch vụ của bạn không cải thiện, thì còn mang lại nhiều hại hơn là lợi.

Về xây dựng hệ thống và coding, sẽ có sự dịch chuyển về balance của việc build và maintain với agentic engineering. Bạn có thể xây nhanh hơn trong những giai đoạn đầu, nhưng trong giai đoạn scale bạn có thể sẽ gặp được những khó khăn mới trong việc quản trị chất lượng. Các enterprise systems, cán cân về việc maintenance có thể sẽ khác xưa rất nhiều. Nếu bạn từng làm việc với các hệ thống CI chạy regression test suites mất hàng tiếng, bây giờ có khi bạn sẽ xây dựng hệ thống harness engineering phải làm gấp 2-3 lần so với trước, vì Agent làm nhanh và khó dự đoán hơn con người, nên sẽ có thêm nhiều hệ thống cần phải chặt chẽ hơn.

Một hướng mà mình cũng có nói chuyện với một số đồng nghiệp, đó là những measurement mới trong thời đại agentic engineering. Làm sao để cái code repo của mình nó ready và optimized cho agents? Nếu chén thánh của agentic engineering là việc mình có thể one-shot một cái feature implementation trong một session, thì cái sizing của cái one-shot là bao nhiêu (LoCs hoặc complexity), với việc sử dụng bao nhiêu tokens? Ví dụ bạn có một thay đổi nhỏ trên frontend với chỉ tầm 2 dòng code, nhưng mà bạn vẫn phải chạy đủ agentic flow, thì liệu cách mình sử dụng agent có giá trị cao hay không?

Về bản thân, thì chắc có một thay đổi là mình cảm thấy nhiệt tình hơn với việc code các thứ vui vẻ. Nghe mọi người nói chuyện về business nhiều cũng mệt, nên là bây giờ mình chỉ thích nghĩ đến việc code các thử nhảm nhí vui vẻ và không kiếm ra tiền. Có lẽ một ngày nào đó mình sẽ share nhiều hơn về việc này.

Còn hiện giờ, mình sẽ ngồi tiếp tục nghiên cứu cách để thay thế bản thân vậy.

Một số bài viết của mình cũng có chút liên quan:

Lạc quan và thích nghi