Linus lays down the law, and says it like it is. May as well not use an editor, or a compiler. Why stop at AI?

@gadi While I sort of agree with the conclusion the compiler-LLM (or editor-LLM) equivalence is just false:

https://blog.trailofbits.com/2025/12/19/can-chatbots-craft-correct-code/

@buherator how do?

@gadi sorry what?

@buherator @gadi It looks false from a programmier’s point of view IMHO. From a program manager’s or product owner perspective (and if you have a process like https://blog.koehntopp.info/2026/06/05/llm-driven-development/ describes it) things look different. Otherwise rewrites or ports wouldn't be possible. For a product (or any other substantial artefact) I define requirements, quality gates and UX. If everything passes, I do not care which language it was written in or how the code looks.
1/2

@buherator @gadi This requires a lot more than just the code. Where I want reproducible behavior is on the application level. The second run of my tax declaration better not differs from the first run with the same data. I know from years in workshops with customers how hard it is to get ambiguity out at the problem domain level. Code is a means to an end. If you use plain Englisch or Rust or Python or 68K Assembler doesn't matter. "Does it solve my requirement?“ does matter.
2/2

@Linkshaender @gadi if you don't care how the code looks you don't care about the long term maintainability of the codebase and having the right model of your domain. Linus argues that you *can* get these things right while using LLMs, and I agree. I also see that with LLMs it's very easy to accidentally impose massive debt on yourself by skipping the thinking required to bridge the gap between natural and formal languages.

@buherator @gadi Ah, maintainability, the holy grail of software development. 😉 IMHO this term split up in two: „run" and "change". As long as the software fulfills all quality gates and requirements, it is "ready“. It just has to run on the platform.
If the process that software has been built for changes, it's "change". Which means, if I have requirements and quality gates defined, I recreate it. Here I agree with Linus and you. LLM, used right can do/support this.
1/n

@buherator @gadi As for „thinking required to bridge the gap between natural and formal languages“, I am less concerned. Using natural language, we brought 450 tons of metal up 450 km in orbit. 😉 We got to the moon and back using natural language and people transplant hearts and lungs using processes described in natural language.
The problem lies in using concise natural language. Ask an MD ad hoc how to transplant a lung or do an ECG and it will turn out muddy and unprecise.
2/n

@buherator @gadi Natural language is sufficient to specify expected behaviour of a system if used correctly. I know (and I am sure you also) lots of software systems that were built with edge cases undescribed, lack of specific instructions for certain inputs. That is not a problem of formal language or not. This is a problem of fully understanding the problem domain. Yes, you may have to change specs, quality gates and UX descriptions, but that's also the case with „classical" programming.
3/3

@Linkshaender

Sorry, there is a lot to argue with here, so let me give you an extreme, but hopefully illustrative example:

Our spec is to add two finite integers. There is a non-zero chance, that the LLM will implement this by calculating square roots and applying a ton of hacks and so it does.

Humans are not able to touch the code since every bit of it is unreasonable and literally drives them crazy. Having an LLM do a change makes things worse.

Still all of your tests pass, since that's the success criteria for the LLM (btw how do you know what to test for in this case?). Some inputs (you don't know which) would DoS your system or give inaccurate results, but no one complained the last 6 months.

Would you be a happy PO of this system?

@gadi