Linus Torvalds Is Vibe Coding Now—Are Software Engineers Doomed?

Let's talk about something that's been blowing up in the developer community lately. Linus Torvalds—yes, the creator of Linux—just released a new open-source project. What's got everyone talking? He built a Python visualization tool using Google's AI IDE Antigravity and vibe coding. This became a lightning rod for debate because, over the past year since vibe coding emerged as a concept, many software engineers have dismissed it as something only non-programmers use. So when one of the industry's most legendary figures starts vibe coding, people notice.

Once word got out that Linus was vibe coding, the hot takes came flooding in: "Software engineers are finished." You'll find plenty of posts like this on X. But is that really the case? In this article, we'll dig into what Linus actually thinks about AI-assisted development, whether his vibe coding means other engineers should panic, and what role traditional software engineering plays in the AI era.

How Linus Torvalds Views AI-Assisted Development

Let's rewind to 2023, about a year after ChatGPT launched. In a conversation at the Linux Foundation, Linus shared a surprisingly optimistic take on AI tools. He sees them as genuinely helpful for engineers tackling the work in front of them.

He went on to explain that throughout his career, he's written countless bugs—and seen even more from others. The thing is, most bugs aren't subtle edge cases requiring deep analysis. They're stupid mistakes that simply slipped through. Compilers have long caught some obvious errors and flagged warnings. But with large language models and AI, Linus believes we can now catch issues that aren't quite so obvious. That's why he's genuinely positive about these tools.

Fast forward to late 2025. By then, "vibe coding" had been coined earlier that year, and naturally, Linus was asked about it during a Linux Foundation discussion. His answer? Vibe coding is both great and terrible. Sounds contradictory—let's break it down.

First, the good: Linus thinks vibe coding works well for personal side projects. Setting aside the people dreaming of billion-dollar startups built entirely on vibe coding, he finds it exciting and genuinely positive. He pointed out that when he was learning to code, there was a real barrier to entry. As technology has grown more complex, that barrier has only gotten higher. Vibe coding gives newcomers an easier path over that hurdle. So for that purpose, he's all for it.

Given these comments from late 2025, it's no surprise that in early January 2026, he shipped a new open-source project built with vibe coding. Cue the takes: "Linus is vibe coding, so engineers are done for—everyone should just vibe code now." But is that actually what's happening here?

The Limits of Vibe Coding

Remember, Linus said vibe coding is both great and terrible. We covered the great part—now let's talk about the terrible.

The distinction comes down to context. For small projects or as a way to get started with programming, vibe coding is great. But for long-term product development and maintenance? Linus calls it a terrible idea.

In that same conversation, he explained that for truly impactful, large-scale projects, most people eventually realize vibe coding doesn't hold up. He's been working on Linux for nearly 35 years now, and the real work—the important work—has always been maintenance and ongoing support. When new hardware comes out, the kernel needs updates. After 35 years, he's still collaborating with open-source contributors worldwide to keep the codebase clean, maintainable, and stable.

From this perspective, it makes sense why he views vibe coding as useless—even harmful—for long-term maintenance. And he's not alone. Many voices in the open-source community share this concern.

Take Mitchell Hashimoto, founder of HashiCorp and creator of the popular open-source terminal Ghostty. He's been vocal about how people who blindly use AI to submit garbage code should be publicly called out and blocked by project maintainers. Interestingly, Hashimoto has been one of the biggest advocates for AI-assisted development over the past year. But even as an AI enthusiast, he's frustrated by the low-quality submissions flooding in.

The problem is simple: when contributors don't rigorously review what they're submitting, maintainers waste time reading through garbage, rejecting it, and getting pulled away from meaningful work.

So here's the bottom line: if you're vibe coding on an enterprise project or a major open-source codebase like the Linux kernel, you're wasting maintainers' time. And if unreviewed vibe-coded work actually gets merged, it drags down code quality and drives up long-term maintenance costs.

Are Software Engineers Really Doomed?

Back to the question at hand: does Linus vibe coding mean software engineers are finished? We don't think so. Linus himself said you won't see vibe coding in the Linux kernel. If the previous section convinced you, then you already know that even with Linus vibe coding on the side, software engineers aren't going anywhere.

But you might still wonder: what's the role of traditional software engineering in the AI era? Here's an insightful take from The Pragmatic Engineer, a well-known voice in the community. He shared what he called a potentially unpopular opinion: as AI tools become widespread, traditional software engineering best practices will become more valuable—things like testing, observability, and continuous delivery.

While he humbly suggested this might be unpopular, we couldn't agree more. Consider this: if you're working on a large, complex project with no tests, and you ask AI to modify some code, how do you know that change won't break something else? Without tests, you can't have confidence. And if you want AI to help automate more of your work, you need that confidence.

The takeaway is clear: projects with solid testing are better positioned for AI collaboration. Traditional software engineering practices are what enable AI to do its job well.

The Gatekeeper Role

Beyond best practices, the gatekeeper role that software engineers have always played becomes even more critical in the AI era. In a 2025 Linux Foundation conversation, Linus mentioned he hasn't been a "programmer" for about 20 years. His role has been technical leadership and system maintenance, while contributors from around the world do the actual coding.

Sound familiar? That's essentially the relationship most of us now have with AI. The AI does the implementation; we provide technical leadership, maintain the system, and serve as gatekeepers.

If you remember, in mid-2025, Linus rejected a kernel contribution from a former Google engineer. The rejection sparked significant community discussion. The core issue? The submitted code introduced an unnecessary layer of abstraction. Linus rejected it because he has the technical judgment to recognize that this extra abstraction would harm the kernel's maintainability.

Even though Linus hasn't been the one writing code for two decades, he remains absolutely essential to the system as its gatekeeper. We believe that now and in the future, software engineers working with AI must embrace this same role—ensuring that while productivity scales up, quality doesn't suffer.

We hope this deep dive into a trending topic helps clarify the relationship between software engineers and AI. If you want to get better at using AI for software development, we've created a Cursor course that's available for free online. Just search "Cursor tutorial" on Google—our SEO ranking is actually higher than Cursor's official docs.

If you want to sharpen the technical judgment needed to evaluate AI output, check out our YouTube channel for more content. And if you're a frontend or backend engineer looking to level up your career, build solid fundamentals, and develop stronger technical intuition, consider joining our Eplus Growth Program. We offer complete learning paths, online courses, and an exclusive Discord community. Search "Eplus Growth Program" on Google to learn more.

Thanks for reading—see you in the next one.