Yeah, it was cool watching those four $146,000,000/each RS-25 engines return to the landing pad. Stupid capitalists.

It's not peanuts at all, which is precisely why there is also competition in the medical industry to reduce radiologists, and push more work onto larger centralized corporately hosted radiology mills.

They're not even close.
LLMs outperform doctors in diagnostics. ImageNets do not outperform them clearly*.

Radiologists today are being "replaced" (in that more work is piled onto less radiologists now augmented by AI)
That is still replacement.

* there are some cases where ImageNets do outperform radiologists, and there are also cases where they do significantly poorly.
VLMs also have a very noted problem in the way that they're trained that leads them to producing reports that are quite bad when evaluated by other radiologists (implying the trainers aren't using radiologists to train the output)

It's inherently different.
The ImageNet is trained to recognize images, and pair it with contextual information given in its scanning.
I.e., it is- at best- distilled from the knowledge of rad techs.

Indeed. Many ImageNets have been trained on more dogs than I will ever see in my lifetime, and will still- a few percent of the time- call them a duck.

I find it funny that you start off talking about how doctors don't stay up on medicine (which is very true), and then point out that these aren't LLMs.
LLMs used in diagnostics regularly outperform doctors for precisely the reason you mentioned.

However, image classifiers match doctors at best, and are sometimes much worse in the case of false positives, most likely due to their inability to consider broader context than the image they're looking at.
This doesn't mean they don't have a place, but it's not real clear what it is yet.
Studies are mixed. Sometimes doctors augmented with AI do worse (suspected anti-AI bias), sometimes they do considerably better. Sometimes doctors alone outperform AI (critical miss rate on low sensitivity scans), sometimes worse- critical miss rate on high-sensitive scans.

Doctors are not liable for missing something on a scan. They're liable for negligence in interpreting a scan.

Correct.

Like any network, how good it is is a mix of how much data you throw at it, and how many parameters it is.
Large ImageNets cost millions to train.

Not an accusation in the slightest. Was giving you an out for disclaiming authorship of that post ;)
It is impressively ignorant.

You showed evidence of popularity of a thing within a tiny non-representative sample in a discussion about feature parity. Put scientifically- you showed nothing.
As mentioned, no amount of Claude Code's codebase is going to make you give OpenCode more github stars. Idiots are led by a different metric than code.

Problem with "AI and digital images" is that classifier is only as good as its training data.
The cost to train goes up dramatically the more training data you give it. This means there is a financial incentive to not train on edge cases, which means your AI *will not catch them.*

Like all things, it's not the tech I fear. It's the executives in charge of monetizing it.

False positives, in fact, are the cause of all kinds of human misery- often leading to unneeded surgeries, and sometimes surgeries with very serious consequences.
They're a part of why there are screening guidelines.

Never-mind that. I had no idea they had hall effect thrusters on them.
Cool. And ya, that's almost certainly what it was. I assumed they were using some kind of monopropellant and was going to point the finger that way.

Why would there be a COPV on a Starlink sat?

They don't, and it isn't.
There is no "Kessler event". You're imagining some shit like the movie Gravity, but that's not Kessler Syndrome. It's just good graphics.

Kessler Syndrome is merely the state of increasing orbital debris from ongoing impacts being greater than that reduced by atmospheric drag.
By some measures, we're already well within a Kessler Syndrome. Station Keeping sats, or sats that can otherwise dodge debris are just fine.

To quote an AC quoting a wise man,

Some kind of hypothetical future situation- a "Super Kessler" where even mobile sats cannot possibly dodge the amount of debris up there is just bad science fiction.

lol- the data points, which are like pointing out the sky is blue except for 1 of them, are not what was referred to, you illiterate buffoon.
It are the fluff opinions- the sound bites- that are devoid of fact.
Read again:

This is why elementary school is important.

Christ. Only in 2026 would I have to do this.

1) We weren't talking about a popularity contest. Though I do imagine Claude Code definitely had the most mentions by respondents to the, uhhh /me glances at notes, "pragmaticengineer.com survey". OpenClaw has more stars on github than software with tens of millions more in installed base than it.
2) After this comment, I'm not sure you should ever reply to anything technical ever again.

If there's anything that can be learned here, it's that people like you love having opinions. Even when shit like "My sense of it is that this code is not the LLM itself, it is the infrastructure and interface layer between the user and the LLM." has escaped your fingers on a public forum. Did an LLM write that? Be honest.

Claude and OpenCode have near feature-parity. I don't think anything in Claude Code's codebase is going to help it win your github stars. Maybe more flashy lights and buzzwords might, though.

Context engineering for modern agents. The distinction is what you can imagine. In context engineering, you're dynamically altering the entire context window instead of just prompts added to them.

As for "of value", perhaps the system and agent prompts. That's a pretty fast-moving target. But since Claude has locked down Opus access to just API keys for external tools, those are really just for trying to glean ideas from.

The competition is easily keeping up with Claude Code. It's their LLM that's impressive, not their terminal application.
Even OpenCode is keeping up well with Claude Code, and it works with any LLM.

Incorrect.

There is nothing in it that should demand high performance, I agree.
But Claude Code is never waiting on your input. It's waiting on its frame timer to expire so it can render the next frame of its interface. Because decisions... were made... my people of questionable wisdom.

It's a real time React renderer that runs at 60fps.