Centaur Chess Already Told You Where You Fit Next to AI
By Derek Neighbors on October 20, 2026
In 2005, an online chess site ran a tournament with almost no rules, an early test of what people now call centaur chess: humans and computers playing as one team. Anyone could enter. Teams could use any computers and any chess engines they wanted. Grandmasters signed up with strong engines. So did teams running serious hardware.
Two American amateurs won it. Steven Cramton and Zackary Stephen were club players with three ordinary computers. They beat grandmasters who had engines of their own.
Garry Kasparov, who had lost to Deep Blue eight years earlier and then spent years promoting human-plus-machine chess, wrote the line everyone still quotes: “Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.”
You have heard some version of that line in an AI keynote. It lands as comfort: you will be fine, because you plus the machine beats the machine alone.
The keynote usually stops there, right before the part of the story that tells you where you fit.
The Myth: Human Plus AI Always Wins
There are two versions of this myth, and they point in opposite directions.
The first is the keynote version. Human plus machine beats machine alone, so the safe move is to keep a person on every step. Put someone in the loop. Review everything the model touches. That way you get the speed and keep the judgment, and the centaur wins.
The second version is the one people tell once they hear how the chess story ended. Engines kept getting stronger, and the human-plus-engine teams stopped adding anything. So the human is done. The model wins, and you should get out of its way.
Both sound reasonable. The first one matches what happened in 2005, and the second matches what happened after. They are both wrong about the same thing, which is what the human was doing in the first place.
What Won the 2005 Centaur Chess Tournament
Read Kasparov’s whole account and the human contribution looks narrow. Cramton and Stephen did not out-think grandmasters about chess. Kasparov said their edge was skill at “manipulating and ‘coaching’” their computers to look very deeply into positions. They ran several engines at once. When the engines disagreed, they had a way to decide which one to trust and where to make the machines look harder.
So the winning human contribution was a process for sorting what the machines produced. Chess knowledge mattered less than that. The grandmasters knew more chess and had a worse way of using the machines. I made the same point about software teams when AI exposes the process you never had. The model raises the ceiling, and your process decides whether you reach it.
Then the engines kept improving. Today most strong players will tell you a human adds little or nothing to the moves a top engine picks. In correspondence chess, where engines are allowed and players get days per move, most games at the top end in draws. Everyone has the same engines, and the engines agree.
Chess had something most work does not have, which is a written score. Every position can be evaluated. Checkmate is unambiguous. Once a machine could score positions better than any person, it could also sort its own options better than any person, and the centaur’s job at the board went away. The human edge went somewhere else, and that is the part of the story worth your time.
What Each Myth Costs You
The keynote myth puts people in the wrong places. A team that believes it parks a reviewer on every step, including the ones the model already scores better than a person. The tests pass or fail, and the type checker and the linter have already weighed in. Then a human reads the same diff after all three and approves it, slower, and after the third week, without really reading it. I wrote about where that goes in the human in the loop who is not driving. The person ends up rubber-stamping the parts the machine scored, and they are too tired by then to make the call only a person can make.
The mirror myth does the opposite damage. A team that believes the human is done hands the model the sorts nobody has written a score for. Which of these four designs do we build? What do we tell the customer about the delay? The model will answer every one of those, fluently, with the most likely answer. Aiming for the most likely answer works when a test can check it. Without a test, the most likely answer is the average one, and you shipped the average on purpose.
One team has too many people in the loop and the other has too few, and both skipped the same work: figuring out which decisions have a written score and which do not.
Where You Fit
You fit where nobody has written down the score.
It helps to sort your work into three kinds of decisions.
| Kind of decision | Examples | Who chooses |
|---|---|---|
| Has a written score | Tests, evals, type checks, a rubric | The model |
| No written score yet | Which design to build, which draft sounds like you, what this customer will love | You |
| A promise | Money moving, who a user is, what a contract says | Plain code that does the same thing every time |
Most of this piece is about the second kind, because that is where people get it wrong in both directions.
The second kind covers more of your week than it sounds. Which of five reasonable ways to split a service can this team still maintain in a year? Which of twelve drafts of a launch email sounds like you? Then come the people calls, like what this particular customer will love, as opposed to what customers in general say they want, or how far to bend on scope for a client you plan to keep for ten years.
Nobody has a test for those. There is no eval suite that knows your team’s tolerance for complexity or your customer’s patience. The model can generate excellent options for every one of them, and it should. It can generate more options in a minute than you could in a week. What it cannot do is score them against a standard that lives in your head and nowhere else.
That standard is what people mean by taste: knowing which good option fits here, now, for these people, when no test can tell you. Taste aims at what will serve the customer who uses the thing and the engineer who has to maintain it next year. That aim is why one person’s taste can be better than another’s, and why yours can be wrong. You build it the slow way, by seeing what worked, what aged badly, and what you regretted shipping, and you can keep building it.
I made the upstream version of this argument when code got cheap and building did not. Deciding whether a thing should exist at all is the first sort. This piece is about all the sorts after it. Every time the model hands you a pile of good options, someone has to pick, and the one who picks is the one doing the scarce work.
How to Work Where the Score Is Unwritten
1. Ask for five options instead of one. The default way people use a model is to ask for an answer and take it. That gives you the most likely answer, and the most likely answer tends toward the generic one. When I ask Claude for one way to restructure a messy module, I get something reasonable. When I ask for four, each with what it costs and what it makes harder later, the second or third is often better, and sometimes the right answer takes a piece from two of them. Generating options is nearly free now, so ask for more of them.
2. Write down every score you can, then let the model sort. Every time you turn a judgment into a test, an eval, a type, or a short rubric, you move that sort off your desk and onto the model’s. It will apply the rubric at three in the morning without getting tired, and it will apply it the same way every time. If you can say “a good error message names the field, says what was wrong, and says what to do next,” write that down and stop reviewing error messages yourself. The rubric is still your judgment, in writing. When a bad error message gets through, that is your miss, and the fix is a better rubric. The chess story says the machine wins wherever the score is written, so write more scores and let it win.
3. Say why you picked, in one line. When you choose option three, put one sentence in the pull request or the design doc saying why. “Picked the boring queue over the clever one because this team has two people on-call.” Someone can learn from a written reason, argue with it, or check it six months later, and none of that happens with a habit that lives in your head and leaves when you do. Writing the reason down also shows you when your reasons repeat, and a reason that repeats is ready to become a rubric (see step 2).
4. Keep the promises in the harness. Promises are the third kind of decision. Money moving, who a user is, what a contract says you will do, whether a payment runs twice. Those belong in plain code you control, with tests, not in a model’s judgment call. I wrote about this in solving it with code first. The model can write that code, and should, but the promise lives in the code and its tests.
5. Move when the model starts picking what you would pick. Once you have written down your reasons and given the model the context behind them, its top option starts matching yours. Watch for the day that happens every time for a whole category of decision. Write that rule down and hand the whole category over. Then go find the next sort that has no score yet. The edge kept moving in chess, and it will keep moving in your work. What you control is the habit: hand over each decision you have figured out, whatever pace the edge sets, and spend the time you get back on the ones nobody has figured out yet.
Final Thoughts
Centaur chess gets told as a story about humans and machines teaming up, and the ending gets told as a story about humans losing. Both versions miss what the two amateurs in 2005 were doing. They had a better way of sorting what the machines produced, and that skill was worth more than knowing more chess.
At the chessboard, the machines eventually learned to sort for themselves, because chess has a score written down to the last pawn. Most of your work does not. Your job sits in the decisions where nobody has written the standard yet, where you pick the option you will still be glad you shipped. Go fast everywhere else. Let the model generate everything, let it choose wherever a test can judge, and put your own attention on the picks only you can make.
If you want to work with builders who use AI for everything and still argue hard about which option to ship, MasteryLab is where that happens.
FAQ
What is centaur chess?
Centaur chess, also called advanced or freestyle chess, is chess where a human plays with one or more computer engines helping. Garry Kasparov popularized it after losing to Deep Blue in 1997. The famous result came in a 2005 freestyle tournament, where two amateur players using three ordinary computers beat grandmasters who also had engines. Kasparov credited their better process for using the machines.
Do humans plus AI still beat AI at chess?
Not in any way that matters at the top. Engines got strong enough that most strong players will tell you a human adds little or nothing to the moves an engine picks. In correspondence chess, where engines are allowed, most top games end in draws. Chess has a fully written score, so once machines could score positions better than people, they could also choose better.
What does taste mean in AI-assisted work?
Taste is knowing which of several good options fits this team, this customer, and this moment when no test can tell you. AI can generate dozens of workable options in seconds. Picking the one you will still be glad you shipped in a year, and being able to say why, is the skill that is worth more as generation gets cheaper.
How do I decide what to let AI choose?
Ask whether the score is written down. If there is a test, an eval, a type check, or a clear rubric, let the model generate and choose, and move fast. If the right answer depends on things nobody has written down yet, like what a customer will love or what the team can maintain, the model generates and you choose. Keep anything you have to promise, like money, identity, and contracts, in plain code you control.
