Công cụ lập trình AI đang thúc đẩy sự thống trị của hệ sinh thái JavaScript như thế nào

Vào tháng 8 năm 2025, TypeScript đã trở thành ngôn ngữ được sử dụng nhiều nhất trên GitHub. Đây là sự thay đổi lớn nhất trong bảng xếp hạng ngôn ngữ của GitHub trong mười năm qua và nó diễn ra trong giai đoạn các tác nhân AI lập trình (coding AI agents) được áp dụng với tốc độ nhanh nhất.

Trước đây, các tác nhân AI lập trình từng được dự đoán sẽ làm giảm tầm quan trọng của việc lựa chọn ngôn ngữ. Người ta cho rằng các tổ chức sẽ trở nên linh hoạt với mọi nền tảng (stack agnostic) và chỉ chọn các công nghệ dựa trên nhu cầu của bài toán kinh doanh, thay vì cân nhắc đến nguồn nhân lực lập trình viên sẵn có. Thay vào đó, chỉ hai năm sau khi các công cụ lập trình AI được phổ biến rộng rãi, thị trường dường như trở nên hạn hẹp hơn, với sự thu hẹp nhanh chóng của các ngôn ngữ lập trình khả dụng, và phần lớn sự tập trung đều đổ dồn vào một hệ ngôn ngữ duy nhất.

Phân tích về sự thay đổi

Báo cáo Octoverse tháng 10 năm 2025 của GitHub đã thống kê số lượng người đóng góp cho TypeScript. Với 2,64 triệu người đóng góp hàng tháng, con số này đánh dấu mức tăng 66% so với cùng kỳ năm ngoái. Trong năm 2025, TypeScript đã chứng kiến hơn một triệu lập trình viên viết những dòng mã TypeScript đầu tiên của họ trên GitHub.

Sự tăng trưởng này cộng hưởng với vị thế vốn đã rất thống trị trước đó. Năm 2025, Stack Overflow đã thực hiện một cuộc khảo sát lập trình viên với hơn 49.000 phản hồi. Trong số đó, 66% tự nhận là đang sử dụng JavaScript. Trong gần như mọi năm kể từ 2011, JavaScript luôn giữ vững vị trí thống trị này. Tóm lại, hệ ngôn ngữ JavaScript vừa là ngôn ngữ được sử dụng nhiều nhất, vừa là ngôn ngữ phát triển nhanh nhất trên GitHub.

Cần phải đề cập ngắn gọn một vấn đề với phương pháp đếm của GitHub; việc đếm hoạt động trên GitHub chính là đếm hoạt động trên trang web của họ, điều này tạo ra xung đột lợi ích vì họ có thể muốn số liệu trông đẹp hơn. Ngoài ra, các xu hướng thời thượng cũng ảnh hưởng đến loại thông tin được đưa vào các kho lưu trữ công khai. Tuy nhiên, các chỉ số vẫn khớp với dữ liệu khảo sát, điều này là hợp lý khi xét đến phạm vi của xu hướng cụ thể này.

Các mô hình viết tốt nhất bằng mã nguồn mà chúng đã thấy nhiều nhất

Cách thức hoạt động khá đơn giản. Các mô hình học từ mã nguồn được công khai, và phần lớn mã nguồn được công khai đều được viết bằng JavaScript và TypeScript. Trên thực tế, phần lớn mã nguồn đều xoay quanh React.

Điều này tạo ra một khoảng cách đáng kể trong kết quả đầu ra mà các lập trình viên có thể thấy trong các tác nhân của họ chỉ trong vòng một ngày sau khi thay đổi nền tảng công nghệ. Hãy yêu cầu một tác nhân lập trình tạo ra một React component có định kiểu (typed), kết quả thường sẽ biên dịch được, tuân thủ các tiêu chuẩn của cơ sở mã và chỉ cần chỉnh sửa tối thiểu. Ngược lại, khi bạn yêu cầu cùng tác nhân đó tạo mã cho Svelte, Solid hoặc một framework backend ít phổ biến hơn, kết quả thường sẽ sơ sài hơn nhiều. Ngoài ra, bạn sẽ thấy nhiều API tự chế hơn và phần khung (scaffolding) sẽ cần sửa chữa nhiều hơn trước khi có thể thực thi.

Kết quả là, điều này đang làm thay đổi cách các đội ngũ lựa chọn nền tảng công nghệ của họ. Nó không còn đơn thuần là quyết định framework nào hiệu quả nhất hay dễ làm việc nhất, mà là framework nào tương thích tốt nhất với các công cụ của đội ngũ, bởi vì khoảng cách về năng suất trong kết quả đầu ra của tác nhân trong một chu kỳ xây dựng kéo dài là rất lớn. Khi đội ngũ đó tạo ra sản phẩm, nó được xuất bản, thu thập (scraped) và đưa vào các đợt huấn luyện tiếp theo, từ đó làm nới rộng khoảng cách năng suất.

Không có điều nào trong số này đưa ra một phán quyết về mặt kỹ thuật. Solid và Svelte là những framework tốt, và một vài framework hiện đại hơn còn vượt trội hơn React về tốc độ thuần túy. Thị trường đã tưởng thưởng cho lựa chọn mà các mô hình đã biết trước.

Các mô hình được xây dựng bằng Python, nhưng sản phẩm lại được vận chuyển bằng JavaScript

Một lập luận phản bác hợp lý cho các điểm trên là việc phát triển AI diễn ra bằng Python. Việc huấn luyện mô hình, đánh giá và hầu hết các công cụ nghiên cứu đều chạy bằng Python, và điều đó vẫn chưa thay đổi.

Tuy nhiên, rất ít những gì khách hàng tương tác lại được viết bằng Python. Trên thực tế, giao diện người dùng (front end) của một sản phẩm AI về cơ bản là một cửa sổ truyền phát các token. Nó cũng yêu cầu các nút bấm để thực thi công cụ, một bước phê duyệt cho bất kỳ điều gì có thể dẫn đến kết quả tiêu cực, và phần giải thích về những gì hệ thống đã làm và tại sao. Tất cả những điều này đều được thực hiện bằng JavaScript và TypeScript, bất kể mô hình đó có nguồn gốc từ OpenAI, Anthropic hay là một mô hình mở (open-weight) mà công ty tự lưu trữ trên phần cứng của riêng họ.

Đến cuối năm 2025, GitHub đã báo cáo hơn 1,1 triệu kho lưu trữ công khai sử dụng LLM SDK, tăng 178% so với năm trước. Sự gia tăng này chủ yếu là do phát triển ứng dụng, thay vì phát triển mô hình. Mọi dự án thí điểm của doanh nghiệp vượt qua giai đoạn demo đều yêu cầu ai đó xây dựng thành phần hướng tới người dùng, và các công cụ tiêu chuẩn công nghiệp cho công việc đó chính là các framework JavaScript.

Hệ thống kiểu (type systems) đã trở thành rào chắn cho mã nguồn được tạo ra

Quan điểm từ GitHub cho rằng sự thay đổi này có nghĩa là các lập trình viên đang chuyển sang các ngôn ngữ có kiểu (typed languages) vì hệ thống kiểu giúp việc phát triển với sự hỗ trợ của tác nhân trở nên an toàn hơn. Mã nguồn được tạo ra có một loại lỗi đặc thù. Nó đọc và có cấu trúc tốt. Nó thậm chí chạy hoàn hảo trong các ngôn ngữ động, chỉ để bị treo do không khớp kiểu dữ liệu (shape mismatches) sau vài lần gọi hàm. Các trình kiểm tra kiểu (type checkers) sẽ xác định phần lớn lỗi này trước khi mã nguồn kịp chạy.

Lý thuyết này đã được chứng minh là đúng trong thực tế. Năm 2026, việc sử dụng TypeScript bởi các lập trình viên chuyên nghiệp đã đạt 78%, tăng từ 69% hai năm trước đó. Khoảng 40% lập trình viên viết hoàn toàn bằng TypeScript, và chỉ 6% lập trình viên viết hoàn toàn bằng JavaScript thuần.

Các loại lỗi mà trình biên dịch tìm thấy thường là những loại lỗi mà người đánh giá là con người sẽ bỏ qua khi phải đối mặt với 400 dòng mã hợp lý.

● Một hàm được gọi với một đối tượng bị thiếu một trong các trường bắt buộc.

● Mã nguồn chứa giả định rằng một giá trị tồn tại, và điều này dẫn đến việc một giá trị null hoặc undefined được truyền đi.

● Hình thái của một phản hồi API đã thay đổi, và trình xử lý được tạo ra vẫn sử dụng cái cũ.

Nút thắt cổ chai đã chuyển từ viết mã sang xác minh mã

Báo cáo thực địa từ OpenAI liên quan đến việc sử dụng các tác nhân lập trình trong tính toán khoa học từ tháng 7 năm 2026 đã nêu rõ hạn chế này: xác minh đã trở thành yếu tố giới hạn, thay vì tạo mã. Mặc dù đây là một nhà cung cấp đang tự đánh giá sản phẩm của chính mình và cần được xem xét thận trọng, nhưng kết quả này trùng khớp với những gì nhiều đội ngũ kỹ thuật, đặc biệt là những đội ngũ bên ngoài lĩnh vực nghiên cứu, đã ghi nhận trong năm qua.

Khi một giao diện người dùng có năng lực được hoàn thành trong một buổi chiều thay vì ba tuần, phần chậm nhất của quy trình trở thành việc xác định xem mọi thứ xuất hiện trên màn hình có chính xác, an toàn và dễ bảo trì hay không. Điều này thay đổi những gì được mong đợi từ một lập trình viên JavaScript. Tốc độ gõ mã chưa bao giờ là giá trị thực sự của công việc, nhưng nó từng được dùng làm thước đo thô về năng lực trong quá trình tuyển dụng. Mã nguồn được tạo ra đã lấy đi thước đo đó và để lại sự phán đoán.

Người ta kỳ vọng rằng một React effect sẽ kích hoạt hai lần trong quá trình phát triển, và một lập trình viên không biết điều này có thể dành cả ngày để điều tra cái mà họ nghĩ là lỗi do gọi API trùng lặp. Một truy vấn được tạo ra sẽ có vẻ ổn trong môi trường phát triển với dữ liệu mẫu, nhưng nó có thể quét toàn bộ bảng khi được sử dụng trong môi trường sản xuất. Một bước kiểm tra xác thực (auth check) có thể được đặt ở bất kỳ đâu trong một component và không hiệu quả, điều này có thể tạo ra ảo giác về bảo mật, nhưng ảo giác đó sẽ biến mất khi ai đó thực sự kiểm tra nó.

Có một sự lệch pha mà các đội ngũ thường bỏ qua. Khả năng tạo mã là gần như vô hạn và tăng lên theo mỗi tác nhân bổ sung hoặc một gói đăng ký mới. Ngược lại, khả năng đánh giá bị giới hạn bởi số lượng kỹ sư am hiểu hệ thống để xác định một lỗi hợp lý. Con số đó khó có thể tăng với cùng tốc độ. Việc thêm nhiều khả năng tạo mã vào một đội ngũ đã đạt giới hạn về khả năng đánh giá sẽ không làm tăng tốc độ phân phối. Nó chỉ đơn giản là chuyển nút thắt cổ chai từ viết sang đánh giá. Một đội ngũ có thể tăng gấp đôi khả năng tạo mã trong một tuần, nhưng điều đó sẽ không thay đổi số lượng người sẵn sàng để đánh giá. Đây là lý do tại sao ràng buộc đã thay đổi và tại sao các công cụ bổ sung không cung cấp giải pháp.

Điều tương tự không đúng với các phương thức tuyển dụng. Hầu hết các khâu sàng lọc vẫn đánh giá liệu ứng viên có thể đưa ra một giải pháp hoạt động được hay không, đây là phần mà các công cụ đã hỗ trợ. Một số công ty đã bắt đầu đánh giá kỹ năng ngược lại. Họ đưa cho ứng viên các khối mã do AI tạo ra có chứa lỗi và quan sát xem lỗi đó tồn tại bao lâu mà không được giải quyết.

Các công ty tuyển dụng cũng đã đi theo hướng đó. Ví dụ, Full Scale hiện mô tả các kỹ sư JavaScript mà họ giới thiệu là những người thông thạo các công cụ AI và có tư duy sản phẩm, thay vì số dòng mã đã viết. Một công ty đặt mục tiêu thuê một lập trình viên JavaScript chuyên trách hiện đang thu nhận khả năng đánh giá nhiều như khả năng xây dựng. Điều đó có vẻ là một sự thay đổi nhỏ cho đến khi một luồng đăng nhập do AI tạo ra đi vào sản xuất mà không có sự can thiệp của con người.

Sự tập trung này đi kèm với một cái giá

Một thị trường coi trọng những gì các mô hình đã biết khiến việc giới thiệu bất cứ điều gì mới trở nên khó khăn. Một framework mới được xuất bản trong năm nay không có kho dữ liệu huấn luyện tồn tại từ trước, khiến các tác nhân khó làm việc với nó, dẫn đến việc các đội ngũ tránh sử dụng, dẫn đến kịch bản không có kho dữ liệu nào được tạo ra. Thời gian để gọi vốn điển hình là không đủ để các giải pháp dựa trên giá trị thực sự phá vỡ chu kỳ này. Các framework đạt được cột mốc quan trọng trước năm 2023 hiện có một lợi thế không liên quan gì đến chất lượng thiết kế.

Rủi ro hẹp hơn đối với một công ty đơn lẻ. Một doanh nghiệp có sản phẩm, công cụ và quy trình tuyển dụng đều xoay quanh một hệ ngôn ngữ duy nhất đã đặt cùng một canh bạc ba lần. Điều đó thật thoải mái khi hệ ngôn ngữ đó duy trì sự thống trị, và sẽ rất tốn kém nếu nó suy yếu.

Dự đoán đầu tiên đã đúng một nửa. AI thực sự đã loại bỏ phần lớn chi phí viết mã bằng một ngôn ngữ mà không ai trong đội ngũ hiểu. Chi phí để hiểu và làm chủ vẫn tồn tại, và đối với hầu hết các đội ngũ, đây là chi phí chính quyết định nền tảng công nghệ.