Agentic work feels fast. The agent is always typing, the diffs scroll, something is happening every second you are at the keyboard. That feeling is real, and it is not the same thing as being fast. Feeling fast and being fast are two different measurements, and the distance between them is the entire reason to keep a record. The gap is not a hunch. In a randomized trial, 16 experienced open-source developers worked through 246 real tasks on repositories they had spent years in, with AI tools allowed on some tasks and withheld on others. They forecast the AI would make them 24% faster. After the study, having done the work, they still estimated it had made them about 20% faster. Measured against the clock, allowing the AI made them 19% slower. The felt direction and the measured direction pointed opposite ways, for skilled people, on code they knew well. That is not proof that AI makes everyone slower. It does not. It is evidence that the feeling is an unreliable instrument, and that you should not navigate by it alone. Speed is real, but narrow and uneven Plenty of measured speedups are real. In a controlled task where developers built an HTTP server in JavaScript from scratch, the group with an AI assistant finished 55.8% faster. That is the number that gets quoted. It is also a small, greenfield, self-contained task, the exact shape of problem where the assistant shines and the exact shape least like the tangled, half-built thing you usually open in the morning. A real result on a narrow task travels badly into a feeling about every task. The gains are uneven, too. Across three field experiments pooling 4,867 developers, an AI assistant raised completed tasks by about 26%, and the lift was uneven: both adoption and gains concentrated among the less experienced developers, while the senior ones gained substantially less. And in the 2024 DORA report, AI adoption raised individuals' sense of productivity and flow while team delivery did not improve. The report associates a 25% rise in adoption with a small drop in delivery throughput and stability. The felt-faster at one desk did not become faster shipping for the team. The record is the corrective, not flattery So the honest position is not that you are wrong to feel fast. It is that the feeling cannot settle the question, so keep something that can. That is what the record is for. It does not flatter the pace. It exists because the pace can lie. Seorak keeps the plain facts of each session and shows them side by side. Whether a run reached a commit. How long it ran and what it cost, derived from the token count on your own machine. Where it stalled or looped. And, slowest of all, line survival: whether the lines a session changed were still on the branch later, or gone. None of these is the feeling. Each of them is the other half of the comparison the feeling cannot make on its own. The record is not there to confirm you were fast. It is there because the feeling of fast and the fact of fast are different measurements, and only one of them keeps score. Held next to each other, a fast-feeling session and a session that produced lasting work are sometimes the same session and sometimes not. The point of the record is that you can tell which, instead of assuming. Where this stops being true Seorak does not measure your felt-vs-actual gap, and it would be dishonest to say it does. It never asks how fast a session felt. It has no read on your perception, only on what the sessions left behind. The studies above had a control group and a stopwatch. The record has neither. What it offers is narrower: the actual half of the comparison, kept plainly enough that you can hold your own sense of a session up against it and notice when the two disagree. That noticing is the whole benefit. Not a verdict that you were slow. A standing reason to check, on the days when the typing felt like progress, whether the branch agreed.