Cập nhật: tháng 8/2026.
Suốt hai mươi năm, câu hỏi “nên chọn ngôn ngữ nào” luôn được trả lời từ góc nhìn của người gõ phím: ngôn ngữ nào viết nhanh, đọc dễ, tuyển người dễ, thư viện nhiều. Từ đầu 2026, câu hỏi đó bị đổi nền móng. Khi phần lớn số dòng mã trong một dự án không còn do người gõ ra nữa, tiêu chí “viết cho sướng tay” mất phần lớn trọng số. Cái thay chỗ nó là một tiêu chí lạ hơn nhiều: ngôn ngữ đó cho phép máy tự chứng minh mã đúng tới đâu, nhanh cỡ nào, và rẻ bao nhiêu.
Đây không phải một cuộc thi “ngôn ngữ nào hay hơn”. Đây là chuyện nút cổ chai của ngành phần mềm vừa dịch chuyển sang một chỗ khác, và mọi thứ xung quanh — trình biên dịch, công cụ, thậm chí cả cách đo độ phổ biến của ngôn ngữ — đang được sắp lại theo chỗ mới đó.
Nút cổ chai đã dời: sinh mã rẻ đi, tin mã thì không
Chi phí tạo ra một đoạn mã hợp lý về mặt hình thức đã rơi xuống gần bằng chi phí điện. Chi phí để biết chắc đoạn mã đó làm đúng việc thì gần như không giảm — vì nó vẫn phụ thuộc vào thời gian đọc của một kỹ sư có đủ ngữ cảnh, thứ đắt nhất và khó nhân bản nhất trong ngành.
Hệ quả rất trực tiếp. Trước đây, một ngôn ngữ “dễ dãi” là ngôn ngữ hiệu quả: bạn viết ít ký tự hơn, chạy thử nhanh hơn, và bạn — người viết — vẫn giữ trong đầu mô hình về những gì đoạn mã đó giả định. Bây giờ đoạn mã do máy sinh ra, và máy không bàn giao lại mô hình trong đầu nó. Cái duy nhất được bàn giao là văn bản. Nếu ngôn ngữ không ép các giả định ấy hiện ra thành thứ kiểm được, chúng biến mất — và tái xuất hiện ba tuần sau dưới dạng một sự cố lúc 2 giờ sáng.
Nói cách khác: thứ khan hiếm không còn là mã. Thứ khan hiếm là niềm tin có căn cứ rằng mã đó đúng. Và ngôn ngữ nào biến niềm tin đó thành một lệnh chạy được trong vài giây thì đang thắng.
Vì sao một trình biên dịch khó tính bỗng thành lợi thế
Agent viết mã hoạt động theo vòng lặp: đề xuất — chạy kiểm — đọc lỗi — sửa — lặp lại. Chất lượng đầu ra của vòng lặp này phụ thuộc gần như hoàn toàn vào chất lượng của cái mà giới nghiên cứu gọi là oracle: nguồn phán xử tự động cho biết “sai”, và tốt hơn nữa là “sai ở đâu, vì sao”.
Ba đặc tính quyết định một oracle tốt:
- Bắt sớm. Lỗi lộ lúc biên dịch rẻ hơn lỗi lộ lúc chạy hàng chục lần, và rẻ hơn lỗi lộ ở production hàng nghìn lần.
- Chẩn đoán có cấu trúc. Một thông báo nêu rõ tệp, dòng, cột, mã lỗi và gợi ý sửa là thứ agent tiêu hoá được ngay. Một dòng Segmentation fault hay một TypeError ở tận đáy stack thì gần như vô dụng — agent chỉ còn cách đoán.
- Thu hẹp không gian chương trình hợp lệ. Đây là điểm ít ai nói tới nhưng quan trọng nhất. Kiểu dữ liệu nghiêm, khớp mẫu vét cạn, lỗi phải xử lý tường minh, quy tắc sở hữu — mỗi ràng buộc loại bỏ trước cả một họ chương trình sai. Mô hình sinh ra văn bản theo xác suất; ràng buộc càng chặt thì phần “trông hợp lý mà sai” càng bị cắt bớt trước khi ai kịp chạy nó.
Đó là lý do trong năm 2026, giới nghiên cứu bắt đầu coi trình biên dịch và language server không phải công cụ cho người, mà là nguồn tín hiệu giám sát cho máy: đã có các hướng huấn luyện dùng thẳng phản hồi của compiler và language server làm phần thưởng, và cả một hội thảo NeurIPS 2026 dành riêng cho chủ đề sinh mã có thể kiểm chứng, nơi agent làm việc cùng bộ chứng minh định lý, model checker và bộ giải SMT. Cái mà trước đây là “trải nghiệm lập trình viên” nay là giao diện máy–máy.
Nhưng bảng xếp hạng lại nói ngược
Nếu lập luận trên đúng, ta phải thấy các ngôn ngữ kiểu tĩnh vọt lên. Thực tế 2026 phức tạp hơn: Python vẫn thắng đậm nhất. Chỉ số TIOBE giữa 2026 cho Python thị phần quanh mức 20% — mức mà nhiều năm nay không ngôn ngữ nào chạm tới — với cú nhảy nhiều điểm phần trăm chỉ trong một năm. RedMonk, vốn đo bằng cách khác, tháng 1/2026 vẫn xếp JavaScript nhất, Python nhì, Java ba, và top 20 gần như bất động.
Hai lực đang kéo ngược nhau, và cả hai đều thật:
- Lực kéo Python lên là hạ tầng AI. Mọi thứ liên quan tới mô hình — huấn luyện, phục vụ, đánh giá, dựng agent — đều có đường ngắn nhất đi qua Python. Thêm nữa, mô hình sinh mã giỏi nhất ở những ngôn ngữ có nhiều dữ liệu công khai nhất, mà Python và JavaScript đứng đầu danh sách đó. Đây là một vòng lặp tự củng cố.
- Lực kéo về phía kiểu tĩnh là nhu cầu kiểm chứng vừa nói. Nó không thể hiện thành thứ hạng ngôn ngữ, mà thể hiện thành chế độ mà người ta chạy ngôn ngữ đó: TypeScript ở chế độ strict thay cho JavaScript trần, Python có chú thích kiểu đầy đủ và một bộ kiểm kiểu bắt buộc trong CI thay cho Python “chạy được là xong”.
Cũng nên nói thẳng một điều mà chính RedMonk đã cảnh báo: các thước đo cũ đang hỏng dần. Số câu hỏi trên Stack Overflow không còn phản ánh mức độ dùng khi lập trình viên hỏi thẳng mô hình; số pull request trên GitHub biến động lạ khi tốc độ sinh mã tăng nhưng cách gom thay đổi lại khác trước. Nghĩa là: mọi con số xếp hạng ngôn ngữ giai đoạn này nên đọc như chỉ dấu xu thế, không phải phép đo chính xác.
Cách ngành hoà giải: gắn giáp kiểm chứng lên ngôn ngữ động
Điều thú vị nhất của 2026 không phải Python thua hay Rust thắng, mà là ngành đã chọn con đường thứ ba: giữ ngôn ngữ động, nhưng bọc quanh nó một lớp kiểm chứng nhanh tới mức nằm lọt trong vòng lặp của agent. Vài mốc cụ thể:
- TypeScript 7 ra bản chính thức giữa 2026 với trình biên dịch được viết lại từ đầu bằng Go (dự án mang mã hiệu “Corsa”), nhanh hơn bản cũ khoảng một bậc độ lớn ở các phép kiểm kiểu toàn dự án. Đây không phải chuyện tiện nghi: khi kiểm kiểu cả monorepo mất mười phút, agent không thể dùng nó làm oracle sau mỗi lần sửa; khi nó mất vài chục giây thì có thể. Cần nói thêm cho công bằng — bản 7.0 đầu tiên chưa có API lập trình ổn định, nên một loạt công cụ ăn theo (typescript-eslint, các bộ kiểm mẫu của Vue, Svelte, Astro) chưa chạy được ngay, và việc chuyển đổi phải làm dần.
- Python có bộ kiểm kiểu thế hệ mới viết bằng Rust: ty của Astral và pyrefly của Meta, cả hai đều nhắm tới độ trễ đủ nhỏ để chạy liên tục chứ không phải chạy mỗi đêm. Cộng với uv và ruff, chuỗi công cụ Python năm 2026 gần như đã thay xong phần lõi bằng Rust — và tháng 3/2026, OpenAI mua lại Astral, một tín hiệu khá rõ rằng hạ tầng công cụ Python được coi là tài sản chiến lược của thời agent chứ không phải tiện ích phụ.
- Bản thân Python cũng đổi phần chạy: từ 3.14, bản không GIL chuyển từ thử nghiệm sang được hỗ trợ chính thức, kèm một JIT còn ở dạng thử nghiệm. Chi phí đơn luồng của bản free-threaded đã giảm mạnh so với thế hệ trước, dù các thư viện C chưa khai báo tương thích vẫn khiến GIL bật lại — nên đây là quá trình chuyển tiếp nhiều năm, không phải một cú lật công tắc.
Điểm chung của cả ba: tốc độ công cụ kiểm giờ đã là một tính năng của ngôn ngữ, ngang hàng với cú pháp. Một bộ kiểm kiểu đúng nhưng chậm thì trong thế giới agent gần như không tồn tại, vì nó không kịp nằm trong vòng lặp.
Thang kiểm chứng, và ta đang đứng ở bậc nào
Đặt mọi thứ lên một thang sẽ thấy rõ hơn. Mỗi bậc bắt thêm một lớp lỗi và đắt thêm một chút — về công sức viết đặc tả lẫn thời gian máy chạy.
Bậc cao nhất — sinh mã kèm chứng minh hình thức, tạm gọi là vericoding để phân biệt với vibe coding — là nơi nghiên cứu 2026 sôi động nhất. Ý tưởng: người viết đặc tả, máy sinh cả phần cài đặt lẫn phần chứng minh, rồi một bộ kiểm chứng độc lập xác nhận chương trình thoả đặc tả. Đã có bộ benchmark cho Dafny, cho Verus (Rust) và cho Lean; đã có các quy trình khép kín trong đó mô hình lặp lại việc sửa cài đặt cho dễ chứng minh hơn. Kết quả đủ tốt để thú vị, và có trường hợp còn phát hiện lỗi trong mã do người viết.
Nhưng phải trung thực về ranh giới: bậc này vẫn hẹp. Nó đòi hỏi có đặc tả hình thức — mà viết đặc tả đúng thường khó ngang viết chương trình đúng. Nó tốn thời gian máy đáng kể. Và nó có một cái bẫy cố hữu: chứng minh đúng theo một đặc tả sai thì vẫn là phần mềm sai, chỉ là sai một cách rất trang trọng. Tới 8/2026, phần lớn đội ngũ thực chiến đứng ở bậc 2 đến 4 — kiểu tĩnh, kiểu nghiêm, và với hệ thống nền tảng thì thêm mô hình sở hữu của Rust.
Rust: thắng ở chỗ ít người dự đoán
Rust vào 2026 đã hết giai đoạn “ngôn ngữ được yêu thích” và bước vào giai đoạn “ngôn ngữ bị yêu cầu”. Sức ép không đến từ cộng đồng mà từ phía quy định: các cơ quan an ninh mạng đặt mốc buộc nhà cung cấp phần mềm hạ tầng phải có lộ trình chuyển sang ngôn ngữ an toàn bộ nhớ, với hạn chót rơi vào đầu 2026. Cộng thêm chuyện driver Rust trong nhân Linux đã qua giai đoạn thí điểm, và tỉ lệ doanh nghiệp dùng Rust trong sản xuất tiếp tục tăng.
Nhưng lập luận thú vị hơn nằm ở chỗ khác. Rào cản lớn nhất của Rust xưa nay là chi phí học và chi phí cãi nhau với borrow checker — một chi phí trả bằng sự bực bội của con người. Chi phí đó vừa bị hạ giá mạnh, vì máy không bực. Một agent bị borrow checker từ chối lần thứ hai mươi vẫn đọc thông báo lỗi và thử lại với đúng chừng đó nhiệt tình như lần đầu. Thứ từng là điểm trừ lớn nhất của Rust với con người lại đúng là thứ agent cần nhất: một trọng tài không khoan nhượng, nói rõ lý do, và luôn cho cùng một câu trả lời.
Nói cách khác, cùng một đặc tính ngôn ngữ nhưng đổi người dùng thì đổi dấu: khó với người, dễ với máy.
Góc kinh tế: mỗi vòng lặp hỏng là tiền thật
Chuyện này quy về tiền theo ba đường, và cả ba đều đo được.
Thứ nhất, chi phí một vòng lặp. Mỗi lần agent đoán sai rồi phải sửa là một lượt suy luận: token vào, token ra, thời gian chạy CI. Ngôn ngữ nào để lỗi lộ ra ở bước biên dịch — chưa cần chạy, chưa cần dựng môi trường, chưa cần dữ liệu thật — sẽ cắt gần hết những vòng đắt tiền phía sau. Với một đội chạy hàng nghìn tác vụ agent mỗi tuần, khác biệt vài vòng lặp mỗi tác vụ là khác biệt thấy được trên hoá đơn.
Thứ hai, và lớn hơn nhiều: chi phí xét duyệt của con người. Một lượt kiểm kiểu tốn vài xu tiền máy; một giờ kỹ sư cao cấp đọc mã tốn hàng chục đô la và là nguồn lực không co giãn. Khi lượng mã cần duyệt tăng gấp nhiều lần mà số người duyệt không đổi, con người trở thành nút cổ chai mới. Vậy nên tiêu chí chọn ngôn ngữ, đọc theo ngôn ngữ tài chính, chính là: tỉ lệ lỗi bị máy chặn trên tổng số lỗi. Mỗi điểm phần trăm dịch sang phía máy là một điểm phần trăm thời gian người được giải phóng cho việc mà chỉ người làm được — quyết định xem thứ đang xây có phải thứ nên xây hay không.
Thứ ba, chi phí sự cố. Lỗi thoát ra tới production đắt hơn lỗi bị chặn ở CI vài bậc độ lớn — tính cả sự cố dịch vụ, dữ liệu hỏng và lỗ hổng bảo mật. Đây cũng là chỗ mà bên mua bảo hiểm và bên làm quy định bắt đầu để ý: khi tỉ lệ mã do máy sinh tăng, câu hỏi “anh chứng minh được gì về mã của mình” chuyển từ chuyện kỹ thuật sang chuyện trách nhiệm pháp lý. Ngôn ngữ và công cụ có bằng chứng máy kiểm được sẽ rẻ hơn về mặt rủi ro, và điều đó cuối cùng hiện lên bảng cân đối.
Những chỗ dễ nhầm
- Kiểu tĩnh không bắt được ý định sai. Một chương trình có thể đúng kiểu, biên dịch sạch, chạy trơn tru và vẫn làm sai hoàn toàn thứ khách hàng cần. Trình biên dịch kiểm mã nhất quán với chính nó, không kiểm mã giải đúng bài toán. Đây là lý do phần việc quý nhất của kỹ sư đang dịch về phía diễn đạt yêu cầu và thiết kế ranh giới hệ thống.
- Ngôn ngữ ít dữ liệu chịu thiệt kép. Một ngôn ngữ trẻ, dù thiết kế đẹp tới đâu, cũng gặp bất lợi vì mô hình ít thấy nó và bởi vậy sinh mã kém hơn. Nghịch lý: thời đại AI vừa làm việc học một ngôn ngữ mới dễ hơn cho người, vừa làm việc phổ biến một ngôn ngữ mới khó hơn.
- Chiều ngược lại thì bất ngờ: ngôn ngữ di sản được cứu. Chính vì agent đọc và sửa được COBOL hay Fortran ở mức khá, chi phí giữ và hiện đại hoá hệ thống cũ giảm hẳn — làm suy yếu chính lý do người ta từng viết lại chúng. Không phải ngôn ngữ nào cũng cần thắng để tồn tại.
- Đừng nhầm “có kiểu” với “kiểu chặt”. Một dự án TypeScript rắc any khắp nơi có oracle yếu gần bằng JavaScript. Giá trị nằm ở chế độ nghiêm và ở việc để công cụ chặn cửa trong CI, không nằm ở tên ngôn ngữ.
Dự đoán
- Cuộc phân hoá diễn ra bên trong ngôn ngữ, không phải giữa các ngôn ngữ. Python và JavaScript giữ ngôi đầu về số lượng, nhưng biến thể được dùng nghiêm túc sẽ mặc định có kiểm kiểu bắt buộc trong CI. “Python không chú thích kiểu” dần thành thứ chỉ dùng cho script vứt đi.
- Tốc độ toolchain thành tiêu chí chọn ngôn ngữ. Sau TypeScript viết lại bằng Go và bộ công cụ Python viết bằng Rust, sẽ có thêm hệ sinh thái làm điều tương tự — mục tiêu ngầm là đưa mọi phép kiểm toàn dự án xuống dưới ngưỡng vài chục giây.
- Rust tiếp tục ăn phần hạ tầng, một phần vì lý do phi kỹ thuật. Sức ép quy định về an toàn bộ nhớ cộng với ưu thế trong vòng lặp agent khiến Rust là mặc định cho lớp nền mới, dù C và C++ vẫn còn khối lượng mã khổng lồ trong nhiều thập kỷ tới.
- Vericoding rời phòng thí nghiệm nhưng chỉ vào những chỗ đắt nhất. Mật mã, nhân hệ điều hành, hệ thống thanh toán, phần mềm y tế và hàng không — nơi chi phí một lỗi đủ lớn để trả giá cho việc viết đặc tả hình thức. Phần còn lại của ngành vẫn ở bậc kiểu tĩnh cộng kiểm thử.
- Kỹ năng đắt giá đổi chỗ. Không phải “biết cú pháp ngôn ngữ X”, mà là dựng được bộ kiểm chứng: viết đặc tả, thiết kế kiểu dữ liệu sao cho trạng thái sai không biểu diễn được, đặt bất biến, dựng property test, và biết dừng vòng lặp agent ở đâu.
- Thước đo độ phổ biến sẽ phải làm lại. Khi câu hỏi lập trình chuyển vào các cuộc trò chuyện riêng tư với mô hình và phần lớn mã do máy sinh, các chỉ số dựa trên diễn đàn công khai và số commit mất dần ý nghĩa; nhiều khả năng sẽ có cách đo mới dựa trên mã đang chạy thật.
Tóm lại, cuộc đua ngôn ngữ 2026 không quyết bằng cú pháp đẹp hay thư viện nhiều, mà bằng một câu hỏi khô khan: trong một giây, ngôn ngữ này chứng minh được bao nhiêu điều về đoạn mã vừa sinh ra? Ngôn ngữ trả lời được nhiều thì agent hội tụ nhanh, người duyệt được nhẹ gánh, và tiền tiết kiệm là tiền thật. Ngôn ngữ trả lời được ít thì vẫn sống — nhưng phải mượn giáp từ nơi khác, và trên thực tế thì cả ngành đang bận đi mượn giáp.
Thảo luận