Khi code trở nên rẻ, phán đoán trở thành điểm nghẽn

Có một cảnh đang lặp lại ở nhiều đội phần mềm.

Số pull request tăng. Những task trước đây mất vài ngày giờ có thể có bản chạy được sau một buổi. Một người bước sang module mình chưa từng chạm, nhờ AI đọc code, đề xuất cách sửa, viết test rồi mở pull request. Nhìn ở đầu đường ống, mọi thứ đều nhanh lên.

Nhưng ở cuối đường ống, release không nhanh lên tương ứng. Pull request nằm chờ lâu hơn. Người review phải giữ nhiều thay đổi cùng lúc trong đầu. Một lỗi vượt qua test rồi chỉ lộ ra khi gặp dữ liệu, quyền truy cập hoặc thứ tự sự kiện ngoài production.

Không có nghịch lý nào ở đây cả. Chỉ có một cái bơm mới được gắn vào đầu một đường ống cũ.

AI đã làm tăng tốc một công đoạn thật. Sai lầm bắt đầu khi ta lấy tốc độ của công đoạn đó làm tốc độ của cả hệ thống, rồi suy tiếp rằng những người từng đứng ở các công đoạn khác đã trở nên thừa.

Một con số đẹp có thể đứng cạnh một hàng đợi xấu

Báo cáo AI Engineering 2026 của Faros AI (PDF) tổng hợp hai năm telemetry từ 22.000 developer thuộc hơn 4.000 team. Ở nhóm có mức áp dụng AI cao, số epic hoàn thành trên mỗi developer tăng 66,2%, số task tăng 33,7% và số pull request được merge tăng 16,2%.

Đó là mức tăng thật trong dữ liệu quan sát. Cùng báo cáo ấy lại ghi nhận thời gian trung vị nằm trong review tăng 441,5% - tức gấp khoảng 5,4 lần mức cơ sở ở nhóm áp dụng AI thấp. Số bug trên mỗi developer tăng 54%, còn tỷ lệ incident trên mỗi pull request tăng 242,7% - tức cao gấp khoảng 3,4 lần mức cơ sở.

Một bộ dữ liệu khác của DX lấy mẫu ngẫu nhiên từ một tập gồm hơn 400 công ty trong giai đoạn tháng 11/2024 đến tháng 2/2026 (PDF). Mẫu chỉ gồm những công ty nơi mức áp dụng AI tăng mạnh, có tỷ lệ sử dụng trung bình 75% và ít nhất 100 kỹ sư. Trong nhóm đó, mức sử dụng AI tăng trung bình 65%, còn thông lượng pull request trung vị tăng 7,76%. Mức tăng trung bình là 13,1%, cao hơn trung vị vì một số ít công ty đứng đầu kéo con số lên. DX cho rằng viết code chỉ chiếm khoảng 16% ngày làm việc của developer; phần còn lại nằm ở planning, alignment, review, validation và những lần bàn giao giữa người với người.

Hai nguồn này đều do nhà cung cấp công cụ đo lường công bố. Dữ liệu của họ là quan sát, không phải thử nghiệm đối chứng, nên không đủ để kết luận AI là nguyên nhân duy nhất của các bug hay hàng đợi review. Đội dùng AI nhiều có thể đã khác đội còn lại từ trước. Cách đo giữa hai báo cáo cũng không giống nhau.

Riêng thiết kế mẫu của DX không cho ta thấy những công ty nơi mức áp dụng AI không tăng mạnh, kể cả khả năng thử rồi không mở rộng hoặc quay lui. Vì thế, 7,76% là trung vị của nhóm đã đạt mức áp dụng cao theo tiêu chí nghiên cứu, không phải trung vị của thị trường.

Nhưng chúng cho ta một tín hiệu cấu trúc khó bỏ qua: năng lực tạo thay đổi có thể tăng nhanh hơn năng lực hấp thụ thay đổi.

DORA 2025 (PDF) mô tả AI như một bộ khuếch đại của hệ thống mà nó được đặt vào. Đội có feedback loop tốt và tiêu chuẩn chất lượng rõ sẽ khuếch đại những thứ đó. Đội đang nghẽn ở review hoặc sống nhờ tri thức truyền miệng cũng sẽ khuếch đại đúng điểm yếu ấy.

Cái bơm không tạo ra vết nứt trên đường ống. Nó làm vết nứt cũ chịu áp lực lớn hơn.

Artifact không phải là năng lực

Trước AI, ranh giới nghề nghiệp thường được nhìn qua sản phẩm đầu ra. BA viết tài liệu yêu cầu. Developer viết code. QA viết test case. Kiến trúc sư viết bản thiết kế. PM giữ backlog và roadmap.

Khi AI có thể sinh tất cả những artifact đó, một kết luận nghe rất hợp lý xuất hiện: nếu một người tạo được mọi đầu ra, người đó có thể thay mọi vai trò.

Kết luận ấy lẫn hai thứ khác nhau.

Artifact là thứ còn lại sau công việc: một file đặc tả, một đoạn code, một test suite, một sơ đồ. Năng lực là thứ làm cho artifact có giá trị: hiểu vì sao hệ thống đang như hiện tại, nhận ra mục tiêu nào đang xung đột, biết bằng chứng nào đủ để chốt và đứng tên cho hậu quả của quyết định đó.

AI hạ rất mạnh chi phí biên của artifact. Nó chưa hạ chi phí của ngữ cảnh và phán đoán theo cùng tỷ lệ.

Một model có thể viết hai phương án migration database. Nó không tự có hàm giá trị để biết downtime, khả năng rollback hay tính toàn vẹn dữ liệu đang được tổ chức đặt cao hơn. Việc chọn hàm nào vẫn là một quyết định nằm ngoài model.

Nó cũng có thể viết test từ cùng bản đặc tả đã dùng để sinh code. Nhưng khi code và test cùng đi ra từ một mô hình về bài toán, cả hai có thể bỏ sót cùng một điều. Thêm nhiều test không tự động tạo ra một góc nhìn độc lập.

Đây là chỗ cần nhớ: độc lập không phải thuộc tính của artifact. Độc lập là thuộc tính của vòng phản hồi đã tạo và kiểm tra artifact đó.

Khi đúng chức năng vẫn chưa đủ đúng

Benchmark SusVibes (PDF) lấy 200 yêu cầu tính năng từ 108 dự án Python mã nguồn mở, bao phủ 77 lớp điểm yếu bảo mật. Trong chín kết hợp được thử, SWE-Agent với Claude 4 Sonnet đứng đầu về tỷ lệ vượt kiểm tra chức năng với 61%, nhưng chỉ 10,5% lời giải vượt cả kiểm tra chức năng lẫn bảo mật. Cấu hình có tỷ lệ vượt cả hai cao nhất cũng chỉ đạt 12,5%. Riêng trong cấu hình 61% ấy, 82,8% lời giải đúng chức năng vẫn không an toàn.

Các tỷ lệ này không phải ước lượng tỷ lệ code do AI ngoài thực tế không an toàn. Bộ benchmark cố ý chọn những tác vụ từng dẫn tới lỗi bảo mật, nên nó là một kính hiển vi chẩn đoán, không phải bản đồ phân bố công việc hằng ngày.

Thứ nó chứng minh hẹp hơn, nhưng đắt hơn: một hệ thống có thể tối ưu rất nhanh cho tín hiệu “chạy đúng” trong khi năng lực phán đoán về “an toàn trong bối cảnh này” vẫn ở rất xa phía sau.

Vì thế, khi AI viết code tốt hơn, công việc kiểm chứng không biến mất. Nó đổi độ cao. Ta bớt soi dấu chấm phẩy và phải soi nhiều hơn vào giả định, quyền truy cập, mô hình dữ liệu, đường rollback và những trạng thái mà bản đặc tả không kể tới.

Chuyên môn hóa không biến mất, nó đổi đơn vị

Nếu chuyên môn hóa được định nghĩa là “mỗi chức danh sản xuất một loại tài liệu”, AI đang làm định nghĩa ấy lỗi thời rất nhanh. Một developer hoàn toàn có thể dùng AI để phác thảo acceptance criteria. Một BA có thể dựng prototype. Một QA có thể đọc code và tạo bản vá nhỏ. Biên giữa các thao tác đang mờ đi, và đó là điều tốt.

Nhưng từ đó không suy ra rằng mọi năng lực có thể được dồn vào cùng một vòng lặp.

Thứ cần được tách không nhất thiết là con người. Thứ cần được tách là quyền tạo ra một phán đoán và quyền tuyên bố phán đoán ấy đã đủ tốt.

Với một công cụ nội bộ nhỏ, sai thì sửa trong một buổi, cùng một người có thể giữ nhiều năng lực. Độc lập có thể đến từ branch protection, một người khác review hoặc một bộ test được thiết kế trước khi implementation bắt đầu. Giữ đủ chức danh trong trường hợp này chỉ tạo thêm điểm bàn giao.

Với hệ thống thanh toán, dữ liệu cá nhân hoặc một quyết định khó đảo ngược, cùng cấu trúc ấy không còn đủ. Người viết code không nên là điểm kiểm soát cuối cùng cho chính thay đổi của mình. Ở đây, chuyên gia bảo mật, QA, kiến trúc sư hay người sở hữu nghiệp vụ tồn tại vì vòng phản hồi cần một vị trí có ngữ cảnh, tiêu chuẩn và trách nhiệm khác.

Faros ghi nhận tỷ lệ pull request được merge mà không qua bất kỳ review nào - bởi người hay agent - tăng 31,3% khi các team chuyển từ mức áp dụng AI thấp lên cao. Cùng lúc, 25% pull request trong bộ dữ liệu được agent review, tăng từ 0 trong bộ dữ liệu trước. Hai con số không chứng minh review bằng agent là vô giá trị. Chúng cho thấy điểm kiểm soát đang được tái cấu trúc ngay khi đầu ra tăng, và một phần thay đổi thậm chí không đi qua điểm kiểm soát nào.

Vậy câu hỏi “có còn cần BA, QA hay kiến trúc sư không” thường là câu hỏi đặt sai đơn vị. Câu hỏi hữu ích hơn là: phán đoán nào trong hệ thống này cần một góc nhìn độc lập, ai đang giữ ngữ cảnh để đưa ra nó, và điều gì xảy ra nếu họ sai?

Sau đó mới tới chuyện năng lực ấy cần một người chuyên trách, một chuyên gia dùng chung cho nhiều đội hay một guardrail nằm ngay trong quy trình.

Cái giá dài hạn của việc bỏ qua ma sát

Năm 1985, Peter Naur viết trong Programming as Theory Building (PDF) rằng sản phẩm cốt lõi của lập trình không chỉ là chương trình và tài liệu. Đó là một “theory” trong đầu những người xây hệ thống: hiểu hệ thống ánh xạ vào thế giới thật thế nào và vì sao một quyết định được chọn.

AI có thể làm code xuất hiện mà không buộc người vận hành nó phải xây đầy đủ theory ấy.

Margaret-Anne Storey gọi hệ quả này là cognitive debt và intent debt (PDF). Technical debt nằm trong code và làm hệ thống khó thay đổi. Cognitive debt nằm trong sự hiểu biết chung đang xói mòn, làm hệ thống khó hiểu. Intent debt nằm trong những mục tiêu và lý do chưa được ghi lại, làm người lẫn máy không biết hệ thống tồn tại để làm gì.

AI có thể giảm loại nợ thứ nhất trong khi tăng hai loại sau. Nó refactor code và viết tài liệu trông sạch hơn. Nếu không ai kiểm chứng rationale, sự gọn gàng ấy chỉ che một khoảng trống nhận thức bằng một bề mặt đẹp.

Một thử nghiệm ngẫu nhiên có đối chứng với 52 developer học một thư viện Python mới (PDF) do Judy Hanwen Shen và Alex Tamkin thực hiện được công bố đầu năm 2026. Nghiên cứu của Shen nằm trong Anthropic Fellows Program, còn Tamkin thuộc Anthropic. Nhóm dùng AI làm bài nhanh hơn một chút, nhưng khác biệt thời gian không đạt ý nghĩa thống kê. Trong bài quiz ngay sau đó, điểm trung bình của họ thấp hơn nhóm tự viết code khoảng 17%, tương đương chênh 4,15 điểm trên thang 27; khoảng cách lớn nhất nằm ở câu hỏi debugging.

Nghiên cứu này nhỏ, chỉ đo một thư viện và hiểu biết tức thời. Nó không chứng minh người dùng AI sẽ mất kỹ năng dài hạn. Nhưng nó đặt ra một cơ chế đáng lo: code chạy ngay có thể lấy đi chính ma sát từng buộc ta phải hiểu hệ thống. Nếu đội chỉ thưởng cho tốc độ merge, người mới sẽ học rất nhanh cách làm cho artifact xuất hiện và rất chậm cách bác bỏ artifact khi nó sai.

Đến lúc đó, vấn đề không còn là AI có thay junior hay không. Vấn đề là senior của vài năm tới sẽ được hình thành bằng con đường nào.

Một phép thử nhỏ cho đường ống của bạn

Lấy 20 pull request có AI hỗ trợ gần nhất của đội. Với mỗi pull request, ghi lại bốn thứ: thời gian tạo thay đổi, thời gian nằm chờ review, số lần phải mở lại hoặc sửa sau merge, và ai có thể giải thích vì sao giải pháp này được chọn thay vì phương án gần nhất.

Ba chỉ dấu đầu thường lấy được từ tracker. Chỉ dấu cuối không nằm sẵn trong telemetry: bạn phải hỏi người đề xuất, review hoặc vận hành thay đổi, và đó có thể là phần tốn thời gian nhất của phép thử.

Đừng dùng kết quả để kết luận AI đang tốt hay xấu. Hai mươi pull request quá ít, và hàng đợi dài có thể đến từ thiếu người, release dồn cục hoặc thay đổi quy trình không liên quan. Một pull request không có link tới rationale cũng chưa chứng minh không ai hiểu nó; lý do có thể đang nằm trong một cuộc trao đổi mà bạn chưa thấy.

Phép thử chỉ trả lời một câu hẹp: tốc độ đang tăng ở đoạn nào, và áp lực đang dồn sang đoạn nào.

Nếu thời gian tạo giảm nhưng thời gian review tăng, đừng yêu cầu mọi người prompt nhanh hơn. Nếu thay đổi được merge đều nhưng không ai giải thích được lựa chọn thiết kế, đừng thêm một con số throughput vào dashboard. Nếu một người đang vừa đề xuất, vừa sinh code, vừa sinh test và vừa tự xác nhận giá trị, đừng hỏi AI còn làm được thêm vai trò nào nữa.

Hãy tìm chỗ đường ống đang chịu áp lực.

AI không xóa chuyên môn hóa. Nó làm lộ ra phần nào của chuyên môn hóa trước đây chỉ là lao động tạo artifact, và phần nào thật sự là quyền sở hữu ngữ cảnh, phán đoán độc lập cùng trách nhiệm giải trình.

Code đang trở nên rẻ hơn. Chính vì vậy, khả năng biết code nào không nên được viết, thay đổi nào chưa nên được merge và bằng chứng nào chưa đủ để tin sẽ trở nên đắt hơn.