Chúng ta nên tham vọng hơn với phần mềm mình xây dựng

Trong giới phát triển phần mềm, có một nghịch lý đang diễn ra: các mô hình AI ngày càng mạnh, nhưng niềm tin của công chúng vào phần mềm do AI tạo ra lại ngày càng giảm. Bài viết mới của Dan Luu — một kỹ sư phần mềm nổi tiếng với các phân tích kỹ thuật sâu sắc — đặt ra một câu hỏi đáng suy ngẫm: liệu chúng ta có đang quá dè dặt với những gì mình có thể xây dựng?

Khi một dự án "ảo giác" lại tạo ra giá trị thật

Michael Malis, tác giả của dự án pgrust — nỗ lực viết lại PostgreSQL bằng Rust — đã nhiều lần nói với Dan Luu rằng "chúng ta nên tham vọng hơn với phần mềm mình xây dựng".

Phản ứng đầu tiên của phần lớn người quan tâm là hoài nghi, và điều đó hoàn toàn dễ hiểu. Trên các diễn đàn công nghệ, mỗi khi pgrust được nhắc đến, đa số bình luận đều gạt đi như một sản phẩm "vibeslop" — thuật ngữ chỉ những dự án được tạo ra bằng cách để AI viết code theo cảm hứng mà không có kiểm chứng nghiêm túc.

Nhưng có một chi tiết đáng chú ý: trong quá trình kiểm thử pgrust, nhóm của Malis đã phát hiện ra hàng loạt lỗi thực sự trong PostgreSQL, bao gồm:

• Một lỗi số học khiến các thao tác SP-GiST hợp lệ bị thất bại
• Một lỗi cache định dạng gây ra kết quả sai từ JSONPath
• Một lỗi trong pgcrypto khiến các thao tác sau đó bị hỏng
• Nhiều lỗi an toàn bộ nhớ trong bộ nạp từ điển
• Một lỗi tràn số trong kiểu dữ liệu money

Ngay cả khi pgrust không bao giờ thành công, chỉ riêng việc dám thử đã giúp PostgreSQL trở nên tốt hơn một cách bền vững.

Vấn đề không nằm ở AI, mà ở cách chúng ta dùng nó

Dan Luu thừa nhận rằng sự hoài nghi là có cơ sở. Là người dùng phần mềm, ai cũng từng gặp những ứng dụng chậm chạp nhưng được quảng cáo là nhanh nhờ một bài benchmark nào đó. Phần mềm kém chất lượng chưa bao giờ phổ biến đến thế.

Nhưng với tư cách là người xây dựng phần mềm, việc gần như tất cả các dự án khác đều là "vibeslop" không thành vấn đề. Bạn vẫn có thể tạo ra những thứ như pgrust — những dự án trước đây quá lớn để khả thi — miễn là bạn kiểm thử và đo lường một cách nghiêm túc.

Tác giả dẫn chứng trải nghiệm cá nhân: với tư cách một người không biết gì về regex, thuật toán so khớp chuỗi hay trình biên dịch, ông đã xây dựng được:

• Một regex engine có thể tinh chỉnh để nhanh hơn các thư viện đa dụng trên bất kỳ khối lượng công việc cụ thể nào
• Một bản fork của ripgrep sử dụng trình biên dịch mã gốc từ regex engine
• Một bản Rust tùy biến giúp tăng tốc đáng kể thời gian build cho các dự án của mình

Theo ước tính của ông, những dự án này trước đây sẽ mất một năm hoặc hơn để đạt chất lượng "chạy được cho tôi". Giờ đây, chúng chỉ tốn vài giờ làm việc.

Khoảng cách giữa "làm được" và "kiểm chứng được"

Một trong những quan sát sâu sắc nhất trong bài viết liên quan đến dự án AI chơi cờ Azul. Dan Luu kể rằng khi dùng GPT-5.1/5.2, ông mất khoảng 5 giờ để tạo ra một AI ở mức siêu phàm. Nhưng khi một người khác — Gabriel Cangussu — dùng các mô hình mới hơn (Fable 5.1, Opus 5.5), anh ta đã đánh bại AI của Luu với thời gian ít hơn đáng kể.

Điểm khác biệt then chốt: các mô hình mới hiểu lĩnh vực AI trò chơi bàn cờ tốt hơn hẳn. Với GPT-5.1/5.2, gần như mọi gợi ý đều sai và Luu phải tự điều chỉnh rất nhiều. Với các mô hình mới hơn, điều đó không còn cần thiết.

Tuy nhiên, tác giả cũng đưa ra một cảnh báo quan trọng:

Khi mọi người nói rằng họ dùng mô hình mới và mọi thứ "chỉ chạy được", bài toán phần mềm đã được giải quyết — tôi không thấy điều đó đúng chút nào. Sự thật là có nhiều thứ hơn mà mô hình mới có thể làm một phát ăn ngay, nhưng điều đó chỉ có nghĩa là tôi lại chuyển sang làm những thứ tham vọng hơn, nơi mô hình vẫn còn vất vả.

Khoảng cách giữa những gì mô hình có thể triển khai và những gì mô hình có thể tự kiểm chứng mà không cần con người hỗ trợ đang ngày càng rộng ra. Đây là lý do vì sao kỹ năng lập trình của con người vẫn — và có lẽ còn hơn bao giờ hết — là đòn bẩy quan trọng.

Lời phản biện: không phải ai cũng nên tham vọng

Bài viết cũng bao gồm một phụ lục đáng chú ý trích dẫn Yossi Kreinin, người đề nghị được phản biện lại quan điểm trên:

Nếu bạn công bố bài này, tôi sẽ công bố một bài phản hồi giải thích rằng với hầu hết mọi người, họ nên bớt tham vọng với phần mềm do AI xây dựng, nếu không họ sẽ gặp thất bại thảm hại. Nhiều vấn đề không phù hợp với các "vòng lặp agent" vì bạn không có tiêu chí đúng/sai rõ ràng.

Kreinin so sánh tình huống này với kiến trúc microservices: một số người thực sự cần và rất giỏi dùng nó, nhưng phần lớn mọi người không cần lắm và cũng không dùng tốt. Ông nhắc đến một ví dụ đáng lo: nếu bạn có một quản lý tin rằng "không có lý do gì phần mềm phải chậm" và ép nhân viên dùng AI để tăng tốc các phần ngẫu nhiên của hệ thống — hãy chạy ngay đi.

Góc nhìn từ thực tế Việt Nam

Đối với cộng đồng phát triển phần mềm Việt Nam, bài viết này đưa ra vài gợi ý thực tiễn đáng cân nhắc:

• Đầu tư vào kiểm thử và benchmark thay vì chỉ chạy theo tính năng mới là yếu tố quyết định chất lượng. Đây là điểm yếu cố hữu của nhiều dự án phần mềm trong nước.
• Kỹ năng nền tảng vẫn quan trọng: hiểu hệ thống phân rã thành những phần nào, khi nào nên tối ưu sâu một phần, và cách đo lường đúng — những thứ AI chưa thay thế được.
• Tận dụng AI cho các công cụ nội bộ: những tiện ích nhỏ phục vụ riêng cá nhân hay đội nhóm, trước đây không đáng bỏ thời gian, giờ đây có thể tạo ra trong vài phút. Đây có thể là bước khởi đầu an toàn nhất.
• Cẩn thận với văn hóa "AI làm được hết": các doanh nghiệp cần quy trình đánh giá chất lượng nghiêm túc trước khi đưa sản phẩm do AI hỗ trợ vào môi trường production.

Kết luận

Thông điệp cốt lõi của Dan Luu có thể tóm gọn như sau: sự thật rằng nhiều người đang tạo ra những đống phần mềm kém chất lượng không có nghĩa là bạn phải làm theo. Công cụ đã đủ mạnh để những dự án từng quá tốn kém trở nên khả thi — nhưng tham vọng chỉ có ý nghĩa khi đi kèm với kỷ luật kỹ thuật.

Như chính tác giả thừa nhận, nếu do ông viết lại tiêu đề, có lẽ ông sẽ chọn "chúng ta có thể tham vọng hơn" thay vì "chúng ta nên tham vọng hơn". Bởi lẽ, câu hỏi không phải là bạn có nên thử hay không, mà là bạn có đủ hiểu biết để biết mình đang làm gì hay không.