Two developers describe how they work. Same coding agent, same model, same editor, same terminal, roughly the same week of updates. From the outside they are now indistinguishable. They are not remotely the same developer, and nothing in the description says why. This is a recent problem. For most of the history of the craft, what you used carried real information about you. Tools were unevenly distributed, took effort to learn, and cost something to adopt. Naming yours told a reader where you had spent that effort. That was never a complete picture, but it was a real one. Coding agents broke the arrangement quickly. They arrived nearly free, nearly everywhere, on nearly the same schedule, and they are good at the part that used to take the longest to learn. What you can say about your setup has converged. The list is easy to produce, easy to copy, and increasingly the same list. The description stopped separating anyone Notice what actually happened. The tools did not stop mattering. They stopped distinguishing, which is a different claim. An agent that writes competent code for anyone who asks is enormously useful and tells a reader almost nothing about the person who asked. A description everyone can produce carries no information about any of them, however true each one is. If a developer's public account of themselves is mostly an inventory, the inventory is now close to noise. The awkward part is that the inventory is often all there is. It is what fits in a bio, what recruiters filter on, what a profile page has space for. So the thing that stopped carrying information is also the thing most likely to be asked for. What is still different Plenty is still different. It just moved. Which problems you take on. Choosing a problem is most of the work, and no agent chooses it for you. What you decide before you start. The constraints you set, the approaches you rule out, the thing you are unwilling to trade away. When you step in. A run that has stopped helping keeps going until somebody stops it. Noticing early is a skill, and it is not the agent's. What you throw away. Deleting work an agent produced is a judgment about quality, and it is one of the few judgments that cannot be delegated to the thing being judged. What you do when it goes wrong. Retry, rewrite the request, or abandon the approach entirely. These are three different developers. What holds up. Weeks later, on the branch, some of it is still there and some of it is not. None of those are equipment. They are decisions, made repeatedly, under conditions only you can see. They are also, unhelpfully, invisible. A decision leaves no artifact. What it leaves is an aftermath. The tools converged. The decisions did not. The difficulty is that a tool is easy to name and a decision is not. What a record can honestly see This is the point where a product like this one is supposed to claim it captures judgment. It does not, and the claim would be easy to make and wrong. Seorak keeps a small set of facts about each coding-agent session, derived on your own machine: whether a run reached a commit, how long it ran, what it cost by token count, where it stalled or looped, and whether the lines it changed were still on the branch some days later. Code and prompts stay put. What ships is the count, never the thing that was counted. Set that against the list above and the mismatch is obvious. "How long a run went before it was stopped" is not "when you step in." It is a number that a decision left behind. "Lines still on the branch" is not "what holds up in the sense that matters." It is a narrow proxy that is revert-blind and sees one branch. So the record does not recover the decisions. It does something smaller and more defensible: it accumulates the residue of a lot of them, in one place, over enough time that patterns are at least visible to the person who made them. A month of sessions is not a portrait of judgment. It is a month of aftermaths, and the person who lived through them is the only reader who can supply what is missing. Where this stops being true Three limits, plainly. The first is that the record cannot tell a good decision from a lucky one. A session stopped at forty minutes might be discipline or a phone call. The numbers are identical. The second is that difficulty does not register. Two sessions with the same duration, cost, and survival can be a rename and a genuinely hard piece of work. Nothing in what is captured distinguishes them, and nothing in what is captured could. The third is the largest. Everything above is evidence about sessions, and sessions are only where some of the work happens. Thinking, reading, choosing not to build something, and abandoning an approach before the agent is opened are all real work that leaves no session at all. A record that only sees sessions will always under-represent the developer who does the most before starting one. That is worth stating clearly rather than working around, because the alternative is a product that quietly treats the measurable slice as the whole and calls the result a person. The part worth keeping The honest version of this is not that a session record reveals who you are. It is narrower and more useful than that. When the tools stop distinguishing people, the difference has to be argued from somewhere, and the two available places are assertion and evidence. Assertion is what the inventory already was. Evidence is thinner than assertion, harder to produce, and much harder to fake, and it is at least about what happened rather than about what someone says about themselves. A stack listing says what you have. It was never going to say what you did with it, and it has finally stopped pretending otherwise.