In some industries it’s critical. Think about aerospace where code is almost always homegrown or done by specialized company, and are specific implementations for specific needs. You don’t have that many COTS due to the criticality etc.
The thing about specific needs is that they are usually narrow. You could throw darts at the dartboard of problems, working on very narrow problems for years and never get a job solving any of them. If a problem calls out to you and you won't stop until you get a job with it, then the effort could be worth it. But sometimes, even if you get THE job, you'll have a slight twist in constraints that makes most of your prep go by the wayside.
I agree, but we all have to pick our battles. Do you want to solve real problems, enjoy other things in life, or solve some problem that a guy on the internet said is essential for any "real" programmer?
The question is: if we keep the same context and model, and the same LLM configuration (quantization etc.), does it provide the same output at same prompt?
If the answer is no, then we cannot be sure to use it as a high-level language. The whole purpose of a language is providing useful, concise constructs to avoid something not being specified (undefined behavior).
If we can't guarantee that the behavior of the language is going to be the same, it is no better than prompting someone some requirements and not checking what they are doing until the date of delivery.
This is something that could be distilled from some industries like aviation, where specification of software (requirements, architecture documents, etc.) is even more important that the software itself.
The problem is that natural language is in itself ambiguous, and people don't really grasp the importance of clear specification (how many times I have repeated to put units and tolerances to any limits they specify by requirements).
Another problem is: natural language doesn't have "defaults": if you don't specify something, is open to interpretation. And people _will_ interpret something instead of saying "yep I don't know this".
IMO, it's clarifying software development. I think ultimately it means that some people who are slightly on the softer side of development will become indistinguishable from other developers, and people on the more mechanical side of development will disappear.
If what you do can be done by the systematic manipulation of symbols, we have a better system for that now. If the spec they hand to you has to be so specific that you don't have to think while implementing it, we have a machine that can do everything except think that can handle that.
> If the spec they hand to you has to be so specific that you don't have to think while implementing it
Does this exist in 2026? I feel like, at least in my bubble, expectations on individual developers has never been higher. I feel like the cut has already been made.
You can use LLMs as specification compilers. They are quite good at finding ambiguities in specs and writing out lists of questions for the author to answer, or inferring sensible defaults in explicitly called out ways.
Yeah, if you can somehow convince them you really, really want them to follow the specification and not just do whatever they want.
And is doesn't matter how many times you tell them the implementation and, more importantly, the tests needs to 100% follow the spec they'll still write tests to match the buggy code or just ignore bugs completely until you call them out on it and/or watch them like a hawk.
I see the fancy methodologies and processes as the way of streamlining what you have to do in order to "sit down to think about the software", particularly in teams of more than one developer.
Most of it happens, as always, at the interface. So these methodologies help you manage these interfaces between people, machine and product.
It is the HashiCorp fiasco all over again. HashiCorp thinks third-party is profiting from Terraform, they relicense, Terraform gets forked into OpenTofu.
Here, Rebble says Core is profiting from their work (hey, look at your licenses). It would be a direct violation of their ToS though, since there is this clause:
> 4. Services Usage Limits
>
> You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, access to the Service, or Content accessed through use of the Service, without Rebble’s express written permission.
So I don't know what to think honestly, I don't see any bad actors here...
What do you mean, practices from safety-critical industries applied to security? Unpossible! (end /s)
For that you need regulation that enforces it. On a global scale it is pretty difficult, since it's a country-by-country thing... If you say e.g. for customers in the US, then US Congress needs to pass legislation on that. Trend is however to install backdoors everywhere, so good luck with that.