Tôi không trở thành nhà phát triển để đánh giá sản phẩm AI kém chất lượng.

Tuy nhiên, gần đây, công việc lại mang đến cảm giác chính xác như vậy. Hàng đợi PR (Pull Request) của tôi đầy ắp những công việc mà, về mặt kỹ thuật, có thể biên dịch được. Bản tóm tắt nghe có vẻ hợp lý. Thậm chí có thể có một số thử nghiệm. Nhưng khi tôi mở bản diff (bản so sánh thay đổi), công việc thực sự mới bắt đầu. Thay đổi này được cho là để làm gì? Có ai thực sự chạy luồng (flow) này không? Tại sao đoạn mã trợ giúp (helper) này lại bị trùng lặp sáu lần? Đây có thực sự là sửa lỗi, hay AI chỉ chạy vòng quanh và tuyên bố đã hoàn thành? AI đã giúp mọi người trong nhóm của tôi (và của bạn) tạo mã một cách dễ dàng, nhưng nó không làm cho mã đó đáng tin cậy. Khảo sát Nhà phát triển năm 2025 của Stack Overflow cho thấy sự thất vọng phổ biến nhất với các công cụ AI là đầu ra "gần đúng, nhưng không hoàn toàn". Báo cáo Tình trạng Mã năm 2026 của Sonar cho thấy 96% nhà phát triển không hoàn toàn tin tưởng mã do AI tạo ra, và 38% cho rằng việc xem xét nó tốn nhiều công sức hơn so với xem xét mã do con người viết. Điều này là do mã AI trông có vẻ ổn, nhưng bạn phải thực sự tìm hiểu sâu để thấy được những gì nó đang làm tốt. Mã tệ rõ ràng thì dễ từ chối hơn nhiều. Tôi cảm thấy khó chịu. Có lẽ bạn cũng vậy. Hãy cùng tìm hiểu và giải quyết vấn đề này. Một PR... gần như quá rẻ bây giờ Các tác nhân AI (AI agents) có thể tạo ra các nhánh (branches) từ các phiếu Jira, các bản vá (patches) từ các cuộc trò chuyện Slack, hoặc thậm chí là các PR hoàn chỉnh từ một báo cáo lỗi trước khi bất kỳ ai đồng ý rằng lỗi đó là có thật. Thành thật mà nói, đó là một thế giới khá tuyệt vời. Nhưng vấn đề là, các nhà phát triển không phải là những người duy nhất sử dụng các công cụ này. Các PM (Product Manager) sẽ tạo mẫu tính năng mà họ đã cố gắng giải thích trong ba sprint, chủ yếu bằng những cử chỉ mơ hồ, vô ích. Các nhà thiết kế sẽ điều chỉnh các luồng UX (User Experience) và sửa các bố cục liên tục bị giảm ưu tiên. Các nhà tiếp thị sẽ cập nhật các trang đích (landing pages) và biểu mẫu. (Liên tục.) Bộ phận hỗ trợ sẽ vá các điểm đau của khách hàng mà họ biết rõ nhất. Và tất cả những điều đó là một chiến thắng. Các bản sửa lỗi nhỏ không nên nằm trong danh sách tồn đọng (backlog hell) chờ đợi một kỹ sư tình cờ biết phần mã đó. Kiến thức sản phẩm nên được chuyển thành phần mềm hoạt động nhanh hơn. Nhưng việc mở một PR càng dễ dàng, các nhà phát triển càng có nghĩa vụ phải xem xét chúng. Và các PR không có giá trị chỉ vì chúng tồn tại. Chúng chỉ có giá trị khi chúng có thể được tin cậy. Và sự tin cậy vẫn thực sự đắt đỏ AI thực sự giỏi trong việc viết mã. Trong một cuộc thi hackathon gần đây, tôi đã nhờ GPT 5.5 tạo ra 10.000 dòng mã hoạt động trong khoảng 45 phút. Ứng dụng hoạt động khá tốt. Chắc chắn, giao diện người dùng (UI) là một cơn ác mộng, nhưng chức năng cốt lõi đã có. Nhưng viết mã và viết mã đáng tin cậy, có khả năng mở rộng là hai điều khác nhau. Một mô hình có thể tạo ra một bản diff, giải thích nó, và thậm chí chạy một số thử nghiệm theo kịch bản thành công (happy-path tests). Nhưng vẫn có người chịu trách nhiệm về những thứ thực sự quan trọng: Mã này có thực sự khắc phục vấn đề đã nêu không? Tác giả có thực sự hiểu hệ thống không, hay điều này đang tạo ra nợ kỹ thuật (tech debt) cho sau này? Bản diff có lớn hơn mức cần thiết không? (Gần như chắc chắn là có.) Bản sửa lỗi này có âm thầm phá vỡ một luồng khác trong mã, điều mà sẽ rõ ràng nếu một người dùng duy nhất chỉ cần thử nó không? Giao diện người dùng có thực sự hoạt động cho người dùng thực trong các trình duyệt thực không? Bản sửa lỗi này có tồn tại sau một bản demo không? Đây có thực sự là một giải pháp cho vấn đề gốc, hay chỉ là một miếng băng dán? Sự đánh đổi về bảo mật này có chấp nhận được không? Đây không phải là những câu hỏi về cú pháp. Đây là những câu hỏi về sự tin cậy. Và hiện tại, tất cả chúng đều đổ dồn vào bạn và tôi, những nhà phát triển. @richiemcilroy đã nói rất đúng trong một video được tweet lan truyền gần đây: Các số liệu thống kê cũng cho thấy điều tương tự. Các tiêu chuẩn năm 2026 của LinearB chỉ ra rằng các PR (Pull Request) do AI tạo ra phải chờ đánh giá lâu hơn 4,6 lần và bị từ chối nhiều hơn đáng kể so với các PR do con người viết. Nghiên cứu của METR về các nhà phát triển mã nguồn mở có kinh nghiệm cho thấy các công cụ AI đầu năm 2025 thực sự làm chậm các nhà phát triển đi 19%, một phần vì công việc thực tế bao gồm phong cách, kiểm thử, tài liệu và đánh giá – chứ không chỉ đơn thuần là gõ mã. Điều này không có nghĩa là AI vô dụng. Và các công cụ thực sự đang ngày càng tốt hơn mỗi ngày. Nhưng công việc thực sự của phần mềm chưa bao giờ chỉ là gõ mã vào các tệp. Đó là việc biết cái gì nên thay đổi, cái gì không nên, và khi nào một bản vá lỗi bề mặt về mặt kỹ thuật giải quyết được vấn đề nhưng thực chất sẽ gây rắc rối cho nhóm của bạn trong sáu tháng tới. Đó là nơi bạn cần tập trung sự chú ý của mình. Bạn nên cân nhắc những thứ cần sự tinh tế và ngữ cảnh, chứ không phải tự mình khám phá lại những điều cơ bản sau khi PR đã nằm trong hàng đợi của bạn. Cảm giác phát triển hiện tại không tốt Mặc dù các công cụ AI đang làm cho mọi người năng suất hơn, nhưng việc trở thành nút thắt cổ chai lại mang lại cảm giác tồi tệ. Những người khác có thể hoàn thành nhiều việc hơn bao giờ hết, bởi vì đột nhiên mã nguồn trở nên dễ tiếp cận với họ. Với tư cách là một nhà phát triển, bạn chỉ trải nghiệm sự cường điệu như một khoản nợ đánh giá đang đến. Bạn không xây dựng. Bạn đang đánh giá. Bạn không thiết kế hệ thống; bạn đang kiểm soát các cạnh của nó. Bạn không trực tiếp giải quyết vấn đề khó khăn; bạn đang đảo ngược kỹ thuật những gì một tác nhân hoặc đồng đội đang cố gắng làm, sau đó đặt cược cả buổi chiều của mình vào việc liệu sự khác biệt có an toàn để giữ lại hay không. AI được làm phần thú vị. Bạn được làm một robot. Điều đó không có nghĩa là bạn vô dụng. Nếu có, sự phán đoán của bạn bây giờ còn quan trọng hơn nhiều. Nhưng quy trình làm việc đang lãng phí sự phán đoán của bạn một cách khủng khiếp. Nó đang lấy nguồn tài nguyên khan hiếm nhất trong hệ thống – sự chú ý của kỹ sư giàu kinh nghiệm – và hướng nó vào những khác biệt bí ẩn, các bản vá lỗi cồng kềnh, thiếu ngữ cảnh và mã được tạo ra chỉ trông có vẻ đúng. Vì vậy, đúng vậy, nó nhàm chán. Đúng vậy, nó gây khó chịu. Khi ai đó nói "bây giờ mọi người đều có thể gửi mã", điều bạn và tôi nghe thấy là "bây giờ mọi người đều có thể tạo ra công việc cho chúng ta". Do đó, sự kiệt sức. Khóa kho lưu trữ giải quyết sai vấn đề Vậy, chúng ta phải làm gì? Phản ứng rõ ràng sẽ là khóa kho lưu trữ. Chỉ dành cho các nhà phát triển. Và tôi hiểu điều đó. Bạn là người bị gọi lúc 2 giờ sáng khi hệ thống sản xuất gặp sự cố. Bảo vệ mã không phải là sự độc quyền. Bạn chỉ có một ký ức. Nhưng việc hạn chế quyền truy cập giải quyết sai vấn đề. Các PR đa chức năng không tự động là xấu. Trên thực tế, theo nhiều cách, chúng chính xác là những gì chúng ta đã mong muốn trong nhiều năm: kiến thức sản phẩm biến thành các bản sửa lỗi nhỏ mà không cần chờ lịch trình của kỹ sư. Nhưng vấn đề là, mặc dù bây giờ mọi người đều có thể mở PR, nhưng việc tiếp nhận PR vẫn chưa phát triển. Các nhóm vẫn coi một PR như một sự chuyển giao từ nhà phát triển sang nhà phát triển: đây là sự khác biệt, đây là mô tả, hãy tiếp tục.