Lập Trình Bằng Prompt là Hành Vi Tự Hại - Và Tại Sao Chúng ta Phải Thức Dậy

"Mô hình lý thuyết tích hợp về phát triển và duy trì hành vi tự hại chỉ ra rằng các hành vi này được thực hiện dưới dạng một phương tiện hiệu quả để cá nhân có thể ngay lập tức điều chỉnh các trải nghiệm cảm xúc và tình huống xã hội." - M.K.Nock, 2009.

“Lập trình bằng cách Prompt - Accept là một hành vi tự hại.” - N.P.H Linh, 2026.

Lập Trình Bằng Prompt là Hành Vi Tự Hại - Và Tại Sao Chúng ta Phải Thức Dậy

Hôm nay tôi muốn nói về cái gì mà hầu hết người sợ nhìn thẳng vào mặt: chúng ta đang nuôi dưỡng một thế hệ lập trình viên mà thực chất là những zombie có khả năng gõ bàn phím.

Năm ngoái, một đồng nghiệp trẻ sinh năm 2002 của tôi tự hào nói: "Tôi có 5 năm kinh nghiệm phát triển phần mềm Go." Tôi hỏi cậu ta tạo một cái bộ nhớ cache có khóa an toàn từ đầu mà không dùng bất kỳ thư viện nào, trong một tiếng. Cậu ta ngồi 10 phút rồi hỏi: "Tôi có thể dùng trí tuệ nhân tạo không?" Chính lúc đó, tôi hiểu rằng cậu ta không bao giờ thực sự lập trình. Cậu ta chỉ biết cách nhắn tin cho máy.

Tiếng bàn phím trong văn phòng hôm nay thật lạ lùng. Thay vì giai điệu nhịp nhàng của những bộ não nhảy múa cùng logic, chúng ta lắng nghe một âm thanh khác - những tiếng gõ gián đoạn, tuyệt vọng: gõ một dòng lệnh, ngồi chờ con trỏ nhấp nháy, sau đó là một cú lạch cạch: Accept. Rồi lại lặp lại. Một trăm lần một ngày. Chào mừng bạn đến với kỷ nguyên của những "Zombie Chấp Nhận".

Cơn say của trí tuệ nhân tạo rẻ tiền quá. Chỉ cần vài giây, một cô gái trẻ có thể dựng lên cả một hệ thống vi dịch vụ trông hoành tráng. Nó tạo ra một ảo giác quyền năng kinh tởm, khiến mọi người tin rằng sở hữu công cụ đồng nghĩa với sở hữu trí tuệ. Nhìn vào màn hình thấy code chạy, họ tự huyễn hoặc mình là kiến trúc sư. Nhưng thực chất, họ chỉ là những công nhân lắp ráp mù quáng. Khi lỗi tinh vi xuất hiện - những cái lỗi nằm sâu trong logic nghiệp vụ chứ không phải lỗi cú pháp đơn giản - cái "quyền năng" đó lập tức sụp đổ như tòa lâu đài cát. Họ lại van xin trí tuệ nhân tạo sửa lỗi, rồi tiếp tục chu trình "Nhắn Tin - Chấp Nhận" trong vô vọng. Họ không làm chủ công nghệ; họ là con rối của xác suất thống kê.

Đây là phần đau đớn nhất: hầu hết mọi người sẽ không nhận ra vấn đề cho đến khi quá muộn. Khi trí tuệ nhân tạo dạo bước vào tầm hiểu biết của nó (và nó sẽ), khi những "nợ kiến thức" với lãi suất vũ trụ bắt đầu đòi nợ, những cô bé trẻ này sẽ hoàn toàn bất lực. Họ sẽ không biết cách sửa chữa vì họ chưa bao giờ học cách suy nghĩ.

Lập trình, về bản chất, là nghệ thuật của sự đau khổ. Một thầy cô giáo thực thụ trưởng thành từ những đêm trắng gỡ lỗi, từ việc đọc tài liệu cho đến khi nó hành động, từ việc cố gắng hiểu tại sao một con trỏ lại trỏ vào địa chỉ trống. Chính cái ma sát đau đớn đó tạo nên nếp nhăn não và trực giác. Nhưng trí tuệ nhân tạo đã triệt tiêu ma sát. Thế hệ "Zombie Lập Trình" nhận được câu trả lời trước khi kịp hỏi câu hỏi. Họ nhảy cóc qua quản lý bộ nhớ, độ phức tạp thuật toán để đi thẳng tới kết quả. Hệ quả là một tầng lớp nhân sự lửng lơ: làm việc rất nhanh nhưng nền tảng rỗng tuếch. Cái họ tích lũy không phải kinh nghiệm, mà là "nợ kiến thức" với lãi suất cắt cổ. Khi trí tuệ nhân tạo dạo bước vào tầm hiểu biết của nó, họ hoàn toàn không có khả năng tự vệ.

Đó là lý do tôi gọi nó là hành vi tự hại. Không phải vì nó rõ ràng độc hại, mà vì nó tinh vi. Nó giống như lạm dụng hình ảnh kỹ thuật số - bạn làm điều đó để điều chỉnh cảm xúc hiện tại (tránh rắc rối, tránh suy nghĩ, nhận được phần thưởng ngay), nhưng hậu quả lâu dài là tổn thương bản thân.

Khi rào cản kỹ thuật bị san phẳng, chúng ta không đón nhận một làn sóng tái sinh, mà đang hứng chịu một trận lũ của sự tầm thường. Chào mừng đến với hội "Những Người Lập Trình Theo Cảm Tính" - những người mã hóa vì tò mò, không vì hiểu biết, những người thấy code chạy là xong rồi deploy. Trí tuệ nhân tạo thường sinh ra những đoạn mã "an toàn", dài dòng và chung chung. Kết quả là hàng triệu dòng code thừa thãi, những ứng dụng phình to một cách vô lý để giải quyết những vấn đề bé bằng móng tay. Người ta viết ứng dụng vì tò mò, vì "thấy hay hay", tạo ra những "xác chết kỹ thuật số" chiếm dụng băng thông và làm rác các kho lưu trữ. Tư duy "cần gì tối ưu khi máy tính rẻ" chính là mồi lửa cho cuộc khủng hoảng tài nguyên vĩ mô.

Định luật Wirth từ 1995 ngày nay là tiên tri: "Phần mềm chậm đi nhanh hơn phần cứng trở nên nhanh." Một ứng dụng chat đơn giản năm nay chiếm 2 tỷ byte bộ nhớ chỉ để hiển thị danh sách tin nhắn văn bản. Mười năm trước, một hệ điều hành hoàn chỉnh chiếm ít hơn thế. Nó không phải vì công nghệ tiến bộ. Nó là vì không ai quan tâm đến hiệu suất. Trí tuệ nhân tạo tạo ra mã, mã hoạt động (một cách nào đó), nên bạn ship nó. Vào lúc đó, bạn tích tũy chi phí nhân lực, chi phí năng lượng, chi phí môi trường - tất cả dấu tích theo cấp số nhân.

Tôi bắt đầu thấy một rạn nứt trong ngành. Ở một phía: những lập trình viên viết mã bằng tay, hiểu những nguyên lý cơ bản, họ đánh giá mã một cách thận trọng, kiến trúc hệ thống, hướng dẫn những người trẻ tuổi hơn. Họ chậm, nhưng sâu sắc, mạnh mẽ, có thể bảo trì. Ở phía khác: "Kỹ sư Nhắn Tin" tạo ra mã nhanh chóng, phát hành các tính năng thường xuyên, dùng trí tuệ nhân tạo ở mọi nơi, mã thường phù phiếm nhưng "hoạt động". Họ nhanh, nhưng bề nông, dễ vỡ, có thể loại bỏ được.

Phía thứ hai bây giờ nhiều hơn. Và họ đang ăn chúng ta. Những công ty khởi nghiệp thuê mười "Kỹ sư Nhắn Tin", phát hành mười lần code (dù 70% là rác), bằng cách những công ty truyền thống thuê hai thầy cô cao cấp, phát hành một hệ thống vững chắc. Công ty khởi nghiệp phát triển nhanh chóng (thậm chí chỉ tồn tại vì may mắn), huy động 50 triệu đô la Series B. Công ty truyền thống phát triển chậm (vì tập trung vào chất lượng), bị coi là "lỗi thời". Thị trường khen ngợi tốc độ, chứ không phải chất lượng.

Nhưng đây là phần quan trọng - Cách để không trở thành 80% xấu xa

Tôi muốn nói: "Chúng ta phải dừng lại, quay lại những nguyên lý cơ bản, viết mã tốt." Nhưng tôi biết hầu hết mọi người sẽ không làm. Tại sao? Vì tốc độ là kích thích. Nhắn tin cho trí tuệ nhân tạo, đầu ra ngay. Những phần thưởng não bộ hit. So với suy nghĩ một giờ, gỡ lỗi hai giờ, mới có giải pháp. Áp lực tiến hóa đẩy mọi người sang phía "nhanh". Nếu bạn chậm mà cẩn thận, những kẻ cạnh tranh dùng trí tuệ nhân tạo sẽ đánh bại bạn.

Nhưng nghe tôi nói rõ: bạn vẫn có lựa chọn. Và nó không phải hard mode hay lựa chọn dành cho những người thần thánh. Đó là những bước thực tiễn, những thứ bạn có thể bắt đầu ngày hôm nay.

Thứ nhất: Quy tắc 30 phút. Khi bạn bị stuck, đừng nhắn tin cho trí tuệ nhân tạo ngay lập tức. Cố gắng 30 phút một mình. Đọc tài liệu, tìm kiếm trên mạng, gỡ lỗi bằng tay, đoán và kiểm tra. Nó khó chịu và buồn tẻ. Nhưng sau 30 phút đó, khi bạn cuối cùng hỏi trí tuệ nhân tạo, bạn sẽ hiểu vấn đề đủ sâu để phân biệt giữa câu trả lời tốt và xấu. Bạn sẽ không chỉ copy-paste. Bạn sẽ thực sự học. Đó là khi tăng trưởng xảy ra.

Thứ hai: Buộc bản thân viết mã mà không có trí tuệ nhân tạo ít nhất 30% thời gian làm việc. Hãy chọn một dự án nhỏ, có thể một công cụ dòng lệnh, một script tự động hóa, thứ gì đó mà bạn có thể kiểm soát. Không có gợi ý tự động, không có gợi ý khi bạn gõ. Dùng một trình soạn thảo đơn giản, terminal, và bộ não của bạn. Nó sẽ chậm. Syntax error sẽ xảy ra. Nhưng bộ não của bạn sẽ thích ứng. Bạn sẽ nhớ cú pháp tốt hơn. Bạn sẽ bắt đầu thấy pattern. Bạn sẽ thực sự hiểu cái gì bạn đang làm thay vì chỉ làm theo hướng dẫn.

Thứ ba: Đọc mã từ các nguồn thực tế. Mở Linux kernel. Đọc Redis source. Tìm hiểu cách thư viện Go tiêu chuẩn được viết. Không phải để copy-paste. Mà để hấp thụ. Để thấy cách những kỹ sư thực sự - những người đã chi tiêu thập kỷ - suy nghĩ về code. Dòng mã từ họ nói lên những trực giác mà bạn không thể học từ tutorial. Cấp phát một thời gian hàng tuần chỉ để đọc, không để viết. Nó tẻ nhạt. Nhưng nó là nơi mà sự khôn ngoan tích tũy.

Thứ tư: Gỡ lỗi thủ công. Khi code break, đừng hỏi trí tuệ nhân tạo ngay. Thêm logging, mở debugger, trace through execution từng dòng. Hình dung luồng dữ liệu. Hình thành giả thuyết. Kiểm tra giả thuyết. Gỡ lỗi là một hình thức thám tử công. Nó dạy bạn suy nghĩ hệ thống. Nó dạy bạn quan sát. Là lúc bạn thực sự học cách máy tính hoạt động.

Thứ năm: Dạy cho người khác. Tìm một người trẻ tuổi hơn bạn. Dạy họ những gì bạn biết. Không phải bài giảng trình bày, mà là hợp tác thực sự. Giải thích code, giải thích quyết định thiết kế, chia sẻ những sai lầm bạn đã mắc phải. Khi bạn giải thích, bạn sẽ nhận ra những lỗ hổng trong hiểu biết của chính mình. Bạn buộc phải suy nghĩ sâu hơn. Và bạn sẽ tìm thấy rằng việc dạy là cách học nhanh nhất.

Thứ sáu: Chọn một người cố vấn thực sự - hoặc là một. Nếu bạn có thể, hãy tìm một senior developer sẵn lòng dành thời gian cho bạn. Không phải AI. Một con người thực sự có kinh nghiệm. Họ sẽ mách bạn những cái tẫu khiêm tốn nhất - không phải những gì để học, mà cách để suy nghĩ. Cách để cân bằng tốc độ và chất lượng. Cách để biết khi nào cắt góc là ổn và khi nào nó là sai lầm. Trí tuệ nhân tạo không thể dạy bạn điều này. Chỉ có con người.

Thứ bảy: Bắt đầu một dự án nhỏ từ đầu. Không phải một thứ được tạo ra từ template hoặc scaffolder. Nhưng một dự án thực tế mà bạn phải thiết kế kiến trúc, lập kế hoạch, dự đoán các vấn đề, và giải quyết chúng. Có thể nó là một công cụ nhỏ, có thể là một hệ thống để theo dõi tài chính cá nhân, hoặc bất cứ cái gì. Điểm là bạn phải làm tất cả - không chỉ implement, mà thiết kế. Nó sẽ xấu. Bạn sẽ làm lại. Nhưng từ đó, bạn sẽ hiểu tại sao những kiến trúc nhất định hoạt động tốt và những cái khác không.

Thứ tám: Theo dõi nợ kiến thức của bạn một cách tự nguyện. Tạo một danh sách. "Tôi không biết làm sao binary search hoạt động." "Tôi không hiểu pointer." "Tôi không biết cách database index được tổ chức." Sau đó, thực sự dành thời gian để học chúng. Không phải để vượt qua cuộc phỏng vấn. Nhưng để thực sự biết. Thêm một mục mỗi tuần. Hoàn thành một mục mỗi tuần. Kiên trì. Năm năm từ bây giờ, khi bạn nhìn lại danh sách đó, bạn sẽ nhớ lại người bạn đã là ai khi chưa biết những điều này. Và bạn sẽ tôn trọng con đường.

Thứ chín: Đặt chuyện vào bối cảnh của bạn. Bạn không cần phải hoàn toàn tránh trí tuệ nhân tạo. Nhưng sử dụng nó như một công cụ tham khảo, không phải suy nghĩ thay thế. Hỏi nó để giải thích khái niệm. Hỏi nó để xem xét thiết kế. Nhưng bạn viết code. Bạn tạo quyết định. Bạn chủ sở hữu kết quả. Đó là sự khác biệt giữa một kỹ sư và một người bấm nút.

Thứ mười: Đừng so sánh tốc độ của bạn với tốc độ của những zombie. Họ sẽ kết thúc PR nhanh hơn bạn. Tính năng của họ sẽ đi vào production trước. Nhưng sáu tháng từ bây giờ, khi bug tinh tế xuất hiện, khi hệ thống cần được mở rộng, khi bạn cần để thay thế hai dòng code thay vì viết một cẩu thả cứu cấp? Bạn sẽ là người giải quyết nó. Bạn sẽ là người hiểu nó. Bạn sẽ là người được trả lương khủng khiếp để khắc phục bộn bề của người khác. Đây không phải về chiến thắng ngắn hạn. Đây là về khôn ngoan dài hạn.

Tôi dự đoán: trong năm năm tới, 80% lập trình viên mới sẽ là "Kỹ sư Nhắn Tin", 15% sẽ là lai (dùng trí tuệ nhân tạo nhưng duy trì một số suy nghĩ), 5% sẽ là thực sự lập trình viên (những nguyên lý cơ bản, sâu sắc, độc lập). Top 5% đó sẽ trở nên vô cùng quý giá. Vì khi mọi hệ thống được xây dựng bởi những Kỹ sư Nhắn Tin sụp đổ (và nó sẽ), bạn cần những người hiểu tại sao.

Điều tôi đang nói với bạn là: bạn có thể ở trong top 5% đó. Nó sẽ mất thời gian. Nó sẽ buồn tẻ. Nó sẽ có những lúc bạn cảm thấy chậm, lỗi thời, bị lại phía sau. Nhưng khi bạn nhìn quanh năm năm từ bây giờ, bạn sẽ thấy hàng chục "Kỹ sư Nhắn Tin" đã bị thay thế bởi một nút ấn tốt hơn, một mô hình tốt hơn, một công cụ tốt hơn. Nhưng bạn - những người thực sự hiểu - sẽ vẫn đứng. Bạn sẽ vẫn có giá trị. Bạn sẽ vẫn cần thiết.

Tôi không biết liệu chúng ta có thể quay lại được không. Cấu trúc khuyến khích của thế giới công nghệ (chuyển động nhanh, phá vỡ mọi thứ, sử dụng trí tuệ nhân tạo ở mọi nơi) không khuyến khích công việc sâu. Tốc độ được khen thưởng, chất lượng không. Nhưng những lập trình viên giống bạn - những người từ chối là Zombie - là ánh sáng trong bóng tối.

Tiếp tục viết mã bằng tay. Tiếp tục hiểu những nguyên lý cơ bản. Tiếp tục hướng dẫn. Tiếp tục suy nghĩ.

Vì khi trí tuệ nhân tạo trở nên phổ biến, điều duy nhất còn có giá trị là sự khôn ngoan của con người. Và sự khôn ngoan không thể được tạo ra.

Bạn có một lựa chọn hôm nay. Hãy chọn cái khó. Hãy chọn cái mà bạn sẽ vui vẻ khi nhìn lại.

Kết:

• Nếu bạn đang hoài nghi bài viết này có sử dụng AI không thì câu trả lời là có!