Gần đây, câu hỏi “Liệu AI có thay thế chúng ta không?” đã trở thành nỗi lo lắng của nhiều người. Chúng ta có thể thấy rõ ràng cách các Mô hình Ngôn ngữ Lớn (LLM) xử lý các nhiệm vụ lập trình một cách xuất sắc, viết mã ở trình độ từ trung cấp đến cao cấp. Điều này khiến không ít kỹ sư phần mềm trăn trở về tương lai sự nghiệp của mình.
Mục lục
Giới Thiệu: Đánh Giá Đa Chiều Về Vai Trò Của AI Trong Phát Triển Phần Mềm
Thành thật mà nói, tôi đã chỉnh sửa bài viết này nhiều lần và dành nhiều thời gian hơn bình thường cho nó. Tôi không muốn đứng về phía những người phản đối AI, đó không phải là cách tôi nhìn nhận vấn đề. Tôi đã sử dụng các LLM trong công việc hàng ngày của mình vài năm nay và thật khó để tưởng tượng việc làm việc mà không có chúng. Không phải vì tôi sẽ không thể viết mã hay giải quyết các vấn đề phức tạp, mà vì hiệu suất của tôi chắc chắn sẽ thấp hơn.
Trí tuệ nhân tạo đang phát triển nhanh hơn hầu hết các nhà phát triển có thể thích nghi, và chúng ta đang chứng kiến những thay đổi lớn trong ngành công nghiệp IT. Chính vì vậy, nhiều người cảm thấy căng thẳng, phủ nhận, hoặc thậm chí là thái độ thù địch đối với AI. Nhưng hầu hết những cảm xúc này không phải do các mối đe dọa thực sự thúc đẩy, mà là do sự cường điệu và chiến lược marketing mạnh mẽ từ các nhà cung cấp AI lớn.
Mục tiêu của bài viết này không phải là để chứng minh rằng AI yếu kém hay vô dụng, hay chúng ta không nên sử dụng nó. Hoàn toàn không. Tôi muốn làm nổi bật một khía cạnh khác, một khía cạnh mà mọi người không nói đến đủ. Các LLM là những công cụ mạnh mẽ, nhưng chúng đi kèm với những hạn chế và đòi hỏi những chuyên gia có kỹ năng thực sự hiểu rõ những gì họ đang làm.
Trí Tuệ Nhân Tạo Trong Phát Triển Phần Mềm: Sức Mạnh Và Giới Hạn
Các LLM hiện đại thực sự đã trở thành công cụ mạnh mẽ trong phát triển phần mềm. Các mô hình như Claude Code hay Codex có khả năng viết mã chất lượng cao, có cấu trúc tốt và khá phức tạp. Chúng có thể làm việc với các codebase lớn và hiểu ngữ cảnh của dự án.
Để hiểu liệu AI có thể thay thế các kỹ sư phần mềm trong tương lai hay không, trước tiên chúng ta hãy nhìn vào câu hỏi chính: một LLM có thực sự hiểu tại sao đoạn mã này lại cần thiết không?
Như bạn đã biết, một LLM hoạt động bằng cách dự đoán chuỗi token có khả năng tiếp theo nhất dựa trên một lượng lớn dữ liệu huấn luyện. Nói một cách đơn giản, AI hiện đại không “suy nghĩ” và không “hiểu” mục tiêu của hệ thống. Nó đưa ra quyết định thống kê về những gì hợp lý nhất để viết tiếp theo.
Đó là lý do tại sao các LLM cho thấy kết quả xuất sắc trong các nhiệm vụ điển hình và được định nghĩa rõ ràng:
- Ứng dụng CRUD (Create, Read, Update, Delete)
- Các API REST tiêu chuẩn
- Các ứng dụng trang đơn giản (SPA) được xây dựng bằng Angular hoặc React
- Logic nghiệp vụ dựa trên mẫu (template-based business logic)
Tất cả những điều này đã xuất hiện nhiều lần trong dữ liệu huấn luyện, vì vậy mô hình có thể tự tin tái tạo các mẫu quen thuộc.
Vấn đề bắt đầu khi cần hiểu sâu sắc về miền (domain) và ngữ cảnh thực thi. Ví dụ, khi thiết kế một hệ thống phân tán với các yêu cầu phức tạp về khả năng chịu lỗi, tính nhất quán dữ liệu và các ràng buộc nghiệp vụ. Trong những nhiệm vụ như vậy, AI có thể tạo ra mã trông “sạch” và đúng, nhưng:
- Không xem xét các kịch bản tải thực tế.
- Vi phạm các quy tắc logic nghiệp vụ quan trọng.
- Hoặc đề xuất các giải pháp kiến trúc không thể hoạt động trong môi trường nhất định.
Hệ thống càng phức tạp, ngữ cảnh càng rộng và yêu cầu càng ít hình thức, thì khả năng mô hình bị nhầm lẫn, “ảo giác” (hallucinate) hoặc đi theo các giải pháp sai lầm càng cao.
Tại Sao Chỉ Mở Rộng Quy Mô LLM Thôi Là Chưa Đủ?
Một trong những thách thức lớn nhất trong việc xây dựng các LLM mạnh mẽ hơn là chất lượng dữ liệu mà chúng được huấn luyện. Ngay cả khi chúng ta tiếp tục mở rộng quy mô mô hình, các vấn đề như sự suy giảm mô hình (model collapse) có thể hạn chế tiến bộ. Khi các mô hình được huấn luyện trên dữ liệu đã chứa nội dung do AI tạo ra hoặc nội dung chất lượng thấp, chúng có thể bắt đầu khuếch đại lỗi, lặp lại sai lầm hoặc học các mẫu không thực tế. Việc chỉ làm cho mô hình lớn hơn sẽ không giải quyết được vấn đề cơ bản; bản thân nền tảng cần phải sạch và đáng tin cậy.
Yann LeCun, người đoạt giải Turing và là một trong những người sáng lập AI hiện đại, đồng thời là cựu Trưởng nhóm Khoa học AI tại Meta, tin rằng việc chỉ tăng kích thước và sức mạnh của các LLM sẽ không có ích. Theo ông, đây không phải là con đường dẫn đến trí tuệ nhân tạo tổng quát (AGI) thực sự.
Ông lập luận rằng trí tuệ thực sự cần một mô hình về thế giới thực, bao gồm vật lý, nguyên nhân và kết quả, và các mục tiêu. Ngôn ngữ đơn thuần là không đủ:
"Chúng ta cần các hệ thống hiểu thế giới vật lý, chứ không chỉ các hệ thống tạo ra văn bản hợp lý."Lập trình đòi hỏi khả năng lập kế hoạch, suy luận và hiểu các hậu quả dài hạn. Các LLM có thể giúp viết mã, nhưng chúng không thực sự thiết kế hệ thống hoặc hiểu tại sao các giải pháp lại hoạt động. Đó là lý do tại sao, dù các mô hình mới có mạnh mẽ đến đâu, cùng một vấn đề cơ bản vẫn còn tồn tại.
Đồng thời, Yann LeCun đang nghiên cứu một kiến trúc AI mới có tên là VL-JEPA (Vision-Language Joint Embedding Predictive Architecture). Đây không phải là một cách tiếp cận sinh học cổ điển như các mô hình GPT. Thay vì dự đoán văn bản từng token một, mô hình hoạt động ở cấp độ biểu diễn ngữ nghĩa. Nó không tạo ra câu trả lời từng từ một. Nó dự đoán một biểu diễn ngữ nghĩa của câu trả lời, một loại “dấu vân tay ý nghĩa”. Nếu cần, biểu diễn này sau đó có thể được giải mã thành văn bản.
VL-JEPA có thể hiệu quả hơn các mô hình đa phương thức truyền thống vì nó không tốn tính toán để tạo ra từng token. Trong các nhiệm vụ như phân loại, hiểu video, tìm kiếm video và trả lời câu hỏi bằng hình ảnh, cách tiếp cận này có thể nhẹ hơn và nhanh hơn. Kiến trúc cũng mang tính phổ quát hơn: cùng một mô hình có thể giải quyết các nhiệm vụ phân loại, tìm kiếm và trả lời câu hỏi mà không cần huấn luyện một mô hình riêng cho từng nhiệm vụ.
Xu Hướng “Vibe Coding” Năm 2025: Những Bài Học Đắt Giá
Thuật ngữ “vibe-coding” xuất hiện vào tháng 2 năm 2025, khi đồng sáng lập OpenAI nhắc đến nó trên X (Twitter). Ông viết rằng đây là một cách tuyệt vời để tạo mã bằng ngôn ngữ tự nhiên và hoàn toàn tin tưởng vào AI, thay vì lập trình thủ công truyền thống. Sau đó, có một làn sóng cường điệu khổng lồ. Và tại sao không? Giờ đây bạn chỉ cần nói chuyện với AI, và nó sẽ làm những gì mọi người đã học ở trường đại học và thực hành trong nhiều năm.
Chiến dịch marketing đã rất mạnh mẽ. Nhiều người ngoài ngành IT bắt đầu xây dựng dịch vụ web của riêng họ. Một số thậm chí còn sa thải lập trình viên, tại sao phải trả nhiều hơn nếu bạn có thể mua gói đăng ký 20 đô la và tự làm mọi thứ? Sau một thời gian, chúng ta bắt đầu thấy kết quả: các khóa
API keybị commit vào kho lưu trữ công khai, các lỗ hổng bảo mật trong các trang web và các trường hợp mọi người chi 300-400 đô la trong một buổi tối vì sử dụng quá nhiều token. Trong một số trường hợp, toàn bộ ứng dụng đơn giản là ngừng hoạt động.
Nếu bạn nghĩ điều này chỉ xảy ra với những người mới bắt đầu ngây thơ trong nghề, hãy cùng tìm hiểu sâu hơn về chủ đề này.
Deloitte và Vụ Báo Cáo “Vibe-Lawyer”
Bạn có thể đã nghe tin tức rằng vào mùa hè năm 2025, Deloitte đã vướng vào một vụ bê bối. Hóa ra báo cáo của họ cho chính phủ Úc đã được tạo ra một phần bằng ChatGPT và bao gồm các luật không tồn tại và các tham chiếu đến các sự kiện sai lệch. Tôi sẽ gọi đây là “vibe-lawyer”. Công ty đã phải đối mặt với cả tổn thất tài chính và thiệt hại về danh tiếng. Và đây là một công ty cấp toàn cầu. Trong các công ty như vậy, các báo cáo được thông qua nhiều phòng ban và nhiều người. Nhưng chúng ta có thể thấy kết quả.
Thiệt Hại Hàng Triệu Đô Từ Smart Contract Lỗi
Một trường hợp khác xảy ra vào tháng 2 năm 2026. Giao thức DeFi Moonwell đã phát hành một bản cập nhật mới. Sau đó, hệ thống bắt đầu định giá token
cbETHở mức khoảng 1.12 đô la, trong khi giá thị trường thực tế của nó là khoảng 2.200 đô la.
Vấn đề hóa ra là một lỗi tính toán cơ bản trong logic hợp đồng thông minh. Mặc dù nhóm Moonwell đã phản ứng nhanh chóng và sửa lỗi trong vòng bốn phút, giao thức vẫn chịu tổn thất khoảng 1,7 triệu đô la.
Vậy thì vibe coding liên quan gì đến điều này?
Sau đó, người ta phát hiện ra rằng commit đưa lỗ hổng vào đã được tạo bằng Claude Code. Tất nhiên, sẽ không công bằng nếu chỉ đổ lỗi cho AI. Một nhà phát triển đã xem xét mã trước khi đẩy nó. Nhưng đây là lúc yếu tố con người xuất hiện, việc xem xét không đủ kỹ lưỡng và quá nhiều niềm tin đã được đặt vào một mô hình “thay đổi cuộc chơi”.
Bài học chính rất đơn giản: dù mã do LLM tạo ra có vẻ sạch sẽ hay thuyết phục đến đâu, bạn vẫn nên luôn suy nghĩ một cách nghiêm túc và xem xét các trường hợp biên.
Vibe coding ổn nếu bạn đang làm một dự án cá nhân và chỉ muốn xác thực một ý tưởng. Nhưng đối với các hệ thống lớn, phức tạp, vibe coding không phải là thứ bạn có thể dựa vào.
AI Agents: Liệu Có Phải Là Giải Pháp Thay Thế Lập Trình Viên?
Từ ngữ gây sốt thứ hai sau “vibe-coding” là “AI agent” (tác nhân AI). Điều gì làm nó khác biệt so với AI thông thường, ngoài marketing? Đó là khả năng tự chủ. Một agent có thể lập kế hoạch, hành động và tự đánh giá công việc của mình. Các tác nhân AI như vậy thường có quyền truy cập vào mã, cơ sở dữ liệu hoặc các công cụ phát triển khác của bạn. Vì vậy, không giống như các cuộc trò chuyện đơn giản với ChatGPT, một agent có thể lập kế hoạch và hoàn thành các nhiệm vụ một cách độc lập hơn. Nghe có vẻ như một bước đột phá, phải không?
Có lẽ bây giờ, với các tác nhân AI tự chủ mạnh mẽ được xây dựng trên các mô hình mới nhất từ Anthropic, các lập trình viên cuối cùng sẽ biến mất? Rất tiếc, không.
Các tác nhân AI không giải quyết được vấn đề cơ bản: chúng vẫn là các mô hình ngôn ngữ mà không có sự hiểu biết thực sự về mục tiêu và không có trách nhiệm đối với kết quả cuối cùng. Đúng vậy, chúng có thể tự xử lý một số nhiệm vụ nhất định, đặc biệt là các công việc lặp đi lặp lại, thường xuyên. Nhưng chúng không phải, và không thể là, tương đương với các kỹ sư phần mềm giàu kinh nghiệm.
Vai trò này vẫn thuộc về con người. Chỉ một kỹ sư có kinh nghiệm mới có thể:
- Xác định đúng nhiệm vụ.
- Đánh giá sự đánh đổi về kiến trúc.
- Kiểm tra xem giải pháp có phù hợp với ngữ cảnh kinh doanh thực tế hay không.
- Và chịu trách nhiệm về sản phẩm cuối cùng.
Đó là lý do tại sao ngày nay AI không phải là bộ não của sự phát triển, mà là đôi tay của nó. Nó làm cho quá trình nhanh hơn, loại bỏ các nhiệm vụ thường ngày và tăng năng suất. Nhưng hướng đi, sự kiểm soát và ý nghĩa vẫn đến từ con người.
Những Rủi Ro Tiềm Ẩn Của AI Agents
Các tác nhân AI (và LLM nói chung) đi kèm với một loạt các lỗ hổng.
Một ví dụ gần đây cho thấy các hệ thống này có thể không thể đoán trước được trong cuộc sống thực như thế nào. Summer Yue, người làm việc về an toàn AI tại Meta, đã quyết định thử một tác nhân AI mã nguồn mở có tên OpenClaw và cấp cho nó quyền truy cập vào hộp thư đến của cô. Cô đã chỉ dẫn rõ ràng cho nó xác nhận trước khi thực hiện bất kỳ hành động nào.
Thay vào đó, tác nhân bắt đầu tự xóa email của cô và bỏ qua yêu cầu dừng lại của cô. Cô thậm chí không thể dừng nó từ điện thoại của mình và phải chạy đến máy tính để tắt nó đi.
Điều này cho thấy một điểm đơn giản nhưng quan trọng: ngay cả khi các hướng dẫn có vẻ rõ ràng, các tác nhân AI không phải lúc nào cũng tuân theo chúng và có thể hành xử theo những cách không mong muốn.
Ngoài ra, bạn có thể đã nghe nói về bộ ba gây chết người (lethal trifecta), bao gồm:
- Truy cập vào dữ liệu riêng tư của bạn — một trong những lý do chính khiến các công cụ này tồn tại ngay từ đầu.
- Tiếp xúc với nội dung không đáng tin cậy — bất kỳ tình huống nào mà văn bản hoặc hình ảnh do kẻ tấn công kiểm soát có thể tiếp cận LLM của bạn.
- Khả năng giao tiếp ra bên ngoài — theo những cách có thể được sử dụng để trích xuất dữ liệu của bạn.
Các tác nhân AI có thể dễ bị tấn công bởi nhiều loại tấn công độc hại, và phần đáng lo ngại nhất là chúng thậm chí sẽ không nhận ra điều đó.
Và chúng ta không chỉ nói về một trường hợp tác nhân của bạn vô tình làm rò rỉ một tệp
.envvào kho lưu trữ. Các kịch bản tiềm năng có thể còn tồi tệ hơn nhiều.
Tôi đã viết một bài ngắn về chủ đề này – Các Trình Duyệt Dùng AI Agent Nguy Hiểm! Lỗ Hổng AI, nơi tôi đi sâu hơn vào chi tiết.
Ngay cả với tất cả các vấn đề đã đề cập ở trên, các tác nhân AI vẫn là những công cụ mạnh mẽ cho phát triển phần mềm, đặc biệt là trong tay các kỹ sư giàu kinh nghiệm. Tuy nhiên, bạn nên luôn thận trọng, hiểu rõ rủi ro và hậu quả có thể xảy ra, đồng thời dựa vào kinh nghiệm và phán đoán của riêng mình.
Thế Giới Không Có Lập Trình Viên: Một Viễn Cảnh Đáng Lo Ngại
Hãy tưởng tượng một tình huống mà AI hiện đại đã thực sự thay thế các lập trình viên.
Bạn là giám đốc của một nền tảng đám mây tải cao. Hàng trăm khách hàng sử dụng dịch vụ của bạn và trả rất nhiều tiền cho sự ổn định và đáng tin cậy. Đối với họ, dù chỉ một phút ngừng hoạt động cũng đồng nghĩa với tổn thất tài chính nghiêm trọng, và điều này cũng có nghĩa là tổn thất danh tiếng và tài chính trực tiếp cho công ty của bạn.
Sau đó, một ngày “đẹp trời”, hệ thống đột nhiên ngừng hoạt động. Màn hình giám sát báo đỏ, các chỉ số bị hỏng và một số dịch vụ không khả dụng. Mới hôm qua mã vẫn hoạt động, các thử nghiệm đã vượt qua và việc triển khai là “xanh”.
Bạn khẩn trương liên hệ với bộ phận AI, vì không còn lập trình viên nào nữa. Họ đã được thay thế thành công bởi tác nhân AI chính chịu trách nhiệm phát triển và bảo trì. Bạn mô tả tình hình cho trưởng nhóm phát triển AI của mình.
AI tự tin trả lời:
"Vấn đề có thể liên quan đến cấu hình hoặc trạng thái hệ thống không chính xác. Dưới đây là các nguyên nhân có thể và các ví dụ về cách khắc phục..."Nó tạo ra một số tùy chọn mã, đề xuất khởi động lại dịch vụ, cập nhật các phụ thuộc và thay đổi cấu hình. Bạn thử mọi cách, không có gì giúp ích. Bạn đặt thêm câu hỏi, thêm ngữ cảnh mới, nhật ký và chi tiết cơ sở hạ tầng. Các câu trả lời trở nên tổng quát hơn. Ngữ cảnh tăng lên. Đến một lúc nào đó, các token hết, và cuộc đối thoại dừng lại.
Nhưng ngay cả khi các token không hết, vấn đề chính vẫn sẽ tồn tại.
Không có sự chịu trách nhiệm thực sự đối với mã.
Không có người nào:
- Nhớ tại sao kiến trúc lại được thiết kế theo cách này.
- Biết những thỏa thuận kinh doanh nào ẩn đằng sau các “sửa lỗi tạm thời”.
- Có thể đưa ra một quyết định rủi ro nhưng cần thiết ngay bây giờ.
AI không cảm nhận được trách nhiệm. Nó không hiểu rằng việc hệ thống ngừng hoạt động đang khiến công ty mất hàng trăm ngàn đô la vào lúc này. Nó không thể triệu tập một cuộc họp khẩn cấp, quyết định hoàn tác mọi thứ, hoặc từ chối một giải pháp về mặt hình thức là đúng nhưng nguy hiểm. Nó chỉ đơn giản là tiếp tục tạo ra các câu trả lời hợp lý về mặt thống kê.
Hệ thống vẫn ngừng hoạt động. Khách hàng không hài lòng. Tiền đang bị mất.
Và rồi một câu hỏi đơn giản nhưng khó chịu xuất hiện:
Ai là người chịu trách nhiệm?
- AI?
- Công ty đã tạo ra mô hình?
- Hay giám đốc đã quyết định rằng “AI đã đủ thông minh để thay thế các kỹ sư”?
Chừng nào AI còn chưa thể chịu trách nhiệm, sở hữu một hệ thống và hiểu nó trong ngữ cảnh kinh doanh thực tế, thì nó không thể thay thế một lập trình viên.
Tương Lai Nào Cho Các Lập Trình Viên Junior?
Chúng ta đã biết rằng các LLM không thể thay thế các nhà phát triển giàu kinh nghiệm. Nhưng còn những lập trình viên junior hoặc những người muốn bắt đầu sự nghiệp trong ngành IT thì sao? Các đợt sa thải lớn trong ngành IT đã bắt đầu từ năm 2022, và sau đó AI càng làm tăng thêm sự không chắc chắn. Liệu có cơ hội nào cho những người mới bắt đầu bây giờ không?
Theo ý kiến của tôi, câu trả lời rất rõ ràng – có, bạn vẫn cần thiết! Không thể tìm thấy những người nào có động lực và sẵn sàng học hỏi những điều mới hơn các lập trình viên junior.
Tôi không còn là một lập trình viên mới vào nghề, nhưng tôi vẫn nhớ sự hào hứng khi nhận được công việc đầu tiên của mình. Ở công ty đầu tiên, có một nguyên tắc rất quan trọng được gọi là T-shape: bạn thực sự giỏi trong một lĩnh vực, nhưng bạn cũng hiểu các lĩnh vực liên quan. Sau sáu tháng ở đó, tôi được đề nghị một dự án thứ hai với một công nghệ khác. Thay vì WPF, đó là
React + TypeScript. Và bạn có biết tôi cảm thấy thế nào không? Tôi coi đó là một cơ hội tuyệt vời để học hỏi điều gì đó mới. Họ cho tôi một tháng để thích nghi, nhưng tôi đã học được mọi thứ trong 2 tuần và sẵn sàng chịu trách nhiệm triển khai các tính năng mới.
Động lực và tình yêu dành cho lập trình không biến mất khi bạn trở thành một nhà phát triển cấp cao, nhưng các junior là nhóm năng động nhất về mặt này.
Về cạnh tranh và AI: những người hiểu rõ lĩnh vực của mình, chịu trách nhiệm và không ngừng học hỏi sẽ luôn cần thiết. Ngay cả các junior, không có nhiều kinh nghiệm thương mại, cũng có giá trị. Nhưng bạn cần phải là người giỏi nhất trong số họ. Vào năm 2026, chỉ biết các nguyên tắc
SOLIDvà các mô hình OOP cơ bản là chưa đủ. Với AI, bạn phải có khả năng giải quyết các vấn đề cấp trung, cố gắng độc lập và không ngừng học hỏi.
Bạn có thể trở thành người giỏi nhất không? Nếu bạn thực sự yêu thích lập trình, được truyền cảm hứng từ nó và thấy nó thú vị – vâng, tất nhiên rồi. Chỉ cần đừng ngừng phát triển: xây dựng các dự án của riêng bạn, đóng góp vào mã nguồn mở, nghiên cứu kiến trúc hệ thống và thể hiện sự chủ động. Khi đó, không AI nào có thể thay thế bạn.
Kết Luận: AI Là Công Cụ Mạnh Mẽ, Không Phải Kẻ Thay Thế
Các LLM là những công cụ tuyệt vời cho phát triển phần mềm. Các mô hình hiện đại thực sự tăng năng suất và loại bỏ nhiều nhiệm vụ thường ngày khỏi các nhà phát triển. Nhưng cho đến khi trí tuệ nhân tạo tổng quát (AGI) thực sự tồn tại, việc nói rằng AI hiện đại có thể thay thế các lập trình viên là sai lầm. Chỉ một kỹ sư phần mềm hiểu rõ lĩnh vực, biết các quy trình kinh doanh và sử dụng LLM một cách hiệu quả mỗi ngày mới có thể “thay thế” một nhà phát triển khác.
Vì vậy, ngay cả khi bạn là một nhà phát triển cấp cao, đừng bao giờ ngừng học hỏi!
Cảm ơn bạn đã đọc bài viết này đến cuối cùng. Tôi rất vui nếu bạn chia sẻ những câu chuyện của riêng mình về việc sử dụng AI trong phát triển, những thành công bạn đã đạt được, nơi nó đã giúp bạn và nơi nó đã làm chậm bạn.
#AIThayTheLapTrinhVien #TuongLaiIT #PhanTichAI #KySuPhanMem #LLMVaLapTrinh #VibeCoding #AIAgent #HocHoiLienTuc
