Lập trình viên cảm thấy nhanh hơn 20% nhờ AI, nhưng thực tế lại chậm đi 19%

Có một thử nghiệm ngẫu nhiên của METR năm 2025 cho kết quả gây sốc: những lập trình viên giàu kinh nghiệm dùng công cụ AI mất thêm 19% thời gian để hoàn thành công việc thực tế. Nhưng sau đó, chính họ lại ước lượng rằng AI đã giúp mình nhanh hơn khoảng 20%.

Khoảng cách giữa cảm giác và con số thật đó chính là chủ đề của bài viết này — và điều đáng lo không nằm ở bản thân con số.

2 giờ sáng và đoạn mã không ai hiểu

Hãy hình dung cảnh quen thuộc: 2 giờ sáng, hệ thống thanh toán sập. Kỹ sư trực ca mở service đang lỗi ra đọc và phát hiện thủ phạm là một hàm dài 400 dòng, được merge ba tuần trước với một emoji giơ ngón tay cái thay cho đánh giá code. Không ai trong nhóm viết nó. Một AI agent đã viết trong khoảng 90 giây, và lúc đó mọi người đều thấy điều đó "ngầu".

Bây giờ thì nó bớt ngầu đi rất nhiều.

Tác giả bài viết gốc không phải người chống AI — anh dùng AI mỗi ngày và ship nhiều hơn bao giờ hết. Nhưng theo anh, cần phải trung thực về cái giá của nó, vì "không ai đăng những chi phí đó lên LinkedIn".

Nhìn vào những con số

Một số thống kê đáng chú ý được kiểm chứng lại:

• CodeRabbit phân tích 470 pull request thực tế vào tháng 12 và phát hiện mã do AI đồng tác giả có nhiều hơn 75% lỗi logic và gấp tới 2,74 lần vấn đề bảo mật.
• Harness khảo sát 500 lãnh đạo kỹ thuật: 67% cho biết họ dành nhiều thời gian hơn để debug mã do AI viết.
• Dữ liệu bảng lương của Stanford cho thấy lập trình viên 22-25 tuổi đang ở mức thấp hơn gần 20% so với đỉnh cuối năm 2022.
• Khảo sát Developer Survey 2026 của Stack Overflow: phần lớn lập trình viên đã dùng AI ở nơi làm việc, gần một nửa chỉ tin tưởng kết quả khi có thể dễ dàng kiểm chứng, và chỉ 6,6% sẵn sàng giao cho AI một quyết định quan trọng.

Cộng lại, ta có nhiều mã hơn bao giờ hết, ít hiểu biết về nó hơn, và phần lớn thời gian "tiết kiệm" được lại âm thầm đổ vào việc dọn dẹp.

Tác giả cũng cảnh báo vài con số lan truyền nhưng không đáng tin: thống kê "63% lập trình viên mất nhiều thời gian hơn để debug mã AI" không truy được về nghiên cứu gốc nào, còn "Stack Overflow giảm 25%" là số liệu quá cũ — vào tháng 7/2026, site chỉ nhận khoảng 1.400 câu hỏi mới, so với hơn 200.000 câu hỏi trong tháng đỉnh điểm năm 2014.

Thay đổi công cụ không bằng viết brief tốt hơn

Điều thực sự cải thiện kết quả của tác giả lại khá nhàm chán: giao cho agent những việc nhỏ hơn.

Các mô hình đúng là tốt hơn rõ rệt vào cuối 2025, nhưng bước nhảy lớn nhất đến từ việc chia nhỏ công việc thành từng giai đoạn: lập kế hoạch trước, rồi kiến trúc, rồi xây dựng, rồi debug — mỗi bước là một nhiệm vụ riêng.

"Thêm rate limiting cho endpoint đăng nhập, 5 lần mỗi phút, trả về 429" là một ticket có thể hoàn thành. "Làm ứng dụng bảo mật hơn" là cách để mất cả tuần.

Agent cũng không khác gì — có điều chúng sẽ không quay lại hỏi ý bạn là gì. Chúng sẽ đoán.

Một điểm nữa cần chấp nhận: công cụ AI không mang tính tất định. Dán cùng một prompt sau mười phút có thể nhận câu trả lời khác. Việc bắt kịp công cụ từ chỗ "nice-to-have" đã trở thành một phần của công việc.

AI sẽ không nói cho bạn biết nền móng đang sai

Tác giả kể lại một kịch bản lặp đi lặp lại: ai đó nhờ AI dựng một ứng dụng web nhỏ, một giờ sau có bản nháp chạy được với cơ sở dữ liệu quan hệ bài bản — bảng chặt chẽ, khóa ngoại đầy đủ. Rồi ý tưởng thay đổi, dữ liệu hóa ra lộn xộn và liên tục đổi hình dạng, cái cần thực sự là một cột JSON linh hoạt.

AI không nhận ra. Nó không bao giờ dừng lại để nói "khoan đã, schema này không còn phù hợp nữa". Nó cứ xây tiếp trên nền cũ, mỗi tính năng mới lại phải nhét vừa thiết kế ban đầu, cho đến khi kéo bản mới nhất về giống như chơi Jenga trên tòa tháp của người khác.

Công cụ AI rất giỏi xây dựng trên bất cứ thứ gì đang có trước mặt. Chúng rất kém trong việc nói rằng thứ đang có trước mặt là sai. Vẫn phải có người chịu trách nhiệm điều đó.

Với codebase cũ thì còn khó hơn. Dự án mới rất dễ: mô tả điều bạn muốn và nhận 90% trong thời gian ngắn. Nhưng 10% cuối là lúc hệ thống bắt đầu già đi, và mọi codebase thực tế đều mang theo nhiều năm "cặn" — những lần refactor dở dang và những quyết định không ai còn nhớ ai đã đưa ra.

AI làm đội giỏi giỏi hơn, đội lộn xộn lộn xộn hơn

Báo cáo DORA 2025 của Google khảo sát gần 5.000 người trong ngành công nghệ và kết luận AI hoạt động như một bộ khuếch đại: nó không sửa được một đội ngũ, mà chỉ tăng âm lượng cho bất cứ thứ gì đội ngũ đó vốn đã là.

Nếu hệ thống của bạn lỏng lẻo và feedback loop nhanh, bạn thấy lợi ích thật. Nếu mọi thứ chằng chịt vào nhau và mỗi lần release mất hàng tuần, bạn gần như chẳng được gì.

Dữ liệu của GitClear phân tích 211 triệu dòng code thay đổi từ 2020 đến 2024: năm 2024 là năm đầu tiên số dòng sao chép vượt số dòng di chuyển (chỉ dấu của refactor). Nói cách khác: trùng lặp nhiều hơn, dọn dẹp ít đi.

Bạn có thể đã thấy điều này trong repo của mình: AI viết validateEmail thứ tư thay vì dùng một trong ba cái đã có. Cả bốn đều chạy được, đó chính là lý do không ai xóa chúng — cho đến ngày bạn cần đổi quy tắc và phải tìm đủ cả bốn.

Xây prototype thì tốt, nhưng đừng ship nó

Tác giả hoan nghênh việc PM và chuyên gia nghiệp vụ giờ có thể tự dựng bản thô cho ý tưởng của mình. Nhưng nguy cơ nằm ở thói quen cũ: prototype đầu tiên âm thầm trở thành hệ thống production.

Quy trình được khuyến nghị:

1. Coi bản prototype lộn xộn là cách để làm rõ câu chuyện, không phải thứ để ship.
2. Dùng AI chuyển những gì đã hiểu thành đặc tả (spec) bài bản.
3. Vứt prototype đi và xây lại từ đúng spec đó.
4. Chỉ định một người có kinh nghiệm chịu trách nhiệm chính thức cho quyết định "ship" cuối cùng.

Người đó hiện thường là chốt kiểm soát thật sự duy nhất giữa đầu ra của AI và production, nên đó phải là công việc được giao chính thức, không phải việc làm nếu có thời gian.

Lập trình viên junior không mất việc, họ mất môi trường học nghề

Đây là phần tác giả thấy khó viết nhất, vì anh nhớ mình từng là junior và học được rất nhiều từ những ticket nhỏ, nhàm chán.

• Nghiên cứu của Harvard trên 62 triệu lao động Mỹ: tại các công ty áp dụng AI, số nhân sự junior giảm khoảng 9% trong sáu quý, trong khi cấp senior gần như không đổi.
• Dữ liệu chính phủ Mỹ: việc làm "computer programmer" — chủ yếu viết code theo đặc tả của người khác — giảm 27,5%, mức thấp nhất từ năm 1980. Việc làm "software developer" gần như không thay đổi.

Các công ty không hết muốn tuyển kỹ sư mới. Họ chỉ mất đi công việc từng giao cho người mới — sửa lỗi nhỏ, làm màn hình đơn giản — chính là loại việc mà một agent hoàn thành trong vài giây.

Lời khuyên cho người mới bước vào nghề: tập trung vào hiểu hệ thống — các mảnh ghép khớp với nhau thế nào, vì sao một quyết định ở tuần đầu lại thành cơn đau đầu ở tháng thứ sáu. Cú pháp giờ rẻ rồi; biết được ứng dụng đó có nên tồn tại và nó sẽ làm hỏng những gì mới là nơi giá trị đã dịch chuyển.

Sáu loại thay đổi của AI, và loại thứ sáu đáng sợ nhất

Khi một agent đưa ra thay đổi, có ích khi phân loại trước khi đọc:

• Mã mới: file hoặc hàm mới, không động vào gì có sẵn. Thường ổn.
• Sửa logic hiện có.
• Xóa code, cấu hình hoặc dữ liệu.
• Viết lại lớn trải khắp nhiều file.
• Dọn dẹp như đổi tên và format. Vô hại, nhưng rất giỏi che giấu thay đổi quan trọng.
• Thay đổi hành vi âm thầm — loại đáng sợ nhất. API trả về hơi khác, frontend vỡ, và không có gì fail lúc build.

Nếu không giới hạn phạm vi agent được phép chạm vào, một nhiệm vụ có thể lang thang qua cả sáu loại. Và loại cuối thường được báo cáo bởi khách hàng, chứ không phải bởi test.

Về những pull request 2.000 dòng

Trái với trực giác, dữ liệu cho thấy các thay đổi lớn của AI không bị revert thường xuyên hơn của người. Điều đáng lo là chúng không fail ồn ào — chúng được duyệt, hoặc bỏ qua review hoàn toàn, vì không ai có thể review tử tế một diff cỡ đó vào 4 giờ chiều thứ Năm.

Nghiên cứu của Google trên 3,52 triệu thay đổi code phát hiện thay đổi của AI nhận gấp 1,92 lần số bình luận review mang tính chặn. Báo cáo 2026 của Faros trên 22.000 lập trình viên ghi nhận thời gian review trung vị tăng hơn 400% và 31% số PR được merge mà không hề qua review.

Hai nguyên tắc tác giả thực sự tuân thủ

Thứ nhất: giữ diff khoảng 50 dòng. Nếu trả về lớn hơn nhiều, không cố review nữa — vứt đi, siết lại brief và chạy lại, gần như luôn nhanh hơn là gỡ rối. Hãy biến con số này thành một cổng kiểm tra cứng trong CI: PR vượt giới hạn sẽ bị trả về kèm yêu cầu spec rõ ràng hơn.

Thứ hai: không để bí mật đến gần agent. Biến môi trường, API key, token, mật khẩu — tuyệt đối không đưa cho agent trừ khi đang quan sát. Dán một key vào prompt một lần, đến cuối phiên có thể thấy nó bị hardcode trong cả chục file.

Vài thói quen nhỏ khác:

• Yêu cầu agent viết test trước khi làm tính năng.
• Bật kiểm tra mã trùng lặp trong linter để cái validateEmail thứ tư bị gắn cờ.
• Đọc kế hoạch, không chỉ đọc diff — phần lớn code tồi bắt đầu từ một kế hoạch tồi.

Cái giá thật của "code rẻ"

Code rẻ thường trở nên đắt về sau. Tác giả gọi đó là "fast-fashion software": trông tuyệt khi ship, bắt đầu rã ra sau vài tháng.

Hệ quả vượt xa khỏi repo của chúng ta:

• Tailwind phổ biến hơn bao giờ hết, nhưng người sáng lập viết trên GitHub rằng lưu lượng truy cập tài liệu giảm khoảng 40% từ đầu 2023, và doanh thu giảm khoảng 80%. Ba trong bốn kỹ sư bị cho nghỉ việc.
• Stack Overflow — nơi nhiều người trong chúng ta học code — chỉ còn nhận được một phần nhỏ câu hỏi so với trước.
• IEA dự báo trung tâm dữ liệu sẽ tiêu thụ khoảng 945 TWh điện vào năm 2030, hơn gấp đôi hiện nay, với AI là động lực lớn nhất.
• Gartner dự đoán chi phí lập trình bằng AI sẽ vượt mức lương trung bình của lập trình viên vào năm 2028.

Giá mà chúng ta đang trả chưa bao giờ là giá thật. Tiền đầu tư mạo hiểm đã gánh phần lớn chi phí cho mỗi token chúng ta đốt, và điều đó đang dần kết thúc.

Điều này để lại chúng ta ở đâu?

Một dự đoán cho năm 2027: sẽ bắt đầu xuất hiện những ngôn ngữ lập trình chủ yếu thiết kế cho AI agent thay vì cho con người. Vercel Labs đã open-source Zero — một ngôn ngữ thử nghiệm cho coding agent, với compiler giao tiếp qua lệnh có cấu trúc, máy đọc được. Còn sơ khai, nhưng hướng đi đã rõ.

Và dù tất cả những điều trên, tác giả vẫn thấy việc xây dựng thú vị hơn nhiều năm qua: có thể bắt đầu một ý tưởng sáng thứ Bảy và có prototype chạy được ngay tối hôm đó.

Vậy AI đang giúp hay đang hại lập trình viên? Cả hai — và cái nào xảy ra phụ thuộc chủ yếu vào thói quen. Những người tư duy hệ thống, giữ thay đổi nhỏ và đặt con người ở chốt quyết định cuối đang làm rất tốt. Những đội ship bản nháp và duyệt diff không ai đọc đang âm thầm tích một hóa đơn mà họ chưa nhìn thấy.

Cách khắc phục chưa bao giờ là "dùng ít AI đi". Mà là đảm bảo rằng khi có thứ gì đó sập lúc 2 giờ sáng, ít nhất một người trong đội biết nó hoạt động thế nào.