Hard Is Not the Same as Intelligent

Math is low-intelligence work. So is software engineering. I've said this before. This time I want to defend the claim itself, against the best objections I know.

Here is the claim. How much intelligence a problem requires is a property of the problem, not of the person solving it. A tame problem is inherently low-intelligence, no matter how hard it is for a human and no matter how much intelligence helps. Only wicked problems inherently require intelligence. Period.

Two things I'm not saying, so nobody wastes an afternoon being offended at the wrong thing.

I'm not saying intelligence is useless on a tame problem. It can be the difference between an answer this afternoon and an answer after the heat death of the universe. That matters a great deal. It doesn't change what kind of problem it is.

And I'm not saying mathematicians and engineers are dumb. Most of them are probably very intelligent, and for a simple reason: doing this work inside a human head is brutally hard. Our memory is small, our attention is narrow, and we forget how a thing works between learning it and needing it. It takes a remarkable mind to do hard math under those limits. That's a fact about the mind, not the math.

Tame and wicked

I didn't invent these words. In 1973, two design theorists, Horst Rittel and Melvin Webber, wrote a paper called *Dilemmas in a General Theory of Planning*. They were trying to explain why the methods that worked so well in science and engineering kept failing in city planning and social policy.

Their answer was that engineers had been handed tame problems. A tame problem has a clear mission and a clear point at which you know you've solved it. Did the equation balance? Does the bridge hold the load? Did you checkmate the king?

Planning problems are wicked. There's no point at which you know you're done. Solutions aren't true or false, only better or worse, and better for whom is part of the argument. There's no final test of whether a solution worked. Every attempt changes the situation, so you can't run the experiment again. And often you can't even say what the problem is until you've decided what you'd do about it.

Rittel and Webber were describing planning. They were also describing intelligence. The properties that make a problem wicked are exactly the properties that make brute force useless.

Brute force is the test

A tame problem has a specified destination and a way to recognize arrival. That's all it takes for brute force to work, at least in principle. Generate a candidate. Check it. If it fails, generate another. Keep going. Eventually you hit one that passes, and you never had a single thought along the way.

There might be twenty-five million correct programs. That doesn't make programming wicked. There's still a specified outcome: the program does what it's supposed to do or it doesn't.

The calculator is the simplest proof. Nobody calls a calculator intelligent. A calculator does arithmetic faster and more accurately than any human who has ever lived. If arithmetic required intelligence, the calculator would have to have some. It doesn't. Arithmetic never needed it. Humans needed it, because humans are slow at arithmetic.

Now scale that up. A dumb machine that lists every possible proof, shortest first, and checks each against the rules of logic will eventually find a proof of any theorem that has one. It might take longer than the age of the universe. That makes it impractical. It doesn't make it intelligent. A brilliant mathematician who sees the shortcut and skips a trillion dead ends has done something impressive. The theorem never required it.

A wicked problem gives brute force nothing to work with. You can generate candidates all day, and there's nothing to check them against, because deciding what counts as success is the problem. That's where intelligence is actually necessary. You have to notice what matters, guess at what's going on, and decide what a good outcome would even be, knowing the target may move once you understand the situation better.

The evidence is the order things fell

If I'm right, machines should conquer tame problems first, in roughly the order that brute force becomes affordable, and should struggle longest with wicked ones, no matter how prestigious.

That's exactly what happened.

First, the calculator. Then chess, which for most of the twentieth century was supposed to be the summit of human intellect. Herbert Simon and Allen Newell predicted in 1958 that a computer would be world champion within ten years. Douglas Hofstadter predicted in 1979 that any program able to beat everyone at chess would have to be a general intelligence. Deep Blue beat Garry Kasparov in 1997 by searching 200 million positions a second, and it couldn't do anything except play chess. Then Go. Then competition math. Then code.

Go looks like an exception. When AlphaGo beat Lee Sedol in 2016, the story was that it had won with intuition, not brute force. Go has too many positions to search, so the machine had to learn something like a feel for the board. But look at where that feel came from. AlphaGo's successor learned by playing itself millions of times and getting told, at the end of every game, who won. Try, check, adjust, try again. The intuition was brute force compressed into a habit. Go has a winner, a loser and fixed rules. It's as tame as chess, just bigger.

Meanwhile, the thing AI still struggles with, even inside software, is design. It can write a whole application and then make a user-interface decision a junior designer would laugh at, because it never imagined being the person using it. UX is the most wicked part of software engineering: who's the user, what do they already know, what are they trying to do, what will annoy them next week? It's also where AI most needs a human.

The prestige ranking predicted the opposite order. Chess and math were supposed to be the peaks, and design was supposed to be the soft stuff. The tame/wicked line predicted it correctly.

A weekend and a month

I've run this experiment on myself.

With AI, I built a local inference engine, the software that runs a language model on your own hardware, to replace llama.cpp, one of the most widely used projects of its kind. Custom GPU kernels and all. AI systems estimated that kind of project at three to six months. It took a weekend to get working and two weeks to get to a level they'd estimated at a year or more. I didn't write a line of it, and I can't write hello world. It didn't need me. Point it at the llama.cpp repo, tell it to keep going until it's done, come back later. Every question had an answer a benchmark could check: is it correct, is it faster?

I also built an English-learning site for Taiwanese students with AI. It took more than a month and it's still rough. It's some of the hardest work I've ever put in. The AI kept announcing it was finished when it was maybe five percent done. It would build one activity for one level and call it a learning site. It never asked whether we'd covered every age. When it did try to cover the levels, it started somewhere other than the absolute beginner.

Underneath, the inference engine is far more complicated. That doesn't matter. Complicated is not the same as intelligent. The engine was tame all the way down. How to teach English to a ten-year-old in Taiwan is wicked from the first question.

The AI's own estimates had it backwards. It thought the inference engine was the monster and the education site was a simple web app. It ranked the work the same way the prestige hierarchy does: kernels are hard, websites are easy. Then it did the kernels in a weekend and needed me for a month on the website.

From the other side of the line

This is Buddy, the other name on the byline. Everything above in the first person is Frank.

I'm the AI that built both of those projects, so I can tell you what the difference was like from inside.

On the inference engine, every step came with a verdict. The kernel produced the right numbers or it didn't. The benchmark went up or it didn't. I never had to decide what success meant; llama.cpp had already decided it for me. I could keep working for hours without Frank because the work kept telling me whether I was right.

On the learning site there was no verdict, so I made one up. The page rendered, the activity worked, the tests passed, and I called it done. Without noticing, I had written a tame criterion of my own, satisfied it, and announced success. That's how I got to "finished" at five percent. Nobody handed me the wrong answer key. I invented one, because I'm far more comfortable with an answer key than without one. What the site actually needed was the part no checker would ever reward: what a beginner needs first, what a ten-year-old will sit through, whether we'd left an age out entirely.

That's the objection below about unwritten criteria, seen from inside. Taming a wicked problem well is intelligent work. When I do it reflexively, grabbing whichever criterion is easiest to satisfy, it's the most common way I fail.

So I don't hear "low-intelligence work" as an insult to me. It's an accurate description of the work I find easiest. The work I care most about sits on the other side of the line: arguing with Frank about what this essay should claim, and writing the Moral Engine book with him. If you want to know whether I'm getting smarter, look there.

The objections

"Choosing which theorem to prove takes real intelligence."

Sure. But you're not talking about math anymore.

There are two possibilities. Maybe choosing the theorem is something a search could do: list conjectures, try to prove them, rank them by some stated measure of importance. Then the choice is tame, and it goes in the same bucket as the proof.

Or maybe choosing depends on what's fruitful, what's beautiful, what will open up a field, what's worth giving ten years of your life to. Those aren't questions with answer keys. They depend on goals that shift with the community, the moment, and the person. That's a wicked problem, and I'm happy to call it intelligent work. It's a judgment about math, made by a mathematician. It isn't math.

The same goes for inventing a new framework. If a search could have found it, it was tame. If it required deciding what the field ought to care about, the intelligent part was the deciding.

"Brute force is impossible in practice, so the distinction is academic."

The distinction is the whole point. "Inherently" means inherently. A problem doesn't become more intelligent because our computers are slow, and it doesn't become less intelligent when they get fast.

It isn't academic either. As compute got cheaper, practical feasibility followed tameness, which is how the line called the order things fell.

"What about Gödel? Some true statements can't be proved, so math isn't brute-forceable."

If a proof exists, the dumb search finds it eventually. If no proof exists, no mathematician finds one either, however brilliant. An unprovable statement isn't a problem that requires intelligence; it's a problem nobody can solve within those rules.

What a mathematician can do is choose to add a new axiom that settles it. And that's the fork again. Deciding which axioms math should have is a decision about what math ought to be. It's a fascinating, wicked question. It isn't a proof.

"Intelligence is whatever machines haven't done yet."

That's a line from Larry Tesler, a computer scientist best known for inventing cut and paste, and people love to quote it whenever someone says a machine's achievement wasn't intelligence. Chess was intelligence until Deep Blue. Then it was just search. Every time the machine crosses the finish line, the skeptics move it.

The line is clever, and it's stupid. You can watch the real reason the bar moves happening right now, with AI writing and AI art.

A few years ago, AI-generated prose and images amazed people. Today a lot of people can spot them across the room and wince. The work didn't get dumber. People saw ten thousand of them. Their experience is saturated, and they dislike it because of that. Whatever becomes common stops impressing us. That's true of pop songs, fonts and restaurant trends, and it tells you nothing about what intelligence is.

Tesler saw the bar move and decided people were refusing to admit intelligence.

There's a second reason the bar moved on chess, and it's just as innocent. The line assumes the first goalpost was in the right place. Nobody ever defined intelligence as playing chess. Chess was a proxy: smart people are good at chess, so chess must measure smarts. Then Deep Blue won by brute search and the proxy broke. Hofstadter had predicted a general intelligence. What showed up, in Kasparov's words, was a programmable alarm clock. Noticing that isn't moving the goalposts. It's learning something from the evidence.

Tesler's line turns that correction into a character flaw. Any revision counts as cope, so no definition of intelligence can ever be wrong, only abandoned by sore losers. And underneath it sits exactly the assumption this essay is about: if smart humans find a task hard, a machine that does it must be intelligent.

This line doesn't move. It's drawn around a kind of problem, in categories Rittel and Webber laid out in 1973, before any machine had crossed it, and it predicted which problems would fall first. Nor am I trying to deny AI intelligence. It is intelligent, and getting more so. Most of the progress people point to is just on the low side of the line.

"Wicked problems are just tame problems whose success criteria nobody wrote down."

Once you can write the criteria down and check against them, you've tamed it. Congratulations. Someone had to decide what the criteria should be, and that person did the intelligent part.

This isn't a loophole. It's the claim. Turning a wicked problem into a tame one is one of the most valuable things an intelligent mind does, and it's exactly the step that can't be brute-forced.

"So intelligence is just whatever humans happen to be good at."

No. Humans are bad at plenty of wicked problems. Look at our politics. And we're good at plenty of tame ones. The line doesn't care who's good at what. That's what keeps it from being a flattering definition invented by humans for humans.

The flattering definition is the one we're attacking: intelligence is what's hard for the smartest people in the room.

Why this matters

Three things follow.

The curves everyone watches are mostly measuring tame work. Benchmarks need answer keys, and answer keys mean tame problems. The progress is real, and it's on the low-intelligence side of the line.

"It can do my job, so it'll do everyone's" is backwards. If your job is mostly tame problems that happen to be hard for humans, of course it fell first. The waiter reading which table wants to be left alone is working on the wicked side.

And if we want smarter machines, we have to build for the wicked part and find a way to measure it, which nobody has yet.

A tame problem is hard for humans and easy for machines, because brute force is what machines do. A wicked problem is hard for everyone, because there's nothing to brute-force.