The cost of investigating the same thing twice

There is a category of engineering work that no tracker records and no dashboard shows: finding out something the team already found out.

It does not appear as a ticket. It appears as a ticket taking longer than it should. Nobody logs "spent ninety minutes establishing that the webhook retries are the reason for the duplicate rows, which Priya established in March." They log the fix.

Which means the cost is real, recurring, and structurally invisible. You cannot manage it, because nothing measures it, and nothing measures it because each individual instance looks exactly like ordinary work.

What repetition actually looks like

Four shapes, roughly in order of how often we see them.

Across people. One engineer investigates, fixes, moves on. Three months later someone else hits an adjacent symptom and starts from the beginning. The first engineer is two desks away and has no idea it is happening.

Across repositories. The finding was about a shared client, or an environment variable, or a deployment quirk, and it applies to four services. It was learned in one of them. The other three will each learn it separately.

Across time, same person. Less discussed and very common. You solved this. You remember there was something. You do not remember what. You re-derive it in twenty minutes and feel mildly stupid, which is the wrong response, because expecting a person to hold that is unreasonable.

Across agents. The newest one and the most expensive per instance. Every session starts cold. An agent that spent forty tool calls mapping how the payment flow handles idempotency retains none of it, and the next session spends forty tool calls again. See why coding agents forget for the mechanism.

Why the usual answers do not hold

Every team has already tried the obvious things, which is worth taking seriously rather than dismissing. The obvious things have real failure modes.

Write better documentation. The problem is not the writing, it is the retrieval. Findings are written at the moment they are least interesting, when the bug is fixed and the writer is done, and they are needed months later by someone who does not know the finding exists and therefore cannot search for it. Search requires knowing roughly what you are looking for. That is precisely what the person re-investigating does not have.

Search the issue tracker. Sometimes this works, and when it does it is because someone happened to phrase the symptom the same way twice. Trackers are organised around work items, not around facts about the system, and the reasoning that would help is usually in a comment thread on a closed issue with a title that describes the ticket rather than the discovery.

Ask in Slack. This works better than either, which is a strong statement about the other two. It also depends on the right person being present, awake and willing to be interrupted, it produces an answer visible to whoever was in that channel that day, and the answer is gone in a week.

Assign an owner. Concentrates the knowledge in one person and makes the team's throughput depend on their availability. It converts repeated investigation into a queue at that person's desk.

Agents changed the shape

Two things happened at once when teams started using coding agents seriously.

The first is that investigation got cheaper, which is good, and the volume of it went up, which is mixed. When finding out is cheap, you find out more often, including things somebody already found out. Cheap repetition is still repetition, and it is now happening continuously rather than occasionally.

The second is that the loss became total. A person who investigates retains a fraction of it, unreliably, and can at least say "I remember hitting something like that." An agent retains nothing at all. So teams that moved a lot of investigation onto agents also moved it into a system with a retention rate of zero, and the human fallback quietly stopped applying, because the human was not the one doing the investigating.

That is the trade most teams have made without deciding to make it. It is a good trade on speed and a bad one on accumulation.

Where to look for it

You will not find it in metrics. You can find it in conversation, and it is worth doing deliberately, because a team that has never named this problem tends to assume it is just how work feels.

Ask, in a retro, without judgement: what did you find out this month that you suspect somebody here already knew? People answer that question readily and specifically. The answers are usually about environments, about the seams between services, and about the reason something is the way it is.

Ask what a new joiner had to ask a person, because the answer was not anywhere they could have found it. Every one of those is a finding the team holds and has not stored.

Then look at how much of it is about relationships between repositories rather than inside one. In our experience that is where the highest concentration is, because a single repository has a codebase that can be read and a team boundary spans several that mostly cannot.

What would have to be true

For repeated investigation to stop being the default, a finding would have to be captured as a side effect of the work rather than as an additional task, retrievable by an agent working on an adjacent problem months later without knowing the finding exists, scoped to the team and its repositories rather than to one developer, and checked against the current code before it is presented, so that a stale finding is not simply repeated with confidence.

None of those four is exotic. All four at once is a system, and it is the system REM is being built to be: continuous observation, deliberate consolidation, claims linked to evidence and reconciled against the repository. It is in private beta.

The honest short version is that the first re-investigation costs almost nothing and the tenth costs a real fraction of the team, and no dashboard will ever tell you which one you are on.