IMO neither Go nor Rust are great for reading/reviewing code.
Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries.
I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes.
I also think we need a high level formal specification language to tell agents what we expect them to do.
> I also think we need a high level formal specification language to tell agents what we expect them to do.
Let’s make that specification Turing complete while at it.
Jokes aside, IMO it will be a good natural progression. Specify the problem statement in LLM specification, generate the code in Go/Rust whatever is the language of your choice and review the generated code to make sure it adheres to the architecture/design principles that you have set.
It absolutely should be Turing complete. I want to formally specify some constraints/invariants that any generated code has to meet, like very high level test cases.
It doesn't have to be a new language. I'm sure some existing language can be used to create a DSL that serves this purpose.
It can obviously never be complete. Some parts of the spec will always have to be natural language if we want to make the best use of LLMs.
Maybe we can have Large Logic Models instead, and they could have formalized keywords with rigid meanings? Like IF, WHILE and FOREACH maybe. Or even ASYNC if you want to be modern about it.
I do think that AI models should get better at logic. But if code generators are supposed to be tools, we have to tell them what to do. I'm not sure what combination of languages is best for that purpose.
It would be so much easier if we could precisely specify what we wanted, without all the double meanings, slang and general ambiguity that comes from using a natural language.
If only there was an entire class of well-studied languages which don't have any such ambiguity. They'd be perfect for programming LLMs! We could call them "programming languages" perhaps.
So what you're saying is that something far worse happened here. They did test for flooded streets but some slight difference caused the model to fail in real life.
To be fair, there will always be something that fails. So the more important question is probably the frequency and severity of those failures.
Yes, once you have modeled the problem correctly and you know all the input parameters. This is not that: Session# * tps * 86400 (secs in a day) * 30 days.
I don't think there is enough public information to check Anthropic's claims regarding inference profitability. It depends not just on unknown technical factors but also on agreements they have with other companies.
I agree that we dont know how expensive SOTA is. But yes my math should give you the max amount of tokens you can sell per month, and its not remotely profitible for most of the larger open source models (at their current pricing). Im not sure why a 10x larger model that is more in demand would be profitible when its only 5x the price.
Its possible you could pay off hardware for Kimi 2.6 after maybe 2-3 yrs (by providing low tps / high concurrency) but you're now out of warranty and have been running your machines full throttle 24/7 for 2-3 years.
This is why moonshot attempted to double the price when they released 2.6 but then it got driven down by North American capital subsidies.
I think explanation is itself a rather complex concept. At what point do we consider something as explained? Usually it has to do with identifying some causal factors and their relationships so that we can intervene and explore counterfactuals. But in many cases we are forced to act on the basis of incomplete explanations (e.g. in medicine).
I think there will be regulation that requires some users of AI to provide an explanation upon request. For instance, banks could be required to "explain" why you didn't get that loan. What if the decision is based on a credit score that includes some AI prediction that ultimately relies on the entire training corpus?
The bank can give you a list of factors that play into the decision but they may not be able to explain deterministically why a very similar customer did get that loan. At that point I think we're going to resort to statistics that prove a lack of bias against certain protected characteristics, but that's not really an explanation, is it?
I think we will never get useful and complete explanations for everything that AI does. Society will just accept some explanation-like thing or proxy and move on.
Supply of RAM isn't really limited by natural resources - silicon is literally one of the most abundant materials on the planet. It's limited by the construction of billion dollar factories.
>I do not care how software gets built. Only that it works.
I mean, I agree on a very high level of abstraction. But my problem is that I need to understand how software gets built so that I can have confidence in my ability to maintain and evolve the project.
I need to understand whether a feature is easy to add or requires a wholesale rewrite of the entire codebase, which comes with risks. I need to understand how new features affect existing users.
I also need to understand the economics of the process and the economics of my industry. That means I have to care to some degree about how software gets made, not just whether some specific program works at the present moment.
If you give me a choice between an implementation that is 100 LOC I can understand and an implementation that is a million LOC that I can never understand, I'm going to chose the former, even if both implementations pass all tests.
I may be able understand any given line of code but not necessarily all of them. The capacity of AI to generate code will quickly exceed human capacity to read and understand it.
Also, code quality matters for AI as well. Maintaining a million lines of code requires more tokens than maintaining 100 lines of code.
>The problem is introduced in Altman's case if (a) there was no disclosure (red flag)
The article says the investments were disclosed:
"OpenAI board chairman Bret Taylor defended Altman in a court hearing Monday, testifying that Altman had been “forthright” and “proactive and transparent” about his involvements in other companies. Altman recused himself from recent discussions about a deal between OpenAI and Helion as well, The Wall Street Journal reported."
iOS takes a very different approach to managing app memory though. And the intended purpose of a phone isn't quite the same as that of a laptop either, especially not for people who don't have an extra 128GB memory machine lying around. I'm not sure the comparison makes a whole lot of sense.
This is grasping at straws. Centralised social media platforms have won long ago for completely different reasons (mostly network effects and convenience). They haven't been threatened by independent sites for ages.
Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries.
I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes.
I also think we need a high level formal specification language to tell agents what we expect them to do.
reply