Elon muốn AI bỏ qua mã và phun ra nhị phân. đó không phải là tiến bộ.

Năm 1952, Grace Hopper ngồi trước một chiếc UNIVAC I và mệt mỏi khi sao chép các địa chỉ phụ thông thường bằng tay.Các lập trình viên vào thời điểm đó đã viết mã máy thô, nhìn lên các vị trí bộ nhớ từ một thư viện giấy, và ghép chúng lại với nhau bằng tay.Đó là chậm.Đó là khả năng mắc lỗi.Và những sai lầm là ngoạn mục. “Tôi có một trình biên dịch đang chạy và không ai có thể chạm vào nó”, cô sau đó nhớ lại. Cô đã xây dựng trình biên dịch A-0 dù sao đi nữa. Nó đã lấy mã toán học tượng trưng và tự động dịch nó thành hướng dẫn máy. Những gì trước đây đòi hỏi một tháng mã hóa thủ công có thể được thực hiện trong năm phút. Những người hoài nghi nói với cô rằng cô bối rối về những gì máy tính là cho. Cô bỏ qua chúng. Trong một thập kỷ, cô đã giúp tạo ra COBOL, và toàn bộ quỹ đạo phát triển phần mềm đã được thay đổi vĩnh viễn. Tôi đưa ra điều này bởi vì bảy mươi bốn năm sau, Elon Musk về cơ bản đã đề xuất rằng chúng ta hủy bỏ tất cả. Yêu cầu Trong một Tháng này, , Musk dự đoán rằng vào cuối năm 2026, "bạn thậm chí sẽ không bận tâm làm mã hóa. AI sẽ chỉ tạo ra nhị phân trực tiếp." Ông đi xa hơn: "AI có thể tạo ra một nhị phân hiệu quả hơn nhiều so với bất kỳ trình biên dịch nào."Tầm nhìn là đơn giản. XAI All-Hands họp Báo cáo của Reuters Ông cũng ủng hộ một bài đăng tuyên bố rằng tạo nhị phân trực tiếp thông qua AI đại diện cho "phương pháp tiết kiệm năng lượng nhất để tính toán."Bước tiếp theo sau đó, ông nói, sẽ là "sản xuất pixel trực tiếp, thời gian thực bởi mạng thần kinh." Có một thuật ngữ kỹ thuật cho những gì đang xảy ra ở đây, và nó không phải là "đổi mới." Đó là một lỗi thể loại. Một trình biên dịch là một bộ chuyển đổi bảo tồn ngữ nghĩa: nó hoạt động trên một ngôn ngữ chính thức với một thông số kỹ thuật, và sản lượng của nó có thể kiểm tra chống lại thông số kỹ thuật đó. Một LLM là một công cụ suy luận tạo ra các phần tiếp theo có thể tin được của các chuỗi token mà không có sự đảm bảo chính xác vốn có. Musk đang đề xuất chúng ta thay thế thứ nhất bằng thứ hai. Để hiểu tại sao điều này bị phá vỡ, bạn cần hiểu những gì các trình biên dịch thực sự làm. Điều gì xảy ra khi bạn hit compile Hầu hết các nhà phát triển có một mô hình tinh thần mơ hồ của biên soạn. Bạn viết mã, bạn chạy một lệnh, một executable xuất hiện. và đầu ra nhị phân là một trong những chuỗi biến đổi chính thức tinh vi nhất trong tất cả khoa học máy tính. gcc -O2 main.c Quá trình bắt đầu với : trình biên dịch đọc ký tự mã nguồn của bạn theo ký tự và phá vỡ nó thành token. từ khóa, định danh, nhà khai thác, chữ cái. , nơi các token đó được tổ chức thành một Abstract Syntax Tree (AST) đại diện cho cấu trúc ngữ pháp của chương trình của bạn. nếu ngữ pháp của bạn là sai, đây là nơi mà trình biên dịch bắt nó. Nó cho bạn biết dòng chính xác, nhân vật chính xác, và thường gợi ý những gì bạn có thể có nghĩa là. lexical analysis parsing Sau đó đến Trình biên dịch kiểm tra xem chương trình của bạn có thực sự có ý nghĩa hay không. Các loại của bạn có tương thích không? Bạn có tham chiếu các biến tồn tại không? Các chữ ký chức năng của bạn có nhất quán không? Lớp này bắt được toàn bộ các loại lỗi sớm: sự không phù hợp kiểu, tham chiếu không xác định, vi phạm arity, mã không thể tiếp cận được. Nếu không, những lỗi đó xuất hiện trong sản xuất, thường vào thời điểm tồi tệ nhất có thể. semantic analysis Sau đó, trình biên dịch dịch mã của bạn thành một Trong LLVM, đây là một đó là độc lập với cả ngôn ngữ nguồn và phần cứng mục tiêu. Đây là nền tảng của toàn bộ kiến trúc. Rust, Swift, C, C++, Julia, Zig, tất cả đều biên soạn xuống cùng một IR. Và một khi chúng ở đó, cùng một thông qua tối ưu hóa áp dụng cho tất cả chúng. intermediate representation định dạng, dựa trên SSA Loại bỏ mã chết: mã không bao giờ có thể truy cập được bị xóa. Loop unrolling: vòng tròn nhỏ được mở rộng để giảm các chi nhánh trên đầu. Vectorization: các hoạt động scalar được chuyển đổi thành các lệnh SIMD - xử lý nhiều điểm dữ liệu trong một chu kỳ CPU duy nhất. Đăng ký phân bổ: trình biên dịch quyết định những giá trị nào sống trong đó CPU đăng ký, giải quyết một vấn đề hài lòng hạn chế mà con người đã từ bỏ làm bằng tay vào những năm 1970. của Matt Godbolt là một cửa sổ đẹp vào thế giới này. gõ một số C++ ở bên trái, xem lắp ráp xuất hiện ở bên phải, và chuyển cấp độ tối ưu hóa để xem mã của bạn chuyển đổi. , you get a literal translation. At , trình biên dịch thực hiện phẫu thuật mà sẽ mất hàng giờ để lý luận về. trên 3.000 phiên bản biên dịch và 81 ngôn ngữ lập trình. các kỹ sư tại Google sử dụng nó hàng ngày để trong code sản xuất. Trình duyệt Explorer -O0 -O3 92 triệu biên soạn mỗi năm study optimization patterns Dự án LLVM một mình đã được phát triển GCC đã tồn tại từ năm 1987. a Việc thực hiện chỉ các thông qua tối ưu hóa cơ bản, lây lan liên tục, loại bỏ mã chết, xóa vòng, phân bổ đăng ký, sẽ đòi hỏi nhiều kỹ sư có kinh nghiệm làm việc trong nhiều năm. Và những trình biên dịch này vẫn đang trở nên tốt hơn. Cả GCC và LLVM tiếp tục cải thiện các chiến lược vectorization và tối ưu hóa cụ thể về kiến trúc của họ với mỗi bản phát hành. Từ năm 2000 sản xuất-chất lượng tối ưu hóa biên dịch đại diện cho hàng thập kỷ người-năm phát triển Mỗi một trong những biến đổi này là Với cùng một mã nguồn, cùng một phiên bản biên dịch và cùng một cờ, bạn nhận được cùng một nhị phân. (Đạt được khả năng tái tạo đầy đủ trên các môi trường xây dựng là , nhưng bản thân trình biên dịch là một chức năng thuần túy của các đầu vào của nó.) , được xác nhận bởi nhiều thập kỷ thử nghiệm, hàng tỷ giờ sản xuất và các bộ thử nghiệm khổng lồ. Các trình biên dịch thông thường như GCC và LLVM không được chứng minh chính thức từ đầu đến cuối, nhưng chúng là một trong những hiện vật phần mềm được thử nghiệm nhiều nhất mà con người từng tạo ra. . deterministic kỷ luật của riêng mình designed to preserve program semantics CompCert milliseconds Đây là điều mà Musk đề xuất thay thế bằng một mô hình ngôn ngữ. Kinh tế của Stochastic Compilation Glauber Costa, người sáng lập Turso và là người đóng góp lâu năm cho Linux Kernel, “Câu hỏi không phải là liệu AI có thể ‘viết nhị phân trực tiếp’ hay không, câu hỏi là liệu nó có phải là kinh tế để làm như vậy hay không, nó tốn token cho AI để làm mọi thứ. Đặt nó ngắn gọn trên X Điều này xứng đáng được giải nén bởi vì chênh lệch chi phí không phải là giới hạn. chạy Trên một trường hợp đám mây, đó là một phần của một xu. Ngay cả việc biên soạn hạt nhân Linux từ đầu, một trong những công việc biên soạn lớn nhất mà hầu hết các nhà phát triển sẽ gặp phải, mất vài phút và chi phí ít hơn một đô la trong máy tính. gcc -O2 main.c Một LLM biên giới như Claude Opus 4.6 chạy tại Một nhị phân được biên soạn điển hình cho một ứng dụng không tầm thường có thể là hàng chục ngàn dòng mã máy. Để tạo ra điều đó "trực tiếp" như nhị phân, mô hình sẽ cần phải tạo ra hàng triệu token đầu ra với độ chính xác hoàn hảo. Bởi vì các lỗi nhỏ trong nhị phân không cho bạn một câu trả lời hơi sai. Họ cung cấp cho bạn một segfault, một lỗ hổng bảo mật, hoặc hành vi không xác định mà làm hỏng bộ nhớ trong im lặng. Và không giống như một typpo trong mã nguồn, mà một trình biên dịch đánh dấu với một lỗi hữu ích trên dòng chính xác, một byte sai trong nhị phân cho bạn không có gì để làm việc với. Debugging đó là khảo cổ học, không phải kỹ thuật. $5 mỗi triệu token đầu vào và $25 mỗi triệu token đầu ra Perfect. Ngay cả khi chúng ta hào phóng và giả định một LLM có thể bằng cách nào đó tạo ra kết quả nhị phân chính xác (mà nó không thể, nhưng chúng ta sẽ đạt được điều đó), nền kinh tế năng lượng một mình là nguy hiểm. Trong khi đó, một trình biên dịch xác định chuyển đổi cùng một mã nguồn sang cùng một mã nhị phân bằng cách sử dụng một vài trăm chu kỳ CPU mỗi hướng dẫn, tiêu thụ các đơn đặt hàng có quy mô ít năng lượng hơn. 4 Joules cho mỗi token đầu ra Bạn đang đề xuất thay thế một sự biến đổi xác định sử dụng tính toán không đáng kể bằng một quá trình suy luận stochastic đòi hỏi các cụm GPU chạy ở hàng trăm watt mỗi thẻ. Những gì bạn mất khi bạn xóa mã nguồn Tuy nhiên, ngay cả khi kết luận là miễn phí, đề xuất vẫn sẽ là sai, bởi vì nó về cơ bản hiểu sai mã nguồn là gì. Mã nguồn không chỉ là một đầu vào cho một trình biên dịch. Nó là tác phẩm nghệ thuật của kỹ thuật phần mềm. Đó là điều mà con người suy nghĩ, xem xét, phiên bản, xóa, gỡ lỗi và duy trì. Loại bỏ nó, và bạn không chỉ mất một “bước trong đường ống.” Git, công cụ làm nền tảng cho hầu hết các phát triển phần mềm chuyên nghiệp, hoạt động bằng cách theo dõi các thay đổi theo từng dòng đối với các tệp văn bản. Bạn có thể thấy chính xác những gì đã thay đổi giữa hai phiên bản, ai đã thay đổi nó, và tại sao (nếu họ đã viết một thông điệp cam kết xứng đáng). Bạn không thể phân biệt hai nhị phân một cách có ý nghĩa. Version control stops working. Tại bất kỳ tổ chức kỹ thuật nghiêm túc nào, không có tàu mã mà không có đánh giá của đồng nghiệp. Một người đánh giá đọc diff, kiểm tra logic, nắm bắt các trường hợp cạnh và đặt câu hỏi. Với đầu ra nhị phân, không có gì để xem xét. Bạn đang yêu cầu các kỹ sư tin rằng AI đã làm đúng, không có cách nào để xác minh. Đây không phải là một dòng công việc. Code review becomes impossible. Khi một chương trình được biên soạn thất bại, bạn nhận được một trace stack, một số dòng, và một trạng thái biến. Khi một chương trình chỉ có nhị phân thất bại, bạn nhận được một địa chỉ bộ nhớ và một segfault. Một trong số này có thể gỡ lỗi. Debugging goes from hard to impossible. Một nhị phân được biên dịch cho x86 sẽ không chạy trên ARM. Một nhị phân cho ARM sẽ không chạy trên RISC-V. Mã nguồn biên dịch cho tất cả chúng với trình biên dịch thích hợp. Hopper nhận ra trong những năm 1950 rằng việc gắn các chương trình với phần cứng cụ thể là lãng phí.Nếu AI của bạn tạo ra nhị phân thô, nó bây giờ cần tạo ra các đầu ra hoàn toàn khác nhau cho mỗi kiến trúc mục tiêu. Cross-platform portability disappears. Những lý do chính khiến các ngôn ngữ cấp cao được phát minh Bạn không thể kiểm toán những gì bạn không thể đọc. an ninh chuỗi cung ứng, đã là một trong những vấn đề khó khăn nhất trong kỹ thuật phần mềm, trở nên không thể thực tế khi mỗi hiện vật là một nhị phân không rõ ràng được tạo ra bởi một quá trình không xác định. làm thế nào bạn xác minh rằng AI không giới thiệu một lỗ hổng? làm thế nào bạn thậm chí xác định "sự dễ bị tổn thương" khi bạn không thể kiểm tra logic? Security auditing becomes a black box. Hopper hiểu điều này vào năm 1952. toàn bộ điểm di chuyển ra khỏi mã máy là cung cấp cho con người một cách để lý luận về những gì máy tính đang làm. ngôn ngữ lập trình không phải là một hạn chế để vượt qua. Chúng là một giao thức giao tiếp giữa con người và máy móc. loại bỏ lớp có thể đọc được của con người không đơn giản hóa bất cứ điều gì. Những gì LLM thực sự làm tốt (và nó không phải là điều này) Đây là điều: LLM đang thực sự biến đổi phát triển phần mềm. tôi sử dụng chúng mỗi ngày. Chúng là những công cụ đáng chú ý. Và cách chúng thực sự hữu ích không có gì để làm với "trượt mã và tạo ra nhị phân." LLMs excel trong công việc Họ rất giỏi trong việc tạo mã boilerplate, khám phá API, tạo nguyên mẫu nhanh chóng, dịch giữa các ngôn ngữ lập trình, giải thích các cơ sở mã không quen thuộc và viết các bài kiểm tra. within Điều này có giá trị. Nó làm cho các nhà phát triển nhanh hơn, làm giảm rào cản để vào, và cho phép các kỹ sư giàu kinh nghiệm dành nhiều thời gian hơn cho kiến trúc và thiết kế. công cụ xung quanh phát triển hỗ trợ LLM, những thứ như Cursor, GitHub Copilot, và khả năng mã hóa đại lý của Claude, đang được cải thiện với tốc độ nhanh chóng. Nhưng hãy chú ý những gì tất cả các công cụ này sản xuất: Mã nguồn có thể đọc được bởi con người, có thể kiểm soát phiên bản, có thể xem lại, có thể gỡ lỗi. Mã đó sau đó được biên dịch bởi các nhà biên dịch xác định thành các nhị phân được tối ưu hóa. LLM xử lý thế hệ sáng tạo. Bộ biên dịch xử lý sự chuyển đổi xác định. Mỗi người làm những gì họ giỏi. source code. Có nghiên cứu thực sự thú vị tại giao điểm của LLMs và biên soạn. , một khuôn khổ được trình bày vào năm 2025, sử dụng LLMs để tái tạo mã thành các mô hình có khả năng biên dịch tự động, đạt được tốc độ trung bình 1.77x. có một cách tiếp cận tương tự, sử dụng LLMs để tạo SIMD nội tại với xác minh chính thức thông qua Alive2 để đảm bảo tính chính xác. Nhưng lưu ý các mô hình trong cả hai: các LLMs đang tạo ra mã cấp nguồn mà sau đó đi qua đường ống biên dịch truyền thống. Tuổi LLM-Vector hóa Như Costa lưu ý: “Nếu AI trở nên tốt hơn trong việc biên dịch mã hơn so với các trình biên dịch hiện tại, thì nó sẽ viết một trình biên dịch và từ thời điểm đó, sử dụng nó.” Nhưng nếu nó không có nghĩa là theo nghĩa đen thì sao? Một bài đọc hào phóng về tuyên bố của Musk có thể đi một cái gì đó như thế này: “Ông ấy không thực sự có nghĩa là lấy mẫu các bit ngẫu nhiên. Đúng rồi, chúng ta hãy làm thép thôi. Nếu bạn có nghĩa , điều đó đã xảy ra. Nghiên cứu tôi vừa trích dẫn cho thấy LLMs giúp với các quyết định vectorization, sắp xếp thông qua tối ưu hóa, và refactoring mã cho sự hợp tác biên dịch tốt hơn. Điều này là thực sự, hữu ích, và gia tăng. Nó cũng không phải là những gì Musk mô tả. ông nói "bạn thậm chí không làm phiền làm mã hóa," không phải "nhà biên dịch trở nên thông minh hơn." AI cải thiện các trình biên dịch Nếu bạn có nghĩa , đó là một lĩnh vực nghiên cứu tích cực với nhiều thập kỷ lịch sử. và các công cụ tổng hợp hiện đại có thể tạo ra các chương trình từ những hạn chế. Nhưng chúng hoạt động chính xác bởi vì chúng có các thông số kỹ thuật chính thức để xác minh chống lại. Các đầu ra được kiểm tra, không đáng tin cậy. Và các thông số kỹ thuật bản thân được viết bằng các ngôn ngữ có cấu trúc, có thể đọc được bởi con người. Bạn vẫn cần lớp có thể đọc được bởi con người. tổng hợp chương trình từ các thông số kỹ thuật chính thức Sketch Nếu bạn có nghĩa Với không có mã nguồn, không có thông số kỹ thuật chính thức, và không có bước xác minh, thì bạn đã đến với tuyên bố thực tế của Musk, và nó sụp đổ dưới những vấn đề mà tôi đã mô tả. Nói một cách rõ ràng: các phương pháp tiếp cận hiện tại "hầu hết không thể vượt qua các trình biên dịch truyền thống về hiệu suất, chi phí hoặc khả năng mở rộng" ngay cả đối với các nhiệm vụ biên dịch hẹp, chưa kể đến thế hệ từ đầu đến cuối. end-to-end thế hệ nhị phân từ ngôn ngữ tự nhiên Khảo sát gần đây về nghiên cứu LLM-compiler Các phiên bản thép không phải là những gì ông nói hoặc không phải là mới. phiên bản theo nghĩa đen là những gì ông nói và không hoạt động. Tại sao anh ấy nói điều này Musk tuyên bố rằng ông đã xây dựng các trò chơi điện tử khi còn nhỏ.Nếu đó là sự thật, không có gì trong số này nên xa lạ với ông.Ông ta viết mã.Ông ta đối phó với các trình biên dịch.Ông ta có thể hiểu sự khác biệt giữa một quá trình xác định và một quá trình xác suất. Nhưng “AI giúp các nhà phát triển viết mã tốt hơn nhanh hơn” không phải là một câu chuyện hữu ích nếu bạn đang chạy xAI. Nó không thay đổi vị trí của Grok. Nó không biện minh cho hàng tỷ trong cơ sở hạ tầng GPU. Nó không làm cho tiêu đề. “AI giết chết mã hóa hoàn toàn” làm cả ba. Điều này không phải là duy nhất đối với Musk. Mỗi công ty xây dựng cơ sở hạ tầng GPU đều có động lực để tuyên bố rằng mọi thứ sẽ đòi hỏi tính toán kết luận. Khi mô hình kinh doanh phụ thuộc vào việc bán mã thông báo, mọi vấn đề đều có vẻ như nó cần nhiều mã thông báo hơn. Musk chạy xAI. Grok cần một câu chuyện. Và mọi tuyên bố về sức mạnh toàn năng sắp tới của AI cũng là một tuyên bố về giá trị của cơ sở hạ tầng xAI đang được xây dựng. Khi bạn nói với thế giới rằng AI sẽ thay thế các trình biên dịch, tạo ra các nhị phân trực tiếp và cuối cùng tạo ra đầu ra pixel thời gian thực từ các mạng thần kinh, bạn đang không đưa ra một dự đoán kỹ thuật. Bạn đang đưa ra một luận án đầu tư. Bạn đang nói với thị trường rằng nhu cầu cho máy tính kết luận sắp trở nên vô Musk có một lịch sử dự đoán với các dòng thời gian đầy tham vọng. Xe hoàn toàn tự động vào năm 2018 (chưa có ở đây). Một triệu taxi robot trên đường vào năm 2020 (cười về phía sau). Tương tác giữa con người và máy móc thông qua Neuralink vào năm 2021 (chúng tôi đã quản lý để cho một vài người di chuyển con trỏ). Những dự đoán này không có nghĩa là chính xác. Chúng có nghĩa là định hướng, định hình kỳ vọng và đầu tư xung quanh một tầm nhìn cụ thể về tương lai, một trong đó công ty của ông là trung tâm. Các "mã hóa đi đến không" tuyên bố là cùng một trò chơi. Nó không phải là một phân tích kỹ thuật. Nó là thế hệ nhu cầu cho kết luận máy tính, ăn mặc như lời tiên tri. Tương lai thực tế Tương lai của lập trình không phải là thế hệ nhị phân từ lời nhắc.Đó là những gì đã xảy ra: trừu tượng cấp cao hơn, công cụ tốt hơn, và AI như một cộng tác viên trong quá trình sáng tạo viết phần mềm. Các ngôn ngữ lập trình sẽ tiếp tục phát triển. Các trình biên dịch sẽ tiếp tục cải thiện, có khả năng với các bước tối ưu hóa được hỗ trợ bởi ML khám phá ra những biến đổi mới. LLM sẽ tiếp tục trở nên tốt hơn trong việc tạo ra, xem xét và giải thích mã. Khoảng cách giữa "Tôi có ý tưởng" và "Tôi có phần mềm làm việc" sẽ tiếp tục thu hẹp. Nhưng mã nguồn không đi đâu cả. nó tồn tại vì con người cần phải hiểu, xác minh và duy trì những gì máy tính làm. nhu cầu đó không biến mất vì máy tính trở nên thông minh hơn. Grace Hopper đã dành sự nghiệp của mình đấu tranh cho ý tưởng rằng lập trình nên dễ tiếp cận, rằng con người nên có thể thể hiện ý định của họ bằng các ngôn ngữ mà họ có thể đọc và lý luận, và rằng máy móc nên xử lý việc dịch sang phần cứng. Câu trả lời cho câu hỏi “làm thế nào để chúng ta phát triển phần mềm tốt hơn” không phải là “tắt khả năng của con người để hiểu phần mềm.” câu trả lời là các công cụ tốt hơn, ngôn ngữ tốt hơn, trình biên dịch tốt hơn, và có, các trợ lý AI tốt hơn làm việc trong stack thay vì cố gắng thay thế nó. Dự đoán của Musk sẽ già đi theo cách mà các dự đoán khác của ông đã già đi: như một lời nhắc nhở rằng những tiếng nói lớn nhất trong công nghệ thường ít quan tâm đến cách mọi thứ thực sự hoạt động.