GitHub Octoverse 2026: agent đã mở đầu hơn 40% pull request, nút thắt mới nằm ở khâu soát xét

GitHub vừa công bố báo cáo Octoverse 2026, bản tổng kết một năm hoạt động trên nền tảng này. Trong 12 tháng tính đến ngày 30 tháng 9 năm 2026, lập trình viên đã đẩy mã lên GitHub 17,9 tỷ lần. Con số này lớn hơn tổng số lần đẩy mã của cả năm 2024 và năm 2025 cộng lại.

Những con số chính trong báo cáo

Tất cả các con số dưới đây đều là số liệu của chính GitHub, đo trên cả kho công khai và kho riêng tư. Báo cáo ghi nhận 34,3 tỷ commit, tức các lần lưu thay đổi mã, và 45,4 tỷ lượt chạy GitHub Actions, hệ thống chạy tự động các tác vụ như kiểm thử và triển khai. Số pull request đã hợp nhất, tức yêu cầu hợp nhất mã được chấp nhận, đạt 1,3 tỷ, trung bình 3,5 triệu mỗi ngày.

So với hai năm trước, mức tăng rất lớn. Số lần đẩy mã tăng từ 5,2 tỷ năm 2024 lên 6,7 tỷ năm 2025 rồi 17,9 tỷ năm nay. Số commit tăng từ 10 tỷ lên 12,9 tỷ rồi 34,3 tỷ. Số lượt chạy Actions tăng từ 8 tỷ lên 14 tỷ rồi 45,4 tỷ.

Điểm đáng chú ý nhất nằm ở vai trò của agent, tức chương trình trí tuệ nhân tạo tự thực hiện công việc thay cho người dùng. Trong tháng 9 năm 2026, hơn 40% pull request được bắt đầu bằng agent, trong khi tháng 3 con số này mới là 17%. Trong số các kho mới tạo trong năm, kho có tập tin cấu hình agent đạt trung bình gấp 8 lần số commit so với kho mới không có tập tin này. Cùng tháng 9, 61% người dùng GitHub Copilot đã dùng hơn một mô hình.

Tháng 6 là điểm gãy của cả năm

Hoạt động trên GitHub tăng đều từ tháng 1, rồi tăng vọt quanh tháng 6. GitHub cho rằng thời điểm này trùng với một loạt thay đổi cùng lúc. Mô hình nền tốt hơn, công cụ hỗ trợ agent hoàn thiện hơn, và agent chuyển từ làm việc theo từng phiên riêng lẻ sang làm việc bền bỉ qua nhiều ngày. Agent mới còn tự điều phối thêm các agent chuyên biệt khác.

Từ tháng 6 trở đi, khoảng 55% commit đến từ các kho hoàn toàn mới. Nhưng làn sóng này không chỉ đến từ người mới. Những người đã đẩy mã trong 12 tháng qua có thâm niên trung bình 36 tháng trên GitHub. Hơn 75% người mở pull request trong tháng 8 lại đẩy mã tiếp trong tháng 9. Nói cách khác, người cũ ở lại và làm nhiều hơn, chứ không phải chỉ có người mới tràn vào.

Đóng góp cho mã nguồn mở công khai cũng tăng gấp đôi, từ 1,12 tỷ năm ngoái lên 2,5 tỷ năm nay. GitHub nêu vài ví dụ: một lập trình viên tại Nepal xây bảng tin lũ lụt trên GitHub Pages, sau đó phát triển thành dịch vụ chuyển tiếp cảnh báo thiên tai bằng tiếng Nepal. Một nhóm tại phòng thí nghiệm sức đẩy phản lực của NASA viết phần mềm chạy trên tàu vũ trụ.

Từ viết mã sang soát xét: nút thắt đã đổi chỗ

Đây là phần phân tích riêng của bài viết, không phải kết luận của GitHub. Khi agent mở đầu hơn 40% pull request, công việc nặng nhọc nhất của một đội không còn là viết mã nữa. Nó chuyển sang soát xét, tức đọc, kiểm tra và quyết định có hợp nhất mã do agent tạo ra hay không.

Một pull request do agent tạo ra có thể dài, đúng cú pháp, và vẫn sai về ý đồ. Người soát xét phải trả lời ba câu hỏi: thay đổi này có đúng việc cần làm không, có phá vỡ hành vi cũ không, và có đáng để bảo trì về lâu dài không. Nếu đội vẫn soát xét theo cách cũ, tức đọc từng dòng theo thứ tự và chờ một người duy nhất duyệt, thì hàng đợi sẽ dài ra đúng theo tốc độ agent tạo mã.

Con số gấp 8 lần commit ở các kho có cấu hình agent cũng cần đọc thận trọng. Đây là mức trung bình so sánh giữa hai nhóm kho, không phải bằng chứng rằng chỉ riêng agent đã gây ra toàn bộ mức chênh lệch. Những đội chủ động cấu hình agent ngay từ đầu vốn đã có thể là những đội làm việc tích cực hơn. Điều chắc chắn rút ra được là: đội nào đưa agent vào quy trình từ ngày đầu sẽ vận hành ở một nhịp khác, và nhịp đó đòi hỏi khâu soát xét phải theo kịp.

AI đến mọi ngành, nhưng agent thì chưa

Năm nay, lần đầu tiên GitHub phân loại kho công khai theo ngành, dùng hệ thống phân loại ngành của Bắc Mỹ. Một mô hình ngôn ngữ đã đọc mẫu kho tạo từ năm 2022 đến năm 2026 và gán mỗi kho vào ngành mà nó phục vụ, dựa trên tên, mô tả, chủ đề và tập tin giới thiệu.

Kết quả cho thấy một khoảng lệch thú vị. Trong các ngành hành chính và hỗ trợ, khai khoáng, y tế và nông nghiệp, hơn 40% kho nhắc đến AI, nhưng chưa tới 3% có pull request do agent mở. Ngành xây dựng đi ngược xu hướng này: khoảng một phần tư số kho nhắc đến AI, nhưng khoảng 9% có pull request do agent mở, cao nhất trong các ngành, tiếp theo là sản xuất.

Xét theo mức tăng từ năm 2022, khai khoáng tăng khoảng 65 lần từ một điểm xuất phát rất thấp. Hành chính và xây dựng tăng 17 đến 18 lần. Sản xuất, ngành tăng chậm nhất trong nhóm này, vẫn tăng gần gấp ba. Dịch vụ chuyên môn, khoa học và kỹ thuật vươn từ vị trí thứ tư lên thứ hai, tăng khoảng 5 lần. Tổng số kho phục vụ các ngành tăng từ 9 triệu năm 2022 lên 25 triệu năm nay.

Khoảng lệch này gợi ý một điều thực tế: nhắc đến AI trong mô tả dự án thì dễ, còn giao cho agent mở pull request thật thì khó hơn nhiều. Những ngành có tỷ lệ agent thấp không hẳn là chậm chân. Họ có thể đang làm việc trong môi trường mà một pull request sai gây hậu quả lớn, như y tế hay khai khoáng, nên họ cần kiểm soát chặt hơn trước khi giao việc cho agent.

Cộng đồng 225 triệu người và dự báo phân tán

GitHub hiện phục vụ hơn 225 triệu lập trình viên. Hai cộng đồng lớn nhất vẫn là Mỹ với 38,3 triệu người và Ấn Độ với 32 triệu người, mỗi nước tăng hơn 10 triệu người trong năm nay. Brazil tăng thêm 3,28 triệu người, đứng thứ ba về số người mới.

Năm ngoái, GitHub dự báo Ấn Độ sẽ đạt 57,5 triệu lập trình viên vào năm 2030 và Mỹ đạt 54,7 triệu. Mới đi được một năm trong lộ trình kéo dài 5 năm, mọi quốc gia trong dự báo đều đã đi được ít nhất một phần năm quãng đường. Mỹ đã đi được 38,6%, Ấn Độ đi được 28,3%.

Khi chạy 43 mô hình dự báo đến năm 2031, GitHub thu được một khoảng kết quả rất rộng. Khoảng một nửa số mô hình dự báo mức tăng cực mạnh, hơn gấp ba vào năm 2031. Gần một nửa dự báo mức tăng đáng kể, từ gấp đôi đến gần gấp ba. Chỉ ba mô hình dự báo mức tăng khiêm tốn, dưới gấp đôi. Khoảng dự báo rộng như vậy tự nó đã là một thông điệp: đà tăng năm 2026 đã làm cho mọi kịch bản cũ đều trở nên thiếu chắc chắn.

Đội nên làm gì trong tuần này

Từ những con số trên, một đội đang dùng agent viết mã có thể bắt đầu bằng bốn việc nhỏ, không cần thay đổi toàn bộ quy trình.

Thứ nhất, giữ pull request nhỏ. Một thay đổi lớn do agent tạo ra rất khó soát xét, còn một thay đổi nhỏ thì người soát xét đọc nhanh và quyết định dứt khoát hơn.

Thứ hai, đặt cổng kiểm tra tự động trước khi con người đọc mã. Kiểm thử, kiểm tra định dạng và quét lỗ hổng nên chạy xong trước khi pull request đến tay người soát xét, để người đọc chỉ tập trung vào ý đồ thay đổi. Bài so sánh 6 công cụ chạy coding agent trên blog này cũng bàn cách chọn công cụ sao cho CI không đổ vỡ: https://www.manhquy.id.vn/vi/blog/so-sanh-6-cong-cu-chay-coding-agent-chon-the-nao-de-ci-khong-do-vo

Thứ ba, phân loại mức độ soát xét theo rủi ro. Thay đổi chạm đến thanh toán, dữ liệu người dùng hay bảo mật cần người có kinh nghiệm duyệt kỹ. Thay đổi tài liệu hay văn bản hiển thị có thể duyệt nhanh hơn.

Thứ tư, đo thời gian chờ soát xét, không chỉ đo tốc độ tạo mã. Nếu agent tạo pull request nhanh gấp đôi mà thời gian chờ duyệt cũng tăng gấp đôi, thì đội chưa nhanh hơn. Đội chỉ nhanh hơn khi mã đến tay người dùng sớm hơn.

Việc 61% người dùng Copilot dùng hơn một mô hình trong tháng 9 cho thấy một thói quen đang hình thành. Thói quen đó là chọn mô hình theo từng việc: có việc cần suy luận sâu, có việc cần tốc độ, có việc cần chi phí thấp.

Nguồn tham khảo

• GitHub Blog, "Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents", https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/