Slartie

This kind of trivia can be discovered in the very interesting and entertaining book "Eccentric Orbits: The Iridium Story" by John Bloom. Highly recommended read (if you're generally into tech/business/startup chronicles)!

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.

Nobody has to "run their own setup". Just buy inference from one of the many different open weight inference providers out there. You can use non-chinese ones as well if you don't trust Moonshot AI.

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.

You mean that "homework" that the US labs stole from me and billions of others before?

Yeah, I gladly get some of the fruits of that work back!

> the latest incident, which arguably isn't their fault

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!

I am frequently running agents on a multi-microservice application workspace where I really need the 1M context windows, because they are filled to the brim when implementing features that require changes on several services and APIs.

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.

Yeah, most PO/PMs I've encountered know awfully little about the business processes, their constraints and complex interactions within their own product. They know quite a bit about priorities the various customers voiced, fancy stuff they'd like to demo on the next review or trade fair or customer relationship meeting, or new features they want to get customers interested in. But don't ask them how those features interact with others!

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.

Whatever LLMs are capable to with regard to translations is not relevant for the 30-year history of primarily Silicon-Valley-originated consumer tech service expansion: todays' LLMs didn't exist pre-2022, but the gigantic moat of US tech giants was developed pre-2022. Today, they mostly profit from that flywheel having been sped up already in the past.

Fragmented EU domestic market (27 very different countries with no shared language) vs. unified US domestic market (50 pretty similar states with shared language) is the most important factor when it comes to scaling the typical services with marginal to nonexistent unit costs that are common in the tech world, especially consumer tech.

If you have work building on top of other work, your "20% wrong" quickly turn into "80% wrong".

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).

Also BPMN, CORBA and UPOS/JavaPOS.

It's funny that you can legitimately just add " - OMG!" in the slang acronym meaning after any of its creations' names.

Where exactly do you take the knowledge from that this strategy is indeed not a strategy, but was retrospectively declared a strategy by the West?

A harness of limited capability is a component that doesn't exist in your proposal, right? Just like non-automatable or at least hard-to-automate things like physical actions to be performed in the real world as part of a business task do not exist, too? Same goes for coordination with other real humans - doesn't exist.

You call it "lack of ambition", implying a certain arrogance; more humble people might just call it "a different sweet spot" of AI integration. After all, the goal in the end is not to use up as many AI tokens as possible, but the goal is to implement/perform a certain business case in the best way possible with regard to cost/speed/quality.

It's not like everyone using AI has the same software development cycle. It's not even that everyone using AI is developing software.

China is actively tripping the US up by pushing the open-weight strategy, which is kind of smart. They realized that they obviously will not be able to make Western companies trust Chinese companies enough to just use proprietary models by sending all their data to services hosted by Chinese companies. The US is still able to attract this trust, although it's eroding quickly in spite of recent political events and the current trust is more or less a function of old habits that need some time to change. But China correctly found that - due to there being no old habits to piggyback on - they wouldn't ever be able to compete in this way, even if they had proprietary foundation models superior to their US counterparts, so they decided to throw sticks into the spokes of the US frontier labs by releasing top open-weight models worth billions of dollars in training cost and thereby devaluing the huge proprietary investments of the US labs.

That is absolutely not "do nothing".

Ehm, sorry, but no, this is not how lithography works. You cannot "hide" functionality in circuitry your machines are producing if your machines' job is to shine light through a mask.

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.