Spaced repetition for programmers who quit Anki

Developers are the ideal audience for spaced repetition and the worst audience for Anki. The problem is the contract, not the algorithm. Here is a guilt-free SRS design, with the actual scheduler we ship.

Programmers should be the ideal spaced repetition users. The job is an endless stream of things worth remembering: language vocabulary if you are learning one, standard library corners, the difference between two consistency models, that flag you look up every single time. And the research behind spacing is as solid as learning research gets: reviewing something right before you would forget it beats massed review by a wide margin, and being tested on it beats rereading it.

Yet almost every developer I know has the same Anki story. Enthusiastic start, a deck built over a weekend, three good weeks, one busy sprint, and then an app icon they avoid opening because it says 437 cards are due.

We ship a spaced repetition system inside Unwait, and designing it forced us to figure out where that story goes wrong. The conclusion: the algorithm was never the problem. The contract is.

The review debt spiral

Classic SRS tools are built on an implicit contract: you will show up every day, and the scheduler decides how much you owe. When you keep the contract, it works beautifully. When you miss days, the due pile compounds, because every skipped day's reviews stay owed while new ones mature.

For someone with a daily commute ritual, that contract is fine. A developer's time is shaped differently: irregular, interrupt-driven, occasionally consumed whole by an incident or a deadline. Miss four days during a launch and the app greets you with a number that reads as a debt. Most people do not pay debts to a flashcard app. They quit, and the quitting feels like personal failure when it was actually a scheduling assumption that never matched their life.

The spacing effect does not require the debt. Nothing about memory science says the 437 must be surfaced as an obligation. That part is a product decision, and it is the wrong one for anyone whose schedule has variance.

The contract that survives variance

Our SRS runs on three rules, and none of them involve owing anything.

Due-first, never due-must. When a card is served and some cards are past due, due cards win over new ones. That single priority rule captures most of the value of scheduling: the things closest to being forgotten get seen first. But there is no due counter, no backlog screen, and missing a week changes nothing except which card you see next. The queue is an ordering, not a ledger.

Only completed cards enter the rotation. A card schedules its next review only when you actually flipped it and moved on. Glanced at it and skipped? It comes back in ten minutes, unscored. Skipping is not a grade and does not touch the schedule, because half-attention data is noise and punishing it teaches people to stop skipping honestly.

Sessions are finite. One card per sitting in our case, since a sitting is an AI agent wait. However you build it: bounded sessions, no autoplay, no "12 more to finish today". The session ends because it ends, not because you cleared a quota.

The scheduler can be boring

Here is the entire vocabulary scheduler we ship, as a table:

No ease factor, no per-card difficulty model, no grading buttons. Concept cards are even simpler: read the explanation today, and the card re-enters as a quiz three days later, every time. News cards never repeat at all, because not everything deserves reviewing, and admitting that per card type beats pretending one policy fits everything.

SM-2 and its descendants tune intervals per card based on graded recall quality. That precision is real, and it is wasted when exposure is irregular, which for our users it always is: reviews happen during waits, and some days have thirty waits while others have none. When the arrival of review opportunities is random, an optimal interval and a decent interval land on the same day in practice. A fixed ladder captures the compounding gaps that make spacing work, and it can be explained in one sentence, which means users trust it instead of gaming it.

If you are building your own: start with the ladder, add sophistication only when you have retention data saying the ladder is the bottleneck. We log every review and have yet to see evidence it is.

Steal the time instead of scheduling it

The deeper reason developers quit Anki is that it asks for a new time slot in a schedule that has none. The fix we bet the product on: do not schedule review time, attach it to dead time that already exists.

A developer working with AI coding agents waits dozens of times a day, thirty seconds to a few minutes per turn, at exactly the moment when starting anything real is not worth it. That is spaced repetition's perfect slot: too short to context-switch into work, long enough for one card, and recurring all day without being asked for. Unwait's whole design is wiring the scheduler above into those gaps, so review happens during time that was going to be lost to a phone glance anyway.

You do not need our app to use the idea. Waiting for CI, for a build, for a deploy to go green: any of those can hold one card. The unit that survives is one, honestly completed, guilt-free card, many times a day, and a scheduler humble enough to work with whatever shows up.

If you are staying with Anki

All of the above translates into settings, if Anki is where your decks live: cap new cards per day well below what feels ambitious, cap the review limit too so a comeback day is not a punishment day, suspend cards without ceremony the moment one annoys you, and delete decks that stopped mattering. The guilt is optional. It was always optional.