# Kỹ sư kỳ cựu phản bác quan điểm 'AI đã giải quyết xong bài toán lập trình'

- Nguồn: Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung)
- Thời gian phát hành: 2026-09-28 22:04 (giờ Việt Nam)
- Điểm AI: 60/100
- Link AIHOT.vn: https://aihot.vn/items/e0ca627e95bb60dc
- Nguồn dữ liệu AI HOT: https://aihot.news/items/maib9kw02zfmnmwvkz65ud7pi
- Link gốc: https://blog.alexewerlof.com/p/coding-is-not-solved

## Tóm tắt AI

Alex Ewerlof khẳng định lập trình vẫn là thách thức lớn vì AI chưa thể đảm nhận trách nhiệm về bảo trì, độ tin cậy và bảo mật. Tác giả bác bỏ các quan điểm cực đoan về AI và khuyên kỹ sư cần giữ tư duy phản biện thay vì phụ thuộc hoàn toàn vào công cụ.

## Thân bài

![Coding is NOT solved](https://substackcdn.com/image/fetch/$s_!-Pk4!,w_1200,h_675,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F409bf75a-d9ef-4adf-b242-bee9d2664a24_1280x1247.jpeg)

Tuyên bố miễn trừ trách nhiệm: Bạn sắp đọc rất nhiều ý kiến cá nhân, nhiều trong số đó có dẫn chứng nhưng một số là kết quả từ trải nghiệm thực tế của tôi khi xây dựng hệ thống AI trong 4 năm qua. Dù sao đi nữa, hãy cảnh giác với ngụy biện "bù nhìn" (straw-man fallacy): chỉ vì một lập luận không khớp với hệ thống niềm tin của bạn, không có nghĩa là những lập luận còn lại đều vô giá trị. Tôi cũng nên nói trước rằng tôi không bài trừ AI. Nếu bạn theo dõi công việc của tôi, bạn biết rằng tôi là người sớm áp dụng không chỉ các công cụ lập trình hỗ trợ bởi LLM, mà còn tự xây dựng các bộ khung (harness), giảng dạy về các chủ đề này và phát triển các sản phẩm tích hợp LLM. Vấn đề không phải là nỗi sợ AI, mà là thách thức lại cái tư duy sáo rỗng cho rằng "lập trình đã xong xuôi" và kỹ thuật giờ đây chỉ là vấn đề về "gu thẩm mỹ".

Cập nhật: Có người đã đăng bài này lên [Hackernews](https://news.ycombinator.com/item?id=49877988).

Hãy nói với tôi rằng bạn không hiểu gì về phần mềm mà không cần phải dùng chính những từ đó đi!!!

Những người khẳng định "LLM có thể viết code ổn" là những người không hiểu code vận hành như thế nào. Chắc chắn, việc tạo ra code rẻ hơn nhiều, nhưng bất kỳ ai từng vận hành phần mềm ở quy mô thực tế (production) đều biết rằng bảo trì, độ tin cậy, bảo mật, khả năng mở rộng, v.v. mới là phần chiếm chi phí lớn nhất. Đây thường được gọi là [NFR](https://blog.alexewerlof.com/p/nfr) (yêu cầu phi chức năng).

Theo kinh nghiệm của tôi, ngay cả các Yêu cầu chức năng (những gì code phải thực hiện) cũng CHƯA phải là vấn đề đã được giải quyết. Có một chút hiệu ứng Dunning-Kruger ở đây, khi những người không đọc kết quả đầu ra lại là những người tự tin nhất về nó.

![](https://substackcdn.com/image/fetch/$s_!jeOZ!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9b522de2-d9a4-43f8-bf5e-b8c668bcbd90_1104x399.png)

Là một lập trình viên kỳ cựu với 2 bằng kỹ sư (kỹ thuật phần cứng và kỹ thuật hệ thống), tôi có thể liệt kê 3 loại sản phẩm không nhất thiết phải đọc code:

1. Phần mềm cá nhân: giải quyết nhu cầu nhỏ, tự động hóa, các bản vá tự làm (DIY), v.v.
2. POC (bằng chứng khái niệm): chứng minh tính khả thi về kỹ thuật và tiềm năng của sản phẩm.
3. AI vũ khí hóa: thừa nhận rủi ro và cố tình hướng nó vào mục tiêu để gây hại.

Hãy chú ý điểm chung: 2 loại đầu có khả năng chấp nhận rủi ro cao, trong khi loại cuối cùng vũ khí hóa chính rủi ro vốn có đó.

Hầu hết các phần mềm cần thuê và trả lương cho kỹ sư phần mềm đều có khả năng 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

…bất cứ nơi nào mà một sai lầm có thể gây tốn kém tiền bạc, tính mạng hoặc hậu quả pháp lý, bạn đều cần trách nhiệm giải trình.

AI không thể chịu trách nhiệm. Nó không thể gánh chịu bất kỳ hậu quả nào. Điều tồi tệ nhất bạn có thể làm với AI là rút phích cắm. Và mặc dù nó bắt chước cảm xúc con người (do dữ liệu huấn luyện), nó chẳng hề quan tâm. AI cũng không chết. Nó không thể bị phạt tù hay phạt tiền. Bạn không thể trừng phạt AI, do đó nó không bao giờ có thể chịu trách nhiệm.

Bạn cũng không thể chịu trách nhiệm cho những gì bạn không thể kiểm soát. Sự thấu hiểu đó là chìa khóa để suy luận về hành vi của hệ thống và sửa chữa nó khi AI chắc chắn sẽ thất bại.

Nếu bạn chỉ đang nghịch ngợm, LLM làm rất tốt. Đó là lý do tại sao một số người ủng hộ mạnh mẽ nhất cho luận điệu "lập trình đã xong" lại chẳng có gì để chứng minh. Anthropic vô tình làm rò rỉ Claude Code (sau khi nghiên cứu kỹ thì thấy có nhiều lỗi) và trang trạng thái của họ cho thấy màu cam đang là màu xanh mới!

Trái ngược với quan điểm phổ biến, lập trình thực tế là một trong những lĩnh vực cuối cùng mà thế hệ LLM hiện tại có thể chiếm lĩnh!!!

Cho phép tôi giải thích rõ hơn:

Lập trình là về logic. Bất kỳ ai từng đối mặt với lỗi trình biên dịch đều biết rằng máy tính không quan tâm bạn nghĩ mình đúng đến mức nào. Nếu sai logic, nó sẽ không biên dịch được. Ngay cả khi cú pháp ổn, vẫn sẽ có lỗi thời gian chạy (runtime errors).

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

LLM có thể ứng biến với các tác vụ liên quan đến ngôn ngữ tự nhiên (ví dụ: viết bài đăng mạng xã hội, báo cáo, bài viết, v.v.) nhưng khi nói đến code, chính cái công cụ chật vật trong việc đếm số chữ R trong từ "Raspberry" hay gợi ý đi bộ đến tiệm rửa xe, cũng bộc lộ những lỗi logic khác.

LLM mang tính ngẫu nhiên và xác suất. Cách duy nhất để chúng ta có thể tiến gần đến mức làm cho chúng trở nên logic là bao bọc chúng trong code truyền thống (được gọi là harness), chạy thử nghiệm và một loạt các kỹ thuật khác (ví dụ: CoT), 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 dữ liệu (đầu vào càng lớn và cửa sổ ngữ cảnh càng được sử dụng nhiều, chúng càng kém chính xác).

Tôi không nói LLM không thể tạo code hoặc duy trì các cơ sở mã hiện có. Chúng có giá trị như một công cụ và khả năng của chúng đang tăng theo đường cong chữ S. Có một điểm lợi nhuận giảm dần mà ở đó các mô hình đắt tiền hơn không nhất thiết mang lại năng suất tương xứng với mức tăng giá.

![](https://substackcdn.com/image/fetch/$s_!-Pk4!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F409bf75a-d9ef-4adf-b242-bee9d2664a24_1280x1247.jpeg)

Những người khẳng định phần mềm do LLM tạo ra là đủ tốt: ❌ Đã lâu không viết code ❌ Không thể nhận ra nếu code của họ có 6 ngón tay (ẩn dụ) ❌ Có tiêu chuẩn thấp về thế nào là tốt ❌ Không quan tâm đến chất lượng hoặc NFR ❌ Khó hiểu về đường cong chữ S ✅ Trung thực: AI thực sự viết code tốt hơn họ.

Nhưng việc suy diễn điều đó ra toàn bộ một ngành công nghiệp chuyên nghiệp đòi hỏi một mức độ tư duy sáo rỗng chỉ có ở những người dành quá nhiều thời gian với các AI nịnh hót.

Tôi không ở đây để thay đổi quy trình làm việc hay bộ công cụ của bất kỳ ai. Tôi không quan tâm.

Điều tôi quan tâm là các dịch vụ mà tôi đang trả tiền (đang nói đến [Google](https://www.linkedin.com/company/google/) và [GitHub](https://www.linkedin.com/company/github/)) đang xuống cấp với những lỗi ngớ ngẩn mà lẽ ra có thể tránh được nếu chúng ta ưu tiên độ tin cậy và trách nhiệm giải trình hơn là tốc độ.

Nếu bạn đang ở vị trí lãnh đạo, xin đừng gây áp lực lên các lập trình viên [vốn thông minh] của bạn để ép buộc AI vào mọi bề mặt và quy trình làm việc có thể.

Công nghệ này có sức mạnh thực sự và là thay đổi lớn nhất trong ngành của chúng ta từ trước đến nay. Nhưng lạm dụng AI là có thật, và khi nó gây hại cho khách hàng, bạn là người chịu trách nhiệm.

Hãy ngừng lặp lại những luận điệu nửa vời từ những kẻ bán token về việc phóng đại khả năng của AI, bởi vì chúng ta, những người tiêu dùng, là bên phải trả giá cuối cùng.

AI rất tuyệt vời cho POC (bằng chứng khái niệm), Phần mềm cá nhân (một danh mục đang phát triển), Map-reduce trên ngôn ngữ con người (ví dụ: dịch thuật, chuyển đổi định dạng, tóm tắt, mở rộng) và các cuộc tấn công mạng (do sự chênh lệch giữa trí tuệ nhân tạo và trí tuệ hữu cơ) với các mức độ thành công khác nhau, nhưng thế hệ công nghệ hiện tại cũng có những vấn đề cơ bản.

Tôi không muốn hạ thấp những gì chúng ta đã đạt được với harness, SKILLS, AGENTS-md, MCP, A2A, ACP, RLM, OKF, MoE, MoA, tự phục hồi, và các kỹ thuật runtime, lượng tử hóa, tối ưu hóa, kiến trúc và bộ nhớ khác nhau.

Tôi đã viết về nhiều thứ trong số đó trước đây:

_Bài gốc còn tiếp._ Xem tiếp tại: <https://blog.alexewerlof.com/p/coding-is-not-solved>