LLM và Giới hạn của "Viên đạn bạc" trong Phát triển Phần mềm

Mọi người đều đồng ý rằng chúng ta đang ở giữa một giai đoạn mang tính bước ngoặt, dù chính xác đó là gì thì vẫn còn gây tranh cãi. Có thể đó là cuộc cách mạng chưa từng có về năng suất và khả năng, hoặc có thể chỉ là một chu kỳ thổi phồng (hype cycle) khác sẽ qua nhanh. Dù quan điểm ra sao, hàng ngàn bài viết đã được dành để tranh luận về vị trí của LLM (Mô hình Ngôn ngữ Lớn) trong thế giới công nghệ.

Bài viết này sẽ đi sâu vào việc liệu LLM có thực sự là “viên đạn bạc” giải quyết mọi vấn đề của phát triển phần mềm hay không, nhìn nhận từ góc độ của một lập trình viên chuyên nghiệp.

Thuật ngữ và Định nghĩa

Trước hết, cần làm rõ một số thuật ngữ. Trong bài viết này, tôi sẽ sử dụng thuật ngữ “LLM” thay vì “AI” một cách chung chung. “AI” là một khái niệm mơ hồ và quá tải, trong khi hầu hết các vấn đề gây tranh cãi hiện nay trong lập trình đều bắt nguồn cụ thể từ sự ra đời của các mô hình ngôn ngữ lớn.

Khi tôi nói về “lập trình bằng LLM”, tôi ám chỉ việc sử dụng LLM để tạo mã trong một ngôn ngữ lập trình nào đó. Đây là thuật ngữ bao trùm cho mọi hình thức sử dụng, dù có sự giám sát của con người hay không, và dù LLM đóng vai trò là nhà sản xuất mã duy nhất hay chỉ hỗ trợ.

Không có “Viên đạn bạc”

Vài năm trước, tôi đã viết về bài viết kinh điển “No Silver Bullet” (Không có viên đạn bạc) của Fred Brooks. Nếu bạn chưa đọc nó, tôi khuyên mạnh bạn nên đọc. Brooks đưa ra một dự đoán táo bạo về phần mềm:

Không có sự phát triển duy nhất nào, dù trong công nghệ hay kỹ thuật quản lý, hứa hẹn mang lại sự cải thiện một cấp độ lớn (một bậc thang) trong vòng một thập kỷ về năng suất, độ tin cậy hay sự đơn giản.

Để hỗ trợ luận điểm này, Brooks chia các nguồn khó khăn trong phát triển phần mềm thành hai loại:

1. Bản chất (Essence): Những khó khăn vốn có thuộc về bản chất của phần mềm (đặc tả, thiết kế, kiểm thử khái niệm).
2. Ngẫu nhiên (Accidental): Những khó khăn gặp phải trong quá trình sản xuất nhưng không vốn có (ví dụ: quản lý bộ nhớ thủ công).

Brooks tin rằng phần khó nhất của việc xây dựng phần mềm là việc đặc tả, thiết kế và kiểm thử cấu trúc khái niệm, chứ không phải công sức đại diện cho nó dưới dạng mã. Nếu điều này đúng, việc xây dựng phần mềm sẽ luôn khó khăn. Không có viên đạn bạc nào.

Nhiều người hiện nay đang quảng bá LLM như một bước tiến cách mạng dựa trên khả năng tạo mã với tốc độ cao. Tuy nhiên, lập luận của “No Silver Bullet” đặt ra một giới hạn cho những gì chúng ta có thể đạt được chỉ bằng việc tạo mã nhanh hơn. Trong cuốn “The Mythical Man-Month”, Brooks ước tính rằng khoảng năm phần sáu (83%) thời gian cho một “nhiệm vụ phần mềm” được dành cho các việc khác ngoài viết mã. Do đó, việc tăng tốc độ viết mã sẽ không mang lại cải thiện năng suất một cấp độ lớn.

Thực tế: Báo cáo và Số liệu

Nhưng đủ lý thuyết, thực tế của lập trình bằng LLM ra sao? Các dữ liệu thực tế chúng ta có hiện nay khá hỗn hợp.

Nhiều người đã chỉ tôi đến báo cáo của DORA về “Trạng thái Phát triển Phần mềm được hỗ trợ bởi AI”. Mặc dù tóm tắt điều hành cho thấy AI đang trở thành “bình thường mới”, nhưng chi tiết lại cho thấy một bức tranh phức tạp hơn:

Nghiên cứu tiết lộ một sự thật quan trọng: Vai trò chính của AI trong phát triển phần mềm là một bộ khuếch đại. Nó khuếch đại điểm mạnh của các tổ chức hoạt động hiệu quả và sự rối loạn của những tổ chức đang gặp khó khăn.

Báo cáo cũng chỉ ra rằng việc áp dụng AI hiện nay cải thiện thông lượng phần mềm, nhưng đồng thời làm tăng sự không ổn định trong giao hàng. Điều này gợi ý rằng các đội ngũ đang thích nghi để tăng tốc, nhưng các hệ thống cơ bản của họ chưa phát triển để quản lý sự phát triển được tăng tốc bởi AI một cách an toàn.

Tương tự, báo cáo “State of Software Delivery” năm 2026 của CircleCI cũng chỉ ra những lo ngại tương tự. Các chỉ số về sự ổn định cho thấy các thay đổi do AI điều khiển thường bị lỗi nhiều hơn và mất nhiều thời gian hơn để sửa. Tỷ lệ thành công trên nhánh chính đã giảm xuống mức thấp nhất trong 5 năm qua.

Điều đáng lo ngại là việc tự đánh giá năng suất của các lập trình viên thường không chính xác. Một nghiên cứu của METR chỉ ra rằng có sự chênh lệch lớn giữa nhận thức và thực tế: các lập trình viên kỳ vọng AI sẽ giúp họ nhanh hơn 24%, nhưng ngay cả khi trải qua sự chậm trễ, họ vẫn tin rằng AI đã giúp họ nhanh hơn 20%.

Nỗi sợ bị bỏ lại phía sau

Khi thể hiện sự hoài nghi về LLM, một phản ứng phổ biến là việc không áp dụng nó sẽ dẫn đến việc bị “bỏ lại phía sau”. LLM là tương lai, nó sẽ xảy ra dù bạn thích hay không!

Tuy nhiên, tôi thấy hai khả năng:

1. Vị trí hoài nghi thắng: LLM không đạt được trạng thái cách mạng. Nó trở thành một công cụ khác trong hộp công cụ, giống như TDD hay lập trình cặp. Việc áp dụng chậm trễ không có bất lợi nào lớn.
2. Vị trí hoài nghi thua: LLM thực sự trở thành công cụ bắt buộc mang lại cải thiện năng suất khổng lồ. Nhưng để đạt được điều đó, nó phải là một bước đột phá đủ khác biệt so với trạng thái hiện tại, đến mức các quy trình làm việc LLM cũ cũng trở nên lỗi thời. Trong trường hợp đó, kinh nghiệm với các LLM cũ cũng không mang lại lợi thế không thể vượt qua.

Dân chủ hóa lập trình?

Một tuyên bố ủng hộ LLM khác là nó sẽ dân chủ hóa việc tiếp cận phát triển phần mềm. Những người không phải là lập trình viên chuyên nghiệp có thể tạo ra phần mềm giải quyết vấn đề của họ.

Tôi không bị thuyết phục bởi trường hợp sử dụng này. Có vẻ như có sự đồng thuận rộng rãi rằng lập trình bằng LLM là một kỹ năng đòi hỏi sự hiểu biết, thực hành và kinh nghiệm đáng kể trước khi có thể tạo ra kết quả hữu ích nhất quán. Điều này mâu thuẫn trực tiếp với tuyên bố dân chủ hóa rằng một người không có kiến thức lập trình trước đó có thể chỉ cần nhờ LLM và nhận được kết quả chức năng.

Kết quả có khả năng nhất là người dùng không kỹ thuật sẽ nhận được một thứ gì đó rõ ràng không phù hợp với mục đích, vì họ thiếu kiến thức cần thiết để tương tác (prompt) với LLM hiệu quả. Họ không biết cách thiết kế kiến trúc phần mềm tốt, hay cách viết các đặc tả kỹ thuật chi tiết.

Kết luận

Nếu phải tóm tắt vị trí của tôi về lập trình bằng LLM trong một câu, đó sẽ là “Hãy đọc No Silver Bullet”. Tôi nghĩ lập luận của Brooks là đúng về mặt lý thuyết và được xác nhận bởi các kết quả thực nghiệm. Nó đặt ra những giới hạn mạnh mẽ về tác động mà lập trình bằng LLM, hay bất kỳ công cụ nào chỉ tấn công vào khó khăn ngẫu nhiên, có thể có.

Tất nhiên, những giới hạn này không nhất thiết là tận thế. Nhưng đó là lập luận rằng bất kỳ lợi ích nào chúng ta đạt được có khả năng sẽ tăng trưởng theo kiểu tiến hóa, chứ không phải là cuộc cách mạng thay đổi thế giới mà nhiều người mong đợi.

Tôi nghĩ không có bất lợi lớn nào hiện nay đối với việc áp dụng chậm LLM. Rất ít tổ chức có nền tảng mạnh cần thiết để hấp thụ sự gia tăng mã nguồn, đó là lý do nhiều báo cáo tìm thấy kết quả hỗn hợp và nhiều đường dẫn CI bị hỏng. Không có viên đạn bạc, và đặc biệt không có lợi ích nhanh chóng hay phép thuật nào từ việc vội vàng áp dụng LLM mà không làm việc trước trên các nền tảng cơ bản.

Thay vì sợ bị bỏ lại phía sau, bạn nên tập trung vào các nguyên tắc cơ bản: kiểm soát phiên bản, bộ kiểm thử toàn diện, tích hợp liên tục, tài liệu có ý nghĩa, chu kỳ phản hồi nhanh... những thứ đã được biết đến và chứng minh trong nhiều thập kỷ.

Như Fred Brooks đã nói:

Bước đầu tiên toward việc quản lý bệnh tật là thay thế các lý thuyết về quỷ dữ và dịch humours bằng lý thuyết về vi khuẩn. Bước đi đó, sự khởi đầu của hy vọng, chính nó đã dập tắt tất cả hy vọng về các giải pháp ma thuật. Nó nói với những người lao động rằng tiến bộ sẽ được thực hiện từng bước một, với nỗ lực lớn, và rằng sự chăm chỉ, kiên trì sẽ phải trả cho một kỷ luật về sự sạch sẽ. Cũng như vậy với kỹ thuật phần mềm ngày nay.