Slartie
And while you're at it, read "Chip Wars" by Christopher R. Miller as well. Extremely good read to understand tomorrows' most relevant geopolitical conflict.
At this point, the only reason why Anthropic has an advantage is laziness on the deciders' side (of which there is a lot) and, for non-coding work, the Claude harness is significantly better than most alternatives. For coding there are several model-agnostic alternatives on par or better than the frontier labs' own offerings. But arguably that is not yet true for office/document work.
Yeah, I gladly get some of the fruits of that work back!
I'd not release them soo easily from their share of responsibility. Tamper-proof hardware is a thing, electronic funds transfer terminals for example already implement ways to detect or prevent physical intrusion into safety-relevant parts of the device. Would probably have cost a few cents in manufacturing to add countermeasures to physical modification into the Ledgers. The fact that there is not even the slightest attempt at securing the device against this kind of attacks is entirely on the manufacturer.
> How a French (EU based) company is still in business after all of this, is an indicator of selective enforcement of EU privacy laws (GDPR, etc).
Surely you can name a dozen of US companies that have been driven out of business by enforcement of EU privacy laws. But I'd be glad if you'd at least name a single one!
This works fine with Opus 5.5. But it also works fine with GPT 6.1 Sol, Kimi K3 and MiMo 2.6 Pro.
It doesn't work equally well with Sonnet 5.5, interestingly.
If you want to go into detail with that kind of stuff, your best bet is not the PO, but the lead engineer of the team. If the team was properly staffed, the lead engineer will have a solid knowledge of the business aspects of the product while at the same time being able to cross-reference that with the most important technical aspects.
LLMs will make more people into "lead engineers", even if all they're "leading" is the LLM agents and not other humans, as it was common before the LLM age. One of those will then emerge as the "lead lead engineer" who's going to lead the humans which in turn lead the LLMs. If it wasn't for the "engineer" in the meaning of "code monkey" dying out - which I also expect - we'd have to invent a new title, but I'm currently expecting this shift to go without that. It'll still leave some engineers who made themselves comfortable just churning out code that does whatever a ticket requests, without even understanding one iota of the business process behind the ticket, without a job, but that's the kind of "software engineer" who in my opinion shouldn't ever have taken up the profession anyway.
If feature B depends on implementation of feature A, and feature A happens to be on the 20% wrong side, then feature B will be wrong too, regardless of whether you happen to have better luck with it being implemented on the 80% right side. It'll simply be built on a broken foundation. It WOULD have been correct if the foundation was right, but it wasn't.
This is actually very common in software development, where you rarely have stuff happening in isolation. A lot of features deliberately touch each other, build on top of each other, and even more so when you factor in "accidential" overlap due to unclean technical boundaries (in spaghetti code, everything touches everything).
It's funny that you can legitimately just add " - OMG!" in the slang acronym meaning after any of its creations' names.
It's not like everyone using AI has the same software development cycle. It's not even that everyone using AI is developing software.
That is absolutely not "do nothing".
You'd have to be the producer of the machine producing the mask. Or, even better, the software that produces the plan according to which a machine produces a mask.
> so if you don't have the most intelligent or cheapest model in the world, you're losing
So how does this match up to the fact that there is currently OpenAI and Anthropic, both raking in money? They can't both have the smartest model at the same time, can they? And all those inference companies selling API access to open weight models on OpenRouter, which are apparently also earning billions already? While the former are probably bound to have much higher cost for research and training than they are currently earning, which may be called "losing", the latter don't have that problem, they can simply price their API access such that the money earned covers their costs, no training and practically no research necessary. In your theory these companies shouldn't have a cent of earnings.
The smarter ones among the rich have realized this and are open for something like a universal basic income precisely for that reason: to protect their wealth and the position in the food chain this wealth affords them.
As long as they offer stable services and do charge the same API prices as competitors (or even less maybe, since they have the most inference providers on board, because OpenRouters' prime popularity also exists with inference providers) you do not really have an incentive to go through the hassle of changing all your configurations.
But it's been novel for inference services when OpenRouter was founded. And nowadays they have a considerable foothold in the market. There are competitors, but the one everyone knows is OpenRouter.
And since they do not need to maintain any stock, don't need to do anything with queries but route them through 1:1, the most complex thing they do from a business perspective is that they collect your money and route the right amounts to various inference providers that served you.
Also: quota. Implies you do not have unlimited access even for flat prices. Which in turn implies that as soon as you hit the quota on the most expensive flat price plan, even you will suddenly discover the magic of economically sensible behavior.
The latter is the core business of Stripe. For them, buying OpenRouter to become the premier channel for LLM token money makes perfect sense. At least if you assume that the current state of labs offering heavily subsidized subscriptions directly is only temporary and the future lies in people buying tokens and switching between models fluidly - and I consider that the future, in light of the recent developments with Kimi K3.
That's it. Simple as that. When you grasp for straws in panic mode, you don't exactly spend time strategizing and weighing the pros and cons of each straw carefully.
Also this arm of the discussion was about speed, not price.
Let's judge the speed of the model when its weights are released and every inference provider on the planet offers it, so demand can spread out a bit.
It's the same topic with token budget comparisons and subscription pricing - don't people understand that this doesn't really matter for open weights models? The pricing is going to be determined by the inference providers, and until they had a chance to evaluate the model on their infra and set token prices accordingly, one doesn't really have anything tangible to compare with other open models nor with closed ones.
Nobody needs "web services run from China" to use Chinese open weight models.
Same as they were doing in their startups: burn mon..., eh, tokens.
> And who is left to manage their hundreds of thousands of servers?
AI, of course.
DeepSeek v4 Flash/Pro also exist, they are open weight and on par with Sonnet, just a bit below Opus. Again: practically useful and sufficient for 80% of things most people actually do. And most of the remaining 20% are benchmarks designed to push the limits, not productive work.
Using these already is way cheaper than your typical Claude API prices. What's still missing is a) mindshare - everyone still thinks "claude = coding" and everyone thinks he/she really needs the very best models because he/she is doing such incredibly complex stuff - and b) someone pushing such a stack as a convenient solution for corporations to easily dump their token money into, complete with user management, enrollment, monitoring, all that enterprisey stuff you need if you want to sell to, well, enterprise customers.