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.
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.
> 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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
«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.
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.
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
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.
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)
> 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.
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.
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.
I don't know, a lot of the things we used to take for granted as "hard" just aren't anymore. Writing a parser for a compiler? It used to be an endeavor that took several days, now an LLM will do it in 20 mins.
Same for annoying training jobs, with sufficient data you can probably let an LLM loose on it in autotrain mode and it will come back with a decent classifier.
Training classifiers is shockingly easy nowadays with LLMs. This is probably the biggest single piece of bespoke software I ship that I didn’t used to.
We have in the works a classifier for if a prospective customer will be long term profitable or not. This changes everything.
> We have in the works a classifier for if a prospective customer will be long term profitable or not
I'm curious, why do you use a classifier for long-term profitability? Wouldn't predicting expected lifetime profit with a forecasting model be more meaningful than just predicting whether a customer will be profitable or not?
That's awful for the misclassified customers who will not get the attention they need. Not to mention that people talk and if you treat some customers badly, the others (the ones from the top of your pile) might reconsider working with you. That doesn't automatically make this a bad idea, but I would tread very carefully.
> Just use the LLM to make a thing that's actually good at what you need it to do.
This is the end state of most imagined use cases for “agentic” software IMO. Use the AI to build software, with a classifier or LLM as the expansion joint in awkward spots.
For example, a client want a classifier to decide to make a go/no go decision on roofing jobs based on weather. The end result doesn’t use LLMs at all, but does use a lot of other techniques including human feedback when it makes the wrong call.
(Now the work crew gets the decision at 5 AM instead of 5:30 and the guy making the decision doesn’t have to wake up at all.)
I think it means the person making the decision does not have to get up early anymore in order to make a decision. The people receiving the decision still receive the decision, and a bit earlier.
The frustrating part about an LLM is at a fundamental level it's designed to do the wrong thing, it's designed to provide an answer for things it can't do, e.g. one argument I've been in recently at work is someone using it to summarise numerical data. They've a raw data spreadsheet they're putting into ChatGPT and asking it to produce a report in a particular style. So the LLM is doing its job, predicting the tokens to emit, and not actually doing mathematical analysis of the underlying data.
I had a team proudly show me how they were feeding their dashboard data into an LLM to predict growth needs, instead of doing basic linear regression or any number of pre-existing basic statistical analysis. The part that depressed me the most on that was it was a bunch of engineers that did it, the people you'd most hope would understand what an LLM is/does.
For numerical work, there’s no reason to assume the computation is happening in the LLM. All frontier models could handily write a Python script to do linear regression then report the result, so the quality of the responses here depends entirely on the prompt + harness.
Definitely. I’ve found Cursor + Grok to be the best budget models for this type of tool use, although I’ve yet to try out the latest Anthropic ones.
You can go “here’s a spreadsheet of some data, do a thing to it” and it’ll go through, have it plan out the type of calculations you want to do, and it’ll write you a program to parse your sheet, calculate what you want, then output an result sheet.
The key to good results with minimal effort seems to be the planning modes to me, combined with the /goal command. A little bit of validation before implementation goes a long way.
+1. I noticed ChatGPT now pulls out a calculator or writes a script instead of hallucinating numbers. Initially it was terrible, but recently it seems pretty good... that said, if you're doing serious work with this you should probably double check. And if you're doing repeated work, obviously get it to write a script or formula instead of doing 1-offs.
They’re very much trained to do this, in fact. Even Step 3.5 Flash, a medium sized open model from way earlier this year is trained to use python to calculate answers on the fly :)
It makes sense to use an LLM to write the queries when exploring data, but if you are building a dashboard that’s going to be used repeatedly, you should save the queries so they can be validated and improved over time. The LLM shouldn’t be rewriting a new query every time you open the dashboard.
These days I wouldn't be surprised if the models are smart enough to get the analysis correct.
However sometimes I think that AI use shows a revealed preference around things. In this case, the actual data just ... maybe never mattered to them at all? People wanted a shiny chart and they got a shiny chart.
I'm building a little side business with LLMs doing 90%+ of the work, and this includes numerical analysis of revenue to figure out where to direct effort.
Today the problem you're mentioning is easily avoided if you are aware by ensuring you direct the agents to build tools for anything deterministic.
Every week "we" (myself and Claude) start by analysing revenue from the previous week. Claude will do some manual proposals but they will be based on analysis done by a deterministic script. It will then run workflows that are increasingly calling deterministic scripts - every week another few decision points the agent used to do (and that I had to then manually vet) gets replaced by deterministic scripts.
It is what allows what is a very low margin opportunity to work - it is scaling with the total amount of manual labour and total token use remaining near constant. It's an opportunity that I won't go into much detail about because the margins are thin and the moat narrow and it's basically only viable because of this approach of setting a tiny budget where ~1/3 of it or so is dedicated to systematically eliminating manual and LLM work from the process.
Even so, I expect the opportunity to actually extract profit from it is going to be short-lived - the moat will eventually evaporate if LLMs keep getting cheaper and better in favour of people "just" asking an LLM to do the whole thing end to end.
So on one hand I agree with you - there are lots of things that'd be better automated with scripts, and where there might well always continue to be efficiencies you can extract by turning things into deterministic scripts instead. On the other hand, LLMs are already so cheap for a lot of things that it increasingly doesn't matter, and good enough that where it does matter they will increasingly also just write tools themselves if you ask them and sometimes - and likely increasingly so over time - without even being asked.
Yeah like the other say it depends on the harness. "into chatgpt" could mean many things. It's likely not predicting the next tokens to emit but rather thinking "okay the data is in format x i need to map it to y, and also this is a good fit for statistical model z" and then writing and executing a python script that runs whatever statistical model on the inputs and then produces some other output file that it then uses to produce a report.
That being said, the correct way would be to just use the LLM to produce the script, validate it themselves (often times there's something very minor wrong), and then use that script next time instead of an LLM to rewrite the same script over and over every time you need to produce a report.
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?
People vastly underrate the patience of people to learn and setup a classifier. Jev is one API call. Training a good classifier is hard.
Same for annoying training jobs, with sufficient data you can probably let an LLM loose on it in autotrain mode and it will come back with a decent classifier.
Heh this used to be an interview question I gave. You’d be surprised how far people would get in 30 minutes.
With enough marketing you can sell anything. Also a decent way to make a product is to do the hard part for someone else.
I've been training classifiers for ten years, it used to be hard. Now it's hard to do really well but it's trivial to do well enough.
100% this is a very good insight
We have in the works a classifier for if a prospective customer will be long term profitable or not. This changes everything.
I'm curious, why do you use a classifier for long-term profitability? Wouldn't predicting expected lifetime profit with a forecasting model be more meaningful than just predicting whether a customer will be profitable or not?
Eventually we hope to identify ones who are going to be lifetime duds.
I don’t have a deep understanding of this topic, but wouldn’t you also need a good amount of relevant data to train on?
This is the end state of most imagined use cases for “agentic” software IMO. Use the AI to build software, with a classifier or LLM as the expansion joint in awkward spots.
For example, a client want a classifier to decide to make a go/no go decision on roofing jobs based on weather. The end result doesn’t use LLMs at all, but does use a lot of other techniques including human feedback when it makes the wrong call.
(Now the work crew gets the decision at 5 AM instead of 5:30 and the guy making the decision doesn’t have to wake up at all.)
I had a team proudly show me how they were feeding their dashboard data into an LLM to predict growth needs, instead of doing basic linear regression or any number of pre-existing basic statistical analysis. The part that depressed me the most on that was it was a bunch of engineers that did it, the people you'd most hope would understand what an LLM is/does.
You can go “here’s a spreadsheet of some data, do a thing to it” and it’ll go through, have it plan out the type of calculations you want to do, and it’ll write you a program to parse your sheet, calculate what you want, then output an result sheet.
The key to good results with minimal effort seems to be the planning modes to me, combined with the /goal command. A little bit of validation before implementation goes a long way.
I'm mostly starting to have some success telling TPMs and engineers to ask chatgpt to give them appropriate code that generates more accurate answers.
However sometimes I think that AI use shows a revealed preference around things. In this case, the actual data just ... maybe never mattered to them at all? People wanted a shiny chart and they got a shiny chart.
Today the problem you're mentioning is easily avoided if you are aware by ensuring you direct the agents to build tools for anything deterministic.
Every week "we" (myself and Claude) start by analysing revenue from the previous week. Claude will do some manual proposals but they will be based on analysis done by a deterministic script. It will then run workflows that are increasingly calling deterministic scripts - every week another few decision points the agent used to do (and that I had to then manually vet) gets replaced by deterministic scripts.
It is what allows what is a very low margin opportunity to work - it is scaling with the total amount of manual labour and total token use remaining near constant. It's an opportunity that I won't go into much detail about because the margins are thin and the moat narrow and it's basically only viable because of this approach of setting a tiny budget where ~1/3 of it or so is dedicated to systematically eliminating manual and LLM work from the process.
Even so, I expect the opportunity to actually extract profit from it is going to be short-lived - the moat will eventually evaporate if LLMs keep getting cheaper and better in favour of people "just" asking an LLM to do the whole thing end to end.
So on one hand I agree with you - there are lots of things that'd be better automated with scripts, and where there might well always continue to be efficiencies you can extract by turning things into deterministic scripts instead. On the other hand, LLMs are already so cheap for a lot of things that it increasingly doesn't matter, and good enough that where it does matter they will increasingly also just write tools themselves if you ask them and sometimes - and likely increasingly so over time - without even being asked.
That being said, the correct way would be to just use the LLM to produce the script, validate it themselves (often times there's something very minor wrong), and then use that script next time instead of an LLM to rewrite the same script over and over every time you need to produce a report.
subnanosecond response times
model fits on CPU