Linus Torvalds: If AI Coding Is Cheating, Why Aren't Compilers?

Imagine interviewing a software engineer. They open an IDE, write code, run tests, use a debugger, and fix bugs. You're satisfied with the result. Now imagine another engineer solves the same problem with an AI coding assistant. The code runs, tests pass, the implementation is clean — but you reject them because they used AI.

As Linus Torvalds recently pointed out on the Linux kernel mailing list (October 13, 2026), this double standard is illogical. If using a machine called a compiler is acceptable, why does calling it an LLM make it complicated? Torvalds' argument is blunt: if you can't write assembly to prove you understand the machine, maybe you shouldn't be allowed to submit code at all. Why stop there? Why allow text editors for commit messages? A true developer should write perfect commit messages without backspace. The absurdity is the point.

Decades of Tools, Not Cheating

For decades we've used tools to write software. Early programmers worked in assembly, directly controlling machine instructions. Then came languages like C, Java, Python — compilers translate logic to machine code. IDEs made navigation, error detection, and refactoring easier. Debuggers reveal runtime behavior. Libraries let us reuse others' work. No one expects a modern engineer to implement their own language, build a compiler, and write everything in assembly before being deemed competent. We judge them on what they create and whether they understand the result.

Consider a simple Python example:

numbers = [10, 20, 30, 40, 50]
average = sum(numbers) / len(numbers)
print(average)

The developer doesn't reimplement sum() to prove they understand averages. They need to know what the function does, why it solves the problem, and what can go wrong elsewhere: empty lists, non-numeric values, millions of records that don't fit in memory. Programming's joy lies in understanding the problem, choosing the right solution, and anticipating flaws. AI coding assistants change how some work gets done, but they don't replace the need for understanding — at least, they shouldn't.

Wait — Is AI Just Another Tool? The Analogy Breaks Down

Comparing AI to a compiler sounds reasonable, but it's not a perfect analogy. A compiler translates a program according to language rules; it might have bugs, but it doesn't invent a whole new implementation from a vague description. AI coding assistants do exactly that. You can ask them to build a caching layer, implement an API endpoint, or optimize a database query. They generate hundreds of lines without you specifying every detail. Sometimes the result is genuinely impressive. Sometimes they introduce subtle bugs, misuse a library, or solve problems you never had. And sometimes the code looks polished enough that nobody notices the issue for a long time. That difference is critical.

Compilers typically operate on existing programs. AI coding assistants can generate programs themselves. This means the person using AI must evaluate not just the final output, but the decisions made along the way. AI drastically lowers the cost of generating code, saving time and effort when you know what you're building. But if you don't know what the correct solution should look like, it's dangerous. Developers who once struggled to write complex code can now generate it in seconds. But generating code and understanding code are two different things.

The real debate isn't whether AI is a tool — it obviously is. The more valuable question: can the user distinguish good results from bad ones?

The Real Problem: Code Runs, But No One Understands It

Imagine a developer asks an AI assistant to implement authentication for a web app. The assistant generates routes, token validation, middleware, and database integration. The app starts, login endpoints return expected responses, and a quick demo works. Weeks later, someone discovers expired tokens are handled incorrectly. Another developer tries to fix it but finds the authentication flow consists of multiple interacting generated code snippets. The original developer can't explain why the middleware was implemented that way or what security assumptions underlie it. They don't know which pieces can be swapped without breaking something else — now we're in trouble.

This has little to do with whether AI was used. Humans write equally bad code without AI; it just takes three days instead of three minutes. AI merely makes it easier to produce large amounts of code without anyone checking whether it makes sense. That's the trade-off: AI lowers the cost of writing code, but it doesn't automatically lower the cost of understanding, testing, and maintaining code. In fact, when AI rapidly generates large volumes of code, those other costs may become even more important.

Why the Linux Kernel Makes This Debate More Complex

This discussion matters beyond personal projects. The Linux kernel is a massive, long-lived project powering servers, cloud infrastructure, embedded systems, Android devices, and more. Kernel contributions aren't judged on whether a demo runs on one developer's machine. Changes can unexpectedly affect memory management, concurrency, device drivers, and other subsystems. A patch that looks correct in isolation might introduce race conditions, break assumptions elsewhere, or cause issues only under specific workloads.

Reviewers need to understand what a change does and why it's necessary. This makes the AI-assisted development question especially pointed. If a contributor submits generated code they can't explain, it creates problems for reviewers whose time is already limited. The kernel community has been discussing how to handle AI-assisted contributions and whether contributors should disclose when AI helped generate a patch. Torvalds' response pushes back on the idea that broad tool restrictions are the right way to judge competence. But there's a distinction: rejecting a blanket ban on AI doesn't mean accepting all AI-generated patches. A project can allow AI use while rejecting code that's buggy, undertested, insecure, or unexplainable by its author. Those two positions are entirely compatible — and they should go together.

So Should Developers Be Allowed to Use AI Everywhere?

Yes, with an important caveat: expectations should depend on task, risk, and outcome. Using AI to generate a throwaway Python script differs from using AI to modify a payment system, implement cryptography, or change memory management routines in the Linux kernel. The consequences of mistakes vary. The same principle applies to how we evaluate work.

Low-risk tasks: Developers can reasonably use AI to generate most of the initial implementation, then verify it works.

Security-sensitive changes: Developers may need deeper understanding of the implementation, extensive testing, and careful review of edge cases.

The point isn't to make people prove every line was hand-written, but to verify the final result meets standards. Here are reasonable criteria for AI-assisted programming:

You should be able to explain the code. If someone asks why a particular function exists or why a specific implementation was chosen, you should give a coherent answer.

You should test more than the happy path. A program that works in one example isn't necessarily correct. AI-generated tests can help, but they also need review.

You should understand the risks. If code touches authentication, payments, personal data, or infrastructure, you must consider failure modes a simple demo won't reveal.

You should own the outcome. When your submitted code causes problems, "the AI wrote it" is not a defense.

You should be honest about the work. If your project, employer, or assignment has specific rules about AI assistance, those still apply. Tool freedom doesn't exempt you from other obligations.

These requirements don't ask developers to avoid AI; they ask developers to act like engineers.

What This Means for Junior Developers

This is perhaps the most concerning part of the debate. AI is incredibly useful for learning: you can ask it to explain unfamiliar functions, generate examples, find bugs, or walk you through complex concepts. But there's a trap. You can now build remarkably functional applications without the skills needed to maintain them. Suppose a beginner uses an AI assistant to generate a complete backend. The app runs, APIs respond, the database stores records. On the surface, it's a successful project. But ask the developer how the app handles concurrent requests, what happens when the database connection fails, or why a particular query slows down as the dataset grows. If they can't answer, the application demonstrates what AI can generate, not what the developer understands. That doesn't mean beginners should wait until they're experts to touch AI. It's like telling people not to use calculators until they've mastered all arithmetic. Instead, use AI to accelerate learning, not bypass it. When AI generates code, read it, run it, tweak it, observe what changes. Ask why a specific approach was chosen. Try to poke holes in the implementation. If the code contains concepts you don't understand, research them before building the next layer. The goal is to reach a point where you can confidently use AI-generated code, not blindly depend on it. This applies to experienced developers too — years of experience don't make you immune to mistakes.

The Deeper Question: How Do We Measure Engineering Competence?

For years, programming interviews have relied on candidates solving problems under artificial constraints: implement a sorting algorithm without built-in sort, solve on a whiteboard without IDE, debugger, or documentation. These exercises have merit — they reveal algorithmic thinking and grasp of fundamentals. But there's a difference between using a constrained environment to test a specific skill and treating that environment as the only acceptable way to do engineering. Most developers don't spend their days writing code on whiteboards. They read existing code, investigate production issues, understand requirements, review pull requests, test hypotheses, and collaborate. If AI becomes a standard part of software development, we'll need better ways to assess those capabilities.

Can the developer spot a flawed AI-generated implementation? Can they identify security vulnerabilities? Can they explain a design decision and back it with technical reasoning? When the AI's explanation is wrong, can they debug the issue? Can they judge when AI is helpful and when it's better to solve the problem manually?

These questions are far more meaningful than "did someone use an AI assistant to write a function?" Developers who can answer them are valuable, regardless of the tools they use.

Final Thoughts

The AI coding debate has two extremes: one says using AI makes you a worse programmer because you stop writing code yourself; the other says AI will write all code so developers no longer need to understand programming. I agree with neither. Using a tool doesn't inherently mean you're incompetent, but it doesn't inherently make you competent either. Torvalds' argument reminds us that tools and the people using them are separate things. Yet critics of AI-assisted development highlight a real problem: generating code is getting easier, but generating plausible-looking code isn't the same as generating correct software. We must not confuse the two. I don't care whether a developer hand-writes a function, uses AI to generate it, or copies it from an existing library. I care whether the function solves the right problem, behaves correctly, and the developer can stand behind it. That's the standard I apply to AI-generated code — and honestly, it's the standard we should have applied to human-written code all along. The future of programming isn't about proving you can work without AI; it's about proving that even when AI does the heavy lifting, you still know what you're doing.