GitHub vẫn là hạ tầng trung tâm của thế giới phát triển phần mềm. Business Insider mô tả GitHub là một nền tảng phát triển phần mềm hàng đầu, được Microsoft mua lại vào năm 2018 ^[14]. Vì vậy, làn sóng chỉ trích hiện nay không nên được hiểu vội là “GitHub đã hết thời”. Cách đọc thận trọng hơn: GitHub đang gặp vấn đề về niềm tin.

Điểm gây căng thẳng là Copilot không còn chỉ là tính năng gợi ý code trong trình soạn thảo. Khi Copilot xuất hiện trong kho mã — issue, pull request, review, bình luận và các lệnh kích hoạt agent — nhiều maintainer cảm thấy quyền đặt luật trong dự án của họ đang bị thu hẹp ^[7][8].

Có sự giận dữ thật, nhưng chưa có bằng chứng về “cuộc di cư”

Các nguồn hiện có ủng hộ kết luận rằng lập trình viên đang bức xúc mạnh hơn là kết luận rằng họ đang rời GitHub hàng loạt.

The Register viết rằng các tính năng AI “khó tránh” đã khiến một số lập trình viên xem xét lựa chọn nền tảng lưu trữ mã khác, nhất là khi maintainer muốn có cách chặn hoặc tắt hành vi của Copilot trong repo ^[8]. Slashdot, khi tóm lược tranh cãi này, cũng dẫn một nhận định rằng việc GitHub chuyển từ một công ty con riêng biệt vào nhóm CoreAI của Microsoft đã góp phần đẩy một số thành viên cộng đồng mã nguồn mở từ chỗ chỉ phàn nàn về Copilot sang chủ động rời xa GitHub ^[1].

Đó là tín hiệu cảnh báo thật. Nhưng nó chưa phải bằng chứng rằng vị thế của GitHub đã sụp đổ. Những nguồn được nêu không đưa ra tổng số dự án đã chuyển đi, số liệu khách hàng doanh nghiệp rời bỏ, hay dữ liệu cấp repo cho thấy GitHub mất nền tảng trên diện rộng. Kết luận hợp lý hơn là: nhiều developer đang đánh giá lại mức độ tin tưởng họ muốn đặt vào GitHub khi Microsoft đẩy AI sâu hơn vào nền tảng này ^[8][14].

Vì sao Copilot trở thành điểm bùng phát

Tranh cãi không chỉ xoay quanh câu hỏi “AI gợi ý code có hữu ích không?”. Vấn đề lớn hơn là Copilot được phép hành động ở đâu.

Theo The Register, thảo luận phổ biến nhất trên GitHub Community trong 12 tháng trước đó là yêu cầu có cách chặn Copilot tạo issue và pull request trong các kho mã ^[8]. Bài viết cũng cho biết thảo luận phổ biến thứ hai, tính theo lượt upvote, là một báo cáo lỗi yêu cầu xử lý việc người dùng không thể tắt Copilot code review ^[8].

Khác biệt này rất quan trọng. Một trợ lý AI gợi ý vài dòng code trong editor cá nhân là một chuyện. Một hệ thống AI xuất hiện trong hàng đợi issue, luồng pull request và phần review lại trở thành một phần của cơ chế quản trị dự án. Với maintainer, câu hỏi không chỉ là Copilot viết code tốt hay dở, mà là chủ dự án có còn được quyết định quy tắc vận hành cộng đồng của mình hay không ^[8].

Khi chất lượng bị nghi ngờ, tự động hóa “khó tránh” càng gây lo

Một phần bức xúc cũng đến từ cảm nhận rằng Copilot chưa đủ đáng tin. Một thảo luận trên GitHub Community ghi nhận cáo buộc từ người dùng rằng Copilot trong VS Code hoạt động thiếu ổn định và gây thiệt hại cho dự án ^[9]. Một thread như vậy không phải là phép đo độc lập về chất lượng Copilot trên mọi người dùng và mọi workflow. Nhưng nó giúp lý giải vì sao một số developer không còn xem hoạt động Copilot ngoài ý muốn là tự động hóa vô hại ^[9].

Khi một công cụ vừa khó né tránh, vừa bị một bộ phận người dùng xem là thiếu ổn định, cuộc tranh luận sẽ chuyển từ “năng suất” sang “sự đồng thuận”.

AI agent biến độ tin cậy thành vấn đề vận hành

Trang trạng thái của chính GitHub cho thấy vì sao workflow kiểu agent làm rủi ro tăng lên. Ngày 22/4/2026, từ 18:49 đến 19:32 UTC, các phiên Copilot Cloud Agent dành cho Agent HQ Codex agent không khởi động được từ những điểm vào như gán issue và nhắc @copilot trong bình luận ^[7]. GitHub cho biết 0,5% tổng số Copilot Cloud Agent job bị ảnh hưởng — khoảng 2.000 job thất bại — trong khi Copilot và các phiên agent khác không bị ảnh hưởng ^[7].

Đó không phải sự cố làm sập toàn bộ GitHub. Nhưng nó cho thấy rủi ro vận hành khi đội kỹ thuật bắt đầu giao việc thật cho AI agent. Nếu issue được gán cho agent hoặc công việc được kích hoạt qua bình luận trong pull request, độ sẵn sàng của Copilot sẽ trở thành một phần của kế hoạch giao hàng phần mềm ^[7]. Trang tin của GitHub cũng thừa nhận các sự cố khả dụng gần đây và nói rằng outage ảnh hưởng đến khách hàng ^[10].

Chiến lược AI của Microsoft làm bài toán niềm tin nhạy cảm hơn

Business Insider đưa tin Microsoft đang tái sắp xếp các đội ngũ để củng cố GitHub và đại tu nền tảng này cho AI coding và agent, trong bối cảnh GitHub đối mặt với các đối thủ AI coding như Cursor và Claude Code ^[14]. Nhìn từ góc độ sản phẩm, hướng đi này dễ hiểu: repo, pull request, issue và review là những nơi tự nhiên để nhúng trợ lý lập trình.

Nhưng về văn hóa kỹ thuật, đây là vùng nhạy cảm. Nhiều lập trình viên coi GitHub như hạ tầng chung của phần mềm. Khi các tính năng Copilot có vẻ khó tránh, maintainer có thể không còn nhìn chúng như công cụ tăng năng suất tùy chọn, mà như cách Microsoft tận dụng vị thế trung tâm của GitHub để phân phối chiến lược AI của mình ^[8][14].

AI Credits biến ranh giới kỹ thuật thành câu chuyện ngân sách

GitHub nói Copilot đang chuyển sang mô hình tính phí theo mức sử dụng và từ ngày 1/6, việc dùng Copilot sẽ tiêu thụ GitHub AI Credits ^[10]. Điều này không chứng minh mọi đội sẽ phải trả nhiều tiền hơn. Nhưng nó có nghĩa là các tổ chức cần hiểu Copilot có thể chạy ở đâu, ai có thể kích hoạt, và mức dùng AI được quy đổi vào ngân sách như thế nào ^[10].

Với những đội đã khó chịu vì Copilot xuất hiện trong không gian repo dùng chung, tính phí theo mức dùng có thể khiến hướng đi của GitHub trông bớt giống một trợ lý tùy chọn và giống một lớp AI có thể phát sinh chi phí được dệt vào workflow phát triển phần mềm ^[8][10].

Không phải câu chuyện “chống nền tảng” nào cũng là rời GitHub

Một số câu chuyện rộng hơn về việc giảm phụ thuộc vào nền tảng tập trung dễ bị gộp vào làn sóng phản ứng với GitHub, dù chúng không trực tiếp nói về GitHub. Hồ sơ HEY của David Heinemeier Hansson giới thiệu ông là đồng sở hữu kiêm CTO của 37signals và là người tạo ra Ruby on Rails ^[26]. Các bài viết gần đây của ông bàn về việc 37signals rời cloud, gồm việc nhận 20 máy chủ Dell R7625 và kế hoạch thoát khỏi sự phức tạp của cloud ^[17][22].

Những bài viết đó nói về hạ tầng cloud, không phải bằng chứng được ghi nhận rằng 37signals hay DHH rời GitHub. Phân biệt điều này là cần thiết: tâm lý hoài nghi với các nền tảng phần mềm tập trung có thể đang tăng, nhưng đó không đồng nghĩa với bằng chứng rằng developer đang bỏ GitHub hàng loạt ^[17][22].

Các đội kỹ thuật nên làm gì lúc này

Phản ứng hợp lý không phải là hoảng loạn, mà là làm rõ các giả định về GitHub và Copilot.

• Kiểm tra mọi điểm Copilot có thể xuất hiện. Rà soát issue, pull request, code review, bình luận, gán issue và các workflow dùng @copilot ^[7][8].
• Đặt chính sách ở cấp repo. Xác định tính năng Copilot nào được phép dùng, tính năng nào bị hạn chế hoặc cấm, nhất là với dự án mã nguồn mở và repo có yêu cầu tuân thủ cao ^[8].
• Xem lại AI Credits trước ngày 1/6. Việc dùng Copilot sẽ tiêu thụ GitHub AI Credits, nên đội kỹ thuật, đội nền tảng và bộ phận tài chính cần hiểu cách tính mức sử dụng ^[10].
• Lập kế hoạch cho sự cố AI agent. Nếu tiến độ phụ thuộc vào gán issue, bình luận pull request hoặc phiên agent, hãy xem độ sẵn sàng của Copilot như một phụ thuộc vận hành ^[7].
• Giữ đường lui không dùng agent. Các repo quan trọng vẫn cần người chịu trách nhiệm rõ ràng, quy trình release được ghi chép và phương án khôi phục khi tự động hóa thất bại.

Kết luận

Nhận định rằng lập trình viên đang bỏ GitHub hàng loạt chưa được các bằng chứng ở đây ủng hộ. Kết luận chắc hơn là GitHub đang đối mặt với khủng hoảng niềm tin: Copilot đi sâu vào workflow phát triển dùng chung, Microsoft được cho là đang tổ chức lại GitHub quanh AI coding và agent, sự cố độ tin cậy trở nên nghiêm trọng hơn khi agent làm việc thật, và mô hình tính phí AI theo mức sử dụng đang đến ^{[7][8][10][14]}.

GitHub vẫn rất quan trọng. Câu hỏi mở là lập trình viên sẽ đòi lại bao nhiêu quyền kiểm soát khi nền tảng này ngày càng trở thành một nền tảng AI mạnh tay hơn.