History Needs a Reproduction Test

Every generation of software arrives with reasons the old rules no longer apply. The language is different. The infrastructure is managed. The model can reason. The team moves faster. Some of those changes are real. None of them repeal dependency, authority, state, incentives, or the need to prove that a system works outside its favorite conditions.

Calling the current project unprecedented is convenient because precedent comes with constraints. It asks who will operate the thing, where failures accumulate, how a boundary is enforced, and what happens when the optimistic assumption expires. Those questions slow down a preferred design before it gathers momentum. So teams wave at history, declare a new era, and rediscover an old mechanism under a newer name.

The problem is not ignorance. Engineers usually know that distributed systems fail partially, abstractions leak, migrations stall, and production finds the branch nobody modeled. The failure is operational: that knowledge does not have authority over the next plan. A lesson without a route into the work is trivia.

Learning from history does not mean rejecting every new approach because something once went wrong. That is cargo culting in the opposite direction. Two systems can look similar while the condition that caused the earlier failure is absent. They can also look completely different while sharing the same load-bearing mistake.

The useful record names the mechanism. What conditions existed? Which decision followed? What evidence supported it? What failed, under which pressure, and what changed afterward? If you cannot answer those questions, you do not have a reusable lesson. You have a story with enough empty space for everyone to insert their existing opinion.

That is why architecture folklore ages badly. A sentence like “we tried that before” can block good work for years. “This design creates two writers for state whose conflicts cannot be reconciled automatically” can be examined. The first asks for deference. The second offers a condition you can reproduce, test, or show no longer exists.

A software factory should not merely store decision records, incident reports, and retired designs. It should turn their mechanisms into checks that meet new work at the relevant boundary. A dependency failure becomes a graph rule. A permission escape becomes a policy test. A migration that collapsed under dual writes becomes an explicit state-transition constraint. A release that passed friendly tests and failed under real traffic becomes a new proof requirement.

This is where agents can outperform a human coordination system. People remember the dramatic outage and forget the quiet precondition. They apply a lesson when the wording feels familiar and miss it when the same mechanism wears a different interface. A factory can retrieve by affected component, authority boundary, state transition, or failure mode. It can place the old constraint in the plan before implementation begins and demand evidence when somebody claims the condition has changed.

Do not paste the whole archive into a giant context window. History needs routing. Give each retained lesson a scope, an owner, a trigger, and a retirement condition. Send the smallest relevant rule to the stage that can act on it. Otherwise the archive becomes noise, stale caution survives forever, and agents learn to route around it just as people did.

The best historical controls are not permanent commandments. They are claims the current plan must confront. If a team believes a new capability removes an old constraint, good. State exactly which capability changed, recreate the pressure that produced the earlier failure, and show the new system surviving it. A reproduction test turns “this time is different” from a mood into evidence.

That test also keeps the past from becoming a veto owned by the longest-tenured person in the room. Nobody gets to win by remembering harder. The factory preserves the original condition, runs the current design against it, and records what happened. Human judgment still decides whether the remaining risk is acceptable. It just does so with a result instead of competing recollections.

When the new design passes, update or retire the control. When it fails, route the evidence back to planning before a customer or operator has to discover it. History stays useful because it can be challenged mechanically, not because it is treated as sacred.

Our position is that organizational memory only exists when it changes execution. A document nobody retrieves is storage. A postmortem that produces no gate is therapy. An expert who must attend every review is a manual dependency. All three can contain wisdom, and all three lose it at the exact moment the work scales beyond the people who were there.

Start with one repeated failure. Reduce it to the condition that made it possible. Attach that condition to the planning, implementation, verification, or release boundary that can stop it. Then prove a fresh agent receives the constraint without somebody retelling the story. If the same failure returns, the organization did not forget. It never built memory in the first place.

Agents will make software production faster, which means they will also make historical amnesia more expensive. A factory can repeat a fashionable mistake at machine speed or turn every expensive lesson into a control every future run inherits. The difference is not how much history your team has read. It is whether the machinery can reproduce the past before production does.