And a calculator outperforms LLMs at multiplication and division...
asgraham · 2026-10-25 18:00:16 UTC
Most people need to be reminded of this. Repeatedly.
everfree · 2026-10-25 18:03:18 UTC
And if you give the LLM a simple calculator MCP, then the calculator's outperformance disappears.
bayindirh · 2026-10-25 18:04:39 UTC
Nope. It'll be more efficient and faster.
everfree · 2026-10-25 18:07:41 UTC
That's just semantics around the word "performance".
We're messaging each other right now inside a heavily sandboxed virtual environment that interprets XML-like markup and runs a text-based JITted scripting language from the 90s. It doesn't really matter that it's extremely inefficient, since it's still effectively instant.
bayindirh · 2026-10-25 18:10:41 UTC
Actually not. Watt per task is a metric bothers more than LLM operators and users. We care about it a lot, and working a lot to measure and improve it, and we're not doing it in context of AI or LLMs.
Effectively instant means nothing, since everything is fast for small n. I love to give this example from a codebase I have worked on during my Ph.D. The problem which took half an hour under Matlab was done in ~40 seconds with mine, however, a thousand-step version of the same problem would take 11 hours. Saving a single second from that 40 second loop would shave my work by ~20 minutes, and this will compound for bigger problems still.
Just because we see the results instantly, doesn't mean it's fast or efficient by any means. It means we might forego optimizing it for sufficiently small n, if we don't care about that part of the code. That's all.
everfree · 2026-10-25 18:17:51 UTC
Generally when I want to use a calculator, I use an app on my phone or computer. The watts per task is abysmal compared to a desk calculator.
The app is less efficient only in an abstract, impractical way.
bayindirh · 2026-10-25 18:25:43 UTC
> The watts per task is abysmal compared to a desk calculator.
It depends on the calculator and task at hand. Consider graphing, integration or any programmable needs, and they might converge. ALU of a processor is pretty efficient at what it does.
> The app is less efficient only in an abstract, impractical way.
Again, depends, as I said above. You tend to brush efficiency away because you only mentally measure time to completion, only, which is understandable.
wrigby · 2026-10-25 18:06:09 UTC
Sure, but what about performance per joule?
everfree · 2026-10-25 18:08:37 UTC
If performance per joule is important in this loosely-defined hypothetical scenario, then it's important.
If it's not, then it's not.
guelo · 2026-10-25 18:20:55 UTC
Imagine performing literally trillions of matrix multiplications in order to figure out the answer to 1 + 2.
everfree · 2026-10-25 18:21:54 UTC
Your computer/phone just performed millions of them in order to display the contents of my comment to you.
cubefox · 2026-10-25 18:27:46 UTC
Pretty much what our brain does.
bayindirh · 2026-10-25 18:03:56 UTC
In a world where masses believe that LLMs are "everything boxes", some reality check is always good.
grumbel · 2026-10-25 18:20:41 UTC
LLMs are pretty good at writing calculators.
bayindirh · 2026-10-25 18:26:41 UTC
I'd rather use a verified one. Scientific calculations on a ALU is tricky. There are many traps and hardware limitations to consider.
ehsankia · 2026-10-25 18:24:18 UTC
LLMs should be for general/high level work. For example, an LLM with the right harness could fetch and use that CNN, or train it's own CNN or other model to use for this task.
The harness in my experience makes a huge different too. Out of curiosity I tried having Gemini chat (with Argon) try to solve a level of this new puzzle game I'm linking (Order of the Sinking Star). It just got in an infinite loop and crashed. Then I try Antigravity with Flash 3.8 and it solved it easily. I saw the harness looked at other sokoban puzzles, coded some stuff, tried to replicate the level, etc. All things that a pure Gemini Chat doesn't really do.
LLMs are great for the high level harness, but if you want to count letters for example, it will still rely on "tools" like a piece of code to do it more reliably. Similarly in the above example, you wouldn't have the LLM directly try to analyze the images, but instead fetch and use the best tool for the job. But that can only be as good as the harness/tools it has access to.
bayindirh · 2026-10-25 18:28:04 UTC
We don't disagree by a great margin. I'm not an anti-LLM person. I'm anti-hype in this case.
jacquesm · 2026-10-25 19:04:28 UTC
The problem is that they are 'everything boxes'. They're the first application that can actually lay claim to being a universal computing aid. What then happens is that people will start using their newfound hammer and before you know it everything becomes a nail, even if for a particular problem there is a better solution you can't beat 'nothing to invest, nothing to learn, get an answer in 10 seconds flat' from a convenience perspective. If I look at the things people use LLMs for I wonder why they take such an unsuitable tool, and then I marvel at the fact that they actually get more-or-less to where they would have gotten with the proper tools, and most likely in less time.
Slide rules displaced tables, calculators displaced slide rules and calculators themselves were displaced for the most part (they are still in use, in education but not nearly as much as they used to be outside of that) by the PC.
LLMs do that sort of thing for just about every information processing aid.
jszymborski · 2026-10-25 18:08:41 UTC
You say this, but the reaction I get from colleagues is increasingly "why bother training new models when you can just ask an LLM?"
Doesn't matter the domain or the task, the answer from some researchers is "LLM" always.
sungam · 2026-10-25 18:37:45 UTC
This does make sense, however in view of the recent maths results and since there are tens of thousands of training images for skin cancer available on the public internet I was expecting the LLMs to perform a lot better than they did
trollbridge · 2026-10-25 19:19:11 UTC
Yeah so that’s why we invented tool calls, and an LLM exercises judgment when it should simply place a tool call to do simple math.
fastball · 2026-10-25 17:56:44 UTC
This isn't really surprising. LLMs are intended to be generally intelligent. They are spiky on the things frontier labs tend to benchmark against (software/math) but are not intended or expected to be great at everything. The general intelligence unlocks new workflows, it does not perfect existing ones.
That being said, I'm sure a frontier LLM could make some improvements to your CNN.
howunfortunate · 2026-10-25 17:58:02 UTC
I'm sorry but as an MLE this is not a remotely useful article, and does not belong on the front page.
It's comparing a fine-tuned CNN to general purpose models on a tiny dataset.
dgellow · 2026-10-25 17:59:58 UTC
There is no such thing as “belong to the front page”. Flag if you think it doesn’t have its place. Otherwise, it’s up to the crowd to decide what they want upvoted. HN front page reflects upvoter interest, nothing else
howunfortunate · 2026-10-25 18:02:29 UTC
The reason I say this is that I suspect many people are reflexively upvoting the title without reading the article. If they read the article they would realize the evidence is flimsy and not really worth reading.
I will not flag it because the post is fine, it's the voters who I believe are acting poorly.
tgv · 2026-10-25 18:03:03 UTC
It's good to be reminded that "frontier models" aren't particularly good at most tasks. They happen to be good at programming, since there's a lot of training data available, and the task has parallels with report writing and story telling. For skin cancer? Probably very little. Also, images of skin cancer probably don't translate that well to a Large Language Model's internal representation.
everfree · 2026-10-25 18:32:41 UTC
It's very strange to me that articles like this get upvoted, because they are coming from this assumption that LLMs are better at everything and that it's notable and newsworthy when there's something that they aren't actually better at.
I don't think we should need to be reminded that frontier models aren't particularly good at most tasks. Just like we shouldn't need to be reminded that a hammer is not particularly good for driving a screw, or writing an essay.
It's an admission of magical thinking about a tool that's made out of the same material of every other digital tool since the invention of computing.
tgv · 2026-10-26 07:01:29 UTC
Unfortunately there's a lot of magical thinking around LLMs.
randcraw · 2026-10-26 19:08:14 UTC
Frankly, I think we very much _do_ need to be reminded that LLMs are in fact _not_ eating the world.
It's at the forebrain of every executive in America that LLMs imbued with RLHF are on the cusp of replacing every job they can imagine, from robot chauffeurs to carpenters to surgeons. But as this paper suggests, the integration of generally capable vision systems with basic tool handling that will be needed to replace the specific skills essential to most human jobs -- especially using only today's frontier models -- still takes us unforeseeably and undeniably far into the realm of sheer fantasy.
ChrisArchitect · 2026-10-25 17:59:33 UTC
fyi CNN: convolutional neural network
starfallg · 2026-10-25 19:52:56 UTC
Yeah, I too was confused for a second.
podgietaru · 2026-10-25 18:00:08 UTC
This doesn't seem that surprising to me? One is tasked with a simple very narrow task. The other has a corpus including billions of other images and pieces of information. It'd seem to me that instinctively one would outperform the other, regardless of age.
4994944995 · 2026-10-25 18:05:03 UTC
Great luckily you are not in charge of a pension fund, thag wkuld be horrible
snitty · 2026-10-25 18:01:31 UTC
This is an example of why I'm a little stumped about why people are excited about Jev-style decision models. For any application at scale it'd be way more accurate to have a dedicated classifier using the right architecture (neural net, bayesian, etc.) LLMs drive the cost of making those models down to near zero.
Just use the LLM to make a thing that's actually good at what you need it to do.
foolswisdom · 2026-10-25 18:04:40 UTC
For some types of applications, Jev is also useful as a stepping stone, you use it for the cases it's most confident so you already get gains from using it, and then collect all the usage to train your specialized model.
nostrebored · 2026-10-25 18:06:06 UTC
You can train gradient boosted trees on jev style features, it is a quick “good enough” approach for a lot of stuff
postepowanieadm · 2026-10-25 18:05:02 UTC
Once you have a hammer everything is a nail.
Y_Y · 2026-10-25 19:10:36 UTC
Even the hammer?
postepowanieadm · 2026-10-25 19:32:42 UTC
Mc Hammer?
heisenbit · 2026-10-25 19:51:05 UTC
True for modern hammers while older had weaker decision models limiting them to finger nails.
howunfortunate · 2026-10-25 18:05:45 UTC
I do agree with you, but I do think you're also making the classic "curse of knowledge" mistake.
You have to know the right words to ask the LLM to make and train a classifier. You and I already know the words. But they are not actually that trivial to learn for an average joe, and people are lazy.
JackSlateur · 2026-10-25 18:07:40 UTC
Just ask the LLM for these words, obviously !
im3w1l · 2026-10-25 18:16:36 UTC
Okay so I just asked it "What question should I be asking you but I don't because I'm not smart enough to think of it?" Response was kind of interesting I have to say.
Natsu · 2026-10-25 18:28:26 UTC
I did this just now, ironically before I even saw this discussion. I ended up questioning the AI about humanism.
jonatron · 2026-10-25 18:43:59 UTC
It gave me a very helpful answer, my project will be improving just because I asked.
alienbaby · 2026-10-25 18:22:21 UTC
That's what I've been doing in areas I lack knowledge tbh. Instead of a half assed attempt at describing what I need, I ask an llm to take my base idea and write it up using industry standard jargon as if I were commissioning a team to do the work. Has been working pretty well so far!
yesco · 2026-10-25 18:41:18 UTC
It's funny you mention this, because I've been thinking lately that all the focus on code quality benchmarks for LLMs seems to miss something. In my experience, LLMs aren't actually all that good at prompting other LLMs, and that's exactly the skill that matters for proper subagent usage.
The corpus of code available to train LLMs on is rich in both volume and quality. The same can't be said for LLM prompts. Prompts only came into existence alongside LLMs themselves, so most of the prompts out there are actually LLM generated, and training on them causes every model to overfit to the same patterns.
LLMs can give clear and concise directives to other LLMs, but only for basic tasks. Beyond that, they frequently overstuff their prompts with too much prose and too much direction, and worse, they often fill them with subtle contradictions.
Of course, there's a spectrum here. Some models turn out to be better at this than others, and I suspect this is what differentiates Fable-type models from the rest, and why vendors have started keeping their models' reasoning confidential.
dev0id · 2026-10-25 19:02:19 UTC
The "agent factories" available to employees at the labs and hyperscalers clearly prove that agent delegation does work. Today, maybe that capacity lies with Fable class models, as you pointed out, but there is no doubt with opus 5.5 that this capability will be available to cheaper models as they get better.
_matthew_ · 2026-10-26 00:28:18 UTC
Quick tip here: Where possible try to trick the model into thinking whatever task it is writing will / could be read and performed by one of your coworkers rather than another agent. It will quickly fall into line and stop writing prompts meant for dumb historic low intelligence LLMs.
staticautomatic · 2026-10-25 18:12:32 UTC
So what? The average joe shouldn't be trying to diagnose people with cancer.
JPLeRouzic · 2026-10-25 18:24:37 UTC
Healthcare is more than having medical knowledge.
Ten years ago, in France, two doctors (one in a professional setting and the other during a private consultation) asked me about a wound I had on my shoulder; obviously I couldn't identify what it was, and they offered no suggestions, so I supposed it was not something important.
It took a visit to a cardiologist—for an entirely different reason—for him to suggest that I rapidly consult a dermatologist.
It was a carcinoma, and surgery removed it.
If ChatGPT had existed back then, this carcinoma would have been removed several years earlier.
gchamonlive · 2026-10-25 18:34:58 UTC
Maybe if chatgpt existed back then you'd have had your carcinoma extracted along with 10 other benign anomalies.
Automation doesn't make up for carelessness.
kaikai · 2026-10-25 18:58:21 UTC
Skin cancer is easily treated with excisions if it’s caught early. Better to have ten small false positives than a single miss.
gchamonlive · 2026-10-25 19:07:59 UTC
Even if addressing each false positive would carrying low but real risk of death or complications?
bell-cot · 2026-10-26 01:27:42 UTC
Is your "low but real" risk comparable to the risk of driving a motorcycle, of riding in a car, or of using the bathroom?
Reasonable treatments for small, non-aggressive skin cancers (or suspected cancers) are extremely low risk. And reasonable practitioners will often suggest that you merely keep an eye on an abnormal spot - because it doesn't look worth the bother of any sort of treatment for now.
gchamonlive · 2026-10-26 12:09:56 UTC
That's not how risk management works, you don't disregard one because another is higher, because risk compose. At the end of the day you'll be in a car accident coming from a surgery you didn't need.
teiferer · 2026-10-25 20:37:30 UTC
Not sure why this is getting downvoted. In its specific case that's quite obviously not a good example because removing benign spots isn't harmful, but overlooking malignant ones is, so there is no downside.
But if we think a little further and generalize then there is great risk (and by extension, harm) to delegate diagnosis and treatment (of health issues in general, including potentially or supposedly fatal ones) to ChatGPT and similar tech. That we'd end up with a net positive is far from obvious.
gchamonlive · 2026-10-25 20:43:30 UTC
I still maintain my point that it isn't harmless to blindly address benign anomalies. Every medical procedure carries risk.
senordevnyc · 2026-10-26 00:17:30 UTC
Your point doesn’t really make a lot of sense. Even with ChatGPT existing and making 90% bad calls, a doctor isn’t likely to just “blindly” be cutting out anomalies.
gchamonlive · 2026-10-26 00:36:33 UTC
As opposed to what OP said?
senordevnyc · 2026-10-26 01:51:25 UTC
Your original comment seemed to imply that if ChatGPT had existed, maybe they’d have had ten benign things removed. But that’s not how it works.
Conversely, ChatGPT can help avoid false negatives.
gchamonlive · 2026-10-26 11:32:57 UTC
It was a carcinoma, and surgery removed it. If ChatGPT had existed back then, this carcinoma would have been removed several years earlier.
My point is against this technical positivism.
red75prime · 2026-10-25 22:03:19 UTC
Obviously, error rate of ChatGPT should be measured by comparing to human diagnoses and when it plateaus, we should investigate a possibility that the number is driven mostly by human errors.
trollbridge · 2026-10-25 19:13:01 UTC
This sounds like a competency problem on the part of the GPs. They’re supposed to make these calls.
devrwoody · 2026-10-25 19:39:28 UTC
Yet here we are
thereforegrin · 2026-10-26 07:04:17 UTC
They are supposed to, but often times they don't and there are no consequences for it.
Current diagnostic setup relies on humans having vast expert knowledge, when in fact it's almost always impossible.
A well trained neural net/LLM will always be better at visual detection because of sheer number of examples it sees during training, compared to a dermatologist which, if lucky will observe no more than 20 patients/day x 270 days a year x 40 years of practice i.e. around 220k samples throughout his lifetime.
MD with other specialties will see significantly less and we are talking about top of the top specialists.
An average MD knows more amount medical diagnostics than than the average Joe, but in principle much less than a well trained AI.
Do we have those kinds of models already? Maybe not yet but, ceteris paribus, we will definitely have them in the future.
IMHO we do have those models already but they aren't available to the public, though their availability would certainly lower cost for healthcare providers.
m11a · 2026-10-25 18:27:01 UTC
I don't believe this is true with current frontier coding agents. Or at least, it's becoming increasingly less true, such that I think it will effectively be nullified in ~6 months.
atomicnumber3 · 2026-10-25 18:51:41 UTC
I'm done waiting 6 months. Just let me know the night before when I don't have to come in to work tomorrow.
trollbridge · 2026-10-25 19:11:35 UTC
Usually you get that info at 4:30 on a Friday.
jeremyjh · 2026-10-25 21:33:11 UTC
Its a bummer because that is also exactly when self-driving cars are going to work. You'll be able to sleep through the commute but won't have to go.
queenkjuul · 2026-10-26 00:37:00 UTC
I can already sleep on the train
sdenton4 · 2026-10-26 02:17:16 UTC
Self driving cars have been working for years... And waymo launched this year in Denver.
If they were working, they'd be able to drive anywhere that a car can be driven.
sdenton4 · 2026-10-27 00:08:06 UTC
They /can/ be driven anywhere a car can be driven. We're seeing a staged, safe rollout for highways and snowy areas Right Now. This isn't cold fusion or quantum computers...
AlexCoventry · 2026-10-26 05:00:46 UTC
Serious people are predicting automated RSI in 6 months this time, FWIW.
misterderpie · 2026-10-25 19:03:15 UTC
I'm gonna cite myself here:
«We came full circle on the problem that also exists with Google Search, and why so many people don't get good results out of it.» [0]
It is not that access to all information was hidden to anyone before, it was harder to find it, sure. Now it can be found easily and aggregated, however, it is not as simple as saying "Do X" and believe that X is correct. Recall the infamous Swing & Product Management meme? [1] The problem is the absence of information you provide, the LLM will have to make a guess of what you mean, much like the human. Likelihoods of this guess being correct depends on the domain and background.
So yes, it'll likely build whatever you ask it (I do think we're there already), but if that matches what you intended to actually get is vastly different. You'll be settling with "Good enough" though and declare it working.
Others already pointed out that 6 months seem to be the constant of distance, irrespective of the date.
The tooling around LLMs is still nascent and, in my opinion, quite poor. You may be able to shotgun easily-falsifiable mathematical proofs with raw compute, but get into the messy world of real data, uncertainty quantification, and a host of other things that go into building real world models, and I think that an LLM plus tooling dedicated to the task plus a human in the loop will open up capabilities not available to an LLM in a chat or development centric software environment.
HPsquared · 2026-10-25 20:50:45 UTC
LLMs are the perfect tool for "finding the right words". They are literally translation machines.
Routine8502 · 2026-10-25 18:06:06 UTC
I mean, it's the pareto principle, right? 80% of the applications require 20% of the intelligence. If I can drop in something without needing to create high quality training data that's good enough, that's great! Skin cancer probably isn't one of those applications.
nostrebored · 2026-10-25 18:06:53 UTC
They make very good classifiers and are easy to fine tune for specific use cases.
weitendorf · 2026-10-25 18:21:56 UTC
it's precisely because you can tune them to do that off a strong base
and because they start off generalized, you can train them against multiple of your workloads (they'll start with some generalized performance/world knowledge about them)
Which allows you to embed proprietary processes/data (world knowledge only you may have) across multiple domains into a model cheaply
sungam · 2026-10-25 18:27:31 UTC
I have been incredibly impressed by LLMs for coding and data analysis and was expecting the LLMs to perform better so I was surprised by the results especially since this is an old model and nowhere near state of the art for skin cancer diagnosis.
dnautics · 2026-10-25 21:50:46 UTC
A transformer trained only on cancer images could probably do better but the old model is trained on a well curated data set to do one thing. A decision model can decide on a much broader universe of things, only a sliver of which is cancer (and probably there's a smaller cancer dataset too)
EagnaIonat · 2026-10-25 18:28:24 UTC
> why people are excited about Jev-style decision models.
I think its a combination of being new to classification models and not using in anger.
LLM Decision models are still relatively new and suffer from a number of issues. Order of choices impacts probability, it starts to break down over 20 classifications and even how you word things impacts probability.
nico · 2026-10-25 21:13:15 UTC
> and not using in anger
Is this a typo? are you saying that this is so new people haven't struggled with Jev enough yet? very interesting
At around 4 classes already LLM-based classifiers (Jev/Laya/GLiNER et al) start falling behind
EagnaIonat · 2026-10-26 07:56:13 UTC
> Is this a typo?
My understanding of the statement is trying to use it in production for the first time. Once you start to actually use decision models beyond something simple you start to see the limitations.
alex_duf · 2026-10-25 18:31:42 UTC
There's a significant engineering cost to having a custom classifier.
An off-the-shelf API has way less friction, if the results are good enough why bother?
dehrmann · 2026-10-25 18:54:13 UTC
For this particular case, it's probably worth it because a dermatologist visit is $200. If I were the NHS or Kaiser, I'd partner with other integrated insurance and service providers to collect as much training data as possible and fund classifier development.
Comments
We're messaging each other right now inside a heavily sandboxed virtual environment that interprets XML-like markup and runs a text-based JITted scripting language from the 90s. It doesn't really matter that it's extremely inefficient, since it's still effectively instant.
Effectively instant means nothing, since everything is fast for small n. I love to give this example from a codebase I have worked on during my Ph.D. The problem which took half an hour under Matlab was done in ~40 seconds with mine, however, a thousand-step version of the same problem would take 11 hours. Saving a single second from that 40 second loop would shave my work by ~20 minutes, and this will compound for bigger problems still.
Just because we see the results instantly, doesn't mean it's fast or efficient by any means. It means we might forego optimizing it for sufficiently small n, if we don't care about that part of the code. That's all.
The app is less efficient only in an abstract, impractical way.
It depends on the calculator and task at hand. Consider graphing, integration or any programmable needs, and they might converge. ALU of a processor is pretty efficient at what it does.
> The app is less efficient only in an abstract, impractical way.
Again, depends, as I said above. You tend to brush efficiency away because you only mentally measure time to completion, only, which is understandable.
If it's not, then it's not.
The harness in my experience makes a huge different too. Out of curiosity I tried having Gemini chat (with Argon) try to solve a level of this new puzzle game I'm linking (Order of the Sinking Star). It just got in an infinite loop and crashed. Then I try Antigravity with Flash 3.8 and it solved it easily. I saw the harness looked at other sokoban puzzles, coded some stuff, tried to replicate the level, etc. All things that a pure Gemini Chat doesn't really do.
LLMs are great for the high level harness, but if you want to count letters for example, it will still rely on "tools" like a piece of code to do it more reliably. Similarly in the above example, you wouldn't have the LLM directly try to analyze the images, but instead fetch and use the best tool for the job. But that can only be as good as the harness/tools it has access to.
Slide rules displaced tables, calculators displaced slide rules and calculators themselves were displaced for the most part (they are still in use, in education but not nearly as much as they used to be outside of that) by the PC.
LLMs do that sort of thing for just about every information processing aid.
Doesn't matter the domain or the task, the answer from some researchers is "LLM" always.
That being said, I'm sure a frontier LLM could make some improvements to your CNN.
It's comparing a fine-tuned CNN to general purpose models on a tiny dataset.
I will not flag it because the post is fine, it's the voters who I believe are acting poorly.
I don't think we should need to be reminded that frontier models aren't particularly good at most tasks. Just like we shouldn't need to be reminded that a hammer is not particularly good for driving a screw, or writing an essay.
It's an admission of magical thinking about a tool that's made out of the same material of every other digital tool since the invention of computing.
It's at the forebrain of every executive in America that LLMs imbued with RLHF are on the cusp of replacing every job they can imagine, from robot chauffeurs to carpenters to surgeons. But as this paper suggests, the integration of generally capable vision systems with basic tool handling that will be needed to replace the specific skills essential to most human jobs -- especially using only today's frontier models -- still takes us unforeseeably and undeniably far into the realm of sheer fantasy.
Just use the LLM to make a thing that's actually good at what you need it to do.
You have to know the right words to ask the LLM to make and train a classifier. You and I already know the words. But they are not actually that trivial to learn for an average joe, and people are lazy.
The corpus of code available to train LLMs on is rich in both volume and quality. The same can't be said for LLM prompts. Prompts only came into existence alongside LLMs themselves, so most of the prompts out there are actually LLM generated, and training on them causes every model to overfit to the same patterns.
LLMs can give clear and concise directives to other LLMs, but only for basic tasks. Beyond that, they frequently overstuff their prompts with too much prose and too much direction, and worse, they often fill them with subtle contradictions.
Of course, there's a spectrum here. Some models turn out to be better at this than others, and I suspect this is what differentiates Fable-type models from the rest, and why vendors have started keeping their models' reasoning confidential.
Ten years ago, in France, two doctors (one in a professional setting and the other during a private consultation) asked me about a wound I had on my shoulder; obviously I couldn't identify what it was, and they offered no suggestions, so I supposed it was not something important.
It took a visit to a cardiologist—for an entirely different reason—for him to suggest that I rapidly consult a dermatologist.
It was a carcinoma, and surgery removed it. If ChatGPT had existed back then, this carcinoma would have been removed several years earlier.
Automation doesn't make up for carelessness.
Reasonable treatments for small, non-aggressive skin cancers (or suspected cancers) are extremely low risk. And reasonable practitioners will often suggest that you merely keep an eye on an abnormal spot - because it doesn't look worth the bother of any sort of treatment for now.
But if we think a little further and generalize then there is great risk (and by extension, harm) to delegate diagnosis and treatment (of health issues in general, including potentially or supposedly fatal ones) to ChatGPT and similar tech. That we'd end up with a net positive is far from obvious.
Conversely, ChatGPT can help avoid false negatives.
Current diagnostic setup relies on humans having vast expert knowledge, when in fact it's almost always impossible.
A well trained neural net/LLM will always be better at visual detection because of sheer number of examples it sees during training, compared to a dermatologist which, if lucky will observe no more than 20 patients/day x 270 days a year x 40 years of practice i.e. around 220k samples throughout his lifetime.
MD with other specialties will see significantly less and we are talking about top of the top specialists.
An average MD knows more amount medical diagnostics than than the average Joe, but in principle much less than a well trained AI.
Do we have those kinds of models already? Maybe not yet but, ceteris paribus, we will definitely have them in the future.
IMHO we do have those models already but they aren't available to the public, though their availability would certainly lower cost for healthcare providers.
https://waymo.com/blog/2025/10/creating-an-all-weather-drive...
«We came full circle on the problem that also exists with Google Search, and why so many people don't get good results out of it.» [0] It is not that access to all information was hidden to anyone before, it was harder to find it, sure. Now it can be found easily and aggregated, however, it is not as simple as saying "Do X" and believe that X is correct. Recall the infamous Swing & Product Management meme? [1] The problem is the absence of information you provide, the LLM will have to make a guess of what you mean, much like the human. Likelihoods of this guess being correct depends on the domain and background. So yes, it'll likely build whatever you ask it (I do think we're there already), but if that matches what you intended to actually get is vastly different. You'll be settling with "Good enough" though and declare it working.
Others already pointed out that 6 months seem to be the constant of distance, irrespective of the date.
[0] - https://news.ycombinator.com/item?id=50063427#50063744
[1] - https://www.productftw.com/productftw-2-the-tire-swing-carto...
and because they start off generalized, you can train them against multiple of your workloads (they'll start with some generalized performance/world knowledge about them)
Which allows you to embed proprietary processes/data (world knowledge only you may have) across multiple domains into a model cheaply
I think its a combination of being new to classification models and not using in anger.
LLM Decision models are still relatively new and suffer from a number of issues. Order of choices impacts probability, it starts to break down over 20 classifications and even how you word things impacts probability.
Is this a typo? are you saying that this is so new people haven't struggled with Jev enough yet? very interesting
> it starts to break down over 20 classifications
Yes, I recently ran a benchmark on exactly that: https://jeffyclassify.com/blog/when-llms-fail-at-classificat...
At around 4 classes already LLM-based classifiers (Jev/Laya/GLiNER et al) start falling behind
My understanding of the statement is trying to use it in production for the first time. Once you start to actually use decision models beyond something simple you start to see the limitations.
An off-the-shelf API has way less friction, if the results are good enough why bother?