AI trong lập trình: Liệu viết code có trở thành viết prompt vào năm 2030?

"Đến năm 2030, bạn không cần phải biết viết code để trở thành một lập trình viên giỏi. Bạn chỉ cần biết cách yêu cầu AI làm việc đó."

Đây là một tuyên bố táo bạo đang lan truyền trong giới công nghệ: viết code đang nhanh chóng trở thành viết prompt. Thay vì tự mình viết từng dòng code, chúng ta sẽ chỉ cần dùng ngôn ngữ tự nhiên để yêu cầu AI tạo, refactor và test code cho mình.

Vậy, liệu kỹ nghệ prompt (prompt engineering) có phải là tương lai của ngành lập trình?

Vừa có lại vừa không. Và sự khác biệt này quan trọng hơn nhiều so với những gì mọi người vẫn nghĩ.

Vào năm 2020, "prompting" chỉ đơn giản là các tham số dòng lệnh (CLI flags) hoặc yêu cầu người dùng nhập dữ liệu đầu vào. Giờ đây, thuật ngữ này có nghĩa là hướng dẫn GPT tự tạo ra một ứng dụng web hoàn chỉnh từ con số không. Điều đó thực sự hữu ích. Sai lầm không nằm ở việc sử dụng AI, mà là ở việc phó mặc việc suy nghĩ cho nó. Khi bạn thay thế các hàm (function) bằng các prompt mà không hiểu rõ bản chất bên dưới, bạn chẳng đang kỹ nghệ hóa thứ gì cả. Bạn chỉ đang đoán mò với một chiếc hộp đen và hy vọng kết quả đầu ra sẽ hoạt động ổn thỏa.

Và có một sự thật mà không ai thực sự muốn thừa nhận: ngay cả trong một tương lai nơi lập trình hoàn toàn là viết prompt (một sự chuyển dịch có thể mất nhiều năm hoặc cả thập kỷ nữa), bạn vẫn cần phải biết cách dẫn dắt cỗ máy. Ai đó phải đưa ra chỉ dẫn, xác minh kết quả đầu ra và chịu trách nhiệm về sản phẩm cuối cùng. Người đó cần phải hiểu rõ logic, nếu không toàn bộ hệ thống sẽ sụp đổ ngay lần đầu tiên AI mắc phải một lỗi sai nhỏ nhưng tinh vi.

Trong bài viết này, chúng ta sẽ cùng tìm hiểu lý do tại sao sự chuyển dịch này lại diễn ra, và tại sao công việc thực sự của bạn đang dần trở thành người thực sự hiểu rõ logic.

Bản chất thực sự của việc viết prompt bằng AI trong lập trình

Ở dạng đơn giản nhất, viết prompt bằng AI trong phát triển phần mềm nghĩa là đưa ra các chỉ dẫn bằng ngôn ngữ tự nhiên cho một mô hình ngôn ngữ lớn để tạo ra kết quả kỹ thuật. Trong bối cảnh lập trình, điều này thường thể hiện qua ba cách:

• Tự động hoàn thành (Autocompletion). Các công cụ như GitHub Copilot hoặc Cursor sẽ đọc đoạn code hiện tại của bạn và gợi ý vài dòng tiếp theo. Đây thực chất là việc khớp mẫu (pattern matching) với tốc độ cao.

• Viết prompt chỉ dẫn (Instructional prompting). Bạn giao cho chatbot một nhiệm vụ cụ thể, chẳng hạn như "Viết một đoạn mã Python để cào tiêu đề từ một trang tin tức và lưu chúng vào tệp CSV." AI sẽ khai thác dữ liệu đào tạo của nó để đưa ra giải pháp.

• Truyền ngữ cảnh (Context injection). Đây là cấp độ nâng cao. Bạn cung cấp cho AI tài liệu hiện có, schema của API hoặc các ràng buộc logic để nó hiểu hệ thống độc nhất của bạn trước khi viết bất kỳ một dấu ngoặc nào.

Đằng sau cả ba cách trên, AI chỉ đơn giản là dự đoán token có khả năng xuất hiện tiếp theo cao nhất dựa trên hàng tỷ ví dụ mà nó đã học. Một trình biên dịch (compiler) sẽ cho bạn câu trả lời nhị phân "Đúng hoặc Sai". Còn một prompt sẽ cho bạn một dự đoán mang tính xác suất. Đôi khi đó là một lối tắt tuyệt vời. Nhưng đôi khi, đó lại là một sự hoang tưởng đầy tự tin (hallucination). Nếu bạn không hiểu cú pháp bên dưới, bạn sẽ không thể biết mình đang nhận được kết quả nào.

Đó chính là mấu chốt của vấn đề. Tất cả những gì tiếp theo là làm sao để bạn luôn đứng ở phía đúng đắn của ranh giới đó.

Lập trình đang thay đổi ra sao, và công việc của bạn sẽ trở thành gì

Nếu AI đảm nhận phần lớn việc gõ phím, thì con người thực sự để làm gì? Câu trả lời không phải là "làm ít đi", mà là "làm khác đi". Có bốn sự chuyển dịch đang tái định hình công việc này ngay lúc này.

1. Từ người thợ xây dựng đến kiến trúc sư hệ thống

Các dấu ngoặc và dấu chấm phẩy giờ đây không còn quá quan trọng nữa. Điều quan trọng hơn là ý định, cấu trúc và những gì đoạn code muốn đạt được. Giá trị của bạn nằm ở việc lập kế hoạch và xác thực kiến trúc. Bạn phải là người hiểu rõ toàn bộ hệ thống kết nối với nhau như thế nào, vì đó là cách duy nhất để bạn phát hiện ra lỗi khi kết quả đầu ra của AI không khớp với hệ thống.

2. Làm chủ ngữ cảnh, không chỉ là prompt

Các LLM có tính phi xác định (non-deterministic). Cùng một câu lệnh có thể cho ra các câu trả lời khác nhau trong những lần chạy khác nhau. Vì vậy, việc quản lý ngữ cảnh bạn cung cấp cho mô hình mới là kỹ năng kỹ thuật thực sự.

Nếu bạn đưa cho nó một vấn đề mơ hồ với rất ít tài liệu tham khảo trên mạng, nó sẽ vui vẻ tự chế ra các hàm không hề tồn tại hoặc tạo ra code rối rắm (spaghetti code) chậm chạp hoặc không an toàn. Ngữ cảnh đầu vào tốt, code đầu ra hữu ích. Ngữ cảnh mơ hồ, kết quả sẽ là những thứ vô nghĩa trông có vẻ hợp lý.

3. Xác minh logic

AI đã tạo ra một lỗ hổng logic nguy hiểm: code được tạo ra nhanh hơn mức con người có thể kiểm duyệt. Và các lỗi do AI tạo ra cực kỳ khó phát hiện vì chúng trông rất chuẩn xác.

Hãy tưởng tượng AI tạo ra một hàm lọc danh sách người dùng theo is_active. Hàm chạy tốt. Các bài test đều vượt qua. Quá trình review code diễn ra suôn sẻ. Sáu tuần sau, số liệu churn của bạn trông sạch sẽ một cách kỳ lạ và không ai hiểu tại sao. Hóa ra hàm này đã âm thầm loại bỏ những người dùng có trạng thái là null thay vì false. Lỗi của một lập trình viên tập sự (junior developer) thường rất dễ thấy. Còn lỗi của AI lại ẩn náu bên trong những đoạn code trông có vẻ hoàn toàn chính xác. Giá trị của bạn nằm ở việc phát hiện ra chúng trước khi sản phẩm được phát hành.

4. Tự động hóa các đoạn code mẫu (boilerplate)

Các trang đăng nhập, luồng thanh toán cơ bản, các thao tác CRUD đơn giản. AI xử lý những việc này rất tốt, và đó là một điều tuyệt vời. Nó giúp bạn giải phóng thời gian để tập trung vào những vấn đề thực sự thú vị: các quyết định về kiến trúc, các trường hợp đặc biệt (edge case) kỳ lạ, và những phần tạo nên sự khác biệt cho dự án của bạn.

Đây là điểm khiến nhiều người dễ bị nhầm lẫn, vì vậy hãy thẳng thắn với nhau: giao code mẫu cho AI thì không sao, nhưng giao phó khả năng phán đoán của bạn cho nó thì không ổn chút nào. Đây là hai quyết định hoàn toàn khác nhau, và việc đánh đồng chúng chính là điều biến các lập trình viên thành những người đoán mò prompt.

---

---

Liệu bạn có trở thành một "khủng long lỗi thời" trong ngành code?

Nhiều năm trước, một số lập trình viên từng coi thường các công cụ "dễ dàng". Các framework như React hay Django bị coi là "gian lận". Lập trình viên thực thụ phải tự tay viết từng dòng JavaScript hoặc CSS từ con số không. Ngày nay, những "lối tắt" đó đã trở thành... tiêu chuẩn. Không ai xây dựng một ứng dụng nghiêm túc bằng cách chế tạo lại bánh xe từ đầu cả.

AI chính là chương tiếp theo của cùng một câu chuyện, và một ranh giới tương tự đang dần được hình thành:

• Những chú "khủng long" không chỉ né tránh AI. Họ từ chối thích nghi với nó. Họ coi đó là mối đe dọa đối với "việc lập trình thực thụ" và dành hàng giờ để giải quyết lại những vấn đề mà ngành công nghiệp đã có lời giải từ lâu. Họ quên mất rằng bản chất của lập trình là giải quyết vấn đề, chứ không phải là gõ phím.

• Những kiến trúc sư sử dụng AI cho những phần nhàm chán và giữ cho kiến thức nền tảng của mình luôn sắc bén đối với mọi thứ khác. Họ không ngừng học hỏi, bởi vì sự hiểu biết sâu sắc là cách duy nhất để xác minh công việc của AI và giữ cho mọi thứ an toàn. Họ không bị AI thay thế. Họ là người làm chủ nó.

Điểm mấu chốt: việc không sử dụng AI không biến bạn thành một lập trình viên tồi. Thành thật mà nói, việc tự mình giải quyết vấn đề vẫn là cách giúp bạn học hỏi sâu sắc nhất. Mục tiêu là luôn giữ được khả năng thích nghi. Dù AI tạo ra một dòng hay toàn bộ một hàm, tên của bạn vẫn nằm trên dự án đó. Trở thành một kiến trúc sư nghĩa là bạn luôn có đủ chiều sâu kiến thức để tự mình thấu hiểu, xác minh và làm chủ logic đó.

Cách để luôn là người làm chủ

Khi các ứng dụng được tạo ra bởi cùng một vài mô hình AI giống nhau, chúng sẽ bắt đầu mang lại cảm giác rập khuôn. Những lựa chọn độc đáo, mang tính con người và thông minh mới là điều làm nên sự đáng nhớ của một phần mềm tuyệt vời, và những điều đó không thể tự dưng xuất hiện từ một chiếc hộp prompt.

Một vài thói quen sau sẽ giúp bạn luôn đứng về phía kiến trúc sư:

• Sử dụng AI để dựng khung sườn, chứ không phải để hoàn thiện các chi tiết cuối cùng. AI rất tuyệt vời cho các phần mang tính cấu trúc. Nhưng những chi tiết tùy biến, các trường hợp đặc biệt, những thứ tạo nên bản sắc riêng cho sản phẩm của bạn thì vẫn là công việc của bạn.

• Đừng để kiến thức nền tảng của bạn bị mai một. Chỉ cần dành ra 5 phút thực hành viết code mỗi ngày cũng đủ để giữ cho tư duy logic của bạn luôn sắc bén. Đôi khi, việc tạm rời xa AI là cách để bạn đảm bảo rằng mình vẫn hiểu rõ cỗ máy mà mình đang lèo lái.

• Hãy đối xử với AI như một lập trình viên tập sự. Đưa ra chỉ dẫn rõ ràng, kiểm tra kết quả công việc và đưa ra quyết định cuối cùng. Quy tắc rất đơn giản: hãy luôn am hiểu hơn công cụ mà bạn đang sử dụng.

Lập trình không hề biến mất. Chỉ là luật chơi đang thay đổi.

Vậy, liệu lập trình có hoàn toàn trở thành việc viết prompt vào năm 2030 hay không?

Thành thật mà nói? Không ai thực sự biết trước được. Hai năm trước, ý nghĩ về việc đưa code do AI tạo ra vào môi trường production nghe giống như một trò đùa. Ngày nay, hầu hết các lập trình viên đều sử dụng nó hằng ngày. Tốc độ phát triển này thật khó để dự đoán.

Nhưng câu trả lời "đúng vậy, tất cả chỉ là viết prompt" chỉ dành cho những ai không quan tâm đến chất lượng. Cho đến khi AI có thể tiếp nhận mô tả của một hệ thống phức tạp và trả về một phần mềm bảo mật, không có lỗi một cách đáng tin cậy (và chúng ta còn cách cột mốc đó rất xa), ngành công nghiệp này vẫn sẽ tiếp tục cần những lập trình viên có thể debug logic và phát hiện ra những lỗi sai mà AI đã âm thầm bỏ qua. Đó không phải là một vai trò dự phòng. Đó mới chính là vai trò đắt giá.

Những kiến trúc sư luôn không ngừng học hỏi. Đó chính là mục tiêu mà Coddy hướng tới: các bài học tương tác, thực hành thực tế giúp bạn xây dựng chiều sâu kiến thức mà không một prompt nào có thể giả mạo được.

Vì vậy, hãy luôn tò mò, viết code và không ngừng học hỏi nhé! :)