Lập trình chưa hề được giải quyết: Góc nhìn từ một kỹ sư kỳ cựu

Trong bối cảnh AI tạo sinh đang bùng nổ, không ít người tuyên bố rằng "lập trình đã được giải quyết" và giá trị của kỹ sư giờ đây chỉ nằm ở "gu thẩm mỹ". Một kỹ sư phần mềm kỳ cựu với hai bằng kỹ thuật đã lên tiếng phản bác quan điểm này, cho rằng chính lập trình lại là một trong những lĩnh vực khó bị LLM thay thế nhất.

Bài viết gốc trên blog của Alex Ewerlöf nhanh chóng thu hút sự chú ý trên Hacker News, làm dấy lên cuộc tranh luận sôi nổi về ranh giới giữa khả năng sinh mã của AI và giá trị thực sự của người kỹ sư.

Tạo mã dễ, duy trì mới khó

Theo tác giả, những người khẳng định "LLM có thể viết code ổn" thường không hiểu cách phần mềm vận hành. Việc tạo mã nguồn giờ đây rẻ hơn nhiều, nhưng bất kỳ ai từng vận hành phần mềm ở quy mô lớn đều biết rằng phần lớn chi phí nằm ở khâu duy trì, độ tin cậy, bảo mật và khả năng mở rộng — những yếu tố thường được gọi là yêu cầu phi chức năng (NFR).

Yêu cầu phi chức năng và những yếu tố quyết định chất lượng phần mềm

Thực tế, ngay cả các yêu cầu chức năng (FR) — tức mã nguồn phải làm đúng điều nó được thiết kế để làm — cũng vẫn chưa được giải quyết trọn vẹn. Tác giả chỉ ra hiệu ứng Dunning-Kruger trong lĩnh vực này: những người không đọc kỹ mã nguồn do AI tạo ra lại là những người tự tin nhất về chất lượng của nó.

Ông phân loại ba dạng sản phẩm không nhất thiết phải đọc kỹ mã nguồn:

• Phần mềm cá nhân: tự động hóa, tiện ích DIY, các bản vá nhỏ
• Bản thử nghiệm (POC): chứng minh tính khả thi kỹ thuật và sản phẩm
• AI vũ khí hóa: cố tình nhắm vào mục tiêu để gây hại

Điểm chung của cả ba là đều có mức độ chấp nhận rủi ro cao. Ngược lại, phần lớn phần mềm cần thuê kỹ sư chuyên nghiệp lại có mức chấp nhận rủi ro thấp: y tế, tài chính, ô tô, quốc phòng, nhà máy điện, hàng không, sản xuất — nơi một sai sót có thể gây thiệt hại về tiền bạc, tính mạng hoặc hệ lụy pháp lý.

AI không thể chịu trách nhiệm

Một lập luận quan trọng của tác giả là AI không thể bị quy trách nhiệm. AI không thể bị phạt, không thể bị tù, không thể mất việc. Điều tồi tệ nhất có thể xảy ra với nó là bị rút phích cắm. Vì không thể trừng phạt AI, nên nó mãi mãi không thể chịu trách nhiệm.

Con người cũng không thể chịu trách nhiệm cho những gì mình không kiểm soát được. Hiểu được nguyên lý này là chìa khóa để lý giải hành vi hệ thống và khắc phục khi AI thất bại.

AI không thể bị quy trách nhiệm. Nó không thể gánh chịu bất kỳ hệ quả nào.

Vì sao lập trình vẫn chưa được giải quyết?

Trái với quan niệm phổ biến, tác giả cho rằng lập trình là một trong những lĩnh vực cuối cùng mà LLM có thể tiếp quản. Lý do rất đơn giản: lập trình gắn liền với logic. Bất kỳ ai từng gặp lỗi biên dịch đều biết máy tính không quan tâm bạn nghĩ mình đúng đến đâu — nếu logic sai, mã không biên dịch được.

LLM thành công trong việc viết code một phần nhờ chúng ta đã tạo ra vòng lặp phản hồi: đưa lỗi cú pháp và lỗi thời gian chạy trở lại cho LLM, lặp đi lặp lại cho đến khi hầu hết lỗi được xử lý hoặc che giấu.

LLM có thể "ứng biến" tốt với các tác vụ ngôn ngữ tự nhiên như viết bài đăng mạng xã hội, báo cáo, bài viết. Nhưng khi nói đến code, chính cỗ máy đôi khi không đếm nổi số chữ "R" trong từ "Raspberry" cũng bộc lộ những ngụy biện logic khác.

LLM mang tính xác suất và ngẫu nhiên. Cách duy nhất để đưa chúng đến gần logic là bọc chúng trong code truyền thống (gọi là harness), chạy kiểm thử và áp dụng nhiều kỹ thuật khác như Chain-of-Thought. Nhưng vấn đề cốt lõi vẫn còn: LLM gặp khó khăn với logic và khối lượng — đầu vào càng lớn, cửa sổ ngữ cảnh càng bị lấp đầy, độ chính xác càng giảm.

Sự khác biệt giữa con người và AI trong việc nhận diện lỗi logic

Tác giả liệt kê những đặc điểm của người tuyên bố phần mềm do LLM tạo ra là "đủ tốt":

• Lâu rồi không viết code
• Không thể nhận ra code của mình "có sáu ngón tay"
• Đặt tiêu chuẩn thấp cho cái gì là "tốt"
• Không quan tâm chất lượng hay NFR
• Khó hiểu đường cong chữ S (S-curve)

Đường cong chữ S và điểm lợi suất giảm dần

Tác giả không phủ nhận sức mạnh của AI. Ông thừa nhận mình là người dùng sớm các công cụ lập trình dựa trên LLM, từng xây dựng harness riêng, giảng dạy về chủ đề này và phát triển sản phẩm AI. Vấn đề ông phản đối là câu chuyện nửa vời rằng "lập trình đã được giải quyết".

Khả năng của LLM đang tăng theo đường cong chữ S, nhưng có một điểm mà lợi suất giảm dần: các mô hình đắt tiền hơn không nhất thiết cho năng suất cao hơn tương ứng với mức giá tăng thêm.

Đường cong chữ S trong sự phát triển năng lực của AI

Những ngụy biện phổ biến

Tác giả điểm mặt một loạt lập luận thường gặp từ phe "AI thay thế lập trình viên":

"Có thể viết đặc tả đầy đủ trước khi làm" — Bất kỳ ai có vài năm kinh nghiệm đều biết điều này gần như bất khả thi với phần mềm không tầm thường. Phần mềm tiến hóa qua thời gian, và đặc tả không bao giờ đầy đủ ngay từ đầu.

"Tiếng Anh thay thế code" — Ngôn ngữ tự nhiên vốn mơ hồ và mâu thuẫn. Đó chính là lý do ngôn ngữ lập trình ra đời. Làm sao đảm bảo một phần chỉ dẫn ngôn ngữ tự nhiên không xung đột với phần khác?

"Tôi làm nhanh hơn nhiều" — Đừng nhầm chuyển động với tiến bộ. Đừng đo lường bằng SLOC, số lượng PR hay tính năng. Hãy đo bằng mức độ hài lòng của người dùng dịch vụ.

"Lợi thế đã chuyển sang gu thẩm mỹ" — Ai cũng có gu riêng. AI đã hạ thấp ngưỡng kỹ năng để tạo phần mềm trông ổn, đồng thời nâng cao ngưỡng cho nỗ lực xứng đáng được trả tiền.

"Agent là trình biên dịch mới" — Một meme hài hước hơn là một luận điểm kỹ thuật nghiêm túc.

Đừng quên bài học về tư duy

Tác giả nhấn mạnh rằng code chỉ là hệ quả của tư duy và thử nghiệm. Ông chưa từng gặp kỹ sư giỏi nào lao vào viết code ngay sau khi nhận bài toán. Kỹ sư giỏi tò mò, có tư duy sản phẩm, cố hiểu TẠI SAO trước khi tìm ra LÀM THẾ NÀO.

Code chỉ là sản phẩm phụ của quá trình tư duy và giải quyết vấn đề

Thu hẹp công việc của kỹ sư thành "viết code" cũng giống như thu hẹp công việc của đầu bếp thành "thái rau". Đó là một phần của công việc, nhưng chưa bao giờ là toàn bộ.

Cảnh báo về "quá liều AI"

Tác giả đưa ra một danh sách các dấu hiệu nhận biết lạm dụng AI (AI overdose):

• Không khoan dung với ý kiến trái chiều và tranh luận văn minh
• Để AI điều khiển cuộc sống, tin tưởng các nhà cung cấp AI với những thứ mà vài năm trước không thể tưởng tượng nổi
• Chạy đến AI với những việc chỉ hơi khó về mặt nhận thức
• Ngừng đọc văn bản dài: sách, bài báo, thậm chí email dài
• Dành nhiều thời gian với AI hơn là với người thật

Ông cũng cảnh báo về kinh tế học của phần mềm: nếu AI 1000 lần nhanh hơn và 100 lần rẻ hơn con người, thì nhiều tác vụ không đáng để đặt một kỹ sư chậm chạp và đắt đỏ vào. Nhưng với phần mềm quan trọng (y tế, tài chính, quân sự), "chậm mà chắc" vẫn xứng đáng.

Làn sóng sa thải và câu chuyện đằng sau

Tác giả chỉ trích các CEO và quản lý vội vàng đặt chỉ số tiêu thụ token làm thước đo năng suất. Ông nhắc đến ví dụ Tobi Lutke của Shopify, người từng thúc đẩy nhân viên dùng AI, rồi một năm sau lại gọi kết quả là "lựu đạn rác" (slop grenades).

AI có thể giải thích cho bạn, nhưng nó không thể hiểu thay bạn. Sự hiểu biết đó là khía cạnh then chốt của quyền sở hữu.

Tác giả định nghĩa quyền sở hữu gồm ba trụ cột:

1. Kiến thức: bạn hiểu vấn đề đang giải quyết, giới hạn của công nghệ và cách nó vận hành
2. Thẩm quyền: bạn được tin tưởng và trao quyền quyết định
3. Trách nhiệm: khi sự cố xảy ra, bạn là người trực tiếp gánh chịu

Ba trụ cột của quyền sở hữu trong kỹ thuật phần mềm

Lời khuyên cho kỹ sư Việt Nam

Với các kỹ sư phần mềm Việt Nam — đặc biệt là những người làm việc trong các dự án gia công cho thị trường nước ngoài — bài viết này mang thông điệp quan trọng:

• Đừng vội vàng giao phó toàn bộ quá trình tư duy cho AI. Giữ kỹ năng lập trình và đọc hiểu mã nguồn luôn là lợi thế cạnh tranh.
• Nuôi dưỡng một dự án cá nhân không dùng AI để giữ kỹ năng luôn tươi mới, phòng khi quay lại thị trường lao động.
• Hiểu rõ trách nhiệm nghề nghiệp: nếu bạn ký duyệt mã nguồn do AI tạo ra, bạn là người chịu trách nhiệm.
• Cảnh giác với dữ liệu: chỉ nên dùng AI đám mây cho dự án mã nguồn mở hoặc dữ liệu công khai. AI chạy cục bộ (local) tuy khó thiết lập hơn nhưng đảm bảo dữ liệu không bị khai thác.

Tác giả kết luận rằng AI không phải là thảm họa, mà là công cụ nâng cao tiêu chuẩn: nếu chất lượng đầu ra của bạn ngang bằng hoặc kém hơn AI, hãy nâng cấp kỹ năng. Ngành công nghiệp phần mềm chắc chắn sẽ thay đổi, nhưng lập trình — với tư cách là một hoạt động đòi hỏi tư duy logic, trách nhiệm và hiểu biết sâu sắc — sẽ không biến mất.