Setting the stage
I need to give a name to something, a name for a problem I keep waiting for the “AI” community to solve. I'm not sure that community even knows the problem is there. Maybe. Maybe they're just calling it something else. But I call it “The Triage Problem.”
If you go to the hospital emergency room (ER), it might be because you are bleeding to death. Or are having a heart attack. Or any of a number of other things that require rapid expert intervention. And yet, at no ER I've visited am I greeted by that hospital's finest doctors. First I see a triage nurse. Why is that?
Truth is, people go to the ER for many reasons, not all of which needs the hospital's highest paid employees. The triage nurse who meets you is not incompetent. Quite the opposite. They are highly specialized to the specific need of rapidly deciding whether you need advanced care, or just something simple, so that easy problems can be handled more cheaply and urgent problems get used only when needed.
Childish antics and world resources
There's pressure these days to do everything with “AI”. Some are just curious to try, many have fear of missing out (FOMO). It's almost as if “AI” tech is trying to compete single-handedly with all other tech in the world. FOMO has become a specific marketing strategy by the “AI” industry, in order to grab market in a realm that is really a missionary sale, an attempt not just to push product but the very idea of a product, where there is not a specific immediate need.
While I get the fun involved in this, and the immense number of dollars, this seems wrong to me. The virtual gold rush that is the “AI” industry is also, sadly, a rush to consume planetary resources at enormous scale at a time when humanity can least afford it (and without paying for it).
A huge amount has been said about the potential benefits alleged for “AI” use, so I won't waste our time here talking about that. My concern at this moment is not about whether it's potentially useful in a bunch of places, but rather whether it's efficient in all of those places.
Efficiency would only hold them back, entrepreneurs might tell you, if they weren't utterly engrossed in the activity of putting us all at risk. Competition on efficiency comes later.
The alleged cost of capability
What's bothering me is not an issue of raw capability, even though the public brawl between tech giants trying to out-macho each other seems to always go to there. The issues are several, different, and subtle.
Let's start with power consumption. I feel strongly that Large Language Models (LLMs), the core technology that many today call “AI”, take too much power overall. This is a strong claim for me to make, seated off to the side while others work hard on this issue day-to-day. So why do I think it?
I'm going to offer a couple of examples that influence my intuition so you can see why it might not take detailed knowledge of the industry to challenge the claim that an enormous computer is needed to do this:
First, a lot of what these “AI” systems do, even the hard parts, could probably be done by a tool with not a huge amount more smarts than a squirrel in my yard, who seems happy to run on sunflower seeds meant for birds. No tool yet devised by the best minds the world can throw at it has made a device that will assure the birds get those seeds and the squirrels don't. Those squirrels may not speak English, but they are very smart. Honestly, I think they probably could speak English, they just don't see the need. So are they smarter, or am I? They seem happier in their world than many of us are in ours.
Second, and similarly, a 2-year-old child, fed only things like applesauce, manages to learn language from examples with no training. Humans are smart from day 1. They do not learn to be intelligent. They learn to use the intelligence they came with. They lack knowledge, but not capability. They do not ask us to deplete the world's resources building data centers in exchange for showing their potential. And humans already know how to compute many algorithms efficiently, so telling me that LLMs are just as good if we'd just burn more of the world's precious resources to let somebody prove it does not impress me.
Examples like this are why I'm convinced that even if more giant data centers help make “AI” smarter, that cannot be the only way to do it. And it isn't a good price.
A hatred of syntax
It's important, too, that we understand why people want natural language. It isn't just one reason. Part of what they want is to describe complex problems and have the answers by some intelligent magic. But part of it is that they just hate command syntax. These are actually two different things.
There is an almost-obsession with overcoming programming syntax, as if command line and programming syntax is some sort of cruel torture that callous programmers have inflicted on the world and this finally is the chance to put them in their place. I actually think there's something to the ire, but the proposed cure comes with a lot of issues.
Syntax may not be the world's biggest computational problem, but it is an impediment to access and non-programmers really do place great value on not having to deal with it. Never mind that by some accounts, human language has syntax far more complex than the things they're getting rid of. The point is that our human brains are well-evolved to dealing with natural language syntax and not similarly evolved to be happy with more formal syntaxes, in spite of the utility skilled programmers find in them.
It's a problem that non-programmers see clearly, but that experienced programmers find almost invisible. Users are comforted by natural language.
Formal languages still matter
Formal language syntaxes create important efficiencies exactly because they are precise, reproducible, and useful. But the market signal is clear: It needs to be behind the scenes. Natural language does not make a good programming language, but it makes a good requirements language. And prompts are really more about requirements than programming.
I can tell you for sure that we are not better off if we discard mathematical notation and say “whatever LLMs do internally is better.” There are few things I take such a strong stand on, but the issue of how to express ideas is something I've spent a lifetime thinking about, so I am not going to equivocate on this. There is room to disagree with me, certainly, but I am ready to take on that challenge if anyone wants to.
My posture is this: Let the LLM figure out interesting ways to write programs, but then after that make sure the thing they write is precise, deterministic, reproducible, and testable. You do not want to fly an airplane whose wing is designed by an LLM. You might, however, want to fly an airplane whose wing was designed by a program that had an assist from an LLM during writing. That's very different.
Generations of programmers did not learn algorithmic complexity just as a bridge strategy to LLM-speak. We learned it because the time and space complexity analysis it provides creates a kind of informational physics that no amount of LLM hype can overcome. It matters to do a database access with an index, not without. It matters to prefer O(n) or at least O(n*log(n)) solutions over O(n^2) solutions. LLMs cannot change that. They might sometimes get faster answers, but if so only because of excessive resource consumption—far too much computation thrown at problems that, in most cases, are unlikely to merit it.
Triage is too fundamental to “fix” later
But now we come to the crux of the matter.
In essence, The Triage Problem exists because an LLM both solves a human factors problem in the design of user interfaces (a desire to use familiar language, not formal language) and implicates the need for higher-than-necessary capability in the triage nurse.
A decision about whether to use the world-resource-consuming engine as the initial triage is not something that can be easily changed later. That sets a certain expectation, risking that the entire design will build in presumptions of this much power. Imagine if early triage nurses were senior surgeons.
It wouldn't just make them smarter, the entire architecture of the waiting room might change to take advantage of things they might want to do right there while waiting. And if someone later suggested that was inefficient, it might be hard to remove because by then other parts of the hospital might be relying on not seeing things they thought that early doctor would filter out.
Any decision to use the most advanced LLM as a triage element would call into question what triage was. There would be pressure to do serious intervention earlier in the system, and with different available information and tools. It would enable use of and perhaps come to actually need knowledge of or permissions for APIs even before resolving the simple question “can this be done more simply?”
Among other things, such an architecture violates the conventional wisdom of assigning roles the least necessary privilege to get their job done.
If enough consideration is given to the problem, my hope is that something less expensive could do the initial dispatch. Perhaps something with more modest capabilities, but still focused on the need. That doesn't sound impossible.
But, possible or not, it won't happen by accident. Someone will have to see The Triage Problem as its own kind of issue with special constraints and take those constraints seriously.
What's being questioned
When people like me say “you're not doing it right,” all the “AI” moguls hear, or maybe all they seem to want to respond to, is “you won't get there from here.” Perhaps it'd be too embarrassing for them to admit, that we might be saying “going the way you're going is too risky, or too expensive, or both.”
Risk is almost their compass arrow. They have more taste for it than we do. Ethics and prudence is a game for the weak, they would surely tell you. So a dangerous overuse of resources continues.
And as they proceed in this dangerous direction, they say, in a voice that carries no more believability than a small child who is very proud of an achievement but oblivious to its horrifying cost, “See? See? I can do it this way!”
But it was never an issue of “can you?” It was an issue of how. At this point we're in a position to say more specifically that The Triage Problem is really about this set of constraints:
- We want to solve simple problems without invoking the fully general engine and fall back to fully general solutions only if cheap solutions fail.
- We want something on the front that understands natural language.
- If the thing on the front end is an LLM, then we can't get cheap access to an efficient problem solver. You can't wrap simplicity around complexity. You can't take something that always expends many resources and have it pretend to be the cheap things.
The stakes are high and the clock is ticking
The solution the industry has converged on is just “Send everything to an LLM. Let it call out to something cheap if it feels that's best.” As far as I'm concerned, that's not a solution because it doesn't satisfy the constraining requirements we've laid out for The Triage Problem.
Many are working on different harnesses that call LLMs in other ways. Maybe one of those will solve the triage problem. I'm not saying they won't. I kind of hope they will. I'm just naming the thing that I'll get excited about if they do it.
Because somewhere in my life, someone taught me that when you see a problem, you do these steps in this order to solve it:
- See if there is a cached solution. If so, use it.
- See if there is a well-known method. If so, use it.
- Having exhausted on-hand information and on-hand techniques for cranking out information, only then invoke general-purpose reasoning.
This small program is everything about minimizing expenditure of resource. So invoking general purpose reasoning to execute it misses the point.
I honestly feel human survival depends on understanding that smaller solutions are needed, not bigger ones.
Author’s Notes:
If you got value from this post, please “Share” it.
The images were generated with help from abacus.ai's ChatLLM (Claude Opus 4.8 and GPT Image 2.5), with light post-processing in Gimp to produce a tighter thumbnail of one of the graphics and to reduce the fuller images in size for faster web download.




