Microsoft trả lời câu hỏi: Liệu mã AI có thể thay thế mọi dòng mã C/C++ trong Windows?

Trung Đào
Trung Đào
Phản hồi: 0

Trung Đào

Writer
Theo Windows Latest, Microsoft tuyên bố rằng họ không có kế hoạch viết lại Windows 11 bằng trí tuệ nhân tạo (AI) 🤔.
1766716130129.png

Điều này hoàn toàn trái ngược với những tuyên bố trước đó của các kỹ sư nội bộ xuất sắc, những người khẳng định họ sẽ sử dụng AI + Rust để thay thế C/C++:
Đến năm 2030, Microsoft đặt mục tiêu loại bỏ hoàn toàn mọi dòng mã C/C++ khỏi cơ sở dữ liệu của mình. Chiến lược này bao gồm việc kết hợp trí tuệ nhân tạo và thuật toán để viết lại kho mã nguồn lớn nhất của Microsoft.
Sơ đồ đường đi cũng khá thô sơ -
Một kỹ sư viết một triệu dòng mã mỗi tháng.
Thông cáo này nhanh chóng gây ra một làn sóng phản đối dữ dội trên mạng internet.

Một số cư dân mạng ngưỡng mộ sự quyết đoán của Microsoft trong việc ứng dụng trí tuệ nhân tạo, nhưng nhiều người khác lại lo ngại rằng việc thúc đẩy trí tuệ nhân tạo quá mạnh mẽ là quá rủi ro, gọi Microsoft là "mơ mộng hão huyền".
Làm như vậy chỉ gây rủi ro cho người dùng. Theo kinh nghiệm cá nhân của tôi, mã do AI tạo ra có tỷ lệ lỗi cao hơn nhiều so với mã tôi tự viết.
Phải chăng đây là lý do phiên bản Office 365 mới lại đầy rẫy lỗi?
Khi tình hình leo thang, kỹ sư của Microsoft, người đã gây ra sự việc, nhanh chóng phát động một chiến dịch quan hệ công chúng và sửa lại bài viết gốc.
Để làm rõ... Windows "hoàn toàn" không được viết lại bằng Rust với AI. Đây chỉ là một dự án nghiên cứu của nhóm tôi.

Microsoft nhanh chóng bác bỏ những tin đồn này.​

"Một kỹ sư, một triệu dòng mã mỗi tháng," vượt qua C/C++ bằng Rust và viết lại Windows 11 bằng trí tuệ nhân tạo.

Đây không chỉ là tin đồn; đó là một tuyên bố đầy tâm huyết của Galen Hunt , một kỹ sư ưu tú của Microsoft, khi ông đăng tin tuyển dụng trên LinkedIn.

Bài báo này nhanh chóng gây ra một làn sóng phản đối dữ dội trên mạng. Nhiều cư dân mạng đặt câu hỏi về "sự vô trách nhiệm" của Microsoft, cho rằng công ty này chỉ đang theo đuổi cái gọi là "tốc độ AI" một cách hời hợt mà không cân nhắc đến những hậu quả nghiêm trọng tiềm tàng.

Mối lo ngại trong cộng đồng mạng là Windows mang theo một gánh nặng lịch sử nặng nề, với hàng triệu dòng mã cũ chứa vô số lỗi "vô tình hoạt động". Nếu sự cố phát sinh sau khi viết lại mã, việc tìm ra nguyên nhân gốc rễ sẽ giống như mò kim đáy bể.

Một số cư dân mạng cũng chỉ ra rằng, ngoài "chất lượng" không thể kiểm soát, "tốc độ" thực tế có thể không nhanh hơn.
Công nghệ AI hiện tại còn cách xa khoảng năm bậc độ lớn so với việc tạo ra mã nguồn chất lượng cao như vậy, với tỷ lệ một lỗi trên mỗi mười dòng mã. Viết một triệu dòng mã sẽ dẫn đến một trăm nghìn lỗi.
Thực tế, với chất lượng hiện tại của các sản phẩm Vibe Coding, Microsoft sẽ tốt hơn nếu thuê người gõ lại bằng tay thay vì dành thời gian xem xét "một triệu dòng mã mỗi tháng".

Có lẽ Galen không ngờ rằng một tin tuyển dụng lại gây ra sự phản đối dữ dội đến vậy từ công chúng. Ông nhanh chóng bổ sung thêm lời giải thích vào bài đăng gốc, nói rằng ông chỉ đăng tin đó để tìm kiếm các kỹ sư có cùng ý tưởng , và mọi người đang hiểu sai ý ông.
Có vẻ như bài đăng của tôi đã thu hút nhiều sự chú ý hơn tôi dự đoán, với nhiều người suy đoán và diễn giải nó theo nhiều cách khác nhau… Tôi xin làm rõ: Windows không được viết lại bằng Rust và trí tuệ nhân tạo (AI) cũng không được thêm vào.
Dự án nghiên cứu này là về việc phát triển các công nghệ cho phép chuyển đổi giữa các ngôn ngữ lập trình khác nhau. Mục đích của tôi khi đăng bài là để tìm kiếm những kỹ sư có cùng chí hướng, chứ không phải để xây dựng một chiến lược mới cho Windows 11+, cũng không phải để ám chỉ rằng Rust là điểm đến cuối cùng.
Tuy nhiên, lời giải thích này dường như có phần yếu kém khi xét đến những "tham vọng" trước đó.

Xét cho cùng, khi Galen Hunt, một kỹ sư ưu tú của Microsoft và người đứng đầu Azure Sphere (nền tảng IoT của Microsoft), bắt đầu công khai sử dụng những thuật ngữ táo bạo như "loại bỏ C/C++" và "viết lại mã nguồn bằng AI", thật khó để không nghi ngờ rằng điều này thể hiện một sự đồng thuận nào đó đã đạt được trong nội bộ Microsoft.

Hơn nữa, Galen thường xuyên sử dụng đại từ "chúng tôi" trong bài đăng của mình, như thể ông ấy thực sự đang phát ngôn thay mặt cho Microsoft. Ít nhất, cũng phải có những tiếng nói ủng hộ trong nội bộ công ty.

Microsoft, một gã khổng lồ, sẵn sàng sử dụng trí tuệ nhân tạo (AI) để phá bỏ hoàn toàn những rào cản mã nguồn cũ nhằm tìm kiếm lại điều gì ?

Rust, thứ từng tưởng chừng không thể có được, giờ đã nằm trong tầm tay.​

Trong nhiều thập kỷ, các lỗ hổng bảo mật bộ nhớ luôn là một vấn đề mà Microsoft đã phải vật lộn để giải quyết.

Để dễ hiểu hơn, ta có thể coi máy tính như một công ty. Trong trường hợp này, hệ thống là ông chủ, còn các chương trình là nhân viên .

Tại công ty nhị phân này, nhân viên cần phải xin phép cấp trên một trạm làm việc, hay còn gọi là bộ nhớ, trước khi bắt đầu công việc. Trạm làm việc này được sử dụng để đặt máy tính, xử lý dữ liệu và liên lạc với đồng nghiệp.

Mỗi trạm làm việc đều có hướng dẫn sử dụng được quy định rõ ràng. Không gian bàn làm việc có hạn, và tất cả nhân viên chỉ được sử dụng trạm làm việc được chỉ định, và phải trả lại ngay lập tức sau khi tan ca.

Nếu nhân viên không tuân thủ các quy tắc này và cứ khăng khăng vượt quá dung lượng bộ nhớ được phân bổ trước, sử dụng máy tính của người khác, hoặc thậm chí trở thành "cựu binh" và từ chối rời khỏi bàn làm việc của nhân viên mới, điều đó sẽ làm gián đoạn hoạt động của công ty. Ở mức độ nhẹ nhất, nó sẽ gây ra lỗi chương trình và màn hình xanh chết chóc; ở mức độ nặng nhất, nó sẽ tạo ra lỗ hổng cho tin tặc.

Về vấn đề này, triết lý quản lý của phiên bản C/C++ trong sổ tay nhân viên là: Tôi tin rằng bạn sẽ không gây ra bất kỳ rắc rối nào!

Đúng vậy, C/C++ không quan tâm đến việc chương trình có tuân thủ các quy tắc sử dụng bộ nhớ hay không; miễn là nó có thể biên dịch được, C/C++ sẽ cho phép.

Vào năm 2019, Microsoft đã công khai thừa nhận rằng khoảng 70% các lỗ hổng bảo mật trong hệ thống Windows là do ngôn ngữ lập trình C/C++ gây ra.

Trong bối cảnh đó, Microsoft bắt đầu quan tâm đến Rust.

Không giống như cách tiếp cận tự do trong việc giảng dạy C/C++, Rust được thiết kế ngay từ đầu để giải quyết vấn đề an toàn bộ nhớ.

Mọi chuyện bắt đầu vào năm 2006. Thang máy trong tòa nhà chung cư nơi một người tên Graydon Hoare sống lại bị hỏng.

Lần thứ n rồi, anh ta càu nhàu và chửi rủa khi chật vật leo lên căn hộ tầng 21 của mình. Anh ta không thể hiểu nổi tại sao hệ thống thang máy lại có thể hỏng dễ dàng như vậy. Không nên như thế này!

Kết quả cho thấy rằng... các chương trình phần mềm thang máy này thường được viết bằng ngôn ngữ C/C++.

Để không còn phải leo cầu thang nữa, Grayton quyết định tạo ra một ngôn ngữ lập trình mới.

Và thế là Rust ra đời.
1766716177870.png

Cụ thể, để loại bỏ các lỗ hổng bảo mật bộ nhớ, phiên bản Rust của sổ tay nhân viên đã thiết lập một kế hoạch quản lý máy trạm nghiêm ngặt hơn về mọi mặt:
  • Bạn không thể tùy tiện chỉ vào vùng nhớ;
  • Bạn tuyệt đối không được nhìn trộm vào khu vực làm việc của đồng nghiệp;
  • Sau khi hoàn thành công việc, hãy dọn dẹp ngay lập tức và trả lại đồ đạc...
Mặc dù có nhiều hạn chế như vậy, hệ thống được thiết kế để ngăn ngừa lãng phí tài nguyên, vì vậy các lập trình viên không cần lo lắng về việc những hạn chế này làm giảm hiệu suất.

Đồng thời, nhờ khả năng tương tác tốt giữa Rust và C/C++, Microsoft có thể trực tiếp gọi API Windows hiện có và dần dần thay thế mã cũ mà không cần phải viết lại hơn 40 triệu dòng mã hệ thống từ đầu .

Đây chính là lý do tại sao Microsoft lại hào hứng với Rust đến vậy. Xét cho cùng, nếu cuộc đại tu lớn này thành công, các vấn đề bảo mật lâu năm đang gây khó khăn cho hệ thống Windows có thể được giải quyết hoàn toàn.

Tuy nhiên, Rust cũng có những nhược điểm, chẳng hạn như độ khó cao hơn và tốc độ phát triển ban đầu chậm hơn so với Go và Java. Nhưng đối với một gã khổng lồ như Microsoft, những điều này hầu như không phải là trở ngại.

Trên thực tế, Microsoft đã bắt đầu viết lại nhân Windows bằng Rust từ năm 2023. Nhưng cho đến nay, nỗ lực này vẫn chỉ giới hạn ở một vài mô-đun và chưa được triển khai trên quy mô lớn.

Ngoài những cân nhắc về mặt kỹ thuật, lý do thực sự ngăn cản Microsoft xoay chuyển tình thế là...

Thứ nhất, đó là gánh nặng lịch sử to lớn.

Nhân hệ điều hành Windows ra đời vào những năm 1980 và đã tích lũy một lượng mã nguồn khổng lồ và phức tạp qua nhiều thập kỷ. Việc chuyển sang Rust sẽ đồng nghĩa với việc viết lại hàng triệu dòng mã trải dài hàng thập kỷ.

Trong đống mã nguồn này ẩn chứa vô số trường hợp ngoại lệ. Nhiều cách triển khai tưởng chừng kỳ lạ và khó hiểu thực chất lại là những trụ cột quan trọng của công trình này.

Nếu có vấn đề phát sinh trong quá trình viết lại, rất có thể nguyên nhân gốc rễ thậm chí sẽ không được tìm ra, bởi vì không ai hiểu cách thức hoạt động của cỗ máy khổng lồ này.

Thứ hai, hệ sinh thái của Rust vẫn chưa đủ hoàn thiện.

Hàng triệu trình điều khiển của bên thứ ba, nhà sản xuất phần cứng và phần mềm cũ, cùng với một bộ công cụ đã hoàn thiện, là những rào cản quan trọng hơn đối với C/C++ so với chính bản chất công nghệ cốt lõi của nó.

Ngược lại, Rust không thân thiện với người mới bắt đầu và có đường cong học tập cao. Thực tế hơn, trong nhiều lĩnh vực chuyên biệt, Rust thiếu các giải pháp đủ hoàn thiện, và các nhà phát triển cần đầu tư rất nhiều thời gian để tích lũy kinh nghiệm nhằm bắt kịp hệ sinh thái mà C/C++ đã xây dựng trong nhiều năm.

Do đó, việc chuyển sang Rust không phải là quyết định mà Microsoft có thể tự mình đưa ra; tất cả các nhà phát triển đều phải đối mặt với một quá trình học hỏi dài .

Những tiến bộ nhanh chóng trong khả năng lập trình trí tuệ nhân tạo đã giúp cho kho báu này lần đầu tiên đến được với công chúng.

Nếu trí tuệ nhân tạo (AI), với vai trò là lớp trung gian, có thể hấp thụ và giảm thiểu chi phí chuyển đổi đã đề cập, thì sự kháng cự đối với việc chuyển đổi sẽ giảm đáng kể đối với cả các nhà phát triển của Microsoft và Windows. Đây có thể là lý do đằng sau đề xuất của Galen về "một kỹ sư, một triệu dòng mã mỗi tháng".

Nhưng lập luận này dựa trên một tiền đề: trí tuệ nhân tạo thực sự có khả năng đóng vai trò là "công cụ dịch thuật" .

Thực tế là ngay cả khi Gemini 3 Pro mang lại một bước tiến vượt bậc về chất lượng, điều đó vẫn chưa đủ để khiến các lập trình viên từ bỏ trách nhiệm của mình. Huống hồ là việc tích hợp trí tuệ nhân tạo (AI) sâu vào kỹ thuật cấp nhân hệ điều hành, điều có thể làm lung lay tận gốc rễ của Windows.

Có lẽ, như Galen đã nói, đây vẫn chỉ là một dự án nghiên cứu. Microsoft thực sự muốn thúc đẩy sự thay đổi, nhưng họ cũng biết rằng công nghệ vẫn chưa sẵn sàng.

Không có lửa thì không có khói.​

Không có gì ngạc nhiên khi cư dân mạng phản ứng mạnh mẽ như vậy, bởi vì Microsoft thực sự rất thích đưa ra những tín hiệu về việc "hoàn toàn đón nhận trí tuệ nhân tạo" trong quá khứ.

Vào tháng 4 năm 2025, Giám đốc điều hành của Microsoft, Satya Nadella, đã tự hào tuyên bố tại hội nghị nhà phát triển Meta rằng khoảng được viết bởi trí tuệ nhân tạo (AI) , và tỷ lệ này vẫn đang tiếp tục tăng lên.
Tôi ước tính rằng khoảng 20% đến 30% mã nguồn trong cơ sở mã của chúng ta, cũng như một số dự án, có lẽ được viết bằng ngôn ngữ lập trình phần mềm.
Cũng trong tháng đó, Giám đốc công nghệ của Microsoft đã đưa ra một tuyên bố thậm chí còn táo bạo hơn. Ông dự đoán rằng đến năm 2030, có tới 95% mã lập trình sẽ được tạo ra bởi trí tuệ nhân tạo (AI).

Tại Microsoft, "cuộc cách mạng AI" này đã lan rộng như cháy rừng, được thúc đẩy bởi sự đầu tư toàn diện của CEO Nadella.

Theo các nguồn tin, Nadella coi trí tuệ nhân tạo (AI) là thời điểm then chốt quyết định sự sống còn của Microsoft, liệu công ty có thể tiếp tục giữ vững vị trí dẫn đầu ngành công nghệ hay không. Đối với Nadella, đây cũng là cơ hội trăm năm có một.

Nhiệm vụ này vừa mang tính chuyên môn vừa mang tính cá nhân.

Do đó, tối hậu thư của CEO Microsoft gửi cho các giám đốc điều hành của mình là: chấp nhận trí tuệ nhân tạo hoặc rời khỏi công ty.

Tuy nhiên, sự cố này có thể buộc Microsoft phải đánh giá lại tốc độ trở thành một "công ty chuyên về trí tuệ nhân tạo".

Việc ngồi yên trên một mỏ vàng như Apple rõ ràng không phải là một lựa chọn, nhưng nếu một công ty thực hiện một bước đi quá lớn, thị trường cũng sẽ lo ngại rằng công ty đó có thể gặp phải một thất bại lớn.

Lên kế hoạch trước ba bước, rồi lùi lại hai bước.

Trong bối cảnh công nghệ phát triển nhanh chóng hiện nay, đây có lẽ là lựa chọn an toàn nhất.
 


Đăng nhập một lần thảo luận tẹt ga
Thành viên mới đăng
http://textlink.linktop.vn/?adslk=aHR0cHM6Ly92bnJldmlldy52bi90aHJlYWRzL21pY3Jvc29mdC10cmEtbG9pLWNhdS1ob2ktbGlldS1tYS1haS1jby10aGUtdGhheS10aGUtbW9pLWRvbmctbWEtYy1jLXRyb25nLXdpbmRvd3MuNzY1MTcv
Top