Skip to content
AtomicReps

Every reader starts at issue one

The Retrieval.

A letter for engineers who want to be able to explain the code they ship. Every issue carries one study worth knowing about, one idea worth a name, and one question you answer from memory in about thirty seconds. You start at issue one the day you subscribe, not whatever went out last Tuesday.

01Start the sequenceNo account
Which track

One confirmation email first. Nothing else until you click it.

The start
Issue one, always
The rhythm
Every other week
The ask
An email address
[02]The specimenIssue 01, in full

This is the first thing that arrives. All of it.

Nothing is held back for subscribers. If it is not worth your inbox, you should be able to tell before you hand it over.

01The unlearning clock

You made every API call fire at once. What changed under load?

You are faster than ever. The question nobody asks is for how long.

The Exhibit

You are faster with the AI on. That is real, and nobody is asking you to pretend otherwise. It was never the interesting question. The interesting question is what happens to the part of the craft you have stopped doing yourself. A 666-person study found that the more people offloaded their thinking to AI, the lower they scored on critical thinking. The study.

Survey data, correlational, so read it as a pattern and not a proof. But you know the pattern from the inside: the code ships faster while the part of you that used to reason it out sits quiet. Fast today. The question is how long the skill stays yours when the tool is the one doing the reps.

The study

Comprehension Debt

Comprehension debt: the gap between what gets shipped and what the team can still reason about.

A skill you stop using does not wait at full strength for you to come back. It fades while the work keeps shipping on schedule, and you only find out the day the tool is wrong and the reasoning is suddenly yours to do. The speed is real. The craft underneath it is the part you are spending.

The idea

The Rep

Thirty seconds:

You take code that calls an API once per item, sequentially, and change it to fire every call at once. Same output, faster. What did you change about behavior under load, and when does it break?

The answer

Sequential became fully concurrent. Every call is scheduled at once and the natural backpressure of doing them one at a time is gone. The platform may still cap how many actually run in parallel, but you have given up the pacing the sequential version provided for free. Faster until the volume trips a rate limit, exhausts sockets or file descriptors, drains the connection pool, or buries the downstream service. The fix is bounded concurrency: run them in parallel but cap how many are in flight at once, instead of releasing all of them unbounded.

About thirty seconds

[03]Every issue so far24 published

The whole archive, open.

[04]Where the evidence comes fromGraded and sourced

Every study we cite is on the research page, with its caveats beside it.

The letter quotes the number and links the paper. When a result did not replicate, or the effect was smaller than the headline, that is printed at the same weight as the claim. You should be able to check us.

Read the research

Start the sequence

You read issue one already. Twelve more are written.

Every other week, one study, one idea worth a name, and one question you answer from memory. Nobody joins mid-conversation.

Which track

One confirmation email first. Nothing else until you click it.