Personally, I think even if AI tools can possibly used meaningfully and productively by experienced Linux kernel developers - people which have decades of experience with scrutinizing complex code that other programmers wrote -

… it will likely be an utter disaster in hands of average companies which are already ridden by technical debt, have no specs, no testing, no designed architecture, and will try to use AI to simply cut more corners and produce a higher volume of far worse code with cheaper hires. This will not end well for them.

(There is the argument that AI already “produces code that is better than typical code from the average mid/junior developer”. I do not think this holds water, because it can’t produce good code alone - this returns to the core of Torvalds argument.)

That would only be true if you were a clearvoyant which can predict which part of the code will change and which not. Which in turn would require to know which external requirements will change or not.

From the article:

Speaking on stage, Torvalds said the framing misses an obvious historical parallel. Compilers have translated essentially all shipped source code into machine code for decades, he noted, yet no engineer describes their software as “compiler-written.” AI, in his view, belongs in the same category — a powerful productivity layer sitting on top of human design and understanding, not a replacement for it.Linux & Unix

“When I see people saying, ‘Hey, 99% of our code is written by AI,’ I literally get angry, because those same people — I can pretty much guarantee — that 100% of their code is written by compilers.”

From the article:

https://pbxscience.com/torvalds-ai-is-the-new-compiler-not-the-new-programmer/

Speaking on stage, Torvalds said the framing misses an obvious historical parallel. Compilers have translated essentially all shipped source code into machine code for decades, he noted, yet no engineer describes their software as “compiler-written.” AI, in his view, belongs in the same category — a powerful productivity layer sitting on top of human design and understanding, not a replacement for it.Linux & Unix

“When I see people saying, ‘Hey, 99% of our code is written by AI,’ I literally get angry, because those same people — I can pretty much guarantee — that 100% of their code is written by compilers.”

The OP has likely no clue what the article is about even.

Jumping directly to an ad hominem attack leaves the inpression that you don’t have any meaningful argument in respect to the subject of the article.

previous discussion on that.

Note that Torvalds does not claim that AI tools necessarily speed up code generation. This is not how they actually use it in the Linux kernel. They use it for bug detection.

and the link does not contain a quote that can be remotely matched to this post’s title.

That’s not the case - first part pharaphrases Torvalds, second part cites him.

It is first the web pages title suggestion (see the URL if the link) followed by the title of the article.

And I don’t think the first part is awful - it sums up the main idea in few words.

See existing discussion in the technology@lemmy.world post, submitted by somebody else.

Edit: Whether the site-suggested page title in the first part is really a good title is somewhat subjective and therefore debatable. The question is does it sum up precisely a main topic of the article?

I think the notion that AI tools are actually intelligent and AI does the important work while the programmer only does tidy up work is manipulative framing.

The same as with many kinds of automation which denies the human part of the work, for better exploitation. It reminds me in self-service cash registers which are said to be fully automated - but the customer does now the work of the cashier and is given the responsibility of the employee.

Nobody would say a book itself is smart, in spite of printed books being a powerful technology, and some books containing deep thoughts. Nobody would say a photographic camera does the actual work of a painter. It is a tool which can help to create art in the hands of an artist

sure nuclear WAS fine, french power plants are getting old, can’t handle oncoming increasing heatwaves and regularly have major accidents.

Plus: Building nuclear power plants requires huge amounts of concrete. And making huge amounts of concrete requires extremely huge carbon emissions.

Which is also why claiming that agentic engineering (using long known best practices) is faster than programming without AI (and without specs, docs, written architecture, design reviews, issue tracking, APIs, and (God beware) sometimes even without version control is misleading.

Either one needs to compare humans and clankers without these tools, or both sides of the comparison need to have it.

Otherwise, it is a good question what is the true goal of this hype… making development in general faster does not seem to be it.

Rules like these ultimately presuppose that the contributor is acting in good faith.

All of civilization is based on that.

For Example hiding it in the statistical Distribution of word lenghts. Also, such hidden bits can be signed with public keys of the LLM companies.

He might have done so on purpose because the intended audience is already doing the same.

He is not only an open source contributor and entrepreneur, but also has learned how to communicate such matters to a non-technical audience. An incredibly valuable capability for the open source community.

Does it really? He does not omit to mention that generative AI might be more useful in the future, and AI algorithms have been used successfully.

The takeaway is that people, and especially executives, with personal positive AI experiences are not necessarily well positioned to decide on behalf of their organization whether AI has been a success. No matter how good it feels on a personal level. The same applies to people who use ChatGPT individually for work: it may feel great to have AI write and summarize reports for you, but is the organization actually becoming better as a result? That may not be your concern personally, but it certainly is the concern of management. I’ll return to that later.

An enormous problem is that in most organizations, people no longer evaluate whether AI is actually successful, or even can be. After all, it’s “the future.” AI is indeed here to stay, but it would still be nice to think carefully about what we should actually do with it. Or at the very least, define beforehand what you expect it to achieve and measure whether it actually does. Because “it felt good” simply isn’t enough. More on that later.

The takeaway is that people, and especially executives, with personal positive AI experiences are not necessarily well positioned to decide on behalf of their organization whether AI has been a success. No matter how good it feels on a personal level. The same applies to people who use ChatGPT individually for work: it may feel great to have AI write and summarize reports for you, but is the organization actually becoming better as a result? That may not be your concern personally, but it certainly is the concern of management. I’ll return to that later.

An enormous problem is that in most organizations, people no longer evaluate whether AI is actually successful, or even can be. After all, it’s “the future.” AI is indeed here to stay, but it would still be nice to think carefully about what we should actually do with it. Or at the very least, define beforehand what you expect it to achieve and measure whether it actually does. Because “it felt good” simply isn’t enough. More on that later.

Good Books on the essence of OOP!

I now think that useful OOP is mostly about invariants.

The finer details of the coding advice in Clean Code is also insane. There’s a good summary of it but I forgor where.

See

https://github.com/johnousterhout/aposd-vs-clean-code

By the way, "Uncle Bob"s prime number generator example discussed there (which Bob Martin, as he admits himself, does not understands any more in spite of that he himself published it in “Clean Code”) was originally designed and published by nobody less than Edsger Dijkstra and was used as an Example of Literate Programming by Don Knuth.

They are giants on whose shoulders we are standing. It is totally worth it reading first Dijkstra’s Chapter, then Don Knuth’s text, and then John Ousterhout’s discussion of Martin’s rewrite (linked above).

Or perhaps starting with Martins code and see if you understand it…

• https://gist.github.com/pooya-raz/59aa46460f72f994f204a861c7342b4b (Bob Martins Code, which he can’t explain when interviewed by Ousterhout)

• https://www.cs.tufts.edu/~nr/cs257/archive/literate-programming/01-knuth-lp.pdf (Knuths beautiful explanation of the algorithm invented by Dijkstra, using and demonstrating Knuth’s fantastic “Literate Programming” method)

• https://pure.tue.nl/ws/files/2408738/252825.pdf (Dijkstra’s original code and explanation, a gem of computer science history, where among other things he introduces the concept of invariants)

• https://github.com/johnousterhout/aposd-vs-clean-code (Ousterhouts interview with Martin, after publishing A Philosophy of Software Design)