AI & I

AI có đang thu hẹp khoảng cách giữa Fresher và Senior? Câu trả lời ngắn gọn của mình là: có, nhưng chỉ ở phần tốc độ — còn phần tư duy thì gần như không đổi, thậm chí đang bị AI che giấu đi. Nghe có vẻ mâu thuẫn, nhưng đó chính xác là những gì mình quan sát được khi làm việc cùng đồng nghiệp ở nhiều cấp độ trong hơn một năm AI-coding-assistant trở thành công cụ mặc định.1. Những việc trước đây chỉ Senior mới làm được, giờ Fresher đã làm đượcThành thật mà nói, danh sách này khá dài. Viết boilerplate, setup dự án, cấu hình CI/CD cơ bản — trước đây đòi hỏi kinh nghiệm để nhớ hết các bước, giờ chỉ cần mô tả đúng yêu cầu là AI dựng ra gần như hoàn chỉnh. Đọc hiểu codebase lạ cũng không còn là rào cản lớn: Fresher giờ có thể hỏi AI "đoạn code này làm gì, luồng dữ liệu đi đâu" thay vì mất cả ngày dò từng file như trước. Viết unit test, refactor code đơn giản — những việc từng là "đặc quyền" của người có kinh nghiệm vì đòi hỏi sự tỉ mỉ — giờ AI làm nhanh và ít lỗi hơn cả một số Senior lười. Ngay cả debug lỗi phổ biến — stack trace, lỗi cú pháp, lỗi cấu hình — AI cũng xử lý cực nhanh, những thứ mà trước đây Fresher phải hỏi Senior hoặc mất hàng giờ search Stack Overflow.Nhìn vào đây, đúng là ranh giới bị xóa nhòa thật. Một Fresher chăm chỉ, biết dùng AI đúng cách, có thể tạo ra output nhìn "chuyên nghiệp" chỉ sau vài tháng — điều mà trước đây cần 2-3 năm.2. Nhưng khoảng cách thật sự nằm ở đâu?Đây là phần mình muốn nói thẳng, không tô hồng: AI không thu hẹp khoảng cách về năng lực ra quyết định. Và đây mới là thứ phân biệt Fresher với Senior.Thứ nhất, khi AI sai, ai là người nhận ra? AI có thể viết ra một đoạn code chạy được, test pass, nhìn "sạch sẽ" — nhưng lại chọn sai kiến trúc, tạo ra vấn đề về hiệu năng, hoặc vi phạm một ràng buộc nghiệp vụ mà AI không hề biết vì nó không có trong prompt. Senior nhìn vào là thấy ngay "cái này chạy được nhưng sai hướng". Fresher thì thường tin tưởng tuyệt đối vào output vì nó trông có vẻ đúng.Thứ hai, câu hỏi "nên làm gì" quan trọng hơn "làm như thế nào". AI trả lời cực tốt câu hỏi "làm sao để implement X". Nhưng câu hỏi "có nên implement X không, hay vấn đề thực sự nằm ở chỗ khác" thì AI không tự đặt ra được — nó cần người đặt câu hỏi đúng. Đó là kỹ năng chỉ có được từ việc từng bị đấm vào mặt bởi hậu quả của quyết định sai trong quá khứ.Thứ ba — và đây là điều khiến mình phải nói thẳng — khi AI "hết token" hoặc không dùng được, Fresher thường đứng hình. Có không ít Fresher (và cả một số người tự nhận là mid-level), khi bị giới hạn số lượng request/token trong ngày, hoặc gặp sự cố mạng không truy cập được AI, hoặc rơi vào tình huống mà AI liên tục trả lời sai/loop không thoát ra được, thì không biết phải làm gì tiếp theo. Không phải vì họ lười, mà vì họ chưa bao giờ thực sự tự mình đi qua toàn bộ quá trình tư duy — từ đọc lỗi, đặt giả thuyết, kiểm chứng, đến tự tay tra tài liệu gốc. Với họ, AI không phải là "trợ lý" mà đã trở thành "bộ não thay thế". Khi bộ não đó offline, họ mất luôn khả năng tự vận hành.Mình từng chứng kiến một bạn Fresher dùng AI dựng cả một tính năng khá phức tạp trong vài giờ — nhìn rất ấn tượng. Nhưng khi hệ thống gặp sự cố lúc nửa đêm và không thể chờ AI (do rate limit), bạn ấy hoàn toàn không biết bắt đầu từ đâu để đọc log, vì trước giờ mọi lần debug đều là "paste lỗi vào AI, AI trả lời, làm theo". Đó là lúc mình nhận ra: AI không tạo ra Senior nhanh hơn — nó chỉ khiến Fresher trông giống Senior nhanh hơn. Hai điều đó rất khác nhau.Senior thì khác — với họ, AI là một công cụ tăng tốc, không phải nền tảng tư duy. Không có AI, Senior vẫn debug được, chỉ là chậm hơn. Đó chính là khoảng cách thật sự, và nó không hề bị AI thu hẹp — thậm chí còn dễ bị AI che giấu đi, khiến người quản lý lầm tưởng năng lực của Fresher cao hơn thực tế, cho đến khi có sự cố thật xảy ra.3. Vậy điều gì vẫn tạo nên sự khác biệt khi cả hai đều có AI?Khả năng đặt câu hỏi đúng — prompt tốt đến từ hiểu vấn đề tốt, không phải kỹ năng gõ chữ.Trực giác về rủi ro — biết đoạn code nào "trông ổn nhưng sẽ nổ trong production" mà chưa cần chạy thử.Khả năng review chính output của AI — đọc và phản biện, chứ không phải copy-paste.Hiểu bức tranh lớn — AI giỏi giải quyết bài toán cục bộ, nhưng chưa thấy được toàn bộ hệ thống, các ràng buộc nghiệp vụ, lịch sử "tại sao code lại như vậy".Chịu trách nhiệm khi mọi thứ sai — đây là thứ AI không bao giờ làm thay được.Theo mình, kỹ năng mà AI khó thay thế kinh nghiệm thực tế nhất là khả năng chịu đựng sự mơ hồ và tự mình đưa ra quyết định khi thông tin không đầy đủ. Kinh nghiệm thực chất là một tập hợp các "lần đã từng sai" được tích lũy lại. AI có thể cho bạn kiến thức, nhưng không cho bạn "vết sẹo" — và chính vết sẹo đó mới là thứ giúp Senior phản xạ nhanh trong tình huống thực tế căng thẳng, không có thời gian hỏi AI.4. Tổng kết Theo mình, AI đang thu hẹp khoảng cách về tốc độ tạo ra sản phẩm, nhưng khoảng cách về tư duy, phán đoán và khả năng tự vận hành khi không còn AI thì gần như không đổi — thậm chí rủi ro là nó đang bị che giấu, tạo ảo tưởng năng lực cho cả Fresher lẫn nhà tuyển dụng. Bài học thực tế nhất: nếu bạn là Fresher, hãy dùng AI để học nhanh hơn, chứ đừng dùng AI để thay thế việc tự mình tư duy — vì đến một ngày AI "hết token", bạn vẫn phải tự mình biết đường ra.

Một Fresher sử dụng AI có thể tạo ra trong 30 phút đoạn code mà trước đây họ cần vài ngày để tự nghiên cứu.Nhưng khi đoạn code đó gây lỗi trên production, ai sẽ biết nên kiểm tra ở đâu, đánh giá mức độ ảnh hưởng như thế nào và lựa chọn giải pháp nào ít rủi ro nhất?Đó là điểm khiến tôi nghĩ rằng AI đang thay đổi khoảng cách giữa Fresher và Senior, nhưng không đơn giản theo hướng “Fresher sắp thay thế Senior”.AI đang thu hẹp khoảng cách về tốc độ viết code, khả năng tiếp cận kiến thức và mức độ hoàn thiện của đầu ra. Đồng thời, nó làm nổi bật một khoảng cách khác khó nhìn thấy hơn: khả năng đặt câu hỏi, đánh giá rủi ro và chịu trách nhiệm cho quyết định kỹ thuật.Những việc từng khó với Fresher giờ đã trở nên dễ tiếp cận hơnKhi mới bắt đầu lập trình, một developer có thể mất nhiều thời gian chỉ để hiểu cấu trúc dự án, cách gọi API, quản lý state hoặc xử lý lỗi.Ngày nay, với AI, một Fresher có thể yêu cầu:Tạo một màn hình React Native từ thiết kế.Viết API service và TypeScript interface từ JSON response.Giải thích một đoạn source code cũ.Chuyển class component sang function component.Viết unit test cho một hàm.Phân tích log lỗi build Android hoặc iOS.Đề xuất cách tối ưu component bị re-render nhiều lần.Tạo tài liệu cho một tính năng vừa hoàn thành.Nếu cung cấp đủ bối cảnh, AI có thể tạo ra kết quả khá tốt. Một Fresher biết sử dụng AI thậm chí có thể hoàn thành những task mà vài năm trước thường được giao cho developer có kinh nghiệm hơn.Đây là một thay đổi rất tích cực.Trước đây, Fresher phải dành nhiều thời gian để vượt qua “rào cản cú pháp”: không biết tên API, không nhớ cách cấu hình hoặc chưa từng gặp một lỗi tương tự. AI giúp giảm rào cản đó và cho phép họ tập trung sớm hơn vào logic của sản phẩm.AI cũng giống như một người hướng dẫn luôn sẵn sàng trả lời. Fresher có thể hỏi những câu rất cơ bản mà không sợ bị đánh giá, yêu cầu giải thích lại nhiều lần hoặc nhờ đưa ra ví dụ phù hợp với trình độ hiện tại.Nhờ vậy, tốc độ học có thể nhanh hơn rất nhiều.Nhưng tạo ra code chỉ là một phần của công việc phát triển phần mềm.Khoảnh khắc khiến tôi nhìn AI và kinh nghiệm khác điTrong một ứng dụng mobile, tôi từng xử lý luồng thanh toán qua trình duyệt và nhận kết quả trả về bằng deep link.Nếu chỉ mô tả yêu cầu chính, AI có thể nhanh chóng viết một đoạn code:Mở trang thanh toán.Lắng nghe deep link.Đọc trạng thái giao dịch.Chuyển tới màn hình thành công hoặc thất bại.Đoạn code trông hợp lý và có thể chạy tốt trong lần thử đầu tiên.Nhưng khi đưa vào sản phẩm thực tế, hàng loạt câu hỏi khác xuất hiện:Điều gì xảy ra nếu người dùng thanh toán xong khi ứng dụng đã bị tắt?Nếu ứng dụng chỉ đang ở background thì có nhận được callback không?Nếu deep link được gửi hai lần, giao dịch có bị xử lý hai lần không?Nếu người dùng sửa tham số status=success trong URL thì sao?Nếu callback của luồng nạp tiền và mua thẻ sử dụng các đường dẫn gần giống nhau thì phân biệt thế nào?Màn hình nào sẽ nhận kết quả nếu navigation chưa khởi tạo xong?Dữ liệu trên thiết bị có được xem là nguồn xác nhận thanh toán hay phải kiểm tra lại từ server?AI có thể trả lời từng câu hỏi này.Nhưng vấn đề là ai sẽ nghĩ ra những câu hỏi đó trước khi sự cố xảy ra?Đó là lúc tôi nhận ra giá trị lớn nhất của kinh nghiệm không nằm ở việc Senior nhớ nhiều cú pháp hơn. AI có thể nhớ cú pháp tốt hơn bất kỳ ai.Kinh nghiệm nằm ở khả năng nhìn một yêu cầu đơn giản và thấy được những tình huống ẩn phía sau nó.Fresher thường hỏi: “Làm thế nào để tính năng này chạy?”Senior thường hỏi thêm: “Nó sẽ hỏng trong trường hợp nào?”AI thu hẹp khoảng cách ở đâu?Theo tôi, AI đang thu hẹp rõ nhất ba khoảng cách.1. Khoảng cách về kiến thức có thể tra cứuFresher không còn phải mất nhiều giờ tìm đúng từ khóa hoặc đọc hàng chục câu trả lời không liên quan. AI có thể tổng hợp kiến thức, giải thích theo ngữ cảnh và đề xuất điểm bắt đầu.Điều này không biến Fresher thành Senior ngay lập tức, nhưng giúp họ tiếp cận kiến thức của Senior nhanh hơn.2. Khoảng cách về tốc độ tạo đầu raVới những task có phạm vi rõ ràng, AI giúp Fresher tạo component, test, tài liệu và code mẫu với tốc độ rất cao.Nếu trước đây Senior nhanh hơn vì đã từng viết đoạn code tương tự, lợi thế đó hiện không còn lớn như trước.3. Khoảng cách về khả năng thử nghiệmFresher có thể nhanh chóng tạo nhiều phương án và so sánh chúng. Thay vì chỉ học lý thuyết, họ có thể yêu cầu AI tạo ví dụ, chạy thử, sửa lỗi và quan sát kết quả.Vòng lặp học tập trở nên ngắn hơn. Một developer có thái độ học đúng có thể tiến bộ với tốc độ mà trước đây rất khó đạt được.Khi cả Fresher và Senior đều có AI, điều gì tạo ra khác biệt?Nếu cả hai cùng sử dụng một công cụ, lợi thế không còn nằm ở việc ai có AI.Lợi thế nằm ở việc ai cung cấp bối cảnh tốt hơn, đặt câu hỏi chính xác hơn và nhận ra khi câu trả lời có vấn đề.Cùng đứng trước một đoạn code do AI tạo ra, Fresher có thể thấy:“Code sạch, không báo lỗi và chạy đúng yêu cầu.”Senior có thể nhìn thấy thêm:Đoạn code này có tạo listener mới mỗi lần component render không?Có rò rỉ bộ nhớ khi màn hình bị unmount không?Có ảnh hưởng tới phiên bản hệ điều hành cũ không?Thư viện được đề xuất có còn được duy trì không?Giải pháp có vi phạm kiến trúc hiện tại của dự án không?Nếu API chậm hoặc trả dữ liệu thiếu thì giao diện sẽ thế nào?Sau sáu tháng, đội ngũ có dễ bảo trì đoạn code này không?Khác biệt không nhất thiết nằm ở câu trả lời. Nó nằm ở số lượng và chất lượng của những câu hỏi được đặt ra trước khi chấp nhận câu trả lời.AI khuếch đại năng lực sẵn có của người sử dụng.Một Fresher có nền tảng tốt và tư duy phản biện sẽ học nhanh hơn. Một Senior có kinh nghiệm và biết dùng AI sẽ xử lý được phạm vi công việc lớn hơn.Ngược lại, nếu quá phụ thuộc vào AI, Fresher có thể tạo ra nhiều code hơn nhưng hiểu ít hơn. Senior cũng có thể mắc sai lầm nếu tin vào câu trả lời chỉ vì nó được trình bày thuyết phục.Những bài học vẫn cần trải nghiệm thực tếCó những kiến thức có thể đọc trong vài phút nhưng cần nhiều lần va chạm mới thực sự hiểu.Bạn có thể đọc rằng không nên chỉnh sửa production vào cuối ngày thứ Sáu. Nhưng cảm giác phải tìm nguyên nhân một lỗi nghiêm trọng khi người dùng đang chờ là một bài học hoàn toàn khác.Bạn có thể hỏi AI cách thiết kế kiến trúc tốt. Nhưng chỉ sau khi từng bảo trì một source code được xây quá phức tạp, bạn mới hiểu vì sao giải pháp đơn giản thường có giá trị.Bạn có thể học quy trình review code. Nhưng cần trải nghiệm làm việc trong đội nhóm để biết khi nào nên bảo vệ quan điểm kỹ thuật, khi nào nên thỏa hiệp và cách phản hồi mà không biến một cuộc thảo luận thành xung đột.Một số năng lực rất khó có được chỉ bằng câu trả lời của AI:Ước lượng công việc khi yêu cầu còn mơ hồ.Đưa ra quyết định khi không có phương án hoàn hảo.Xử lý sự cố production dưới áp lực.Hiểu ảnh hưởng của một thay đổi tới người dùng và hoạt động kinh doanh.Giao tiếp với product, design, backend và khách hàng.Biết lúc nào nên tiếp tục tối ưu và lúc nào sản phẩm đã “đủ tốt”.Chịu trách nhiệm cho kết quả thay vì chỉ hoàn thành phần code được giao.AI có thể mô phỏng tình huống và đưa ra lời khuyên. Nhưng trải nghiệm thật tạo ra trực giác: cảm giác rằng một chi tiết nào đó “có vẻ không ổn” dù chưa xuất hiện lỗi rõ ràng.Trực giác kỹ thuật không phải phép thuật. Nó là kết quả của nhiều lần sai, sửa và ghi nhớ.Senior trong thời đại AI không nên chỉ là người code nhanh hơnNếu giá trị của Senior chỉ nằm ở việc viết code nhanh, AI chắc chắn sẽ làm lợi thế đó giảm đi.Theo tôi, vai trò của Senior cần dịch chuyển từ “người biết nhiều đáp án” sang:Người xác định đúng vấn đề.Người đưa ra tiêu chuẩn để đánh giá đáp án.Người quản lý rủi ro kỹ thuật.Người giúp đội ngũ tránh những sai lầm đắt giá.Người biến kinh nghiệm cá nhân thành kiến thức chung.Người hướng dẫn Fresher hiểu code, không chỉ tạo ra code.Một Senior tốt không nên dùng kinh nghiệm để giữ khoảng cách với Fresher. Họ nên dùng AI và kinh nghiệm để giúp Fresher rút ngắn con đường phát triển.Và Fresher cũng không nên xem AI là đường tắt để bỏ qua nền tảng.AI có thể viết một custom hook, nhưng developer vẫn cần hiểu lifecycle.AI có thể tối ưu một danh sách, nhưng developer vẫn cần hiểu nguyên nhân gây re-render.AI có thể sửa lỗi, nhưng developer cần biết vì sao cách sửa đó đúng và nó có thể tạo ra lỗi mới ở đâu.Nếu chỉ sao chép kết quả, Fresher sẽ hoàn thành task nhanh hơn nhưng không tích lũy được kinh nghiệm. Khi gặp một vấn đề nằm ngoài những gì AI nhìn thấy, họ sẽ tiếp tục bị phụ thuộc.Khoảng cách không biến mất, nó đang đổi hình dạngTrước AI, khoảng cách giữa Fresher và Senior thường thể hiện qua tốc độ viết code, lượng kiến thức ghi nhớ và số vấn đề từng gặp.Sau AI, khoảng cách về code và kiến thức có thể thu hẹp đáng kể.Nhưng khoảng cách về phán đoán, trách nhiệm, hiểu sản phẩm và khả năng ra quyết định vẫn còn. Trong một số trường hợp, nó thậm chí trở nên rõ hơn vì AI cho phép mọi người tạo ra nhiều code với tốc độ cao hơn — bao gồm cả code tốt lẫn code tạo thêm rủi ro.Vì vậy, tôi không nghĩ AI làm kinh nghiệm mất giá.AI làm những kinh nghiệm chỉ dùng để ghi nhớ cú pháp mất giá. Đồng thời, nó làm những kinh nghiệm liên quan đến tư duy hệ thống, đánh giá rủi ro và hiểu con người trở nên giá trị hơn.Kết luậnAI có thể giúp Fresher làm được những task từng cần Senior. Nhưng “làm được một task” và “chịu trách nhiệm cho toàn bộ kết quả” là hai cấp độ khác nhau.Một Fresher dùng AI tốt có thể tiến bộ rất nhanh.Một Senior dùng AI tốt có thể mở rộng đáng kể phạm vi ảnh hưởng.Người gặp khó khăn nhất có lẽ không phải Fresher hay Senior, mà là developer ngừng học vì nghĩ AI đã có thể suy nghĩ thay mình.Theo tôi, ranh giới mới giữa các cấp độ kinh nghiệm không còn là:“Bạn có thể viết đoạn code này không?”Mà là:“Bạn có biết đoạn code này có nên được viết, có thể sai ở đâu và ai sẽ bị ảnh hưởng khi nó sai không?”AI đang thu hẹp khoảng cách giữa đôi tay của Fresher và Senior.Nhưng khoảng cách giữa hai cách tư duy vẫn phải được rút ngắn bằng trải nghiệm, trách nhiệm và sự chủ động học hỏi.Còn bạn nghĩ sao: AI đang giúp Fresher tiến gần Senior hơn, hay đang giúp Senior tiến xa hơn nữa?

Trước khi dùng AI, tôi mất hai giờ để viết một tính năng và một giờ để kiểm tra.Sau khi dùng AI, tôi có thể viết tính năng đó trong 30 phút. Nhưng thay vì được nghỉ sớm hơn 90 phút, tôi thường nhận thêm hai tính năng mới, review nhiều code hơn và phải đảm bảo chất lượng cao hơn trước.Ngày làm việc vẫn đủ tám tiếng.Chỉ có lượng công việc hoàn thành trong tám tiếng đó tăng lên.Là một mobile developer làm việc chủ yếu với React Native, tôi dùng AI gần như mỗi ngày: đọc lỗi build, gợi ý code, tạo cấu trúc màn hình, viết hàm xử lý dữ liệu, giải thích source code cũ và chuẩn bị tài liệu kỹ thuật.Không thể phủ nhận rằng AI giúp tôi làm việc nhanh hơn. Nhưng sau một thời gian sử dụng thường xuyên, tôi nhận ra một nghịch lý:AI tiết kiệm thời gian cho từng công việc, nhưng chưa chắc tiết kiệm thời gian cho người làm công việc đó.Quy trình làm việc của tôi đã thay đổi như thế nào?Trước đây, khi gặp một lỗi Android hoặc iOS, quy trình quen thuộc của tôi thường là:Đọc log → tìm kiếm trên Google → mở nhiều trang Stack Overflow hoặc GitHub Issues → thử từng cách → build lại → tiếp tục sửa.Có những lỗi mất vài giờ chỉ để xác định nguyên nhân.Hiện tại, tôi có thể đưa log lỗi cùng những phần cấu hình liên quan cho AI. Trong vài phút, AI có thể phân tích các khả năng, giải thích mối liên hệ giữa phiên bản thư viện, Gradle, Kotlin, CocoaPods hoặc React Native và đề xuất hướng kiểm tra.Khi cần xây một tính năng mới, tôi cũng không còn bắt đầu hoàn toàn từ trang trắng. AI có thể tạo bộ khung component, TypeScript interface, API service, validation và các trường hợp cần xử lý.Nhưng quy trình không thực sự mất đi nhiều bước. Nó chỉ được thay đổi thành:Mô tả vấn đề → cung cấp bối cảnh → nhận đề xuất từ AI → đọc và kiểm chứng → sửa lại → chạy thử → kiểm tra trên thiết bị thật → review tác động tới phần còn lại của ứng dụng.Một số bước cũ được rút ngắn, nhưng các bước mới xuất hiện: viết yêu cầu đủ rõ, đánh giá câu trả lời và phát hiện những chỗ AI tự tin nhưng không chính xác.Tôi viết code ít hơn, nhưng review nhiều hơn.30 phút tạo code có thể kéo theo hai giờ kiểm traĐiều nguy hiểm nhất ở code do AI tạo ra không phải là code sai hoàn toàn. Nếu sai rõ ràng, chúng ta có thể phát hiện ngay.Nguy hiểm hơn là đoạn code nhìn rất hợp lý, chạy được trong trường hợp thông thường nhưng sai ở những tình huống đặc biệt.Ví dụ, AI có thể đề xuất một API đã bị thay đổi ở phiên bản thư viện tôi đang sử dụng. Nó có thể viết một luồng đăng nhập hoạt động tốt trên Android nhưng thiếu cấu hình cần thiết trên iOS. Nó cũng có thể tạo logic xử lý thanh toán đúng khi giao dịch thành công nhưng bỏ sót trường hợp người dùng hủy, ứng dụng bị đưa xuống background hoặc deep link được mở khi app chưa khởi động.Nếu tôi tin ngay vào kết quả và sao chép vào dự án, thời gian “tiết kiệm” lúc viết code có thể trở thành thời gian sửa lỗi sau khi phát hành.Đặc biệt với mobile app, một đoạn code không chỉ cần chạy trên máy của developer. Nó còn phải hoạt động trên nhiều phiên bản hệ điều hành, kích thước màn hình, trạng thái mạng và vòng đời ứng dụng khác nhau.Vì vậy, AI càng tạo code nhanh, tôi càng phải giữ kỷ luật kiểm chứng:Đọc lại logic thay vì chỉ nhìn kết quả chạy được.Kiểm tra tài liệu chính thức của thư viện.Test cả Android và iOS.Thử các trường hợp mất mạng, bấm nhiều lần hoặc đưa app xuống background.Đảm bảo giải pháp không làm hỏng những tính năng đang hoạt động.Không đưa dữ liệu nhạy cảm hoặc thông tin người dùng vào công cụ AI.AI giúp giảm thời gian gõ code. Nhưng trách nhiệm về chất lượng, bảo mật và trải nghiệm người dùng vẫn thuộc về developer.Khi mọi người đều có AI, “nhanh” trở thành tiêu chuẩn mớiThời gian đầu, hoàn thành một công việc sớm hơn dự kiến tạo ra cảm giác rất tích cực.Nhưng khi tốc độ đó lặp lại đủ nhiều, nó không còn được xem là một thành tích đặc biệt. Nó dần trở thành tốc độ mặc định.Một task từng được ước tính ba ngày có thể được kỳ vọng hoàn thành trong một ngày. Một bản demo trước đây chỉ cần thể hiện luồng chính, nay có thể được yêu cầu thêm giao diện đẹp, xử lý đầy đủ trường hợp lỗi và có tài liệu đi kèm.Khi AI giúp tạo ra ba phương án nhanh chóng, câu hỏi tiếp theo thường không phải là “Bạn có thể nghỉ sớm không?”, mà là:“Có thể làm thêm phương án thứ tư không?”Đây không hẳn là lỗi của AI, cũng không hoàn toàn là lỗi của quản lý hay khách hàng. Nó là kết quả tự nhiên khi năng suất chung tăng lên. Khi công cụ thay đổi, kỳ vọng về tốc độ và chất lượng cũng thay đổi theo.Điều đáng chú ý là AI không chỉ giúp tôi hoàn thành công việc cũ nhanh hơn. Nó còn khiến những công việc từng bị xem là “không đủ thời gian để làm” trở nên khả thi.Tôi có thể viết tài liệu kỹ hơn, thêm test case, phân tích log sâu hơn, thử nhiều phương án UI hơn hoặc chủ động cải thiện những đoạn source code cũ.Kết quả là sản phẩm tốt hơn, nhưng danh sách việc cần làm cũng dài hơn.AI có tạo thêm công việc không?Có, theo một cách khá thú vị.Khi việc tạo prototype trở nên dễ dàng, chúng ta thử nhiều ý tưởng hơn. Mỗi ý tưởng lại cần được đánh giá, chỉnh sửa và quyết định có tiếp tục hay không.Khi AI giúp tìm thấy nhiều vấn đề tiềm ẩn trong source code, chúng ta có thêm một danh sách cần xử lý.Khi AI có thể viết tài liệu nhanh, tiêu chuẩn mới có thể trở thành “mọi tính năng đều phải có tài liệu”.AI không chỉ hoàn thành công việc. Nó còn mở ra những công việc trước đây chúng ta chưa có khả năng hoặc thời gian để nhìn thấy.Có lúc tôi hỏi AI cách tối ưu một màn hình bị giật. Tôi chỉ muốn tìm một nguyên nhân, nhưng nhận lại hàng loạt đề xuất: giảm re-render, tối ưu danh sách, cache dữ liệu, kiểm tra kích thước ảnh, theo dõi memory và đo thời gian render.Câu trả lời giúp tôi tiết kiệm thời gian nghiên cứu, đồng thời tạo ra thêm một danh sách việc phải làm.Tôi gọi đó là “nợ năng suất”: khi có khả năng làm nhiều hơn, chúng ta bắt đầu cảm thấy mình nên làm tất cả.Vậy AI có thật sự giúp tôi làm ít đi không?Nếu xét trên từng task, câu trả lời là có.Nếu xét trên toàn bộ ngày làm việc, câu trả lời của tôi là chưa.AI chưa giúp tôi có thêm nhiều thời gian rảnh. Nó giúp tôi hoàn thành nhiều việc hơn trong cùng một khoảng thời gian. Chất lượng đầu ra cao hơn, khả năng thử nghiệm nhanh hơn và thời gian mắc kẹt với những vấn đề nhỏ giảm đi đáng kể.Điều đó vẫn rất có giá trị.Tuy nhiên, tôi nhận ra rằng thời gian tiết kiệm được chỉ trở thành thời gian rảnh khi chính chúng ta chủ động bảo vệ nó. Nếu không, mọi khoảng trống vừa được AI tạo ra sẽ nhanh chóng được lấp đầy bằng một task mới, một ý tưởng mới hoặc một yêu cầu cao hơn.Tôi đang học cách dùng AI để làm việc tốt hơn, không chỉ nhiều hơnThay vì hỏi “AI có thể giúp tôi làm thêm gì?”, tôi bắt đầu hỏi ba câu khác:Việc này có thực sự cần làm không?Kết quả nào là đủ tốt ở giai đoạn hiện tại?Phần thời gian tiết kiệm được nên dành cho task tiếp theo hay để suy nghĩ kỹ hơn?Tôi cũng cố gắng không đánh giá năng suất chỉ bằng số lượng task hoàn thành. Một giờ dùng để nói chuyện với người dùng, thiết kế kiến trúc đúng hoặc ngăn một lỗi nghiêm trọng có thể giá trị hơn cả ngày tạo ra thật nhiều code.AI giúp tăng tốc đôi tay, nhưng chúng ta vẫn cần dùng kinh nghiệm để chọn hướng đi.Nếu đi sai hướng, chạy nhanh hơn chỉ khiến chúng ta cách mục tiêu xa hơn.Kết luậnAI thực sự giúp tôi làm việc nhanh hơn, nhưng chưa làm tôi làm việc ít hơn.Nó biến thời gian chờ đợi thành thời gian thực hiện, biến những ý tưởng từng mất nhiều ngày thành prototype trong vài giờ và giúp một developer có thể đảm nhận nhiều vai trò hơn.Đổi lại, khối lượng đầu ra tăng, tiêu chuẩn chất lượng cao hơn và trách nhiệm kiểm chứng cũng lớn hơn.Với tôi, câu hỏi quan trọng không còn là:“AI giúp tiết kiệm được bao nhiêu giờ?”Mà là:“Ai sẽ quyết định cách sử dụng những giờ vừa tiết kiệm được?”Nếu câu trả lời luôn là deadline tiếp theo, AI chỉ giúp chúng ta bận rộn hiệu quả hơn.Còn nếu chúng ta dùng khoảng thời gian đó để học hỏi, suy nghĩ sâu hơn, chăm sóc sức khỏe hoặc đơn giản là kết thúc công việc đúng giờ, khi ấy AI mới thật sự giúp con người làm việc ít đi.Còn bạn thì sao? Từ khi dùng AI, bạn có thêm thời gian rảnh hay chỉ có thêm nhiều task đã hoàn thành hơn?

Hai tuần để xây xong một tính năng. Hai tháng để nhận ra mình đã xây sai thứ.Đó là trải nghiệm khiến tôi hiểu rằng: AI có thể rút ngắn đáng kể thời gian phát triển sản phẩm, nhưng không tự động rút ngắn khoảng cách từ một sản phẩm “chạy được” đến một sản phẩm “có người dùng và tạo ra doanh thu”.Tôi là một mobile developer, chủ yếu làm việc với React Native. Khi AI coding ngày càng mạnh, quy trình phát triển của tôi thay đổi rất rõ. Những công việc từng mất nhiều giờ như dựng màn hình, viết API service, xử lý validation, tìm nguyên nhân lỗi build Android/iOS hay viết tài liệu kỹ thuật giờ có thể hoàn thành nhanh hơn rất nhiều.Có lần, tôi cần phát triển một tính năng lập lộ trình cho xe điện: người dùng chọn loại xe, mức pin hiện tại, điểm đến và các trạm sạc phù hợp trên đường đi. AI giúp tôi đề xuất cấu trúc dữ liệu, công thức ước tính mức tiêu thụ pin, cách chia màu tuyến đường theo lượng pin còn lại và cả những trường hợp cần xử lý khi người dùng đi lệch tuyến.Chỉ trong thời gian ngắn, tôi đã có một phiên bản demo khá hoàn chỉnh.Nhìn trên màn hình, mọi thứ đều hợp lý.Nhưng khi đưa cho người dùng thử, câu hỏi đầu tiên tôi nhận được lại là:“Thông tin trạm sạc này có chính xác không?”Không ai hỏi thuật toán chia màu tuyến đường được viết thế nào. Không ai quan tâm tôi đã tối ưu bao nhiêu component hay tiết kiệm được bao nhiêu ngày lập trình. Điều họ cần biết là liệu có thể tin vào sản phẩm khi đang chạy xe ngoài đường, pin sắp hết và trạm sạc gần nhất có thể cách hàng chục kilomet hay không.Khoảnh khắc đó khiến tôi nhận ra bức tường lớn nhất không nằm ở việc viết code.Nó nằm ở niềm tin của người dùng.Xây nhanh hơn không có nghĩa là hiểu người dùng nhanh hơnAI rất giỏi khi yêu cầu đã rõ ràng. Nhưng trong quá trình xây sản phẩm, phần khó nhất thường là xác định yêu cầu nào thực sự đáng để làm.Developer rất dễ bị cuốn vào những tính năng thú vị về mặt kỹ thuật. Chúng ta có thể dành nhiều ngày tối ưu animation, kiến trúc source code hoặc một thuật toán phức tạp, trong khi người dùng chỉ cần ba điều đơn giản:Thông tin có chính xác không?Thao tác có đủ dễ không?Sản phẩm có giải quyết được vấn đề ngay lúc họ cần không?AI có thể tạo ra mười phương án giao diện trong vài phút, nhưng không thể thay tôi quan sát một người dùng loay hoay vì không biết phải nhấn nút nào.AI có thể phân tích dữ liệu phản hồi, nhưng không tự cảm nhận được sự do dự khi người dùng chuẩn bị thanh toán.AI có thể viết nội dung quảng cáo rất hấp dẫn, nhưng không thể tạo ra niềm tin nếu sản phẩm chưa chứng minh được giá trị.Tốc độ phát triển tăng lên đôi khi còn tạo ra một chiếc bẫy: vì làm tính năng mới quá nhanh, chúng ta dễ lựa chọn xây thêm thay vì dừng lại để hỏi xem tính năng cũ có thật sự hữu ích hay không.Phần khó hơn tôi dự kiến: có sản phẩm rồi, tìm người dùng ở đâu?Trước đây, tôi từng nghĩ hành trình phát triển sản phẩm diễn ra theo một đường khá thẳng:Ý tưởng → xây dựng → phát hành → có người dùng → tạo doanh thu.Thực tế lại giống như:Ý tưởng → xây dựng → phát hiện giả định sai → sửa → tìm người dùng → không ai chú ý → thay đổi cách giới thiệu → có vài người dùng thử → họ rời đi → tiếp tục tìm nguyên nhân.Đưa ứng dụng lên App Store hay Google Play chỉ giúp sản phẩm tồn tại. Nó không khiến sản phẩm được khám phá.Một sản phẩm tốt nhưng không có kênh phân phối phù hợp vẫn có thể không có người dùng. Một tính năng hữu ích nhưng được mô tả bằng ngôn ngữ kỹ thuật cũng khó khiến khách hàng hiểu được giá trị. Và nếu người dùng thử một lần rồi không quay lại, việc có thêm lượt tải xuống cũng chưa tạo ra một sản phẩm bền vững.AI có thể giúp tôi viết bài giới thiệu, tạo hình ảnh hoặc đề xuất kế hoạch marketing. Tuy nhiên, những quyết định quan trọng vẫn cần trải nghiệm và hiểu biết thực tế:Nhóm người dùng đầu tiên là ai?Họ đang ở đâu?Vấn đề có đủ lớn để họ thay đổi thói quen không?Vì sao họ nên tin một sản phẩm mới?Điều gì khiến họ quay lại lần thứ hai?Giá trị nào đủ lớn để họ sẵn sàng trả tiền?Đây không còn là bài toán của riêng lập trình. Nó là bài toán về sản phẩm, phân phối, tâm lý và niềm tin.Những việc tôi vẫn chưa thể giao hoàn toàn cho AISau quá trình sử dụng AI để phát triển sản phẩm, tôi thấy có ba việc vẫn phụ thuộc rất nhiều vào con người.Thứ nhất là chọn đúng vấn đề.AI có thể gợi ý hàng trăm ý tưởng, nhưng người xây sản phẩm phải xác định vấn đề nào đang xảy ra đủ thường xuyên, đủ đau và có một nhóm người thực sự muốn giải quyết.Thứ hai là đọc được điều người dùng không nói trực tiếp.Người dùng có thể nói “ứng dụng hơi khó dùng”, nhưng nguyên nhân thật sự có thể là họ không tin dữ liệu, không hiểu lợi ích hoặc sợ thực hiện sai thao tác. Muốn tìm được nguyên nhân, chúng ta phải quan sát, hỏi tiếp và đặt phản hồi vào đúng bối cảnh.Thứ ba là đưa ra sự đánh đổi.Một startup hoặc đội sản phẩm luôn có giới hạn về thời gian, con người và ngân sách. Nên làm thêm tính năng, sửa trải nghiệm hiện tại hay tập trung tìm kênh phân phối? AI có thể phân tích lựa chọn, nhưng người chịu trách nhiệm vẫn phải quyết định và chấp nhận rủi ro.Nếu bắt đầu lại, tôi sẽ làm gì khác?Tôi vẫn sử dụng AI, thậm chí sử dụng nhiều hơn. Nhưng tôi sẽ thay đổi thứ tự ưu tiên.Trước khi viết quá nhiều code, tôi sẽ tìm từ 5 đến 10 người thuộc đúng nhóm khách hàng và trò chuyện với họ. Tôi muốn biết lần gần nhất họ gặp vấn đề là khi nào, hiện tại họ giải quyết bằng cách nào và điều gì khiến giải pháp đó chưa đủ tốt.Sau đó, tôi sẽ tạo phiên bản nhỏ nhất có thể kiểm chứng một giả định quan trọng. Không phải MVP có thật nhiều tính năng, mà là một sản phẩm đủ nhỏ để trả lời câu hỏi: “Người dùng có thật sự cần điều này không?”Tôi cũng sẽ nghĩ về phân phối ngay từ ngày đầu tiên:Ai sẽ là nhóm người dùng đầu tiên?Kênh nào có thể tiếp cận họ?Vì sao họ muốn chia sẻ sản phẩm cho người khác?Sản phẩm tạo ra giá trị trước hay chỉ yêu cầu người dùng đăng ký, cung cấp thông tin và trả tiền?Cuối cùng, tôi sẽ đo lường hành vi thay vì chỉ đếm lượt tải. Người dùng có hoàn thành hành động quan trọng không? Họ có quay lại không? Họ rời đi ở bước nào? Họ có sẵn sàng giới thiệu sản phẩm không?AI làm giảm chi phí xây dựng, nhưng làm tăng giá trị của việc lựa chọn đúngKhi bất kỳ ai cũng có thể tạo ra một ứng dụng nhanh hơn, lợi thế cạnh tranh sẽ không còn chỉ nằm ở khả năng viết code.Lợi thế sẽ thuộc về người hiểu khách hàng sâu hơn, kiểm chứng giả định sớm hơn, xây dựng được niềm tin và tìm ra cách đưa sản phẩm đến đúng người.AI có thể là một developer làm việc không biết mệt, một người hỗ trợ nghiên cứu hay một cộng sự giúp chúng ta thử nghiệm ý tưởng nhanh hơn. Nhưng AI không thể thay chúng ta gặp người dùng, chịu trách nhiệm cho lựa chọn và quyết định điều gì thực sự đáng để xây.Bài học lớn nhất của tôi là:Đừng dùng tốc độ của AI để xây thật nhanh một sản phẩm mà chưa ai cần. Hãy dùng tốc độ đó để học về người dùng nhanh hơn đối thủ.Còn với bạn, bức tường lớn nhất sau khi xây xong sản phẩm là gì: tìm người dùng đầu tiên, khiến họ quay lại hay thuyết phục họ trả tiền?

There is a strange irony in my relationship with AI.AI has contributed to me becoming unemployed.But unemployment gave me something I had been missing throughout years of full-time work:Time.And somehow, AI is also helping me turn that unexpected free time into an opportunity to pursue a dream I used to believe was far beyond what one person could realistically build.I do not just want to write a novel.My dream is a little bigger than that:I want to build a virtual world of my own.The novel is only the foundation.If I can take it far enough, I want that world to eventually have its own website, structured data, voices, visuals, videos, games, and perhaps one day, even films.That sounds fairly ambitious for someone who is currently unemployed.Yet strangely enough, at the very moment when AI makes me most uncertain about my career, it is also making me feel for the first time that:Maybe I really can start building this on my own.After 10 years as a developer, I started wondering: how valuable is writing code itself anymore?I have been working as a developer for around 10 years.That makes the speed at which AI is changing software development impossible for me to ignore.In the past, implementing a feature might start with reading requirements, navigating the codebase, understanding the existing flow, writing code, debugging, refactoring, testing, and so on.Today, AI can participate in almost every part of that process.Need a component?AI can write it.Need to refactor a function?AI can propose several approaches.Do not understand a piece of legacy code?AI can explain it.Need to figure out where a state is being modified across a large project?Give AI enough of the codebase and ask it to trace the flow.Regex, SQL, scripts, test cases, documentation, migrations, data processing...The list keeps getting longer.And what actually worries me is not that AI can write a function.The bigger question is:How much more work can one developer with AI accomplish compared with that same developer a few years ago?If a team once needed ten people, will it still need all ten in the future?I do not know.But I do know that I am gradually becoming evidence for why that question exists.Because the better I become at using AI, the more work I can handle by myself.Then, while the industry was going through all these changes, I became unemployed.I do not believe AI was the only cause. The economy, company downsizing, hiring demand, and many other factors all played a role.But for me, AI is clearly part of the larger shift that is taking place.And that leaves me in a rather ironic position:The technology that makes me worry that companies may need fewer people like me is also making me need fewer people to build my own projects.I no longer use AI just to write codeAt first, I used AI in much the same way many developers do:Task → ask AI → get code → modify it → run it.Over time, that workflow began to change.I stopped thinking of AI as merely a smarter autocomplete.Instead, I started giving it entire chains of work.Read the codebase.Find the relevant files.Analyze the problem.Suggest possible solutions.Implement one.Review the changes.Fix the issues.Generate a patch.Check what else might be affected.I gradually moved from asking isolated questions toward a more agentic workflow: breaking larger objectives into multiple steps and letting AI work through those steps under my supervision.For some tasks that I previously had to perform manually from beginning to end, I can now start with a different question:What result do I actually want at the end?Then I design a workflow that allows AI to move toward that result.Once I started thinking this way, I began looking at almost everything around me with a developer's instinct:“Can I automate this?”I started digitizing almost everything I doThis is probably where AI started changing not only how I code, but how I live.I run a rental shop.Instead of searching for an existing management system and forcing my workflow to fit somebody else's software, I can build my own system around the way my shop actually operates.Missing a feature?Build it.The workflow changes?Modify it.Need a new type of report?Add it.Want to produce audio content?I build my own TTS tool.Need a workflow for creating videos?I build video-processing tools.Want to collect social videos as research material and build my own dataset?I write tools to help with that.Whenever I encounter a repetitive task, my first instinct is increasingly to figure out how to automate it.Many of these tools are things I probably would never have built in the past.If writing one from scratch required several days or weeks of development, the problem simply would not have been important enough to justify the effort.AI changes that equation dramatically.An idea I have in the morning can sometimes become a working prototype by the evening.It may not be elegant.It may not be complete.But it works.And for me, that is a significant change.In the past, software was mostly something I built for companies or clients.Now I increasingly build software to increase my own capabilities.From software developer to someone who builds tools for himselfThis is probably the most interesting part of AI to me.Someone without a programming background can already do a great deal with AI.But when someone who already understands software development gains access to AI, the leverage becomes even greater.When AI gives me a piece of code, I do not have to blindly trust it.I can read it.I can see where the architecture is heading.I can recognize excessive coupling.I can tell when a piece of logic will become difficult to maintain.I can spot unnecessary abstraction.I know the difference between a quick hack that happens to work and something that has a reasonable path toward future expansion.After roughly ten years in the profession, what AI accelerates for me is no longer simply my ability to write code.It accelerates my ability to turn an idea into software.Those are not exactly the same thing.And the more I use AI, the more I realize:Programming experience does not become worthless because of AI. Its value shifts from “being able to manually write every line of code” toward “knowing what should be built, how it should be built, and whether AI is doing it correctly.”Of course, I had to pay some tuition to learn that lesson.And some of it was expensive.I trusted AI too much once and ended up with a pile of garbage I could no longer debugThere was a period when I became accustomed to how quickly AI could modify code.A bug appeared?Give it to AI.AI fixed it.Another bug?Give it back.It fixed that too.The application seemed to work.Keep going.New feature?Add another patch.Patch on top of patch.And because results arrived so quickly, there were times when I skipped something no experienced developer should skip:Code review.Eventually, the source still worked in certain flows, but internally the architecture had turned into a mess.Fix one thing, break another.AI would read code that AI itself had generated and add yet another patch on top of it.The context kept growing.The original architectural decisions gradually disappeared.Eventually, I reached the worst possible state:I could no longer debug it.The price was rewriting a large portion of the codebase from scratch.Painful.But useful.It taught me a rule I now try very hard to follow:AI can write code extremely quickly. But I am still responsible for the codebase.Skipping review because “AI probably got it right” is basically the same as merging code from a developer you have never met without reading the diff.Except this particular developer can generate thousands of lines of code while you are making coffee.Then sometimes I go too far in the opposite directionAfter that experience, I became much more careful about reviewing AI-generated code.Sometimes perhaps... too careful.This is where ten years of programming habits become a slightly ridiculous problem.I look at a piece of AI-generated code and think:“It works, but it is ugly.”So I ask AI to rewrite it.“This function is too long.”Rewrite it.“Separate the responsibilities.”Rewrite it.“This naming does not follow the convention.”Rewrite it.“This architecture will be difficult to extend later.”Rewrite it.“Refactor it and make it clean.”Rewrite it again.Eventually, I may have spent several hours polishing a personal tool that I will use only a few times a month.No additional revenue.No user cares.No additional problem has been solved.But the code looks beautiful.Beautiful in a way that is... economically meaningless.This may be one of my hardest old habits to break.Years of software development taught me that code should be clean, maintainable, standardized, and extensible.That is not wrong.But AI increases the speed of software creation so dramatically that another question becomes much more important:“Is this piece of code actually worth another two hours of polishing?”I still do not always answer that question correctly.Sometimes I am working on a tool that only I use, glance at the clock after midnight, and realize:I just refactored something that will probably never need to scale.AI saved me three hours of writing code.Then I spent exactly those three hours asking AI to make the code prettier.Net time saved: zero.Very developer of me.AI does not give me more free time. It gives me the ability to do moreAnd that is probably my answer to the question “Easier or Busier with AI?”For each individual task:Much easier.For my life as a whole:Busier.Something that used to take four hours may now take one.But those other three hours do not magically become leisure time.Instead, I think:“Then I can build this too.”Already have a TTS tool?Build the next stage of the audio pipeline.Already have a website?Improve the data system.Already have the data?Automate more of the workflow.Automation works?Start thinking about which parts can be delegated to agents.AI does not make my to-do list shorter.It removes the limits on what I am willing to put on that list.And that is also how an old dream started becoming much more serious.15 years of reading fiction, 10 years of programming, and a dream that may be a little too ambitiousI have been reading fiction for around 15 years.Long enough to accumulate a great deal of knowledge that I never really thought of as “experience.”I have read enough stories to feel when a character's actions are unnatural.When a plotline is being forced.When a new power appears only because the protagonist needs to be saved.When a fictional world exists merely as background decoration rather than as a place governed by its own rules.I know what kind of worlds I enjoy.What types of plot devices I dislike.How I want characters to grow.And I want to build a world of my own.Thiên Đạo Chi Lộ started from that desire.But my ultimate goal is not simply to finish a novel.I want to build a world/IP that can exist across different forms of media.The novel is the foundation because it is the most accessible way to establish the lore, characters, history, geography, power systems, and conflicts of that world.But from that foundation, I want to keep experimenting.Audio.Images.Video.Interactive websites.Games.And, if I ever reach that point, films.Perhaps I will never make it to the final stage.But the important difference is that, for the first time, I can look at that entire chain and no longer immediately think:“You would need an entire company to do this.”Instead, I ask:“Which part can I build myself first?”AI does not replace my 15 years of reading or my 10 years of programmingThis is something I find particularly interesting.People often ask whether AI will make experience meaningless.My experience has been almost the opposite.The stronger AI becomes, the more valuable my accumulated experience feels.With code, I have around ten years of experience helping me recognize when AI is producing a reasonable solution and when it is building a technical time bomb.With fiction, I have spent around fifteen years reading enough stories to look at an idea AI proposes and say:“No.”“Too cliché.”“That character would never do that.”“This is too convenient.”“The world does not work that way.”“This idea is good, but it needs to be foreshadowed a hundred chapters earlier.”I do not need AI to make decisions for me.I need it to generate possibilities faster than I could generate them myself.Then I review.Challenge.Reject.Combine.Redirect.And ask it to continue.Seen this way, my role is changing significantly.In the past, I personally produced most of the output.Now, for many kinds of work, I increasingly behave like the person who designs the system, defines the standards, and reviews the output.Almost like a Tech Lead.Except sometimes my entire team is made of AI.The good news is that this team never asks for a raise.The bad news is that if I give it insufficient context, it can enthusiastically destroy production.From chatbot to AI agentsI think this is also the most important evolution in how I use AI.If I use AI only like this:“Write this function.”“Rewrite this paragraph.”“Create this prompt.”then AI is extremely useful, but it is still mostly a tool that responds to individual instructions.What interests me now is something different:AI executing an entire workflow.For example, an agent could receive an objective, inspect the current data, determine which steps are required, call the appropriate tools, generate an output, validate the result, and then hand it over to the next stage.Another agent could handle content.Another could review logic.Another could process data.Another could work on code.Automation can connect all of those stages.Of course, I still need to supervise a lot of it.And after letting AI turn one codebase into an undebuggable mess, I no longer believe in the fantasy of “press one button and AI will do everything.”But the direction itself fascinates me.Because when AI can use the tools I build, while I can also use AI to build new tools for AI...a rather interesting feedback loop appears:I use AI to build tools.Those tools allow AI to do more.A more capable AI workflow then helps me build the next generation of tools faster.For an individual, that is a level of leverage that I could barely imagine having only a few years ago.Maybe what I am building is not actually a novelThe further I go, the more I realize that Thiên Đạo Chi Lộ is only the most visible part.What I really want to build behind it is a system.A place where lore is stored in structured form.Characters have timelines.Factions have relationships.Events have causes and consequences.A website can consume that data.A TTS tool can transform the content into audio.Video tools can use character and world data to assist with content production.One day, perhaps a game could use the same data.And if the world expands further, other forms of media could still be built on top of the same foundation.At that point, my programming background and my love of fiction stop being two separate interests.They finally meet.Fifteen years of reading stories gives me the intuition for the world I want to create.Ten years of programming gives me the ability to turn that world into systems.AI gives me the leverage to attempt it at a scale I would never previously have considered possible for one person.That is the real dream.And I am still anxious about AII do not believe the statement:“AI is just a tool. There is nothing to worry about.”I think there is plenty to worry about.Repetitive jobs will be affected.Teams may become smaller.One person with AI can handle workloads that previously required several people.Productivity expectations will continue rising.And software development may gradually have to move away from measuring a developer's value by how much code they can personally write.That is frightening.Especially when I am the one looking for a job during this transition.But there is another truth I cannot ignore:If AI allows a company to accomplish more with fewer people, it also allows an individual to attempt things that previously only a company had enough resources to build.Those are not two different phenomena.They are two sides of the same one.The difference is simply which side of the table I am sitting on.As an employee, it scares me.As someone trying to create something of my own, it looks like an enormous door opening.The thing that helped take away my job may also help me build one for myselfI am still looking for work.I am still a developer.And if the right opportunity appears tomorrow, I will probably continue working professionally just as I did before.But something has changed.In the past, I believed that pursuing this dream would require:More money.More time.A writer.A designer.A video editor.A development team.Marketing.Perhaps even an entire studio.I no longer wait until I have all of those things.I am starting with what I already have:15 years of reading fiction.10 years of software development.A computer.The unexpected time that unemployment gave me.And AI.AI contributed to me losing my job.Unemployment gave me time to begin.Experience gives me the ability to review and guide AI.And AI gives someone like me the ability to code, build tools, automate workflows, create content, and gradually construct a world that I once believed would require an entire team.So has AI made my life easier or busier?Both.It makes each individual task easier.But it also makes the things I am willing to dream about much bigger.And when the dream gets bigger, the amount of work never really gets smaller.It is rather ironic that the technology that once made me ask:“Will companies still need a developer like me a few years from now?”is now making me ask a completely different question:“With AI, how much can a developer like me build on his own?”I do not know the answer yet.But at least now, I have the time to find out.

Có một nghịch lý khá buồn cười trong câu chuyện của tôi với AI.AI góp phần khiến tôi thất nghiệp.Nhưng thất nghiệp lại cho tôi thứ mà suốt nhiều năm đi làm full-time tôi luôn thiếu:Thời gian.Và rồi cũng chính AI giúp tôi biến khoảng thời gian bất đắc dĩ đó thành cơ hội để theo đuổi một giấc mơ mà trước đây tôi luôn nghĩ rằng một cá nhân không đủ nguồn lực để làm.Không chỉ là viết một bộ truyện.Ước mơ của tôi lớn hơn một chút:Tôi muốn xây dựng một thế giới ảo của riêng mình.Truyện chỉ là nền móng đầu tiên.Nếu có thể đi đủ xa, tôi muốn thế giới ấy có website, dữ liệu, hình ảnh, giọng nói, video, game, thậm chí một ngày nào đó là phim.Nghe khá tham vọng đối với một người đang thất nghiệp.Nhưng điều kỳ lạ là chính trong thời đại AI khiến tôi hoang mang nhất về nghề nghiệp, tôi lại lần đầu tiên cảm thấy:Có lẽ một mình mình thật sự có khả năng bắt đầu làm việc đó.Sau 10 năm làm lập trình, lần đầu tiên tôi tự hỏi: viết code còn đáng giá bao nhiêu?Tôi đã làm lập trình khoảng 10 năm.Vì vậy tôi cảm nhận rất rõ tốc độ AI đang thay đổi công việc này.Ngày trước, một feature có thể bắt đầu bằng việc đọc requirement, tìm source, xác định luồng xử lý, viết code, debug, refactor, test...Bây giờ rất nhiều đoạn trong quy trình đó đã có AI tham gia.Một component?AI viết.Một function cần refactor?AI đưa phương án.Không hiểu một đoạn code cũ?AI giải thích.Cần tìm nơi một state được thay đổi trong một project lớn?Cho AI đọc source.Regex, SQL, script, test case, documentation, migration, xử lý dữ liệu...AI ngày càng làm được nhiều hơn.Và điều khiến tôi thực sự lo lắng không phải chuyện AI có thể viết một function.Mà là:Một developer biết dùng AI có thể làm được bao nhiêu công việc so với chính developer đó vài năm trước?Nếu trước đây một team cần 10 người, sau này liệu có còn cần đủ 10 người?Tôi không biết.Nhưng tôi biết chính mình đang trở thành bằng chứng cho câu hỏi đó.Bởi càng dùng AI, lượng công việc một mình tôi có thể xử lý càng lớn.Rồi giữa lúc thị trường thay đổi, tôi thất nghiệp.Tôi không cho rằng AI là nguyên nhân duy nhất. Kinh tế, doanh nghiệp cắt giảm nhân sự, thị trường tuyển dụng và rất nhiều yếu tố khác đều có ảnh hưởng.Nhưng với riêng tôi, AI rõ ràng là một phần của sự thay đổi đang diễn ra.Và thế là tôi rơi vào một tình huống khá trớ trêu:Thứ khiến tôi lo mình không còn cần thiết với doanh nghiệp lại đang giúp tôi ngày càng ít cần đến một đội ngũ để làm những dự án của riêng mình.Tôi không chỉ dùng AI để viết code nữaBan đầu cách tôi dùng AI khá giống nhiều lập trình viên khác:Có task → hỏi AI → lấy code → sửa → chạy.Nhưng dần dần workflow thay đổi.Tôi bắt đầu không nhìn AI như một autocomplete thông minh nữa.Tôi bắt đầu giao cho nó cả một chuỗi công việc.Đọc source.Tìm các file liên quan.Phân tích vấn đề.Đề xuất hướng xử lý.Viết code.Chạy lại logic.Review thay đổi.Sửa tiếp.Tạo patch.Kiểm tra những phần có khả năng bị ảnh hưởng.Từ một câu hỏi đơn lẻ, tôi chuyển dần sang cách làm mang tính agentic hơn: chia mục tiêu lớn thành nhiều bước và để AI xử lý từng phần dưới sự giám sát của mình.Có những việc trước đây tôi phải ngồi làm từng bước bằng tay, bây giờ tôi chỉ cần định nghĩa:Tôi muốn kết quả cuối cùng là gì?Rồi xây workflow để AI tiến dần tới đó.Và khi đã quen với cách nghĩ này, tôi bắt đầu nhìn mọi công việc xung quanh bằng con mắt của một developer:“Cái này có tự động hóa được không?”Tôi bắt đầu số hóa gần như mọi thứ mình làmĐây có lẽ là lúc AI thực sự thay đổi cách tôi sống chứ không chỉ cách tôi code.Tôi có một cửa hàng cho thuê đồ.Thay vì tìm một phần mềm rồi cố ép quy trình của mình vào cách phần mềm đó hoạt động, tôi có thể tự xây một hệ thống quản lý phù hợp với chính cửa hàng của mình.Thiếu chức năng?Viết thêm.Quy trình thay đổi?Sửa.Cần thống kê một kiểu mới?Thêm.Tôi muốn làm nội dung audio?Tôi tự viết tool TTS.Muốn phục vụ quy trình làm video?Tự xây tool hỗ trợ video.Muốn thu thập các video social phục vụ việc nghiên cứu và xây dựng nguồn dữ liệu của riêng mình?Tôi viết công cụ hỗ trợ.Có một thao tác lặp đi lặp lại?Tôi nghĩ cách tự động hóa nó.Điều thú vị là rất nhiều tool trong số đó nếu trước đây phải tự viết hoàn toàn từ đầu, có thể tôi sẽ bỏ cuộc vì chúng không đủ quan trọng để dành vài ngày hoặc vài tuần phát triển.Nhưng với AI, chi phí để tạo một công cụ nhỏ giảm xuống rất mạnh.Một ý tưởng xuất hiện vào buổi sáng có thể đến buổi tối đã có prototype.Nó chưa chắc đẹp.Chưa chắc hoàn chỉnh.Nhưng nó chạy được.Và với tôi, đó là một thay đổi rất lớn.Ngày trước, phần mềm chủ yếu là thứ tôi viết cho công ty hoặc khách hàng.Bây giờ, tôi bắt đầu viết phần mềm để tăng năng lực cho chính mình.Từ lập trình viên thành người xây công cụ cho chính mìnhĐây là điểm mà tôi thấy AI thú vị nhất.Một người không biết lập trình có AI có thể làm được rất nhiều thứ.Nhưng một người đã có nền tảng lập trình rồi có thêm AI thì khả năng mở rộng còn lớn hơn nữa.Bởi khi AI đưa ra một đoạn code, tôi không nhất thiết phải tin nó.Tôi có thể đọc.Tôi biết architecture đang đi về đâu.Tôi biết đoạn này đang coupling quá chặt.Biết logic này sẽ khó maintain.Biết abstraction kia là thừa.Biết chỗ nào đang hack cho chạy và chỗ nào thực sự có thể mở rộng.Sau khoảng 10 năm làm nghề, điều AI tăng tốc cho tôi không chỉ là khả năng viết code.Nó tăng tốc khả năng biến một ý tưởng thành phần mềm.Hai thứ đó không hoàn toàn giống nhau.Và càng dùng AI, tôi càng nhận ra:Giá trị của kinh nghiệm lập trình không biến mất. Nó chuyển từ “tự tay viết từng dòng code” sang “biết nên xây cái gì, xây như thế nào và biết AI đang làm đúng hay sai”.Nhưng tôi cũng phải trả học phí cho bài học đó.Có lúc khá đắt.Tôi từng tin AI quá mức và nhận lại một đống rác không thể debugCó một giai đoạn tôi bắt đầu quen với việc AI sửa code rất nhanh.Một lỗi xuất hiện?Đưa cho AI.AI sửa.Lỗi khác?Đưa tiếp.Nó lại sửa.Thấy chạy được.Tiếp tục.Feature mới?Lại thêm.Patch chồng patch.Và vì kết quả đến quá nhanh, có lúc tôi bỏ qua thứ mà một lập trình viên đáng lẽ không bao giờ được bỏ qua:Review.Đến một thời điểm, source vẫn chạy ở một số luồng nhưng cấu trúc bên trong đã trở thành một mớ hỗn độn.Fix chỗ này vỡ chỗ khác.AI đọc phần code do chính AI tạo ra rồi tiếp tục vá lên nó.Context ngày càng lớn.Các quyết định architecture ban đầu bị phá vỡ dần.Cuối cùng tôi rơi vào trạng thái tồi tệ nhất:Không thể debug nổi nữa.Và cái giá phải trả là viết lại một phần rất lớn source code từ đầu.Khá đau.Nhưng cũng rất đáng giá.Nó khiến tôi nhận ra một nguyên tắc mà bây giờ tôi gần như luôn cố giữ:AI có thể code rất nhanh. Nhưng người chịu trách nhiệm cho source vẫn phải là tôi.Không review vì “AI chắc đúng” chẳng khác gì merge code của một developer mình chưa từng gặp mà không đọc diff.Chỉ khác ở chỗ developer này có thể viết vài nghìn dòng trong lúc mình đi pha cà phê.Nhưng đôi lúc tôi lại đi sang cực đoan ngược lạiSau cú đó, tôi review AI kỹ hơn.Có lẽ đôi khi… kỹ quá.Đây là nơi 10 năm làm nghề lại tạo ra một vấn đề khá buồn cười.Tôi nhìn đoạn code AI viết và nghĩ:“Chạy thì chạy đấy, nhưng xấu.”Rồi bắt nó sửa.“Function này dài quá.”Sửa.“Tách responsibility ra.”Sửa.“Tên này không đúng convention.”Sửa.“Architecture này sau này khó mở rộng.”Sửa.“Refactor lại cho clean.”Sửa tiếp.Đến lúc nhìn lại, tôi có thể đã dành vài tiếng để làm đẹp một tool cá nhân mà tổng cộng cả tháng chạy vài lần.Không thêm doanh thu.Không có user nào quan tâm.Không giải quyết thêm vấn đề gì.Nhưng code thì rất đẹp.Đẹp một cách... vô nghĩa về kinh tế.Đây có lẽ là một trong những thói quen cũ khó bỏ nhất của tôi.Làm developer lâu năm khiến tôi quen với suy nghĩ rằng code phải sạch, phải chuẩn, phải dễ mở rộng.Điều đó không sai.Nhưng AI khiến tốc độ tạo phần mềm tăng lên đến mức một câu hỏi khác trở nên quan trọng hơn:“Đoạn code này có thực sự đáng để mình dành thêm hai tiếng làm đẹp không?”Tôi vẫn chưa phải lúc nào cũng trả lời được đúng.Có hôm tôi đang làm một tool dùng cho chính mình, nhìn đồng hồ đã qua nửa đêm và chợt nhận ra:Tôi vừa refactor một thứ mà có lẽ chẳng bao giờ cần mở rộng.AI giúp tôi tiết kiệm ba tiếng viết code.Sau đó tôi dùng đúng ba tiếng đó để bắt AI viết lại code cho đẹp hơn.Không lời được phút nào.Đúng chất lập trình viên.AI không làm tôi rảnh hơn. Nó khiến tôi có khả năng làm nhiều việc hơnĐó cũng là câu trả lời của tôi cho chủ đề “Easier or Busier with AI?”Nếu xét từng task:Dễ hơn rất nhiều.Nhưng xét tổng thể cuộc sống:Tôi bận hơn.Trước đây một việc mất bốn tiếng.Bây giờ mất một tiếng.Nhưng ba tiếng còn lại không biến thành thời gian nghỉ.Tôi nghĩ:“Vậy làm thêm cái này.”Có tool TTS rồi?Làm tiếp pipeline audio.Có website rồi?Tối ưu dữ liệu.Có dữ liệu rồi?Nghĩ đến automation.Automation chạy được?Nghĩ tiếp xem phần nào có thể giao cho agent.AI không làm danh sách công việc của tôi ngắn lại.Nó làm giới hạn của danh sách đó biến mất.Và đây cũng là lúc một giấc mơ cũ bắt đầu trở nên nghiêm túc hơn.15 năm đọc truyện, 10 năm viết code và một giấc mơ hơi quá sứcTôi đọc truyện khoảng 15 năm.Đủ lâu để trong đầu tích lũy rất nhiều thứ mà trước đây tôi chưa từng nghĩ có thể gọi là “kinh nghiệm”.Tôi đọc đủ nhiều để cảm nhận khi một nhân vật hành động không tự nhiên.Khi một tuyến truyện đang bị ép.Khi một sức mạnh xuất hiện chỉ để cứu nhân vật chính.Khi thế giới tồn tại như phông nền thay vì một nơi có quy luật riêng.Tôi biết mình thích kiểu thế giới nào.Ghét kiểu tình tiết nào.Muốn nhân vật phát triển ra sao.Và tôi muốn xây một thế giới của riêng mình.Thiên Đạo Chi Lộ bắt đầu từ đó.Nhưng mục tiêu cuối cùng của tôi không chỉ là có một bộ tiểu thuyết.Tôi muốn xây dựng một world/IP có khả năng tồn tại ở nhiều hình thức khác nhau.Truyện là nền tảng vì nó là cách rẻ nhất để xây lore, nhân vật, lịch sử, địa lý, hệ thống sức mạnh và những xung đột của thế giới.Nhưng từ nền tảng đó, tôi muốn thử tiếp.Audio.Hình ảnh.Video.Website tương tác.Game.Và nếu một ngày đủ khả năng, phim.Có thể tôi sẽ không bao giờ đi được đến bước cuối.Nhưng điều quan trọng là lần đầu tiên tôi nhìn toàn bộ chuỗi đó và không còn nghĩ:“Muốn làm cái này chắc phải có cả một công ty.”Tôi bắt đầu nghĩ:“Phần nào mình có thể tự làm trước?”AI không thay thế 15 năm đọc truyện hay 10 năm lập trình của tôiĐây là điều tôi thấy khá thú vị.Người ta thường hỏi AI có làm kinh nghiệm trở nên vô nghĩa không.Trải nghiệm của tôi lại gần như ngược lại.AI càng mạnh, tôi càng thấy những năm mình đã tích lũy kinh nghiệm có giá trị.Với code, tôi có khoảng 10 năm để biết lúc nào AI đang tạo ra một giải pháp ổn và lúc nào nó đang xây một quả bom kỹ thuật.Với truyện, tôi có khoảng 15 năm đọc đủ nhiều để nhìn một ý tưởng AI đưa ra và nói:“Không.”“Quá cliché.”“Nhân vật sẽ không làm vậy.”“Đoạn này tiện quá.”“Thế giới không vận hành như thế.”“Ý này hay, nhưng phải gieo từ 100 chương trước.”Tôi không cần AI quyết định thay mình.Tôi cần nó tạo phương án nhanh hơn khả năng tôi tự tạo.Sau đó tôi review.Phản biện.Loại bỏ.Ghép lại.Định hướng.Và bắt nó làm tiếp.Nếu nhìn theo cách đó, vai trò của tôi đang thay đổi khá nhiều.Trước đây tôi là người trực tiếp sản xuất phần lớn đầu ra.Bây giờ ở nhiều công việc, tôi giống người thiết kế hệ thống, đưa ra tiêu chuẩn và review đầu ra hơn.Khá giống Tech Lead.Chỉ có điều team của tôi đôi lúc toàn là AI.Và thành viên này không đòi tăng lương, nhưng nếu giao task thiếu context thì có khả năng phá production với tinh thần làm việc cực kỳ nhiệt tình.Từ chatbot đến AI agentTôi nghĩ đây cũng là bước thay đổi quan trọng nhất trong cách tôi dùng AI.Nếu chỉ dùng AI theo kiểu:“Hãy viết function này.”“Hãy sửa đoạn text này.”“Hãy tạo prompt kia.”thì AI rất hữu ích, nhưng vẫn chỉ là một công cụ phản hồi yêu cầu.Điều tôi đang muốn tiến tới là một hệ thống khác:AI có thể thực hiện cả workflow.Ví dụ một agent có thể nhận một mục tiêu, đọc dữ liệu hiện tại, xác định các bước cần làm, gọi tool phù hợp, tạo đầu ra, kiểm tra kết quả rồi chuyển cho bước tiếp theo.Một agent khác xử lý nội dung.Một agent rà logic.Một agent làm dữ liệu.Một agent hỗ trợ code.Một workflow tự động có thể nối những việc đó lại với nhau.Tất nhiên hiện tại tôi vẫn phải kiểm soát rất nhiều.Và sau lần để AI biến source thành đống rác, tôi cũng không còn mơ mộng chuyện “bấm nút rồi AI làm hết”.Nhưng hướng đi đó khiến tôi cực kỳ hứng thú.Bởi khi AI có thể sử dụng chính những công cụ mà tôi viết, còn tôi lại có thể dùng AI để viết thêm công cụ mới cho nó...thì xuất hiện một vòng lặp khá đặc biệt:Tôi dùng AI để xây tool.Tool giúp AI làm được nhiều việc hơn.AI mạnh hơn lại giúp tôi xây tool mới nhanh hơn.Với một cá nhân, đây là một dạng đòn bẩy mà vài năm trước tôi gần như không thể có.Có lẽ thứ tôi đang xây không phải một bộ truyệnCàng làm, tôi càng nhận ra Thiên Đạo Chi Lộ chỉ là thứ dễ nhìn thấy nhất.Thứ tôi thực sự muốn xây phía sau nó là một hệ thống.Một nơi lore được lưu trữ có cấu trúc.Nhân vật có timeline.Thế lực có quan hệ.Sự kiện có nguyên nhân và hậu quả.Website có thể đọc dữ liệu đó.Tool TTS có thể biến nội dung thành audio.Tool video có thể lấy dữ liệu nhân vật và thế giới để hỗ trợ tạo nội dung.Một ngày nào đó game có thể dùng chính dữ liệu đó.Và nếu đi xa hơn nữa, những hình thức nội dung khác vẫn dựa trên cùng một thế giới.Lúc đó, kỹ năng lập trình và sở thích đọc truyện của tôi không còn là hai thứ tách biệt.Chúng gặp nhau.15 năm đọc truyện cho tôi cảm giác về thế giới mà mình muốn xây.10 năm lập trình cho tôi khả năng biến thế giới đó thành hệ thống.AI cho tôi lực lượng để thử làm nó với quy mô mà trước đây một mình tôi không dám nghĩ tới.Đó mới thực sự là giấc mơ của tôi.Và vì thế tôi vẫn hoang mang vì AITôi không tin câu:“AI chỉ là công cụ, không có gì phải lo.”Tôi nghĩ có rất nhiều thứ phải lo.Những công việc mang tính lặp lại sẽ bị ảnh hưởng.Team có thể nhỏ đi.Một người có AI có thể xử lý khối lượng việc trước đây cần nhiều người.Tiêu chuẩn năng suất sẽ tiếp tục tăng.Và nghề lập trình có lẽ sẽ phải dần rời khỏi việc đánh giá một người bằng số dòng code họ có thể viết.Điều đó đáng sợ.Đặc biệt khi chính tôi là người đang tìm việc trong thời điểm này.Nhưng có một sự thật khác mà tôi cũng không thể phủ nhận:Nếu AI khiến một công ty có thể làm nhiều việc hơn với ít người hơn, thì nó cũng khiến một cá nhân có thể làm được những việc trước đây chỉ công ty mới đủ nguồn lực làm.Hai mặt đó thực ra là cùng một hiện tượng.Chỉ khác việc mình đang đứng ở phía nào.Khi đứng ở vị trí người lao động, nó khiến tôi sợ.Khi đứng ở vị trí người muốn tạo ra một sản phẩm của riêng mình, nó khiến tôi thấy một cánh cửa rất lớn đang mở ra.Thứ lấy mất công việc của tôi cũng đang giúp tôi tự xây công việc cho mìnhTôi vẫn đang tìm việc.Tôi vẫn là một lập trình viên.Và có lẽ nếu ngày mai có một công việc phù hợp, tôi vẫn tiếp tục đi làm như trước.Nhưng có một thứ đã thay đổi.Trước đây tôi nghĩ muốn theo đuổi giấc mơ này, mình cần:Nhiều tiền hơn.Nhiều thời gian hơn.Một writer.Một designer.Một video editor.Một team developer.Marketing.Có thể cả một studio.Bây giờ tôi không còn đợi đủ tất cả những thứ đó nữa.Tôi bắt đầu từ những gì mình đang có:15 năm đọc truyện.10 năm làm lập trình.Một chiếc máy tính.Khoảng thời gian bất đắc dĩ sau khi thất nghiệp.Và AI.AI góp phần khiến tôi thất nghiệp.Thất nghiệp cho tôi thời gian để bắt đầu.Kinh nghiệm giúp tôi biết cách review và định hướng AI.Còn AI giúp một cá nhân như tôi có thể code, xây tool, tự động hóa workflow, làm nội dung và từng bước dựng nên một thế giới mà trước đây tôi luôn nghĩ phải cần cả một đội ngũ.Vậy AI khiến tôi Easier hay Busier?Cả hai.Nó khiến từng công việc dễ hơn.Nhưng khiến những thứ tôi dám mơ tới lớn hơn.Và khi giấc mơ lớn lên, công việc chẳng bao giờ ít đi.Khá trớ trêu khi thứ từng khiến tôi tự hỏi:“Liệu vài năm nữa người ta còn cần một lập trình viên như mình không?”lại đang khiến tôi đặt ra một câu hỏi hoàn toàn khác:“Với AI, một lập trình viên như mình có thể tự xây được bao nhiêu thứ?”Tôi chưa biết câu trả lời.Nhưng ít nhất bây giờ tôi có thời gian để thử.

Một buổi sáng, cả team dev chỗ tôi nhận thông báo: công cụ AI đang dùng đổi cách tính tiền. Trước đó mỗi người 300 request/tháng, dùng thả ga. Giờ chuyển sang trả theo token — dùng tới đâu tính tiền tới đó. Công ty tính lại chi phí, nên đã chuyển sang một AI agent khác có cách tính tương tự nhưng được đánh giá tốt hơn.Nghe chỉ là chuyện đổi công cụ. Nhưng suy nghĩ đầu tiên trong đầu của tôi là sao lại tăng giá rồi, nó làm tôi nhớ đến một hình ảnh không mấy dễ chịu: rau hẹ được nuôi rồi cắt cũng như gà được nuôi béo chuẩn bị làm thịt.Giai đoạn vỗ béo: khi mọi thứ rẻ đến mức đáng ngờHãy nhớ lại vài năm qua. Công cụ AI rẻ như cho, hào phóng, gần như miễn phí. Hạn mức rộng rãi, model xịn cho dùng thoải mái. Chúng ta vui vẻ "ăn no": mọi task đều mở agent ra trước, code tay thưa dần, và năng suất tăng đều.Nhưng không hãng nào đốt tiền mãi vì lòng tốt. Giá rẻ giai đoạn đầu là để làm một việc: khiến chúng ta quen, rồi lệ thuộc. Khi cả một quy trình làm việc, cả một thói quen tư duy đã gắn chặt vào công cụ, thì việc gỡ ra tốn kém hơn so với việc cắn răng trả thêm tiền. Đó là lúc con gà đã đủ béo.Giai đoạn làm thịt: hóa đơn bắt đầu nói chuyệnVà rồi giá đổi. Với người dùng agent nhiều, chi phí có thể nhảy lên gấp nhiều lần chỉ sau một thông báo. Không cần ai làm gì sai — đơn giản là giai đoạn trợ giá kết thúc, đến lượt thu hồi vón từ các công ty. Đây là quy luật của mọi làn sóng công nghệ, không riêng gì AI.Câu hỏi đáng sợ không phải "công cụ nào rẻ nhất bây giờ", mà là: nếu mai nó tăng giá gấp ba, hoặc công ty cắt quyền truy cập, mình còn code được không?Vậy giỏi code thôi đã đủ để sống sót trong ngành chưa?Tôi nghĩ là chưa — nhưng có lẽ không theo cách nhiều người tưởng.Trước đây "giỏi" nghĩa là viết được code tốt. Giờ AI viết được phần lớn code tốt đó. Nếu năng lực của bạn chỉ là gõ ra dòng lệnh, thì thứ đó đang rẻ đi từng ngày, và bạn cũng đang bị "vỗ béo" để một ngày dễ bị thay thế — bởi công cụ, hoặc bởi người dùng công cụ giỏi hơn.Những thứ không thể rẻ đi, và cũng không ai cắt giá hay thay thế được của bạn, là những thứ AI chưa làm thay: khả năng đọc hiểu một hệ thống, debug khi mọi thứ cháy, đánh giá một giải pháp đúng hay sai, và biết khi nào không nên tin output của agent. Càng dùng AI nhiều, kỹ năng thẩm định này càng quý, chứ không phải càng thừa.Nên định hướng của tôi gói trong ba điều: giữ vững nền tảng (AI viết hộ, nhưng người chịu trách nhiệm khi nó sai vẫn là bạn); tránh khoá cứng vào một nhà cung cấp (ưu tiên giải pháp cho đổi model, mã nguồn mở); và coi AI là đòn bẩy chứ không phải nạng — đòn bẩy giúp người mạnh đi xa hơn, còn nạng khiến người ta quên cách tự đi.Chuyện đổi công cụ ở công ty tôi rồi cũng xong, team thích nghi được. Nhưng câu hỏi nó để lại thì vẫn còn nguyên. Trong một ngành mà công cụ có thể đổi giá sau một đêm, giỏi code là cần, nhưng chưa đủ. Thứ quyết định bạn còn đứng vững hay không, là khi con gà đã được vỗ béo xong, bạn là người cầm dao — hay là người nằm trên thớt.

Khi Artificial Intelligence ngày càng xuất hiện nhiều trong ngành Information Technology, mình nhận ra công việc của một người IT đang thay đổi khá rõ. Trước đây, mình nghĩ chỉ cần làm tốt chuyên môn là đủ. Nhưng hiện tại, điều quan trọng không chỉ là “biết làm”, mà còn là biết cách làm việc cùng AI để tăng hiệu quả và tạo ra giá trị thực tế hơn.Mình từng tham gia dự án AI Buddy Chat — một chatbot giáo dục hỗ trợ học sinh hỏi đáp kiến thức, gợi mở nội dung học tập và đồng hành theo bộ sách Trí tuệ nhân tạo. Dự án này khiến mình thay đổi khá nhiều về tư duy làm việc.Trước đây khi làm testing, phần lớn thời gian của mình dành cho việc viết testcase thủ công, kiểm tra từng flow hoặc lặp đi lặp lại các bước regression test. Từ khi bắt đầu ứng dụng AI vào công việc, mình có thể dùng AI để: Gợi ý testcase nhanh hơn,  Tạo edge case,  Hỗ trợ viết query SQL,  Phân tích log,  Hoặc tổng hợp nhanh các scenario có thể xảy ra. AI giúp mình giảm khá nhiều thời gian ở các tác vụ lặp lại. Nhưng đổi lại, mình phải “nghĩ nhiều hơn” ở những phần mà AI chưa thể làm tốt hoàn toàn.Ví dụ trong dự án chatbot giáo dục, AI có thể tạo ra câu trả lời rất tự nhiên nhưng chưa chắc phù hợp với học sinh. Có lần chatbot giải thích khái niệm machine learning quá dài và dùng nhiều thuật ngữ khó hiểu với học sinh cấp hai. Nếu chỉ nhìn theo góc độ “chatbot trả lời đúng” thì có thể xem là pass, nhưng nhìn từ trải nghiệm người học thì chưa thực sự hiệu quả.Điều đó khiến mình bắt đầu quan tâm nhiều hơn đến: Context conversation,  Độ phù hợp của nội dung với người dùng,  Logic nghiệp vụ,  Và trải nghiệm thực tế thay vì chỉ test theo checklist. Mình cũng nhận ra bản thân đang làm nhiều việc hơn trước đây. Ngoài testing, mình phải: Hiểu thêm về sản phẩm giáo dục,  Phân tích intent của người dùng,  Kiểm tra chất lượng nội dung AI trả về,  Trao đổi với team về trải nghiệm hội thoại,  Và đôi khi tham gia góp ý cách chatbot phản hồi sao cho tự nhiên hơn. Có những kỹ năng trước đây chỉ là “nên có”, nhưng bây giờ gần như trở thành “phải có”, ví dụ: Kỹ năng đặt câu hỏi,  Tư duy phân tích,  Khả năng học nhanh,  Hiểu API và dữ liệu,  Và đặc biệt là biết sử dụng AI đúng cách thay vì phụ thuộc hoàn toàn vào nó. Khó khăn lớn nhất với mình trong giai đoạn đầu là học cách kiểm chứng thông tin AI đưa ra. Vì AI có thể trả lời rất thuyết phục dù đôi khi chưa đúng hoàn toàn. Có những testcase AI gợi ý nghe hợp lý nhưng lại thiếu business rule quan trọng của hệ thống giáo dục. Điều đó khiến mình hiểu rằng dùng AI hiệu quả không phải là copy kết quả, mà là biết đánh giá và chọn lọc.Với những bạn mới vào ngành IT, mình nghĩ ngoài kiến thức chuyên môn thì nên chuẩn bị thêm: Khả năng tự học,  Kỹ năng giao tiếp,  Tư duy logic,  Và khả năng làm việc cùng AI. Theo mình, AI sẽ không thay thế hoàn toàn người làm IT, nhưng chắc chắn sẽ thay đổi cách chúng ta làm việc mỗi ngày. Vì vậy mình đang cố gắng phát triển theo hướng hiểu sản phẩm nhiều hơn, học thêm API, SQL, automation và quan trọng nhất là giữ tư duy chủ động học hỏi để không bị tụt lại phía sau.Hiện tại, mình không xem AI là đối thủ, mà là một công cụ giúp mình làm việc hiệu quả hơn. Nhưng để thực sự tạo ra giá trị, mình nghĩ người làm IT vẫn cần khả năng phân tích, hiểu người dùng và đưa ra quyết định phù hợp trong những tình huống thực tế mà AI chưa thể thay thế hoàn toàn.