Why we built ChessWarp
The problem with standard chess tactics training is not the puzzles. The puzzles are fine. The problem is what they announce before you start.
Open any major tactics app. The interface loads, positions a board, and tells you, implicitly or explicitly, that there is a winning move here. Your job is to find it. This is a reasonable thing to ask of a player. It is also the wrong thing to practice.
In a real game, no one tells you. You sit down across from an opponent and the position develops the way positions develop. At some point the board contains a fork, or a pin, or a hanging piece, or it does not. Whether you see it is not a function of whether you can calculate well once you are looking in the right direction. It is a function of whether you looked in that direction at all. The moment of recognition — the glance that says something is here — is a skill that exists before calculation, separate from it, and trainable with the right kind of practice. Standard apps do not train it.
The research on expert chess players has been consistent on this for fifty years. Adriaan de Groot's work in the 1940s showed that grandmasters do not calculate more variations than intermediate players. They see fewer, better ones, because the board presents itself to them differently. Chase and Simon's chunking research in the 1970s showed that the expert advantage is perceptual. Meaningful configurations of pieces are stored as units, recognized on sight, pulled from memory rather than reconstructed by search. What separates 2000 from 1600 is not calculation speed. It is the size and quality of the pattern library.
That is what ChessWarp trains.
Every position in the app is a real tactic from over-the-board play, checked by Stockfish at depth 22 before it enters the corpus. We do not use generated positions because generated positions do not have the structure that makes real patterns recognizable. Recognition collapses on positions that do not look like what a game actually produces. The corpus has to be real or the training does not transfer.
The key design decision was not to announce the tactic. A player arrives at a position and reads the board. They decide whether something is there. Then they find it, or confirm it is quiet. The moment of recognition — the trigger — is what we are training, and you cannot train a trigger if you bypass it by telling the player it needs to be pulled.
After each position the app shows what was there: which piece carried the threat, which square it claimed, what the engine saw at each depth. The explanation is not decoration. It is the second half of the training loop. Recognition gets faster when the pattern is named and seen clearly after the fact. Reps build the pattern; the explanation makes it stick.
The dashboard tracks recognition speed, not just accuracy. Median milliseconds to correct answer per motif is a better signal than a percentage correct. Solve-time falls as a chunk forms. You can watch the skill developing in the numbers, which is different from a score that goes up and down depending on which positions came up that day.
Two things are live when this is written. The core lesson loop: real positions, graded by motif and difficulty, with the full explanation after each solve. And the discrimination mode: a mixed feed of real winning tactics and real quiet positions, where the first task is deciding which kind you are looking at before you try to find anything. That second mode is where the trigger gets trained most directly.
We are not the first people to notice this gap. There are two small apps that attempt something like it. Neither has a vetted corpus at scale, and neither has the curriculum structure to move a player from 1600 toward 2000 in a principled way. We thought the thing was worth building properly.
Chess is one of the few skill domains where the underlying theory of expertise is actually understood. We know what the gap between strong and intermediate looks like at the perceptual level. We know what makes the pattern library grow. We built a tool around that knowledge. Most chess products do not. They optimize for engagement instead: streaks, points, the next puzzle loading fast. ChessWarp optimizes for one thing. The climb.
Related project
ChessWarp
Train the eye, not the move list.
Other notes
The decisions that don't iterate
Most things you build are reversible. A few are not. Telling them apart is harder than it sounds, and getting it wrong is what most software regret turns out to be.
What 'honest software' means in practice
We use the phrase a lot. It is easy to say. It is harder to specify.
Why we built Vyzrly
College admissions has always been a black box. We wanted to make it a little more honest.
When AI is the wrong tool
The reflex to reach for AI on every problem is a symptom of taste failure, not technical sophistication.
Why we built Glossem
Product copy lives inside code. That is a problem for everyone who is not an engineer.
Why we built USACO Tutor
Competitive programming builds a kind of thinking that matters. We wanted to make that more accessible.
Why we built Break the Test
The SAT has seven versions in circulation. Serious students burn through them in a month. The bigger problem is that even unlimited practice would not fix the thing that actually costs them points.