AI Tạo Gần Một Nửa Đầu Việc Trong Linear, Nhưng Chỉ 32,7% Pull Request Có AI Được Merge
Trang dữ liệu công khai của Linear cho thấy tính đến tháng 8/2026, tác tử AI và MCP tạo khoảng 2,435 triệu đầu việc mỗi tuần — gần ngang 2,481 triệu của người dùng và tích hợp. Hai năm trước, con số này là dưới một phần nghìn. Nhưng báo cáo benchmark 2026 của LinearB, đo trên 8,1 triệu pull request,
Hai con số cùng nói về tác tử lập trình, và chúng kéo về hai hướng ngược nhau. Một bên: AI đã tạo gần một nửa số đầu việc trên Linear. Bên kia: chỉ khoảng một phần ba pull request có AI hỗ trợ đi được tới nhánh chính. Đọc riêng từng con số sẽ ra hai kết luận trái ngược — đọc cùng nhau thì mới thấy nút thắt thật nằm ở đâu.
Con số của Linear: gần một nửa
Linear — công cụ quản lý đầu việc được nhiều đội phát triển phần mềm dùng — công khai một trang dữ liệu về cách AI đang được dùng trong chính nền tảng của họ. Tính đến tháng 8/2026, tác tử AI và các máy khách MCP tạo ra khoảng 2,435 triệu đầu việc mỗi tuần, so với 2,481 triệu đến từ người dùng và các tích hợp truyền thống. Chênh lệch chưa tới 2%.
Điều đáng chú ý không phải con số hiện tại mà là tốc độ. Linear cho biết hai năm trước, chưa tới một đầu việc trên một nghìn là do AI tạo. Đây là mức tăng ba bậc độ lớn trong khoảng thời gian ngắn hơn một vòng đời sản phẩm thông thường.
Về sản lượng, dữ liệu Linear cho thấy tổng số pull request tăng 111% trong hai năm. Nhưng mức tăng đó phân bổ rất lệch: đội có dùng tác tử lập trình đi từ 21 lên 65 pull request mỗi tuần, trong khi đội không dùng chỉ nhích từ 8 lên 10.
Đây là dữ liệu một nền tảng tự công bố về chính người dùng của mình, không phải khảo sát toàn ngành. Mẫu gồm 127.000 người dùng trả phí cho phần đo tỷ lệ áp dụng, và 47.900 workspace trả phí tính đến tháng 6/2026 cho phần đo pull request. Người dùng Linear nghiêng về nhóm công ty công nghệ tiếp nhận công cụ mới sớm, nên nên đọc đây là chỉ dấu xu hướng, không phải mặt bằng chung của ngành phần mềm.
Nhưng vào được nhánh chính lại là chuyện khác
Một bộ dữ liệu độc lập kể phần còn lại của câu chuyện. Báo cáo Engineering Benchmarks 2026 của LinearB phân tích 8,1 triệu pull request từ khoảng 4.800 đội tại 42 quốc gia, và đưa ra một chỉ số mới: tỷ lệ pull request được merge trong vòng 30 ngày.
Kết quả: pull request không dùng AI đạt 84,5%, còn pull request có AI hỗ trợ chỉ đạt 32,7% — chưa tới một nửa. Trong khi đó, 88,3% lập trình viên trong mẫu nói họ dùng AI thường xuyên, tăng từ khoảng 72% hồi đầu năm 2024.
Linear và LinearB là hai công ty khác nhau. Tên gần giống nhau và cùng nói về pull request nên rất dễ nhầm, nhưng đây là hai tổ chức độc lập với hai bộ dữ liệu riêng: Linear là công cụ quản lý công việc, LinearB là nền tảng đo lường quy trình kỹ thuật. Bài này đặt hai bộ số cạnh nhau chính vì chúng độc lập với nhau.
Vì sao tỷ lệ merge tụt xuống
LinearB đưa ra bốn cách lý giải, và cả bốn đều nói về khâu review chứ không phải khâu sinh mã:
- Kích thước. Ở bách phân vị 75, pull request có AI hỗ trợ vượt 400 dòng mã, so với 157 dòng của mã người tự viết. Pull request do tác tử tạo nằm ở giữa, khoảng 290 dòng. Khối thay đổi càng lớn thì gánh nặng nhận thức đặt lên người review càng nặng.
- Quyền sở hữu mờ. Pull request do tác tử sinh ra thường không có người chịu trách nhiệm rõ ràng, khiến người review ít động lực đặt nó lên đầu hàng đợi.
- Thiếu tin cậy. Lập trình viên nói họ dè dặt khi review mã AI vì lo có lỗi hoặc thiếu ngữ cảnh, và vì không đoán được sẽ phải bỏ ra bao nhiêu công sức.
- Vượt phạm vi. AI có xu hướng sửa nhiều hơn những gì được yêu cầu, làm pull request phình ra ngoài chủ đề ban đầu.
Hệ quả hiện rõ ở thời gian chờ. Theo LinearB, pull request do AI sinh ra phải đợi trung bình hơn 16 giờ mới có người nhận review, trong khi pull request không dùng AI chỉ đợi khoảng 200 phút. Nghịch lý là một khi đã bắt đầu review, chu kỳ review của nhóm có AI lại nhanh hơn đôi chút — khoảng 194 phút so với 252 phút. Vấn đề nằm ở chỗ bắt đầu, không phải ở chỗ làm.
Hai nguồn độc lập khác cho kết quả cùng hướng. CodeRabbit phân tích 470 pull request mã nguồn mở và thấy pull request có AI đồng tác giả chứa khoảng 1,7 lần số vấn đề so với pull request thuần người viết. Một nghiên cứu quy mô lớn trình bày tại hội nghị MSR 2026 khảo sát 33.000 pull request do năm tác tử lập trình tạo trên GitHub, và thấy tác tử làm tốt nhất ở các việc tài liệu, CI và cập nhật build, còn kém nhất ở tối ưu hiệu năng và sửa lỗi. Hai nguyên nhân bị từ chối hàng đầu: mô tả nhiệm vụ mơ hồ và thiếu ngữ cảnh.
Hai bộ số không mâu thuẫn — chúng đo hai khâu khác nhau
Cần nói rõ để tránh kết luận sai: Linear đo số đầu việc và pull request được tạo ra, LinearB đo tỷ lệ pull request đi tới đích. Đó là hai khâu khác nhau trong cùng một quy trình, trên hai tập tổ chức khác nhau, với cách định nghĩa "có AI hỗ trợ" và "do tác tử tạo" không hoàn toàn trùng khớp. Không bên nào bác bỏ bên nào.
Nhưng ghép lại thì bức tranh khá rõ: đầu vào tăng theo cấp số nhân, còn tỷ lệ đi qua được cửa review thì giảm. Nút thắt của kỹ thuật phần mềm đã dịch chuyển. Suốt nhiều năm, viết mã là công đoạn đắt nhất. Giờ nó rẻ đi rất nhanh, và công đoạn đắt nhất trở thành việc đọc, hiểu và chịu trách nhiệm cho mã mà một hệ thống khác vừa viết ra.
Một chi tiết trong dữ liệu LinearB đáng để dừng lại: ở bách phân vị 75, tỷ lệ refactoring trong pull request không dùng AI vào khoảng 37%, còn ở pull request có AI hỗ trợ thì gần bằng không. Nói cách khác, AI có xu hướng thêm mã mới thay vì dọn dẹp mã cũ. Với một cơ sở mã phải sống nhiều năm, đó là khoản nợ kỹ thuật tích lại lặng lẽ.
Đội kỹ thuật Việt Nam nên làm gì
- Đo tỷ lệ merge, đừng đo số dòng mã. Nếu chỉ số theo dõi là sản lượng pull request, tác tử sẽ làm chỉ số đó đẹp lên ngay mà không nói gì về phần mềm thực sự giao được. Tỷ lệ merge trong 30 ngày là thước đo trung thực hơn nhiều.
- Đặt trần kích thước pull request. Đây là biện pháp rẻ nhất tác động thẳng vào nguyên nhân số một. Yêu cầu tác tử chia nhỏ công việc thành nhiều pull request dưới 200 dòng thay vì một khối 400 dòng.
- Gán người chịu trách nhiệm cho mọi pull request của tác tử. "Của AI" không phải một chủ sở hữu. Phải có tên một người chịu trách nhiệm giải trình cho thay đổi đó, nếu không nó sẽ nằm mãi trong hàng đợi.
- Giao cho tác tử đúng loại việc. Dữ liệu MSR 2026 khá rõ: tài liệu, CI, cập nhật build là nơi tác tử thắng. Tối ưu hiệu năng và sửa lỗi phức tạp thì chưa.
- Viết mô tả nhiệm vụ cho tử tế. Mô tả mơ hồ là nguyên nhân từ chối hàng đầu. Thời gian bỏ ra để viết rõ yêu cầu và ngữ cảnh rẻ hơn nhiều so với thời gian review một pull request đi sai hướng.
- Tính năng lực review vào kế hoạch. Tăng gấp ba sản lượng pull request mà giữ nguyên số người review là công thức tạo ra hàng đợi, không phải tạo ra tốc độ.
Nguồn:
- Linear — AI usage patterns in software teams — nguồn sơ cấp cho số đầu việc, mức tăng 111% và so sánh 21/65 với 8/10
- LinearB — 8 million pull requests reveal where engineering productivity breaks down — nguồn sơ cấp cho tỷ lệ merge, kích thước pull request và thời gian chờ review
- LinearB / Dev Interrupted — Why AI-assisted PRs merge at half the rate of human code — bốn cách lý giải và định nghĩa cửa sổ 30 ngày
- CodeRabbit — State of AI vs Human Code Generation Report — mức 1,7 lần số vấn đề trên 470 pull request
- MSR 2026 — Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub — khảo sát 33.000 pull request của tác tử
Ảnh: Đồ hoạ do Locaith dựng từ số liệu công bố của Linear và LinearB — không phải hình ảnh của hai công ty này. Số liệu Linear là dữ liệu nền tảng tự công bố về người dùng của chính mình, chưa có kiểm định độc lập. Ngày phát hành chính xác của báo cáo LinearB được ghi khác nhau giữa các trang của chính LinearB, nên bài viết chỉ dẫn là "báo cáo 2026" thay vì gán một mốc ngày cụ thể. Linear và LinearB là hai công ty độc lập, không liên quan sở hữu. Tổng hợp và phân tích bởi Ban Biên Tập Locaith, ngày 21/8/2026.