Most engineering decisions are made with less evidence than people admit.

A staff engineer proposes deprecating an API. Someone says, "I think one or two internal jobs still use it."
A migration plan is drawn up around a list of services that may or may not still be talking to the old system.
A refactor ships on the assumption that the affected method is hot.
A rollback plan exists for a flow that may not exist in production anymore.

These decisions are not careless. They are made by experienced people. But the inputs are usually the same: stale documentation, partial memory, half-correct diagrams, and gut feel sharpened by years of pattern matching.

Most engineering decisions are not wrong because the engineers were wrong. They are wrong because the evidence was thin.

Confidence is not the same as evidence

In a long-lived system, confidence is cheap. Someone has always seen something. Someone always remembers how it used to work. Someone has a strong opinion.

Evidence is harder. Evidence is:

• This method ran 4.1 million times last week, almost entirely from one upstream service, and that service is scheduled to be decommissioned next quarter.
• This API has had zero production traffic for ninety days.
• This code path looks central in the diagram and is dormant in reality.

Decisions made on confidence feel fast. Decisions made on evidence are fast and hold up.

The gap between the two is where most expensive engineering mistakes live — the migration that breaks a forgotten consumer, the deprecation that takes down an internal job, the optimization that makes the wrong path faster.

Production is the strongest evidence engineers have

Tests show that the code can work. Reviews show that the code looks reasonable. Documentation shows what the code was once meant to do.

Production behaviour shows what the code actually does, right now, under real load, with real callers.

Architecture diagrams show intent. Production behaviour shows reality.

Nothing else in an engineering team's toolkit is as honest. Logs are filtered. Diagrams are aspirational. Tribal knowledge is partial. Production is just what happened.

The teams that make the best decisions are not the ones with the strongest opinions. They are the ones that put production behaviour into the room before the decision is made.

The shift

Behaviour-grounded decisions sound obvious. They are not common, because the evidence has historically been hard to get to. It sat in tracing systems, in dashboards, in queries somebody had to remember to run. That is changing. Production behaviour is becoming something you can put on the table next to the proposal, the same way you put a design doc on the table.

This is the direction CodeKarma is building toward — making behaviour cheap enough to consult that no serious change has to be argued from memory.

Confidence comes from behaviour, not assumptions.