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. Each issue has one research study, one engineering concept and one question to 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.

[02]The specimenIssue 01, in full

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

Nothing is held back for subscribers. If the letter is not worth reading, you should be able to tell before you give us your email address.

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 your own work: the code ships faster while you no longer reason it out yourself. Fast today. The question is how long you keep the skill when the tool does the practice for you.

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 stay at full strength until you return to it. The skill 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. What you are losing is the skill underneath it.

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 hits a rate limit, exhausts sockets or file descriptors, drains the connection pool, or overloads 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]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

Get the next issue by email.

Every other week. Each issue has one research study, one engineering concept and one question to answer from memory. Every reader starts at issue one.

Which track

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