In December 2025 I wrote that Claude Opus 4.5 changed everything. I had been using AI coding tools since the beginning. They were useful, but they were also unreliable. The working pattern was defensive: stage every change, review every prompt, stay on feature branches, lean hard on CI, and be ready to roll back.
Then I spent serious time with Opus 4.5.
What shifted was not that the model suddenly produced perfect software. It still didn’t. What shifted was the economics of my own time. I could describe why I wanted something instead of spelling out every implementation detail. The agent could plan, write, test, and iterate. I spent more of my day reviewing results, thinking about architecture, and deciding what should be built next.
I wrote at the time:
“Suddenly, when you are running 6 AI agents in parallel, it is like freaking horizontally scaling yourself.”
That was my personal inflection point — the moment AI-assisted development stopped feeling like a productivity experiment and started feeling like a fundamental change in how software could be built.
It was still only my experience. I could have been unusually tolerant of AI-generated code. Then July 2026 happened.
On July 14, 2026, Linus Torvalds replied to a discussion on the Linux kernel mailing list about LLM-based tooling for maintainers. The thread included familiar anti-LLM concerns and the question of whether such tools should simply be avoided.
Torvalds was direct:
“Linux is not one of those anti-AI projects”
and
“AI is a tool, just like other tools we use. And it’s clearly a useful one.”
This is not a random developer saying AI is handy. This is the person who created and still shepherds the Linux kernel.
That is why this matters more than my December experience. My moment was personal. This is a project-level signal from one of the most consequential figures in open-source software.
I’m not going to paraphrase the email and pretend the surrounding context is irrelevant. Read the full message:
Subject: Re: Linking Patchwork with Sashiko?
Date: Tue, 14 Jul 2026 20:06:14 -0700 [thread overview]
Message-ID: (raw)
In-Reply-To:[4928C919-7999-4E76-ADCB-F8643FED105B@linux.dev]
On Tue, 14 Jul 2026 at 19:01, Roman Gushchin[roman.gushchin@linux.dev]wrote:I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
LLMs in general, let’s discuss this, not how to make each use case more complex.It seems like [1] expresses a very anti-LLM position in general
Yes.
And no, that's not the position of the Linux kernel.
I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.
Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.
Or just walk away.
AI is a tool, just like other tools we use. And it's clearly a useful one.
It may not have been that "clearly" even just a year ago, but it's no
longer in question today.
There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.
Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.
But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.
The solution is to make sure those LLM toolshelpmaintainers
instead of just causing them pain. There's no question on that side.
We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.
And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.
Because it's not like natural intelligence is always all that great either.
The kernel project has been and will continue to be about the technology.
Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not thepointof the project.
This isNOTsome kind of "social warrior" project, never has been,
and never will be.
In the kernel community we do open source because it results in better
technology, not because of religious reasons.
And so we make decisions primarily based on technical merit. Not fear
of new tools.
Linus
What struck me most is that Torvalds does not claim AI is perfect. He talks about the problems it creates — embarrassing bugs, extra workload for maintainers, the risk of noise. His conclusion is not “AI is dangerous, therefore ban it.” It is closer to “AI is useful, therefore figure out how to make it work.”
That is a meaningful distinction.
The conversation around “AI slop” has gone sideways.
AI can still produce code that is:
I have seen all of those. I still review every change. I still rely on tests and CI. I still throw away AI-generated work when it is not good enough.
None of that contradicts the claim that AI has become an extremely useful engineering tool. In some ways it is why the tool is useful: we have gotten better at using it despite its failure modes.
The important fact is not that AI never makes mistakes. The important fact is that the cost of generating, evaluating, and discarding candidates has fallen far enough that the overall process is now productive.
Imagine opening a pull request and saying: “This was written by AI, so it’s slop.”
That is not a technical review.
A technical review asks:
“Was an LLM involved?” can be useful context. It is not a quality judgment.
Humans have produced terrible software for decades. We do not call it “human slop.” We call it bad code, review it, fix it, or delete it. The same standard should apply to AI-generated code.
The biggest shift is not that AI can write code. We have known that for years. The shift is that the cost of producing another implementation has collapsed.
This does not make engineering judgment less important. It makes it more important.
When implementation becomes cheap, deciding what to implement becomes more valuable. Architecture, requirements, code review, testing, domain knowledge, and the ability to recognize bad solutions all rise in relative value.
In December 2025 the story was capability: multiple agents, dramatically higher throughput, less time spent on repetitive implementation, more time spent on product thinking and review.
In July 2026 the story became acceptance: one of the world’s most important open-source projects is not going to reject the technology on ideological grounds.
Capability plus acceptance is a stronger signal than either alone.